[Xen-devel] [qemu-upstream-4.3-testing test] 94749: trouble: blocked/broken

[osstest service owner]

flight 94749 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94749/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  108 days
Testing same since93977  2016-05-10 11:09:16 Z   14 days   53 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

[Xen-devel] [ovmf test] 94750: regressions - FAIL

[osstest service owner]

flight 94750 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94750/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 94748

version targeted for testing:
 ovmf bd3fc8133b2b17ad2e0427d1bf6b44b08cf2f3b2
baseline version:
 ovmf dc99315b8732b6e3032d01319d3f534d440b43d0

Last test of basis94748  2016-05-24 22:43:25 Z0 days
Testing same since94750  2016-05-25 03:43:08 Z0 days1 attempts


People who touched revisions under test:
  Marvin H?user 
  Marvin Haeuser 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit bd3fc8133b2b17ad2e0427d1bf6b44b08cf2f3b2
Author: Marvin H?user 
Date:   Fri May 20 03:04:02 2016 +0800

ShellPkg/App: Fix memory leak and save resources.

1) RunSplitCommand() allocates the initial SplitStdOut via
   CreateFileInterfaceMem(). Free SplitStdIn after the swap to fix
   the memory leak.

2) In RunSplitCommand(), SplitStdOut is checked for equality with
   StdIn. This cannot happen due to the if-check within the swap.
   Hence remove it.

3) UefiMain() doesn't free SplitList. Delete all list entries and
   reinitialize the list when in DEBUG. This does not include the
   CreateFileInterfaceMem()-allocated SplitStd mentioned in 1), so
   keep the ASSERT() until resolved.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
Reviewed-by: Qiu Shumin 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [ovmf test] 94748: all pass - PUSHED

[osstest service owner]

flight 94748 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94748/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf dc99315b8732b6e3032d01319d3f534d440b43d0
baseline version:
 ovmf 328f84b1565165f35ea7755fb85b09fbf335c2cb

Last test of basis94739  2016-05-24 12:13:31 Z0 days
Testing same since94748  2016-05-24 22:43:25 Z0 days1 attempts


People who touched revisions under test:
  Jeff Fan 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=ovmf
+ revision=dc99315b8732b6e3032d01319d3f534d440b43d0
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
dc99315b8732b6e3032d01319d3f534d440b43d0
+ branch=ovmf
+ revision=dc99315b8732b6e3032d01319d3f534d440b43d0
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' xdc99315b8732b6e3032d01319d3f534d440b43d0 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 

[Xen-devel] [qemu-upstream-4.3-testing test] 94747: trouble: blocked/broken

[osstest service owner]

flight 94747 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94747/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  108 days
Testing same since93977  2016-05-10 11:09:16 Z   14 days   52 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

[Xen-devel] [PATCH 3/4] xen:arm: arm64: Add correct MPIDR_HWID_MASK value for ARM64

[Wei Chen]

Current MPIDR_HWID_MASK is using the bit definition of ARM32 MPIDR.
This value is not correct while Xen is running on ARM64.
Now, we add a correct value for this marco on ARM64. But this value
is not a valid 64-bit immediate which can be encoded in mov instruction.
So we have to use ldr to load this value to register.

Signed-off-by: Wei Chen 
---
 xen/arch/arm/arm64/head.S   | 2 +-
 xen/include/asm-arm/processor.h | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index d5831f2..3090beb 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -270,7 +270,7 @@ common_start:
 tbz   x0, _MPIDR_SMP, 1f /* Multiprocessor extension not 
supported? */
 tbnz  x0, _MPIDR_UP, 1f  /* Uniprocessor system? */
 
-mov   x13, #(~MPIDR_HWID_MASK)
+ldr   x13, =(~MPIDR_HWID_MASK)
 bic   x24, x0, x13   /* Mask out flags to get CPU ID */
 1:
 
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index b4cce7e..284ad6a 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -18,7 +18,11 @@
 #define MPIDR_SMP   (_AC(1,U) << _MPIDR_SMP)
 #define MPIDR_AFF0_SHIFT(0)
 #define MPIDR_AFF0_MASK (_AC(0xff,U) << MPIDR_AFF0_SHIFT)
+#ifdef CONFIG_ARM_64
+#define MPIDR_HWID_MASK _AC(0xff00ff,UL)
+#else
 #define MPIDR_HWID_MASK _AC(0xff,U)
+#endif
 #define MPIDR_INVALID   (~MPIDR_HWID_MASK)
 #define MPIDR_LEVEL_BITS(8)
 
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 4/4] xen/arm: arm64: Remove MPIDR multiprocessing extensions check

[Wei Chen]

In ARM64, the MPIDR multiprocessing extensions bit is reserved to 1.
So, the value check for this bit is no longer necessary on ARM64.

Signed-off-by: Wei Chen 
---
 xen/arch/arm/arm64/head.S | 1 -
 1 file changed, 1 deletion(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 3090beb..91e2817 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -267,7 +267,6 @@ common_start:
   * find that multiprocessor extensions are
   * present and the system is SMP  */
 mrs   x0, mpidr_el1
-tbz   x0, _MPIDR_SMP, 1f /* Multiprocessor extension not 
supported? */
 tbnz  x0, _MPIDR_UP, 1f  /* Uniprocessor system? */
 
 ldr   x13, =(~MPIDR_HWID_MASK)
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 1/4] xen/arm: Change the variable type of cpu_logical_map to register_t

[Wei Chen]

The cpu_logical_map is used to store CPU hardware ID from MPIDR_EL1 or
from CPU node of DT. Currently, the cpu_logical_map is using the u32 as
its variable type. It can work properly while Xen is running on ARM32,
because the hardware ID is 32-bits. While Xen is running on ARM64, the
hardware ID expands to 64-bits and then the cpu_logical_map will overflow.

Change the the variable type of cpu_logical_map to register_t will make
cpu_logical_map to store hardware ID correctly on ARM32 and ARM64.

Signed-off-by: Wei Chen 
---
 xen/arch/arm/gic-v3.c   |  2 +-
 xen/arch/arm/smpboot.c  | 13 +++--
 xen/include/asm-arm/processor.h |  2 +-
 3 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index a095064..9910877 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -674,7 +674,7 @@ static int __init gicv3_populate_rdist(void)
 } while ( !(typer & GICR_TYPER_LAST) );
 }
 
-dprintk(XENLOG_ERR, "GICv3: CPU%d: mpidr 0x%x has no re-distributor!\n",
+dprintk(XENLOG_ERR, "GICv3: CPU%d: mpidr 0x%"PRIregister" has no 
re-distributor!\n",
 smp_processor_id(), cpu_logical_map(smp_processor_id()));
 
 return -ENODEV;
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index c5109bf..ba83406 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -40,7 +40,7 @@ cpumask_t cpu_possible_map;
 struct cpuinfo_arm cpu_data[NR_CPUS];
 
 /* CPU logical map: map xen cpuid to an MPIDR */
-u32 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
+register_t __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
 
 /* Fake one node for now. See also include/asm-arm/numa.h */
 nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
@@ -100,7 +100,7 @@ static void __init dt_smp_init_cpus(void)
 struct dt_device_node *cpu;
 unsigned int i, j;
 unsigned int cpuidx = 1;
-static u32 tmp_map[NR_CPUS] __initdata =
+static register_t tmp_map[NR_CPUS] __initdata =
 {
 [0 ... NR_CPUS - 1] = MPIDR_INVALID
 };
@@ -120,7 +120,8 @@ static void __init dt_smp_init_cpus(void)
 {
 const __be32 *prop;
 u64 addr;
-u32 reg_len, hwid;
+u32 reg_len;
+register_t hwid;
 
 if ( !dt_device_type_is_equal(cpu, "cpu") )
 continue;
@@ -160,7 +161,7 @@ static void __init dt_smp_init_cpus(void)
  */
 if ( hwid & ~MPIDR_HWID_MASK )
 {
-printk(XENLOG_WARNING "cpu node `%s`: invalid hwid value (0x%x)\n",
+printk(XENLOG_WARNING "cpu node `%s`: invalid hwid value 
(0x%"PRIregister")\n",
dt_node_full_name(cpu), hwid);
 continue;
 }
@@ -176,7 +177,7 @@ static void __init dt_smp_init_cpus(void)
 if ( tmp_map[j] == hwid )
 {
 printk(XENLOG_WARNING
-   "cpu node `%s`: duplicate /cpu reg properties %"PRIx32" 
in the DT\n",
+   "cpu node `%s`: duplicate /cpu reg properties 
%"PRIregister" in the DT\n",
dt_node_full_name(cpu), hwid);
 break;
 }
@@ -211,7 +212,7 @@ static void __init dt_smp_init_cpus(void)
 
 if ( (rc = arch_cpu_init(i, cpu)) < 0 )
 {
-printk("cpu%d init failed (hwid %x): %d\n", i, hwid, rc);
+printk("cpu%d init failed (hwid %"PRIregister"): %d\n", i, hwid, 
rc);
 tmp_map[i] = MPIDR_INVALID;
 }
 else
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 6789cd0..7de9c8e 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -348,7 +348,7 @@ extern void identify_cpu(struct cpuinfo_arm *);
 extern struct cpuinfo_arm cpu_data[];
 #define current_cpu_data cpu_data[smp_processor_id()]
 
-extern u32 __cpu_logical_map[];
+extern register_t __cpu_logical_map[];
 #define cpu_logical_map(cpu) __cpu_logical_map[cpu]
 
 /* HSR data abort size definition */
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 2/4] xen/arm: Make AFFINITY_MASK generate correct mask for level3

[Wei Chen]

The original affinity shift bits algorithm in AFFINITY_MASK is buggy,
it could not generate correct affinity shift bits of level3.
The macro MPIDR_LEVEL_SHIFT can calculate level3 affinity shift bits
correctly. We use this macro in AFFINITY_MASK to generate correct
mask for level3.

Signed-off-by: Wei Chen 
---
 xen/include/asm-arm/processor.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 7de9c8e..b4cce7e 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -21,7 +21,6 @@
 #define MPIDR_HWID_MASK _AC(0xff,U)
 #define MPIDR_INVALID   (~MPIDR_HWID_MASK)
 #define MPIDR_LEVEL_BITS(8)
-#define AFFINITY_MASK(level)~((_AC(0x1,U) << ((level) * MPIDR_LEVEL_BITS)) 
- 1)
 
 
 /*
@@ -37,6 +36,8 @@
 #define MPIDR_AFFINITY_LEVEL(mpidr, level) \
  ((mpidr >> MPIDR_LEVEL_SHIFT(level)) & MPIDR_LEVEL_MASK)
 
+#define AFFINITY_MASK(level)~((_AC(0x1,UL) << MPIDR_LEVEL_SHIFT(level)) - 
1)
+
 /* TTBCR Translation Table Base Control Register */
 #define TTBCR_EAE_AC(0x8000,U)
 #define TTBCR_N_MASK _AC(0x07,U)
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 0/4] xen/arm: arm64: Widen register access to mpidr to 64-bits

[Wei Chen]

In ARM64 the MPIDR register is mapped to MPIDR_EL1, and the register
bits are expanded to 64-bits. But Xen 64-bit ARM code treats this it
as 32-bit register.
We have to provide correct accessing to this register to avoid
unexpected issues that is caused by incorrect MPIDR value.

Wei Chen (4):
  xen/arm: Change the variable type of cpu_logical_map to register_t
  xen/arm: Make AFFINITY_MASK generate correct mask for level3
  xen:arm: arm64: Add correct MPIDR_HWID_MASK value for ARM64
  xen/arm: arm64: Remove MPIDR multiprocessing extensions check

 xen/arch/arm/arm64/head.S   |  3 +--
 xen/arch/arm/gic-v3.c   |  2 +-
 xen/arch/arm/smpboot.c  | 13 +++--
 xen/include/asm-arm/processor.h |  9 +++--
 4 files changed, 16 insertions(+), 11 deletions(-)

-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-mainline test] 94743: tolerable FAIL - PUSHED

[osstest service owner]

flight 94743 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94743/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail REGR. vs. 94737
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94737
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 94737
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94737

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu287db79df8af8e31f18e262feb5e05103a09e4d4
baseline version:
 qemuu4c63a818de8d77bda3332c890fc52d900ebb2db1

Last test of basis94737  2016-05-24 10:42:05 Z0 days
Testing same since94743  2016-05-24 16:40:55 Z0 days1 attempts


People who touched revisions under test:
  Amit Shah 
  Eduardo Habkost 
  Greg Kurz 
  Jason J. Herne 
  Markus Armbruster 
  Peter Maydell 
  Wei Jiangang 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl   

[Xen-devel] [PATCH 1/7] x86/xen: Simplify set_aliased_prot

[Andy Lutomirski]

In aa1acff356bb ("x86/xen: Probe target addresses in
set_aliased_prot() before the hypercall"), I added an explicit probe
to work around a hypercall issue.  The code can be simplified by
using probe_kernel_read.

Cc: Andrew Cooper 
Cc: Boris Ostrovsky 
Cc: David Vrabel 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: xen-devel 
Signed-off-by: Andy Lutomirski 
---
 arch/x86/xen/enlighten.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 6ab672233ac9..eed696c229ba 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -521,9 +521,7 @@ static void set_aliased_prot(void *v, pgprot_t prot)
 
preempt_disable();
 
-   pagefault_disable();/* Avoid warnings due to being atomic. */
-   __get_user(dummy, (unsigned char __user __force *)v);
-   pagefault_enable();
+   probe_kernel_read(, (unsigned char *)v, 1);
 
if (HYPERVISOR_update_va_mapping((unsigned long)v, pte, 0))
BUG();
-- 
2.5.5


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-upstream-4.3-testing test] 94745: trouble: blocked/broken

[osstest service owner]

flight 94745 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94745/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  108 days
Testing same since93977  2016-05-10 11:09:16 Z   14 days   51 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

[Xen-devel] [xen-unstable test] 94740: tolerable FAIL

[osstest service owner]

flight 94740 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94740/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail   like 94730
 build-i386-rumpuserxen6 xen-buildfail   like 94730
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94730
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 94730
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 94730
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94730
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 94730

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  983aae0b591458c6cf2e3166c4e1170fd0404e7d
baseline version:
 xen  983aae0b591458c6cf2e3166c4e1170fd0404e7d

Last test of basis94740  2016-05-24 12:47:10 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 16945 days0 attempts

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvops   

Re: [Xen-devel] Question about the best practice to install two versions of Xen toolstack on the same machine

[Meng Xu]

Hi Olaf,

Thank you very much for your suggestion!

On Fri, May 20, 2016 at 4:52 AM, Olaf Hering  wrote:
> On Thu, May 19, Meng Xu wrote:
>
>> Does anyone try to install two version of Xen toolstack on the same machine?
>
> I do that. See the INSTALL file which has examples at the end:
>
> * To build a private copy of tools and xen:
> configure --prefix=/odd/path --sysconfdir=/odd/path/etc --enable-rpath
> make
> sudo make install BOOT_DIR=/ood/path/boot EFI_DIR=/odd/path/efi
>

I'm wondering if  BOOT_DIR=/ood/path/boot and EFI_DIR=/odd/path/efi is a must?
I'm using the grub2 to boot the kernel (so that I can remotely control
which grub entry I will get into).

I put the xen image to /boot and the system can boot up. The xl
toolstack seems working well.

However, the dom0's name is null.

When I run /ood/path/etc/init.d/xencommons restart , it reports the
following message:

Stopping xenconsoled
Stopping QEMU
WARNING: Not stopping xenstored, as it cannot be restarted.
Starting xenconsoled...
Starting QEMU as disk backend for dom0

I guess there is something wrong with the xenstored's configuration?
Did you happen to experience this issue before?


Thanks and Best Regards,

Meng
---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: RTDS: fix another instance of the 'read NOW()' race

[Wei Liu]

On Tue, May 24, 2016 at 05:06:58PM +0200, Dario Faggioli wrote:
> which was overlooked in 779511f4bf5ae ("sched: avoid
> races on time values read from NOW()").
> 
> Reported-by: Jan Beulich 
> Signed-off-by: Dario Faggioli 

Release-acked-by: Wei Liu 

> ---
> Cc: Meng Xu 
> Cc: George Dunlap 
> Cc: Jan Beulich 
> Cc: Wei Liu 
> ---
>  xen/common/sched_rt.c |4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
> index 0946101..5b077d7 100644
> --- a/xen/common/sched_rt.c
> +++ b/xen/common/sched_rt.c
> @@ -840,12 +840,14 @@ static void
>  rt_vcpu_insert(const struct scheduler *ops, struct vcpu *vc)
>  {
>  struct rt_vcpu *svc = rt_vcpu(vc);
> -s_time_t now = NOW();
> +s_time_t now;
>  spinlock_t *lock;
>  
>  BUG_ON( is_idle_vcpu(vc) );
>  
>  lock = vcpu_schedule_lock_irq(vc);
> +
> +now = NOW();
>  if ( now >= svc->cur_deadline )
>  rt_update_deadline(now, svc);
>  
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] ARM Xen Bug #45: Is there a solution?

[Julien Grall]

On 24/05/2016 14:39, Dirk Behme wrote:

Hi Julien,


Hello Dirk,


On 23.05.2016 22:15, Julien Grall wrote:

Hello Dirk,


is there a solution for

arm: domain 0 disables clocks which are in fact being used
http://bugs.xenproject.org/xen/bug/45

?

On an ARM based board I have to use 'clk_ignore_unused' preventing that
Dom0 disables the UART clock for the console UART configured with
console=hvc0.


There is no better solution than passing "clk_ignore_unused" on the
kernel command line so far.



What would be the solution for this issue? The

"propagate any clock related properties from the UART
node into the Xen hypervisor node"

mentioned in the ticket?


That is correct. Xen would copy the property "clocks" of the UART into 
the hypervisor node.


DOM0 would then parse the clocks associated to this node and mark them 
as used by Xen (I think CLK_IGNORE_UNUSED could do the job for us).


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC for-4.8 0/6] xen/arm: Add support for mapping mmio-sram nodes into dom0

[Julien Grall]

Hi Edgar,

On 23/05/2016 16:42, Edgar E. Iglesias wrote:

On Mon, May 23, 2016 at 04:13:53PM +0100, Julien Grall wrote:

On 23/05/16 15:02, Edgar E. Iglesias wrote:

On Mon, May 23, 2016 at 02:02:39PM +0100, Julien Grall wrote:

(CC Wei Liu)

On 23/05/16 12:56, Edgar E. Iglesias wrote:

On Mon, May 23, 2016 at 11:29:31AM +0100, Julien Grall wrote:

On 20/05/16 16:51, Edgar E. Iglesias wrote:

From: "Edgar E. Iglesias" 

This series adds support for mapping mmio-sram nodes into dom0
as MEMORY, cached and with RWX perms.


Can you explain why you chose to map those nodes as MEMORY, cached and with
RWX perms?


My understanding is that these mmio-sram nodes are allowed to be treated as
Normal memory by the guest OS.
Guests could potentially do any kind of memory like operations on them.

In our specific case, dom0 won't execute code from these regions but
Linux/dom0 ends up using standard memcpy/memset/x functions (not
memcpy_fromio and friends) on the regions.


I looked at the generic sram driver in Linux (drivers/misc/sram.c) which
actually use memcpy_{to,from}io. So how you driver differs from the generic
one? What the SRAM will contain?


We intend to use that same driver to map the memory but mmio-sram
nodes allow you to assign the regions to other device-drivers.

Some examples:
Documentation/devicetree/bindings/crypto/marvell-cesa.txt
arch/arm/boot/dts/orion5x.dtsi
drivers/crypto/mv_cesa.c

The cover letter for the sram driver had an example aswell allthough
the function names have changed since (it's of_gen_pool_get now):
https://lwn.net/Articles/537728/

Nothing explicitely says that the regions can be assumed to be mapped
as Normal memory, but on Linux they do get mapped as Mormal WC mem
(unless the no-memory-wc prop is set on the node).
The marvell-cesa example also uses plain memset on the sram.


I am a bit confused with this example. From my understanding of
mv_cesa_get_ram, cp->sram can point either to a normal memory (?) area (see
gen_pool_dma_alloc) or a Device_nGnRE area (see devm_ioremap_resource).

However, memcpy_{from,to}io should be used when dealing with MMIO (the field
sram has the __iomem attribute). See the commit 0f3304dc from Russel King
related to marvell/cesa.



Yeah, I'm started to get confused too. Maybe they just forgot the memset
in drivers/crypto/mv_cesa.c.

There are other examples though, that don't do fromio/toio at all.
Documentation/devicetree/bindings/media/coda.txt
drivers/media/platform/coda/coda-common.c

Allthough ofcourse, these could also be wrong. Maybe I've missunderstood how
mmio-sram is supposed to be used.


I have talked about the memory attribute around me and the consensus is 
we should use the most relaxed mode that does not have any security 
implication or undefined behavior for a given device.


For SRAM it would be normal memory uncached (?) when the property 
"no-memory-wc" is not present, else TBD.


I suspect we would have to relax more MMIOs in the future. Rather than 
providing a function to map, the code is very similar except the memory 
attribute, I suggest to provide a list of compatible with the memory 
attribute to use.


All the children node would inherit the memory attribute of the parent.

What do you think?

Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: RTDS: fix another instance of the 'read NOW()' race

[Meng Xu]

On Tue, May 24, 2016 at 11:06 AM, Dario Faggioli
 wrote:
> which was overlooked in 779511f4bf5ae ("sched: avoid
> races on time values read from NOW()").
>
> Reported-by: Jan Beulich 
> Signed-off-by: Dario Faggioli 
> ---
> Cc: Meng Xu 
> Cc: George Dunlap 
> Cc: Jan Beulich 
> Cc: Wei Liu 
> ---

Reviewed-by: Meng Xu 

-- 
Best Regards,

Meng

Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable-smoke test] 94744: tolerable all pass - PUSHED

[osstest service owner]

flight 94744 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94744/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  4504b7d1a6594c8ad4b1ecdab15d30feca7eaa51
baseline version:
 xen  983aae0b591458c6cf2e3166c4e1170fd0404e7d

Last test of basis94725  2016-05-23 19:01:56 Z0 days
Testing same since94744  2016-05-24 17:01:59 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Ian Jackson 
  Jan Beulich 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=4504b7d1a6594c8ad4b1ecdab15d30feca7eaa51
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
4504b7d1a6594c8ad4b1ecdab15d30feca7eaa51
+ branch=xen-unstable-smoke
+ revision=4504b7d1a6594c8ad4b1ecdab15d30feca7eaa51
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' x4504b7d1a6594c8ad4b1ecdab15d30feca7eaa51 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print 

[Xen-devel] [qemu-upstream-4.3-testing test] 94742: trouble: blocked/broken

[osstest service owner]

flight 94742 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94742/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  108 days
Testing same since93977  2016-05-10 11:09:16 Z   14 days   50 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-qemuu-ovmf-amd64

[Wei Liu]

On Sun, May 22, 2016 at 05:37:51AM +, osstest service owner wrote:
> branch xen-unstable
> xenbranch xen-unstable
> job test-amd64-amd64-xl-qemuu-ovmf-amd64
> testid guest-start/debianhvm.repeat
> 
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
> Tree: xen git://xenbits.xen.org/xen.git
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen git://xenbits.xen.org/xen.git
>   Bug introduced:  1542efcea893df874b13b1ea78101e1ff6a55c41
>   Bug not present: c32381352cce9744e640bf239d2704dae4af4fc7
>   Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/94689/
> 
> 
>   commit 1542efcea893df874b13b1ea78101e1ff6a55c41
>   Author: Wei Liu 
>   Date:   Wed May 18 11:48:25 2016 +0100
>   
>   Config.mk: update ovmf changeset
>   
>   Signed-off-by: Wei Liu 
> 

I did some tests and analysis today.

* Manual tests

Seconds between starting a guest to receiving ping, test three times

  xl create guest.cfg ;\
  s=`date +%s`; date --date="@$s"; \
  while true;  do \
   ping -c 1  -q -W 1 172.16.147.190 2>&1 1>/dev/null;\
   if [ $? = 0 ]; then break; fi ;\
   done;\
  e=`date +%s`; date --date="@$e";\
  expr $e - $s

  merlot0 tg06
old ovmf, 5000mb ram 98 99 9633 32 31
old ovmf, 768mb  ram 97 100 100  31 31 32
new ovmf, 5000mb ram 158 158 157 25 26 25
new ovmf, 768mb  ram 151 156 160 26 25 25

Old ovmf refers to 52a99493 (currently in master)
New ovmf refers to b41ef325 (the fingered one)

Tg06 and merlot0 have the same changeset git:983aae0.

Note that the guest runs on tg06 has a different version of Debian, so it is
not really comparable to the guest on merlot0.  Also note that we can't
extrapolate from my manual test that osstest will or will not see timeout on
merlot0 because the technique to test that is not the same.

The conclusions are: we now know the results are consistent and the guest
memory size doesn't affect the time taken to start the guest.

* Osstest report

Pick the ovmf flight that tested the fingered changeset:

http://logs.test-lab.xenproject.org/osstest/logs/94519/test-amd64-amd64-xl-qemuu-ovmf-amd64/17.ts-repeat-test.log

2016-05-18 05:40:26 Z guest debianhvm.guest.osstest 5a:36:0e:37:00:01 22 
link/ip/tcp: ok. (185s) 
2016-05-18 05:44:13 Z guest debianhvm.guest.osstest 5a:36:0e:37:00:01 22 
link/ip/tcp: ok. (184s) 
2016-05-18 05:47:55 Z guest debianhvm.guest.osstest 5a:36:0e:37:00:01 22 
link/ip/tcp: ok. (184s) 
...

The time out for checking if a guest is up is 200 seconds so 180 seconds should
be fine.

The new ovmf failure reported by bisector is the controller timed out when
trying to check if the guest is up.


http://logs.test-lab.xenproject.org/osstest/logs/94689/test-amd64-amd64-xl-qemuu-ovmf-amd64/17.ts-repeat-test.log

The old ovmf passed on merlot0:


http://logs.test-lab.xenproject.org/osstest/logs/94680/test-amd64-amd64-xl-qemuu-ovmf-amd64/17.ts-repeat-test.log
2016-05-22 02:49:57 Z guest debianhvm.guest.osstest 5a:36:0e:d8:00:01 22 
link/ip/tcp: ok. (141s) 

The old ovmf passed on other machine:


http://logs.test-lab.xenproject.org/osstest/logs/94580/test-amd64-amd64-xl-qemuu-ovmf-amd64/17.ts-repeat-test.log

2016-05-19 22:45:39 Z guest debianhvm.guest.osstest 5a:36:0e:74:00:3c 22 
link/ip/tcp: ok. (122s) 

The two numbers suggest that merlot is slower than the other machine.

Pick one of the recent test report for OVMF:

http://logs.test-lab.xenproject.org/osstest/logs/94739/test-amd64-amd64-xl-qemuu-ovmf-amd64/17.ts-repeat-test.log

The same metric (guest creation to guest responding to network traffic) is a
lot shorter (on a non-merlot machine):

2016-05-24 14:21:59 Z guest debianhvm.guest.osstest 5a:36:0e:13:00:02 22 
link/ip/tcp: ok. (49s) 
2016-05-24 14:23:28 Z guest debianhvm.guest.osstest 5a:36:0e:13:00:02 22 
link/ip/tcp: ok. (49s) 
2016-05-24 14:25:03 Z guest debianhvm.guest.osstest 5a:36:0e:13:00:02 22 
link/ip/tcp: ok. (48s) 
2016-05-24 14:26:45 Z guest debianhvm.guest.osstest 5a:36:0e:13:00:02 22 
link/ip/tcp: ok. (48s) 
...

It looks like it's getting better.

I don't have a conclusion on this issue because I can't eliminate all
variables.  I'm inclined to push another a newer ovmf changeset to see what
happens, because:

1. merlot is slower than other machine, the time difference is about 20s.
2. new ovmf on other machine already takes ~180s to come up (less than 20s to
   200s timeout).
3. the time taken to come up seems to get shorter, though I didn't see why when
   I skimmed ovmf changelog.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] x86 PAT fixes for stable

[Kani, Toshimitsu]

Hello,

The following patches fix two x86 PAT issues reported in 4.4 [1][2]. Can
you please backport them up to 4.4? 

1/7 x86/mm/pat: Add support of non-default PAT MSR setting
02f037d641dc6672be5cfe7875a48ab99b95b154

2/7 x86/mm/pat: Add pat_disable() interfacecommit
224bb1e5d67ba0f2872c98002d6a6f991ac6fd4a

3/7 x86/mm/pat: Replace cpu_has_pat with boot_cpu_has
d63dcf49cf5ae5605f4d14229e3888e104f294b1

4/7 x86/mtrr: Fix Xorg crashes in Qemu sessions
edfe63ec97ed8d4496225f7ba54c9ce4207c5431

5/7 x86/mtrr: Fix PAT init handling when MTRR is disabled
ad025a73f0e9344ac73ffe1b74c184033e08e7d5

6/7 x86/xen,pat: Remove PAT table init code from Xen
88ba281108ed0c25c9d292b48bd3f272fcb90dd0

7/7 x86/pat: Document PAT initialization
b6350c21cfe8aa9d65e189509a23c0ea4b8362c2

1/1 x86/mm/pat: Fix BUG_ON in mmap_mem on QEMU/i386
1886297ce0c8d563a08c8a8c4c0b97743e06cd37

Thanks,
-Toshi
 
[1] https://lkml.org/lkml/2016/3/3/828
[2] http://www.gossamer-threads.com/lists/xen/devel/432189?page=last
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC 15/18] arm: Add ability to relocate Xen in over 4GB space

[Julien Grall]

Hello,

On 18/05/16 17:32, Andrii Anisov wrote:

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 48f734f..7e507bc 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -394,9 +394,13 @@ static paddr_t __init get_xen_paddr(void)
  const struct membank *bank = >bank[i];
  paddr_t s, e;

+//TODO: investigate reason why we need contiguous memory
+//and how it can affect relocation of Xen in over 4GB space


Xen ARM was not able to support sparse memory before Xen 4.5. I.e only 
contiguous banks were supported. Xen had to be relocated on those banks 
to avoid issues when the init memory was released.


I believe this is not necessary anymore. Can you send this fix in a 
separate patch?



+#ifndef ARM32_RELOCATE_OVER_4GB
  /* We can only deal with contiguous memory at the moment */
  if ( last_end != bank->start )
  break;
+#endif

  last_end = bank->start + bank->size;



Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] PAT-related crash booting Linux 4.4 + Xen 4.5 on VMware ESXi

[Kani, Toshimitsu]

On Tue, 2016-05-24 at 11:54 -0400, Boris Ostrovsky wrote:
> On 05/24/2016 10:53 AM, Kani, Toshimitsu wrote:
> > 
> > On Mon, 2016-05-23 at 15:52 -0700, Ed Swierk wrote:
> > > 
> > > Good question. I ran my tests again, and found I'd misinterpreted the
> > > Fusion behavior.
> > > 
> > > On Fusion 8.1.1, MSR_IA32_CR_PAT returns a reasonable value:
> > > 
> > > (XEN) Freed 308kB init memory.
> > > mapping kernel into physical memory
> > > cpu_has_pat=0 cpuid_edx(1)=f89cbf5 pat=65536
> > > pat_init_cache_modes pat=50100070406
> > > pat_init_cache_modes i=7 pat_val=0 cache=3
> > > pat_init_cache_modes ok
> > > pat_init_cache_modes i=6 pat_val=0 cache=3
> > > pat_init_cache_modes ok
> > > pat_init_cache_modes i=5 pat_val=5 cache=5
> > > pat_init_cache_modes ok
> > > pat_init_cache_modes i=4 pat_val=1 cache=1
> > > pat_init_cache_modes ok
> > > pat_init_cache_modes i=3 pat_val=0 cache=3
> > > pat_init_cache_modes ok
> > > pat_init_cache_modes i=2 pat_val=7 cache=2
> > > pat_init_cache_modes ok
> > > pat_init_cache_modes i=1 pat_val=4 cache=4
> > > pat_init_cache_modes ok
> > > pat_init_cache_modes i=0 pat_val=6 cache=0
> > > pat_init_cache_modes ok
> > > pat_init_cache_modes pat_msg=WB  WT  UC- UC  WC  WP  UC  UC
> > > about to get started...
> > > [0.00] x86/PAT: Configuration [0-7]: WB  WT  UC-
> > > UC  WC  WP  UC  UC
> > > 
> > > On ESXi 5.5.0, MSR_IA32_CR_PAT returns 0, and we are indeed hitting
> > > the BUG_ON in update_cache_mode_entry():
> > > 
> > > (XEN) Freed 312kB init memory.
> > > mapping kernel into physical memory
> > > cpu_has_pat=0 cpuid_edx(1)=f89cbf5 pat=65536
> > > pat_init_cache_modes pat=0
> > > pat_init_cache_modes i=7 pat_val=0 cache=3
> > > pat_init_cache_modes ok
> > > pat_init_cache_modes i=6 pat_val=0 cache=3
> > > pat_init_cache_modes ok
> > > pat_init_cache_modes i=5 pat_val=0 cache=3
> > > pat_init_cache_modes ok
> > > pat_init_cache_modes i=4 pat_val=0 cache=3
> > > pat_init_cache_modes ok
> > > pat_init_cache_modes i=3 pat_val=0 cache=3
> > > pat_init_cache_modes ok
> > > pat_init_cache_modes i=2 pat_val=0 cache=3
> > > pat_init_cache_modes ok
> > > pat_init_cache_modes i=1 pat_val=0 cache=3
> > > pat_init_cache_modes ok
> > > pat_init_cache_modes i=0 pat_val=0 cache=3
> > > (XEN) traps.c:459:d0v0 Unhandled invalid opcode fault/trap [#6] on
> > > VCPU 0 [ec=]
> > > (XEN) domain_crash_sync called from entry.S: fault at
> > > 82d0802276c3
> > > create_bounce_frame+0x12b/0x13a
> > > 
> > > In both cases, the PAT CPUID feature bit is set, and cpu_has_pat is
> > > always 0 at this early point (so my RFC patch is wrong). The simplest
> > > fix is to call pat_init_cache_modes(pat) only if pat != 0.
> > > 
> > > This is starting to look like the same logic that's in
> > > pat_bsp_init(),
> > > which doesn't seem to be called when booting on Xen. Should it be?
> > > Was
> > > Xen deliberately excluded from this PAT emulation change?
> > > https://groups.google.com/d/msg/linux.kernel/JoJKbCOxV0U/PM0I9d1v60kJ
> >
> > Calling pat_init() requires the CPU rendezvous handler in MTRR, which
> > is disabled in Xen.  This PAT initialization has been problematic, and
> > the following patches addressed it in 4.6.  This will fix your problem
> > as well. 
> > https://lkml.org/lkml/2016/3/23/500
> > 
> > In particular, patch 6/7 removed the Xen code in question.
> > https://lkml.org/lkml/2016/3/23/503
> > 
> > Do you need to fix this issue in 4.4?  If so, we should be able to
> > request backporting the patches to 4.4 stable.
> 
> Would disabling PAT when the MSR is clearly broken (and not trying to
> emulate it) not work?

That should work, but the above patches fix the qemu32 issue also found in
4.4. So, they need to be backported to 4.4.
https://lkml.org/lkml/2016/3/3/828

-Toshi
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] xen: use vma_pages().

[Boris Ostrovsky]

On 05/23/2016 08:04 PM, Muhammad Falak R Wani wrote:
> Replace explicit computation of vma page count by a call to
> vma_pages().
>
> Signed-off-by: Muhammad Falak R Wani 

Reviewed-by: Boris Ostrovsky 



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-mainline test] 94737: tolerable FAIL - PUSHED

[osstest service owner]

flight 94737 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94737/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 94724
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94724
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94724

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu4c63a818de8d77bda3332c890fc52d900ebb2db1
baseline version:
 qemuuc9158547617584bb9d19db7fb139998fbef80133

Last test of basis94724  2016-05-23 18:12:07 Z0 days
Testing same since94737  2016-05-24 10:42:05 Z0 days1 attempts


People who touched revisions under test:
  Max Filippov 
  Peter Maydell 
  Zhou Jie 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 

Re: [Xen-devel] [Qemu-devel] [PATCH] xen: Clean up includes

[Eric Blake]

On 05/24/2016 09:27 AM, Peter Maydell wrote:
> Clean up includes so that osdep.h is included first and headers
> which it implies are not included manually.
> 
> This commit was created with scripts/clean-includes.
> 
> Signed-off-by: Peter Maydell 
> ---
>  hw/usb/xen-usb.c | 5 +
>  include/hw/xen/xen.h | 1 -
>  2 files changed, 1 insertion(+), 5 deletions(-)
> 

Reviewed-by: Eric Blake 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] PAT-related crash booting Linux 4.4 + Xen 4.5 on VMware ESXi

[Boris Ostrovsky]

On 05/24/2016 10:53 AM, Kani, Toshimitsu wrote:
> On Mon, 2016-05-23 at 15:52 -0700, Ed Swierk wrote:
>> Good question. I ran my tests again, and found I'd misinterpreted the
>> Fusion behavior.
>>
>> On Fusion 8.1.1, MSR_IA32_CR_PAT returns a reasonable value:
>>
>> (XEN) Freed 308kB init memory.
>> mapping kernel into physical memory
>> cpu_has_pat=0 cpuid_edx(1)=f89cbf5 pat=65536
>> pat_init_cache_modes pat=50100070406
>> pat_init_cache_modes i=7 pat_val=0 cache=3
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=6 pat_val=0 cache=3
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=5 pat_val=5 cache=5
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=4 pat_val=1 cache=1
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=3 pat_val=0 cache=3
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=2 pat_val=7 cache=2
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=1 pat_val=4 cache=4
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=0 pat_val=6 cache=0
>> pat_init_cache_modes ok
>> pat_init_cache_modes pat_msg=WB  WT  UC- UC  WC  WP  UC  UC
>> about to get started...
>> [0.00] x86/PAT: Configuration [0-7]: WB  WT  UC-
>> UC  WC  WP  UC  UC
>>
>> On ESXi 5.5.0, MSR_IA32_CR_PAT returns 0, and we are indeed hitting
>> the BUG_ON in update_cache_mode_entry():
>>
>> (XEN) Freed 312kB init memory.
>> mapping kernel into physical memory
>> cpu_has_pat=0 cpuid_edx(1)=f89cbf5 pat=65536
>> pat_init_cache_modes pat=0
>> pat_init_cache_modes i=7 pat_val=0 cache=3
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=6 pat_val=0 cache=3
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=5 pat_val=0 cache=3
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=4 pat_val=0 cache=3
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=3 pat_val=0 cache=3
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=2 pat_val=0 cache=3
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=1 pat_val=0 cache=3
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=0 pat_val=0 cache=3
>> (XEN) traps.c:459:d0v0 Unhandled invalid opcode fault/trap [#6] on
>> VCPU 0 [ec=]
>> (XEN) domain_crash_sync called from entry.S: fault at 82d0802276c3
>> create_bounce_frame+0x12b/0x13a
>>
>> In both cases, the PAT CPUID feature bit is set, and cpu_has_pat is
>> always 0 at this early point (so my RFC patch is wrong). The simplest
>> fix is to call pat_init_cache_modes(pat) only if pat != 0.
>>
>> This is starting to look like the same logic that's in pat_bsp_init(),
>> which doesn't seem to be called when booting on Xen. Should it be? Was
>> Xen deliberately excluded from this PAT emulation change?
>> https://groups.google.com/d/msg/linux.kernel/JoJKbCOxV0U/PM0I9d1v60kJ
> Calling pat_init() requires the CPU rendezvous handler in MTRR, which is
> disabled in Xen.  This PAT initialization has been problematic, and the
> following patches addressed it in 4.6.  This will fix your problem as
> well. 
> https://lkml.org/lkml/2016/3/23/500
>
> In particular, patch 6/7 removed the Xen code in question.
> https://lkml.org/lkml/2016/3/23/503
>
> Do you need to fix this issue in 4.4?  If so, we should be able to request
> backporting the patches to 4.4 stable.


Would disabling PAT when the MSR is clearly broken (and not trying to
emulate it) not work?

-boris


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 08/16] x86: add multiboot2 protocol support

[Jan Beulich]

>>> On 15.04.16 at 14:33,  wrote:
> @@ -19,6 +20,28 @@
>  #define BOOT_PSEUDORM_CS 0x0020
>  #define BOOT_PSEUDORM_DS 0x0028
>  
> +#define MB2_HT(name)  (MULTIBOOT2_HEADER_TAG_##name)
> +#define MB2_TT(name)  (MULTIBOOT2_TAG_TYPE_##name)
> +
> +.macro mb2ht_args arg, args:vararg
> +.long \arg
> +.ifnb \args
> +mb2ht_args \args
> +.endif
> +.endm
> +
> +.macro mb2ht_init type, req, args:vararg

If you already use :vararg here and above, please also use :req on
the other macro arguments.

> @@ -34,6 +57,42 @@ multiboot1_header_start:   /*** MULTIBOOT1 HEADER /
>  .long   -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
>  multiboot1_header_end:
>  
> +/*** MULTIBOOT2 HEADER /
> +/* Some ideas are taken from grub-2.00/grub-core/tests/boot/kernel-i386.S 
> file. */
> +.align  MULTIBOOT2_HEADER_ALIGN
> +
> +multiboot2_header_start:
> +/* Magic number indicating a Multiboot2 header. */
> +.long   MULTIBOOT2_HEADER_MAGIC
> +/* Architecture: i386. */
> +.long   MULTIBOOT2_ARCHITECTURE_I386
> +/* Multiboot2 header length. */
> +.long   multiboot2_header_end - multiboot2_header_start
> +/* Multiboot2 header checksum. */
> +.long   -(MULTIBOOT2_HEADER_MAGIC + MULTIBOOT2_ARCHITECTURE_I386 + \
> +(multiboot2_header_end - multiboot2_header_start))
> +
> +/* Multiboot2 information request tag. */
> +mb2ht_init MB2_HT(INFORMATION_REQUEST), MB2_HT(REQUIRED), \
> +   MB2_TT(BASIC_MEMINFO), MB2_TT(MMAP)
> +
> +/* Align modules at page boundry. */
> +mb2ht_init MB2_HT(MODULE_ALIGN), MB2_HT(REQUIRED)
> +
> +/* Console flags tag. */
> +mb2ht_init MB2_HT(CONSOLE_FLAGS), MB2_HT(OPTIONAL), \
> +   MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
> +
> +/* Framebuffer tag. */
> +mb2ht_init MB2_HT(FRAMEBUFFER), MB2_HT(OPTIONAL), \
> +   0, /* Number of the columns - no preference. */ \
> +   0, /* Number of the lines - no preference. */ \
> +   0  /* Number of bits per pixel - no preference. */
> +
> +/* Multiboot2 header end tag. */
> +mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
> +multiboot2_header_end:

Imo "end" labels should always preferably be .L-prefixed, to avoid
them getting used by a consumer instead of another "proper" label
starting whatever comes next.

> @@ -82,10 +141,49 @@ __start:
>  mov %ecx,%es
>  mov %ecx,%ss
>  
> -/* Check for Multiboot bootloader */
> +/* Bootloaders may set multiboot{1,2}.mem_lower to a nonzero value. 
> */
> +xor %edx,%edx
> +
> +/* Check for Multiboot2 bootloader. */
> +cmp $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
> +je  multiboot2_proto
> +
> +/* Check for Multiboot bootloader. */
>  cmp $MULTIBOOT_BOOTLOADER_MAGIC,%eax
>  jne not_multiboot
>  
> +/* Get mem_lower from Multiboot information. */
> +testb   $MBI_MEMLIMITS,MB_flags(%ebx)
> +
> +/* Not available? BDA value will be fine. */
> +cmovnz  MB_mem_lower(%ebx),%edx
> +jmp trampoline_setup
> +
> +multiboot2_proto:
> +/* Skip Multiboot2 information fixed part. */
> +lea (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%ebx),%ecx
> +and $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
> +
> +0:
> +/* Get mem_lower from Multiboot2 information. */
> +cmpl$MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,MB2_tag_type(%ecx)
> +jne 1f
> +
> +mov MB2_mem_lower(%ecx),%edx
> +jmp trampoline_setup
> +
> +1:
> +/* Is it the end of Multiboot2 information? */
> +cmpl$MULTIBOOT2_TAG_TYPE_END,MB2_tag_type(%ecx)
> +je  trampoline_setup
> +
> +/* Go to next Multiboot2 information tag. */
> +add MB2_tag_size(%ecx),%ecx
> +add $(MULTIBOOT2_TAG_ALIGN-1),%ecx
> +and $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
> +jmp 0b

I'm missing a total size check, matching what meanwhile got added
to the C equivalent(s) of this loop. There's little point in doing it
there if it doesn't also get done here.

> @@ -41,7 +45,16 @@ asm (
>  );
>  
>  typedef unsigned int u32;
> +typedef unsigned long long u64;
> +
>  #include "../../../include/xen/multiboot.h"
> +#include "../../../include/xen/multiboot2.h"
> +
> +#define ALIGN_UP(addr, align) \
> +(((addr) + (typeof(addr))(align) - 1) & 
> ~((typeof(addr))(align) - 1))

What is the left typeof() needed for here? (I can see the point of
the right one.)

> +static multiboot_info_t *mbi2_mbi(u32 mbi_in)
> +{
> +const multiboot2_memory_map_t *mmap_src;
> +const multiboot2_tag_t *tag;
> +/* Do not complain that mbi_out_mods is not initialized. */
> +module_t 

Re: [Xen-devel] [PATCH] libxl: drop stray const from function return type

[Wei Liu]

On Tue, May 24, 2016 at 04:42:12PM +0100, Ian Jackson wrote:
> Jan Beulich writes ("[PATCH] libxl: drop stray const from function return 
> type"):
> > Some compiler versions warn about this, causing the build to fail due
> > to -Werror.
> > 
> > Signed-off-by: Jan Beulich 
> 
> Acked-by: Ian Jackson 

Queued.

Thank you both.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] libxl: drop stray const from function return type

[Ian Jackson]

Jan Beulich writes ("[PATCH] libxl: drop stray const from function return 
type"):
> Some compiler versions warn about this, causing the build to fail due
> to -Werror.
> 
> Signed-off-by: Jan Beulich 

Acked-by: Ian Jackson 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] libxl: Avoid advertising about device_model_user config option

[Ian Jackson]

Anthony PERARD writes ("[PATCH v2] libxl: Avoid advertising about 
device_model_user config option"):
> Running QEMU as non-root user is not ready yet, so replace the warning
> with a debug message and remove the option from the man page.
> 
> Also improve the doc to include more potential issue with running QEMU
> as non-root.

LGTM

Acked-by: Ian Jackson 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] libxl: drop stray const from function return type

[Jan Beulich]

Some compiler versions warn about this, causing the build to fail due
to -Werror.

Signed-off-by: Jan Beulich 

--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5354,8 +5354,8 @@ libxl_numainfo *libxl_get_numainfo(libxl
 return ret;
 }
 
-static const int libxl__xc_version_wrap(libxl__gc *gc, libxl_version_info 
*info,
-xen_build_id_t *build)
+static int libxl__xc_version_wrap(libxl__gc *gc, libxl_version_info *info,
+  xen_build_id_t *build)
 {
 int r;
 



libxl: drop stray const from function return type

Some compiler versions warn about this, causing the build to fail due
to -Werror.

Signed-off-by: Jan Beulich 

--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5354,8 +5354,8 @@ libxl_numainfo *libxl_get_numainfo(libxl
 return ret;
 }
 
-static const int libxl__xc_version_wrap(libxl__gc *gc, libxl_version_info 
*info,
-xen_build_id_t *build)
+static int libxl__xc_version_wrap(libxl__gc *gc, libxl_version_info *info,
+  xen_build_id_t *build)
 {
 int r;
 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] xen: Clean up includes

[Peter Maydell]

Clean up includes so that osdep.h is included first and headers
which it implies are not included manually.

This commit was created with scripts/clean-includes.

Signed-off-by: Peter Maydell 
---
 hw/usb/xen-usb.c | 5 +
 include/hw/xen/xen.h | 1 -
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c
index 664df04..8fa47ed 100644
--- a/hw/usb/xen-usb.c
+++ b/hw/usb/xen-usb.c
@@ -19,13 +19,10 @@
  *  GNU GPL, version 2 or (at your option) any later version.
  */
 
+#include "qemu/osdep.h"
 #include 
-#include 
-#include 
 #include 
-#include 
 
-#include "qemu/osdep.h"
 #include "qemu-common.h"
 #include "qemu/config-file.h"
 #include "hw/sysbus.h"
diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index 6365483..b2cd992 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -8,7 +8,6 @@
  */
 
 #include "qemu-common.h"
-#include "qemu/typedefs.h"
 #include "exec/cpu-common.h"
 #include "hw/irq.h"
 
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] PAT-related crash booting Linux 4.4 + Xen 4.5 on VMware ESXi

[Ed Swierk]

Yes, we're just now moving to 4.4 stable, and will be there for a
while, so backporting would be very helpful.

--Ed


On Tue, May 24, 2016 at 7:53 AM, Kani, Toshimitsu  wrote:
> On Mon, 2016-05-23 at 15:52 -0700, Ed Swierk wrote:
>> Good question. I ran my tests again, and found I'd misinterpreted the
>> Fusion behavior.
>>
>> On Fusion 8.1.1, MSR_IA32_CR_PAT returns a reasonable value:
>>
>> (XEN) Freed 308kB init memory.
>> mapping kernel into physical memory
>> cpu_has_pat=0 cpuid_edx(1)=f89cbf5 pat=65536
>> pat_init_cache_modes pat=50100070406
>> pat_init_cache_modes i=7 pat_val=0 cache=3
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=6 pat_val=0 cache=3
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=5 pat_val=5 cache=5
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=4 pat_val=1 cache=1
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=3 pat_val=0 cache=3
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=2 pat_val=7 cache=2
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=1 pat_val=4 cache=4
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=0 pat_val=6 cache=0
>> pat_init_cache_modes ok
>> pat_init_cache_modes pat_msg=WB  WT  UC- UC  WC  WP  UC  UC
>> about to get started...
>> [0.00] x86/PAT: Configuration [0-7]: WB  WT  UC-
>> UC  WC  WP  UC  UC
>>
>> On ESXi 5.5.0, MSR_IA32_CR_PAT returns 0, and we are indeed hitting
>> the BUG_ON in update_cache_mode_entry():
>>
>> (XEN) Freed 312kB init memory.
>> mapping kernel into physical memory
>> cpu_has_pat=0 cpuid_edx(1)=f89cbf5 pat=65536
>> pat_init_cache_modes pat=0
>> pat_init_cache_modes i=7 pat_val=0 cache=3
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=6 pat_val=0 cache=3
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=5 pat_val=0 cache=3
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=4 pat_val=0 cache=3
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=3 pat_val=0 cache=3
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=2 pat_val=0 cache=3
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=1 pat_val=0 cache=3
>> pat_init_cache_modes ok
>> pat_init_cache_modes i=0 pat_val=0 cache=3
>> (XEN) traps.c:459:d0v0 Unhandled invalid opcode fault/trap [#6] on
>> VCPU 0 [ec=]
>> (XEN) domain_crash_sync called from entry.S: fault at 82d0802276c3
>> create_bounce_frame+0x12b/0x13a
>>
>> In both cases, the PAT CPUID feature bit is set, and cpu_has_pat is
>> always 0 at this early point (so my RFC patch is wrong). The simplest
>> fix is to call pat_init_cache_modes(pat) only if pat != 0.
>>
>> This is starting to look like the same logic that's in pat_bsp_init(),
>> which doesn't seem to be called when booting on Xen. Should it be? Was
>> Xen deliberately excluded from this PAT emulation change?
>> https://groups.google.com/d/msg/linux.kernel/JoJKbCOxV0U/PM0I9d1v60kJ
>
> Calling pat_init() requires the CPU rendezvous handler in MTRR, which is
> disabled in Xen.  This PAT initialization has been problematic, and the
> following patches addressed it in 4.6.  This will fix your problem as
> well.
> https://lkml.org/lkml/2016/3/23/500
>
> In particular, patch 6/7 removed the Xen code in question.
> https://lkml.org/lkml/2016/3/23/503
>
> Do you need to fix this issue in 4.4?  If so, we should be able to request
> backporting the patches to 4.4 stable.
>
> -Toshi
>
>
>>
>> --Ed
>>
>>
>> On Mon, May 23, 2016 at 1:13 PM, Boris Ostrovsky
>>  wrote:
>> >
>> > On 05/23/2016 10:15 AM, Konrad Rzeszutek Wilk wrote:
>> > >
>> > > On Fri, May 20, 2016 at 04:58:09PM -0700, Ed Swierk wrote:
>> > > >
>> > > > (XEN) traps.c:459:d0v0 Unhandled invalid opcode fault/trap [#6] on
>> > > > VCPU 0 [ec=]
>> > > > (XEN) domain_crash_sync called from entry.S: fault at
>> > > > 82d0802286c3 create_bounce_frame+0x12b/0x13a
>> > > > (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
>> > > > (XEN) [ Xen-4.5.4-pre  x86_64  debug=n  Not tainted ]
>> > > > (XEN) CPU:0
>> > > > (XEN) RIP:e033:[]
>> > > > (XEN) RFLAGS: 0206   EM: 1   CONTEXT: pv guest (d0v0)
>> > > > (XEN) rax: 0022   rbx:    rcx:
>> > > > 
>> > > > (XEN) rdx: 0022   rsi: 0003   rdi:
>> > > > 
>> > > > (XEN) rbp: 81b67ea8   rsp:
>> > > > 81b67e68   r8:  0001
>> > > > (XEN) r9:  0001   r10: 81b67f20   r11:
>> > > > 6c61765f74617020
>> > > > (XEN) r12:    r13: 0003   r14:
>> > > > 
>> > > > (XEN) r15: 81b67ebb   cr0: 8005003b   cr4:
>> > > > 001526b0
>> > > > (XEN) cr3: 0001b16eb000   cr2: 
>> > > > (XEN) ds:    es:    fs:    gs:    ss: e02b   cs:
>> > > > e033
>> > > > (XEN) Guest stack trace from rsp=81b67e68:
>> > > > (XEN) 6c61765f74617020 81053cbd
>> > > > 0001e030
>> > > > (XEN)00010006 

Re: [Xen-devel] [PATCH v2] tools: bump library version numbers

[Wei Liu]

On Tue, May 24, 2016 at 04:15:53PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH v2] tools: bump library version numbers"):
> > The following libraries are checked:
> > 1. libxc, version number bumped
> > 2. libxl, version number bumped
> > 3. libxlu, no development in 4.7 cycle, but depends on libxl, version
> >number bumped
> > 4. libs/*, new in 4.7 cycle, version numbers not bumped
> > 5. libxenstore, no development in 4.7 cycle, version number not bumped
> 
> This last point surprised me, so I double-checked it.  You are right!
> 
> > 6. libxenstat, no development in 4.7 cycle, version number not bumped
> > 7. libvchan, depends on  xengnttab library, API changed, version number
> >bumped
> > 
> > Signed-off-by: Wei Liu 
> 
> Acked-by: Ian Jackson 
> 

Thanks. I will push this soon.

Wei.

> Thanks,
> Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Question about the best practice to install two versions of Xen toolstack on the same machine

[Dario Faggioli]

[trimmed To/Cc]

On Fri, 2016-05-20 at 13:56 -0400, Meng Xu wrote:
> On Fri, May 20, 2016 at 6:20 AM, Jan Beulich 
> wrote:
> > Or, as an alternative to Olaf's reply, don't install the tools at
> > all, but
> > instead run everything right out of the build trees. That requires
> > some
> > script wrappers to get things like the library search path set up
> > correctly, but with that in place it has been working fine for me
> > for
> > years.
> > 
> Thank you so much for your suggestions!  I tried to add the library
> and bins in xen/dist/install into the PATH and LD_LIBRARY_PATH, but
> failed to have the system work properly.
> 
> I'm wondering if it's convenient for you, would you mind sharing your
> script wrapper? I can learn from it and customize it for my machine.
> 
> Once I have it set up successfully, I can write a xen wiki to
> describe
> how to do it.
> 
Hey Meng,

Now that you've got a couple of alternatives, feel free to go and write
the wiki page! :-P

Thanks and Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] tools: bump library version numbers

[Ian Jackson]

Wei Liu writes ("[PATCH v2] tools: bump library version numbers"):
> The following libraries are checked:
> 1. libxc, version number bumped
> 2. libxl, version number bumped
> 3. libxlu, no development in 4.7 cycle, but depends on libxl, version
>number bumped
> 4. libs/*, new in 4.7 cycle, version numbers not bumped
> 5. libxenstore, no development in 4.7 cycle, version number not bumped

This last point surprised me, so I double-checked it.  You are right!

> 6. libxenstat, no development in 4.7 cycle, version number not bumped
> 7. libvchan, depends on  xengnttab library, API changed, version number
>bumped
> 
> Signed-off-by: Wei Liu 

Acked-by: Ian Jackson 

Thanks,
Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] xen: RTDS: fix another instance of the 'read NOW()' race

[Dario Faggioli]

which was overlooked in 779511f4bf5ae ("sched: avoid
races on time values read from NOW()").

Reported-by: Jan Beulich 
Signed-off-by: Dario Faggioli 
---
Cc: Meng Xu 
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Wei Liu 
---
 xen/common/sched_rt.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 0946101..5b077d7 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -840,12 +840,14 @@ static void
 rt_vcpu_insert(const struct scheduler *ops, struct vcpu *vc)
 {
 struct rt_vcpu *svc = rt_vcpu(vc);
-s_time_t now = NOW();
+s_time_t now;
 spinlock_t *lock;
 
 BUG_ON( is_idle_vcpu(vc) );
 
 lock = vcpu_schedule_lock_irq(vc);
+
+now = NOW();
 if ( now >= svc->cur_deadline )
 rt_update_deadline(now, svc);
 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [GIT PULL] xen: bug fixes for 4.7-rc0

[David Vrabel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.7-rc0-tag

xen: bug fixes for 4.7-rc0

Thanks.

David

 arch/x86/pci/xen.c   |  7 +++--
 arch/x86/xen/setup.c | 65 
 arch/x86/xen/time.c  |  6 ++--
 drivers/xen/Makefile |  1 +
 drivers/xen/events/events_base.c |  6 ++--
 drivers/xen/gntdev.c |  2 +-
 6 files changed, 40 insertions(+), 47 deletions(-)

Arnd Bergmann (1):
  Xen: don't warn about 2-byte wchar_t in efi

David Vrabel (1):
  xen/gntdev: reduce copy batch size to 16

Juergen Gross (1):
  xen: use same main loop for counting and remapping pages

Ross Lagerwall (1):
  xen/events: Don't move disabled irqs

Stefano Stabellini (2):
  xen/x86: don't lose event interrupts
  xen/x86: actually allocate legacy interrupts on PV guests
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXRGuCAAoJEFxbo/MsZsTRqn0H/iDtaJVIWjSwXq8BuJzU2f8d
CYJITZVZ67tkXuQMF3Ol+Mf9Gf8cG1PeSA6RsO1o/cFPAtwmhTW97VYw7dcfSTn5
t5skul1rKkrx9bFLaSO8IeExycIGdAYQUZRVoqRh4dwTXqDJeuPmFcEF515HkmaE
AkdXc0xe1b9pppzc3kqG2kBIk6l/CgIUYZY7NsIlQxLRkHm0BPmtySsypYreXo2W
/53mixS39g80IUIjnK0jRpg4o3T8FY+HKqQFP64kIDq6r0IfRXDbx/DY2OeUsTeW
LTUH5/6d3y+oPN2WoOyZLAeYCzr7saheLAYouqpIs4o8yMV0s9IYEk7jTiTZIlc=
=kFQS
-END PGP SIGNATURE-

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/3] VMX: Properly handle pi descriptor and per-cpu blocking list

[Dario Faggioli]

On Tue, 2016-05-24 at 13:33 +, Wu, Feng wrote:
> > From: Wu, Feng
> > > From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> > > 
> > > If a
> > > vCPU is blocker, there is nothing to do, and in fact, nothing
> > > happens
> > > (as vcpu_sleep_nosync() and vcpu_wake() are NOP in that case).
> > What do you mean by saying ' vcpu_sleep_nosync() and vcpu_wake()
> > are NOP '?
>
> I think I understand what you meant above now.
> 
Right. In any case, see the email I've just sent, with a detailed
breakdown of the situation and of what actually happens.

> Do you think the following idea makes sense?
> 
> When a pCPU is unplugged, we can just remove the vcpus on the
> associated per-cpu blocking list, then we can choose another online
> cpu, set the right NDST value, and put the vCPU the new per-cpu list?
>
Well, this does make sense to me, but the point is how you do that. I
mean, how do you get to execute some PI adjustment code, from cpu-
teardown code?

Right now, for what seemed to be necessary until now, we have the
arch_vcpu_block(). Do we need more? If yes where?

From looking only at schedule.c, we already have arch_move_irqs(), can
we take advantage of it?

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 1/6] build: convert debug to Kconfig

[Jan Beulich]

>>> On 24.05.16 at 15:56,  wrote:
> Enabling debug will disable NDEBUG which will result in more debug
> prints.  There are a number of debugging options for Xen so place the
> debug option under a menu for different debugging options to have a way
> to group them all together.
> 
> Signed-off-by: Doug Goldstein 
> Reviewed-by: Andrew Cooper 
> Reviewed-by: Konrad Rzeszutek Wilk 

Acked-by: Jan Beulich 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] PAT-related crash booting Linux 4.4 + Xen 4.5 on VMware ESXi

[Kani, Toshimitsu]

On Mon, 2016-05-23 at 15:52 -0700, Ed Swierk wrote:
> Good question. I ran my tests again, and found I'd misinterpreted the
> Fusion behavior.
> 
> On Fusion 8.1.1, MSR_IA32_CR_PAT returns a reasonable value:
> 
> (XEN) Freed 308kB init memory.
> mapping kernel into physical memory
> cpu_has_pat=0 cpuid_edx(1)=f89cbf5 pat=65536
> pat_init_cache_modes pat=50100070406
> pat_init_cache_modes i=7 pat_val=0 cache=3
> pat_init_cache_modes ok
> pat_init_cache_modes i=6 pat_val=0 cache=3
> pat_init_cache_modes ok
> pat_init_cache_modes i=5 pat_val=5 cache=5
> pat_init_cache_modes ok
> pat_init_cache_modes i=4 pat_val=1 cache=1
> pat_init_cache_modes ok
> pat_init_cache_modes i=3 pat_val=0 cache=3
> pat_init_cache_modes ok
> pat_init_cache_modes i=2 pat_val=7 cache=2
> pat_init_cache_modes ok
> pat_init_cache_modes i=1 pat_val=4 cache=4
> pat_init_cache_modes ok
> pat_init_cache_modes i=0 pat_val=6 cache=0
> pat_init_cache_modes ok
> pat_init_cache_modes pat_msg=WB  WT  UC- UC  WC  WP  UC  UC
> about to get started...
> [0.00] x86/PAT: Configuration [0-7]: WB  WT  UC-
> UC  WC  WP  UC  UC
> 
> On ESXi 5.5.0, MSR_IA32_CR_PAT returns 0, and we are indeed hitting
> the BUG_ON in update_cache_mode_entry():
> 
> (XEN) Freed 312kB init memory.
> mapping kernel into physical memory
> cpu_has_pat=0 cpuid_edx(1)=f89cbf5 pat=65536
> pat_init_cache_modes pat=0
> pat_init_cache_modes i=7 pat_val=0 cache=3
> pat_init_cache_modes ok
> pat_init_cache_modes i=6 pat_val=0 cache=3
> pat_init_cache_modes ok
> pat_init_cache_modes i=5 pat_val=0 cache=3
> pat_init_cache_modes ok
> pat_init_cache_modes i=4 pat_val=0 cache=3
> pat_init_cache_modes ok
> pat_init_cache_modes i=3 pat_val=0 cache=3
> pat_init_cache_modes ok
> pat_init_cache_modes i=2 pat_val=0 cache=3
> pat_init_cache_modes ok
> pat_init_cache_modes i=1 pat_val=0 cache=3
> pat_init_cache_modes ok
> pat_init_cache_modes i=0 pat_val=0 cache=3
> (XEN) traps.c:459:d0v0 Unhandled invalid opcode fault/trap [#6] on
> VCPU 0 [ec=]
> (XEN) domain_crash_sync called from entry.S: fault at 82d0802276c3
> create_bounce_frame+0x12b/0x13a
> 
> In both cases, the PAT CPUID feature bit is set, and cpu_has_pat is
> always 0 at this early point (so my RFC patch is wrong). The simplest
> fix is to call pat_init_cache_modes(pat) only if pat != 0.
> 
> This is starting to look like the same logic that's in pat_bsp_init(),
> which doesn't seem to be called when booting on Xen. Should it be? Was
> Xen deliberately excluded from this PAT emulation change?
> https://groups.google.com/d/msg/linux.kernel/JoJKbCOxV0U/PM0I9d1v60kJ

Calling pat_init() requires the CPU rendezvous handler in MTRR, which is
disabled in Xen.  This PAT initialization has been problematic, and the
following patches addressed it in 4.6.  This will fix your problem as
well. 
https://lkml.org/lkml/2016/3/23/500

In particular, patch 6/7 removed the Xen code in question.
https://lkml.org/lkml/2016/3/23/503

Do you need to fix this issue in 4.4?  If so, we should be able to request
backporting the patches to 4.4 stable.

-Toshi


> 
> --Ed
> 
> 
> On Mon, May 23, 2016 at 1:13 PM, Boris Ostrovsky
>  wrote:
> > 
> > On 05/23/2016 10:15 AM, Konrad Rzeszutek Wilk wrote:
> > > 
> > > On Fri, May 20, 2016 at 04:58:09PM -0700, Ed Swierk wrote:
> > > > 
> > > > (XEN) traps.c:459:d0v0 Unhandled invalid opcode fault/trap [#6] on
> > > > VCPU 0 [ec=]
> > > > (XEN) domain_crash_sync called from entry.S: fault at
> > > > 82d0802286c3 create_bounce_frame+0x12b/0x13a
> > > > (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> > > > (XEN) [ Xen-4.5.4-pre  x86_64  debug=n  Not tainted ]
> > > > (XEN) CPU:0
> > > > (XEN) RIP:e033:[]
> > > > (XEN) RFLAGS: 0206   EM: 1   CONTEXT: pv guest (d0v0)
> > > > (XEN) rax: 0022   rbx:    rcx:
> > > > 
> > > > (XEN) rdx: 0022   rsi: 0003   rdi:
> > > > 
> > > > (XEN) rbp: 81b67ea8   rsp:
> > > > 81b67e68   r8:  0001
> > > > (XEN) r9:  0001   r10: 81b67f20   r11:
> > > > 6c61765f74617020
> > > > (XEN) r12:    r13: 0003   r14:
> > > > 
> > > > (XEN) r15: 81b67ebb   cr0: 8005003b   cr4:
> > > > 001526b0
> > > > (XEN) cr3: 0001b16eb000   cr2: 
> > > > (XEN) ds:    es:    fs:    gs:    ss: e02b   cs:
> > > > e033
> > > > (XEN) Guest stack trace from rsp=81b67e68:
> > > > (XEN) 6c61765f74617020 81053cbd
> > > > 0001e030
> > > > (XEN)00010006 81b67ea8 e02b
> > > > 81b67f20
> > > > (XEN)81b67f10 8105b339 55ff81b67f10
> > > > 5520204355202043
> > > > (XEN)5520204355202043 5520204355202043 0020204355202043
> > > > 
> > > > (XEN) 81b67f38 
> > > > 

Re: [Xen-devel] [PATCH v2] libxl: Avoid advertising about device_model_user config option

[Wei Liu]

On Tue, May 24, 2016 at 03:45:36PM +0100, Anthony PERARD wrote:
> Running QEMU as non-root user is not ready yet, so replace the warning
> with a debug message and remove the option from the man page.
> 
> Also improve the doc to include more potential issue with running QEMU
> as non-root.
> 
> Signed-off-by: Anthony PERARD 

Acked-by: Wei Liu 
Release-acked-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2] libxl: Avoid advertising about device_model_user config option

[Anthony PERARD]

Running QEMU as non-root user is not ready yet, so replace the warning
with a debug message and remove the option from the man page.

Also improve the doc to include more potential issue with running QEMU
as non-root.

Signed-off-by: Anthony PERARD 
---
Changes in V2:
  - remove option from the man page
  - add a comment in the IDL.
---
 docs/man/xl.cfg.pod.5  | 7 ---
 docs/misc/qemu-deprivilege.txt | 5 +++--
 tools/libxl/libxl_dm.c | 2 +-
 tools/libxl/libxl_types.idl| 1 +
 4 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index a4cc1b3..4a8bf51 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -1949,13 +1949,6 @@ Pass additional arbitrary options on the device-model 
command line for
 an HVM device model only. Each element in the list is passed as an
 option to the device-model.
 
-=item 

Re: [Xen-devel] [for-4.8 1/2] xen/arm: Convert DEBUG_DT to Kconfig

[Julien Grall]

Hi Konrad,

On 24/05/16 14:38, Konrad Rzeszutek Wilk wrote:

On Tue, May 24, 2016 at 11:20:40AM +0100, Julien Grall wrote:

Convert device-tree debugging to 'Kconfig' as
CONFIG_DEBUG_TREE_DEBUG.

The option is not enabled by default because the output is very
verbose.

Signed-off-by: Julien Grall 

---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Doug Goldstein 
---
  xen/Kconfig.debug   | 7 +++
  xen/arch/arm/domain_build.c | 4 +---
  xen/common/device_tree.c| 4 +---
  3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index 303bf36..59be34d 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -55,6 +55,13 @@ config VERBOSE_DEBUG
  Guest output from HYPERVISOR_console_io and hypervisor parsing
  ELF images (dom0) is logged in the Xen ring buffer.

+config DEVICE_TREE_DEBUG
+   bool "Device tree debug messages"
+   depends on HAS_DEVICE_TREE
+   ---help---
+ Device tree parsing and DOM0 device tree building messages is
+ logged in the Xen ring buffer


s/is logged/are logged/

Also missing stop at the end.

Perhaps also add:

"If unsure, say N here."


I will do all the 3 changes in the next version.



Or could this be part of the VERBOSE one (which spews out data about
ELF parsing and allows guests to do  the console_io_write hypercalls?).


The debug messages from the device tree is really verbose (it will 
obscure useful boot messages). So it should only be enabled when Xen 
does not parse correctly the device tree.


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [ovmf test] 94739: all pass - PUSHED

[osstest service owner]

flight 94739 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94739/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 328f84b1565165f35ea7755fb85b09fbf335c2cb
baseline version:
 ovmf 5646819ffb2d9cb87785e9e409f8d928a9f3a04d

Last test of basis94735  2016-05-24 08:49:50 Z0 days
Testing same since94739  2016-05-24 12:13:31 Z0 days1 attempts


People who touched revisions under test:
  Jiewen Yao 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=ovmf
+ revision=328f84b1565165f35ea7755fb85b09fbf335c2cb
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
328f84b1565165f35ea7755fb85b09fbf335c2cb
+ branch=ovmf
+ revision=328f84b1565165f35ea7755fb85b09fbf335c2cb
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' x328f84b1565165f35ea7755fb85b09fbf335c2cb = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 

[Xen-devel] [qemu-upstream-4.3-testing test] 94738: trouble: blocked/broken

[osstest service owner]

flight 94738 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94738/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  108 days
Testing same since93977  2016-05-10 11:09:16 Z   14 days   49 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

Re: [Xen-devel] [for-4.7] Request input on XENMAPSPACE_dev_mmio

[Julien Grall]

Hi Jan,

On 24/05/16 14:57, Jan Beulich wrote:

On 24.05.16 at 15:24,  wrote:

For ARM we would need at least the following attributes:
- normal uncached memory: for write-combine on SRAM or video RAM
- Device_nGnRE: non-gathering and non-reordering
- Device_GRE: gathering and redordering

It might be worth to also consider "normal cache memory".

Xen 4.7 will be release very soon (~ couple of weeks), so we have few
solutions:
  1) Extend XENMAPSPACE_dev_mmio for Xen 4.7
  2) Wait for Xen 4.8 to fix it: this may require to introduce a new
space to be backward compatible.
  3) Revert XENMAPSPACE_dev_mmio for Xen 4.7 and re-introduce it
properly on Xen 4.8: It is only used by ACPI on ARM which is a tech preview.

I would lean toward the solution 1) to avoid delaying ACPI support for
ARM and avoid introducing an sub-hypercall which does not fit for our usage.


Option 2 is clearly worse. I view option 3 as a possibility, but only if
option 1 turns out too intrusive or some such.

However, using the top bits of space doesn't look a very nice way
to address this. How about defining one attribute which would
always get used by XENMEM_add_to_physmap (perhaps the one
that gets used it is right now), and supporting a wider range only
through XENMEM_add_to_physmap_batch? Background being that
the latter has an unused (currently ignored) field, which you could
utilize: foreign_domid. Of course that would then need to be
renamed in a backward compatible way (to something more generic,
e.g. "aux"), and we should try to remember to avoid the same
mistake that was made when that sub-op was added and again
when XENMAPSPACE_dev_mmio got introduced: New operations
should not ignore fields, so they can get a meaning assigned later
on.


That is a good idea. For Xen 4.7, I am suggesting to:
  - Document the behavior of XENMEM_add_to_physmap for ARM. I.e it will 
always use Device_nGnRE (we could use a less weaker one but I am not 
confident enough for a such change before the release).
  - Check the foreign_id is always with XEMEM_add_to_physmap_batch. The 
memory attribute associated will be the same as XENMEM_add_to_physmap.


The number of memory attribute supported will be extend after the 
release for Xen 4.8.



I think the space could be extend in a lightweight version for Xen 4.7
by introducing only one memory attribute and warn on any other value.


Not sure what lightweight version you think of here, or how you
would mean to make a hypercall "warn" - it can only return success
or an error.


Let say we only support one kind of memory attribute for Xen 4.7. When 
we will introduce new one, Linux may use them and therefore the mapping 
will fail.


We can either fix by letting Linux try different memory attribute. Or 
use a default one in Xen.


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [for-4.7] Request input on XENMAPSPACE_dev_mmio

[Wei Liu]

On Tue, May 24, 2016 at 02:24:22PM +0100, Julien Grall wrote:
> Hi all,
> 
> Sorry for noticing this problem late in the release process.
> 
> The mapping space XENMAPSPACE_dev_mmio has been introduced recently (will be
> present in Xen 4.7) to let dom0 map device MMIO regions when ACPI is in-use
> on ARM platform.
> 
> Xen ARM will map those regions in the stage-2 page table using the memory
> attribute Device_nGnRE (i.e non-Gathering, non-Reordering, no-unaligned
> access).
> 
> The final memory attribute is a combination of stage-1 (handled by the
> kernel) and stage-2 attributes. It will always result to a restrictive
> memory attribute (see D4.4.3 in ARM DDI 0487A.i).
> 
> Device_nGnRE is one of the most restrictive memory attribute, whilst it fits
> in lot of case, the performance are not great on device such as graphic
> cards, and it makes impossible to access those regions with unaligned access
> (a lot of Linux drivers uses memcpy which does unaligned access).
> 
> Unfortunately it is not possible to find a weaker memory attribute that
> would fit for everyone. For instance, we would need to map static RAM with
> normal memory attribute to allow speculation and unaligned access.
> 
> However, the same normal memory could not be used for MMIOs having
> side-effect (such as an UART) because the processor would be allowed to
> fetch additional memory locations.
> 
> For more details about the different memory attributes see B2.8 in ARM DDI
> 0487A.i.
> 
> In the case of ACPI, only DOM0 has access to the full description of the
> device and know the memory attribute to use. So we need to expand
> XENMAPSPACE_dev_mmio to provide the memory attribute (this could be done
> using the top bits of 'space').
> 
> For ARM we would need at least the following attributes:
>   - normal uncached memory: for write-combine on SRAM or video RAM
>   - Device_nGnRE: non-gathering and non-reordering
>   - Device_GRE: gathering and redordering
> 
> It might be worth to also consider "normal cache memory".
> 
> Xen 4.7 will be release very soon (~ couple of weeks), so we have few
> solutions:
> 1) Extend XENMAPSPACE_dev_mmio for Xen 4.7
> 2) Wait for Xen 4.8 to fix it: this may require to introduce a new space
> to be backward compatible.
> 3) Revert XENMAPSPACE_dev_mmio for Xen 4.7 and re-introduce it properly
> on Xen 4.8: It is only used by ACPI on ARM which is a tech preview.
> 
> I would lean toward the solution 1) to avoid delaying ACPI support for ARM
> and avoid introducing an sub-hypercall which does not fit for our usage.
> 

My preference is 1>3>2, fwiw.

After looking at the code, my gut feeling is that 1 is not going to be
overly intrusive -- there seems to be only a handful of function in Xen
on ARM to handle MMIO mapping.

> I think the space could be extend in a lightweight version for Xen 4.7 by
> introducing only one memory attribute and warn on any other value.
> 

We should just reject the values that are not supported yet imho.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [for-4.8 2/2] xen/arm: Provide device tree debugging helper in a single place

[Edgar E. Iglesias]

On Tue, May 24, 2016 at 11:20:41AM +0100, Julien Grall wrote:
> Provide helper to debug the device tree in device_tree.h. This will
> avoid to have to redeclare helper for each file requiring debug.
> 
> Also replace DPRINT by the new helper dt_dprintk in domain_build.c

Reviewed-by: Edgar E. Iglesias 


> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/domain_build.c   | 71 
> +--
>  xen/common/device_tree.c  |  2 --
>  xen/include/xen/device_tree.h |  9 ++
>  3 files changed, 43 insertions(+), 39 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index fb035ff..71ead8b 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -42,12 +42,6 @@ static void __init parse_dom0_mem(const char *s)
>  }
>  custom_param("dom0_mem", parse_dom0_mem);
>  
> -#ifdef CONFIG_DEVICE_TREE_DEBUG
> -# define DPRINT(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
> -#else
> -# define DPRINT(fmt, args...) do {} while ( 0 )
> -#endif
> -
>  //#define DEBUG_11_ALLOCATION
>  #ifdef DEBUG_11_ALLOCATION
>  # define D11PRINT(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
> @@ -364,7 +358,7 @@ static void allocate_memory(struct domain *d, struct 
> kernel_info *kinfo)
>  {
>  int l;
>  
> -DPRINT("memory node\n");
> +dt_dprintk("memory node\n");
>  
>  reg_size = dt_cells_to_size(dt_n_addr_cells(memory) + 
> dt_n_size_cells(memory));
>  
> @@ -571,7 +565,8 @@ static int make_memory_node(const struct domain *d,
>  __be32 reg[nr_cells];
>  __be32 *cells;
>  
> -DPRINT("Create memory node (reg size %d, nr cells %d)\n", reg_size, 
> nr_cells);
> +dt_dprintk("Create memory node (reg size %d, nr cells %d)\n",
> +   reg_size, nr_cells);
>  
>  /* ePAPR 3.4 */
>  res = fdt_begin_node(fdt, "memory");
> @@ -588,8 +583,8 @@ static int make_memory_node(const struct domain *d,
>  u64 start = kinfo->mem.bank[i].start;
>  u64 size = kinfo->mem.bank[i].size;
>  
> -DPRINT("  Bank %d: %#"PRIx64"->%#"PRIx64"\n",
> -i, start, start + size);
> +dt_dprintk("  Bank %d: %#"PRIx64"->%#"PRIx64"\n",
> +   i, start, start + size);
>  
>  dt_child_set_range(, parent, start, size);
>  }
> @@ -618,7 +613,7 @@ static int make_hypervisor_node(const struct kernel_info 
> *kinfo,
>  int sizecells = dt_child_n_size_cells(parent);
>  void *fdt = kinfo->fdt;
>  
> -DPRINT("Create hypervisor node\n");
> +dt_dprintk("Create hypervisor node\n");
>  
>  /*
>   * Sanity-check address sizes, since addresses and sizes which do
> @@ -667,7 +662,7 @@ static int make_psci_node(void *fdt, const struct 
> dt_device_node *parent)
>  "arm,psci-0.2""\0"
>  "arm,psci";
>  
> -DPRINT("Create PSCI node\n");
> +dt_dprintk("Create PSCI node\n");
>  
>  /* See linux Documentation/devicetree/bindings/arm/psci.txt */
>  res = fdt_begin_node(fdt, "psci");
> @@ -710,7 +705,7 @@ static int make_cpus_node(const struct domain *d, void 
> *fdt,
>  bool_t clock_valid;
>  uint64_t mpidr_aff;
>  
> -DPRINT("Create cpus node\n");
> +dt_dprintk("Create cpus node\n");
>  
>  if ( !cpus )
>  {
> @@ -765,7 +760,8 @@ static int make_cpus_node(const struct domain *d, void 
> *fdt,
>   * is enough for the current max vcpu number.
>   */
>  mpidr_aff = vcpuid_to_vaffinity(cpu);
> -DPRINT("Create cpu@%"PRIx64" (logical CPUID: %d) node\n", mpidr_aff, 
> cpu);
> +dt_dprintk("Create cpu@%"PRIx64" (logical CPUID: %d) node\n",
> +   mpidr_aff, cpu);
>  
>  snprintf(buf, sizeof(buf), "cpu@%"PRIx64, mpidr_aff);
>  res = fdt_begin_node(fdt, buf);
> @@ -821,11 +817,11 @@ static int make_gic_node(const struct domain *d, void 
> *fdt,
>   */
>  if ( node != dt_interrupt_controller )
>  {
> -DPRINT("  Skipping (secondary GIC)\n");
> +dt_dprintk("  Skipping (secondary GIC)\n");
>  return 0;
>  }
>  
> -DPRINT("Create gic node\n");
> +dt_dprintk("Create gic node\n");
>  
>  res = fdt_begin_node(fdt, "interrupt-controller");
>  if ( res )
> @@ -837,7 +833,7 @@ static int make_gic_node(const struct domain *d, void 
> *fdt,
>   */
>  if ( gic->phandle )
>  {
> -DPRINT("  Set phandle = 0x%x\n", gic->phandle);
> +dt_dprintk("  Set phandle = 0x%x\n", gic->phandle);
>  res = fdt_property_cell(fdt, "phandle", gic->phandle);
>  if ( res )
>  return res;
> @@ -894,7 +890,7 @@ static int make_timer_node(const struct domain *d, void 
> *fdt,
>  u32 clock_frequency;
>  bool_t clock_valid;
>  
> -DPRINT("Create timer node\n");
> +dt_dprintk("Create timer node\n");
>  
>  dev = dt_find_matching_node(NULL, timer_ids);
>  if ( !dev )
> @@ -922,15 

Re: [Xen-devel] [for-4.8 1/2] xen/arm: Convert DEBUG_DT to Kconfig

[Edgar E. Iglesias]

On Tue, May 24, 2016 at 11:20:40AM +0100, Julien Grall wrote:
> Convert device-tree debugging to 'Kconfig' as
> CONFIG_DEBUG_TREE_DEBUG.
 ^

Hi Julien,

You've got a typo in the commit message, other than that:
Reviewed-by: Edgar E. Iglesias 

Cheers,
Edgar


> 
> The option is not enabled by default because the output is very
> verbose.
> 
> Signed-off-by: Julien Grall 
> 
> ---
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> Cc: Doug Goldstein 
> ---
>  xen/Kconfig.debug   | 7 +++
>  xen/arch/arm/domain_build.c | 4 +---
>  xen/common/device_tree.c| 4 +---
>  3 files changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
> index 303bf36..59be34d 100644
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -55,6 +55,13 @@ config VERBOSE_DEBUG
> Guest output from HYPERVISOR_console_io and hypervisor parsing
> ELF images (dom0) is logged in the Xen ring buffer.
>  
> +config DEVICE_TREE_DEBUG
> + bool "Device tree debug messages"
> + depends on HAS_DEVICE_TREE
> + ---help---
> +   Device tree parsing and DOM0 device tree building messages is
> +   logged in the Xen ring buffer
> +
>  endif # DEBUG || EXPERT
>  
>  endmenu
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 00dc07a..fb035ff 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -42,9 +42,7 @@ static void __init parse_dom0_mem(const char *s)
>  }
>  custom_param("dom0_mem", parse_dom0_mem);
>  
> -//#define DEBUG_DT
> -
> -#ifdef DEBUG_DT
> +#ifdef CONFIG_DEVICE_TREE_DEBUG
>  # define DPRINT(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
>  #else
>  # define DPRINT(fmt, args...) do {} while ( 0 )
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index 06a2837..0df2e4b 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -54,9 +54,7 @@ struct dt_alias_prop {
>  
>  static LIST_HEAD(aliases_lookup);
>  
> -// #define DEBUG_DT
> -
> -#ifdef DEBUG_DT
> +#ifdef CONFIG_DEVICE_TREE_DEBUG
>  # define dt_dprintk(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
>  static void dt_dump_addr(const char *s, const __be32 *addr, int na)
>  {
> -- 
> 1.9.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC for-4.8 4/6] xen/arm: Add helper functions to map RWX memory regions

[Edgar E. Iglesias]

On Mon, May 23, 2016 at 04:36:03PM +0100, Julien Grall wrote:
> Hi Edgar,
> 
> On 20/05/16 16:51, Edgar E. Iglesias wrote:
> >From: "Edgar E. Iglesias" 
> >
> >Create a helper function to map regions as MEMORY with
> >cached attributes and read-write-execute permissions.
> 
> Providing setting the execute bit is useful, I would try to rationalize the
> helpers by expanding map_regions_rw_cache (and maybe rename it).

Thanks, I'll have change the code around to do that.

> 
> >Signed-off-by: Edgar E. Iglesias 
> >---
> >  xen/arch/arm/p2m.c| 26 ++
> >  xen/include/asm-arm/p2m.h | 10 ++
> >  2 files changed, 36 insertions(+)
> >
> >diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> >index db21433..7e788f9 100644
> >--- a/xen/arch/arm/p2m.c
> >+++ b/xen/arch/arm/p2m.c
> >@@ -1219,6 +1219,32 @@ int p2m_populate_ram(struct domain *d,
> >   d->arch.p2m.default_access);
> >  }
> >
> >+int map_regions_rwx_cache(struct domain *d,
> >+ unsigned long start_gfn,
> >+ unsigned long nr,
> >+ unsigned long mfn)
> >+{
> >+return apply_p2m_changes(d, INSERT,
> >+ pfn_to_paddr(start_gfn),
> >+ pfn_to_paddr(start_gfn + nr),
> >+ pfn_to_paddr(mfn),
> >+ MATTR_MEM, 0, p2m_ram_rw,
> 
> We should not use p2m_ram_rw for other mapping than DRAM. It could be used
> by Xen to differentiate MMIO vs RAM.


OK, I see. I'll fix that.

Cheers,
Edgar

> 
> >+ p2m_access_rwx);
> >+}
> >+
> >+int unmap_regions_rwx_cache(struct domain *d,
> >+   unsigned long start_gfn,
> >+   unsigned long nr,
> >+   unsigned long mfn)
> >+{
> >+return apply_p2m_changes(d, REMOVE,
> >+ pfn_to_paddr(start_gfn),
> >+ pfn_to_paddr(start_gfn + nr),
> >+ pfn_to_paddr(mfn),
> >+ MATTR_MEM, 0, p2m_invalid,
> >+ p2m_access_rwx);
> >+}
> >+
> >  int map_regions_rw_cache(struct domain *d,
> >   unsigned long start_gfn,
> >   unsigned long nr,
> >diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> >index d240d1e..294050e 100644
> >--- a/xen/include/asm-arm/p2m.h
> >+++ b/xen/include/asm-arm/p2m.h
> >@@ -144,6 +144,16 @@ int p2m_cache_flush(struct domain *d, xen_pfn_t 
> >start_mfn, xen_pfn_t end_mfn);
> >  /* Setup p2m RAM mapping for domain d from start-end. */
> >  int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
> >
> >+int map_regions_rwx_cache(struct domain *d,
> >+  unsigned long start_gfn,
> >+  unsigned long nr_mfns,
> >+  unsigned long mfn);
> >+
> >+int unmap_regions_rwx_cache(struct domain *d,
> >+unsigned long start_gfn,
> >+unsigned long nr_mfns,
> >+unsigned long mfn);
> >+
> >  int map_regions_rw_cache(struct domain *d,
> >   unsigned long start_gfn,
> >   unsigned long nr_mfns,
> >
> 
> Regards,
> 
> -- 
> Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v5 6/6] build: convert lock_profile to Kconfig

[Doug Goldstein]

Convert the 'lock_profile' option to Kconfig as CONFIG_LOCK_PROFILE.

Signed-off-by: Doug Goldstein 
Reviewed-by: Andrew Cooper 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Jan Beulich 
---
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Jan Beulich 
CC: Andrew Cooper 
---
 INSTALL|  1 -
 xen/Kconfig.debug  |  7 +++
 xen/Rules.mk   |  5 +++--
 xen/arch/arm/xen.lds.S |  2 +-
 xen/arch/x86/domain.c  |  2 +-
 xen/arch/x86/xen.lds.S |  2 +-
 xen/common/keyhandler.c|  2 +-
 xen/common/spinlock.c  | 10 +-
 xen/common/sysctl.c|  2 +-
 xen/include/xen/spinlock.h |  4 ++--
 10 files changed, 22 insertions(+), 15 deletions(-)

diff --git a/INSTALL b/INSTALL
index 623887d..616a67a 100644
--- a/INSTALL
+++ b/INSTALL
@@ -227,7 +227,6 @@ VGABIOS_REL_DATE="dd Mon "
 
 The following variables can be used to tweak some aspects of the
 hypervisor build.
-lock_profile=y
 lto=y
 
 During tools build external repos will be cloned into the source tree.
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index 56d2c79..abef0ad 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -28,6 +28,13 @@ config FRAME_POINTER
  maybe slower, but it gives very useful debugging information
  in case of any Xen bugs.
 
+config LOCK_PROFILE
+   bool "Lock Profiling"
+   ---help---
+ Lock profiling allows you to see how often locks are taken and 
blocked.
+ You can use serial console to print (and reset) using 'l' and 'L'
+ respectively, or the 'xenlockprof' tool.
+
 config PERF_COUNTERS
bool "Performance Counters"
---help---
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 209c91a..dded8b6 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -3,7 +3,6 @@
 # If you change any of these configuration options then you must
 # 'make clean' before rebuilding.
 #
-lock_profile  ?= n
 lto   ?= n
 
 -include $(BASEDIR)/include/config/auto.conf
@@ -23,6 +22,9 @@ endif
 ifneq ($(origin kexec),undefined)
 $(error "You must use 'make menuconfig' to enable/disable kexec now.")
 endif
+ifneq ($(origin lock_profile),undefined)
+$(error "You must use 'make menuconfig' to enable/disable lock_profile now.")
+endif
 ifneq ($(origin perfc),undefined)
 $(error "You must use 'make menuconfig' to enable/disable perfc now.")
 endif
@@ -56,7 +58,6 @@ ifneq ($(clang),y)
 CFLAGS += -Wa,--strip-local-absolute
 endif
 
-CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(CONFIG_FRAME_POINTER) += -fno-omit-frame-pointer
 
 ifneq ($(max_phys_irqs),)
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 1f010bd..76982b2 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -54,7 +54,7 @@ SECTIONS
*(.rodata)
*(.rodata.*)
 
-#ifdef LOCK_PROFILE
+#ifdef CONFIG_LOCK_PROFILE
. = ALIGN(POINTER_ALIGN);
__lock_profile_start = .;
*(.lockprofile.data)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 5af2cc5..978ec3a 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -251,7 +251,7 @@ struct domain *alloc_domain_struct(void)
 #endif
 
 
-#ifndef LOCK_PROFILE
+#ifndef CONFIG_LOCK_PROFILE
 BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
 #endif
 d = alloc_xenheap_pages(order, MEMF_bits(bits));
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index b14bcd2..a43b29d 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -103,7 +103,7 @@ SECTIONS
*(.ex_table.pre)
__stop___pre_ex_table = .;
 
-#ifdef LOCK_PROFILE
+#ifdef CONFIG_LOCK_PROFILE
. = ALIGN(POINTER_ALIGN);
__lock_profile_start = .;
*(.lockprofile.data)
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 65b70ce..16de6e8 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -64,7 +64,7 @@ static struct keyhandler {
 KEYHANDLER('P', perfc_reset, "reset performance counters", 0),
 #endif
 
-#ifdef LOCK_PROFILE
+#ifdef CONFIG_LOCK_PROFILE
 KEYHANDLER('l', spinlock_profile_printall, "print lock profile info", 1),
 KEYHANDLER('L', spinlock_profile_reset, "reset lock profile info", 0),
 #endif
diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index b377bb9..017bdf3 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -85,7 +85,7 @@ void spin_debug_disable(void)
 
 #endif
 
-#ifdef LOCK_PROFILE
+#ifdef CONFIG_LOCK_PROFILE
 
 #define LOCK_PROFILE_REL \
 if (lock->profile)   \
@@ -212,7 +212,7 @@ int _spin_trylock(spinlock_t *lock)
 if ( cmpxchg(>tickets.head_tail,
  old.head_tail, new.head_tail) != old.head_tail )
 return 0;
-#ifdef LOCK_PROFILE
+#ifdef 

[Xen-devel] [PATCH v5 3/6] build: convert verbose to Kconfig

[Doug Goldstein]

Convert 'verbose', which was enabled by 'debug=y' to Kconfig as
CONFIG_VERBOSE_DEBUG which is enabled by default when CONFIG_DEBUG is
enabled.

Signed-off-by: Doug Goldstein 
Reviewed-by: Andrew Cooper 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Jan Beulich 
---
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Daniel De Graaf 
---
 INSTALL | 1 -
 xen/Kconfig.debug   | 7 +++
 xen/Rules.mk| 6 +++---
 xen/arch/arm/kernel.c   | 2 +-
 xen/arch/x86/domain_build.c | 2 +-
 xen/include/xsm/dummy.h | 2 +-
 6 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/INSTALL b/INSTALL
index 2974b9b..35668bd 100644
--- a/INSTALL
+++ b/INSTALL
@@ -227,7 +227,6 @@ VGABIOS_REL_DATE="dd Mon "
 
 The following variables can be used to tweak some aspects of the
 hypervisor build.
-verbose=y
 perfc=y
 perfc_arrays=y
 lock_profile=y
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index 8eeb13f..fb11c56 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -20,6 +20,13 @@ config CRASH_DEBUG
  If you want to attach gdb to Xen to debug Xen if it crashes
  then say Y.
 
+config VERBOSE_DEBUG
+   bool "Verbose debug messages"
+   default DEBUG
+   ---help---
+ Guest output from HYPERVISOR_console_io and hypervisor parsing
+ ELF images (dom0) will be logged in the Xen ring buffer.
+
 endif # DEBUG || EXPERT
 
 endmenu
diff --git a/xen/Rules.mk b/xen/Rules.mk
index b077e25..2a93ef7 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -3,7 +3,6 @@
 # If you change any of these configuration options then you must
 # 'make clean' before rebuilding.
 #
-verbose   ?= n
 perfc ?= n
 perfc_arrays  ?= n
 lock_profile  ?= n
@@ -17,7 +16,6 @@ include $(XEN_ROOT)/Config.mk
 # Hardcoded configuration implications and dependencies.
 # Do this is a neater way if it becomes unwieldy.
 ifeq ($(debug),y)
-verbose   := y
 frame_pointer := y
 endif
 ifeq ($(perfc_arrays),y)
@@ -33,6 +31,9 @@ endif
 ifneq ($(origin kexec),undefined)
 $(error "You must use 'make menuconfig' to enable/disable kexec now.")
 endif
+ifneq ($(origin verbose),undefined)
+$(error "You must use 'make menuconfig' to enable/disable verbose now.")
+endif
 
 # Set ARCH/SUBARCH appropriately.
 override TARGET_SUBARCH  := $(XEN_TARGET_ARCH)
@@ -60,7 +61,6 @@ ifneq ($(clang),y)
 CFLAGS += -Wa,--strip-local-absolute
 endif
 
-CFLAGS-$(verbose)   += -DVERBOSE
 CFLAGS-$(perfc) += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 9871bd9..3f6cce3 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -472,7 +472,7 @@ static int kernel_elf_probe(struct kernel_info *info,
 
 if ( (rc = elf_init(>elf.elf, info->elf.kernel_img, size )) != 0 )
 goto err;
-#ifdef VERBOSE
+#ifdef CONFIG_VERBOSE_DEBUG
 elf_set_verbose(>elf.elf);
 #endif
 elf_parse_binary(>elf.elf);
diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index f9a3eca..b29c377 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -942,7 +942,7 @@ int __init construct_dom0(
 
 if ( (rc = elf_init(, image_start, image_len)) != 0 )
 return rc;
-#ifdef VERBOSE
+#ifdef CONFIG_VERBOSE_DEBUG
 elf_set_verbose();
 #endif
 elf_parse_binary();
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index abbe282..406cd18 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -215,7 +215,7 @@ static XSM_INLINE int 
xsm_memory_stat_reservation(XSM_DEFAULT_ARG struct domain
 static XSM_INLINE int xsm_console_io(XSM_DEFAULT_ARG struct domain *d, int cmd)
 {
 XSM_ASSERT_ACTION(XSM_OTHER);
-#ifdef VERBOSE
+#ifdef CONFIG_VERBOSE_DEBUG
 if ( cmd == CONSOLEIO_write )
 return xsm_default_action(XSM_HOOK, d, NULL);
 #endif
-- 
2.7.3


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v5 5/6] build: convert perfc{, _arrays} to Kconfig

[Doug Goldstein]

Convert the 'perfc' and 'perfc_arrays' options to Kconfig as
CONFIG_PERF_COUNTERS and CONFIG_PERF_ARRAYS.

Signed-off-by: Doug Goldstein 
Reviewed-by: Andrew Cooper 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Jan Beulich 
---
CC: Andrew Cooper 
CC: George Dunlap 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
CC: Wei Liu 
---
 INSTALL   |  2 --
 xen/Kconfig.debug | 15 +++
 xen/Rules.mk  | 12 +++-
 xen/arch/x86/hvm/hvm.c|  2 +-
 xen/arch/x86/time.c   |  4 ++--
 xen/arch/x86/x86_64/asm-offsets.c |  2 +-
 xen/common/Makefile   |  2 +-
 xen/common/keyhandler.c   |  2 +-
 xen/common/perfc.c|  2 +-
 xen/common/sysctl.c   |  2 +-
 xen/include/asm-x86/asm_defns.h   |  2 +-
 xen/include/asm-x86/domain.h  |  2 +-
 xen/include/xen/perfc.h   |  8 
 xen/include/xen/sched.h   |  2 +-
 14 files changed, 33 insertions(+), 26 deletions(-)

diff --git a/INSTALL b/INSTALL
index f55d42c..623887d 100644
--- a/INSTALL
+++ b/INSTALL
@@ -227,8 +227,6 @@ VGABIOS_REL_DATE="dd Mon "
 
 The following variables can be used to tweak some aspects of the
 hypervisor build.
-perfc=y
-perfc_arrays=y
 lock_profile=y
 lto=y
 
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index 664a67b..56d2c79 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -28,6 +28,21 @@ config FRAME_POINTER
  maybe slower, but it gives very useful debugging information
  in case of any Xen bugs.
 
+config PERF_COUNTERS
+   bool "Performance Counters"
+   ---help---
+ Enables software performance counters that allows you to analyze
+ bottlenecks in the system.  To access this data you can use serial
+ console to print (and reset) using 'p' and 'P' respectively, or
+ the 'xenperf' tool.
+
+config PERF_ARRAYS
+   bool "Performance Counter Array Histograms"
+   depends on PERF_COUNTERS
+   ---help---
+ Enables software performance counter array histograms.
+
+
 config VERBOSE_DEBUG
bool "Verbose debug messages"
default DEBUG
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 418fc74..209c91a 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -3,8 +3,6 @@
 # If you change any of these configuration options then you must
 # 'make clean' before rebuilding.
 #
-perfc ?= n
-perfc_arrays  ?= n
 lock_profile  ?= n
 lto   ?= n
 
@@ -12,11 +10,6 @@ lto   ?= n
 
 include $(XEN_ROOT)/Config.mk
 
-# Hardcoded configuration implications and dependencies.
-# Do this is a neater way if it becomes unwieldy.
-ifeq ($(perfc_arrays),y)
-perfc := y
-endif
 
 ifneq ($(origin crash_debug),undefined)
 $(error "You must use 'make menuconfig' to enable/disable crash_debug now.")
@@ -30,6 +23,9 @@ endif
 ifneq ($(origin kexec),undefined)
 $(error "You must use 'make menuconfig' to enable/disable kexec now.")
 endif
+ifneq ($(origin perfc),undefined)
+$(error "You must use 'make menuconfig' to enable/disable perfc now.")
+endif
 ifneq ($(origin verbose),undefined)
 $(error "You must use 'make menuconfig' to enable/disable verbose now.")
 endif
@@ -60,8 +56,6 @@ ifneq ($(clang),y)
 CFLAGS += -Wa,--strip-local-absolute
 endif
 
-CFLAGS-$(perfc) += -DPERF_COUNTERS
-CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(CONFIG_FRAME_POINTER) += -fno-omit-frame-pointer
 
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 5040a5c..a4c20cd 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3536,7 +3536,7 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
unsigned int *ebx,
 static uint64_t _hvm_rdtsc_intercept(void)
 {
 struct vcpu *curr = current;
-#if !defined(NDEBUG) || defined(PERF_COUNTERS)
+#if !defined(NDEBUG) || defined(CONFIG_PERF_COUNTERS)
 struct domain *currd = curr->domain;
 
 if ( currd->arch.vtsc )
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 6438b47..3928a5f 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1688,7 +1688,7 @@ void pv_soft_rdtsc(struct vcpu *v, struct cpu_user_regs 
*regs, int rdtscp)
 
 spin_lock(>arch.vtsc_lock);
 
-#if !defined(NDEBUG) || defined(PERF_COUNTERS)
+#if !defined(NDEBUG) || defined(CONFIG_PERF_COUNTERS)
 if ( guest_kernel_mode(v, regs) )
 d->arch.vtsc_kerncount++;
 else
@@ -1959,7 +1959,7 @@ static void dump_softtsc(unsigned char key)
 printk(",khz=%"PRIu32, d->arch.tsc_khz);
 if ( d->arch.incarnation )
 printk(",inc=%"PRIu32, d->arch.incarnation);
-#if 

Re: [Xen-devel] [for-4.7] Request input on XENMAPSPACE_dev_mmio

[Jan Beulich]

>>> On 24.05.16 at 15:24,  wrote:
> For ARM we would need at least the following attributes:
>- normal uncached memory: for write-combine on SRAM or video RAM
>- Device_nGnRE: non-gathering and non-reordering
>- Device_GRE: gathering and redordering
> 
> It might be worth to also consider "normal cache memory".
> 
> Xen 4.7 will be release very soon (~ couple of weeks), so we have few 
> solutions:
>  1) Extend XENMAPSPACE_dev_mmio for Xen 4.7
>  2) Wait for Xen 4.8 to fix it: this may require to introduce a new 
> space to be backward compatible.
>  3) Revert XENMAPSPACE_dev_mmio for Xen 4.7 and re-introduce it 
> properly on Xen 4.8: It is only used by ACPI on ARM which is a tech preview.
> 
> I would lean toward the solution 1) to avoid delaying ACPI support for 
> ARM and avoid introducing an sub-hypercall which does not fit for our usage.

Option 2 is clearly worse. I view option 3 as a possibility, but only if
option 1 turns out too intrusive or some such.

However, using the top bits of space doesn't look a very nice way
to address this. How about defining one attribute which would
always get used by XENMEM_add_to_physmap (perhaps the one
that gets used it is right now), and supporting a wider range only
through XENMEM_add_to_physmap_batch? Background being that
the latter has an unused (currently ignored) field, which you could
utilize: foreign_domid. Of course that would then need to be
renamed in a backward compatible way (to something more generic,
e.g. "aux"), and we should try to remember to avoid the same
mistake that was made when that sub-op was added and again
when XENMAPSPACE_dev_mmio got introduced: New operations
should not ignore fields, so they can get a meaning assigned later
on.

> I think the space could be extend in a lightweight version for Xen 4.7 
> by introducing only one memory attribute and warn on any other value.

Not sure what lightweight version you think of here, or how you
would mean to make a hypercall "warn" - it can only return success
or an error.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v5 4/6] build: convert frame_pointer to Kconfig

[Doug Goldstein]

Converts the frame_pointer option to a Kconfig option.

Signed-off-by: Doug Goldstein 
Reviewed-by: Andrew Cooper 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Jan Beulich 
---
CC: Andrew Cooper 
CC: George Dunlap 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
CC: Wei Liu 
---
 INSTALL   | 1 -
 xen/Kconfig.debug | 8 
 xen/Rules.mk  | 9 -
 3 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/INSTALL b/INSTALL
index 35668bd..f55d42c 100644
--- a/INSTALL
+++ b/INSTALL
@@ -230,7 +230,6 @@ hypervisor build.
 perfc=y
 perfc_arrays=y
 lock_profile=y
-frame_pointer=y
 lto=y
 
 During tools build external repos will be cloned into the source tree.
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index fb11c56..664a67b 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -20,6 +20,14 @@ config CRASH_DEBUG
  If you want to attach gdb to Xen to debug Xen if it crashes
  then say Y.
 
+config FRAME_POINTER
+   bool "Compile Xen with frame pointers"
+   default DEBUG
+   ---help---
+ If you say Y here the resulting Xen will be slightly larger and
+ maybe slower, but it gives very useful debugging information
+ in case of any Xen bugs.
+
 config VERBOSE_DEBUG
bool "Verbose debug messages"
default DEBUG
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 2a93ef7..418fc74 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -6,7 +6,6 @@
 perfc ?= n
 perfc_arrays  ?= n
 lock_profile  ?= n
-frame_pointer ?= n
 lto   ?= n
 
 -include $(BASEDIR)/include/config/auto.conf
@@ -15,9 +14,6 @@ include $(XEN_ROOT)/Config.mk
 
 # Hardcoded configuration implications and dependencies.
 # Do this is a neater way if it becomes unwieldy.
-ifeq ($(debug),y)
-frame_pointer := y
-endif
 ifeq ($(perfc_arrays),y)
 perfc := y
 endif
@@ -28,6 +24,9 @@ endif
 ifeq ($(origin debug),command line)
 $(warning "You must use 'make menuconfig' to enable/disable debug now.")
 endif
+ifneq ($(origin frame_pointer),undefined)
+$(error "You must use 'make menuconfig' to enable/disable frame_pointer now.")
+endif
 ifneq ($(origin kexec),undefined)
 $(error "You must use 'make menuconfig' to enable/disable kexec now.")
 endif
@@ -64,7 +63,7 @@ endif
 CFLAGS-$(perfc) += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
-CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
+CFLAGS-$(CONFIG_FRAME_POINTER) += -fno-omit-frame-pointer
 
 ifneq ($(max_phys_irqs),)
 CFLAGS-y+= -DMAX_PHYS_IRQS=$(max_phys_irqs)
-- 
2.7.3


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v5 1/6] build: convert debug to Kconfig

[Doug Goldstein]

Enabling debug will disable NDEBUG which will result in more debug
prints.  There are a number of debugging options for Xen so place the
debug option under a menu for different debugging options to have a way
to group them all together.

Signed-off-by: Doug Goldstein 
Reviewed-by: Andrew Cooper 
Reviewed-by: Konrad Rzeszutek Wilk 
---
CC: Andrew Cooper 
CC: George Dunlap 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
CC: Wei Liu 
---
 xen/Kconfig  |  2 ++
 xen/Kconfig.debug| 14 ++
 xen/Rules.mk |  5 +++--
 xen/include/xen/config.h |  4 
 4 files changed, 23 insertions(+), 2 deletions(-)
 create mode 100644 xen/Kconfig.debug

diff --git a/xen/Kconfig b/xen/Kconfig
index fa8b27c..0fe7a1a 100644
--- a/xen/Kconfig
+++ b/xen/Kconfig
@@ -26,3 +26,5 @@ config DEFCONFIG_LIST
 config EXPERT
string
option env="XEN_CONFIG_EXPERT"
+
+source "Kconfig.debug"
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
new file mode 100644
index 000..796af0c
--- /dev/null
+++ b/xen/Kconfig.debug
@@ -0,0 +1,14 @@
+
+menu "Debugging Options"
+
+config DEBUG
+   bool "Developer Checks"
+   default y
+   ---help---
+ If you say Y here this will enable developer checks such as asserts
+ and extra printks. This option is intended for development purposes
+ only, and not for production use.
+
+ You probably want to say 'N' here.
+
+endmenu
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 961d533..da2f490 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -20,13 +20,14 @@ include $(XEN_ROOT)/Config.mk
 ifeq ($(debug),y)
 verbose   := y
 frame_pointer := y
-else
-CFLAGS += -DNDEBUG
 endif
 ifeq ($(perfc_arrays),y)
 perfc := y
 endif
 
+ifeq ($(origin debug),command line)
+$(warning "You must use 'make menuconfig' to enable/disable debug now.")
+endif
 ifneq ($(origin kexec),undefined)
 $(error "You must use 'make menuconfig' to enable/disable kexec now.")
 endif
diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h
index ef6e5ee..473c5e8 100644
--- a/xen/include/xen/config.h
+++ b/xen/include/xen/config.h
@@ -81,4 +81,8 @@
 /* allow existing code to work with Kconfig variable */
 #define NR_CPUS CONFIG_NR_CPUS
 
+#ifndef CONFIG_DEBUG
+#define NDEBUG
+#endif
+
 #endif /* __XEN_CONFIG_H__ */
-- 
2.7.3


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v5 0/6] Kconfig debug options

[Doug Goldstein]

This converts the debug options from xen/Rules.mk to Kconfig. Hopefully
I haven't missed anything in the back and forth.

change since v4:
- fixing poorly write speuling and the grammer
change since v3:
- wrap all options in 'if DEBUG || EXPERT' (except DEBUG)
- wording update to DEBUG option and some commit messages
- all old command line options now complain
change since v2:
- dropped patch 5 as it was unwanted
- remove 'default n'
- redid patch 1

Doug Goldstein (6):
  build: convert debug to Kconfig
  build: convert crash_debug to Kconfig
  build: convert verbose to Kconfig
  build: convert frame_pointer to Kconfig
  build: convert perfc{,_arrays} to Kconfig
  build: convert lock_profile to Kconfig

 INSTALL   |  6 
 docs/misc/crashdb.txt |  4 +--
 xen/Kconfig   |  2 ++
 xen/Kconfig.debug | 62 +++
 xen/Rules.mk  | 40 -
 xen/arch/arm/kernel.c |  2 +-
 xen/arch/arm/xen.lds.S|  2 +-
 xen/arch/x86/Makefile |  3 +-
 xen/arch/x86/domain.c |  2 +-
 xen/arch/x86/domain_build.c   |  2 +-
 xen/arch/x86/hvm/hvm.c|  2 +-
 xen/arch/x86/time.c   |  4 +--
 xen/arch/x86/x86_64/Makefile  |  2 +-
 xen/arch/x86/x86_64/asm-offsets.c |  2 +-
 xen/arch/x86/xen.lds.S|  2 +-
 xen/common/Makefile   |  4 +--
 xen/common/keyhandler.c   |  4 +--
 xen/common/perfc.c|  2 +-
 xen/common/spinlock.c | 10 +++
 xen/common/sysctl.c   |  4 +--
 xen/include/asm-x86/asm_defns.h   |  2 +-
 xen/include/asm-x86/debugger.h|  2 +-
 xen/include/asm-x86/domain.h  |  2 +-
 xen/include/xen/config.h  |  4 +++
 xen/include/xen/gdbstub.h |  2 +-
 xen/include/xen/perfc.h   |  8 ++---
 xen/include/xen/sched.h   |  2 +-
 xen/include/xen/spinlock.h|  4 +--
 xen/include/xsm/dummy.h   |  2 +-
 29 files changed, 123 insertions(+), 66 deletions(-)
 create mode 100644 xen/Kconfig.debug

-- 
2.7.3


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/3] VMX: Properly handle pi descriptor and per-cpu blocking list

[Dario Faggioli]

On Tue, 2016-05-24 at 10:07 +, Wu, Feng wrote:
> > See, for instance, cpu_disable_scheduler() in schedule.c. What we
> > do is
> > go over all the vcpus of all domains of either the system or the
> > cpupool, and force the ones that we found with v->processor set to
> > the
> > pCPU that is going down, to perform migration (system_state will be
> > different than SYS_STATE_suspend, and we hence take the 'else'
> > branch).
> > 
> > Considering that the pCPU is no longer part of the relevant
> > bitmask-s
> > during the migration, the vCPUs will figure out that they just
> > can't
> > stay there, and move somewhere else.
>
> Thanks a lot for the elaboration, it is really helpful.
> 
NP :-)

> > Note, however, that this happens for running and runnable vCPUs. 
>
> I don't quite understand this, do you mean cpu_disable_scheduler()
> only handle running and runnable vCPUs, I tried to find some hints
> from the code, but I didn't get it. Could you please give some more
> information about this?
> 
It goes through all the vcpus of all domains, and does not check or
care whether they are running, runnable or blocked.

Let's look at this in some more details. So, let's assume that
processor 5 is going away, and that you have the following vcpus
around:

 d0v0 : v->processor = 5, running on cpu 5
 d0v1 : v->processor = 4, running on cpu 4
 d1v0 : v->processor = 5, runnable but not running
 d2v3 : v->processor = 5, blocked

for d0v0, we do:
  cpu_disable_scheduler(5)
    set_bit(_VPF_migrating, d0v0->pause_flags);
    vcpu_sleep_nosync(d0v0);
      SCHED_OP(sleep, d0v0);
        csched_vcpu_sleep(d0v0)
          cpu_raise_softirq(5, SCHEDULE_SOFTIRQ);
    vcpu_migrate(d0v0);
      if ( v->is_running || ...) // assume v->is_running is true
        return
    ...
    ... <--- scheduling occurs on processor 5
    ...
    context_saved(d0v0)
      vcpu_migrate(d0v0);
          //is_running is 0, so _VPF_migrating gets cleared
        vcpu_move_locked(d0v0, new_cpu);
        vcpu_wake(d0v0);
          SCHED_OP(wake, d0v0);
            csched_vcpu_wake(d0v0)
              __runq_insert(d0v0);
              __runq_tickle(d0v0);

for d0v1, we do:
  cpu_disable_scheduler(5)
    if ( d0v1->processor != 5 )
      continue

for d1v0, we do:
  cpu_disable_scheduler(5)
    set_bit(_VPF_migrating, d1v0->pause_flags);
    vcpu_sleep_nosync(d1v0);
      SCHED_OP(sleep, d1v0);
        csched_vcpu_sleep(d1v0)
          __runq_remove(d1v0);
    vcpu_migrate(d1v0);
      if ( d1v0->is_running ||
           !test_and_clear_bit(_VPF_migrating, d1v0->pause_flags)
          // false, but clears the _VPF_migrating flag
      vcpu_move_locked(d1v0, new_cpu);
      vcpu_wake(v);
        SCHED_OP(wake, d1v0);
          csched_vcpu_wake(d1v0)
            __runq_insert(d1v0);
            __runq_tickle(d1v0);

for d2v3, we do:
  cpu_disable_scheduler(5)
    set_bit(_VPF_migrating, d2v3-
>pause_flags);
    vcpu_sleep_nosync(d2v3);
      SCHED_OP(sleep, d2v3);
 
      csched_vcpu_sleep(d2v3)
[1]       // Nothing! 
   
vcpu_migrate(d2v3);
      if ( d2v3->is_running ||
         
 !test_and_clear_bit(_VPF_migrating, d2v3->pause_flags)
          //
false, but clears the _VPF_migrating flag
[*]   vcpu_move_locked(d2v3,
new_cpu);
      vcpu_wake(d2v3);
[2]     // Nothing!

> > If a
> > vCPU is blocker, there is nothing to do, and in fact, nothing
> > happens
> > (as vcpu_sleep_nosync() and vcpu_wake() are NOP in that case). 
>
> What do you mean by saying ' vcpu_sleep_nosync() and vcpu_wake()
> are NOP '?
> 
See [1] and [2] above.

> > For
> > those vCPUs, as soon as they wake up, they'll figure out that their
> > own
> > v->processor is not there any longer, and will move somewhere else.
>
> So basically, when vCPU is blocking, it has no impact to the blocking
> vcpu
> when 'v->processor' is removed. When the vCPU is waken up, it will
> find
> another pCPU to run, since the original 'v->processor' is down and no
> longer in the cpu bitmask, right?
> 
Yes, that was my point.

_However_, as you can see at [*] above, it must be noted that even
those vcpus that blocked while running on a certain processor (5 in the
example), indeed have a chance to have their
v->processor changed to something that is still online (something
different than 5), as a consequence of that processor going away.

Whether this is useful/enough for you, I can't tell right now, out of
the top of my head.

> > > > But this is not an issue  in non pCPU hotplug scenario.
> > > > 
> > It's probably an issue even if you remove a cpu from a cpupool (and
> > even a more "interesting" one, if you also manage to add it to
> > another
> > pool, in the meantime) isn't it?
>
> Yes, things become more complex in that case 
> 
Well, but can you confirm that we also have an issue there, and test
and report what happens if you move a cpu from pool A to pool B, while
it still has vcpus from a domain that stays in pool A.

If there's transient suboptimal behavior, well, we probably can live

[Xen-devel] [PATCH v5 2/6] build: convert crash_debug to Kconfig

[Doug Goldstein]

Convert the crash_debug option to Kconfig as CONFIG_CRASH_DEBUG. This
was previously togglable on the command line so this adds a message for
users enabling it from the command line to tell them to enable it from
make menuconfig.

Signed-off-by: Doug Goldstein 
Reviewed-by: Andrew Cooper 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Jan Beulich 
---
CC: Andrew Cooper 
CC: George Dunlap 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
CC: Wei Liu 
---
 INSTALL|  1 -
 docs/misc/crashdb.txt  |  4 ++--
 xen/Kconfig.debug  | 11 +++
 xen/Rules.mk   |  5 +++--
 xen/arch/x86/Makefile  |  3 +--
 xen/arch/x86/x86_64/Makefile   |  2 +-
 xen/common/Makefile|  2 +-
 xen/include/asm-x86/debugger.h |  2 +-
 xen/include/xen/gdbstub.h  |  2 +-
 9 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/INSTALL b/INSTALL
index 95fa94d..2974b9b 100644
--- a/INSTALL
+++ b/INSTALL
@@ -231,7 +231,6 @@ verbose=y
 perfc=y
 perfc_arrays=y
 lock_profile=y
-crash_debug=y
 frame_pointer=y
 lto=y
 
diff --git a/docs/misc/crashdb.txt b/docs/misc/crashdb.txt
index b41a538..9733666 100644
--- a/docs/misc/crashdb.txt
+++ b/docs/misc/crashdb.txt
@@ -5,7 +5,7 @@ Xen has a simple gdb stub for doing post-mortem debugging i.e. 
once
 you've crashed it, you get to poke around and find out why.  There's
 also a special key handler for making it crash, which is handy.
 
-You need to have crash_debug=y set when compiling , and you also need
+You need to have CRASH_DEBUG=y set when compiling, and you also need
 to enable it on the Xen command line, eg by gdb=com1.
 
 If you need to have a serial port shared between gdb and the console,
@@ -19,7 +19,7 @@ if you have a simple null modem connection between the test 
box and
 the workstation, and aren't using a H/L split console:
 
   * Set debug=y in Config.mk
-  * Set crash_debug=y in xen/Rules.mk
+  * Set CRASH_DEBUG=y with `make -C xen menuconfig`
   * Make the changes in the attached patch, and build.
   * Arrange to pass gdb=com1 as a hypervisor command line argument
 (I already have com1=38400,8n1 console=com1,vga sync_console)
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index 796af0c..8eeb13f 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -11,4 +11,15 @@ config DEBUG
 
  You probably want to say 'N' here.
 
+if DEBUG || EXPERT = "y"
+
+config CRASH_DEBUG
+   bool "Crash Debugging Support"
+   depends on X86
+   ---help---
+ If you want to attach gdb to Xen to debug Xen if it crashes
+ then say Y.
+
+endif # DEBUG || EXPERT
+
 endmenu
diff --git a/xen/Rules.mk b/xen/Rules.mk
index da2f490..b077e25 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -7,7 +7,6 @@ verbose   ?= n
 perfc ?= n
 perfc_arrays  ?= n
 lock_profile  ?= n
-crash_debug   ?= n
 frame_pointer ?= n
 lto   ?= n
 
@@ -25,6 +24,9 @@ ifeq ($(perfc_arrays),y)
 perfc := y
 endif
 
+ifneq ($(origin crash_debug),undefined)
+$(error "You must use 'make menuconfig' to enable/disable crash_debug now.")
+endif
 ifeq ($(origin debug),command line)
 $(warning "You must use 'make menuconfig' to enable/disable debug now.")
 endif
@@ -59,7 +61,6 @@ CFLAGS += -Wa,--strip-local-absolute
 endif
 
 CFLAGS-$(verbose)   += -DVERBOSE
-CFLAGS-$(crash_debug)   += -DCRASH_DEBUG
 CFLAGS-$(perfc) += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 4665a68..4ccef4a 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -27,6 +27,7 @@ obj-y += domain_page.o
 obj-y += e820.o
 obj-y += extable.o
 obj-y += flushtlb.o
+obj-$(CONFIG_CRASH_DEBUG) += gdbstub.o
 obj-y += i387.o
 obj-y += i8259.o
 obj-y += io_apic.o
@@ -66,8 +67,6 @@ obj-y += vm_event.o
 obj-$(CONFIG_XSPLICE) += alternative.o xsplice.o
 obj-y += xstate.o
 
-obj-$(crash_debug) += gdbstub.o
-
 x86_emulate.o: x86_emulate/x86_emulate.c x86_emulate/x86_emulate.h
 
 efi-y := $(shell if [ ! -r $(BASEDIR)/include/xen/compile.h -o \
diff --git a/xen/arch/x86/x86_64/Makefile b/xen/arch/x86/x86_64/Makefile
index 5b54c16..d8815e7 100644
--- a/xen/arch/x86/x86_64/Makefile
+++ b/xen/arch/x86/x86_64/Makefile
@@ -14,4 +14,4 @@ obj-y += cpu_idle.o
 obj-y += cpufreq.o
 obj-bin-$(CONFIG_KEXEC) += kexec_reloc.o
 
-obj-$(crash_debug)   += gdbstub.o
+obj-$(CONFIG_CRASH_DEBUG)   += gdbstub.o
diff --git a/xen/common/Makefile b/xen/common/Makefile
index afd84b6..a98bcc2 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -8,6 +8,7 @@ obj-y += domain.o
 obj-y += event_2l.o
 obj-y += 

Re: [Xen-devel] [for-4.8 2/2] xen/arm: Provide device tree debugging helper in a single place

[Konrad Rzeszutek Wilk]

On Tue, May 24, 2016 at 11:20:41AM +0100, Julien Grall wrote:
> Provide helper to debug the device tree in device_tree.h. This will
> avoid to have to redeclare helper for each file requiring debug.
> 
> Also replace DPRINT by the new helper dt_dprintk in domain_build.c

Reviewed-by: Konrad Rzeszutek Wilk 
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/domain_build.c   | 71 
> +--
>  xen/common/device_tree.c  |  2 --
>  xen/include/xen/device_tree.h |  9 ++
>  3 files changed, 43 insertions(+), 39 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index fb035ff..71ead8b 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -42,12 +42,6 @@ static void __init parse_dom0_mem(const char *s)
>  }
>  custom_param("dom0_mem", parse_dom0_mem);
>  
> -#ifdef CONFIG_DEVICE_TREE_DEBUG
> -# define DPRINT(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
> -#else
> -# define DPRINT(fmt, args...) do {} while ( 0 )
> -#endif
> -
>  //#define DEBUG_11_ALLOCATION
>  #ifdef DEBUG_11_ALLOCATION
>  # define D11PRINT(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
> @@ -364,7 +358,7 @@ static void allocate_memory(struct domain *d, struct 
> kernel_info *kinfo)
>  {
>  int l;
>  
> -DPRINT("memory node\n");
> +dt_dprintk("memory node\n");
>  
>  reg_size = dt_cells_to_size(dt_n_addr_cells(memory) + 
> dt_n_size_cells(memory));
>  
> @@ -571,7 +565,8 @@ static int make_memory_node(const struct domain *d,
>  __be32 reg[nr_cells];
>  __be32 *cells;
>  
> -DPRINT("Create memory node (reg size %d, nr cells %d)\n", reg_size, 
> nr_cells);
> +dt_dprintk("Create memory node (reg size %d, nr cells %d)\n",
> +   reg_size, nr_cells);
>  
>  /* ePAPR 3.4 */
>  res = fdt_begin_node(fdt, "memory");
> @@ -588,8 +583,8 @@ static int make_memory_node(const struct domain *d,
>  u64 start = kinfo->mem.bank[i].start;
>  u64 size = kinfo->mem.bank[i].size;
>  
> -DPRINT("  Bank %d: %#"PRIx64"->%#"PRIx64"\n",
> -i, start, start + size);
> +dt_dprintk("  Bank %d: %#"PRIx64"->%#"PRIx64"\n",
> +   i, start, start + size);
>  
>  dt_child_set_range(, parent, start, size);
>  }
> @@ -618,7 +613,7 @@ static int make_hypervisor_node(const struct kernel_info 
> *kinfo,
>  int sizecells = dt_child_n_size_cells(parent);
>  void *fdt = kinfo->fdt;
>  
> -DPRINT("Create hypervisor node\n");
> +dt_dprintk("Create hypervisor node\n");
>  
>  /*
>   * Sanity-check address sizes, since addresses and sizes which do
> @@ -667,7 +662,7 @@ static int make_psci_node(void *fdt, const struct 
> dt_device_node *parent)
>  "arm,psci-0.2""\0"
>  "arm,psci";
>  
> -DPRINT("Create PSCI node\n");
> +dt_dprintk("Create PSCI node\n");
>  
>  /* See linux Documentation/devicetree/bindings/arm/psci.txt */
>  res = fdt_begin_node(fdt, "psci");
> @@ -710,7 +705,7 @@ static int make_cpus_node(const struct domain *d, void 
> *fdt,
>  bool_t clock_valid;
>  uint64_t mpidr_aff;
>  
> -DPRINT("Create cpus node\n");
> +dt_dprintk("Create cpus node\n");
>  
>  if ( !cpus )
>  {
> @@ -765,7 +760,8 @@ static int make_cpus_node(const struct domain *d, void 
> *fdt,
>   * is enough for the current max vcpu number.
>   */
>  mpidr_aff = vcpuid_to_vaffinity(cpu);
> -DPRINT("Create cpu@%"PRIx64" (logical CPUID: %d) node\n", mpidr_aff, 
> cpu);
> +dt_dprintk("Create cpu@%"PRIx64" (logical CPUID: %d) node\n",
> +   mpidr_aff, cpu);
>  
>  snprintf(buf, sizeof(buf), "cpu@%"PRIx64, mpidr_aff);
>  res = fdt_begin_node(fdt, buf);
> @@ -821,11 +817,11 @@ static int make_gic_node(const struct domain *d, void 
> *fdt,
>   */
>  if ( node != dt_interrupt_controller )
>  {
> -DPRINT("  Skipping (secondary GIC)\n");
> +dt_dprintk("  Skipping (secondary GIC)\n");
>  return 0;
>  }
>  
> -DPRINT("Create gic node\n");
> +dt_dprintk("Create gic node\n");
>  
>  res = fdt_begin_node(fdt, "interrupt-controller");
>  if ( res )
> @@ -837,7 +833,7 @@ static int make_gic_node(const struct domain *d, void 
> *fdt,
>   */
>  if ( gic->phandle )
>  {
> -DPRINT("  Set phandle = 0x%x\n", gic->phandle);
> +dt_dprintk("  Set phandle = 0x%x\n", gic->phandle);
>  res = fdt_property_cell(fdt, "phandle", gic->phandle);
>  if ( res )
>  return res;
> @@ -894,7 +890,7 @@ static int make_timer_node(const struct domain *d, void 
> *fdt,
>  u32 clock_frequency;
>  bool_t clock_valid;
>  
> -DPRINT("Create timer node\n");
> +dt_dprintk("Create timer node\n");
>  
>  dev = dt_find_matching_node(NULL, timer_ids);
>  if ( !dev )
> @@ -922,15 

Re: [Xen-devel] [for-4.8 1/2] xen/arm: Convert DEBUG_DT to Kconfig

[Konrad Rzeszutek Wilk]

On Tue, May 24, 2016 at 11:20:40AM +0100, Julien Grall wrote:
> Convert device-tree debugging to 'Kconfig' as
> CONFIG_DEBUG_TREE_DEBUG.
> 
> The option is not enabled by default because the output is very
> verbose.
> 
> Signed-off-by: Julien Grall 
> 
> ---
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> Cc: Doug Goldstein 
> ---
>  xen/Kconfig.debug   | 7 +++
>  xen/arch/arm/domain_build.c | 4 +---
>  xen/common/device_tree.c| 4 +---
>  3 files changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
> index 303bf36..59be34d 100644
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -55,6 +55,13 @@ config VERBOSE_DEBUG
> Guest output from HYPERVISOR_console_io and hypervisor parsing
> ELF images (dom0) is logged in the Xen ring buffer.
>  
> +config DEVICE_TREE_DEBUG
> + bool "Device tree debug messages"
> + depends on HAS_DEVICE_TREE
> + ---help---
> +   Device tree parsing and DOM0 device tree building messages is
> +   logged in the Xen ring buffer

s/is logged/are logged/

Also missing stop at the end.

Perhaps also add:

"If unsure, say N here."

Or could this be part of the VERBOSE one (which spews out data about
ELF parsing and allows guests to do  the console_io_write hypercalls?).
> +
>  endif # DEBUG || EXPERT
>  
>  endmenu
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 00dc07a..fb035ff 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -42,9 +42,7 @@ static void __init parse_dom0_mem(const char *s)
>  }
>  custom_param("dom0_mem", parse_dom0_mem);
>  
> -//#define DEBUG_DT
> -
> -#ifdef DEBUG_DT
> +#ifdef CONFIG_DEVICE_TREE_DEBUG
>  # define DPRINT(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
>  #else
>  # define DPRINT(fmt, args...) do {} while ( 0 )
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index 06a2837..0df2e4b 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -54,9 +54,7 @@ struct dt_alias_prop {
>  
>  static LIST_HEAD(aliases_lookup);
>  
> -// #define DEBUG_DT
> -
> -#ifdef DEBUG_DT
> +#ifdef CONFIG_DEVICE_TREE_DEBUG
>  # define dt_dprintk(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
>  static void dt_dump_addr(const char *s, const __be32 *addr, int na)
>  {
> -- 
> 1.9.1
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] ARM Xen Bug #45: Is there a solution?

[Dirk Behme]

Hi Julien,

On 23.05.2016 22:15, Julien Grall wrote:

Hello Dirk,


is there a solution for

arm: domain 0 disables clocks which are in fact being used
http://bugs.xenproject.org/xen/bug/45

?

On an ARM based board I have to use 'clk_ignore_unused' preventing that
Dom0 disables the UART clock for the console UART configured with
console=hvc0.


There is no better solution than passing "clk_ignore_unused" on the
kernel command line so far.



What would be the solution for this issue? The

"propagate any clock related properties from the UART
node into the Xen hypervisor node"

mentioned in the ticket?

Best regards

Dirk


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Question about the best practice to install two versions of Xen toolstack on the same machine

[Olaf Hering]

On Tue, May 24, Dongli Zhang wrote:

> 7. export LD_LIBRARY_PATH=/soft/xen/lib

That is to be replaced by --enable-rpath.

> 9. export PYTHONPATH=/soft/xen/lib/python2.7/site-packages (this is for 
> pygrub)

This is to be replaced by pvgrub2.

Olaf

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/3] VMX: Properly handle pi descriptor and per-cpu blocking list

[Wu, Feng]

> -Original Message-
> From: Wu, Feng
> Sent: Tuesday, May 24, 2016 6:08 PM
> To: Dario Faggioli ; Jan Beulich 
> 
> Cc: andrew.coop...@citrix.com; george.dun...@eu.citrix.com; Tian, Kevin
> ; xen-devel@lists.xen.org; konrad.w...@oracle.com;
> k...@xen.org; Wu, Feng 
> Subject: RE: [PATCH 0/3] VMX: Properly handle pi descriptor and per-cpu
> blocking list
> 
> 
> 
> > -Original Message-
> > From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> > Sent: Monday, May 23, 2016 8:39 PM
> > To: Jan Beulich ; Wu, Feng 
> > Cc: andrew.coop...@citrix.com; george.dun...@eu.citrix.com; Tian, Kevin
> > ; xen-devel@lists.xen.org; konrad.w...@oracle.com;
> > k...@xen.org
> > Subject: Re: [PATCH 0/3] VMX: Properly handle pi descriptor and per-cpu
> > blocking list
> >
> > On Mon, 2016-05-23 at 02:51 -0600, Jan Beulich wrote:
> > > > > > On 23.05.16 at 10:44,  wrote:
> > > > >
> > > > > vCPU-s currently having their v->processor set to the pCPU being
> > > > > hot removed would simply get migrated elsewhere. If that's not
> > > > > accompanied by respective PI blocking list adjustments, then I
> > > > > can
> > > > > only refer you back to the original series' review process, where
> > > > > it was (iirc) more than once that it was pointed out that getting
> > > > > out
> > > > > of sync v->processor and the PI list a vCPU sits on may casue
> > > > > issues. And if there is an issue here, I'm not sure what a good
> > > > > solution would be.
> > > > Okay, here is my understanding about the blocking and vCPU
> > > > migration things, if vCPU is blocking and its v->processor is pCPU
> > > > 0,
> > > > at some point, pCPU0 is removed from the system, it will also
> > > > migrate the vCPU to another pCPU, say, pCPU1 as the response
> > > > to pCPU0 being unplugged, hence, v->processor = pCPU1, right?
> > >
> > > Yes.
> > >
> > See, for instance, cpu_disable_scheduler() in schedule.c. What we do is
> > go over all the vcpus of all domains of either the system or the
> > cpupool, and force the ones that we found with v->processor set to the
> > pCPU that is going down, to perform migration (system_state will be
> > different than SYS_STATE_suspend, and we hence take the 'else' branch).
> >
> > Considering that the pCPU is no longer part of the relevant bitmask-s
> > during the migration, the vCPUs will figure out that they just can't
> > stay there, and move somewhere else.
> 
> Thanks a lot for the elaboration, it is really helpful.
> 
> >
> > Note, however, that this happens for running and runnable vCPUs.
> 
> I don't quite understand this, do you mean cpu_disable_scheduler()
> only handle running and runnable vCPUs, I tried to find some hints
> from the code, but I didn't get it. Could you please give some more
> information about this?
> 
> > If a
> > vCPU is blocker, there is nothing to do, and in fact, nothing happens
> > (as vcpu_sleep_nosync() and vcpu_wake() are NOP in that case).
> 
> What do you mean by saying ' vcpu_sleep_nosync() and vcpu_wake()
> are NOP '?

I think I understand what you meant above now.

Do you think the following idea makes sense?

When a pCPU is unplugged, we can just remove the vcpus on the
associated per-cpu blocking list, then we can choose another online
cpu, set the right NDST value, and put the vCPU the new per-cpu list?
Meanwhile, we may need some special treatment to the case that
vmx_vcpu_block() may run concurrently with cpu hotplug.

Thanks,
Feng

> 
> > For
> > those vCPUs, as soon as they wake up, they'll figure out that their own
> > v->processor is not there any longer, and will move somewhere else.
> 
> So basically, when vCPU is blocking, it has no impact to the blocking vcpu
> when 'v->processor' is removed. When the vCPU is waken up, it will find
> another pCPU to run, since the original 'v->processor' is down and no
> longer in the cpu bitmask, right?
> 
> >
> > > > If that is the case, I think the current code may have issues in
> > > > the
> > > > above case, since 'NDST' filed in PI descriptor is still vCPU0 even
> > > > it is removed from the system. I need to consider how to handle
> > > > this case.
> > >
> > Exactly. I don't think you can do that, for instance, from within
> > cpu_disable_scheduler(), or anythign that gets called from there, as it
> > basically deals with running vCPUs, while you're interested in blocked
> > ones.
> >
> > I wonder whether you can register your own notifier, and, inside it,
> > scan the blocked list and fixup things... (just the first idea that
> > came up in my mind)
> >
> > > > But this is not an issue  in non pCPU hotplug scenario.
> > > >
> > It's probably an issue even if you remove a cpu from a cpupool (and
> > even a more "interesting" one, if you also manage to add it to another
> > pool, in the meantime) isn't it?
> 
> Yes, things become 

[Xen-devel] [for-4.7] Request input on XENMAPSPACE_dev_mmio

[Julien Grall]

Hi all,

Sorry for noticing this problem late in the release process.

The mapping space XENMAPSPACE_dev_mmio has been introduced recently 
(will be present in Xen 4.7) to let dom0 map device MMIO regions when 
ACPI is in-use on ARM platform.


Xen ARM will map those regions in the stage-2 page table using the 
memory attribute Device_nGnRE (i.e non-Gathering, non-Reordering, 
no-unaligned access).


The final memory attribute is a combination of stage-1 (handled by the 
kernel) and stage-2 attributes. It will always result to a restrictive 
memory attribute (see D4.4.3 in ARM DDI 0487A.i).


Device_nGnRE is one of the most restrictive memory attribute, whilst it 
fits in lot of case, the performance are not great on device such as 
graphic cards, and it makes impossible to access those regions with 
unaligned access (a lot of Linux drivers uses memcpy which does 
unaligned access).


Unfortunately it is not possible to find a weaker memory attribute that 
would fit for everyone. For instance, we would need to map static RAM 
with normal memory attribute to allow speculation and unaligned access.


However, the same normal memory could not be used for MMIOs having 
side-effect (such as an UART) because the processor would be allowed to 
fetch additional memory locations.


For more details about the different memory attributes see B2.8 in ARM 
DDI 0487A.i.


In the case of ACPI, only DOM0 has access to the full description of the 
device and know the memory attribute to use. So we need to expand
XENMAPSPACE_dev_mmio to provide the memory attribute (this could be done 
using the top bits of 'space').


For ARM we would need at least the following attributes:
  - normal uncached memory: for write-combine on SRAM or video RAM
  - Device_nGnRE: non-gathering and non-reordering
  - Device_GRE: gathering and redordering

It might be worth to also consider "normal cache memory".

Xen 4.7 will be release very soon (~ couple of weeks), so we have few 
solutions:

1) Extend XENMAPSPACE_dev_mmio for Xen 4.7
2) Wait for Xen 4.8 to fix it: this may require to introduce a new 
space to be backward compatible.
3) Revert XENMAPSPACE_dev_mmio for Xen 4.7 and re-introduce it 
properly on Xen 4.8: It is only used by ACPI on ARM which is a tech preview.


I would lean toward the solution 1) to avoid delaying ACPI support for 
ARM and avoid introducing an sub-hypercall which does not fit for our usage.


I think the space could be extend in a lightweight version for Xen 4.7 
by introducing only one memory attribute and warn on any other value.


Do you have any opinions on the way to fix it? I can provide a patch as 
soon as possible.


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 07/16] x86/boot: create *.lnk files with linker script

[Jan Beulich]

>>> On 24.05.16 at 14:28,  wrote:
> On Tue, May 24, 2016 at 03:05:06AM -0600, Jan Beulich wrote:
>> >>> On 15.04.16 at 14:33,  wrote:
>> > --- /dev/null
>> > +++ b/xen/arch/x86/boot/build32.lds
>> > @@ -0,0 +1,49 @@
>> > +/*
>> > + * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
>> > + *  Daniel Kiper 
>> > + *
>> > + * This program is free software; you can redistribute it and/or modify
>> > + * it under the terms of the GNU General Public License as published by
>> > + * the Free Software Foundation; either version 2 of the License, or
>> > + * (at your option) any later version.
>> > + *
>> > + * This program is distributed in the hope that it will be useful,
>> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> > + * GNU General Public License for more details.
>> > + *
>> > + * You should have received a copy of the GNU General Public License along
>> > + * with this program.  If not, see .
>> > + */
>> > +
>> > +ENTRY(_start)
>> > +
>> > +SECTIONS
>> > +{
>> > +  /* Merge code and data into one section. */
>> > +  .text : {
>> > +*(.text)
>> > +*(.text.*)
>> > +*(.rodata)
>>
>> This (and the respective %.lnk rule change below) is not in line with
>> the patch description. It's further suspicious that you only handle
> 
> I am not sure what exactly do you mean by that.

Quoting your commit message: "...  merge all text and data sections
into one .text section." Contrast this to the limited set of sections
above.

>> .rodata but not also .rodata.* here.
> 
> I did this deliberately. I just want to take only these sections which I 
> know that
> contain required code and data. Nothing more. If in the future we find out 
> that
> .rodata.* (or anything else) is needed then we can add it later.
> 
>> > +  }
>> > +
>> > +  /DISCARD/ : {
>> > +/*
>> > + * .got.plt section is used only by dynamic linker
>> > + * and our output is not supposed to be loaded by
>> > + * dynamic linker. Additionally, it just contains
>> > + * .PLT0 which is referenced from nowhere. So, we
>> > + * can safely drop .got.plt here.
>> > + *
>> > + * Ha! This should be really discarded here. However,
>> > + * .got.plt section contains _GLOBAL_OFFSET_TABLE_
>> > + * symbol too and it is used as a reference for relative
>> > + * addressing (and only for that thing). Hence, ld
>> > + * complains if we remove that section because it
>> > + * cannot find _GLOBAL_OFFSET_TABLE_. So, drop .got.plt
>> > + * section during conversion to plain binary format.
>> > + * Please check build32.mk for more details.
>> > + */
>> > +/* *(.got.plt) */
>> > +  }
>>
>> I'm afraid this needs more investigation: Afaik there should be no
> 
> I am not sure what else we should look for.

The reason why such an empty .got.plt gets created in the first place.
If e.g. that turns out to be a bug in (some versions of) binutils, then
that bug should be named here as the reason.

>> reason for the linker to create an otherwise empty .got.plt in the
> 
> As I wrote above. It contains _GLOBAL_OFFSET_TABLE_ which is used
> as a reference for relative addressing.

But we don't use any such, so without being needed I don't think
the symbol needs to be created.

>> first place. And discarding it without being sure it is empty is not
>> that good an idea anyway.
> 
> Good point! Potentially we can check is it empty, excluding 
> _GLOBAL_OFFSET_TABLE_ symbol, in build32.mk.

Well, your comment above says it have .PLT0, which means it's not
exactly empty.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable test] 94730: tolerable FAIL - PUSHED

[osstest service owner]

flight 94730 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94730/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail   like 94580
 build-i386-rumpuserxen6 xen-buildfail   like 94580
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94580
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 94580
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 94580
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94580
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 94580

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  983aae0b591458c6cf2e3166c4e1170fd0404e7d
baseline version:
 xen  bab2bd8e222de9e596699ac080ea985af828c4c4

Last test of basis94580  2016-05-19 13:08:47 Z4 days
Failing since 94589  2016-05-20 02:45:09 Z4 days9 attempts
Testing same since94730  2016-05-23 22:43:07 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Wei Chen 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt 

Re: [Xen-devel] [PATCH v3 07/16] x86/boot: create *.lnk files with linker script

[Daniel Kiper]

On Tue, May 24, 2016 at 03:05:06AM -0600, Jan Beulich wrote:
> >>> On 15.04.16 at 14:33,  wrote:
> > --- /dev/null
> > +++ b/xen/arch/x86/boot/build32.lds
> > @@ -0,0 +1,49 @@
> > +/*
> > + * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
> > + *  Daniel Kiper 
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License along
> > + * with this program.  If not, see .
> > + */
> > +
> > +ENTRY(_start)
> > +
> > +SECTIONS
> > +{
> > +  /* Merge code and data into one section. */
> > +  .text : {
> > +*(.text)
> > +*(.text.*)
> > +*(.rodata)
>
> This (and the respective %.lnk rule change below) is not in line with
> the patch description. It's further suspicious that you only handle

I am not sure what exactly do you mean by that.

> .rodata but not also .rodata.* here.

I did this deliberately. I just want to take only these sections which I know 
that
contain required code and data. Nothing more. If in the future we find out that
.rodata.* (or anything else) is needed then we can add it later.

> > +  }
> > +
> > +  /DISCARD/ : {
> > +/*
> > + * .got.plt section is used only by dynamic linker
> > + * and our output is not supposed to be loaded by
> > + * dynamic linker. Additionally, it just contains
> > + * .PLT0 which is referenced from nowhere. So, we
> > + * can safely drop .got.plt here.
> > + *
> > + * Ha! This should be really discarded here. However,
> > + * .got.plt section contains _GLOBAL_OFFSET_TABLE_
> > + * symbol too and it is used as a reference for relative
> > + * addressing (and only for that thing). Hence, ld
> > + * complains if we remove that section because it
> > + * cannot find _GLOBAL_OFFSET_TABLE_. So, drop .got.plt
> > + * section during conversion to plain binary format.
> > + * Please check build32.mk for more details.
> > + */
> > +/* *(.got.plt) */
> > +  }
>
> I'm afraid this needs more investigation: Afaik there should be no

I am not sure what else we should look for.

> reason for the linker to create an otherwise empty .got.plt in the

As I wrote above. It contains _GLOBAL_OFFSET_TABLE_ which is used
as a reference for relative addressing.

> first place. And discarding it without being sure it is empty is not
> that good an idea anyway.

Good point! Potentially we can check is it empty, excluding 
_GLOBAL_OFFSET_TABLE_
symbol, in build32.mk.

Anyway, there is a chance that these tricks will not be needed at all. I will
try to link 32-bit code directly into Xen binary using objcopy, etc. which
we discussed during hackathon.

Daniel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: sched: avoid races on time values read from NOW()

[Dario Faggioli]

On Tue, 2016-05-24 at 04:08 -0600, Jan Beulich wrote:
> While backporting this for 4.6 (which required substantial
> adjustment to the sched_rt.c part) 
>
Yep, I figure it did. :-(

It sounds like you've pretty much done with it, but if not, and if you
want me or Meng to provide the backport, just ask!

> I noticed that there's another
> of the cases mentioned in the description in rt_vcpu_insert(). The
> commit message doesn't mention why this was left unchanged, so
> was not fixing this perhaps just an oversight?
> 
It is indeed. I'll send a patch.

Sorry,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: use same main loop for counting and remapping pages

[David Vrabel]

On 18/05/16 15:44, Juergen Gross wrote:
> Instead of having two functions for cycling through the E820 map in
> order to count to be remapped pages and remap them later, just use one
> function with a caller supplied sub-function called for each region to
> be processed. This eliminates the possibility of a mismatch between
> both loops which showed up in certain configurations.

Applied to for-linus-4.7, thanks.

David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [ovmf test] 94735: all pass - PUSHED

[osstest service owner]

flight 94735 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94735/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 5646819ffb2d9cb87785e9e409f8d928a9f3a04d
baseline version:
 ovmf 3e43396b3506b9fdaf71ffb69ed160f2e108894b

Last test of basis94731  2016-05-23 23:13:58 Z0 days
Testing same since94735  2016-05-24 08:49:50 Z0 days1 attempts


People who touched revisions under test:
  Fu Siyuan 
  Ruiyu Ni 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=ovmf
+ revision=5646819ffb2d9cb87785e9e409f8d928a9f3a04d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
5646819ffb2d9cb87785e9e409f8d928a9f3a04d
+ branch=ovmf
+ revision=5646819ffb2d9cb87785e9e409f8d928a9f3a04d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' x5646819ffb2d9cb87785e9e409f8d928a9f3a04d = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

[Xen-devel] [qemu-upstream-4.3-testing test] 94733: trouble: blocked/broken

[osstest service owner]

flight 94733 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94733/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  107 days
Testing same since93977  2016-05-10 11:09:16 Z   13 days   48 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

Re: [Xen-devel] [for-4.8 0/2] xen/arm: Convert DEBUG_DT to Kconfig

[Julien Grall]

On 24/05/2016 11:20, Julien Grall wrote:

Hello all,

This small patch series converts DEBUG_DT to Kconfig. This is easier
to enable than having to modify the code when the user wants to debug
the device tree parsing.

This series is based on the version 4 of "Kconfig debug options" [1].


I forgot to add a link to Doug's series:

http://lists.xen.org/archives/html/xen-devel/2016-05/msg02093.html



Yours sincerely,

Julien Grall (2):
  xen/arm: Convert DEBUG_DT to Kconfig
  xen/arm: Provide device tree debugging helper in a single place

 xen/Kconfig.debug |  7 +
 xen/arch/arm/domain_build.c   | 73 ---
 xen/common/device_tree.c  |  6 +---
 xen/include/xen/device_tree.h |  9 ++
 4 files changed, 51 insertions(+), 44 deletions(-)



--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [for-4.8 1/2] xen/arm: Convert DEBUG_DT to Kconfig

[Julien Grall]

Convert device-tree debugging to 'Kconfig' as
CONFIG_DEBUG_TREE_DEBUG.

The option is not enabled by default because the output is very
verbose.

Signed-off-by: Julien Grall 

---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Doug Goldstein 
---
 xen/Kconfig.debug   | 7 +++
 xen/arch/arm/domain_build.c | 4 +---
 xen/common/device_tree.c| 4 +---
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index 303bf36..59be34d 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -55,6 +55,13 @@ config VERBOSE_DEBUG
  Guest output from HYPERVISOR_console_io and hypervisor parsing
  ELF images (dom0) is logged in the Xen ring buffer.
 
+config DEVICE_TREE_DEBUG
+   bool "Device tree debug messages"
+   depends on HAS_DEVICE_TREE
+   ---help---
+ Device tree parsing and DOM0 device tree building messages is
+ logged in the Xen ring buffer
+
 endif # DEBUG || EXPERT
 
 endmenu
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 00dc07a..fb035ff 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -42,9 +42,7 @@ static void __init parse_dom0_mem(const char *s)
 }
 custom_param("dom0_mem", parse_dom0_mem);
 
-//#define DEBUG_DT
-
-#ifdef DEBUG_DT
+#ifdef CONFIG_DEVICE_TREE_DEBUG
 # define DPRINT(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
 #else
 # define DPRINT(fmt, args...) do {} while ( 0 )
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 06a2837..0df2e4b 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -54,9 +54,7 @@ struct dt_alias_prop {
 
 static LIST_HEAD(aliases_lookup);
 
-// #define DEBUG_DT
-
-#ifdef DEBUG_DT
+#ifdef CONFIG_DEVICE_TREE_DEBUG
 # define dt_dprintk(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
 static void dt_dump_addr(const char *s, const __be32 *addr, int na)
 {
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [for-4.8 2/2] xen/arm: Provide device tree debugging helper in a single place

[Julien Grall]

Provide helper to debug the device tree in device_tree.h. This will
avoid to have to redeclare helper for each file requiring debug.

Also replace DPRINT by the new helper dt_dprintk in domain_build.c

Signed-off-by: Julien Grall 
---
 xen/arch/arm/domain_build.c   | 71 +--
 xen/common/device_tree.c  |  2 --
 xen/include/xen/device_tree.h |  9 ++
 3 files changed, 43 insertions(+), 39 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index fb035ff..71ead8b 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -42,12 +42,6 @@ static void __init parse_dom0_mem(const char *s)
 }
 custom_param("dom0_mem", parse_dom0_mem);
 
-#ifdef CONFIG_DEVICE_TREE_DEBUG
-# define DPRINT(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
-#else
-# define DPRINT(fmt, args...) do {} while ( 0 )
-#endif
-
 //#define DEBUG_11_ALLOCATION
 #ifdef DEBUG_11_ALLOCATION
 # define D11PRINT(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
@@ -364,7 +358,7 @@ static void allocate_memory(struct domain *d, struct 
kernel_info *kinfo)
 {
 int l;
 
-DPRINT("memory node\n");
+dt_dprintk("memory node\n");
 
 reg_size = dt_cells_to_size(dt_n_addr_cells(memory) + 
dt_n_size_cells(memory));
 
@@ -571,7 +565,8 @@ static int make_memory_node(const struct domain *d,
 __be32 reg[nr_cells];
 __be32 *cells;
 
-DPRINT("Create memory node (reg size %d, nr cells %d)\n", reg_size, 
nr_cells);
+dt_dprintk("Create memory node (reg size %d, nr cells %d)\n",
+   reg_size, nr_cells);
 
 /* ePAPR 3.4 */
 res = fdt_begin_node(fdt, "memory");
@@ -588,8 +583,8 @@ static int make_memory_node(const struct domain *d,
 u64 start = kinfo->mem.bank[i].start;
 u64 size = kinfo->mem.bank[i].size;
 
-DPRINT("  Bank %d: %#"PRIx64"->%#"PRIx64"\n",
-i, start, start + size);
+dt_dprintk("  Bank %d: %#"PRIx64"->%#"PRIx64"\n",
+   i, start, start + size);
 
 dt_child_set_range(, parent, start, size);
 }
@@ -618,7 +613,7 @@ static int make_hypervisor_node(const struct kernel_info 
*kinfo,
 int sizecells = dt_child_n_size_cells(parent);
 void *fdt = kinfo->fdt;
 
-DPRINT("Create hypervisor node\n");
+dt_dprintk("Create hypervisor node\n");
 
 /*
  * Sanity-check address sizes, since addresses and sizes which do
@@ -667,7 +662,7 @@ static int make_psci_node(void *fdt, const struct 
dt_device_node *parent)
 "arm,psci-0.2""\0"
 "arm,psci";
 
-DPRINT("Create PSCI node\n");
+dt_dprintk("Create PSCI node\n");
 
 /* See linux Documentation/devicetree/bindings/arm/psci.txt */
 res = fdt_begin_node(fdt, "psci");
@@ -710,7 +705,7 @@ static int make_cpus_node(const struct domain *d, void *fdt,
 bool_t clock_valid;
 uint64_t mpidr_aff;
 
-DPRINT("Create cpus node\n");
+dt_dprintk("Create cpus node\n");
 
 if ( !cpus )
 {
@@ -765,7 +760,8 @@ static int make_cpus_node(const struct domain *d, void *fdt,
  * is enough for the current max vcpu number.
  */
 mpidr_aff = vcpuid_to_vaffinity(cpu);
-DPRINT("Create cpu@%"PRIx64" (logical CPUID: %d) node\n", mpidr_aff, 
cpu);
+dt_dprintk("Create cpu@%"PRIx64" (logical CPUID: %d) node\n",
+   mpidr_aff, cpu);
 
 snprintf(buf, sizeof(buf), "cpu@%"PRIx64, mpidr_aff);
 res = fdt_begin_node(fdt, buf);
@@ -821,11 +817,11 @@ static int make_gic_node(const struct domain *d, void 
*fdt,
  */
 if ( node != dt_interrupt_controller )
 {
-DPRINT("  Skipping (secondary GIC)\n");
+dt_dprintk("  Skipping (secondary GIC)\n");
 return 0;
 }
 
-DPRINT("Create gic node\n");
+dt_dprintk("Create gic node\n");
 
 res = fdt_begin_node(fdt, "interrupt-controller");
 if ( res )
@@ -837,7 +833,7 @@ static int make_gic_node(const struct domain *d, void *fdt,
  */
 if ( gic->phandle )
 {
-DPRINT("  Set phandle = 0x%x\n", gic->phandle);
+dt_dprintk("  Set phandle = 0x%x\n", gic->phandle);
 res = fdt_property_cell(fdt, "phandle", gic->phandle);
 if ( res )
 return res;
@@ -894,7 +890,7 @@ static int make_timer_node(const struct domain *d, void 
*fdt,
 u32 clock_frequency;
 bool_t clock_valid;
 
-DPRINT("Create timer node\n");
+dt_dprintk("Create timer node\n");
 
 dev = dt_find_matching_node(NULL, timer_ids);
 if ( !dev )
@@ -922,15 +918,15 @@ static int make_timer_node(const struct domain *d, void 
*fdt,
  * level-sensitive interrupt */
 
 irq = timer_get_irq(TIMER_PHYS_SECURE_PPI);
-DPRINT("  Secure interrupt %u\n", irq);
+dt_dprintk("  Secure interrupt %u\n", irq);
 set_interrupt_ppi(intrs[0], irq, 0xf, IRQ_TYPE_LEVEL_LOW);
 
 irq = timer_get_irq(TIMER_PHYS_NONSECURE_PPI);
-DPRINT("  Non secure interrupt 

[Xen-devel] [for-4.8 0/2] xen/arm: Convert DEBUG_DT to Kconfig

[Julien Grall]

Hello all,

This small patch series converts DEBUG_DT to Kconfig. This is easier
to enable than having to modify the code when the user wants to debug
the device tree parsing.

This series is based on the version 4 of "Kconfig debug options" [1].

Yours sincerely,

Julien Grall (2):
  xen/arm: Convert DEBUG_DT to Kconfig
  xen/arm: Provide device tree debugging helper in a single place

 xen/Kconfig.debug |  7 +
 xen/arch/arm/domain_build.c   | 73 ---
 xen/common/device_tree.c  |  6 +---
 xen/include/xen/device_tree.h |  9 ++
 4 files changed, 51 insertions(+), 44 deletions(-)

-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: sched: avoid races on time values read from NOW()

[Jan Beulich]

>>> On 19.05.16 at 10:11,  wrote:
> --- a/xen/common/sched_rt.c
> +++ b/xen/common/sched_rt.c
> @@ -1198,7 +1198,7 @@ static void
>  rt_vcpu_wake(const struct scheduler *ops, struct vcpu *vc)
>  {
>  struct rt_vcpu * const svc = rt_vcpu(vc);
> -s_time_t now = NOW();
> +s_time_t now;
>  bool_t missed;
>  
>  BUG_ON( is_idle_vcpu(vc) );
> @@ -1225,6 +1225,7 @@ rt_vcpu_wake(const struct scheduler *ops, struct vcpu 
> *vc)
>   * If a deadline passed while svc was asleep/blocked, we need new
>   * scheduling parameters (a new deadline and full budget).
>   */
> +now = NOW();
>  
>  missed = ( now >= svc->cur_deadline );
>  if ( missed )
> @@ -1394,7 +1395,7 @@ rt_dom_cntl(
>   * from the replq and does the actual replenishment.
>   */
>  static void repl_timer_handler(void *data){
> -s_time_t now = NOW();
> +s_time_t now;
>  struct scheduler *ops = data;
>  struct rt_private *prv = rt_priv(ops);
>  struct list_head *replq = rt_replq(ops);
> @@ -1406,6 +1407,8 @@ static void repl_timer_handler(void *data){
>  
>  spin_lock_irq(>lock);
>  
> +now = NOW();
> +
>  /*
>   * Do the replenishment and move replenished vcpus
>   * to the temporary list to tickle.

While backporting this for 4.6 (which required substantial
adjustment to the sched_rt.c part) I noticed that there's another
of the cases mentioned in the description in rt_vcpu_insert(). The
commit message doesn't mention why this was left unchanged, so
was not fixing this perhaps just an oversight?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/3] VMX: Properly handle pi descriptor and per-cpu blocking list

[Wu, Feng]

> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Monday, May 23, 2016 8:39 PM
> To: Jan Beulich ; Wu, Feng 
> Cc: andrew.coop...@citrix.com; george.dun...@eu.citrix.com; Tian, Kevin
> ; xen-devel@lists.xen.org; konrad.w...@oracle.com;
> k...@xen.org
> Subject: Re: [PATCH 0/3] VMX: Properly handle pi descriptor and per-cpu
> blocking list
> 
> On Mon, 2016-05-23 at 02:51 -0600, Jan Beulich wrote:
> > > > > On 23.05.16 at 10:44,  wrote:
> > > >
> > > > vCPU-s currently having their v->processor set to the pCPU being
> > > > hot removed would simply get migrated elsewhere. If that's not
> > > > accompanied by respective PI blocking list adjustments, then I
> > > > can
> > > > only refer you back to the original series' review process, where
> > > > it was (iirc) more than once that it was pointed out that getting
> > > > out
> > > > of sync v->processor and the PI list a vCPU sits on may casue
> > > > issues. And if there is an issue here, I'm not sure what a good
> > > > solution would be.
> > > Okay, here is my understanding about the blocking and vCPU
> > > migration things, if vCPU is blocking and its v->processor is pCPU
> > > 0,
> > > at some point, pCPU0 is removed from the system, it will also
> > > migrate the vCPU to another pCPU, say, pCPU1 as the response
> > > to pCPU0 being unplugged, hence, v->processor = pCPU1, right?
> >
> > Yes.
> >
> See, for instance, cpu_disable_scheduler() in schedule.c. What we do is
> go over all the vcpus of all domains of either the system or the
> cpupool, and force the ones that we found with v->processor set to the
> pCPU that is going down, to perform migration (system_state will be
> different than SYS_STATE_suspend, and we hence take the 'else' branch).
> 
> Considering that the pCPU is no longer part of the relevant bitmask-s
> during the migration, the vCPUs will figure out that they just can't
> stay there, and move somewhere else.

Thanks a lot for the elaboration, it is really helpful.

> 
> Note, however, that this happens for running and runnable vCPUs. 

I don't quite understand this, do you mean cpu_disable_scheduler()
only handle running and runnable vCPUs, I tried to find some hints
from the code, but I didn't get it. Could you please give some more
information about this?

> If a
> vCPU is blocker, there is nothing to do, and in fact, nothing happens
> (as vcpu_sleep_nosync() and vcpu_wake() are NOP in that case). 

What do you mean by saying ' vcpu_sleep_nosync() and vcpu_wake()
are NOP '?

> For
> those vCPUs, as soon as they wake up, they'll figure out that their own
> v->processor is not there any longer, and will move somewhere else.

So basically, when vCPU is blocking, it has no impact to the blocking vcpu
when 'v->processor' is removed. When the vCPU is waken up, it will find
another pCPU to run, since the original 'v->processor' is down and no
longer in the cpu bitmask, right?

> 
> > > If that is the case, I think the current code may have issues in
> > > the
> > > above case, since 'NDST' filed in PI descriptor is still vCPU0 even
> > > it is removed from the system. I need to consider how to handle
> > > this case.
> >
> Exactly. I don't think you can do that, for instance, from within
> cpu_disable_scheduler(), or anythign that gets called from there, as it
> basically deals with running vCPUs, while you're interested in blocked
> ones.
> 
> I wonder whether you can register your own notifier, and, inside it,
> scan the blocked list and fixup things... (just the first idea that
> came up in my mind)
> 
> > > But this is not an issue  in non pCPU hotplug scenario.
> > >
> It's probably an issue even if you remove a cpu from a cpupool (and
> even a more "interesting" one, if you also manage to add it to another
> pool, in the meantime) isn't it?

Yes, things become more complex in that case 

Thanks,
Feng

> 
> Regards,
> Dario
> --
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [libvirt test] 94734: regressions - FAIL

[osstest service owner]

flight 94734 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94734/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-qcow2  6 xen-bootfail REGR. vs. 94591

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  580dbf06a4ac9bbcbcb325003d54070a864f96e2
baseline version:
 libvirt  4a718d6a0ef5db034b8b779cdf57347074f07994

Last test of basis94591  2016-05-20 04:21:50 Z4 days
Failing since 94623  2016-05-21 04:19:38 Z3 days3 attempts
Testing same since94734  2016-05-24 04:23:36 Z0 days1 attempts


People who touched revisions under test:
  Cole Robinson 
  Jiri Denemark 
  John Ferlan 
  Jovanka Gulicoska 
  Ján Tomko 
  Laine Stump 
  Michal Privoznik 
  Mikhail Feoktistov 
  Nishith Shah 
  Pavel Hrdina 
  Peter Krempa 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw fail
 test-amd64-amd64-libvirt-vhd pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 768 lines long.)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 05/10] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU mapping.

[Xu, Quan]

On May 24, 2016 5:09 PM, Jan Beulich  wrote:
> >>> On 24.05.16 at 11:01,  wrote:
> > On May 23, 2016 11:53 PM, Jan Beulich  wrote:
> >> >>> On 18.05.16 at 10:08,  wrote:
> >> > Propagate the IOMMU Device-TLB flush error up to IOMMU mapping.
> >>
> >> Btw - there's little reason to repeat the title here.
> >>
> >
> > I'll drop it.
> >
> > Can I apply it to  other patches?
> 
> You mean dropping a description that simply repeats the title - yes, of 
> course.

Yes, I think so too.

> Even better would of course be, where meaningful, if you added actual
> descriptions.
> 

I am afraid I would make things worse, so I will just simply drop  the 
description that simply repeats the title.

Quan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 11/15] xen/arm: Document the errata implemented in Xen

[Julien Grall]

Hi Andrew,

On 23/05/2016 15:38, Andrew Cooper wrote:

On 23/05/16 15:17, Julien Grall wrote:

The new document will help to keep track of all the erratum that Xen is
able to handle.


Just a grammar nit (which most native English speakers get wrong, given
its Latin roots)

An erratum, or Many errata.


I know about that. I was not sure whether it is "all + plural" or "all + 
singular".


In this case, I would suggest "... to keep track of each erratum Xen is
able to handle."


I will update the commmit message.

Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/4] dma-mapping: Constify dma_attrs

[Christoph Hellwig]

I think this is moving into the wrong direction.  The right fix here
is to get of all the dma_attrs boilerplate code and just replace it
with a simple enum dma_flags.  This would simplify both the callers
and most importantly the wrappers for the flag-less versions a lot.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 02/10] IOMMU: handle IOMMU mapping and unmapping failures

[Xu, Quan]

On May 23, 2016 9:41 PM, Jan Beulich  wrote:
> >>> On 18.05.16 at 10:08,  wrote:
> > No spamming can occur.
> 
> May I suggest "No spamming of the log can occur", to set some context for
> what follows?
> 

Make sense.

> > --- a/xen/drivers/passthrough/iommu.c
> > +++ b/xen/drivers/passthrough/iommu.c
> > @@ -240,21 +240,49 @@ int iommu_map_page(struct domain *d,
> unsigned long gfn, unsigned long mfn,
> > unsigned int flags)  {
> >  const struct domain_iommu *hd = dom_iommu(d);
> > +int rc;
> >
> >  if ( !iommu_enabled || !hd->platform_ops )
> >  return 0;
> >
> > -return hd->platform_ops->map_page(d, gfn, mfn, flags);
> > +rc = hd->platform_ops->map_page(d, gfn, mfn, flags);
> > +
> > +if ( unlikely(rc) )
> 
> A more general word on the use of blank lines: I think their use is well 
> advised
> to separate logically (mostly) independent steps. In cases like this, where 
> you
> check the return value of a function, the two things really belong together
> imo. Using too little blank lines negatively affects readability, but using 
> too
> many easily leads to not seeing enough context anymore when looking at
> some code fragment.
> 

I will also apply it to other patches.

> > +{
> > +if ( !d->is_shutting_down && printk_ratelimit() )
> > +printk(XENLOG_ERR
> > +   "d%d: IOMMU mapping gfn %#lx mfn %#lx failed %d.",
> 
> I really dislike having to repeat this yet another time: No stops in log 
> messages
> please. Also to the reader of the log it would be unclear what the number at
> the end represents. May I suggest
> 
> printk(XENLOG_ERR
>"d%d: IOMMU mapping gfn %#lx to mfn %#lx failed: %d",
>d->domain_id, gfn, mfn, rc);
> 
> (arguably one might then also remove the words "gfn" and "mfn").
> 

To me, we are better not to remove 'gfn' / 'mfn', but I really need to add a 
'\n'.. then

printk(XENLOG_ERR
   "d%d: IOMMU mapping gfn %#lx to mfn %#lx failed: %d\n",
   d->domain_id, gfn, mfn, rc);


Quan

> Apart from these cosmetic issues I think this is fine now.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 05/10] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU mapping.

[Jan Beulich]

>>> On 24.05.16 at 11:01,  wrote:
> On May 23, 2016 11:53 PM, Jan Beulich  wrote:
>> >>> On 18.05.16 at 10:08,  wrote:
>> > Propagate the IOMMU Device-TLB flush error up to IOMMU mapping.
>> 
>> Btw - there's little reason to repeat the title here.
>> 
> 
> I'll drop it.
> 
> Can I apply it to  other patches?

You mean dropping a description that simply repeats the title - yes,
of course. Even better would of course be, where meaningful, if
you added actual descriptions.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 07/16] x86/boot: create *.lnk files with linker script

[Jan Beulich]

>>> On 15.04.16 at 14:33,  wrote:
> --- /dev/null
> +++ b/xen/arch/x86/boot/build32.lds
> @@ -0,0 +1,49 @@
> +/*
> + * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
> + *  Daniel Kiper 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program.  If not, see .
> + */
> +
> +ENTRY(_start)
> +
> +SECTIONS
> +{
> +  /* Merge code and data into one section. */
> +  .text : {
> +*(.text)
> +*(.text.*)
> +*(.rodata)

This (and the respective %.lnk rule change below) is not in line with
the patch description. It's further suspicious that you only handle
.rodata but not also .rodata.* here.

> +  }
> +
> +  /DISCARD/ : {
> +/*
> + * .got.plt section is used only by dynamic linker
> + * and our output is not supposed to be loaded by
> + * dynamic linker. Additionally, it just contains
> + * .PLT0 which is referenced from nowhere. So, we
> + * can safely drop .got.plt here.
> + *
> + * Ha! This should be really discarded here. However,
> + * .got.plt section contains _GLOBAL_OFFSET_TABLE_
> + * symbol too and it is used as a reference for relative
> + * addressing (and only for that thing). Hence, ld
> + * complains if we remove that section because it
> + * cannot find _GLOBAL_OFFSET_TABLE_. So, drop .got.plt
> + * section during conversion to plain binary format.
> + * Please check build32.mk for more details.
> + */
> +/* *(.got.plt) */
> +  }

I'm afraid this needs more investigation: Afaik there should be no
reason for the linker to create an otherwise empty .got.plt in the
first place. And discarding it without being sure it is empty is not
that good an idea anyway.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 05/10] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU mapping.

[Xu, Quan]

On May 23, 2016 11:53 PM, Jan Beulich  wrote:
> >>> On 18.05.16 at 10:08,  wrote:
> > Propagate the IOMMU Device-TLB flush error up to IOMMU mapping.
> 
> Btw - there's little reason to repeat the title here.
> 

I'll drop it.

Can I apply it to  other patches?


> > @@ -295,12 +297,23 @@ static void __hwdom_init
> amd_iommu_hwdom_init(struct domain *d)
> >   * a pfn_valid() check would seem desirable here.
> >   */
> >  if ( mfn_valid(pfn) )
> > -amd_iommu_map_page(d, pfn, pfn,
> > -   IOMMUF_readable|IOMMUF_writable);
> > +{
> > +int ret;
> > +
> > +ret = amd_iommu_map_page(d, pfn, pfn,
> > +
> > + IOMMUF_readable|IOMMUF_writable);
> > +
> > +if ( unlikely(ret) )
> > +rc = ret;
> > +}
> 
> So you do the adjustment needed to add __must_check to
> amd_iommu_map_page(), but you don't actually add the annotation.
> Is there a reason for this?
>

Sorry, I missed it.
I really need a __must_check to amd_iommu_map_page() in 
include/asm-x86/hvm/svm/amd-iommu-proto.h.


 
> And of course the comment to an earlier patch applies regarding which error
> to return.

I'll apply it to all of my patch set.

Quan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 12/15] xen/arm: arm64: Add Cortex-A53 cache errata workaround

[Julien Grall]

Hello,

Please configure your e-mail client to quote properly.

On 24/05/2016 03:46, Chenxiao Zhao wrote:

On Mon, May 23, 2016 at 7:22 AM Julien Grall > wrote:
 /*
+<<< HEAD
+===
+ * icache_line_size - get the minimum I-cache line size from the
CTR register.
+ */
+   .macro  icache_line_size, reg, tmp
+   mrs \tmp, ctr_el0   // read CTR
+   and \tmp, \tmp, #0xf// cache line size
encoding
+   mov \reg, #4// bytes per word
+   lsl \reg, \reg, \tmp// actual cache line
size
+   .endm
+
+/*
+ * flush_icache_range(start,end)
+ *
+ * Ensure that the I and D caches are coherent within specified
region.
+ * This is typically used when code has been written to a
memory region,
+ * and will be executed.
+ *
+ * - start   - virtual start address of region
+ * - end - virtual end address of region
+ */
+ENTRY(flush_icache_range)
+   dcache_line_size x2, x3
+   sub x3, x2, #1
+   bic x4, x0, x3
+1:
+alternative_if_not ARM64_WORKAROUND_CLEAN_CACHE
+   dc  cvau, x4
+alternative_else
+   dc  civac, x4
+alternative_endif
+   add x4, x4, x2
+   cmp x4, x1
+   b.lo1b
+   dsb ish
+
+   icache_line_size x2, x3
+   sub x3, x2, #1
+   bic x4, x0, x3
+1:
+   ic  ivau, x4// invalidate I line PoU
+   add x4, x4, x2
+   cmp x4, x1
+   b.lo1b
+   dsb ish
+   isb
+   mov x0, #0
+   ret
+ENDPROC(flush_icache_range)
+
+/*
+>>> 3b39ae7... xen/arm: arm64: Add Cortex-A53 cache errata

workaround



This patch has a conflict, only can patched manually.


Whilst this patch contain a conflict because I have not rebased 
correctly, it applies without any issue and compile on ARM64.


This is because  are part of the comments. I will sent a new version 
of this patch.


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [ovmf test] 94731: all pass - PUSHED

[osstest service owner]

flight 94731 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94731/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 3e43396b3506b9fdaf71ffb69ed160f2e108894b
baseline version:
 ovmf 60c809f3621039bb1ac6b4c1947baf5a848814b0

Last test of basis94727  2016-05-23 20:42:51 Z0 days
Testing same since94731  2016-05-23 23:13:58 Z0 days1 attempts


People who touched revisions under test:
  Maurice Ma 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=ovmf
+ revision=3e43396b3506b9fdaf71ffb69ed160f2e108894b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
3e43396b3506b9fdaf71ffb69ed160f2e108894b
+ branch=ovmf
+ revision=3e43396b3506b9fdaf71ffb69ed160f2e108894b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' x3e43396b3506b9fdaf71ffb69ed160f2e108894b = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 

Re: [Xen-devel] [PATCH v5 06/10] IOMMU/MMU: propagate IOMMU Device-TLB flush error up to iommu_iotlb_flush{, _all} (top level ones).

[Xu, Quan]

On May 24, 2016 4:34 PM, Jan Beulich  wrote:
> but indeed if you
> drop the annotations from non-IOMMU functions (unless, as said, you mean
> to also add them further up the call trees), then I think things should be
> coming close.
> 

I'll drop the annotations from non-IOMMU functions.
Quan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 03/16] x86/boot: call reloc() using cdecl calling convention

[Jan Beulich]

>>> On 15.04.16 at 14:33,  wrote:
> --- a/xen/arch/x86/boot/reloc.c
> +++ b/xen/arch/x86/boot/reloc.c
> @@ -10,15 +10,25 @@
>   *Keir Fraser 
>   */
>  
> -/* entered with %eax = BOOT_TRAMPOLINE */
> +/*
> + * This entry point is entered from xen/arch/x86/boot/head.S with:
> + *   - 0x4(%esp) = MULTIBOOT_INFORMATION_ADDRESS,
> + *   - 0x8(%esp) = BOOT_TRAMPOLINE_ADDRESS.
> + */
>  asm (
>  ".text \n"
>  ".globl _start \n"
>  "_start:   \n"
> +"push %ebp \n"
> +"mov  %esp,%ebp\n"
>  "call 1f   \n"
> -"1:  pop  %ebx \n"
> -"mov  %eax,alloc-1b(%ebx)  \n"
> -"jmp  reloc\n"
> +"1:  pop  %ecx \n"
> +"mov  0xc(%ebp),%eax   \n"
> +"mov  %eax,alloc-1b(%ecx)  \n"
> +"push 0x8(%ebp)\n"
> +"call reloc\n"
> +"leave \n"
> +"ret   \n"
>  );

If Andrew's suggestion to remove this asm() altogether doesn't
work out, then I do not see justification for adding a frame
pointer here - addressing through %esp should be quite fine.
Which in turn would eliminate the need to convert jmp to call.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 1/4] dma-mapping: Constify attrs passed to dma_get_attr

[Krzysztof Kozlowski]

The dma_get_attr() does not modify passed dma_attrs so the pointer can
point to const data.

Signed-off-by: Krzysztof Kozlowski 
---
 include/linux/dma-attrs.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/linux/dma-attrs.h b/include/linux/dma-attrs.h
index 5246239a4953..f3c5aeadb100 100644
--- a/include/linux/dma-attrs.h
+++ b/include/linux/dma-attrs.h
@@ -60,7 +60,8 @@ static inline void dma_set_attr(enum dma_attr attr, struct 
dma_attrs *attrs)
  * @attr: attribute to set
  * @attrs: struct dma_attrs (may be NULL)
  */
-static inline int dma_get_attr(enum dma_attr attr, struct dma_attrs *attrs)
+static inline int dma_get_attr(enum dma_attr attr,
+  const struct dma_attrs *attrs)
 {
if (attrs == NULL)
return 0;
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 3/4] arm64: dma-mapping: Constify attrs passed to internal functions

[Krzysztof Kozlowski]

Some of the non-exported functions do not modify passed dma_attrs so the
pointer can point to const data.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm64/mm/dma-mapping.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index c566ec83719f..0ef620a34c4e 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -29,7 +29,7 @@
 
 #include 
 
-static pgprot_t __get_dma_pgprot(struct dma_attrs *attrs, pgprot_t prot,
+static pgprot_t __get_dma_pgprot(const struct dma_attrs *attrs, pgprot_t prot,
 bool coherent)
 {
if (!coherent || dma_get_attr(DMA_ATTR_WRITE_COMBINE, attrs))
@@ -88,7 +88,7 @@ static int __free_from_pool(void *start, size_t size)
 
 static void *__dma_alloc_coherent(struct device *dev, size_t size,
  dma_addr_t *dma_handle, gfp_t flags,
- struct dma_attrs *attrs)
+ const struct dma_attrs *attrs)
 {
if (dev == NULL) {
WARN_ONCE(1, "Use an actual device structure for DMA 
allocation\n");
@@ -118,7 +118,7 @@ static void *__dma_alloc_coherent(struct device *dev, 
size_t size,
 
 static void __dma_free_coherent(struct device *dev, size_t size,
void *vaddr, dma_addr_t dma_handle,
-   struct dma_attrs *attrs)
+   const struct dma_attrs *attrs)
 {
bool freed;
phys_addr_t paddr = dma_to_phys(dev, dma_handle);
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/4] ARM: dma-mapping: Constify attrs passed to internal functions

[Russell King - ARM Linux]

On Tue, May 24, 2016 at 08:28:08AM +0200, Krzysztof Kozlowski wrote:
> Some of the non-exported functions do not modify passed dma_attrs so the
> pointer can point to const data.
> 
> Signed-off-by: Krzysztof Kozlowski 

Acked-by: Russell King 

Thanks.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 0/4] dma-mapping: Constify dma_attrs

[Krzysztof Kozlowski]

Hi,

The patchset is divided into two parts:
1. (patch 1-3): Constify dma_attrs passed to some of functions. The
   first patch is a dependency for all other. This is not intrusive.

2. patch 4: request for comments, constify dma_attrs everywhere (struct
   dma_map_ops and implementations).
   Constness may protect from certain coding bugs and, what is more
   important, is a direct documentation of how the core deals
   with passed data. Some of the dma-mapping users allocate attrs
   on the stack so the ownership cannot be transferred. 'Const' here
   means exactly that - the ownership stays with the caller.

   Unfortunately this cannot be done separately per-implementation
   without introducing build warnings so the patch touches multiple
   subsystems. Maybe using some casts in intermediate steps might help
   splitting it into separate patches?

   This is not finished because there is no point of my effort if
   I will hear short NACK soon. :)

Comments are welcomed.

Best regards,
Krzysztof

Krzysztof Kozlowski (4):
  dma-mapping: Constify attrs passed to dma_get_attr
  ARM: dma-mapping: Constify attrs passed to internal functions
  arm64: dma-mapping: Constify attrs passed to internal functions
  dma-mapping: Constify dma_attrs

 arch/arm/include/asm/dma-mapping.h | 12 +++---
 arch/arm/mm/dma-mapping.c  | 87 --
 arch/arm/xen/mm.c  |  4 +-
 arch/arm64/mm/dma-mapping.c| 53 +++
 drivers/iommu/dma-iommu.c  |  6 +--
 include/linux/dma-attrs.h  |  3 +-
 include/linux/dma-iommu.h  |  6 +--
 include/linux/dma-mapping.h| 34 ---
 include/linux/swiotlb.h|  9 ++--
 lib/dma-noop.c |  9 ++--
 lib/swiotlb.c  |  9 ++--
 11 files changed, 123 insertions(+), 109 deletions(-)

-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 2/4] ARM: dma-mapping: Constify attrs passed to internal functions

[Krzysztof Kozlowski]

Some of the non-exported functions do not modify passed dma_attrs so the
pointer can point to const data.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/mm/dma-mapping.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ff7ed5697d3e..4abc50952451 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -621,7 +621,7 @@ static void __free_from_contiguous(struct device *dev, 
struct page *page,
dma_release_from_contiguous(dev, page, size >> PAGE_SHIFT);
 }
 
-static inline pgprot_t __get_dma_pgprot(struct dma_attrs *attrs, pgprot_t prot)
+static inline pgprot_t __get_dma_pgprot(const struct dma_attrs *attrs, 
pgprot_t prot)
 {
prot = dma_get_attr(DMA_ATTR_WRITE_COMBINE, attrs) ?
pgprot_writecombine(prot) :
@@ -732,7 +732,7 @@ static struct arm_dma_allocator remap_allocator = {
 
 static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
 gfp_t gfp, pgprot_t prot, bool is_coherent,
-struct dma_attrs *attrs, const void *caller)
+const struct dma_attrs *attrs, const void *caller)
 {
u64 mask = get_coherent_dma_mask(dev);
struct page *page = NULL;
@@ -878,7 +878,7 @@ int arm_dma_mmap(struct device *dev, struct vm_area_struct 
*vma,
  * Free a buffer as defined by the above mapping.
  */
 static void __arm_dma_free(struct device *dev, size_t size, void *cpu_addr,
-  dma_addr_t handle, struct dma_attrs *attrs,
+  dma_addr_t handle, const struct dma_attrs *attrs,
   bool is_coherent)
 {
struct page *page = pfn_to_page(dma_to_pfn(dev, handle));
@@ -1253,7 +1253,8 @@ static inline void __free_iova(struct dma_iommu_mapping 
*mapping,
 static const int iommu_order_array[] = { 9, 8, 4, 0 };
 
 static struct page **__iommu_alloc_buffer(struct device *dev, size_t size,
- gfp_t gfp, struct dma_attrs *attrs)
+ gfp_t gfp,
+ const struct dma_attrs *attrs)
 {
struct page **pages;
int count = size >> PAGE_SHIFT;
@@ -1342,7 +1343,7 @@ error:
 }
 
 static int __iommu_free_buffer(struct device *dev, struct page **pages,
-  size_t size, struct dma_attrs *attrs)
+  size_t size, const struct dma_attrs *attrs)
 {
int count = size >> PAGE_SHIFT;
int i;
@@ -1439,7 +1440,8 @@ static struct page **__atomic_get_pages(void *addr)
return (struct page **)page;
 }
 
-static struct page **__iommu_get_pages(void *cpu_addr, struct dma_attrs *attrs)
+static struct page **__iommu_get_pages(void *cpu_addr,
+  const struct dma_attrs *attrs)
 {
struct vm_struct *area;
 
@@ -1633,8 +1635,8 @@ static int __dma_direction_to_prot(enum 
dma_data_direction dir)
  */
 static int __map_sg_chunk(struct device *dev, struct scatterlist *sg,
  size_t size, dma_addr_t *handle,
- enum dma_data_direction dir, struct dma_attrs *attrs,
- bool is_coherent)
+ enum dma_data_direction dir,
+ const struct dma_attrs *attrs, bool is_coherent)
 {
struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
dma_addr_t iova, iova_base;
@@ -1676,8 +1678,8 @@ fail:
 }
 
 static int __iommu_map_sg(struct device *dev, struct scatterlist *sg, int 
nents,
-enum dma_data_direction dir, struct dma_attrs *attrs,
-bool is_coherent)
+enum dma_data_direction dir,
+const struct dma_attrs *attrs, bool is_coherent)
 {
struct scatterlist *s = sg, *dma = sg, *start = sg;
int i, count = 0;
@@ -1758,8 +1760,8 @@ int arm_iommu_map_sg(struct device *dev, struct 
scatterlist *sg,
 }
 
 static void __iommu_unmap_sg(struct device *dev, struct scatterlist *sg,
-   int nents, enum dma_data_direction dir, struct dma_attrs *attrs,
-   bool is_coherent)
+   int nents, enum dma_data_direction dir,
+   const struct dma_attrs *attrs, bool is_coherent)
 {
struct scatterlist *s;
int i;
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [RFC 4/4] dma-mapping: Constify dma_attrs

[Krzysztof Kozlowski]

Pointer to dma_attrs passed to all dma-mapping implementations can point
to const data. This brings some benefits:
 - const-safeness,
 - is a direct indication that ownership of memory is not transferred to
   called functions so it can be safely allocated on the stack (which is
   a pattern already used).

Please have in mind that this is RFC, not finished yet. Only ARM and
ARM64 are fixed. However other API users also have to be converted which
is quite intrusive. I would rather avoid it until the overall approach
is accepted.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/include/asm/dma-mapping.h | 12 
 arch/arm/mm/dma-mapping.c  | 61 +-
 arch/arm/xen/mm.c  |  4 +--
 arch/arm64/mm/dma-mapping.c| 47 +++--
 drivers/iommu/dma-iommu.c  |  6 ++--
 include/linux/dma-iommu.h  |  6 ++--
 include/linux/dma-mapping.h| 34 +++--
 include/linux/swiotlb.h|  9 +++---
 lib/dma-noop.c |  9 +++---
 lib/swiotlb.c  |  9 +++---
 10 files changed, 104 insertions(+), 93 deletions(-)

diff --git a/arch/arm/include/asm/dma-mapping.h 
b/arch/arm/include/asm/dma-mapping.h
index a83570f10124..07202beed663 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -174,7 +174,7 @@ static inline void dma_mark_clean(void *addr, size_t size) 
{ }
  * to be the device-viewed address.
  */
 extern void *arm_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
-  gfp_t gfp, struct dma_attrs *attrs);
+  gfp_t gfp, const struct dma_attrs *attrs);
 
 /**
  * arm_dma_free - free memory allocated by arm_dma_alloc
@@ -191,7 +191,7 @@ extern void *arm_dma_alloc(struct device *dev, size_t size, 
dma_addr_t *handle,
  * during and after this call executing are illegal.
  */
 extern void arm_dma_free(struct device *dev, size_t size, void *cpu_addr,
-dma_addr_t handle, struct dma_attrs *attrs);
+dma_addr_t handle, const struct dma_attrs *attrs);
 
 /**
  * arm_dma_mmap - map a coherent DMA allocation into user space
@@ -208,7 +208,7 @@ extern void arm_dma_free(struct device *dev, size_t size, 
void *cpu_addr,
  */
 extern int arm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
-   struct dma_attrs *attrs);
+   const struct dma_attrs *attrs);
 
 /*
  * This can be called during early boot to increase the size of the atomic
@@ -262,16 +262,16 @@ extern void dmabounce_unregister_dev(struct device *);
  * The scatter list versions of the above methods.
  */
 extern int arm_dma_map_sg(struct device *, struct scatterlist *, int,
-   enum dma_data_direction, struct dma_attrs *attrs);
+   enum dma_data_direction, const struct dma_attrs *attrs);
 extern void arm_dma_unmap_sg(struct device *, struct scatterlist *, int,
-   enum dma_data_direction, struct dma_attrs *attrs);
+   enum dma_data_direction, const struct dma_attrs *attrs);
 extern void arm_dma_sync_sg_for_cpu(struct device *, struct scatterlist *, int,
enum dma_data_direction);
 extern void arm_dma_sync_sg_for_device(struct device *, struct scatterlist *, 
int,
enum dma_data_direction);
 extern int arm_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
-   struct dma_attrs *attrs);
+   const struct dma_attrs *attrs);
 
 #endif /* __KERNEL__ */
 #endif
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 4abc50952451..245954e7e343 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -124,7 +124,7 @@ static void __dma_page_dev_to_cpu(struct page *, unsigned 
long,
  */
 static dma_addr_t arm_dma_map_page(struct device *dev, struct page *page,
 unsigned long offset, size_t size, enum dma_data_direction dir,
-struct dma_attrs *attrs)
+const struct dma_attrs *attrs)
 {
if (!dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
__dma_page_cpu_to_dev(page, offset, size, dir);
@@ -133,7 +133,7 @@ static dma_addr_t arm_dma_map_page(struct device *dev, 
struct page *page,
 
 static dma_addr_t arm_coherent_dma_map_page(struct device *dev, struct page 
*page,
 unsigned long offset, size_t size, enum dma_data_direction dir,
-struct dma_attrs *attrs)
+const struct dma_attrs *attrs)
 {
return pfn_to_dma(dev, page_to_pfn(page)) + offset;
 }
@@ -154,7 +154,7 @@ static dma_addr_t arm_coherent_dma_map_page(struct device 
*dev, struct page *pag
  */
 static void arm_dma_unmap_page(struct device *dev, dma_addr_t handle,

Re: [Xen-devel] [PATCH v5 06/10] IOMMU/MMU: propagate IOMMU Device-TLB flush error up to iommu_iotlb_flush{, _all} (top level ones).

[Jan Beulich]

>>> On 24.05.16 at 10:11,  wrote:
> I thought the IOMMU / MM boundary is the MM functions (high level callers) 
> which call iommu_* interfaces (such as,  iommu_map_page / iommu_unmap_page / 
> iommu_iotlb_flush ...).

Exactly - the boundary is _in_ those MM functions, at the points where
they call IOMMU ones.

> For this case, the xenmem_add_to_physmap() indeed calls iommu_iotlb_flush(), 
>  but xenmem_add_to_physmap() may be hypervisor interface, instead of MM 
> interface.
> 
> If I drop this __must_check and fix patch 3 / patch 5, then I think 
> __must_check would not be a block issue.

Not sure what "a block issue" is supposed to mean here, but indeed
if you drop the annotations from non-IOMMU functions (unless, as
said, you mean to also add them further up the call trees), then I
think things should be coming close.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel