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

2016-05-27 Thread osstest service owner 
flight 94852 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94852/

Failures :-/ but no regressions.

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

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-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-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-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-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-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-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  55dc7f61260f4becc6c5e52a8155a6b8741c03cc
baseline version:
 xen  f5610009529628314c9d1d52b00715fe855fcf06

Last test of basis94816  2016-05-27 04:21:11 Z1 days
Testing same since94852  2016-05-27 19:13:18 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Haozhong Zhang 

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

[Xen-devel] [PATCH 1/1] xsplice-build-tools: replace realpath with readlink in xsplice-build

2016-05-27 Thread Dongli Zhang 
Replace realpath with readlink since '-m' option is not supported by realpath.

Signed-off-by: Dongli Zhang 
---
 xsplice-build | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xsplice-build b/xsplice-build
index 2eb7993..5852186 100755
--- a/xsplice-build
+++ b/xsplice-build
@@ -213,7 +213,7 @@ while [[ $# -gt 0 ]]; do
 ;;
 --xen-syms)
 shift
-XENSYMS="$(realpath -m -- "$1")"
+XENSYMS="$(readlink -m -- "$1")"
 [ -f "$XENSYMS" ] || die "xen-syms file does not exist"
 shift
 ;;
@@ -238,9 +238,9 @@ done
 [ -z "$outputarg" ] && die "Output directory not given"
 [ -z "$DEPENDS" ] && die "Build-id dependency not given"
 
-SRCDIR="$(realpath -m -- "$srcarg")"
-PATCHFILE="$(realpath -m -- "$patcharg")"
-OUTPUT="$(realpath -m -- "$outputarg")"
+SRCDIR="$(readlink -m -- "$srcarg")"
+PATCHFILE="$(readlink -m -- "$patcharg")"
+OUTPUT="$(readlink -m -- "$outputarg")"
 
 [ -d "${SRCDIR}" ] || die "Xen directory does not exist"
 [ -f "${PATCHFILE}" ] || die "Patchfile does not exist"
-- 
1.9.1


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

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

2016-05-27 Thread osstest service owner 
flight 94833 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94833/

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
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 94748

version targeted for testing:
 ovmf 27a4059387dc46e0f83faacb30d8ff6fa5b3eb96
baseline version:
 ovmf dc99315b8732b6e3032d01319d3f534d440b43d0

Last test of basis94748  2016-05-24 22:43:25 Z3 days
Failing since 94750  2016-05-25 03:43:08 Z2 days8 attempts
Testing same since94833  2016-05-27 10:56:46 Z0 days1 attempts


People who touched revisions under test:
  Dandan Bi 
  Darbin Reyes 
  Gary Lin 
  Hao Wu 
  Jiaxin Wu 
  Laszlo Ersek 
  Liming Gao 
  Marvin H?user 
  Marvin Haeuser 
  Michael Zimmermann 
  Yonghong Zhu 

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 fail
 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.

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

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

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

2016-05-27 Thread osstest service owner 
flight 94849 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94849/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  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-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 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-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
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 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  111 days
Testing same since93977  2016-05-10 11:09:16 Z   17 days   69 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-4.6-testing test] 94837: regressions - FAIL

2016-05-27 Thread osstest service owner 
flight 94837 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94837/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
94709

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94709
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 94709
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94709
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 94709
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 94709

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   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-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 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-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 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
 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-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  ab2d455dcd06d19b4f6755bf406ee7302e879c02
baseline version:
 xen  1e3e9447460037d125014fe4eb5b3172b130663c

Last test of basis94709  2016-05-22 15:13:22 Z5 days
Testing same since94837  2016-05-27 13:09:46 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  George Dunlap 
  Jan Beulich 
  Julien Grall 

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-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops

Re: [Xen-devel] [PATCH] xen: remove incorrect forward declaration

2016-05-27 Thread Arnd Bergmann 
On Thursday, May 26, 2016 11:32:40 AM CEST David Vrabel wrote:
> On 11/05/16 14:07, Arnd Bergmann wrote:
> > A bugfix patch for the xen balloon driver introduced a forward
> > declaration for a static function that is conditionally compiled,
> > causing a warning if only the declaration but not the definition
> > are there:
> > 
> > drivers/xen/balloon.c:154:13: error: 'release_memory_resource' declared 
> > 'static' but never defined [-Werror=unused-function]
> >  static void release_memory_resource(struct resource *resource);
> > 
> > This removes the declaration again and instead moves the function
> > definition to the right place, before its first caller and inside
> > of the #ifdef protecting both.
> 
> I've applied the equivalent patch from Ross, instead.

Ok, thanks.

> > The patch that introduced the warning is marked for stable
> > backports, so if that gets applied to 4.4, so should this one.
> 
> Fixes for compiler warnings are not sufficiently important to be
> backported to stable.

Sure, but this is not an existing warning but one that only gets
introduced after the other patch gets backported, which I'd consider
a different category.

Arnd

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

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

2016-05-27 Thread osstest service owner 
flight 94851 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94851/

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  5ff371e9d87f468bf73acfafd65ba5a0d1b7bd4f
baseline version:
 xen  55dc7f61260f4becc6c5e52a8155a6b8741c03cc

Last test of basis94844  2016-05-27 16:01:45 Z0 days
Testing same since94851  2016-05-27 19:01:55 Z0 days1 attempts


People who touched revisions under test:
  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=5ff371e9d87f468bf73acfafd65ba5a0d1b7bd4f
+ . ./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 
5ff371e9d87f468bf73acfafd65ba5a0d1b7bd4f
+ branch=xen-unstable-smoke
+ revision=5ff371e9d87f468bf73acfafd65ba5a0d1b7bd4f
+ . ./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
+ '[' x5ff371e9d87f468bf73acfafd65ba5a0d1b7bd4f = 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-mainline test] 94821: tolerable trouble: broken/fail/pass - PUSHED

2016-05-27 Thread osstest service owner 
flight 94821 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94821/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl   3 host-install(3)   broken pass in 94808
 test-amd64-amd64-amd64-pvgrub  3 host-install(3)  broken pass in 94808
 test-amd64-i386-libvirt   3 host-install(3)   broken pass in 94808
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken 
pass in 94808
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)broken pass in 94808
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail in 94808 pass 
in 94821

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt  12 migrate-support-check fail in 94808 never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 94808 never pass
 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-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 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-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 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
 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-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 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

version targeted for testing:
 qemuu84cfc756d158a061bd462473d42b0a9f072218de
baseline version:
 qemuu287db79df8af8e31f18e262feb5e05103a09e4d4

Last test of basis94743  2016-05-24 16:40:55 Z3 days
Failing since 94795  2016-05-26 12:49:04 Z1 days3 attempts
Testing same since94808  2016-05-26 22:18:23 Z0 days2 attempts


People who touched revisions under test:
  Alberto Garcia 
  Alex Williamson 
  Alexey Kardashevskiy 
  Amit Shah 
  Andreas Färber 
  Andreas Färber 
  Daniel P. Berrange 
  Eric Blake 
  Gerd Hoffmann 
  John Snow 
  Juan Quintela 
  Kevin Wolf 
  Max Filippov 
  Max Reitz 
  Paolo Bonzini 
  Peter Maydell 
  Sergey Fedorov

[Xen-devel] [PATCH] xen: xenbus: Remove create_workqueue

2016-05-27 Thread Bhaktipriya Shridhar 
With concurrency managed workqueues, use of dedicated workqueues can be
replaced by using system_wq. Drop xenbus_frontend_wq by using system_wq.

Since there is only a single work item, increase of concurrency level by
switching to system_wq should not break anything.

Since the work item could be pending and the code expects it to run
once scheduled, flush_work() has been used in xenbus_dev_suspend()

Signed-off-by: Bhaktipriya Shridhar 
---
 drivers/xen/xenbus/xenbus_probe.c  |  2 ++
 drivers/xen/xenbus/xenbus_probe_frontend.c | 15 +--
 2 files changed, 3 insertions(+), 14 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_probe.c 
b/drivers/xen/xenbus/xenbus_probe.c
index 33a31cf..bc97019 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -592,6 +592,8 @@ int xenbus_dev_suspend(struct device *dev)

DPRINTK("%s", xdev->nodename);

+   cancel_work_sync(>work);
+
if (dev->driver == NULL)
return 0;
drv = to_xenbus_driver(dev->driver);
diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c 
b/drivers/xen/xenbus/xenbus_probe_frontend.c
index bcb53bd..611a231 100644
--- a/drivers/xen/xenbus/xenbus_probe_frontend.c
+++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
@@ -31,7 +31,6 @@
 #include "xenbus_probe.h"


-static struct workqueue_struct *xenbus_frontend_wq;

 /* device// => - */
 static int frontend_bus_id(char bus_id[XEN_BUS_ID_SIZE], const char *nodename)
@@ -109,13 +108,7 @@ static int xenbus_frontend_dev_resume(struct device *dev)
if (xen_store_domain_type == XS_LOCAL) {
struct xenbus_device *xdev = to_xenbus_device(dev);

-   if (!xenbus_frontend_wq) {
-   pr_err("%s: no workqueue to process delayed resume\n",
-  xdev->nodename);
-   return -EFAULT;
-   }
-
-   queue_work(xenbus_frontend_wq, >work);
+   schedule_work(>work);

return 0;
}
@@ -485,12 +478,6 @@ static int __init xenbus_probe_frontend_init(void)

register_xenstore_notifier(_notifier);

-   if (xen_store_domain_type == XS_LOCAL) {
-   xenbus_frontend_wq = create_workqueue("xenbus_frontend");
-   if (!xenbus_frontend_wq)
-   pr_warn("create xenbus frontend workqueue failed, S3 
resume is likely to fail\n");
-   }
-
return 0;
 }
 subsys_initcall(xenbus_probe_frontend_init);
--
2.1.4


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

[Xen-devel] [xen-4.5-testing test] 94838: regressions - FAIL

2016-05-27 Thread osstest service owner 
flight 94838 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94838/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 
94707

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-localmigrate fail REGR. vs. 94707
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 94707
 test-amd64-amd64-libvirt-vhd 13 guest-saverestorefail   like 94682
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 94707
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 94707
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 94707
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94707

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 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   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-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-vhd  10 guest-start  fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 10 guest-start  fail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  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-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 10 guest-start  fail 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-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  524a93d1fa33d18f09004592bde22a4e8409b7f8
baseline version:
 xen  ffda547469694ff22b6c8d0bc23436c9b4ce84ec

Last test of basis94707  2016-05-22 12:40:52 Z5 days
Testing same since94838  2016-05-27 13:08:50 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  George Dunlap 
  Jan Beulich 
  Julien Grall 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass

[Xen-devel] [PATCH] xen: xen-pciback: Remove create_workqueue

2016-05-27 Thread Bhaktipriya Shridhar 
With concurrency managed workqueues, use of dedicated workqueues can be
replaced by using system_wq. Drop host->intr_wq by using
system_wq.

Since there is only a single work item, increase of concurrency level by
switching to system_wq should not break anything.

cancel_work_sync() has been used in xen_pcibk_disconnect() to ensure that
work item is not pending or executing by the time exit path runs.

Signed-off-by: Bhaktipriya Shridhar 
---
 drivers/xen/xen-pciback/pciback.h |  1 -
 drivers/xen/xen-pciback/pciback_ops.c |  2 +-
 drivers/xen/xen-pciback/xenbus.c  | 10 +-
 3 files changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/xen/xen-pciback/pciback.h 
b/drivers/xen/xen-pciback/pciback.h
index 4d529f3..7af369b6 100644
--- a/drivers/xen/xen-pciback/pciback.h
+++ b/drivers/xen/xen-pciback/pciback.h
@@ -55,7 +55,6 @@ struct xen_pcibk_dev_data {

 /* Used by XenBus and xen_pcibk_ops.c */
 extern wait_queue_head_t xen_pcibk_aer_wait_queue;
-extern struct workqueue_struct *xen_pcibk_wq;
 /* Used by pcistub.c and conf_space_quirks.c */
 extern struct list_head xen_pcibk_quirks;

diff --git a/drivers/xen/xen-pciback/pciback_ops.c 
b/drivers/xen/xen-pciback/pciback_ops.c
index 2f19dd7..f8c7775 100644
--- a/drivers/xen/xen-pciback/pciback_ops.c
+++ b/drivers/xen/xen-pciback/pciback_ops.c
@@ -310,7 +310,7 @@ void xen_pcibk_test_and_schedule_op(struct xen_pcibk_device 
*pdev)
 * already processing a request */
if (test_bit(_XEN_PCIF_active, (unsigned long *)>sh_info->flags)
&& !test_and_set_bit(_PDEVF_op_active, >flags)) {
-   queue_work(xen_pcibk_wq, >op_work);
+   schedule_work(>op_work);
}
/*_XEN_PCIB_active should have been cleared by pcifront. And also make
sure xen_pcibk is waiting for ack by checking _PCIB_op_pending*/
diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index c252eb3..f70a8e1 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -17,7 +17,6 @@
 #include "pciback.h"

 #define INVALID_EVTCHN_IRQ  (-1)
-struct workqueue_struct *xen_pcibk_wq;

 static bool __read_mostly passthrough;
 module_param(passthrough, bool, S_IRUGO);
@@ -76,8 +75,7 @@ static void xen_pcibk_disconnect(struct xen_pcibk_device 
*pdev)
/* If the driver domain started an op, make sure we complete it
 * before releasing the shared memory */

-   /* Note, the workqueue does not use spinlocks at all.*/
-   flush_workqueue(xen_pcibk_wq);
+   cancel_work_sync(>op_work);

if (pdev->sh_info != NULL) {
xenbus_unmap_ring_vfree(pdev->xdev, pdev->sh_info);
@@ -733,11 +731,6 @@ const struct xen_pcibk_backend *__read_mostly 
xen_pcibk_backend;

 int __init xen_pcibk_xenbus_register(void)
 {
-   xen_pcibk_wq = create_workqueue("xen_pciback_workqueue");
-   if (!xen_pcibk_wq) {
-   pr_err("%s: create xen_pciback_workqueue failed\n", __func__);
-   return -EFAULT;
-   }
xen_pcibk_backend = _pcibk_vpci_backend;
if (passthrough)
xen_pcibk_backend = _pcibk_passthrough_backend;
@@ -747,6 +740,5 @@ int __init xen_pcibk_xenbus_register(void)

 void __exit xen_pcibk_xenbus_unregister(void)
 {
-   destroy_workqueue(xen_pcibk_wq);
xenbus_unregister_driver(_pcibk_driver);
 }
--
2.1.4


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

Re: [Xen-devel] [PATCH v3 2/9] monitor: Don't call vm_event_fill_regs from common

2016-05-27 Thread Tamas K Lengyel 
On Mon, May 16, 2016 at 3:48 AM, Julien Grall  wrote:
> Hi Tamas,
>
> On 04/05/16 15:51, Tamas K Lengyel wrote:
>>
>> The prototype of vm_event_fill_regs will differ on x86 and ARM so in this
>> patch
>> we move components from common to arch-specific that use this function. As
>> part of this patch we rename and relocate vm_event_monitor_guest_request
>> as
>> monitor_guest_request from vm_event to monitor.
>
>
> Would not it be possible to find a common prototype between ARM and x86?
>
> From patch #4, the ARM prototype is:
>
> void vm_event_fill_regs(vm_event_request_t *req,
> const struct cpu_user_regs *regs,
> struct domain *d)
>
> and the x86 one is
>
> void vm_event_fill_regs(vm_event_request_t *req);
>
> The parameter "regs" will always be equal to guest_cpu_user_regs(). And the
> domain will always be current->domain.
>
> So, IHMO, there is no need to differ between ARM and x86. This would also
> keep the code simple.
>

Yeap, you are right, I'll get rid of this patch.

Thanks,
Tamas

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

[Xen-devel] [xen-unstable test] 94816: tolerable trouble: blocked/broken/fail/pass - PUSHED

2016-05-27 Thread osstest service owner 
flight 94816 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94816/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3) broken pass in 94802
 test-amd64-amd64-xl-qemut-winxpsp3  3 host-install(3) broken pass in 94802
 test-armhf-armhf-xl-multivcpu 16 guest-start.2 fail in 94802 pass in 94816

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail REGR. vs. 94789
 build-amd64-rumpuserxen   6 xen-buildfail   like 94789
 build-i386-rumpuserxen6 xen-buildfail   like 94789
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94789
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 94789
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 94789
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 94789
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94789

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-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-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-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  f5610009529628314c9d1d52b00715fe855fcf06
baseline version:
 xen  8478c9409a2c6726208e8dbc9f3e455b76725a33

Last test of basis94789  2016-05-26 09:35:03 Z1 days
Testing same since94802  2016-05-26 19:43:08 Z0 days2 attempts


People who touched revisions under test:
  Chao Peng 
  Ian Jackson 
  Jan Beulich 
  Wei Liu 

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

[Xen-devel] [PATCH V3] arm/gic-v3: Fix ACPI probe fail on GICv4 hardware

2016-05-27 Thread Shanker Donthineni 
The current driver ACPI probe fails on hardware which has GICv4
version, even though it is fully compatible to GICv3. This patch
fixed the issue by registering the same probe function for GICv4
hardware.

Signed-off-by: Shanker Donthineni 
---
Changes since v2:
- Keep it the GICv4 version number inside driver and export outside as 
GICv3.

Changes since v1:
- Edit commit text.
- Fix BUG() in xen/arch/arm/domain.c 

 xen/arch/arm/gic-v3.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index a095064..982c632 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1608,6 +1608,11 @@ ACPI_DEVICE_START(agicv3, "GICv3", DEVICE_GIC)
 .class_type = ACPI_MADT_GIC_VERSION_V3,
 .init = gicv3_acpi_preinit,
 ACPI_DEVICE_END
+
+ACPI_DEVICE_START(agicv4, "GICv4", DEVICE_GIC)
+.class_type = ACPI_MADT_GIC_VERSION_V4,
+.init = gicv3_acpi_preinit,
+ACPI_DEVICE_END
 #endif
 
 /*
-- 
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
a Linux Foundation Collaborative Project


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

Re: [Xen-devel] [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit width support

2016-05-27 Thread Boris Ostrovsky 
On 05/27/2016 03:34 AM, Zheng, Lv wrote:
> Hi,
>
>> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
>> Subject: Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access
>> bit width support
>>
>> On 05/26/2016 12:26 PM, Jan Beulich wrote:
>> Boris Ostrovsky  05/25/16 9:17
>> PM >>>
 On 05/05/2016 12:58 AM, Lv Zheng wrote:
> +static u8
> +acpi_hw_get_access_bit_width(struct acpi_generic_address *reg, u8
>> max_bit_width)
> +{
> +u64 address;
> +
> +if (!reg->access_width) {
> +/*
> + * Detect old register descriptors where only the bit_width field
> + * makes senses. The target address is copied to handle possible
> + * alignment issues.
> + */
> +ACPI_MOVE_64_TO_64(, >address);
> +if (!reg->bit_offset && reg->bit_width &&
> +ACPI_IS_POWER_OF_TWO(reg->bit_width) &&
> +ACPI_IS_ALIGNED(reg->bit_width, 8) &&
> +ACPI_IS_ALIGNED(address, reg->bit_width)) {
> +return (reg->bit_width);
> +} else {
> +if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_IO) {
> +return (32);
 This (together with "... Add access_width/bit_offset support in
 acpi_hw_write") breaks Xen guests using older QEMU which doesn't
>> support
 4-byte IO accesses.

 Why not return "reg->bit_width?:max_bit_width" ? This will preserve
 original behavior.
>>> Did you figure out why we get here in the first place, instead of taking
>> the
>>> first "return"? I.e. isn't the issue the apparently wrong use of the second
>>> ACPI_IS_ALIGNED() above? Afaict it ought to be
>>> ACPI_IS_ALIGNED(address, reg->bit_width / 8)...
>> We are trying to access address 0x...b004 (PM1a control) so yes, fixing
>> alignment check would probably resolve the problem that we are seeing
>> now.
>>
>> However, for compatibility purposes we may consider not doing any
>> checks
>> and simply return bit_width if access_width is not available.
> [Lv Zheng] 

Your patch from earlier does resolve both issues, thanks.

> Your solution could result in problems like:
> If a GAS is defined with bit_width not a power of 2, and access_width is any 
> (0).
>
> So the correct fix here is to make sure if bit_width is exactly 8,16,32,64, 
> which matches old register descriptors.
> I added address check here because I want to limit this regression safe check 
> to old register descriptors.
> As since the old bit_width can actually reflect the register's access width, 
> the address of the register should always be aligned.
>
> There might be cases that using the new GAS register descriptor format, it is 
> possible to define a GAS that is not aligned, and it's bit_width is exactly 
> 8,16,32,64.
> We shouldn't make a default access_width decision using bit_width here.

True. But OTOH switching to 32-bit accesses may result in us suddenly
trying to touch bytes we haven't accessed before.

-boris


> The address check here can help to avoid applying this workaround on such 
> cases.
>
> Thanks and best regards
> -Lv



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

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

2016-05-27 Thread Konrad Rzeszutek Wilk 
On Fri, May 27, 2016 at 05:37:51PM +0100, Julien Grall wrote:
> Convert device-tree debugging to 'Kconfig' as
> CONFIG_DEVICE_TREE_DEBUG.
> 
> The option is not enabled by default because the output is very
> verbose.
> 
> Signed-off-by: Julien Grall 
> Reviewed-by: Edgar E. Iglesias 

Reviewed-by: Konrad Rzeszutek Wilk 
> 
> ---
> Changes in v2:
> - Fix typoes in the commit message and the Kconfig description
> - Update the Kconfig description
> - Add Edgar's reviewed-by
> 
> 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   | 8 
>  xen/arch/arm/domain_build.c | 4 +---
>  xen/common/device_tree.c| 4 +---
>  3 files changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
> index 303bf36..360c3be 100644
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -55,6 +55,14 @@ 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 are
> +   logged in the Xen ring buffer.
> +   If unsure, say N here.
> +
>  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] [libvirt bisection] complete build-i386-libvirt

2016-05-27 Thread osstest service owner 
branch xen-unstable
xenbranch xen-unstable
job build-i386-libvirt
testid libvirt-build

Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.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:  libvirt_gnulib git://git.sv.gnu.org/gnulib.git
  Bug introduced:  54615b95ff238e235e806855efc46a9abad09f2e
  Bug not present: e78f894d0bdc770101bc040613f4ea94e45f38f7
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/94847/


  commit 54615b95ff238e235e806855efc46a9abad09f2e
  Author: Paul Eggert 
  Date:   Sat Feb 6 18:11:48 2016 -0800
  
  misc: port better to gcc -fsanitize=address
  
  Without these patches, ./configure CFLAGS='-fsanitize=address'
  would compute incorrect values.  This patch fixes some (but not all)
  test failures with recent glibc, with this configuration.
  * m4/acl.m4 (gl_ACL_GET_FILE):
  * m4/calloc.m4 (_AC_FUNC_CALLOC_IF):
  * m4/canonicalize.m4 (gl_FUNC_REALPATH_WORKS):
  * m4/d-ino.m4 (gl_CHECK_TYPE_STRUCT_DIRENT_D_INO):
  * m4/duplocale.m4 (gl_FUNC_DUPLOCALE):
  * m4/getcwd.m4 (gl_FUNC_GETCWD_NULL):
  * m4/getdelim.m4 (gl_FUNC_GETDELIM):
  * m4/getgroups.m4 (gl_FUNC_GETGROUPS):
  * m4/getline.m4 (gl_FUNC_GETLINE):
  * m4/malloc.m4 (_AC_FUNC_MALLOC_IF):
  * m4/realloc.m4 (_AC_FUNC_REALLOC_IF):
  * m4/regex.m4 (gl_REGEX):
  * m4/strndup.m4 (gl_FUNC_STRNDUP):
  * tests/test-calloc-gnu.c (main):
  * tests/test-duplocale.c (main):
  * tests/test-getgroups.c (main):
  * tests/test-getline.c (main):
  * tests/test-inttostr.c (main):
  * tests/test-localename.c (test_locale_name)
  (test_locale_name_thread, test_locale_name_environ)
  (test_locale_name_default):
  * tests/test-regex.c (main):
  * tests/test-setlocale1.c (main):
  * tests/test-stat.h (test_stat_func):
  Free heap-allocated storage before exiting.
  * m4/asm-underscore.m4 (gl_ASM_SYMBOL_PREFIX):
  Don't match *_foo symbols inserted by AddressSanitizer.
  * tests/test-regex.c, tests/test-stat.c: Include stdlib.h, for 'free'.


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/libvirt/build-i386-libvirt.libvirt-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/libvirt/build-i386-libvirt.libvirt-build 
--summary-out=tmp/94847.bisection-summary --basis-template=94785 
--blessings=real,real-bisect libvirt build-i386-libvirt libvirt-build
Searching for failure / basis pass:
 94817 fail [host=pinot1] / 94785 [host=chardonnay1] 94751 [host=baroque1] 
94734 [host=huxelrebe0] 94591 [host=huxelrebe0] 94572 [host=huxelrebe1] 94539 
[host=elbling1] 94502 ok.
Failure / basis pass flights: 94817 / 94502
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.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
Latest 0cd64883dc1573c935592b64354e5a97b2bacca6 
8d807a99c6e8eecd2a9cf7c7b5d48ec0b2c934f8 
df553c056104e3dd8a2bd2e72539a57c4c085bae 
44a072f0de0d57c95c2212bbce0232b7b74f 
8478c9409a2c6726208e8dbc9f3e455b76725a33
Basis pass 0e8a72a5ef16c093181af2c22e632ae639808a1b 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
e4ceb77cf88bc44f0b7fe39225c49d660735f327 
62b3d206425c245ed0a020390a64640d40d97471 
ad4aa3619f436e3ed79eea8498ac18aa8d5e6b83
Generating revisions with ./adhoc-revtuple-generator  
git://libvirt.org/libvirt.git#0e8a72a5ef16c093181af2c22e632ae639808a1b-0cd64883dc1573c935592b64354e5a97b2bacca6
 
git://git.sv.gnu.org/gnulib.git#6cc32c63e80bc1a30c521b2f07f2b54909b59892-8d807a99c6e8eecd2a9cf7c7b5d48ec0b2c934f8
 
git://xenbits.xen.org/qemu-xen-traditional.git#e4ceb77cf88bc44f0b7fe39225c49d660735f327-df553c056104e3dd8a2bd2e72539a57c4c085bae
 
git://xenbits.xen.org/qemu-xen.git#62b3d206425c245ed0a020390a64640d40d97471-44a072f0de0d57c95c2212bbce0232b7b74f
 
git://xenbits.xen.org/xen.git#ad4aa3619f436e3ed79eea8498ac18aa8d5e6b83-8478c9409a2c6726208e8dbc9f3e455b76725a33
From git://cache:9419/git://libvirt.org/libvirt
   9b9d0f1..e9ef4df  master -> origin/master
Loaded 35089 nodes in revision graph
Searching for test results:
 94539 [host=elbling1]
 94502 pass 0e8a72a5ef16c093181af2c22e632ae639808a1b 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
e4ceb77cf88bc44f0b7fe39225c49d660735f327 
62b3d206425c245ed0a020390a64640d40d97471 
ad4aa3619f436e3ed79eea8498ac18aa8d5e6b83
 94633 [host=huxelrebe0]
 94572 [host=huxelrebe1]
 94623 [host=huxelrebe0]
 94591 [host=huxelrebe0]
 94645

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

2016-05-27 Thread 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,

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

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

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

-- 
1.9.1


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

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

2016-05-27 Thread 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 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Edgar E. Iglesias 

--
Changes in v2:
- Add Konrad's and Edgar's reviewed-by
---
 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);
+

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

2016-05-27 Thread Julien Grall 
Convert device-tree debugging to 'Kconfig' as
CONFIG_DEVICE_TREE_DEBUG.

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

Signed-off-by: Julien Grall 
Reviewed-by: Edgar E. Iglesias 

---
Changes in v2:
- Fix typoes in the commit message and the Kconfig description
- Update the Kconfig description
- Add Edgar's reviewed-by

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   | 8 
 xen/arch/arm/domain_build.c | 4 +---
 xen/common/device_tree.c| 4 +---
 3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index 303bf36..360c3be 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -55,6 +55,14 @@ 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 are
+ logged in the Xen ring buffer.
+ If unsure, say N here.
+
 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] [PATCH] xen: xen-pciback: Remove create_workqueue

2016-05-27 Thread Konrad Rzeszutek Wilk 
On Fri, May 27, 2016 at 12:08:22PM -0400, Tejun Heo wrote:
> Hello,
> 
> On Fri, May 27, 2016 at 12:01:14PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Fri, May 27, 2016 at 09:24:11PM +0530, Bhaktipriya Shridhar wrote:
> > > With concurrency managed workqueues, use of dedicated workqueues can be
> > > replaced by using system_wq. Drop host->intr_wq by using
>   ^
> xen_pcibk_wq
> > > system_wq.
> > > 
> > > Since there is only a single work item, increase of concurrency level by
> > > switching to system_wq should not break anything.
> > 
> > _should_ not? Hehe. I presume this has not been tested?
> 
> Yeah, this is a part of sweeping conversions and it's challenging (and
> often impossible for specific drivers) to setup test environments.
> xen isn't as bad but can still be a pretty specialized setup.  The
> conversions aren't high risk and shouldn't be too difficult to root
> cause when something goes south.  We'd greatly appreciate any helps
> with reviewing and testing.
> 
> > > cancel_work_sync() has been used in xen_pcibk_disconnect() to ensure that
> > > work item is not pending or executing by the time exit path runs.
> > > 
> > > Signed-off-by: Bhaktipriya Shridhar 
> > > @@ -76,8 +75,7 @@ static void xen_pcibk_disconnect(struct 
> > > xen_pcibk_device *pdev)
> > >   /* If the driver domain started an op, make sure we complete it
> > >* before releasing the shared memory */
> > > 
> > > - /* Note, the workqueue does not use spinlocks at all.*/
> > > - flush_workqueue(xen_pcibk_wq);
> > > + cancel_work_sync(>op_work);
> 
> Should it be flush_work() instead?  Is it okay for a pdev->op_work to
> be queued and canceled without actually getting executed?

It should really flush them. The comment above says so, but in reality it
does not matter that much as we tearing down the communication. As long as
the pdev->op_work either completes or is never executed - we are fine.

> 
> Thanks.
> 
> -- 
> tejun

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

Re: [Xen-devel] [PATCH v3] x86/mce: handle reserved domain ID in XEN_MC_msrinject

2016-05-27 Thread Wei Liu 
On Fri, May 27, 2016 at 05:14:08PM +0100, Wei Liu wrote:
> On Fri, May 27, 2016 at 10:06:31AM -0600, Jan Beulich wrote:
> > >>> On 27.05.16 at 17:31,  wrote:
> > > On Fri, May 27, 2016 at 03:06:08PM +0100, Wei Liu wrote:
> > >> On Fri, May 27, 2016 at 08:03:42AM -0600, Jan Beulich wrote:
> > >> > >>> On 27.05.16 at 15:30,  wrote:
> > >> > > Commit 26646f3 "x86/mce: translate passed-in GPA to host machine
> > >> > > address" and commit 4ddf474 "tools/xen-mceinj: Pass in GPA when
> > >> > > injecting through MSR_MCI_ADDR" forgot to consider reserved domain
> > >> > > ID and mistakenly add MC_MSRINJ_F_GPADDR flag for them, which in turn
> > >> > > causes bug reported by
> > >> > > http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg02640.html.
> > >> > > 
> > >> > > This patch removes MC_MSRINK_F_GPADDR flag and checks this when 
> > >> > > injecting
> > >> > > to reserved domain IDs except DOMID_SELF, and treats the passed-in
> > >> > > address as host machine address.
> > >> > > 
> > >> > > Signed-off-by: Haozhong Zhang 
> > >> > 
> > >> > Reviewed-by: Jan Beulich 
> > >> > 
> > >> 
> > >> Release-acked-by: Wei Liu 
> > > 
> > > And queued.
> > 
> > Please wait for a maintainer ack.
> > 
> 
> $ ./scripts/get_maintainer.pl -f xen/arch/x86/cpu/mcheck/mce.c
> Christoph Egger 
> Liu Jinsong 
> Jan Beulich 
> Andrew Cooper 
> xen-devel@lists.xen.org
> 

OK, so looking at MAINTAINERS file:

MACHINE CHECK (MCA) & RAS
M:  Christoph Egger 
M:  Liu Jinsong 
S:  Supported
F:  xen/arch/x86/cpu/mcheck/

I will revert this patch now. Sorry for all the trouble!

Wei.

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

Re: [Xen-devel] [PATCH v3] x86/mce: handle reserved domain ID in XEN_MC_msrinject

2016-05-27 Thread Wei Liu 
On Fri, May 27, 2016 at 10:06:31AM -0600, Jan Beulich wrote:
> >>> On 27.05.16 at 17:31,  wrote:
> > On Fri, May 27, 2016 at 03:06:08PM +0100, Wei Liu wrote:
> >> On Fri, May 27, 2016 at 08:03:42AM -0600, Jan Beulich wrote:
> >> > >>> On 27.05.16 at 15:30,  wrote:
> >> > > Commit 26646f3 "x86/mce: translate passed-in GPA to host machine
> >> > > address" and commit 4ddf474 "tools/xen-mceinj: Pass in GPA when
> >> > > injecting through MSR_MCI_ADDR" forgot to consider reserved domain
> >> > > ID and mistakenly add MC_MSRINJ_F_GPADDR flag for them, which in turn
> >> > > causes bug reported by
> >> > > http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg02640.html.
> >> > > 
> >> > > This patch removes MC_MSRINK_F_GPADDR flag and checks this when 
> >> > > injecting
> >> > > to reserved domain IDs except DOMID_SELF, and treats the passed-in
> >> > > address as host machine address.
> >> > > 
> >> > > Signed-off-by: Haozhong Zhang 
> >> > 
> >> > Reviewed-by: Jan Beulich 
> >> > 
> >> 
> >> Release-acked-by: Wei Liu 
> > 
> > And queued.
> 
> Please wait for a maintainer ack.
> 

$ ./scripts/get_maintainer.pl -f xen/arch/x86/cpu/mcheck/mce.c
Christoph Egger 
Liu Jinsong 
Jan Beulich 
Andrew Cooper 
xen-devel@lists.xen.org

So I took it that your review was sufficient and pushed it.

It's already in staging. I can revert it now.

Wei.

> Jan
> 
> 
> ___
> 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] [PATCH v2] arm/gic-v3: Fix ACPI probe fail on GICv4 hardware

2016-05-27 Thread Julien Grall 

Hello Shanker,

On 27/05/16 16:30, Shanker Donthineni wrote:

On 05/27/2016 10:10 AM, Julien Grall wrote:

On 27/05/16 16:00, Shanker Donthineni wrote:

The current driver ACPI probe fails on hardware which has GICv4
version, even though it is fully compatible to GICv3. This patch
fixes the issue by registering the same probe function for GICv4
hardware.

Signed-off-by: Shanker Donthineni 
---
Changes since v1:
 - Edit commit text.
 - Fix BUG() in xen/arch/arm/domain.c


Please see my latest comment on the previous version [1].

To go further, the ACPI tables may not represent the actual hardware. It is 
possible to have ACPI tables describing a GICv2 whilst the real hardware is a 
GICv3.


Yes, it is absolutely valid and UEFI firmware can decide what to be exported to 
OS by changing the version number in ACPI MADT table.

On Qualcomm Technologies QDF2XXX platforms, GIC version set to 4.


To be clear, I am not against adding support of GICv4 in Xen. My concern 
is how the patch add it. Exposing GICv4 beyond the GICv3 driver is not 
necessary today.


Better to keep as small as possible until we figure out how Xen will 
support GICv4 features.


I.e, the following the code should be enough.

ACPI_DEVICE_START(acgicv4, "GICv4", DEVICE_GIC)
   .class_type = ACPI_MADT_GIC_VERSION_V4,
   .init = gicv3_acpi_preinit,
ACPI_DEVICE_END




Xen will use the GICv2 driver and not the GICv3. So the helper will return 
GIC_V2 (and not GIC_V3).



The current xen is supporting both the GICv2 and GICv3 for ACPI based boot.

ACPI_DEVICE_START(agicv3, "GICv3", DEVICE_GIC)
 .class_type = ACPI_MADT_GIC_VERSION_V3,
 .init = gicv3_acpi_preinit,
ACPI_DEVICE_END

ACPI_DEVICE_START(agicv2, "GICv2", DEVICE_GIC)
 .class_type = ACPI_MADT_GIC_VERSION_V2,
 .init = gicv2_acpi_preinit,
ACPI_DEVICE_END


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] xen: xen-pciback: Remove create_workqueue

2016-05-27 Thread Tejun Heo 
Hello,

On Fri, May 27, 2016 at 12:01:14PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, May 27, 2016 at 09:24:11PM +0530, Bhaktipriya Shridhar wrote:
> > With concurrency managed workqueues, use of dedicated workqueues can be
> > replaced by using system_wq. Drop host->intr_wq by using
  ^
  xen_pcibk_wq
> > system_wq.
> > 
> > Since there is only a single work item, increase of concurrency level by
> > switching to system_wq should not break anything.
> 
> _should_ not? Hehe. I presume this has not been tested?

Yeah, this is a part of sweeping conversions and it's challenging (and
often impossible for specific drivers) to setup test environments.
xen isn't as bad but can still be a pretty specialized setup.  The
conversions aren't high risk and shouldn't be too difficult to root
cause when something goes south.  We'd greatly appreciate any helps
with reviewing and testing.

> > cancel_work_sync() has been used in xen_pcibk_disconnect() to ensure that
> > work item is not pending or executing by the time exit path runs.
> > 
> > Signed-off-by: Bhaktipriya Shridhar 
> > @@ -76,8 +75,7 @@ static void xen_pcibk_disconnect(struct xen_pcibk_device 
> > *pdev)
> > /* If the driver domain started an op, make sure we complete it
> >  * before releasing the shared memory */
> > 
> > -   /* Note, the workqueue does not use spinlocks at all.*/
> > -   flush_workqueue(xen_pcibk_wq);
> > +   cancel_work_sync(>op_work);

Should it be flush_work() instead?  Is it okay for a pdev->op_work to
be queued and canceled without actually getting executed?

Thanks.

-- 
tejun

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

[Xen-devel] [for-4.7 v3 0/2] xen: XENMEM_add_to_physmap_batch: Mark 'foreign_id" as reserved for dev_mmio

2016-05-27 Thread Julien Grall 
Hello all,

This series is based on the thread [1]. To allow future extension, the new
space dev_mmio should have all unused fields marked as reserved.

This series is candidate for Xen 4.7, the first patch ensure a clean ABI
for the new space which will allow future extension.

See in each patch for all the changes.

Regards,

[1] http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg02328.html

Julien Grall (2):
  xen: XENMEM_add_to_physmap_batch: Mark 'foreign_id' as reserved for
dev_mmio
  xen/arm: Document the behavior of XENMAPSPACE_dev_mmio

 xen/arch/arm/mm.c   |  9 +++--
 xen/arch/x86/mm.c   |  4 ++--
 xen/common/compat/memory.c  |  7 +++
 xen/common/memory.c | 12 +---
 xen/include/public/memory.h | 16 ++--
 xen/include/xen/mm.h|  3 ++-
 6 files changed, 41 insertions(+), 10 deletions(-)

-- 
1.9.1


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

Re: [Xen-devel] [PATCH v3] x86/mce: handle reserved domain ID in XEN_MC_msrinject

2016-05-27 Thread Jan Beulich 
>>> On 27.05.16 at 17:31,  wrote:
> On Fri, May 27, 2016 at 03:06:08PM +0100, Wei Liu wrote:
>> On Fri, May 27, 2016 at 08:03:42AM -0600, Jan Beulich wrote:
>> > >>> On 27.05.16 at 15:30,  wrote:
>> > > Commit 26646f3 "x86/mce: translate passed-in GPA to host machine
>> > > address" and commit 4ddf474 "tools/xen-mceinj: Pass in GPA when
>> > > injecting through MSR_MCI_ADDR" forgot to consider reserved domain
>> > > ID and mistakenly add MC_MSRINJ_F_GPADDR flag for them, which in turn
>> > > causes bug reported by
>> > > http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg02640.html.
>> > > 
>> > > This patch removes MC_MSRINK_F_GPADDR flag and checks this when injecting
>> > > to reserved domain IDs except DOMID_SELF, and treats the passed-in
>> > > address as host machine address.
>> > > 
>> > > Signed-off-by: Haozhong Zhang 
>> > 
>> > Reviewed-by: Jan Beulich 
>> > 
>> 
>> Release-acked-by: Wei Liu 
> 
> And queued.

Please wait for a maintainer ack.

Jan


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

[Xen-devel] [for-4.7 v3 1/2] xen: XENMEM_add_to_physmap_batch: Mark 'foreign_id' as reserved for dev_mmio

2016-05-27 Thread Julien Grall 
The field 'foreign_id' is not used when the space is dev_mmio. As the
space is not yet part of the stable ABI, the field is marked as reserved
for future use.

The value should always be 0, other values will return -EOPNOTSUPP.

Signed-off-by: Julien Grall 

---
Changes in v3:
- s/add_to_physmap_batch_extra/xen_add_to_physmap_batch_extra/
- Add a comment in compat

Changes in v2:
- Return -EOPNOTSUPP rather than -ENOSYS
- Introduce a union in the structure xenmem_add_to_physmap_batch
---
 xen/arch/arm/mm.c   |  9 +++--
 xen/arch/x86/mm.c   |  4 ++--
 xen/common/compat/memory.c  |  7 +++
 xen/common/memory.c | 12 +---
 xen/include/public/memory.h | 10 +-
 xen/include/xen/mm.h|  3 ++-
 6 files changed, 36 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index b46e23e..0aa8092 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1047,7 +1047,7 @@ void share_xen_page_with_privileged_guests(
 int xenmem_add_to_physmap_one(
 struct domain *d,
 unsigned int space,
-domid_t foreign_domid,
+union xen_add_to_physmap_batch_extra extra,
 unsigned long idx,
 xen_pfn_t gpfn)
 {
@@ -1103,7 +1103,8 @@ int xenmem_add_to_physmap_one(
 {
 struct domain *od;
 p2m_type_t p2mt;
-od = rcu_lock_domain_by_any_id(foreign_domid);
+
+od = rcu_lock_domain_by_any_id(extra.foreign_domid);
 if ( od == NULL )
 return -ESRCH;
 
@@ -1143,6 +1144,10 @@ int xenmem_add_to_physmap_one(
 break;
 }
 case XENMAPSPACE_dev_mmio:
+/* extra should be 0. Reserved for future use. */
+if ( extra.res0 )
+return -EOPNOTSUPP;
+
 rc = map_dev_mmio_region(d, gpfn, 1, idx);
 return rc;
 
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 03a4d5b..8d10a3e 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4769,7 +4769,7 @@ static int handle_iomem_range(unsigned long s, unsigned 
long e, void *p)
 int xenmem_add_to_physmap_one(
 struct domain *d,
 unsigned int space,
-domid_t foreign_domid,
+union xen_add_to_physmap_batch_extra extra,
 unsigned long idx,
 xen_pfn_t gpfn)
 {
@@ -4830,7 +4830,7 @@ int xenmem_add_to_physmap_one(
 break;
 }
 case XENMAPSPACE_gmfn_foreign:
-return p2m_add_foreign(d, idx, gpfn, foreign_domid);
+return p2m_add_foreign(d, idx, gpfn, extra.foreign_domid);
 default:
 break;
 }
diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index 19a914d..20c7671 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -253,6 +253,13 @@ int compat_memory_op(unsigned int cmd, 
XEN_GUEST_HANDLE_PARAM(void) compat)
 unsigned int size = cmp.atpb.size;
 xen_ulong_t *idxs = (void *)(nat.atpb + 1);
 xen_pfn_t *gpfns = (void *)(idxs + limit);
+/*
+ * The union will always be 16-bit width. So it is not
+ * necessary to have the exact field which correspond to the
+ * space.
+ */
+enum XLAT_add_to_physmap_batch_u u =
+XLAT_add_to_physmap_batch_u_res0;
 
 if ( copy_from_guest(, compat, 1) ||
  !compat_handle_okay(cmp.atpb.idxs, size) ||
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 644f81a..ccc6436 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -639,9 +639,15 @@ static int xenmem_add_to_physmap(struct domain *d,
 {
 unsigned int done = 0;
 long rc = 0;
+union xen_add_to_physmap_batch_extra extra;
+
+if ( xatp->space != XENMAPSPACE_gmfn_foreign )
+extra.res0 = 0;
+else
+extra.foreign_domid = DOMID_INVALID;
 
 if ( xatp->space != XENMAPSPACE_gmfn_range )
-return xenmem_add_to_physmap_one(d, xatp->space, DOMID_INVALID,
+return xenmem_add_to_physmap_one(d, xatp->space, extra,
  xatp->idx, xatp->gpfn);
 
 if ( xatp->size < start )
@@ -658,7 +664,7 @@ static int xenmem_add_to_physmap(struct domain *d,
 
 while ( xatp->size > done )
 {
-rc = xenmem_add_to_physmap_one(d, xatp->space, DOMID_INVALID,
+rc = xenmem_add_to_physmap_one(d, xatp->space, extra,
xatp->idx, xatp->gpfn);
 if ( rc < 0 )
 break;
@@ -719,7 +725,7 @@ static int xenmem_add_to_physmap_batch(struct domain *d,
 }
 
 rc = xenmem_add_to_physmap_one(d, xatpb->space,
-   xatpb->foreign_domid,
+   xatpb->u,
idx, gpfn);
 
 if ( unlikely(__copy_to_guest_offset(xatpb->errs, 0, , 1)) )
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index fe52ee1..5f7e0d2

[Xen-devel] [for-4.7 v3 2/2] xen/arm: Document the behavior of XENMAPSPACE_dev_mmio

2016-05-27 Thread Julien Grall 
Currently, XENMAPSPACE_dev_mmio maps MMIO regions using one of the most
restrictive memory attribute (Device-nGnRE).

Signed-off-by: Julien Grall 
Acked-by: Stefano Stabellini 
Acked-by: Jan Beulich 

---
Changes in v3:
- Update comment
- Add Stefano's Jan's ack

Changes in v2:
- s/Device_nGnRE/Device-nGnRE/ to match the spec
- Update the comment to mention the name for ARMv7.
---
 xen/include/public/memory.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 5f7e0d2..29ec571 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -220,7 +220,11 @@ DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
 #define XENMAPSPACE_gmfn_range   3 /* GMFN range, XENMEM_add_to_physmap only. 
*/
 #define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
 * XENMEM_add_to_physmap_batch only. */
-#define XENMAPSPACE_dev_mmio 5 /* device mmio region */
+#define XENMAPSPACE_dev_mmio 5 /* device mmio region
+  ARM only; the region is mapped in
+  Stage-2 using the memory attribute
+  "Device-nGnRE" (previously named
+  "Device" on ARMv7) */
 /* ` } */
 
 /*
-- 
1.9.1


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

Re: [Xen-devel] [for-4.7 v2 1/2] xen: XENMEM_add_to_physmap_batch: Mark 'foreign_id' as reserved for dev_mmio

2016-05-27 Thread Jan Beulich 
>>> On 27.05.16 at 17:16,  wrote:
> On 27/05/16 10:58, Jan Beulich wrote:
> On 25.05.16 at 17:56,  wrote:
>>> --- a/xen/common/compat/memory.c
>>> +++ b/xen/common/compat/memory.c
>>> @@ -253,6 +253,8 @@ int compat_memory_op(unsigned int cmd, 
>>> XEN_GUEST_HANDLE_PARAM(void) compat)
>>>   unsigned int size = cmp.atpb.size;
>>>   xen_ulong_t *idxs = (void *)(nat.atpb + 1);
>>>   xen_pfn_t *gpfns = (void *)(idxs + limit);
>>> +enum XLAT_add_to_physmap_batch_u u =
>>> +XLAT_add_to_physmap_batch_u_res0;
>>
>> Here you're cheating, and to help future readers understand you are
>> you should say why this is okay in a comment. Or alternatively handle
>> things properly.
> 
> Well, this is the case on other place having to convert union (see 
> XENMEM_get_vnumainfo). So I though it was valid.

It depends on context whether you can go this way or need to use
switch().

Jan


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

Re: [Xen-devel] [PATCH] xen: xen-pciback: Remove create_workqueue

2016-05-27 Thread Konrad Rzeszutek Wilk 
On Fri, May 27, 2016 at 09:24:11PM +0530, Bhaktipriya Shridhar wrote:
> With concurrency managed workqueues, use of dedicated workqueues can be
> replaced by using system_wq. Drop host->intr_wq by using
> system_wq.
> 
> Since there is only a single work item, increase of concurrency level by
> switching to system_wq should not break anything.

_should_ not? Hehe. I presume this has not been tested?
> 
> cancel_work_sync() has been used in xen_pcibk_disconnect() to ensure that
> work item is not pending or executing by the time exit path runs.
> 
> Signed-off-by: Bhaktipriya Shridhar 
> ---
>  drivers/xen/xen-pciback/pciback.h |  1 -
>  drivers/xen/xen-pciback/pciback_ops.c |  2 +-
>  drivers/xen/xen-pciback/xenbus.c  | 10 +-
>  3 files changed, 2 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/xen/xen-pciback/pciback.h 
> b/drivers/xen/xen-pciback/pciback.h
> index 4d529f3..7af369b6 100644
> --- a/drivers/xen/xen-pciback/pciback.h
> +++ b/drivers/xen/xen-pciback/pciback.h
> @@ -55,7 +55,6 @@ struct xen_pcibk_dev_data {
> 
>  /* Used by XenBus and xen_pcibk_ops.c */
>  extern wait_queue_head_t xen_pcibk_aer_wait_queue;
> -extern struct workqueue_struct *xen_pcibk_wq;
>  /* Used by pcistub.c and conf_space_quirks.c */
>  extern struct list_head xen_pcibk_quirks;
> 
> diff --git a/drivers/xen/xen-pciback/pciback_ops.c 
> b/drivers/xen/xen-pciback/pciback_ops.c
> index 2f19dd7..f8c7775 100644
> --- a/drivers/xen/xen-pciback/pciback_ops.c
> +++ b/drivers/xen/xen-pciback/pciback_ops.c
> @@ -310,7 +310,7 @@ void xen_pcibk_test_and_schedule_op(struct 
> xen_pcibk_device *pdev)
>* already processing a request */
>   if (test_bit(_XEN_PCIF_active, (unsigned long *)>sh_info->flags)
>   && !test_and_set_bit(_PDEVF_op_active, >flags)) {
> - queue_work(xen_pcibk_wq, >op_work);
> + schedule_work(>op_work);
>   }
>   /*_XEN_PCIB_active should have been cleared by pcifront. And also make
>   sure xen_pcibk is waiting for ack by checking _PCIB_op_pending*/
> diff --git a/drivers/xen/xen-pciback/xenbus.c 
> b/drivers/xen/xen-pciback/xenbus.c
> index c252eb3..f70a8e1 100644
> --- a/drivers/xen/xen-pciback/xenbus.c
> +++ b/drivers/xen/xen-pciback/xenbus.c
> @@ -17,7 +17,6 @@
>  #include "pciback.h"
> 
>  #define INVALID_EVTCHN_IRQ  (-1)
> -struct workqueue_struct *xen_pcibk_wq;
> 
>  static bool __read_mostly passthrough;
>  module_param(passthrough, bool, S_IRUGO);
> @@ -76,8 +75,7 @@ static void xen_pcibk_disconnect(struct xen_pcibk_device 
> *pdev)
>   /* If the driver domain started an op, make sure we complete it
>* before releasing the shared memory */
> 
> - /* Note, the workqueue does not use spinlocks at all.*/
> - flush_workqueue(xen_pcibk_wq);
> + cancel_work_sync(>op_work);
> 
>   if (pdev->sh_info != NULL) {
>   xenbus_unmap_ring_vfree(pdev->xdev, pdev->sh_info);
> @@ -733,11 +731,6 @@ const struct xen_pcibk_backend *__read_mostly 
> xen_pcibk_backend;
> 
>  int __init xen_pcibk_xenbus_register(void)
>  {
> - xen_pcibk_wq = create_workqueue("xen_pciback_workqueue");
> - if (!xen_pcibk_wq) {
> - pr_err("%s: create xen_pciback_workqueue failed\n", __func__);
> - return -EFAULT;
> - }
>   xen_pcibk_backend = _pcibk_vpci_backend;
>   if (passthrough)
>   xen_pcibk_backend = _pcibk_passthrough_backend;
> @@ -747,6 +740,5 @@ int __init xen_pcibk_xenbus_register(void)
> 
>  void __exit xen_pcibk_xenbus_unregister(void)
>  {
> - destroy_workqueue(xen_pcibk_wq);
>   xenbus_unregister_driver(_pcibk_driver);
>  }
> --
> 2.1.4
> 

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

Re: [Xen-devel] [PATCH] Config.mk: update qemu-xen tag

2016-05-27 Thread Wei Liu 
On Fri, May 27, 2016 at 04:00:54PM +0100, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD 

Ack + queued.

> ---
>  Config.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Config.mk b/Config.mk
> index f6e536e..5ddfbf8 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -271,7 +271,7 @@ SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
>  MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git
>  endif
>  OVMF_UPSTREAM_REVISION ?= 52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d
> -QEMU_UPSTREAM_REVISION ?= qemu-xen-4.7.0-rc4
> +QEMU_UPSTREAM_REVISION ?= qemu-xen-4.7.0-rc5
>  MINIOS_UPSTREAM_REVISION ?= 1a3ee6eeca136525aa2e6917ae500e7cf731c09d
>  # Fri May 13 15:21:10 2016 +0100
>  # lib/sys.c: enclose file_types in define guards
> -- 
> Anthony PERARD
> 

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

Re: [Xen-devel] [PATCH v3] x86/mce: handle reserved domain ID in XEN_MC_msrinject

2016-05-27 Thread Wei Liu 
On Fri, May 27, 2016 at 03:06:08PM +0100, Wei Liu wrote:
> On Fri, May 27, 2016 at 08:03:42AM -0600, Jan Beulich wrote:
> > >>> On 27.05.16 at 15:30,  wrote:
> > > Commit 26646f3 "x86/mce: translate passed-in GPA to host machine
> > > address" and commit 4ddf474 "tools/xen-mceinj: Pass in GPA when
> > > injecting through MSR_MCI_ADDR" forgot to consider reserved domain
> > > ID and mistakenly add MC_MSRINJ_F_GPADDR flag for them, which in turn
> > > causes bug reported by
> > > http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg02640.html.
> > > 
> > > This patch removes MC_MSRINK_F_GPADDR flag and checks this when injecting
> > > to reserved domain IDs except DOMID_SELF, and treats the passed-in
> > > address as host machine address.
> > > 
> > > Signed-off-by: Haozhong Zhang 
> > 
> > Reviewed-by: Jan Beulich 
> > 
> 
> Release-acked-by: Wei Liu 

And queued.

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

Re: [Xen-devel] [PATCH v2] arm/gic-v3: Fix ACPI probe fail on GICv4 hardware

2016-05-27 Thread Shanker Donthineni 


On 05/27/2016 10:10 AM, Julien Grall wrote:
> Hello Shanker,
>
> On 27/05/16 16:00, Shanker Donthineni wrote:
>> The current driver ACPI probe fails on hardware which has GICv4
>> version, even though it is fully compatible to GICv3. This patch
>> fixes the issue by registering the same probe function for GICv4
>> hardware.
>>
>> Signed-off-by: Shanker Donthineni 
>> ---
>> Changes since v1:
>> - Edit commit text.
>> - Fix BUG() in xen/arch/arm/domain.c
>
> Please see my latest comment on the previous version [1].
>
> To go further, the ACPI tables may not represent the actual hardware. It is 
> possible to have ACPI tables describing a GICv2 whilst the real hardware is a 
> GICv3.
>
Yes, it is absolutely valid and UEFI firmware can decide what to be exported to 
OS by changing the version number in ACPI MADT table.

On Qualcomm Technologies QDF2XXX platforms, GIC version set to 4. 

> Xen will use the GICv2 driver and not the GICv3. So the helper will return 
> GIC_V2 (and not GIC_V3).
>

The current xen is supporting both the GICv2 and GICv3 for ACPI based boot.

ACPI_DEVICE_START(agicv3, "GICv3", DEVICE_GIC)
.class_type = ACPI_MADT_GIC_VERSION_V3,
.init = gicv3_acpi_preinit,
ACPI_DEVICE_END

ACPI_DEVICE_START(agicv2, "GICv2", DEVICE_GIC)
.class_type = ACPI_MADT_GIC_VERSION_V2,
.init = gicv2_acpi_preinit,
ACPI_DEVICE_END

> Regards,
>
> [1] https://www.mail-archive.com/xen-devel@lists.xen.org/msg69273.html
>

-- 
Shanker Donthineni
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


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

Re: [Xen-devel] [for-4.7 v2 1/2] xen: XENMEM_add_to_physmap_batch: Mark 'foreign_id' as reserved for dev_mmio

2016-05-27 Thread Julien Grall 

Hi Jan,

On 27/05/16 10:58, Jan Beulich wrote:

On 25.05.16 at 17:56,  wrote:

--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -253,6 +253,8 @@ int compat_memory_op(unsigned int cmd, 
XEN_GUEST_HANDLE_PARAM(void) compat)
  unsigned int size = cmp.atpb.size;
  xen_ulong_t *idxs = (void *)(nat.atpb + 1);
  xen_pfn_t *gpfns = (void *)(idxs + limit);
+enum XLAT_add_to_physmap_batch_u u =
+XLAT_add_to_physmap_batch_u_res0;


Here you're cheating, and to help future readers understand you are
you should say why this is okay in a comment. Or alternatively handle
things properly.


Well, this is the case on other place having to convert union (see 
XENMEM_get_vnumainfo). So I though it was valid.


I will add a comment here.




--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -259,7 +259,15 @@ struct xen_add_to_physmap_batch {

  /* Number of pages to go through */
  uint16_t size;
-domid_t foreign_domid; /* IFF gmfn_foreign */
+
+#if __XEN_INTERFACE_VERSION__ < 0x00040700
+domid_t foreign_domid; /* IFF gmfn_foreign. Should be 0 for other
spaces. */
+#else
+union add_to_physmap_batch_extra {


This lacks a xen_ prefix.


I will fix it.

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] xen/arm: setup: fix typo

2016-05-27 Thread Julien Grall 

Hello Peng,

On 27/05/16 06:20, Peng Fan wrote:

Typo fix: fdt_get_mem_rsc -> fdt_get_mem_rsv

Signed-off-by: Peng Fan 
Cc: Julien Grall 
Cc: Stefano Stabellini 


Reviewed-by: Julien Grall 

Regards,


---
  xen/arch/arm/setup.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 09ff1ea..dcb23b7 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -185,7 +185,7 @@ void dt_unreserved_regions(paddr_t s, paddr_t e,
  /* If we can't read it, pretend it doesn't exist... */
  continue;

-r_e += r_s; /* fdt_get_mem_rsc returns length */
+r_e += r_s; /* fdt_get_mem_rsv returns length */

  if ( s < r_e && r_s < e )
  {



--
Julien Grall

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

Re: [Xen-devel] [PATCH v2] arm/gic-v3: Fix ACPI probe fail on GICv4 hardware

2016-05-27 Thread Julien Grall 

Hello Shanker,

On 27/05/16 16:00, Shanker Donthineni wrote:

The current driver ACPI probe fails on hardware which has GICv4
version, even though it is fully compatible to GICv3. This patch
fixes the issue by registering the same probe function for GICv4
hardware.

Signed-off-by: Shanker Donthineni 
---
Changes since v1:
- Edit commit text.
- Fix BUG() in xen/arch/arm/domain.c


Please see my latest comment on the previous version [1].

To go further, the ACPI tables may not represent the actual hardware. It 
is possible to have ACPI tables describing a GICv2 whilst the real 
hardware is a GICv3.


Xen will use the GICv2 driver and not the GICv3. So the helper will 
return GIC_V2 (and not GIC_V3).


Regards,

[1] https://www.mail-archive.com/xen-devel@lists.xen.org/msg69273.html

--
Julien Grall

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

[Xen-devel] [PATCH] Config.mk: update qemu-xen tag

2016-05-27 Thread Anthony PERARD 
Signed-off-by: Anthony PERARD 
---
 Config.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Config.mk b/Config.mk
index f6e536e..5ddfbf8 100644
--- a/Config.mk
+++ b/Config.mk
@@ -271,7 +271,7 @@ SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
 MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git
 endif
 OVMF_UPSTREAM_REVISION ?= 52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d
-QEMU_UPSTREAM_REVISION ?= qemu-xen-4.7.0-rc4
+QEMU_UPSTREAM_REVISION ?= qemu-xen-4.7.0-rc5
 MINIOS_UPSTREAM_REVISION ?= 1a3ee6eeca136525aa2e6917ae500e7cf731c09d
 # Fri May 13 15:21:10 2016 +0100
 # lib/sys.c: enclose file_types in define guards
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v2] arm/gic-v3: Fix ACPI probe fail on GICv4 hardware

2016-05-27 Thread Shanker Donthineni 
The current driver ACPI probe fails on hardware which has GICv4
version, even though it is fully compatible to GICv3. This patch
fixes the issue by registering the same probe function for GICv4
hardware.

Signed-off-by: Shanker Donthineni 
---
Changes since v1:
   - Edit commit text.
   - Fix BUG() in xen/arch/arm/domain.c

This patch tested on Qualcomm Technologies on QDF2XXX platforms.

 xen/arch/arm/domain.c |  5 +
 xen/arch/arm/gic-v3.c | 13 +
 xen/include/asm-arm/gic.h |  1 +
 3 files changed, 19 insertions(+)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 1365b4a..5647b80 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -571,6 +571,11 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 d->arch.vgic.version = GIC_V3;
 break;
 
+   case GIC_V4:
+config->gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
+d->arch.vgic.version = GIC_V3;
+break;
+
 default:
 BUG();
 }
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index a095064..594cf6e 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1604,10 +1604,23 @@ static int __init gicv3_acpi_preinit(const void *data)
 return 0;
 }
 
+static int __init gicv4_acpi_preinit(const void *data)
+{
+gicv3_info.hw_version = GIC_V4;
+register_gic_ops(_ops);
+
+return 0;
+}
+
 ACPI_DEVICE_START(agicv3, "GICv3", DEVICE_GIC)
 .class_type = ACPI_MADT_GIC_VERSION_V3,
 .init = gicv3_acpi_preinit,
 ACPI_DEVICE_END
+
+ACPI_DEVICE_START(agicv4, "GICv4", DEVICE_GIC)
+.class_type = ACPI_MADT_GIC_VERSION_V4,
+.init = gicv4_acpi_preinit,
+ACPI_DEVICE_END
 #endif
 
 /*
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index cd97bb2..5be814a 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -218,6 +218,7 @@ struct gic_lr {
 enum gic_version {
 GIC_V2,
 GIC_V3,
+GIC_V4,
 };
 
 extern enum gic_version gic_hw_version(void);
-- 
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
a Linux Foundation Collaborative Project


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

Re: [Xen-devel] [PATCH] arm/gic-v3: Fix driver probe fail on GICv4 hardware

2016-05-27 Thread Julien Grall 

Hello Shanker,

On 27/05/16 15:31, Shanker Donthineni wrote:

   diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 1365b4a..56a47f5 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -571,6 +571,11 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
   d->arch.vgic.version = GIC_V3;
   break;

+case GIC_V4:
+config->gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
+d->arch.vgic.version = GIC_V3;
+break;


As mentioned in my previous mail, there is no support of GICv4 in Xen. Although 
the GICv3 driver is supporting this hardware.So we should not advertise GIC_V4 
outside of the driver until Xen will get enough knowledge of GICv4 which will 
require sensible change in the generic code.


GICv4 hardware is fully compatible to GICv3 and has an additional feature vLPI. 
 We don't need any special driver or changes to current driver to support GICv4 
for SPIs/LPIs in Xen just like Linux kernel.

Confused, you are expecting gic_hw_version() should return GIC version number 
'3' on on GICv4 hardware, right?


Because the function is misnamed. It returns the version of GIC 
supported by the driver to find the associated vGIC. Currently we only 
support GICv3 and GICv2. If other GIC version are supported, it is only 
because they are compatible.


This is a choice of the driver and should not be exposed/spread outside 
of the drivers until it is strictly necessary.


Anyway, Stefano may have a different opinion on this.

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 4/4] VMX: fixup PI descritpor when cpu is offline

2016-05-27 Thread Jan Beulich 
>>> On 26.05.16 at 15:39,  wrote:
> @@ -102,9 +103,10 @@ void vmx_pi_per_cpu_init(unsigned int cpu)
>  {
>  INIT_LIST_HEAD(_cpu(vmx_pi_blocking, cpu).list);
>  spin_lock_init(_cpu(vmx_pi_blocking, cpu).lock);
> +per_cpu(vmx_pi_blocking, cpu).down = 0;

This seems pointless - per-CPU data starts out all zero (and there
are various places already which rely on that).

> @@ -122,10 +124,25 @@ static void vmx_vcpu_block(struct vcpu *v)
>   * new vCPU to the list.
>   */
>  spin_unlock_irqrestore(>arch.hvm_vmx.pi_hotplug_lock, flags);
> -return;
> +return 1;
>  }
>  
>  spin_lock(pi_blocking_list_lock);
> +if ( unlikely(per_cpu(vmx_pi_blocking, v->processor).down) )

Is this something that can actually happen? vmx_pi_desc_fixup()
runs in stop-machine context, i.e. no CPU can actively be here (or
anywhere near the arch_vcpu_block() call sites).

> +{
> +/*
> + * We being here means that the v->processor is going away, and all
> + * the vcpus on its blocking list were removed from it. Hence we
> + * cannot add new vcpu to it. Besides that, we return -1 to
> + * prevent the vcpu from being blocked. This is needed because
> + * if the vCPU is continue to block and here we don't put it
> + * in a per-cpu blocking list, it might not be woken up by the
> + * notification event.
> + */
> +spin_unlock(pi_blocking_list_lock);
> +spin_unlock_irqrestore(>arch.hvm_vmx.pi_hotplug_lock, flags);
> +return 0;

The comment says you mean to return -1 here...

> +void vmx_pi_desc_fixup(int cpu)

unsigned int

> +{
> +unsigned int new_cpu, dest;
> +unsigned long flags;
> +struct arch_vmx_struct *vmx, *tmp;
> +spinlock_t *new_lock, *old_lock = _cpu(vmx_pi_blocking, cpu).lock;
> +struct list_head *blocked_vcpus = _cpu(vmx_pi_blocking, cpu).list;
> +
> +if ( !iommu_intpost )
> +return;
> +
> +spin_lock_irqsave(old_lock, flags);
> +per_cpu(vmx_pi_blocking, cpu).down = 1;
> +
> +list_for_each_entry_safe(vmx, tmp, blocked_vcpus, pi_blocking.list)
> +{
> +/*
> + * We need to find an online cpu as the NDST of the PI descriptor, it
> + * doesn't matter whether it is within the cpupool of the domain or
> + * not. As long as it is online, the vCPU will be woken up once the
> + * notification event arrives.
> + */
> +new_cpu = cpu;
> +restart:

Labels indented by at least one blank please. Or even better, get
things done without goto.

> +while ( 1 )
> +{
> +new_cpu = (new_cpu + 1) % nr_cpu_ids;
> +if ( cpu_online(new_cpu) )
> +break;
> +}

Please don't open code things like cpumask_cycle(). But with the
restart logic likely unnecessary (see below), this would probably
better become cpumask_any() then.

> +new_lock = _cpu(vmx_pi_blocking, cpu).lock;

DYM new_cpu here? In fact with ...

> +spin_lock(new_lock);

... this I can't see how you would have successfully tested this
new code path, as I can't see how this would end in other than
a deadlock (as you hold this very lock already).

> +/*
> + * After acquiring the blocking list lock for the new cpu, we need
> + * to check whether new_cpu is still online.

How could it have gone offline? As mentioned, CPUs get brought
down in stop-machine context (and btw for the very reason of
avoiding complexity like this).

> + * If '.down' is true, it mean 'new_cpu' is also going to be offline,
> + * so just go back to find another one, otherwise, there are two
> + * possibilities:
> + *   case 1 - 'new_cpu' is online.
> + *   case 2 - 'new_cpu' is about to be offline, but doesn't get to
> + *the point where '.down' is set.
> + * In either case above, we can just set 'new_cpu' to 'NDST' field.
> + * For case 2 the 'NDST' field will be set to another online cpu when
> + * we get to this function for 'new_cpu' some time later.
> + */
> +if ( per_cpu(vmx_pi_blocking, cpu).down )

And again I suspect you mean new_cpu here.

> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -833,10 +833,8 @@ void vcpu_block(void)
>  
>  set_bit(_VPF_blocked, >pause_flags);
>  
> -arch_vcpu_block(v);
> -
>  /* Check for events /after/ blocking: avoids wakeup waiting race. */
> -if ( local_events_need_delivery() )
> +if ( arch_vcpu_block(v) || local_events_need_delivery() )

Here as well as below I'm getting the impression that you have things
backwards: vmx_vcpu_block() returns true for the two pre-existing
return paths (in which case you previously did not enter this if()'s
body), and false on the one new return path. Plus ...

> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@

Re: [Xen-devel] [PATCH] arm/acpi: Add Server Base System Architecture UART support

2016-05-27 Thread Julien Grall 

Hello Shanker,

On 27/05/16 15:01, Shanker Donthineni wrote:

On 05/27/2016 08:04 AM, Julien Grall wrote:

On 27/05/16 01:28, Shanker Donthineni wrote:

The ARM Server Base System Architecture describes a generic UART
interface. It doesn't support clock control registers to set
baudrate. So, extend the driver probe() to handle SBSA interface
types and set the baudrate to 115200 for SBSA interfaces.


I cannot find any mention of the baudrate in the SBSA. Where does it come from?


Yes, no where mentioned about the baudrate in SBSA document. I used 115200 
based on the  the Linux  PL011 driver.


Looking at the Linux code, it is a default when there is no valid 
configuration (which may not be suitable for any platform?).


Whilst Linux userspace cares about the baudrate, Xen only use it to 
configure the hardware. Given that the UART should have been configured 
by the hardware-specific software, the proper value should be BAUD_AUTO.


If you look at the code, pl011_init_preirq will read the baud rate when 
uart->baud == BAUD_AUTO but will never be used after.



Also the driver is using registers which should not be touch for the SBSA UART 
(see appendix B in the SBSA ARM-DEN-0029 v3.0). So this need to be address to 
get a proper support.


Yes, I agree with you, Which registers it is touching other than baudrate 
control registers?


Well, I only gave a quick look and noticed the difference between the 
SBSA and the pl011 (e.g CR, IFLS,...) . I am sure you can find out the 
rest of the registers by looking at the code (pl011-uart.h) and the spec.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] arm/gic-v3: Fix driver probe fail on GICv4 hardware

2016-05-27 Thread Shanker Donthineni 


On 05/27/2016 09:07 AM, Julien Grall wrote:
>
>
> On 27/05/16 14:48, Shanker Donthineni wrote:
>> Hi Julien,
>
> Hello Shanker,
>
>> On 05/27/2016 07:35 AM, Julien Grall wrote:
>>> On 27/05/16 00:59, Shanker Donthineni wrote:
 The current driver probe fails on hardware which has GICv4 version,
 even though it is fully compatible to GICv3. This patch fixes the
 issue by registering the same probe function for GICv4 hardware.

 Signed-off-by: Shanker Donthineni 
 ---
xen/arch/arm/gic-v3.c | 13 +
xen/include/asm-arm/gic.h |  1 +
2 files changed, 14 insertions(+)

 diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
 index a095064..594cf6e 100644
 --- a/xen/arch/arm/gic-v3.c
 +++ b/xen/arch/arm/gic-v3.c
 @@ -1604,10 +1604,23 @@ static int __init gicv3_acpi_preinit(const void 
 *data)
return 0;
}

 +static int __init gicv4_acpi_preinit(const void *data)
 +{
 +gicv3_info.hw_version = GIC_V4;
>>>
>>> It will crash Xen as soon as DOM0 is created (see the BUG() in 
>>> arch_domain_create). Please test any patch before sending on the ML.
>>>
>>> Anyway, there is no support of GICv4 in Xen. Instead Xen will drive it 
>>> using the GICv3 driver. So the hardware version should be GIC_V3 here.
>>>
>> Yes, I know I am going to fix in a separate to fix dom0 boot issue some 
>> thing like below.
>
> This should have been in the same patch or before. There is no point to have 
> a patch adding support for GICv4 with ACPI which will lead to an obscure 
> crash (a BUG() rather than a panic with a nice message).
>
Sure, I'll do it in a single patch.
>>   diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
>> index 1365b4a..56a47f5 100644
>> --- a/xen/arch/arm/domain.c
>> +++ b/xen/arch/arm/domain.c
>> @@ -571,6 +571,11 @@ int arch_domain_create(struct domain *d, unsigned int 
>> domcr_flags,
>>   d->arch.vgic.version = GIC_V3;
>>   break;
>>
>> +case GIC_V4:
>> +config->gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
>> +d->arch.vgic.version = GIC_V3;
>> +break;
>
> As mentioned in my previous mail, there is no support of GICv4 in Xen. 
> Although the GICv3 driver is supporting this hardware.So we should not 
> advertise GIC_V4 outside of the driver until Xen will get enough knowledge of 
> GICv4 which will require sensible change in the generic code.
>
GICv4 hardware is fully compatible to GICv3 and has an additional feature vLPI. 
 We don't need any special driver or changes to current driver to support GICv4 
for SPIs/LPIs in Xen just like Linux kernel.

Confused, you are expecting gic_hw_version() should return GIC version number 
'3' on on GICv4 hardware, right?

switch ( gic_hw_version () )
{
case GIC_V2:
config->gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
d->arch.vgic.version = GIC_V2;
break;
case GIC_V3:
config->gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
d->arch.vgic.version = GIC_V3;
break;

> Regards,
>

-- 
Shanker Donthineni
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


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

Re: [Xen-devel] [PATCH v3] x86/mce: handle reserved domain ID in XEN_MC_msrinject

2016-05-27 Thread Jan Beulich 
>>> On 27.05.16 at 15:30,  wrote:
> Commit 26646f3 "x86/mce: translate passed-in GPA to host machine
> address" and commit 4ddf474 "tools/xen-mceinj: Pass in GPA when
> injecting through MSR_MCI_ADDR" forgot to consider reserved domain
> ID and mistakenly add MC_MSRINJ_F_GPADDR flag for them, which in turn
> causes bug reported by
> http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg02640.html.
> 
> This patch removes MC_MSRINK_F_GPADDR flag and checks this when injecting
> to reserved domain IDs except DOMID_SELF, and treats the passed-in
> address as host machine address.
> 
> Signed-off-by: Haozhong Zhang 

Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH] arm/gic-v3: Fix driver probe fail on GICv4 hardware

2016-05-27 Thread Julien Grall 



On 27/05/16 14:48, Shanker Donthineni wrote:

Hi Julien,


Hello Shanker,


On 05/27/2016 07:35 AM, Julien Grall wrote:

On 27/05/16 00:59, Shanker Donthineni wrote:

The current driver probe fails on hardware which has GICv4 version,
even though it is fully compatible to GICv3. This patch fixes the
issue by registering the same probe function for GICv4 hardware.

Signed-off-by: Shanker Donthineni 
---
   xen/arch/arm/gic-v3.c | 13 +
   xen/include/asm-arm/gic.h |  1 +
   2 files changed, 14 insertions(+)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index a095064..594cf6e 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1604,10 +1604,23 @@ static int __init gicv3_acpi_preinit(const void *data)
   return 0;
   }

+static int __init gicv4_acpi_preinit(const void *data)
+{
+gicv3_info.hw_version = GIC_V4;


It will crash Xen as soon as DOM0 is created (see the BUG() in 
arch_domain_create). Please test any patch before sending on the ML.

Anyway, there is no support of GICv4 in Xen. Instead Xen will drive it using 
the GICv3 driver. So the hardware version should be GIC_V3 here.


Yes, I know I am going to fix in a separate to fix dom0 boot issue some thing 
like below.


This should have been in the same patch or before. There is no point to 
have a patch adding support for GICv4 with ACPI which will lead to an 
obscure crash (a BUG() rather than a panic with a nice message).



  diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 1365b4a..56a47f5 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -571,6 +571,11 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
  d->arch.vgic.version = GIC_V3;
  break;

+case GIC_V4:
+config->gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
+d->arch.vgic.version = GIC_V3;
+break;


As mentioned in my previous mail, there is no support of GICv4 in Xen. 
Although the GICv3 driver is supporting this hardware.So we should not 
advertise GIC_V4 outside of the driver until Xen will get enough 
knowledge of GICv4 which will require sensible change in the generic code.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [BUG] win2008 guest cannot get ip through sriov

2016-05-27 Thread Jan Beulich 
>>> On 27.05.16 at 15:34,  wrote:
> On Fri, May 27, 2016 at 06:16:30AM -0600, Jan Beulich wrote:
>> >>> On 27.05.16 at 12:39,  wrote:
>> > Is this a regression? Does it work on previous versions of Xen?
>> 
>> I think this is what was already reported by other Intel people,
>> see e.g. Quan's most recent reply:
>> http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg01896.html 
>> It is not clear where the problem is, and not seeing the issue
>> myself makes it hard to analyze. In any event this quite likely
>> is a regression.
>> 
> 
> My reading of that email thread and all relevant links (including the
> KVM bug report) is that there is a regression vf driver, but not in Xen.

Just from reading that I would tend to agree. But the report here
is about Win2K8.

Jan

> There isn't enough evidence to rule out a bug in Xen, but over all  I'm
> inclined to think this bug is not in Xen given all the things presented.
> 
> Wei.



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

Re: [Xen-devel] [PATCH v3] x86/mce: handle reserved domain ID in XEN_MC_msrinject

2016-05-27 Thread Wei Liu 
On Fri, May 27, 2016 at 08:03:42AM -0600, Jan Beulich wrote:
> >>> On 27.05.16 at 15:30,  wrote:
> > Commit 26646f3 "x86/mce: translate passed-in GPA to host machine
> > address" and commit 4ddf474 "tools/xen-mceinj: Pass in GPA when
> > injecting through MSR_MCI_ADDR" forgot to consider reserved domain
> > ID and mistakenly add MC_MSRINJ_F_GPADDR flag for them, which in turn
> > causes bug reported by
> > http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg02640.html.
> > 
> > This patch removes MC_MSRINK_F_GPADDR flag and checks this when injecting
> > to reserved domain IDs except DOMID_SELF, and treats the passed-in
> > address as host machine address.
> > 
> > Signed-off-by: Haozhong Zhang 
> 
> Reviewed-by: Jan Beulich 
> 

Release-acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] arm/acpi: Add Server Base System Architecture UART support

2016-05-27 Thread Shanker Donthineni 


On 05/27/2016 08:04 AM, Julien Grall wrote:
> Hello Shanker,
>
> On 27/05/16 01:28, Shanker Donthineni wrote:
>> The ARM Server Base System Architecture describes a generic UART
>> interface. It doesn't support clock control registers to set
>> baudrate. So, extend the driver probe() to handle SBSA interface
>> types and set the baudrate to 115200 for SBSA interfaces.
>
> I cannot find any mention of the baudrate in the SBSA. Where does it come 
> from?
>
Yes, no where mentioned about the baudrate in SBSA document. I used 115200 
based on the  the Linux  PL011 driver.

> Also the driver is using registers which should not be touch for the SBSA 
> UART (see appendix B in the SBSA ARM-DEN-0029 v3.0). So this need to be 
> address to get a proper support.
>
Yes, I agree with you, Which registers it is touching other than baudrate 
control registers?

>> Signed-off-by: Shanker Donthineni 
>> ---
>> https://silver.arm.com/download/download.tm?pv=2950177
>>   xen/drivers/char/pl011.c | 25 +
>>   1 file changed, 21 insertions(+), 4 deletions(-)
>>
>> diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
>> index 1212d5c..81d095f 100644
>> --- a/xen/drivers/char/pl011.c
>> +++ b/xen/drivers/char/pl011.c
>> @@ -226,14 +226,14 @@ static struct uart_driver __read_mostly pl011_driver = 
>> {
>>   .vuart_info   = pl011_vuart,
>>   };
>>
>> -static int __init pl011_uart_init(int irq, u64 addr, u64 size)
>> +static int __init pl011_uart_init(int irq, u64 addr, u64 size, int baud)
>>   {
>>   struct pl011 *uart;
>>
>>   uart = _com;
>>   uart->irq   = irq;
>>   uart->clock_hz  = 0x16e3600;
>> -uart->baud  = BAUD_AUTO;
>> +uart->baud  = baud;
>>   uart->data_bits = 8;
>>   uart->parity= PARITY_NONE;
>>   uart->stop_bits = 1;
>> @@ -285,7 +285,7 @@ static int __init pl011_dt_uart_init(struct 
>> dt_device_node *dev,
>>   return -EINVAL;
>>   }
>>
>> -res = pl011_uart_init(res, addr, size);
>> +res = pl011_uart_init(res, addr, size, BAUD_AUTO);
>>   if ( res < 0 )
>>   {
>>   printk("pl011: Unable to initialize\n");
>> @@ -315,6 +315,7 @@ static int __init pl011_acpi_uart_init(const void *data)
>>   {
>>   acpi_status status;
>>   struct acpi_table_spcr *spcr = NULL;
>> +int baud = BAUD_AUTO;
>>   int res;
>>
>>   status = acpi_get_table(ACPI_SIG_SPCR, 0,
>> @@ -326,17 +327,23 @@ static int __init pl011_acpi_uart_init(const void 
>> *data)
>>   return -EINVAL;
>>   }
>>
>> +if ( (spcr->interface_type == ACPI_DBG2_SBSA_32) ||
>
> Based on the DBG2 spec, this value is deprecated. So I do not think we should 
> support it.
>

I'll fix.

>> + (spcr->interface_type == ACPI_DBG2_SBSA) )
>> +baud = 115200;
>> +
>>   /* trigger/polarity information is not available in spcr */
>>   irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH);
>>
>>   res = pl011_uart_init(spcr->interrupt, spcr->serial_port.address,
>> -  PAGE_SIZE);
>> +  PAGE_SIZE, baud);
>>   if ( res < 0 )
>>   {
>>   printk("pl011: Unable to initialize\n");
>>   return res;
>>   }
>>
>> +
>> +
>
> Spurious changes.
>
>>   return 0;
>>   }
>>
>> @@ -344,6 +351,16 @@ ACPI_DEVICE_START(apl011, "PL011 UART", DEVICE_SERIAL)
>>   .class_type = ACPI_DBG2_PL011,
>>   .init = pl011_acpi_uart_init,
>>   ACPI_DEVICE_END
>> +
>> +ACPI_DEVICE_START(asbsa_uart, "SBSA UART", DEVICE_SERIAL)
>> +.class_type = ACPI_DBG2_SBSA,
>> +.init = pl011_acpi_uart_init,
>> +ACPI_DEVICE_END
>> +
>> +ACPI_DEVICE_START(asbsa32_uart, "SBSA32 UART", DEVICE_SERIAL)
>> +.class_type = ACPI_DBG2_SBSA_32,
>> +.init = pl011_acpi_uart_init,
>> +ACPI_DEVICE_END
>>   #endif
>>
>>   /*
>>
>
> Regards,
>

-- 
Shanker Donthineni
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


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

Re: [Xen-devel] [PATCH v2 3/4] VMX: Assign the right value to 'NDST' field in a concern case

2016-05-27 Thread Jan Beulich 
>>> On 26.05.16 at 15:39,  wrote:
> Normally, in vmx_cpu_block() 'NDST' filed should have the same
> value with 'dest' or 'MASK_INSR(dest, PI_xAPIC_NDST_MASK)' depending
> on whether x2apic is enabled. However, in the following scenario,
> 'NDST' has different value:
> 
> 'vcpu_block' hook gets assigned in vmx_pi_hooks_assign(), but all
> other three PI hooks have not been assigned or not been excuted yet.
> And during this interval, we are running in vmx_vcpu_block(), then
> 'NDST' may have different value.

How about simply assigning vcpu_block last? Or alternatively
holding pi_blocking_list_lock around all four assignments? Or
(maybe in addition to one of these) writing something sensible in
vmx_pi_hooks_assign() before doing the hook assignments? Of
course much depends on whether the ASSERT() you replace was
meant just as a sanity check, or instead logic elsewhere relies on
NDST having the right value already before getting into
vmx_vcpu_block().

Also, rather than saying twice that NDST has a different value in
that case, how about stating what exact value it has then and
why that's not what we want/need? (Same goes for the code
comment then.)

> This patch fix this concern case.

Here as well as in earlier patches - do you perhaps mean "corner
case"?

Jan


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

Re: [Xen-devel] [PATCH] arm/acpi: Fix the deadlock in function vgic_lock_rank()

2016-05-27 Thread Julien Grall 

Hello Shanker,

On 27/05/16 01:39, Shanker Donthineni wrote:

Commit 9d77b3c01d1261c (Configure SPI interrupt type and route to
Dom0 dynamically) causing dead loop inside the spinlock function.
Note that spinlocks in XEN are not recursive. Re-acquiring a spinlock
that has already held by calling CPU leads to deadlock. This happens
whenever dom0 does writes to GICD regs ISENABLER/ICENABLER.


Thank you for spotting it, I have not noticed it while I was  reviewing, 
only tested on a model without any SPIs.



The following call trace explains the problem.

DOM0 writes GICD_ISENABLER/GICD_ICENABLER
   vgic_v3_distr_common_mmio_write()
 vgic_lock_rank()  -->  acquiring first time
   vgic_enable_irqs()
 route_irq_to_guest()
   gic_route_irq_to_guest()
 vgic_get_target_vcpu()
   vgic_lock_rank()  -->  attemping acquired lock

The simple fix release spinlock before calling vgic_enable_irqs()
and vgic_disable_irqs().


You should explain why you think it is valid to release the lock earlier.

In this case, I think the fix is not correct because the lock is 
protecting both the register value and the internal state in Xen 
(modified by vgic_enable_irqs). By releasing the lock earlier, they may 
become inconsistent if another vCPU is disabling the IRQs at the same time.


I cannot find an easy fix which does not involve release the lock. When 
I was reviewing this patch, I suggested to split the IRQ configuration 
from the routing.


The routing (call to route_irq_to_guest) will be done before DOM0 is 
booting. The IRQ configuration will be done in the ICFGR register.


This will also help for PCI-passthrough as the guest will have to 
configure the SPIs (we can't expect DOM0 doing it for it). But the 
routing will be done ahead.


This would resolve the locking issue, however it is a big task. Feel 
free to suggest a simpler one.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 2/4] VMX: Cleanup PI per-cpu blocking list when vcpu is destroyed

2016-05-27 Thread Jan Beulich 
>>> On 26.05.16 at 15:39,  wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -366,6 +366,7 @@ static void vmx_vcpu_destroy(struct vcpu *v)
>  vmx_destroy_vmcs(v);
>  vpmu_destroy(v);
>  passive_domain_destroy(v);
> +vmx_pi_blocking_cleanup(v);
>  }

Isn't this redundant with the cleanup done when the last device
gets removed (via pci_release_devices()) during domain cleanup?

Jan


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

Re: [Xen-devel] [PATCH] arm/gic-v3: Fix driver probe fail on GICv4 hardware

2016-05-27 Thread Shanker Donthineni 
Hi Julien,

On 05/27/2016 07:35 AM, Julien Grall wrote:
> Hello Shanker,
>
> Please mention in the title and the commit message that is patch is ACPI only.
>

I'll change commit text.
> On 27/05/16 00:59, Shanker Donthineni wrote:
>> The current driver probe fails on hardware which has GICv4 version,
>> even though it is fully compatible to GICv3. This patch fixes the
>> issue by registering the same probe function for GICv4 hardware.
>>
>> Signed-off-by: Shanker Donthineni 
>> ---
>>   xen/arch/arm/gic-v3.c | 13 +
>>   xen/include/asm-arm/gic.h |  1 +
>>   2 files changed, 14 insertions(+)
>>
>> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
>> index a095064..594cf6e 100644
>> --- a/xen/arch/arm/gic-v3.c
>> +++ b/xen/arch/arm/gic-v3.c
>> @@ -1604,10 +1604,23 @@ static int __init gicv3_acpi_preinit(const void 
>> *data)
>>   return 0;
>>   }
>>
>> +static int __init gicv4_acpi_preinit(const void *data)
>> +{
>> +gicv3_info.hw_version = GIC_V4;
>
> It will crash Xen as soon as DOM0 is created (see the BUG() in 
> arch_domain_create). Please test any patch before sending on the ML.
>
> Anyway, there is no support of GICv4 in Xen. Instead Xen will drive it using 
> the GICv3 driver. So the hardware version should be GIC_V3 here.
>
Yes, I know I am going to fix in a separate to fix dom0 boot issue some thing 
like below.

 diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 1365b4a..56a47f5 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -571,6 +571,11 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 d->arch.vgic.version = GIC_V3;
 break;
 
+case GIC_V4:
+config->gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
+d->arch.vgic.version = GIC_V3;
+break;
+
 default:
 BUG();
 }

-- 
Shanker Donthineni
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


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

Re: [Xen-devel] [BUG] IGD-PT doesn't work on Skylake-S client

2016-05-27 Thread Konrad Rzeszutek Wilk 
On Fri, May 27, 2016 at 06:57:19AM +, Zhang, PengtaoX wrote:
> Bug detailed description:
> 
> 1. Create a rhel7.1 guest with IGD-PT on SKL-S client , login guest and run 
> 3D(nexuiz) , opencl(beignet) , media(transcode ,encode,decode) test , all 
> test are run failed .
> 2. All these test could run pass on Boardwell-UP platform .

The logs all say Xen 4.6? Is that intentional?

> 3. The SKL-H client and BDW-UP platform are using the same hard disk to test .
> 
> Environment :
> 
> HW: Skylake-S
> Xen: Xen 4.7.0 RC3
> Dom0: Linux 4.6.0
> 
> Reproduce steps:
> 
> 1.Install redhat 6.7 OS on Skylake-S client as base OS , then compile and 
> install  ,xen and Dom0, reboot from xen .
> 2.Create a rhel7.1 guest (include 3D, OpenCL ,Media SDK) with IGD-PT .
>   Hide graphic  device by : xl pci-assignable-add 00:02.0
>   Create guest by : xl create config-hvm.log
> 3.Login guest and run 3D , OpenCL , Media test .
> 
> Current result:
> 
> All 3D ,Opencl ,Media test are failed on Skylake-S client .

Are the PCI configuration registers different when you setup the guest between
Skylake-S and Broadwell? Or are they the same?


> 
> Base error log:
> 
> I attached both Boardwell-UP and Skylake-S test log .
> 
> Regards,
> Pengtao










> ___
> 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] [PATCH v2 1/4] VMX: Properly handle pi when all the assigned devices are removed

2016-05-27 Thread Jan Beulich 
>>> On 26.05.16 at 15:39,  wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -113,7 +113,19 @@ static void vmx_vcpu_block(struct vcpu *v)
>   _cpu(vmx_pi_blocking, v->processor).lock;
>  struct pi_desc *pi_desc = >arch.hvm_vmx.pi_desc;
>  
> -spin_lock_irqsave(pi_blocking_list_lock, flags);
> +spin_lock_irqsave(>arch.hvm_vmx.pi_hotplug_lock, flags);
> +if ( unlikely(v->arch.hvm_vmx.pi_blocking_cleaned_up) )
> +{
> +/*
> + * The vcpu is to be destroyed and it has already been removed
> + * from the per-CPU list if it is blocking, we shouldn't add
> + * new vCPU to the list.
> + */

This comment appears to be stale wrt the implementation further
down. But see there for whether it's the comment or the code
that need to change.

> +spin_unlock_irqrestore(>arch.hvm_vmx.pi_hotplug_lock, flags);
> +return;
> +}
> +
> +spin_lock(pi_blocking_list_lock);

There doesn't appear to be an active problem with this, but
taking a global lock inside a per-vCPU one feels bad. Both here
and in vmx_pi_blocking_cleanup() I can't see why the global
lock alone won't do - you acquire it anyway.

> +static void vmx_pi_blocking_cleanup(struct vcpu *v)
> +{
> +unsigned long flags;
> +spinlock_t *pi_blocking_list_lock;
> +
> +if ( !iommu_intpost )
> +return;

If the function is to remain to be called from just the body of a loop
over all vCPU-s, please make that loop conditional upon iommu_intpost
instead of checking it here (and bailing) for every vCPU.

> +spin_lock_irqsave(>arch.hvm_vmx.pi_hotplug_lock, flags);
> +v->arch.hvm_vmx.pi_blocking_cleaned_up = 1;
> +
> +pi_blocking_list_lock = v->arch.hvm_vmx.pi_blocking.lock;
> +if (pi_blocking_list_lock == NULL)

Coding style.

> +{
> +spin_unlock_irqrestore(>arch.hvm_vmx.pi_hotplug_lock, flags);
> +return;
> +}
> +
> +spin_lock(pi_blocking_list_lock);
> +if ( v->arch.hvm_vmx.pi_blocking.lock != NULL )
> +{
> +ASSERT(v->arch.hvm_vmx.pi_blocking.lock == pi_blocking_list_lock);
> +list_del(>arch.hvm_vmx.pi_blocking.list);
> +v->arch.hvm_vmx.pi_blocking.lock = NULL;
> +}
> +spin_unlock(pi_blocking_list_lock);
> +spin_unlock_irqrestore(>arch.hvm_vmx.pi_hotplug_lock, flags);
> +}
> +
>  /* This function is called when pcidevs_lock is held */
>  void vmx_pi_hooks_assign(struct domain *d)
>  {
> +struct vcpu *v;
> +
>  if ( !iommu_intpost || !has_hvm_container_domain(d) )
>  return;
>  
> -ASSERT(!d->arch.hvm_domain.vmx.vcpu_block);
> +for_each_vcpu ( d, v )
> +v->arch.hvm_vmx.pi_blocking_cleaned_up = 0;
>  
> -d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
> -d->arch.hvm_domain.vmx.pi_switch_from = vmx_pi_switch_from;
> -d->arch.hvm_domain.vmx.pi_switch_to = vmx_pi_switch_to;
> -d->arch.hvm_domain.vmx.pi_do_resume = vmx_pi_do_resume;
> +if ( !d->arch.hvm_domain.vmx.vcpu_block )
> +{
> +d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
> +d->arch.hvm_domain.vmx.pi_switch_from = vmx_pi_switch_from;
> +d->arch.hvm_domain.vmx.pi_switch_to = vmx_pi_switch_to;
> +d->arch.hvm_domain.vmx.pi_do_resume = vmx_pi_do_resume;
> +}
>  }
>  
>  /* This function is called when pcidevs_lock is held */
>  void vmx_pi_hooks_deassign(struct domain *d)
>  {
> +struct vcpu *v;
> +
>  if ( !iommu_intpost || !has_hvm_container_domain(d) )
>  return;
>  
> -ASSERT(d->arch.hvm_domain.vmx.vcpu_block);
> -
> -d->arch.hvm_domain.vmx.vcpu_block = NULL;
> -d->arch.hvm_domain.vmx.pi_switch_from = NULL;
> -d->arch.hvm_domain.vmx.pi_switch_to = NULL;
> -d->arch.hvm_domain.vmx.pi_do_resume = NULL;
> +for_each_vcpu ( d, v )
> +vmx_pi_blocking_cleanup(v);

If you keep the hooks in place, why is it relevant to do the cleanup
here instead of just at domain death? As suggested before, if you
did it there, you'd likely get away without adding the new per-vCPU
flag.

Furthermore, if things remain the way they are now, a per-domain
flag would suffice.

And finally - do you really need to retain all four hooks? Since if not,
one that gets zapped here could be used in place of such a per-
domain flag.

> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
> +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
> @@ -231,6 +231,9 @@ struct arch_vmx_struct {
>   * pCPU and wakeup the related vCPU.
>   */
>  struct pi_blocking_vcpu pi_blocking;
> +
> +spinlock_tpi_hotplug_lock;

Being through all of the patch, I have a problem seeing the hotplug
nature of this.

> +bool_tpi_blocking_cleaned_up;

If this flag is to remain, it should move into its designated structure
(right above your addition).

Jan

___
Xen-devel mailing list
Xen-devel@lists.xen.org

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

2016-05-27 Thread osstest service owner 
flight 94827 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94827/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  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-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-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
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 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  111 days
Testing same since93977  2016-05-10 11:09:16 Z   17 days   67 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] xsplice: should we use realpath or readlink in xsplice-build?

2016-05-27 Thread Konrad Rzeszutek Wilk 
On Fri, May 27, 2016 at 04:43:48PM +0800, Dongli Zhang wrote:
> Hi Ross and Konrad,

Heya!
> 
> I played xsplice with a sample patch I wrote. It works and really fantastic
> work! 
> 
> I use the utility from
> git://xenbits.xen.org/people/konradwilk/xsplice-build-tools.git
> 
> However, the 'realpath -m' command in file 'xsplice-build' work on neither my
> Ubuntu or Oracle Linuxi (no -m option). It works well after I replace all
> 'realpath' with 'readlink'. The patch elf was generated successfully and could
> be uploaded and applied.
> 
> I am not sure if this is the issue with my OS configuration or we should 
> better
> use 'readlink'. Since this is the new git repo, I am not sure if I could 
> submit
> this patch to xen-devel if a patch is helpful.

Go for it! (Aka submit the patch pls)

> 
> Thank you very much!
> 
> Best,
> 
> Dongli Zhang
> 
> 

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

Re: [Xen-devel] [BUG] win2008 guest cannot get ip through sriov

2016-05-27 Thread Wei Liu 
On Fri, May 27, 2016 at 06:16:30AM -0600, Jan Beulich wrote:
> >>> On 27.05.16 at 12:39,  wrote:
> > Is this a regression? Does it work on previous versions of Xen?
> 
> I think this is what was already reported by other Intel people,
> see e.g. Quan's most recent reply:
> http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg01896.html
> It is not clear where the problem is, and not seeing the issue
> myself makes it hard to analyze. In any event this quite likely
> is a regression.
> 

My reading of that email thread and all relevant links (including the
KVM bug report) is that there is a regression vf driver, but not in Xen.

There isn't enough evidence to rule out a bug in Xen, but over all  I'm
inclined to think this bug is not in Xen given all the things presented.

Wei.

> Jan
> 

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

[Xen-devel] [PATCH v3] x86/mce: handle reserved domain ID in XEN_MC_msrinject

2016-05-27 Thread Haozhong Zhang 
Commit 26646f3 "x86/mce: translate passed-in GPA to host machine
address" and commit 4ddf474 "tools/xen-mceinj: Pass in GPA when
injecting through MSR_MCI_ADDR" forgot to consider reserved domain
ID and mistakenly add MC_MSRINJ_F_GPADDR flag for them, which in turn
causes bug reported by
http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg02640.html.

This patch removes MC_MSRINK_F_GPADDR flag and checks this when injecting
to reserved domain IDs except DOMID_SELF, and treats the passed-in
address as host machine address.

Signed-off-by: Haozhong Zhang 
---
Changes in v3:
 * Refine check condition of domid.

Changes in v2:
 * Consider all reserved domain IDs rather than just DOMID_XEN.

v1 can be found at
http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg02534.html.
---
 tools/tests/mce-test/tools/xen-mceinj.c |  5 -
 xen/arch/x86/cpu/mcheck/mce.c   | 14 +++---
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/tools/tests/mce-test/tools/xen-mceinj.c 
b/tools/tests/mce-test/tools/xen-mceinj.c
index 061ec7c..51abc8a 100644
--- a/tools/tests/mce-test/tools/xen-mceinj.c
+++ b/tools/tests/mce-test/tools/xen-mceinj.c
@@ -317,7 +317,10 @@ static int inject_mci_addr(xc_interface *xc_handle,
domid_t domid)
 {
 return add_msr_bank_intpose(xc_handle, cpu_nr,
-MC_MSRINJ_F_INTERPOSE | MC_MSRINJ_F_GPADDR,
+MC_MSRINJ_F_INTERPOSE |
+((domid >= DOMID_FIRST_RESERVED &&
+  domid != DOMID_SELF) ?
+ 0 : MC_MSRINJ_F_GPADDR),
 MCi_type_ADDR, bank, val, domid);
 }
 
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index cc446eb..0244553 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1427,6 +1427,7 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
 
 if ( mc_msrinject->mcinj_flags & MC_MSRINJ_F_GPADDR )
 {
+domid_t domid;
 struct domain *d;
 struct mcinfo_msr *msr;
 unsigned int i;
@@ -1434,10 +1435,17 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
 unsigned long gfn, mfn;
 p2m_type_t t;
 
-d = get_domain_by_id(mc_msrinject->mcinj_domid);
+domid = (mc_msrinject->mcinj_domid == DOMID_SELF) ?
+current->domain->domain_id : mc_msrinject->mcinj_domid;
+if ( domid >= DOMID_FIRST_RESERVED )
+return x86_mcerr("do_mca inject: incompatible flag "
+ "MC_MSRINJ_F_GPADDR with domain %d",
+ -EINVAL, domid);
+
+d = get_domain_by_id(domid);
 if ( d == NULL )
 return x86_mcerr("do_mca inject: bad domain id %d",
- -EINVAL, mc_msrinject->mcinj_domid);
+ -EINVAL, domid);
 
 for ( i = 0, msr = _msrinject->mcinj_msr[0];
   i < mc_msrinject->mcinj_count;
@@ -1452,7 +1460,7 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
 put_gfn(d, gfn);
 put_domain(d);
 return x86_mcerr("do_mca inject: bad gfn %#lx of domain 
%d",
- -EINVAL, gfn, mc_msrinject->mcinj_domid);
+ -EINVAL, gfn, domid);
 }
 
 msr->value = pfn_to_paddr(mfn) | (gaddr & (PAGE_SIZE - 1));
-- 
2.8.3


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

Re: [Xen-devel] Basic bare metal ARM domain interface

2016-05-27 Thread Ivan Pavić2 
Hello, 

Jullien, thanks for docs and references. 

I used FreeRTOS code for console output. It is based on Mini OS code. There are 
two problems as I've determined with debugging. First is that vsnprintf blocks 
for some reason in print function so i commented it out. After the hypercall 
function blocked as well. I modified hypercall function so it looks like this:

(void)HYPERVISOR_console_io(CONSOLEIO_write, 3, "yes");

hoping to get "yes" as output..., but this blocked as well.

xenctx output after HYPERVISOR_console_io:

PC:   4000828c
CPSR: 21d7
USR:   SP: LR:
SVC: SPSR: SP:4011bff4 LR:4000a37f
FIQ: SPSR: SP:40124200 LR:
IRQ: SPSR: SP:40120200 LR:
ABT: SPSR:21f7 SP:40008140 LR:3f741306
UND: SPSR: SP:4012c200 LR:

 r0_usr: 4000815fr1_usr: r2_usr: 40008160
 r3_usr: 4000815cr4_usr: a338r5_usr: 4000c948
 r6_usr: r7_usr: 4000a53cr8_usr: 
 r9_usr:    r10_usr: 0065   r11_usr: 
r12_usr: 

 r8_fiq: 
 r9_fiq:    r10_fiq:    r11_fiq: 
r12_fiq: 

SCTLR: 00c50078
TTBCR: 
TTBR0: 
TTBR1: 

r10 = 101, I used it for debugging, to locate code where it is stuck. What 
could it be?

Thanks in advance,

Ivan Pavic.


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

Re: [Xen-devel] [PATCH v3] AMD IOMMU: Introduce support for IVHD block type 11h

2016-05-27 Thread Jan Beulich 
>>> On 26.05.16 at 04:50,  wrote:
> --- a/xen/drivers/passthrough/amd/iommu_acpi.c
> +++ b/xen/drivers/passthrough/amd/iommu_acpi.c
> @@ -821,13 +821,29 @@ static u16 __init parse_ivhd_device_special(
>  return dev_length;
>  }
>  
> +static inline size_t

I see Andrew has talked you into using size_t instead of unsigned int
here, yet I have to admit I don't really see why. Andrew?

> +get_ivhd_header_size(const struct acpi_ivrs_hardware *ivhd_block)
> +{
> +switch ( ivhd_block->header.type )
> +{
> +case ACPI_IVRS_TYPE_HARDWARE:
> +return offsetof(struct acpi_ivrs_hardware, efr_image);
> +case ACPI_IVRS_TYPE_HARDWARE_11H:
> +return sizeof(struct acpi_ivrs_hardware);
> +default:
> +break;

I would have thought I had complained about this pointless default
case, but it looks like I didn't look at v2 at all after Andrew did. But
anyway, you're the maintainer of the code, so if you like it this
way...

> @@ -978,6 +966,25 @@ static void __init dump_acpi_table_header(struct 
> acpi_table_header *table)
>  
>  }
>  
> +#define to_ivhd_block(hdr) \
> +container_of(hdr, const struct acpi_ivrs_hardware, header)
> +#define to_ivmd_block(hdr) \
> +container_of(hdr, const struct acpi_ivrs_memory, header)
> +
> +static inline bool_t is_ivhd_block(u8 type)
> +{
> +return ( type == ACPI_IVRS_TYPE_HARDWARE ||
> + type == ACPI_IVRS_TYPE_HARDWARE_11H );

Stray blanks.

> +static inline bool_t is_ivmd_block(u8 type) \
> +{
> +return ( type == ACPI_IVRS_TYPE_MEMORY_ALL ||
> + type == ACPI_IVRS_TYPE_MEMORY_ONE ||
> + type == ACPI_IVRS_TYPE_MEMORY_RANGE ||
> + type == ACPI_IVRS_TYPE_MEMORY_IOMMU );

Again.

With at least these last two issues taken care of
Reviewed-by: Jan Beulich 

And just like Andrew said, these could be taken care of upon
commit.

Jan


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

Re: [Xen-devel] [PATCH] arm/acpi: Add Server Base System Architecture UART support

2016-05-27 Thread Julien Grall 

Hello Shanker,

On 27/05/16 01:28, Shanker Donthineni wrote:

The ARM Server Base System Architecture describes a generic UART
interface. It doesn't support clock control registers to set
baudrate. So, extend the driver probe() to handle SBSA interface
types and set the baudrate to 115200 for SBSA interfaces.


I cannot find any mention of the baudrate in the SBSA. Where does it 
come from?


Also the driver is using registers which should not be touch for the 
SBSA UART (see appendix B in the SBSA ARM-DEN-0029 v3.0). So this need 
to be address to get a proper support.



Signed-off-by: Shanker Donthineni 
---
https://silver.arm.com/download/download.tm?pv=2950177
  xen/drivers/char/pl011.c | 25 +
  1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index 1212d5c..81d095f 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -226,14 +226,14 @@ static struct uart_driver __read_mostly pl011_driver = {
  .vuart_info   = pl011_vuart,
  };

-static int __init pl011_uart_init(int irq, u64 addr, u64 size)
+static int __init pl011_uart_init(int irq, u64 addr, u64 size, int baud)
  {
  struct pl011 *uart;

  uart = _com;
  uart->irq   = irq;
  uart->clock_hz  = 0x16e3600;
-uart->baud  = BAUD_AUTO;
+uart->baud  = baud;
  uart->data_bits = 8;
  uart->parity= PARITY_NONE;
  uart->stop_bits = 1;
@@ -285,7 +285,7 @@ static int __init pl011_dt_uart_init(struct dt_device_node 
*dev,
  return -EINVAL;
  }

-res = pl011_uart_init(res, addr, size);
+res = pl011_uart_init(res, addr, size, BAUD_AUTO);
  if ( res < 0 )
  {
  printk("pl011: Unable to initialize\n");
@@ -315,6 +315,7 @@ static int __init pl011_acpi_uart_init(const void *data)
  {
  acpi_status status;
  struct acpi_table_spcr *spcr = NULL;
+int baud = BAUD_AUTO;
  int res;

  status = acpi_get_table(ACPI_SIG_SPCR, 0,
@@ -326,17 +327,23 @@ static int __init pl011_acpi_uart_init(const void *data)
  return -EINVAL;
  }

+if ( (spcr->interface_type == ACPI_DBG2_SBSA_32) ||


Based on the DBG2 spec, this value is deprecated. So I do not think we 
should support it.



+ (spcr->interface_type == ACPI_DBG2_SBSA) )
+baud = 115200;
+
  /* trigger/polarity information is not available in spcr */
  irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH);

  res = pl011_uart_init(spcr->interrupt, spcr->serial_port.address,
-  PAGE_SIZE);
+  PAGE_SIZE, baud);
  if ( res < 0 )
  {
  printk("pl011: Unable to initialize\n");
  return res;
  }

+
+


Spurious changes.


  return 0;
  }

@@ -344,6 +351,16 @@ ACPI_DEVICE_START(apl011, "PL011 UART", DEVICE_SERIAL)
  .class_type = ACPI_DBG2_PL011,
  .init = pl011_acpi_uart_init,
  ACPI_DEVICE_END
+
+ACPI_DEVICE_START(asbsa_uart, "SBSA UART", DEVICE_SERIAL)
+.class_type = ACPI_DBG2_SBSA,
+.init = pl011_acpi_uart_init,
+ACPI_DEVICE_END
+
+ACPI_DEVICE_START(asbsa32_uart, "SBSA32 UART", DEVICE_SERIAL)
+.class_type = ACPI_DBG2_SBSA_32,
+.init = pl011_acpi_uart_init,
+ACPI_DEVICE_END
  #endif

  /*



Regards,

--
Julien Grall

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

[Xen-devel] [PATCH 2/3] qemu-xen-dir/hw/block/xen_disk: Replace grant map by grant copy.

2016-05-27 Thread Paulina Szubarczyk 
Grant copy operation is divided into two phases different for
'read' and 'write' operation.

For a 'read' operation the flow is as follow:
1. allocate local buffers for all the segments contained in
   a request.
2. fill the request io vectors with the buffers' addresses
3. invoke read operation by qemu device
4. in the completition call grant copy
5. free the buffers

Function 'ioreq_read_init' implements 1. and 2. step. It is called
instead of 'ioreq_map' in 'ioreq_runio_qemu_aio'. Then the function
'ioreq_runio_qemu_aio' continues withouth changes performing step 3.
Steps 4. and 5. are called in the callback function
'qemu_aio_complete'. The ioreq_read' function is implemented for
step 4 which calls the new function 'xc_gnttab_copy_grant' presented
in the other part of the patch.

For a 'write' operation steps 4. happens before step 2.. First data
are copied from calling guest domains and then qemu operates on them.
For that step 'ioreq_write' function is added.

The function for grant map operation are removed.
---
 hw/block/xen_disk.c | 419 +---
 1 file changed, 170 insertions(+), 249 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 37e14d1..3e5eefd 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -79,13 +79,12 @@ struct ioreq {
 int postsync;
 uint8_t mapped;
 
-/* grant mapping */
-uint32_tdomids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+/* grant copy */
+uint16_tdomids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 uint32_trefs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 int prot;
 void*page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 void*pages;
-int num_unmap;
 
 /* aio status */
 int aio_inflight;
@@ -123,13 +122,8 @@ struct XenBlkDev {
 int requests_inflight;
 int requests_finished;
 
-/* Persistent grants extension */
+/* */
 gbooleanfeature_discard;
-gbooleanfeature_persistent;
-GTree   *persistent_gnts;
-GSList  *persistent_regions;
-unsigned intpersistent_gnt_count;
-unsigned intmax_grants;
 
 /* qemu block driver */
 DriveInfo   *dinfo;
@@ -164,46 +158,6 @@ static void ioreq_reset(struct ioreq *ioreq)
 qemu_iovec_reset(>v);
 }
 
-static gint int_cmp(gconstpointer a, gconstpointer b, gpointer user_data)
-{
-uint ua = GPOINTER_TO_UINT(a);
-uint ub = GPOINTER_TO_UINT(b);
-return (ua > ub) - (ua < ub);
-}
-
-static void destroy_grant(gpointer pgnt)
-{
-PersistentGrant *grant = pgnt;
-XenGnttab gnt = grant->blkdev->xendev.gnttabdev;
-
-if (xc_gnttab_munmap(gnt, grant->page, 1) != 0) {
-xen_be_printf(>blkdev->xendev, 0,
-  "xc_gnttab_munmap failed: %s\n",
-  strerror(errno));
-}
-grant->blkdev->persistent_gnt_count--;
-xen_be_printf(>blkdev->xendev, 3,
-  "unmapped grant %p\n", grant->page);
-g_free(grant);
-}
-
-static void remove_persistent_region(gpointer data, gpointer dev)
-{
-PersistentRegion *region = data;
-struct XenBlkDev *blkdev = dev;
-XenGnttab gnt = blkdev->xendev.gnttabdev;
-
-if (xc_gnttab_munmap(gnt, region->addr, region->num) != 0) {
-xen_be_printf(>xendev, 0,
-  "xc_gnttab_munmap region %p failed: %s\n",
-  region->addr, strerror(errno));
-}
-xen_be_printf(>xendev, 3,
-  "unmapped grant region %p with %d pages\n",
-  region->addr, region->num);
-g_free(region);
-}
-
 static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
 {
 struct ioreq *ioreq = NULL;
@@ -314,7 +268,9 @@ static int ioreq_parse(struct ioreq *ioreq)
 ioreq->refs[i]   = ioreq->req.seg[i].gref;
 
 mem = ioreq->req.seg[i].first_sect * blkdev->file_blk;
-len = (ioreq->req.seg[i].last_sect - ioreq->req.seg[i].first_sect + 1) 
* blkdev->file_blk;
+len = (ioreq->req.seg[i].last_sect - ioreq->req.seg[i].first_sect + 1) 
+  * blkdev->file_blk;
+
 qemu_iovec_add(>v, (void*)mem, len);
 }
 if (ioreq->start + ioreq->v.size > blkdev->file_size) {
@@ -328,175 +284,151 @@ err:
 return -1;
 }
 
-static void ioreq_unmap(struct ioreq *ioreq)
+static void* get_buffer(void) {
+void *buf;
+
+buf = mmap(NULL, 1 << XC_PAGE_SHIFT, PROT_READ | PROT_WRITE, 
+   MAP_SHARED | MAP_ANONYMOUS, -1, 0);
+
+if (unlikely(buf == MAP_FAILED))
+return NULL;
+
+return buf;
+}
+
+static int free_buffer(void* buf) {
+return munmap(buf, 1 << XC_PAGE_SHIFT);
+}
+
+static int free_buffers(void** page, int count) 
+{
+int i, r = 0;
+
+for (i = 0; i < count; i++) { 
+
+if(free_buffer(page[i])) 
+r = 1;
+

[Xen-devel] [PATCH 0/3] qemu-qdisk: Replace grant map by grant copy.

2016-05-27 Thread Paulina Szubarczyk 
Hi, 

It is a proposition for implementation of the replacement of the grant map 
operation with grant copy. 

I would appreciate an opinion about the approach if is proper or maybe 
I assumed something wrongly, and if you see any possibility of improvement
or the things that need to be change.
If the approach is any good, I need to still rethink batch mode, notification 
and implementation for mini-os.

In the libs, gnttab, linbxc there is added interface and invocation of 
an ioctl(gntdev, IOCTL_GNTDEV_GRANT_COPY, ..) system call on the gnttdev 
device. 
Described in details in the following messages. It is not implemented for 
mini-os.

The grant map operation is replaced on the behalf of grant copy in 
qemu-xen-dir/hw/block/xen_disk. The implementation is described in the patch.

For the functional test I attached the device with a qdisk backend to the guest.
I successfully mounted it and stored files there. During creation of 
a file system on the device BLKIF_OP_DISCARD operation seems to fail(ret value 
different then zero) but it also fails for the original version due to error 
return from qemu.

I made fio tests before[0] and after[1] the changes with different iodepth and 
size of the block. The test which I run can be accessed on my github[2] but 
mainly after the warm up I run for 60 seconds:
fio --time_based \
--clocksource=clock_gettime \
--rw=randread \
--random_distribution=pareto:0.9 \
--size=10g \
--direct='1' \
--ioengine=libaio \
--filename=$DEV \
--iodepth=$IODEPTH \
--bs=$BS \
--name=$NAME \
--runtime=$RUNTIME >> $FILENAME
The test were repeated at least three times. 

Although before the changes results looks coherent for me, after there are
considerable peaks for iodepth = {4,8}.

[0] 
https://docs.google.com/spreadsheets/d/1n0lraodhF5jlNO-YWNTgl57Aoe3K5S7Qke8YQQkGCDQ/edit?usp=sharing
[1] 
https://docs.google.com/spreadsheets/d/1E6AMiB8ceJpExL6jWpH9u2yy6DZxzhmDUyFf-eUuJ0c/edit?usp=sharing
- domU sheets
[2] https://github.com/paulina-szubarczyk/xen-benchmark
- multitest_with_iodepth.sh


Thanks and regards, 
Paulina

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

[Xen-devel] [PATCH 3/3] qemu-xen-dir/hw/block: Cache local buffers used in grant copy

2016-05-27 Thread Paulina Szubarczyk 
If there are still pending requests the buffers are not free() but
cached in an array of a size max_request*BLKIF_MAX_SEGMENTS_PER_REQUEST
---
 hw/block/xen_disk.c | 59 ++---
 1 file changed, 47 insertions(+), 12 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 3e5eefd..ab1863b 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -125,6 +125,10 @@ struct XenBlkDev {
 /* */
 gbooleanfeature_discard;
 
+/* request buffer cache */
+void**buf_cache;
+int buf_cache_free;
+
 /* qemu block driver */
 DriveInfo   *dinfo;
 BlockBackend*blk;
@@ -284,11 +288,16 @@ err:
 return -1;
 }
 
-static void* get_buffer(void) {
+static void* get_buffer(struct XenBlkDev *blkdev) {
 void *buf;
 
-buf = mmap(NULL, 1 << XC_PAGE_SHIFT, PROT_READ | PROT_WRITE, 
+if(blkdev->buf_cache_free <= 0) {
+buf = mmap(NULL, 1 << XC_PAGE_SHIFT, PROT_READ | PROT_WRITE, 
MAP_SHARED | MAP_ANONYMOUS, -1, 0);
+} else {
+blkdev->buf_cache_free--;
+buf = blkdev->buf_cache[blkdev->buf_cache_free];
+}
 
 if (unlikely(buf == MAP_FAILED))
 return NULL;
@@ -300,21 +309,40 @@ static int free_buffer(void* buf) {
 return munmap(buf, 1 << XC_PAGE_SHIFT);
 }
 
-static int free_buffers(void** page, int count) 
+static int free_buffers(void** page, int count, struct XenBlkDev *blkdev) 
 {
-int i, r = 0;
+int i, put_buf_cache = 0, r = 0;
+
+if (blkdev->more_work && blkdev->requests_inflight < max_requests) {
+put_buf_cache = max_requests * BLKIF_MAX_SEGMENTS_PER_REQUEST
+- blkdev->buf_cache_free;
+}
 
 for (i = 0; i < count; i++) { 
-
-if(free_buffer(page[i])) 
-r = 1;
-
+if(put_buf_cache > 0) {
+blkdev->buf_cache[blkdev->buf_cache_free++] = page[i];
+put_buf_cache--;
+} else { 
+if(free_buffer(page[i])) 
+r = 1;
+}
+
 page[i] = NULL;
 }
 
 return r;
 }
 
+static void free_buf_cache(struct XenBlkDev *blkdev) {
+int i;
+for(i = 0; i < blkdev->buf_cache_free; i++) {
+free_buffer(blkdev->buf_cache[i]);
+}
+
+blkdev->buf_cache_free = 0;
+free(blkdev->buf_cache);
+}
+
 static int ioreq_write(struct ioreq *ioreq) 
 {
 XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev;
@@ -342,7 +370,7 @@ static int ioreq_write(struct ioreq *ioreq)
 offset[i] = ioreq->req.seg[i].first_sect * ioreq->blkdev->file_blk;
 len[i] = (ioreq->req.seg[i].last_sect - ioreq->req.seg[i].first_sect + 
1) 
   * ioreq->blkdev->file_blk;
-pages[i]  = get_buffer();
+pages[i]  = get_buffer(ioreq->blkdev);
 
 if(!pages[i]) {
 xen_be_printf(>blkdev->xendev, 0, 
@@ -356,7 +384,7 @@ static int ioreq_write(struct ioreq *ioreq)
 xen_be_printf(>blkdev->xendev, 0, 
   "failed to copy data for write %d \n", rc);
 
-if(free_buffers(ioreq->page, ioreq->v.niov)) {
+if(free_buffers(ioreq->page, ioreq->v.niov, ioreq->blkdev)) {
 xen_be_printf(>blkdev->xendev, 0, 
   "failed to free page, errno %d \n", errno);
 }
@@ -382,7 +410,7 @@ static int ioreq_read_init(struct ioreq *ioreq)
 }
 
 for (i = 0; i < ioreq->v.niov; i++) {
-ioreq->page[i] = get_buffer();
+ioreq->page[i] = get_buffer(ioreq->blkdev);
 if(!ioreq->page[i]) {
 return -1;
 }
@@ -469,7 +497,7 @@ static void qemu_aio_complete(void *opaque, int ret)
   "failed to copy read data to guest\n");
 }
 case BLKIF_OP_WRITE:
-if(free_buffers(ioreq->page, ioreq->v.niov)) {
+if(free_buffers(ioreq->page, ioreq->v.niov, ioreq->blkdev)) {
 xen_be_printf(>blkdev->xendev, 0, 
   "failed to free page, errno %d \n", errno);
 }
@@ -936,6 +964,11 @@ static int blk_connect(struct XenDevice *xendev)
 }
 blkdev->cnt_map++;
 
+/* create buffer cache for grant copy operations*/
+blkdev->buf_cache_free = 0;
+blkdev->buf_cache = calloc(max_requests * BLKIF_MAX_SEGMENTS_PER_REQUEST, 
+   sizeof(void *));
+
 switch (blkdev->protocol) {
 case BLKIF_PROTOCOL_NATIVE:
 {
@@ -972,6 +1005,8 @@ static void blk_disconnect(struct XenDevice *xendev)
 {
 struct XenBlkDev *blkdev = container_of(xendev, struct XenBlkDev, xendev);
 
+free_buf_cache(blkdev);
+
 if (blkdev->blk) {
 blk_detach_dev(blkdev->blk, blkdev);
 blk_unref(blkdev->blk);
-- 
1.9.1


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

[Xen-devel] [PATCH 1/3] libs, gnttab, libxc: Interface for grant copy operation

2016-05-27 Thread Paulina Szubarczyk 
Implentation of interface to grant copy operation called through
libxc. An ioctl(gntdev, IOCTL_GNTDEV_GRANT_COPY, ..) system call is
invoked for linux. In the mini-os the operation is yet not
implemented.

* In the file "tools/include/xen-sys/Linux/gntdev.h" added
  - 'struct ioctl_gntdev_grant_copy_segment'
The structure is analogous to 'struct gntdev_grant_copy_segment'
defined in linux code include/uapi/xen/gntdev.h. Typdefs are
replaced by they original types:
  typedef uint16_t domid_t;
  typedef uint32_t grant_ref_t;
That leads to defining domids array with type uint16_t in libs,
differently then in other functions concerning grant table
operations in that library.

` - macro #define IOCTL_GNTDEV_GRANT_COPY

  - 'struct ioctl_gntdev_grant_copy'
taken from linux code as higher. Structure aggregating
'struct gntdev_grant_copy_segment'

* In the file libs/gnttab/linux.c
  - function int osdep_gnttab_grant_copy(xengnttab_handle *xgt,
  uint32_t count,
  uint16_t *domids, uint32_t *refs, void
  **bufs, uint32_t *offset, uint32_t *len,
  int type, uint32_t notify_offset,
  evtchn_port_t notify_port)

It is a function used to perform grant copy opertion. It allocats
'ioctl_gntdev_grant_copy' and 'ioctl_gntdev_grant_copy_segment'.
Segments are filled from the passed values.

When @type is different then zero the source to copy from are guest
domain grant pages addressed by @refs and the destination is local
memory accessed from @bufs, the operation flag is then set to
'GNTCOPY_source_gref', contrarily for @type equal zero.

@offset is the offset on the page
@len is the amount of data to copy,
@offset[i] + @len[i] should not exceed XEN_PAGE_SIZE
- the condition is checked in gntdev device.

Notification is yet not implemented.
---
 tools/include/xen-sys/Linux/gntdev.h  | 21 ++
 tools/libs/gnttab/gnttab_core.c   | 12 ++
 tools/libs/gnttab/include/xengnttab.h | 18 +
 tools/libs/gnttab/libxengnttab.map|  2 +
 tools/libs/gnttab/linux.c | 72 +++
 tools/libs/gnttab/minios.c|  8 
 tools/libs/gnttab/private.h   |  6 +++
 tools/libxc/include/xenctrl_compat.h  |  8 
 tools/libxc/xc_gnttab_compat.c| 12 ++
 9 files changed, 159 insertions(+)

diff --git a/tools/include/xen-sys/Linux/gntdev.h 
b/tools/include/xen-sys/Linux/gntdev.h
index caf6fb4..0ca07c9 100644
--- a/tools/include/xen-sys/Linux/gntdev.h
+++ b/tools/include/xen-sys/Linux/gntdev.h
@@ -147,4 +147,25 @@ struct ioctl_gntdev_unmap_notify {
 /* Send an interrupt on the indicated event channel */
 #define UNMAP_NOTIFY_SEND_EVENT 0x2
 
+struct ioctl_gntdev_grant_copy_segment {
+union {
+void *virt;
+struct {
+uint32_t ref;
+uint16_t offset;
+uint16_t domid;
+} foreign;
+} source, dest;
+uint16_t len;
+uint16_t flags;
+int16_t status;
+};
+
+#define IOCTL_GNTDEV_GRANT_COPY \
+_IOC(_IOC_NONE, 'G', 8, sizeof(struct ioctl_gntdev_grant_copy))
+struct ioctl_gntdev_grant_copy {
+unsigned int count;
+struct ioctl_gntdev_grant_copy_segment *segments;
+};
+
 #endif /* __LINUX_PUBLIC_GNTDEV_H__ */
diff --git a/tools/libs/gnttab/gnttab_core.c b/tools/libs/gnttab/gnttab_core.c
index 5d0474d..1e014f8 100644
--- a/tools/libs/gnttab/gnttab_core.c
+++ b/tools/libs/gnttab/gnttab_core.c
@@ -113,6 +113,18 @@ int xengnttab_unmap(xengnttab_handle *xgt, void 
*start_address, uint32_t count)
 return osdep_gnttab_unmap(xgt, start_address, count);
 }
 
+int xengnttab_copy_grant(xengnttab_handle *xgt,
+ uint32_t count,
+ uint16_t *domids,
+ uint32_t *refs,
+ void **bufs,
+ uint32_t *offset, 
+ uint32_t *len,
+ int type)
+{
+return osdep_gnttab_grant_copy(xgt, count, domids, refs, bufs, offset, 
len, 
+   type, -1, -1);
+}
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/gnttab/include/xengnttab.h 
b/tools/libs/gnttab/include/xengnttab.h
index 0431dcf..923e022 100644
--- a/tools/libs/gnttab/include/xengnttab.h
+++ b/tools/libs/gnttab/include/xengnttab.h
@@ -258,6 +258,24 @@ int xengnttab_unmap(xengnttab_handle *xgt, void 
*start_address, uint32_t count);
 int xengnttab_set_max_grants(xengnttab_handle *xgt,
  uint32_t nr_grants);
 
+/**
+ * Copy memory from or to the domains defined in domids array.
+ * When @type is different then zero data is copied from grant pages addressed 
+ * by @refs to @bufs, and contrarily for @type equal zero. 
+ *
+ * @offset is the offset on the page 
+ * @len is the amount of data to copy 
+ *

Re: [Xen-devel] [PATCH v2] x86/mce: handle reserved domain ID in XEN_MC_msrinject

2016-05-27 Thread Haozhong Zhang 
On 05/27/16 06:27, Jan Beulich wrote:
> >>> On 27.05.16 at 14:13,  wrote:
> > --- a/tools/tests/mce-test/tools/xen-mceinj.c
> > +++ b/tools/tests/mce-test/tools/xen-mceinj.c
> > @@ -317,7 +317,9 @@ static int inject_mci_addr(xc_interface *xc_handle,
> > domid_t domid)
> >  {
> >  return add_msr_bank_intpose(xc_handle, cpu_nr,
> > -MC_MSRINJ_F_INTERPOSE | MC_MSRINJ_F_GPADDR,
> > +MC_MSRINJ_F_INTERPOSE |
> > +(domid > DOMID_FIRST_RESERVED ?
> 
> Simply by the name of it I would say this ought to be >=. However,
> DOMID_FIRST_RESERVED == DOMID_SELF, so the > seems right
> here (on the hypervisor side it should be changed though). But for
> clarity I would suggest either adding a respective comment or
> indeed using
> 
>   domid >= DOMID_FIRST_RESERVED && domid != DOMID_SELF
> 
> (which I would hope the compiler can fold).
> 

I'll change on both sides in the next version.

Thanks,
Haozhong

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

Re: [Xen-devel] [PATCH] arm/gic-v3: Fix driver probe fail on GICv4 hardware

2016-05-27 Thread Julien Grall 

Hello Shanker,

Please mention in the title and the commit message that is patch is ACPI 
only.


On 27/05/16 00:59, Shanker Donthineni wrote:

The current driver probe fails on hardware which has GICv4 version,
even though it is fully compatible to GICv3. This patch fixes the
issue by registering the same probe function for GICv4 hardware.

Signed-off-by: Shanker Donthineni 
---
  xen/arch/arm/gic-v3.c | 13 +
  xen/include/asm-arm/gic.h |  1 +
  2 files changed, 14 insertions(+)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index a095064..594cf6e 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1604,10 +1604,23 @@ static int __init gicv3_acpi_preinit(const void *data)
  return 0;
  }

+static int __init gicv4_acpi_preinit(const void *data)
+{
+gicv3_info.hw_version = GIC_V4;


It will crash Xen as soon as DOM0 is created (see the BUG() in 
arch_domain_create). Please test any patch before sending on the ML.


Anyway, there is no support of GICv4 in Xen. Instead Xen will drive it 
using the GICv3 driver. So the hardware version should be GIC_V3 here.



+register_gic_ops(_ops);
+
+return 0;
+}
+
  ACPI_DEVICE_START(agicv3, "GICv3", DEVICE_GIC)
  .class_type = ACPI_MADT_GIC_VERSION_V3,
  .init = gicv3_acpi_preinit,
  ACPI_DEVICE_END
+
+ACPI_DEVICE_START(agicv4, "GICv4", DEVICE_GIC)
+.class_type = ACPI_MADT_GIC_VERSION_V4,
+.init = gicv4_acpi_preinit,
+ACPI_DEVICE_END
  #endif

  /*
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index cd97bb2..5be814a 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -218,6 +218,7 @@ struct gic_lr {
  enum gic_version {
  GIC_V2,
  GIC_V3,
+GIC_V4,
  };

  extern enum gic_version gic_hw_version(void);



Regards,

--
Julien Grall

___
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?

2016-05-27 Thread Dirk Behme 

On 26.05.2016 11:00, Julien Grall wrote:

On 25/05/2016 16:10, Dirk Behme wrote:

On 24.05.2016 22:05, Julien Grall wrote:

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

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).



I've started to look into this:

I'd think in arm_uart.c in dt_uart_init() after

if ( !dev )

we know the UART node we are looking for. From this we have to read the
clock configuration.

To be clarified: How to read the clock configuration? I couldn't find
any convenient function dt_device_get_clock() or similar for that.


Xen does not need to parse the content of the property "clocks" but
copy the raw value to the DOM0 DT.

You cand find the value of a property with dt_get_property.



Now, we have the clocks we are looking for.

These are needed in domain_build.c in make_hypervisor_node(), then.

To be clarified: How to pass the clock configuration from arm_uart.c to
domain_build.c (and not break the non-dt / non-ARM platforms)?

Any ideas or comments?


All the devices (UART included) used by Xen will return DOMID_XEN when
dt_device_used_by is called to the node.

You could use it to collect the clocks of all those devices and gather
the value in a single property to be created in the hypervisor node.



Anything like below (untested) [1]?

I'm unhappy about the global variables and the max clocks, though.

Best regards

Dirk

[1]

---
 xen/arch/arm/domain_build.c |   24 
 1 file changed, 24 insertions(+)

Index: xen.git/xen/arch/arm/domain_build.c
===
--- xen.git.orig/xen/arch/arm/domain_build.c
+++ xen.git/xen/arch/arm/domain_build.c
@@ -42,6 +42,10 @@ static void __init parse_dom0_mem(const
 }
 custom_param("dom0_mem", parse_dom0_mem);

+#define MAX_DT_CLOCKS 256
+static unsigned char dt_clocks[MAX_DT_CLOCKS];
+static unsigned int clk_cnt;
+
 //#define DEBUG_DT

 #ifdef DEBUG_DT
@@ -657,6 +661,10 @@ static int make_hypervisor_node(const st
 if ( res )
 return res;

+res = fdt_property(fdt, "clocks", dt_clocks, clk_cnt);
+if ( res )
+return res;
+
 res = fdt_end_node(fdt);

 return res;
@@ -1213,9 +1221,11 @@ static int handle_node(struct domain *d,
 { /* sentinel */ },
 };
 struct dt_device_node *child;
+unsigned int len;
 int res;
 const char *name;
 const char *path;
+const char *clocks;

 path = dt_node_full_name(node);

@@ -1246,6 +1256,20 @@ static int handle_node(struct domain *d,
 if ( dt_device_used_by(node) == DOMID_XEN )
 {
 DPRINT("  Skip it (used by Xen)\n");
+
+/*
+ * Remember the clock used by the skipped node
+ * We add it later to the hypervisor node to make the
+ * Linux kernel aware of its usage
+ */
+clocks = dt_get_property(node, "clocks", );
+if ( clk_cnt + len >= MAX_DT_CLOCKS ) {
+printk("Failed to remember the clock node of %s\n", path);
+printk("Use the Linux kernel command 'clk_ignore_unused'\n");
+return 0;
+}
+memcpy(_clocks[clk_cnt], clocks, len);
+clk_cnt += len;
 return 0;
 }


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

Re: [Xen-devel] [PATCH v2] x86/mce: handle reserved domain ID in XEN_MC_msrinject

2016-05-27 Thread Jan Beulich 
>>> On 27.05.16 at 14:13,  wrote:
> --- a/tools/tests/mce-test/tools/xen-mceinj.c
> +++ b/tools/tests/mce-test/tools/xen-mceinj.c
> @@ -317,7 +317,9 @@ static int inject_mci_addr(xc_interface *xc_handle,
> domid_t domid)
>  {
>  return add_msr_bank_intpose(xc_handle, cpu_nr,
> -MC_MSRINJ_F_INTERPOSE | MC_MSRINJ_F_GPADDR,
> +MC_MSRINJ_F_INTERPOSE |
> +(domid > DOMID_FIRST_RESERVED ?

Simply by the name of it I would say this ought to be >=. However,
DOMID_FIRST_RESERVED == DOMID_SELF, so the > seems right
here (on the hypervisor side it should be changed though). But for
clarity I would suggest either adding a respective comment or
indeed using

domid >= DOMID_FIRST_RESERVED && domid != DOMID_SELF

(which I would hope the compiler can fold).

Jan


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

Re: [Xen-devel] [BUG] win2008 guest cannot get ip through sriov

2016-05-27 Thread Jan Beulich 
>>> On 27.05.16 at 12:39,  wrote:
> Is this a regression? Does it work on previous versions of Xen?

I think this is what was already reported by other Intel people,
see e.g. Quan's most recent reply:
http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg01896.html
It is not clear where the problem is, and not seeing the issue
myself makes it hard to analyze. In any event this quite likely
is a regression.

Jan


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

[Xen-devel] [PATCH v2] x86/mce: handle reserved domain ID in XEN_MC_msrinject

2016-05-27 Thread Haozhong Zhang 
Commit 26646f3 "x86/mce: translate passed-in GPA to host machine
address" and commit 4ddf474 "tools/xen-mceinj: Pass in GPA when
injecting through MSR_MCI_ADDR" forgot to consider reserved domain
ID and mistakenly add MC_MSRINJ_F_GPADDR flag for them, which in turn
causes bug reported by
http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg02640.html.

This patch removes MC_MSRINK_F_GPADDR flag and check this when injecting
to domain ID larger than DOMID_FIRST_RESERVED, and treats the passed-in
address as host machine address.

Signed-off-by: Haozhong Zhang 
---
This is v2 of 
http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg02534.html.

Changes in v2:
 * Consider all reserved domain IDs rather than just DOMID_XEN.
---
 tools/tests/mce-test/tools/xen-mceinj.c |  4 +++-
 xen/arch/x86/cpu/mcheck/mce.c   | 14 +++---
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/tools/tests/mce-test/tools/xen-mceinj.c 
b/tools/tests/mce-test/tools/xen-mceinj.c
index 061ec7c..055db7b 100644
--- a/tools/tests/mce-test/tools/xen-mceinj.c
+++ b/tools/tests/mce-test/tools/xen-mceinj.c
@@ -317,7 +317,9 @@ static int inject_mci_addr(xc_interface *xc_handle,
domid_t domid)
 {
 return add_msr_bank_intpose(xc_handle, cpu_nr,
-MC_MSRINJ_F_INTERPOSE | MC_MSRINJ_F_GPADDR,
+MC_MSRINJ_F_INTERPOSE |
+(domid > DOMID_FIRST_RESERVED ?
+ 0 : MC_MSRINJ_F_GPADDR),
 MCi_type_ADDR, bank, val, domid);
 }
 
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index cc446eb..711a97c 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1427,6 +1427,7 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
 
 if ( mc_msrinject->mcinj_flags & MC_MSRINJ_F_GPADDR )
 {
+domid_t domid;
 struct domain *d;
 struct mcinfo_msr *msr;
 unsigned int i;
@@ -1434,10 +1435,17 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
 unsigned long gfn, mfn;
 p2m_type_t t;
 
-d = get_domain_by_id(mc_msrinject->mcinj_domid);
+domid = (mc_msrinject->mcinj_domid == DOMID_SELF) ?
+current->domain->domain_id : mc_msrinject->mcinj_domid;
+if ( domid > DOMID_FIRST_RESERVED )
+return x86_mcerr("do_mca inject: incompatible flag "
+ "MC_MSRINJ_F_GPADDR with domain %d",
+ -EINVAL, domid);
+
+d = get_domain_by_id(domid);
 if ( d == NULL )
 return x86_mcerr("do_mca inject: bad domain id %d",
- -EINVAL, mc_msrinject->mcinj_domid);
+ -EINVAL, domid);
 
 for ( i = 0, msr = _msrinject->mcinj_msr[0];
   i < mc_msrinject->mcinj_count;
@@ -1452,7 +1460,7 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
 put_gfn(d, gfn);
 put_domain(d);
 return x86_mcerr("do_mca inject: bad gfn %#lx of domain 
%d",
- -EINVAL, gfn, mc_msrinject->mcinj_domid);
+ -EINVAL, gfn, domid);
 }
 
 msr->value = pfn_to_paddr(mfn) | (gaddr & (PAGE_SIZE - 1));
-- 
2.8.3


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

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

2016-05-27 Thread osstest service owner 
flight 94813 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94813/

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
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 94748

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

Last test of basis94748  2016-05-24 22:43:25 Z2 days
Failing since 94750  2016-05-25 03:43:08 Z2 days7 attempts
Testing same since94796  2016-05-26 13:13:36 Z0 days2 attempts


People who touched revisions under test:
  Dandan Bi 
  Gary Lin 
  Hao Wu 
  Jiaxin Wu 
  Laszlo Ersek 
  Liming Gao 
  Marvin H?user 
  Marvin Haeuser 
  Michael Zimmermann 
  Yonghong Zhu 

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 fail
 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.

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

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

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

2016-05-27 Thread Julien Grall 

Hi Wei,

On 26/05/16 08:58, Wei Chen wrote:

In AArch32, MPIDR bit31 is defined as multiprocessing extensions bit.


NIT: s/bit31/bit 31/


But in AArch64, this bit is always RES1. So the value check for this
bit is no longer necessary in AArch64.

Signed-off-by: Wei Chen 


With the change above:

Reviewed-by: Julien Grall 

Regards,

--
Julien Grall

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

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

2016-05-27 Thread Julien Grall 

Hi Wei,

On 26/05/16 08:58, Wei Chen wrote:

Currently, MPIDR_HWID_MASK is using the bit definition of AArch32 MPIDR.
 From ARMv8 ARM we can see there are 4 levels of affinity on AArch64
whilst AArch32 has only 3. So, this value is not correct when Xen is
running on AArch64.

Now, we use the value 0xff00ff for this macro on AArch64. But neither
of this value and its bitwise invert value can be used in mov instruction
with the encoding of {imm16:shift} or {imms:immr}. So we have to use ldr
to load the bitwise invert value to register.

The details of mov immediate encoding are listed in ARMv8 ARM C4.2.5.


The section numbering may change between two versions of the spec. I 
would mention the version (e.g DDI 0487A.i, I guess?).


Regards,

--
Julien Grall

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

Re: [Xen-devel] [BUG] IGD-PT doesn't work on Skylake-S client

2016-05-27 Thread Wei Liu 
Hello,

Thanks for putting in the effort to post bug reports. We appreciate this
a lot. I skim through all log files. There is no doubt a lot of
information there.

On Fri, May 27, 2016 at 06:57:19AM +, Zhang, PengtaoX wrote:
> Bug detailed description:
> 
> 1. Create a rhel7.1 guest with IGD-PT on SKL-S client , login guest and run 
> 3D(nexuiz) , opencl(beignet) , media(transcode ,encode,decode) test , all 
> test are run failed .
> 2. All these test could run pass on Boardwell-UP platform .
> 3. The SKL-H client and BDW-UP platform are using the same hard disk to test .
> 
> Environment :
> 
> HW: Skylake-S

Hmm... Not sure how many people have such hardware here.

> Xen: Xen 4.7.0 RC3
> Dom0: Linux 4.6.0
> 
> Reproduce steps:
> 
> 1.Install redhat 6.7 OS on Skylake-S client as base OS , then compile and 
> install  ,xen and Dom0, reboot from xen .
> 2.Create a rhel7.1 guest (include 3D, OpenCL ,Media SDK) with IGD-PT .
>   Hide graphic  device by : xl pci-assignable-add 00:02.0
>   Create guest by : xl create config-hvm.log
> 3.Login guest and run 3D , OpenCL , Media test .
> 

All in all, the setup seem to be quite complicated. I'm not sure what I
can help here. For upstream to help with debugging this issue, you need
to provide a few bit-size steps. The simpler the better.

Maybe start with debugging various errors shown in guest / hv log files?
If you or someone from Intel can hunt down the culprit (particular code
path, offending instructions etc) that would be great.

Wei.

> Current result:
> 
> All 3D ,Opencl ,Media test are failed on Skylake-S client .
> 
> Base error log:
> 
> I attached both Boardwell-UP and Skylake-S test log .
> 
> Regards,
> Pengtao











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

Re: [Xen-devel] [BUG] win2008 guest cannot get ip through sriov

2016-05-27 Thread Wei Liu 
Hello

Is this a regression? Does it work on previous versions of Xen?

On Fri, May 27, 2016 at 09:04:47AM +, Zhang, PengtaoX wrote:
> Bug detailed description:
> 
> while assign a vf to guest with vf's bdf number in guest configure file 
> static,or use command :"xl pci-attach $domid $bdf" dynamic , affter guest 
> boot up,win2008 guest can not get ip.
> 

"xl -vvv pci-attch" can provide more insight.

From the screenshot I can see the VF does show up in the guest, so the
xl command probably runs fine.

(A side note, please be considerate to xen-devel subscribers who might
not have large bandwidth or an image viewer -- avoid sending pictures in
the future.)

Maybe have a look at xl dmesg to see if there is anything interesting
there?

Wei.


> Environment :
> 
> HW: Skylake-S ,Boardwell-ep,Board-ex,Haswell-ep,Haswell-ex
> NIC: Intel Corporation 82599 Ethernet Controller
> Xen: Xen 4.7.0 RC3
> Dom0: Linux 4.6.0
> 
> Reproduce steps:
> 
> 1.boot up a win2008 guest with vf's bdf number in guest configure file(boot 
> up a win2k8 guest then use :"xl pci-attach $domid $bdf" to guest).
> 2.check guest ip .
> 
> Current result:
> 
> Win2008 guest didn't have ip address .
> 
> Base error log:
> 
> Please check attachment .
> 
> 
> Regards,
> Pengtao


> builder = "hvm"
> name = "vVTD_ASS_13_1435039196"
> memory = 512
> vcpus=2
> disk = [ '/share/xvs/var/img.vmxVTD_ASS_13_1,qcow2,xvda,rw', 
> '/share/xvs/var/img.vmxVTD_ASS_13_2,raw,xvdb,rw' ]
> device_model_override = '/usr/local/lib/xen/bin/qemu-system-i386'
> device_model_version = 'qemu-xen'
> sdl=0
> vnc=1
> stdvga=1
> hap=1
> acpi=1
> pci = [ '03:10.1' ]
> hpet=1
> 



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

Re: [Xen-devel] [BUG] xen's LLC, UCNA and MEM testing show error messge"Failed to inject MSR"

2016-05-27 Thread Wei Liu 
Hello

Please post patch v2 and see if the patch can be acked and then we might
be able to take it for 4.7.0.

I don't consider this issue a blocker at this point: it's not design
issue, it's not regression. The patch can be backported easily if it
misses 4.7.0.

Wei.

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

[Xen-devel] [PATCH] xen/arm64: config: correct VMAP_VIRT_END

2016-05-27 Thread Peng Fan 
To ARM64, we should use '(VMAP_VIRT_START + GB(1))' as VMAP_VIRT_END,
but not '(VMAP_VIRT_START + GB(1) - 1)'.

Seeing 'vm_end[type] = PFN_DOWN(end - start);' in vm_init_type,
if not correct VMAP_VIRT_END, one page is wasted.

Signed-off-by: Peng Fan 
Cc: Julien Grall 
Cc: Stefano Stabellini 
---

I found X86 use '(VMAP_VIRT_START + GB(64))' and ARM32 use XENHEAP_VIRT_START,
both are aligned address. So, I think ARM64 may also need to use aligned
address. I am not very sure (:

 xen/include/asm-arm/config.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 2d11b62..f92c0a0 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -147,7 +147,7 @@
 #define SLOT0_ENTRY_SIZE  SLOT0(1)
 
 #define VMAP_VIRT_START  GB(1)
-#define VMAP_VIRT_END(VMAP_VIRT_START + GB(1) - 1)
+#define VMAP_VIRT_END(VMAP_VIRT_START + GB(1))
 
 #define FRAMETABLE_VIRT_START  GB(32)
 #define FRAMETABLE_SIZEGB(32)
-- 
2.6.2


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

[Xen-devel] questions of vm save/restore on arm64

2016-05-27 Thread Chenxiao Zhao 
Hi,

My board is Hikey on which have octa-core of arm cortex-a53. I have applied
patches [1] to try vm save/restore on arm.
These patches originally do not working on arm64. I have made some changes
based on patch set [2].

What I have got so far is

1. if I run 'xl save -p guest memState' to leave guest in suspend state,
then run 'xl unpause guest'.
the guest can resume successfully. so I suppose the guest works find on
suspend/resume.

2. if I run 'xl restore -p memState' to restore guest and use xenctx to
dump all vcpu's registers.
all the registers are identical to the state on save. After I run 'xl
unpause guest', I got no error but can not connect to console.
After restore the guest's PC is at a function
called user_disable_single_step(), which is called
by single_step_handler().

My question is

1. How could I debug guest on restore progress? are there any tools
available?
2. From my understanding, the restore not working is because some status is
missing when saving.
 e.g. on cpu_save, it know the domain is 64bit, but on cpu_load, it always
think it is a 32bit domain. so I have hard coded the domain type to
DOMAIN_64BIT.
Am I correct?
3. How could I dump all VM's status? I only found xenctx can dump vcpu's
registers.

I have attached my patch and log below.

Looking forward for your feedback.
Thanks

xl list
NameID   Mem VCPUs  State
Time(s)
Domain-0 0  1024 8 r-
 11.7
root@linaro-alip:~# xl create guest.cfg
Parsing config from guest.cfg
[   39.238723] xen-blkback: ring-ref 8, event-channel 3, protocol 1
(arm-abi) persistent grants

root@linaro-alip:~# xl save -p guest memState
Saving to memState new xl format (info 0x3/0x0/931)
xc: info: Saving domain 1, type ARM
(XEN) HVM1 save: VCPU
(XEN) HVM1 save: A15_TIMER
(XEN) HVM1 save: GICV2_GICD
(XEN) HVM1 save: GICV2_GICC
(XEN) HVM1 save: GICV3
root@linaro-alip:~# /usr/lib/xen/bin/xenctx -a 1
PC:   ffcab028
LR:   ffc00050458c
ELR_EL1:  ffc86b34
CPSR: 21c5
SPSR_EL1: 6145
SP_EL0:   007ff6f2a850
SP_EL1:   ffc0140a7ca0

 x0: 0001x1: deadbeefx2: 0002
 x3: 0002x4: 0004x5: 
 x6: 001bx7: 0001x8: 00618e589e00
 x9:    x10:    x11: 
x12: 01a3   x13: 1911a7d9   x14: 2ee0
x15: 0005   x16: deadbeef   x17: 0001
x18: 0007   x19:    x20: ffc014163d58
x21: ffc014163cd8   x22: 0001   x23: 0140
x24: ffc000d5bb18   x25: ffc014163cd8   x26: 
x27:    x28:    x29: ffc0140a7ca0

SCTLR: 34d5d91d
TTBCR: 0032b5193519
TTBR0: 002d54876000
TTBR1: 40dcf000
root@linaro-alip:~# xl destroy guest
(XEN) mm.c:1265:d0v1 gnttab_mark_dirty not implemented yet
root@linaro-alip:~# xl restore -p memState
Loading new save file memState (new xl fmt info 0x3/0x0/931)
 Savefile contains xl domain config in JSON format
Parsing config from 
xc: info: (XEN) HVM2 restore: VCPU 0
Found ARM domain from Xen 4.7
xc: info: Restoring domain
(XEN) HVM2 restore: A15_TIMER 0
(XEN) HVM2 restore: A15_TIMER 0
(XEN) HVM2 restore: GICV2_GICD 0
(XEN) HVM2 restore: GICV2_GICC 0
(XEN) GICH_LRs (vcpu 0) mask=0
(XEN)VCPU_LR[0]=0
(XEN)VCPU_LR[1]=0
(XEN)VCPU_LR[2]=0
(XEN)VCPU_LR[3]=0
xc: info: Restore successful
xc: info: XenStore: mfn 0x39001, dom 0, evt 1
xc: info: Console: mfn 0x39000, dom 0, evt 2
root@linaro-alip:~# /usr/lib/xen/bin/xenctx -a 2
PC:   ffcab028
LR:   ffc00050458c
ELR_EL1:  ffc86b34
CPSR: 21c5
SPSR_EL1: 6145
SP_EL0:   007ff6f2a850
SP_EL1:   ffc0140a7ca0

 x0: x1: deadbeefx2: 0002
 x3: 0002x4: 0004x5: 
 x6: 001bx7: 0001x8: 00618e589e00
 x9:    x10:    x11: 
x12: 01a3   x13: 1911a7d9   x14: 2ee0
x15: 0005   x16: deadbeef   x17: 0001
x18: 0007   x19:    x20: ffc014163d58
x21: ffc014163cd8   x22: 0001   x23: 0140
x24: ffc000d5bb18   x25: ffc014163cd8   x26: 
x27:    x28:    x29: ffc0140a7ca0

SCTLR: 34d5d91d
TTBCR: b5193519
TTBR0: 002d54876000
TTBR1: 40dcf000
root@linaro-alip:~# xl unpause guest
root@linaro-alip:~# xl list
NameID   Mem VCPUs  State
Time(s)
Domain-0 0  1024 8 r-
 22.2
guest2 0 1 r-
4.8

Re: [Xen-devel] [PATCH v4 0/3] x86/ioreq server: Introduce HVMMEM_ioreq_server mem type.

2016-05-27 Thread George Dunlap 
On 27/05/16 11:00, Jan Beulich wrote:
 On 27.05.16 at 09:52,  wrote:
>> Any comment on this version? Sorry for the disturbance.
> 
> It's on my things to look at, but since it can't go in right now anyway,
> it's not a top priority.

Same -- I have a queue of "Things To Do Before the Release", and another
queue of "Things To Do After Those Thigns Are Done".  This series is
near the top of the second list.

 -George

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

Re: [Xen-devel] [BUG] On bdw-ep, failed to offline/online socket1 cpu on Dom0

2016-05-27 Thread Jan Beulich 
>>> On 27.05.16 at 08:25,  wrote:
> Bug detailed description:
> 1:When offline all the socket1 cpus , network segment hang .
> 2:When online all the socket1 cpus , it show "(XEN) Panic on CPU 44:".
> 3: Haswell-ep and Haswell-ex cpu offline/ online successfully.

I suppose
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=663f2f51b10e55a9093a0bc458dadfbaf1705c31
fixes this?

Thanks, Jan


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

Re: [Xen-devel] Basic bare metal ARM domain interface

2016-05-27 Thread Julien Grall 



On 25/05/16 20:42, Ivan Pavić2 wrote:

Hello,


Hello Ivan,


I'm working on bare metal application for ARM Cortex A7/15 on Odroid XU3
platform. I'm using Xen 4.6.

After successfully creating bare metal example(by successful I mean I've stuck
processor in while loop in main function), I probably should initialize memory
management unit and similiar. I've found FreeRTOS project on Github where
similiar stuff was done for ARM Cortex A15. Project is done for Xen 4.4.
Xen FreeRTOS project: https://github.com/GaloisInc/FreeRTOS-Xen/ .

1) I'm using 4.6. so I don't know if code from  is fully compatible? (I had to
comment out lot of things because they block program, printing for example)


If I remember correctly, FreeRTOS is not using the device-tree to find 
where reside the GIC MMIO regions (and possible other MMIOs).


The memory layout has been reworked between Xen 4.4 and Xen 4.5. So you 
will need to update the base address hardcoded in FreeRTOS.


I have CCed, Jonathan who did the FreeRTOS port for Xen. He will be able 
to give you more details about it.




2) Additionally , I would like to implement basic serial output to dom0 from my
bare metal domU. What is the minimum one should do for implementing console
output?


We provide a PV console interface. The backend is already implement in 
dom0 (assuming you are using Linux). For the frontend, you can give a 
look, how mini-os [1] has implemented it.




3) Furthermore, as this should be bare metal application, I would like at least
to be able to toggle LED. How can interface hardware from domU? My first guess
would be to directly address Exynos 5422 GPIO registers but I don't know if
that would work beacause application is running on VCPU (probably not??) ??


By default, the guest has no access to the hardware. You will need to 
specify in the configure file the list of MMIO regions the guest is 
allowed to access. You can find more details about it here [2].




Any answer, example of implementation, specific documentation or advice would
be very helpful.


There were a few talks to explain how to port an OS on XEN:
 - 
https://events.linuxfoundation.org/sites/events/files/slides/FreeRTOSXenSummit_0.pdf

 - http://fr.slideshare.net/xen_com_mgr/bsdcan-2015-how-to-port-your-bsd

I hope this will help you to create your bare metal app. Feel free to 
send an e-email if you have more questions.


Regards,

[1] 
http://xenbits.xen.org/gitweb/?p=mini-os.git;a=tree;f=console;h=61f51490a1aefc15148b6e1f016d9e63bbfe61aa;hb=HEAD

[2] https://events.linuxfoundation.org/sites/events/files/slides/talk_5.pdf

--
Julien Grall

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

Re: [Xen-devel] How about use different "max_grant_frames" for different domains?

2016-05-27 Thread Jan Beulich 
>>> On 27.05.16 at 04:54,  wrote:
> Because the boosting CPU and memory resources on server, Xen users are allowed
> and actually do create lots of vdisk and vnic, e.g., 6 vnic, 20 vdisk and 24
> vcpu (the number of vnic queue is proportional to the number of vcpu assigned
> to guest), and this requires the administrator to increase the value of
> "max_grant_frames" by changing cmdline param or DEFAULT_MAX_NR_GRANT_FRAMES in
> Xen hypervisor.  Currently, all Xen guests share the same "max_grant_frames" 
> in
> Xen hypervisor, that is, if we increase the grant frame because of one VM, all
> other VMs' grant frame limit will increase as well. 
> 
> Therefore, please let me know if using an individual "max_grant_frames" 
> instead
> of a global variable is reasonable? How about if we relocate this variable to
> "struct grant_table" or "struct domain"?

Why not? I think this being global simply was of no concern so far.

Jan


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

Re: [Xen-devel] [PATCH v4 0/3] x86/ioreq server: Introduce HVMMEM_ioreq_server mem type.

2016-05-27 Thread Zhang, Yu C 



On 5/27/2016 6:00 PM, Jan Beulich wrote:

On 27.05.16 at 09:52,  wrote:

Any comment on this version? Sorry for the disturbance.

It's on my things to look at, but since it can't go in right now anyway,
it's not a top priority.


Got it. Thanks for your feedback. :)

Yu


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

Re: [Xen-devel] [for-4.7 v2 1/2] xen: XENMEM_add_to_physmap_batch: Mark 'foreign_id' as reserved for dev_mmio

2016-05-27 Thread Jan Beulich 
>>> On 25.05.16 at 17:56,  wrote:
> --- a/xen/common/compat/memory.c
> +++ b/xen/common/compat/memory.c
> @@ -253,6 +253,8 @@ int compat_memory_op(unsigned int cmd, 
> XEN_GUEST_HANDLE_PARAM(void) compat)
>  unsigned int size = cmp.atpb.size;
>  xen_ulong_t *idxs = (void *)(nat.atpb + 1);
>  xen_pfn_t *gpfns = (void *)(idxs + limit);
> +enum XLAT_add_to_physmap_batch_u u =
> +XLAT_add_to_physmap_batch_u_res0;

Here you're cheating, and to help future readers understand you are
you should say why this is okay in a comment. Or alternatively handle
things properly.

> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -259,7 +259,15 @@ struct xen_add_to_physmap_batch {
>  
>  /* Number of pages to go through */
>  uint16_t size;
> -domid_t foreign_domid; /* IFF gmfn_foreign */
> +
> +#if __XEN_INTERFACE_VERSION__ < 0x00040700
> +domid_t foreign_domid; /* IFF gmfn_foreign. Should be 0 for other 
> spaces. */
> +#else
> +union add_to_physmap_batch_extra {

This lacks a xen_ prefix.

Jan


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

Re: [Xen-devel] [PATCH v4 0/3] x86/ioreq server: Introduce HVMMEM_ioreq_server mem type.

2016-05-27 Thread Jan Beulich 
>>> On 27.05.16 at 09:52,  wrote:
> Any comment on this version? Sorry for the disturbance.

It's on my things to look at, but since it can't go in right now anyway,
it's not a top priority.

Jan


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

Re: [Xen-devel] [for-4.7 v2 2/2] xen/arm: Document the behavior of XENMAPSPACE_dev_mmio

2016-05-27 Thread Jan Beulich 
>>> On 25.05.16 at 17:56,  wrote:
> Currently, XENMAPSPACE_dev_mmio maps MMIO regions using one of the most
> restrictive memory attribute (Device-nGnRE).
> 
> Signed-off-by: Julien Grall 

Acked-by: Jan Beulich 
irrespective of whether ...

> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -220,7 +220,11 @@ DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
>  #define XENMAPSPACE_gmfn_range   3 /* GMFN range, XENMEM_add_to_physmap 
> only. */
>  #define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
>  * XENMEM_add_to_physmap_batch only. */
> -#define XENMAPSPACE_dev_mmio 5 /* device mmio region */
> +#define XENMAPSPACE_dev_mmio 5 /* device mmio region
> +  ARM only; the region will be mapped
> +  in Stage-2 using the memory attribute
> +  "Device-nGnRE" (previously named
> +  "Device" on ARMv7) */

"will be" would get replaced as suggested by Stefano (I don't think
the current wording is really misleading).

Jan


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

Re: [Xen-devel] Discussion about virtual iommu support for Xen guest

2016-05-27 Thread Tian, Kevin 
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Friday, May 27, 2016 4:47 PM
> > >
> > > A whole lot of this would be easier to reason about if/when we get a
> > > basic root port implementation in Xen, which is necessary for HVMLite,
> > > and which will make the interaction with qemu rather more clean.  It is
> > > probably worth coordinating work in this area.
> >
> > Would it make Xen too complex? Qemu also has its own root port
> > implementation, and then you need some tricks within Qemu to not
> > use its own root port but instead registering to Xen root port. Why is
> > such movement more clean?
> >
> 
> Upstream QEMU already registers PCI BDFs with Xen, and Xen already handles 
> cf8 and cfc
> accesses (to turn them into single config space read/write ioreqs). So, it 
> really isn't much
> of a leap to put the root port implementation in Xen.
> 
>   Paul
> 

Thanks for your information. I didn't realize that fact.

Curious is there anyone already working on a basic root port support
in Xen? If yes, what's the current progress?

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

Re: [Xen-devel] [PATCH v3 14/16] x86/boot: implement early command line parser in C

2016-05-27 Thread Jan Beulich 
>>> On 25.05.16 at 23:36,  wrote:
> On Wed, May 25, 2016 at 04:33:54AM -0600, Jan Beulich wrote:
>> >>> On 15.04.16 at 14:33,  wrote:
>> > --- /dev/null
>> > +++ b/xen/arch/x86/boot/cmdline.c
>> > @@ -0,0 +1,357 @@
>> > +/*
>> > + * Copyright (c) 2015, 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 .
>> > + *
>> > + * strlen(), strncmp(), strspn() and strcspn() were copied from
>> > + * Linux kernel source (linux/lib/string.c).
>>
>> Any reason you can't just #include ".../common/string.c" here?
> 
> I am confused. Sometimes you request to reduce number of such strange
> includes and sometimes you ask me to do something contrary? So, what
> is the rule behind these requests?

The rule is "whatever fits best for the current purpose". Such
"strange" includes should be avoided if their purpose can be
fulfilled by other means. Them being avoided at the price of
quite a bit of code duplication, otoh, doesn't seem well advised
to me.

>> > +/*
>> > + * Compiler is not able to optimize regular strlen()
>> > + * if argument is well known string during build.
>> > + * Hence, introduce optimized strlen_opt().
>> > + */
>> > +#define strlen_opt(s) (sizeof(s) - 1)
>>
>> Do we really care in this code?
> 
> Not to strongly but why not?

Keep things as readable as possible. In fact I wouldn't mind hard
coded literal numbers for the string lengths, if they sit right next
to the respective string literal.

>> > +static int strtoi(const char *s, const char *stop, const char **next)
>> > +{
>> > +int base = 10, i, ores = 0, res = 0;
>>
>> You don't even handle a '-' on the numbers here, so all the variables
> 
> Yep, however, ...
> 
>> and the function return type should be unsigned int afaict. And the
>> function name perhaps be strtoui().
> 
> ... we return -1 in case of error.

Which - having looked at some of the callers - could easily be
UINT_MAX as it seems.

>> > +static u8 skip_realmode(const char *cmdline)
>> > +{
>> > +return !!find_opt(cmdline, "no-real-mode", 0) || !!find_opt(cmdline, 
> "tboot=", 1);
>>
>> The || makes the two !! pointless.
>>
>> Also please settle on which type you want to use for boolean
>> (find_opt()'s last parameter is "int", yet here you use "u8"), and
> 
> Could be u8.
> 
>> perhaps make yourself a bool_t.
> 
> I do not think it make sense here.

I think it makes as much or as little sense as having NULL available.

>> > +/*
>> > + * Increment c outside of strtoi() because otherwise some
>> > + * compiler may complain with following message:
>> > + * warning: operation on ‘c’ may be undefined.
>> > + */
>> > +++c;
>> > +tmp = strtoi(c, "x", );
>>
>> The comment is pointless - the operation is firmly undefined if you
>> put it in the strtoi() invocation.
> 
> In terms of C spec you are right. However, it is quite surprising that older
> GCC complains and newer ones do not. Should not we investigate this?

Actually I think I was wrong here. A function call like func(c++, c)
would be undefined, but func(c++, ) isn't. So I guess if there are
compiler versions getting this wrong, then you should just disregard
my comment.

>> > +pushl   $sym_phys(early_boot_opts)
>> > +pushl   MB_cmdline(%ebx)
>> >  callcmdline_parse_early
>> > +add $8,%esp /* Remove cmdline_parse_early() args 
>> > from stack. */
>>
>> I don't think such a comment is really useful (seems like I overlooked
>> a similar one in an earlier patch, on the reloc() invocation).
> 
> This thing is quite obvious but I do not think that this comment hurts.

It may not really hurt, but it draws needless attention to something
that is to b expected after any function call getting arguments
passed on the stack. You could, btw., make cmdline_parse_early
a stdcall function, so you wouldn't have to do that adjustment
here.

Jan

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

Re: [Xen-devel] [PATCH v3 13/16 - RFC] x86: add multiboot2 protocol support for EFI platforms

2016-05-27 Thread Jan Beulich 
>>> On 25.05.16 at 23:02,  wrote:
> On Wed, May 25, 2016 at 03:32:37AM -0600, Jan Beulich wrote:
>> >>> On 15.04.16 at 14:33,  wrote:
>> >  bad_cpu:
>> >  mov $(sym_phys(.Lbad_cpu_msg)),%esi # Error message
>> > -jmp print_err
>> > +mov $0xB8000,%edi   # VGA framebuffer
>> > +jmp 1f
>> >  not_multiboot:
>> >  mov $(sym_phys(.Lbad_ldr_msg)),%esi # Error message
>> > -print_err:
>> > -mov $0xB8000,%edi  # VGA framebuffer
>> > +mov $0xB8000,%edi   # VGA framebuffer
>> > +jmp 1f
>> > +mb2_too_old:
>> > +mov $(sym_phys(.Lbad_ldr_mb2)),%esi # Error message
>> > +xor %edi,%edi   # No VGA framebuffer
>>
>> Leaving aside that "framebuffer" really is a bad term here (we're
>> talking of text mode output after all), limiting the output to serial
> 
> Yep, but then we should change this in other places too. Maybe in separate 
> patch.

Since you touch (move) it, replacing the word "framebuffer" wouldn't
seem like something making the patch any more difficult to understand.

>> isn't going to be very helpful in the field, I'm afraid. Even more so
>> that there's no guarantee for a UART to be at port 0x3f8. That's
> 
> Right but we do not have big choice here at very early boot stage... :-(((

Excuse me? You're running on EFI, so you have full infrastructure
available to you. As much as in a normal BIOS scenario (and on a
half way normal system) we can assume a text mode screen with
video memory mapped at B8000, under EFI we can assume output
capabilities (whichever the system owner set up in the firmware
setup).

>> not much of a problem for the other two messages as people are
>> unlikely to try to boot Xen on an unsuitable system, but I view it
>> as quite possible for Xen to be tried to get booted with an
>> unsuitable grub2.
>>
>> IOW - this needs a better solution, presumably using EFI boot
>> service output functions.
> 
> No way, here boot services are dead. GRUB2 (or other loader)
> shutdown them... :-(((

Wasn't one of your grub2 changes being precisely the deferral of
that to Xen?

>> > +cld
>> > +
>> > +/* Check for Multiboot2 bootloader. */
>> > +cmp $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
>> > +je  efi_multiboot2_proto
>> > +
>> > +/* Jump to not_multiboot after switching CPU to x86_32 mode. */
>> > +lea not_multiboot(%rip),%rdi
>> > +jmp x86_32_switch
>>
>> What I've said above would also eliminate the need to switch to
>> 32-bit mode just for emitting an error message and halting the
>> system.
> 
> It is not possible. We just know that we run on EFI platform here.
> However, we are not able to get EFI SystemTable pointer.

How are we not able? Later C code does it afair, so why would it not
be possible here?

>> > +efi_multiboot2_proto:
>>
>> .Lefi_multiboot2_proto
> 
> OK if you insist. However, I think that we are loosing helpful
> debug information this way.

I don't see why or how. Labels persisting in the final symbol table
are useful only for generating stack traces, yet if you crash this
early there won't be any stack trace anyway - you don't even
have an IDT set up yet.

>> > +/*
>> > + * Multiboot2 information address is 32-bit,
>> > + * so, zero higher half of %rbx.
>> > + */
>> > +mov %ebx,%ebx
>>
>> Wait, no - that's a protocol bug then. We're being entered in 64-bit
>> mode here, so registers should be in 64-bit clean state.
> 
> You mean higher half cleared. Right? This is not guaranteed.

Hence me saying "that's a protocol bug then".

> Please check this: 
> http://lists.gnu.org/archive/html/grub-devel/2016-03/msg00304.html 

Other than the description of the patch I can't see anything like that,
in particular
- no occurrence of "ebx" in any of the added or changed code
- MULTIBOOT_EFI_MBI_REGISTER getting #define-d as rbx

>> > +/* Skip Multiboot2 information fixed part. */
>> > +lea (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%rbx),%rcx
>> > +and $~(MULTIBOOT2_TAG_ALIGN-1),%rcx
>>
>> Or if there really was a reason to do the above, and if there is a
>> reason not to assume this data is located below 4Gb, then
>> calculations like this could avoid the REX64 prefix by using %ecx.
> 
> Here you said something different:
>   http://lists.xen.org/archives/html/xen-devel/2015-03/msg03557.html 
> 
> So?

So? You simply went too far: There talk was of memory accesses,
i.e. the (%rbx) part of the instruction above. Using (%ebx) there
would cause a pointless address size override prefix emitted. Now
in the new form above you force a pointless REX prefix to be
emitted. The whole point of both of my requests is - avoid prefixes
if you don't really need them.

>> > +0:
>> > +/* Get EFI SystemTable address from Multiboot2 information.

Re: [Xen-devel] Discussion about virtual iommu support for Xen guest

2016-05-27 Thread Paul Durrant 
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Tian, Kevin
> Sent: 27 May 2016 09:35
> To: Andrew Cooper; Lan, Tianyu; jbeul...@suse.com; sstabell...@kernel.org;
> Ian Jackson; xen-de...@lists.xensource.com; Eddie Dong; Nakajima, Jun;
> yang.zhang...@gmail.com; Anthony Perard
> Subject: Re: [Xen-devel] Discussion about virtual iommu support for Xen
> guest
> 
> > From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> > Sent: Thursday, May 26, 2016 7:36 PM
> >
> > On 26/05/16 09:29, Lan Tianyu wrote:
> > > Hi All:
> > > We try pushing virtual iommu support for Xen guest and there are some
> > > features blocked by it.
> > >
> > > Motivation:
> > > ---
> > > 1) Add SVM(Shared Virtual Memory) support for Xen guest
> > > To support iGFX pass-through for SVM enabled devices, it requires
> > > virtual iommu support to emulate related registers and intercept/handle
> > > guest SVM configure in the VMM.
> > >
> > > 2) Increase max vcpu support for one VM.
> > >
> > > So far, max vcpu for Xen hvm guest is 128. For HPC(High Performance
> > > Computing) cloud computing, it requires more vcpus support in a single
> > > VM. The usage model is to create just one VM on a machine with the
> > > same number vcpus as logical cpus on the host and pin vcpu on each
> > > logical cpu in order to get good compute performance.
> > >
> > > Intel Xeon phi KNL(Knights Landing) is dedicated to HPC market and
> > > supports 288 logical cpus. So we hope VM can support 288 vcpu
> > > to meet HPC requirement.
> > >
> > > Current Linux kernel requires IR(interrupt remapping) when MAX APIC
> > > ID is > 255 because interrupt only can be delivered among 0~255 cpus
> > > without IR. IR in VM relies on the virtual iommu support.
> > >
> > > KVM Virtual iommu support status
> > > 
> > > Current, Qemu has a basic virtual iommu to do address translation for
> > > virtual device and it only works for the Q35 machine type. KVM reuses it
> > > and Redhat is adding IR to support more than 255 vcpus.
> > >
> > > How to add virtual iommu for Xen?
> > > -
> > > First idea came to my mind is to reuse Qemu virtual iommu but Xen didn't
> > > support Q35 so far. Enabling Q35 for Xen seems not a short term task.
> > > Anthony did some related jobs before.
> > >
> > > I'd like to see your comments about how to implement virtual iommu for
> Xen.
> > >
> > > 1) Reuse Qemu virtual iommu or write a separate one for Xen?
> > > 2) Enable Q35 for Xen to reuse Qemu virtual iommu?
> > >
> > > Your comments are very appreciated. Thanks a lot.
> >
> > To be viable going forwards, any solution must work with PVH/HVMLite as
> > much as HVM.  This alone negates qemu as a viable option.
> 
> KVM wants things done in Qemu as much as possible. Now Xen may
> have more things moved into hypervisor instead for HVMLite. The end
> result is that many new platform features from IHVs will require
> double effort in the future (nvdimm is another example) which means
> much longer enabling path to bring those new features to customers.
> 
> I can understand the importance of covering HVMLite in Xen community,
> but is it really the only factor to negate Qemu option?
> 
> >
> > From a design point of view, having Xen needing to delegate to qemu to
> > inject an interrupt into a guest seems backwards.
> >
> >
> > A whole lot of this would be easier to reason about if/when we get a
> > basic root port implementation in Xen, which is necessary for HVMLite,
> > and which will make the interaction with qemu rather more clean.  It is
> > probably worth coordinating work in this area.
> 
> Would it make Xen too complex? Qemu also has its own root port
> implementation, and then you need some tricks within Qemu to not
> use its own root port but instead registering to Xen root port. Why is
> such movement more clean?
> 

Upstream QEMU already registers PCI BDFs with Xen, and Xen already handles cf8 
and cfc accesses (to turn them into single config space read/write ioreqs). So, 
it really isn't much of a leap to put the root port implementation in Xen.

  Paul

> >
> >
> > As for the individual issue of 288vcpu support, there are already issues
> > with 64vcpu guests at the moment.  While it is certainly fine to remove
> > the hard limit at 255 vcpus, there is a lot of other work required to
> > even get 128vcpu guests stable.
> >
> 
> Thanks
> Kevin
> ___
> 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

[Xen-devel] xsplice: should we use realpath or readlink in xsplice-build?

2016-05-27 Thread Dongli Zhang 
Hi Ross and Konrad,

I played xsplice with a sample patch I wrote. It works and really fantastic
work! 

I use the utility from
git://xenbits.xen.org/people/konradwilk/xsplice-build-tools.git

However, the 'realpath -m' command in file 'xsplice-build' work on neither my
Ubuntu or Oracle Linuxi (no -m option). It works well after I replace all
'realpath' with 'readlink'. The patch elf was generated successfully and could
be uploaded and applied.

I am not sure if this is the issue with my OS configuration or we should better
use 'readlink'. Since this is the new git repo, I am not sure if I could submit
this patch to xen-devel if a patch is helpful.

Thank you very much!

Best,

Dongli Zhang



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

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

2016-05-27 Thread osstest service owner 
flight 94819 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94819/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  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-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-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
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 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  110 days
Testing same since93977  2016-05-10 11:09:16 Z   16 days   66 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] [PATCH v3 12/16 - RFC] x86/efi: create new early memory allocator

2016-05-27 Thread Jan Beulich 
>>> On 25.05.16 at 21:48,  wrote:
> On Wed, May 25, 2016 at 02:39:57AM -0600, Jan Beulich wrote:
>> >>> On 15.04.16 at 14:33,  wrote:
>> > There is a problem with place_string() which is used as early memory
>> > allocator. It gets memory chunks starting from start symbol and
>> > going down. Sadly this does not work when Xen is loaded using multiboot2
>> > protocol because start lives on 1 MiB address. So, I tried to use
>> > mem_lower address calculated by GRUB2. However, it works only on some
>> > machines. There are machines in the wild (e.g. Dell PowerEdge R820)
>> > which uses first ~640 KiB for boot services code or data... :-(((
>> >
>> > In case of multiboot2 protocol we need that place_string() only allocate
>> > memory chunk for EFI memory map. However, I think that it should be fixed
>> > instead of making another function used just in one case. I thought about
>> > two solutions.
>> >
>> > 1) We could use native EFI allocation functions (e.g. AllocatePool()
>> >or AllocatePages()) to get memory chunk. However, later (somewhere
>> >in __start_xen()) we must copy its contents to safe place or reserve
>> >this in e820 memory map and map it in Xen virtual address space.
>> >In later case we must also care about conflicts with e.g. crash
>> >kernel regions which could be quite difficult.
>>
>> I don't see why that would be: Simply use an allocation type that
>> doesn't lead to the area getting consumed as normal RAM. Nor do
>> I see the kexec collision potential. Furthermore (and I think I've
>> said so before) ARM is already using AllocatePool() - just with an
>> unsuitable memory type -, so doing so on x86 too would allow for
> 
> Nope, they are using standard EfiLoaderData.

Note how I said "just with an unsuitable memory type"?

>> > Jan Beulich added 1b) Do away with efi_arch_allocate_mmap_buffer() and use
>> >AllocatePages() uniformly, perhaps with a per-arch specified memory type
>> >(by means of which you can control whether the memory contents will 
>> > remain
>> >preserved until the time you want to look at it). That will eliminate 
>> > the
>> >only place_string() you're concerned about, with a patch with better
>> >diffstat (largely due to the questionable arch hook gone).
>> >
>> > However, this solution does not solve conflicts problem described in #1
>> > because EFI memory map is needed during Xen runtime after init phase.
>> > So, finally we would get back to #1. Hmmm... Should I check how Linux
>> > and others cope with that problem?
>>
>> Ah, here you mention it actually. Yet you don't explain what conflict
>> potential you see once using EfiRuntimeServicesData for the allocation.
> 
> Good point! IMO, if crash kernel region conflicts with EfiRuntimeServices*
> then we should display warning that it cannot be allocated. By the way,
> once you mentioned that you have in your queue (I suppose that it is
> extremely long) kdump patch which adds functionality to automatically
> establish crash kernel region placement. I think that could solve (at
> least partially) problem with conflicts. Could you post it?

For one, unless asked to be at a specific location, we already dynamically
place that area. The patch that I believe you think of just enhances the
placement to have something between "fully dynamic" and "at a fixed
place". I've never posted it (or even ported it to -unstable) because I've
never got positive feedback on it by those who it was originally created
for. If you think it could be useful, I can certainly revive it.

Jan


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

Re: [Xen-devel] Discussion about virtual iommu support for Xen guest

2016-05-27 Thread Tian, Kevin 
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, May 26, 2016 7:36 PM
> 
> On 26/05/16 09:29, Lan Tianyu wrote:
> > Hi All:
> > We try pushing virtual iommu support for Xen guest and there are some
> > features blocked by it.
> >
> > Motivation:
> > ---
> > 1) Add SVM(Shared Virtual Memory) support for Xen guest
> > To support iGFX pass-through for SVM enabled devices, it requires
> > virtual iommu support to emulate related registers and intercept/handle
> > guest SVM configure in the VMM.
> >
> > 2) Increase max vcpu support for one VM.
> >
> > So far, max vcpu for Xen hvm guest is 128. For HPC(High Performance
> > Computing) cloud computing, it requires more vcpus support in a single
> > VM. The usage model is to create just one VM on a machine with the
> > same number vcpus as logical cpus on the host and pin vcpu on each
> > logical cpu in order to get good compute performance.
> >
> > Intel Xeon phi KNL(Knights Landing) is dedicated to HPC market and
> > supports 288 logical cpus. So we hope VM can support 288 vcpu
> > to meet HPC requirement.
> >
> > Current Linux kernel requires IR(interrupt remapping) when MAX APIC
> > ID is > 255 because interrupt only can be delivered among 0~255 cpus
> > without IR. IR in VM relies on the virtual iommu support.
> >
> > KVM Virtual iommu support status
> > 
> > Current, Qemu has a basic virtual iommu to do address translation for
> > virtual device and it only works for the Q35 machine type. KVM reuses it
> > and Redhat is adding IR to support more than 255 vcpus.
> >
> > How to add virtual iommu for Xen?
> > -
> > First idea came to my mind is to reuse Qemu virtual iommu but Xen didn't
> > support Q35 so far. Enabling Q35 for Xen seems not a short term task.
> > Anthony did some related jobs before.
> >
> > I'd like to see your comments about how to implement virtual iommu for Xen.
> >
> > 1) Reuse Qemu virtual iommu or write a separate one for Xen?
> > 2) Enable Q35 for Xen to reuse Qemu virtual iommu?
> >
> > Your comments are very appreciated. Thanks a lot.
> 
> To be viable going forwards, any solution must work with PVH/HVMLite as
> much as HVM.  This alone negates qemu as a viable option.

KVM wants things done in Qemu as much as possible. Now Xen may 
have more things moved into hypervisor instead for HVMLite. The end
result is that many new platform features from IHVs will require
double effort in the future (nvdimm is another example) which means
much longer enabling path to bring those new features to customers.

I can understand the importance of covering HVMLite in Xen community,
but is it really the only factor to negate Qemu option?

> 
> From a design point of view, having Xen needing to delegate to qemu to
> inject an interrupt into a guest seems backwards.
> 
> 
> A whole lot of this would be easier to reason about if/when we get a
> basic root port implementation in Xen, which is necessary for HVMLite,
> and which will make the interaction with qemu rather more clean.  It is
> probably worth coordinating work in this area.

Would it make Xen too complex? Qemu also has its own root port 
implementation, and then you need some tricks within Qemu to not
use its own root port but instead registering to Xen root port. Why is
such movement more clean?

> 
> 
> As for the individual issue of 288vcpu support, there are already issues
> with 64vcpu guests at the moment.  While it is certainly fine to remove
> the hard limit at 255 vcpus, there is a lot of other work required to
> even get 128vcpu guests stable.
> 

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

Re: [Xen-devel] [PATCH v3 11/16] efi: build xen.gz with EFI code

2016-05-27 Thread Jan Beulich 
>>> On 25.05.16 at 21:07,  wrote:
> On Wed, May 25, 2016 at 01:53:31AM -0600, Jan Beulich wrote:
>> >>> On 15.04.16 at 14:33,  wrote:
>> > --- a/xen/arch/x86/efi/Makefile
>> > +++ b/xen/arch/x86/efi/Makefile
>> > @@ -1,14 +1,9 @@
>> >  CFLAGS += -fshort-wchar
>> >
>> > -obj-y += stub.o
>> > -
>> > -create = test -e $(1) || touch -t 19990101 $(1)
>> > -
>> >  efi := y$(shell rm -f disabled)
>> >  efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) 
>> > -c 
> check.c 2>disabled && echo y))
>> >  efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi 
>> > check.o 
>2>disabled && echo y))
>> > -efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call 
> create,boot.init.o); $(call create,runtime.o)))
>> > +efi := $(if $(efi),$(shell rm disabled)y)
>> >
>> > -extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o
>> > -
>> > -stub.o: $(extra-y)
>> > +obj-y := stub.o
>> > +obj-$(efi) := boot.init.o compat.o relocs-dummy.o runtime.o
>>
>> I assume/hope all these adjustments work for all intended cases, but
> 
> I have done some tests and it looks that everything works.
> 
>> they quite clearly leave stale bits in xen/arch/x86/Rules.mk: Its
> 
> I suppose that you were thinking about xen/arch/x86/Makefile.

Oh, yes, of course.

>> references to efi/*.o should all go away now afaict.
> 
> OK.
> 
>> > --- a/xen/common/efi/boot.c
>> > +++ b/xen/common/efi/boot.c
>> > @@ -1244,6 +1244,9 @@ void __init efi_init_memory(void)
>> >  } *extra, *extra_head = NULL;
>> >  #endif
>> >
>> > +if ( !efi_enabled(EFI_PLATFORM) )
>> > +return;
>>
>> Arguably such checks would then better be put at the call site,
>> allowing the respective stubs to just BUG().
> 
> Ugh... I am confused. Here 
> http://lists.xen.org/archives/html/xen-devel/2015-08/msg01790.html 
> you asked for what is done above. So, what is your final decision?

Well, in v2 you didn't alter stubs.c at all. It's that connection
which makes me think using that earlier approach might be better.
The more that, from a purely abstract pov, it could even allow to
remove some or all of stubs.c in a truly non-EFI build, provided we
never build with -O0.

But in the end, starting the sens with "arguably" I mean to express
that this isn't all that important.

>> Also - what's your rule for where to put such efi_enabled() checks?
>> I would have expected them to get added to everything that has
>> a counterpart in stubs.c, but things like efi_get_time() or
>> efi_{halt,reset}_system() don't get any added. If those are
>> unreachable, I'd at least expect respective ASSERT()s to get added
>> there.
> 
> I have added checks to functions which are called from common EFI/BIOS code.

And how are the ones I named not called from "common" code?

Jan


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

Re: [Xen-devel] Discussion about virtual iommu support for Xen guest

2016-05-27 Thread Lan Tianyu 
On 2016年05月26日 19:35, Andrew Cooper wrote:
> On 26/05/16 09:29, Lan Tianyu wrote:
> 
> To be viable going forwards, any solution must work with PVH/HVMLite as
> much as HVM.  This alone negates qemu as a viable option.
> 
> From a design point of view, having Xen needing to delegate to qemu to
> inject an interrupt into a guest seems backwards.
>

Sorry, I am not familiar with HVMlite. HVMlite doesn't use Qemu and
the qemu virtual iommu can't work for it. We have to rewrite virtual
iommu in the Xen, right?

> 
> A whole lot of this would be easier to reason about if/when we get a
> basic root port implementation in Xen, which is necessary for HVMLite,
> and which will make the interaction with qemu rather more clean.  It is
> probably worth coordinating work in this area.

The virtual iommu also should be under basic root port in Xen, right?

> 
> As for the individual issue of 288vcpu support, there are already issues
> with 64vcpu guests at the moment. While it is certainly fine to remove
> the hard limit at 255 vcpus, there is a lot of other work required to
> even get 128vcpu guests stable.


Could you give some points to these issues? We are enabling more vcpus
support and it can boot up 255 vcpus without IR support basically. It's
very helpful to learn about known issues.

We will also add more tests for 128 vcpus into our regular test to find
related bugs. Increasing max vcpu to 255 should be a good start.





> 
> ~Andrew
> 


-- 
Best regards
Tianyu Lan

___
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

2016-05-27 Thread Jan Beulich 
>>> On 27.05.16 at 10:13,  wrote:
> On 27/05/16 09:08, Jan Beulich wrote:
> On 26.05.16 at 12:28,  wrote:
>> @@ -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.
 Make sense, however, I am in line with multiboot1_header_end label here.
 So, if we wish .L here then we should change multiboot1_header_end label
 above too. Of course in separate patch.
>>> The multiboot1 header is very specifically not a local label, so you can
>>> distinguish the actual header from the 3 nops following it in the
>>> disassembly.
>> I don't follow: Those NOPs (also not sure why you think it's three of
>> them) are there just for padding (alignment), so no need to label
>> them.
> 
> That wasn't the point I was trying to make.
> 
> This is data in a code segment, so objdump/gdb disassembly tries to
> disassemble the data as instructions.
> 
> While the instruction decode of the header is definitely junk, having
> the end label proves an exact boundary for the data in terms of reported
> raw bytes, as well as prevent the following nops being subsumed into the
> bogus decode.

Where the NOPs go doesn't matter. The only relevant thing for
disassembly is that the next actual instruction gets decoded
correctly. And that next instruction follows its own label
(__high_start). Let's please not carry more symbols at runtime
than are really useful.

Jan


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

Re: [Xen-devel] [PATCH v3 10/16] efi: create efi_enabled()

2016-05-27 Thread Jan Beulich 
>>> On 25.05.16 at 19:15,  wrote:
> On Wed, May 25, 2016 at 01:20:23AM -0600, Jan Beulich wrote:
>> >>> On 15.04.16 at 14:33,  wrote:
>> > --- a/xen/arch/x86/efi/stub.c
>> > +++ b/xen/arch/x86/efi/stub.c
>> > @@ -4,11 +4,8 @@
>> >  #include 
>> >  #include 
>> >
>> > -#ifndef efi_enabled
>> > -const bool_t efi_enabled = 0;
>> > -#endif
>> > -
>> >  struct efi __read_mostly efi = {
>> > +  .flags   = 0, /* Initialized later. */
>>
>> This is pointless to add - the field will get zero-initialized anyway.
> 
> Sure thing. However, I think that we should be clear here that
> there is no default value for .flags (well, it is 0). Though if
> you wish I can remove that.

As you say, the initial value for flags is zero, with or without your
addition. Hence the addition is pointless.

>> > --- a/xen/include/xen/efi.h
>> > +++ b/xen/include/xen/efi.h
>> > @@ -2,15 +2,17 @@
>> >  #define __XEN_EFI_H__
>> >
>> >  #ifndef __ASSEMBLY__
>> > +#include 
>> >  #include 
>> >  #endif
>> >
>> > -extern const bool_t efi_enabled;
>> > -
>> >  #define EFI_INVALID_TABLE_ADDR (~0UL)
>> >
>> > +#define EFI_PLATFORM  0
>>
>> So what does "platform" mean? Did you consider using the more fine
> 
> It means "EFI platform". It differentiates from "legacy BIOS platform".

Well, that's what was clear from the beginning. The question however
was (taken together with the second one) what it means functionality
wise. The later addition makes clear it doesn't mean "loaded directly
from EFI". But looking at the various flags Linux has here, what
functionality does it imply? Does it e.g. mean runtime services are to
be used? If so, the flag would need to be cleared when their use if
being suppressed.

>> grained set of flags Linux uses nowadays? That would also eliminate
> 
> I wish to use just basic idea. However, I am not going to copy all
> stuff from Linux. We do not need that.

We don't need all of it, sure. But some more fine grained
identification of what functionality is available / to be used
would surely benefit us as a whole and your patch series in
particular.

Jan


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

Re: [Xen-devel] [PATCH v3 09/16] efi: explicitly define efi struct in xen/arch/x86/efi/stub.c

2016-05-27 Thread Jan Beulich 
>>> On 25.05.16 at 18:45,  wrote:
> On Wed, May 25, 2016 at 01:03:42AM -0600, Jan Beulich wrote:
>> >>> On 15.04.16 at 14:33,  wrote:
>> > Existing solution does not allocate space for this symbol and any
>> > references to acpi20, etc. does not make sense. As I saw any efi.*
>> > references are protected by relevant ifs but we should not do that
>> > because it makes code very fragile. If somebody does not know how
>> > efi symbol is created he/she may assume that it always represent
>> > valid structure and do invalid references somewhere.
>>
>> I do not view this as a valid reason for the change.
> 
> Why?

Because there are no accesses to the structure in non-EFI builds?
Even if it's just a small table, I'm generally opposed to adding dead
code or data. I simply do not like the attitude of "memory is cheap"
these days. Following that model leads to quite a bit of useless
bloat. Plus no matter whether memory is cheap, cache and TLB
bandwidth are precious, and both may get pressure added by such
dead elements.

>> > --- a/xen/arch/x86/efi/stub.c
>> > +++ b/xen/arch/x86/efi/stub.c
>> > @@ -8,6 +8,14 @@
>> >  const bool_t efi_enabled = 0;
>> >  #endif
>> >
>> > +struct efi __read_mostly efi = {
>> > +  .acpi= EFI_INVALID_TABLE_ADDR,
>> > +  .acpi20  = EFI_INVALID_TABLE_ADDR,
>> > +  .mps = EFI_INVALID_TABLE_ADDR,
>> > +  .smbios  = EFI_INVALID_TABLE_ADDR,
>> > +  .smbios3 = EFI_INVALID_TABLE_ADDR
>> > +};
>>
>> I don't view duplicating this here as a good approach - you'd better
>> move the existing instance elsewhere. If this was a temporary thing
>> (until a later patch), it might be acceptable, but since building without
>> EFI support will need to remain an option (for people using older tool
>> chains), I don't expect a later patch to remove this.
> 
> Do you think about separate C file which should contain efi struct
> and should be included in stub.c and runtime.c? Or anything else?

A separate file seems to be overkill. Just move it to some other
existing file; I'm sure some sensible place can be found.

Jan


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

  1   2   >