[Xen-devel] [xen-4.7-testing test] 101932: regressions - FAIL

[osstest service owner]

flight 101932 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101932/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64  9 windows-install   fail REGR. vs. 101683
 build-amd64-xsm   5 xen-build  fail in 101925 REGR. vs. 101683
 build-i3865 xen-build  fail in 101925 REGR. vs. 101683
 build-i386-xsm5 xen-build  fail in 101925 REGR. vs. 101683
 build-amd64   5 xen-build  fail in 101925 REGR. vs. 101683

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-raw 14 guest-start/debian.repeat  fail pass in 101925

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 101683
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 101683
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101683
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 101683
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 101683
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101683

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked in 101925 
n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1) blocked in 101925 n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)blocked in 101925 n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
101925 n/a
 test-xtf-amd64-amd64-11 build-check(1)   blocked in 101925 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
101925 n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked in 
101925 n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked in 101925 n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
in 101925 n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked in 101925 n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked in 101925 n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)  blocked in 101925 n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)  blocked in 101925 n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked in 101925 n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)  blocked in 101925 n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked in 101925 n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked in 101925 n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)   blocked in 101925 n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)blocked in 101925 n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked in 101925 n/a
 build-i386-rumprun1 build-check(1)   blocked in 101925 n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1)   blocked in 101925 n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
101925 n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked in 101925 n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1) blocked in 101925 n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked in 101925 n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)  blocked in 101925 n/a
 test-xtf-amd64-amd64-21 build-check(1)   blocked in 101925 n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1)   blocked in 101925 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked in 101925 n/a
 build-amd64-rumprun   1 build-check(1)   blocked in 101925 n/a
 build-i386-libvirt1 build-check(1)   blocked in 101925 n/a
 test-amd64-i386-xl1 build-check(1)   blocked in 101925 n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked in 101925 n/a
 test-xtf-amd64-amd64-41 build-check(1)   blocked in 101925 n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1)   blocked in 101925 n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked in 101925 n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked in 101925 n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked in 101925 n/a
 build-amd64-libvirt   1 build-check(1)   blocked in 101925 n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
101925 n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1) blocked in 101925 n/a
 test-xtf-amd64-amd64-31 build-check(1)   blocked in 101925 n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)blocked in 101925 n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)  blocked in 101925 n/a
 

[Xen-devel] [qemu-mainline baseline-only test] 67996: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67996 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67996/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-midway   15 guest-start/debian.repeat fail REGR. vs. 67991
 test-armhf-armhf-xl-vhd   9 debian-di-install fail REGR. vs. 67991

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67991
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 67991

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

version targeted for testing:
 qemuu199a5bde46b0eab898ab1ec591f423000302569f
baseline version:
 qemuu4eb28abd52d48657cff6ff45e8dbbbefe4dbb414

Last test of basis67991  2016-11-03 23:17:44 Z1 days
Testing same since67996  2016-11-04 13:19:54 Z0 days1 attempts


People who touched revisions under test:
  Alex Bennée 
  Alex Bennée 
  Changlong Xie 
  Christian Borntraeger 
  Corey Minyard 
  Cédric Le Goater 
  Dan Williams 
  Daniel P. Berrange 
  Dr. David Alan Gilbert 
  Eric Blake 
  Gonglei 
  Haozhong Zhang 
  Jeff Cody 
  Luwei Kang 
  Max Reitz 
  Michael S. Tsirkin 
  Paolo Bonzini 
  Piotr Luc 
  Pranith Kumar 
  Stefan Hajnoczi 
  Xiao Guangrong 

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

[Xen-devel] [linux-3.10 test] 101923: regressions - FAIL

[osstest service owner]

flight 101923 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101923/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-amd64-pvgrub  6 xen-bootfail REGR. vs. 100648
 test-amd64-i386-xl-xsm6 xen-boot fail REGR. vs. 100648
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 100648
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot fail REGR. vs. 100648
 test-amd64-amd64-xl   6 xen-boot fail REGR. vs. 100648
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 100648
 test-amd64-amd64-xl-credit2   6 xen-boot fail REGR. vs. 100648
 test-amd64-i386-xl6 xen-boot fail REGR. vs. 100648

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt-xsm   9 debian-install   fail in 101783 pass in 101923
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail pass in 101576
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail pass in 101594
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail pass in 
101663
 test-amd64-i386-libvirt   6 xen-boot   fail pass in 101680
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-boot  fail pass in 101680
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot   fail pass in 101731
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 
101731
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_host fail pass in 101731
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host fail pass in 101731
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-boot fail pass in 101783
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot   fail pass in 101783
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host  fail pass in 101800
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host  fail pass in 101800
 test-amd64-i386-pair  9 xen-boot/src_host  fail pass in 101800
 test-amd64-i386-pair 10 xen-boot/dst_host  fail pass in 101800
 test-amd64-amd64-qemuu-nested-intel  6 xen-bootfail pass in 101814
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 
101828
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot   fail pass in 101828
 test-amd64-amd64-pair 9 xen-boot/src_host  fail pass in 101828
 test-amd64-amd64-pair10 xen-boot/dst_host  fail pass in 101828
 test-amd64-i386-freebsd10-i386  6 xen-boot fail pass in 101837
 test-amd64-amd64-xl-multivcpu  6 xen-boot  fail pass in 101837
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot  fail pass in 101844
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot   fail pass in 101844
 test-amd64-amd64-xl-xsm   6 xen-boot   fail pass in 101856

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 fail in 101594 like 100646
 build-i386-rumprun5 rumprun-build fail in 101663 baseline untested
 build-amd64-rumprun   5 rumprun-build fail in 101663 baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100648
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100648

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt 12 migrate-support-check fail in 101680 never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 101731 never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 101731 never pass
 build-i386-rumprun7 xen-buildfail   never pass
 build-amd64-rumprun   7 xen-buildfail   never pass
 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-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 linux7828a9658951301a3fd83daa4ed0a607d370399e
baseline version:
 linux2ecaf1d025af0f481d00b3701ffbcc600dcab076

Last test of basis   100648  2016-08-28 23:14:14 Z   68 days
Testing same since   101576  2016-10-21 10:51:14 Z   14 days   23 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf fdaf78424da45b34ef515119cd308ffa8cd43d54
baseline version:
 ovmf 12a37b2ae19b1edabf390c0744ae0af9bb9d2b9a

Last test of basis   101922  2016-11-04 10:17:15 Z0 days
Testing same since   101930  2016-11-04 17:14:46 Z0 days1 attempts


People who touched revisions under test:
  Jiewen Yao 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=fdaf78424da45b34ef515119cd308ffa8cd43d54
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
fdaf78424da45b34ef515119cd308ffa8cd43d54
+ branch=ovmf
+ revision=fdaf78424da45b34ef515119cd308ffa8cd43d54
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xfdaf78424da45b34ef515119cd308ffa8cd43d54 = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : 

[Xen-devel] [ovmf baseline-only test] 67997: trouble: broken/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67997 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67997/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3) broken REGR. vs. 67994

version targeted for testing:
 ovmf 669b6cc60bf610bbee32e79ed165ca604764c169
baseline version:
 ovmf 5f609eb837f235e28464285a2fb768e39cd51b56

Last test of basis67994  2016-11-04 08:18:04 Z0 days
Testing same since67997  2016-11-04 16:17:17 Z0 days1 attempts


People who touched revisions under test:
  Bell Song 
  Dandan Bi 
  Song, BinX 
  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 broken  
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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

broken-step test-amd64-amd64-xl-qemuu-ovmf-amd64 host-install(3)

Push not applicable.


commit 669b6cc60bf610bbee32e79ed165ca604764c169
Author: Yonghong Zhu 
Date:   Thu Nov 3 15:44:17 2016 +0800

BaseTools: Fix the Windows GCC Build Failure with too long path

When path is too long, build tool will wrap them into resp.txt, then call
gcc @resp.txt. It will cause windows GCC build failure, because resp.txt
still uses windows directory separator \. This patch change the \ to /.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
Reviewed-by: Liming Gao 

commit 0c45a5b288437f62b93c046b4cc8827919a79fd1
Author: Song, BinX 
Date:   Thu Nov 3 10:33:20 2016 +0800

MdePkg/BaseLib: Move CHAR_NULL definition to Base.h in BaseLib

- Required unicode control chars -> Null character
- Remove CHAR_NULL definition in SimpleTextIn.h
- https://bugzilla.tianocore.org/show_bug.cgi?id=172

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bell Song 
Reviewed-by: Liming Gao 

commit e135e4a79efdcc1de76a5a38bb17d9f925e6f5a1
Author: Dandan Bi 
Date:   Fri Oct 28 09:34:51 2016 +0800

IntelFrameworkModulePkg/BootMaint: Show "Change Boot order" page correctly

Some boot options may be deleted in the "Delete Boot Option page",
But the data BootOptionOrder in BmmFakeNvData may not be updated.
So when user enter the "Change Boot Order" page, we should not always
get the BootOptionOrder in BmmFakeNvData, it will result in incorrect
UI behaviors. When the Boot Options have been saved,
we should get the BootOptionOrder through function GetBootOrder.

For driver option codes need to do the same change.

This patch is to fix the issue in bugzilla:
https://bugzilla.tianocore.org/show_bug.cgi?id=39

Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Eric Dong 

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

Re: [Xen-devel] [xen-unstable baseline-only test] 67995: regressions - FAIL

[Andrew Cooper]

On 04/11/2016 22:59, Platform Team regression test user wrote:
> This run is configured for baseline tests only.
>
> flight 67995 xen-unstable real [real]
> http://osstest.xs.citrite.net/~osstest/testlogs/logs/67995/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-xtf-amd64-amd64-5   10 xtf-fep   fail REGR. vs. 
> 67981
>  test-xtf-amd64-amd64-1   10 xtf-fep   fail REGR. vs. 
> 67981
>  test-xtf-amd64-amd64-2   10 xtf-fep   fail REGR. vs. 
> 67981
>  test-xtf-amd64-amd64-3   10 xtf-fep   fail REGR. vs. 
> 67981
>  test-xtf-amd64-amd64-4   10 xtf-fep   fail REGR. vs. 
> 67981

The switch from debug to non-debug has resulted in FEP being disabled by
default.  OSSTest should explicitly enable FEP in the builds of Xen
which it uses.

~Andrew

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

[Xen-devel] [xen-unstable baseline-only test] 67995: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67995 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67995/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-5   10 xtf-fep   fail REGR. vs. 67981
 test-xtf-amd64-amd64-1   10 xtf-fep   fail REGR. vs. 67981
 test-xtf-amd64-amd64-2   10 xtf-fep   fail REGR. vs. 67981
 test-xtf-amd64-amd64-3   10 xtf-fep   fail REGR. vs. 67981
 test-xtf-amd64-amd64-4   10 xtf-fep   fail REGR. vs. 67981

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67981
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67981
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 67981
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 67981

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-i386-rumprun6 xen-buildfail   never pass
 build-amd64-rumprun   6 xen-buildfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  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-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail 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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  4ccb2adb96042e0d1e334c01fe260b32e6001db9
baseline version:
 xen  496673a2ada93c201fbe1cc83146c8bd8e79169d

Last test of basis67981  2016-11-02 15:46:22 Z2 days
Testing same since67995  2016-11-04 09:16:29 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Roger Pau Monne 
  Roger Pau Monné 

[Xen-devel] [xen-4.6-testing test] 101924: regressions - FAIL

[osstest service owner]

flight 101924 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101924/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 101679

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 101679
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 101679
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101679
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101679
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101679
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 101679
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 101679
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101679
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 101679

Tests which did not succeed, but are not blocking:
 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-xsm  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-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail 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-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 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-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-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  fa062b2b9a49fa8f0cb44a3854a121b31f40c10d
baseline version:
 xen  03da413a6465f06a2b2854f2b2645f3cae5cbc9c

Last test of basis   101679  2016-10-26 06:28:04 Z9 days
Testing same since   101924  2016-11-04 11:47:32 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  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
 

[Xen-devel] [PATCH v2 2/2] Partially revert 21550029f709072aacf3b90edd574e7d3021b400

[Stefano Stabellini]

Commit 21550029f709072aacf3b90edd574e7d3021b400 removed the
PLATFORM_QUIRK_GIC_64K_STRIDE quirk and introduced a way to
automatically detect that the two GICC pages have a 64K stride.

However the heuristic requires that the device tree for the platform
reports a GICC size == 128K, which is not the case for some versions of
XGene.

Fix the issue by partially reverting
21550029f709072aacf3b90edd574e7d3021b400:

- reintroduce PLATFORM_QUIRK_GIC_64K_STRIDE for XGene
- force csize and vsize to SZ_128K if csize is initially 4K and if
  PLATFORM_QUIRK_GIC_64K_STRIDE

Also add a warning in case GICC is SZ_128K but not aliased.

Signed-off-by: Stefano Stabellini 

---

Changes in v2:
- only set csize to SZ_128K if it is initially SZ_4K
- set vsize to match
- add warning if gicc is SZ_128K and not aliased
---
 xen/arch/arm/gic-v2.c| 10 --
 xen/arch/arm/platforms/xgene-storm.c |  6 ++
 xen/include/asm-arm/platform.h   |  6 ++
 3 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 9bd9d0b..fd2f3b4 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -965,7 +965,10 @@ static void __init gicv2_dt_init(void)
 printk(XENLOG_WARNING "GICv2: WARNING: "
"The GICC size is too small: %#"PRIx64" expected %#x\n",
csize, SZ_8K);
-csize = SZ_8K;
+if ( platform_has_quirk(PLATFORM_QUIRK_GIC_64K_STRIDE) )
+vsize = csize = SZ_128K;
+else
+csize = SZ_8K;
 }
 
 /*
@@ -1189,7 +1192,10 @@ static int __init gicv2_init(void)
 printk(XENLOG_WARNING
"GICv2: Adjusting CPU interface base to %#"PRIx64"\n",
cbase + aliased_offset);
-}
+} else if ( csize == SZ_128K )
+printk(XENLOG_WARNING
+"GICv2: GICC size=%lu but not aliased\n",
+csize);
 
 gicv2.map_hbase = ioremap_nocache(hbase, PAGE_SIZE);
 if ( !gicv2.map_hbase )
diff --git a/xen/arch/arm/platforms/xgene-storm.c 
b/xen/arch/arm/platforms/xgene-storm.c
index 686b19b..c795a95 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -67,6 +67,11 @@ static void __init xgene_check_pirq_eoi(void)
   "Please upgrade your firmware to the latest version");
 }
 
+static uint32_t xgene_storm_quirks(void)
+{
+return PLATFORM_QUIRK_GIC_64K_STRIDE;
+}
+
 static void xgene_storm_reset(void)
 {
 void __iomem *addr;
@@ -116,6 +121,7 @@ PLATFORM_START(xgene_storm, "APM X-GENE STORM")
 .compatible = xgene_storm_dt_compat,
 .init = xgene_storm_init,
 .reset = xgene_storm_reset,
+.quirks = xgene_storm_quirks,
 PLATFORM_END
 
 /*
diff --git a/xen/include/asm-arm/platform.h b/xen/include/asm-arm/platform.h
index c6e5010..2ea9d61 100644
--- a/xen/include/asm-arm/platform.h
+++ b/xen/include/asm-arm/platform.h
@@ -39,6 +39,12 @@ struct platform_desc {
 const struct dt_device_match *blacklist_dev;
 };
 
+/*
+ * Quirk for platforms where the 4K GIC register ranges are placed at
+ * 64K stride.
+ */
+#define PLATFORM_QUIRK_GIC_64K_STRIDE (1 << 0)
+
 void __init platform_init(void);
 int __init platform_init_time(void);
 int __init platform_specific_mapping(struct domain *d);
-- 
1.9.1


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

[Xen-devel] [PATCH v2 1/2] Revert "xen/arm: platform: Drop the quirks callback"

[Stefano Stabellini]

This reverts commit 14fa16961b03a23e9b883e5f0ed06b6837a489d8.
Do not reintroduce platform_dom0_evtchn_ppi.

Signed-off-by: Stefano Stabellini 
---
 xen/arch/arm/platform.c| 10 ++
 xen/include/asm-arm/platform.h |  7 +++
 2 files changed, 17 insertions(+)

diff --git a/xen/arch/arm/platform.c b/xen/arch/arm/platform.c
index b0bfaa9..0af6d57 100644
--- a/xen/arch/arm/platform.c
+++ b/xen/arch/arm/platform.c
@@ -127,6 +127,16 @@ void platform_poweroff(void)
 platform->poweroff();
 }
 
+bool_t platform_has_quirk(uint32_t quirk)
+{
+uint32_t quirks = 0;
+
+if ( platform && platform->quirks )
+quirks = platform->quirks();
+
+return !!(quirks & quirk);
+}
+
 bool_t platform_device_is_blacklisted(const struct dt_device_node *node)
 {
 const struct dt_device_match *blacklist = NULL;
diff --git a/xen/include/asm-arm/platform.h b/xen/include/asm-arm/platform.h
index f97315d..c6e5010 100644
--- a/xen/include/asm-arm/platform.h
+++ b/xen/include/asm-arm/platform.h
@@ -27,6 +27,12 @@ struct platform_desc {
 /* Platform power-off */
 void (*poweroff)(void);
 /*
+ * Platform quirks
+ * Defined has a function because a platform can support multiple
+ * board with different quirk on each
+ */
+uint32_t (*quirks)(void);
+/*
  * Platform blacklist devices
  * List of devices which must not pass-through to a guest
  */
@@ -42,6 +48,7 @@ int platform_cpu_up(int cpu);
 #endif
 void platform_reset(void);
 void platform_poweroff(void);
+bool_t platform_has_quirk(uint32_t quirk);
 bool_t platform_device_is_blacklisted(const struct dt_device_node *node);
 
 #define PLATFORM_START(_name, _namestr) \
-- 
1.9.1


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

[Xen-devel] [PATCH v2 0/2] Fix Xen boot on XGene

[Stefano Stabellini]

Hi all,

the following commit:

commit 21550029f709072aacf3b90edd574e7d3021b400
Author: Julien Grall 
Date:   Thu Oct 8 19:23:53 2015 +0100

xen/arm: gic-v2: Automatically detect aliased GIC400


removed PLATFORM_QUIRK_GIC_64K_STRIDE and introduced an heuristic to
check whether the two GICC pages have a 64K stride. However the
heuristic needs device tree to report a GICC region size of 128K to work
properly. That is not the case for some versions of XGene (including the
one I am using, kindly provided by CloudLab.us).

The patch series fixes the issue by reintroducing platform quirks,
PLATFORM_QUIRK_GIC_64K_STRIDE, and forcing GICC size to 128K if
PLATFORM_QUIRK_GIC_64K_STRIDE.

We should consider this series for 4.8. 


Changes in v2:
- only set csize to SZ_128K if it is initially SZ_4K
- set vsize to match
- add warning if gicc is SZ_128K and not aliased


Stefano Stabellini (2):
  Revert "xen/arm: platform: Drop the quirks callback"
  Partially revert 21550029f709072aacf3b90edd574e7d3021b400

 xen/arch/arm/gic-v2.c| 10 --
 xen/arch/arm/platform.c  | 10 ++
 xen/arch/arm/platforms/xgene-storm.c |  6 ++
 xen/include/asm-arm/platform.h   | 13 +
 4 files changed, 37 insertions(+), 2 deletions(-)

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

[Xen-devel] [PATCH v8] sndif: add ABI for Para-virtual sound

[Andrushchenko, Oleksandr]

Hi, there!

We would like to bring back to life this thread.
We do hope that the re-worked version of the original patch
addresses all the issues discussed before.
What is more we already have a working version of the
frontend and backend which prove that the protocol works
(those are in the process of preparing to be pushed to
the community as well).

Hope you can review the changes and provide some feedback,
so finally sound devices find their way in the world of Xen

Best regards,
Andrushchenko, Oleksandr
Grytsov, Oleksandr

Andrushchenko, Oleksandr (1):
  This is ABI for the two halves of a Para-virtual sound driver to
communicate with each to other.

 xen/include/public/io/sndif.h   | 583 
 xen/include/public/io/sndif_linux.h | 114 +++
 2 files changed, 697 insertions(+)
 create mode 100644 xen/include/public/io/sndif.h
 create mode 100644 xen/include/public/io/sndif_linux.h

-- 
2.7.4


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

[Xen-devel] [PATCH v8] This is ABI for the two halves of a Para-virtual sound driver to communicate with each to other.

[Andrushchenko, Oleksandr]

Signed-off-by: Oleksandr Dmytryshyn 
Signed-off-by: Iurii Konovalenko 
Signed-off-by: Andrushchenko, Oleksandr 
Signed-off-by: Oleksandr Grytsov 
---
Changes since v1:
 * removed __attribute__((__packed__)) from all structures definitions

Changes since v2:
 * removed all C structures
 * added protocol description between frontend and backend drivers

Changes since v3:
 * fixed some typos
 * renamed XENSND_PCM_FORMAT_FLOAT_** to XENSND_PCM_FORMAT_F32_**
 * renamed XENSND_PCM_FORMAT_FLOAT64_** to XENSND_PCM_FORMAT_F64_**
 * added 'id' field to the request and response packets
 * renamed 'stream_id' to 'stream' in the packets description
 * renamed 'pcm_data_rate' to 'pcm_rate' in the packets description
 * renamed 'pcm_stream_type' to 'pcm_type' in the packets description
 * removed 'stream_id' field from the response packets

Changes since v4:
 * renamed 'stream_id' back to the to 'stream' in the packets description
 * moved 'id' field to the upper position in the response packets

Changes since v5:
 * Slightly reworked request/response packets
 * Size of the request/response packet is changed to the 64 bytes
 * Now parameters for the XENSND_OP_SET_VOLUME/XENSND_OP_GET_VOLUME are
   passed via shared page
 * Added parameters for the XenBus nodes (now each stream can be mapped
   to the defined sound device in the backend using those parameters)
 * Added XenBus state diagrams description

Changes since v6:
 * Reworked streams description  in the Backend XenBus Nodes

Changes since v7:
 * re-worked backend device parameters to be more generic and flexible
 * extended frontend device parameters
 * slightly updated state machine description added mute/unmute commands
 * added constants for XenStore configuration strings
   (fields, PCM formats etc.)
 * changed request/response structure size from 64 octets to 16
 * introduced dynamic buffer allocation instead of
   static XENSND_MAX_PAGES_PER_REQUEST
 * re-worked open request to allow dynamic buffer allocation
 * re-worked read/write/volume requests, so they don't pass grefs:
   buffer from the open request is used for these operations to pass data
 * specified type of the volume value to be a signed value in steps
   of 0.001 dBm, while 0 being 0dBm.
 * added Linux include file with structure definitions
---
---
 xen/include/public/io/sndif.h   | 583 
 xen/include/public/io/sndif_linux.h | 114 +++
 2 files changed, 697 insertions(+)
 create mode 100644 xen/include/public/io/sndif.h
 create mode 100644 xen/include/public/io/sndif_linux.h

diff --git a/xen/include/public/io/sndif.h b/xen/include/public/io/sndif.h
new file mode 100644
index 000..df705a6
--- /dev/null
+++ b/xen/include/public/io/sndif.h
@@ -0,0 +1,583 @@
+/**
+ * sndif.h
+ *
+ * Unified sound-device I/O interface for Xen guest OSes.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (C) 2013-2015 GlobalLogic Inc.
+ * Copyright (C) 2016 EPAM Systems Inc.
+ */
+
+#ifndef __XEN_PUBLIC_IO_XENSND_H__
+#define __XEN_PUBLIC_IO_XENSND_H__
+
+/*
+ * Front->back notifications: When enqueuing a new request, sending a
+ * notification can be made conditional on req_event (i.e., the generic
+ * hold-off mechanism provided by the ring macros). Backends must set
+ * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()).
+ *
+ * Back->front notifications: When enqueuing a new response, sending a
+ * notification can be made conditional on rsp_event (i.e., the generic
+ * hold-off mechanism provided by the ring macros). Frontends must set
+ * rsp_event appropriately (e.g., using RING_FINAL_CHECK_FOR_RESPONSES()).
+ */
+
+/*
+ * Feature and Parameter Negotiation
+ * =
+ * The two halves of a 

Re: [Xen-devel] [PATCH 0/2] Fix Xen boot on XGene

[Stefano Stabellini]

On Wed, 2 Nov 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 01/11/2016 19:29, Stefano Stabellini wrote:
> > On Mon, 31 Oct 2016, Julien Grall wrote:
> > > Hi Stefano,
> > > 
> > > On 26/10/16 23:12, Stefano Stabellini wrote:
> > > > On Wed, 26 Oct 2016, Julien Grall wrote:
> > > > > Hi,
> > > > > Apologize for not respecting the netiquette.
> > > > > 
> > > > > On Tue, 25 Oct 2016, 5:49 p.m. Stefano Stabellini,
> > > > >  wrote:
> > > > >   Hi all,
> > > > > 
> > > > >   the following commit:
> > > > > 
> > > > >   commit 21550029f709072aacf3b90edd574e7d3021b400
> > > > >   Author: Julien Grall 
> > > > >   Date:   Thu Oct 8 19:23:53 2015 +0100
> > > > > 
> > > > >   xen/arm: gic-v2: Automatically detect aliased GIC400
> > > > > 
> > > > > 
> > > > >   removed PLATFORM_QUIRK_GIC_64K_STRIDE and introduced an
> > > > > heuristic to
> > > > >   check whether the two GICC pages have a 64K stride. However the
> > > > >   heuristic needs device tree to report a GICC region size of 128K
> > > > > to
> > > > > work
> > > > >   properly. That is not the case for some versions of XGene
> > > > > (including
> > > > > the
> > > > >   one I am using, kindly provided by CloudLab.us).
> > > > > 
> > > > >   The patch series fixes the issue by reintroducing platform
> > > > > quirks,
> > > > >   PLATFORM_QUIRK_GIC_64K_STRIDE, and forcing GICC size to 128K if
> > > > >   PLATFORM_QUIRK_GIC_64K_STRIDE.
> > > > > 
> > > > >   We should consider this series for 4.8.
> > > > > 
> > > > > 
> > > > > The platform you are using has likely a buggy firmware (I cannot find
> > > > > the
> > > > > mail from
> > > > > APM stating that).
> > > > > 
> > > > > I am not convinced that we should support a such case. IIRC unmodified
> > > > > Linux will
> > > > > not work properly on those platform (e.g the GIC will be drived as a
> > > > > GICv1).
> > > > 
> > > > I agree with you that it is buggy firmware, but unfortunately it is
> > > > still out there, deployed. I am using a regular unmodified old Linux
> > > > kernel (4.0) which works fine (and should still work fine with modern
> > > > Xen hypervisors). I believe this DTS comes from upstream Linux 4.0.
> > > > 
> > > > The question is: should we carry this workaround to make our users' life
> > > > easier? Or should we push back the burden of fixing the firmware to the
> > > > users? There are valid arguments for both, eventually it comes down to
> > > > finding the right compromise.
> > > 
> > > In general it is better to get the newest firmware as other unrelated bugs
> > > may
> > > be present on older version or there is missing workaround for broken
> > > hardware
> > > (e.g enabling chicken bits). For instance, we have already decided to not
> > > support some version of the X-gene firmware (see commit 784c2d1 "xen/arm:
> > > Drop
> > > support of platform where GICH_LR_HW is not working correctly").
> > > 
> > > In this specific case, you assume that the GIC device tree node will
> > > always
> > > point to the beginning of the first 64K page. It might be possible in the
> > > future to have an updated firmware pointing to the last alias of the first
> > > page, so the second 4K page will follow directly.
> > 
> > Such firmware could have a version number we could check to disable
> > PLATFORM_QUIRK_GIC_64K_STRIDE.
> 
> Is there any way to retrieve the firmware version number from Xen?
> 
> Also, you mentioned later that it is possible to provide a different DTB with
> U-boot on m410. A user could decide to provide a modified one (e.g pointing to
> a different base address) and will not be possible to
> boot Xen because the quirk will screw up the base addresses.
> 
> I am wondering if you could turn on the quirk only when certain condition met
> (like a given GIC base address and the size is not 128K). This would save us
> some future trouble and that would address my concern. What do you think?

I think you are right. Concidentally the csize is 4K instead of 8K with
this DTB, we already have a workaround for that in gicv2_dt_init. I am
thinking of checking PLATFORM_QUIRK_GIC_64K_STRIDE only if the csize is
4K, which we know it is wrong. Good dtbs wouldn't be affected.

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-multivcpu  3 host-install(3) broken pass in 101905
 test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeat  fail pass in 101905
 test-armhf-armhf-libvirt-raw 14 guest-start/debian.repeat  fail pass in 101905

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 101905
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101905
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101905
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 101905
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101905
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101905
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 101905
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 101905
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101905

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail in 101905 never 
pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail in 101905 
never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 build-i386-rumprun7 xen-buildfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 build-amd64-rumprun   7 xen-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-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-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-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
 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-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 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-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 xen  4ccb2adb96042e0d1e334c01fe260b32e6001db9
baseline version:
 xen  4ccb2adb96042e0d1e334c01fe260b32e6001db9

Last test of basis   101920  2016-11-04 08:52:36 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17109 days0 attempts

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

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

[osstest service owner]

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

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  3ebe9a1a826e8d569bef6045777cc01a5699933d
baseline version:
 xen  bd4d31be073166fc69b131e6375b55033b83b1c0

Last test of basis   101928  2016-11-04 15:02:29 Z0 days
Testing same since   101929  2016-11-04 17:02:10 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 
  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=3ebe9a1a826e8d569bef6045777cc01a5699933d
+ . ./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 
3ebe9a1a826e8d569bef6045777cc01a5699933d
+ branch=xen-unstable-smoke
+ revision=3ebe9a1a826e8d569bef6045777cc01a5699933d
+ . ./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.7-testing
+ '[' x3ebe9a1a826e8d569bef6045777cc01a5699933d = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git

Re: [Xen-devel] Test Xen 4.8 RC5 instable 04.11.16

[Juergen Schinker]

- On 4 Nov, 2016, at 18:31, Dario Faggioli dario.faggi...@citrix.com wrote:

> On Fri, 2016-11-04 at 18:11 +, Juergen Schinker wrote:
>> - On 4 Nov, 2016, at 17:29, Dario Faggioli dario.faggioli@citrix.
>> com wrote:
>> > Also of interest (and in the meanwhile): have you done the same in
>> > your
>> > previous testing of previous rc-s and they did work?
>> > 
>> Yes and no it didn't work
>> 
> Ok.
> 
>> > In other word, would you say it is something in rc5 that is
>> > introducing
>> > this behavior, which was not happening of earlier versions?
>>  
>> it was introduced in rc4 and I consider rc3 stable.
>> 
> Ok. Well, we absolutely need serial output (either of the guest, of the
> host, or of both) to be able to tell.
> 
> Info about how to setup them here:
> 
> https://wiki.xenproject.org/wiki/Xen_Serial_Console
> https://wiki.xenproject.org/wiki/Xen_FAQ_Console
> 
>> the rtds sched has not been tested.
>> 
> I never asked about RTDS. I am interested in and did ask why you tested
> Credit2, how you tested it, and how you do find it, though, if you're
> keen on sharing that. :-D

I consider credit2 as the new default and tested it while using it with a lot 
of guests and different load; I also played

with a lot of vcpu-set and vcpu-pin etc.

credit2 is fantastic and all guests work well balanced and snappy...

J

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

Re: [Xen-devel] [SeaBIOS] Seabios build failure with gcc 6.2.0 in Debian Sid

[Kevin O'Connor]

On Fri, Nov 04, 2016 at 07:06:07PM +0100, Dario Faggioli wrote:
> Hi,
> 
> I'm reporting a build issue that I'm seeing when building Xen's
> userspace tools, when the build process clones and build Seabios, on
> Debian Sid, with gcc '6.2.0 20161019 (Debian 6.2.0-9)'.
> 
> The error looks like this (http://pastebin.com/99cubDZ3):
> 
> make -C seabios-dir all
> make[6]: Entering directory 
> '/home/SOURCES/xen/xen.git/tools/firmware/seabios-dir-remote'
>   Compile checking out/src/stacks.o
> src/stacks.c: Assembler messages:
> src/stacks.c:567: Error: found `(', expected: `)'
> src/stacks.c:567: Error: junk `(%ebp))' after expression
> src/stacks.c:568: Warning: indirect call without `*'
> Makefile:133: recipe for target 'out/src/stacks.o' failed
> make[6]: *** [out/src/stacks.o] Error 1
> make[6]: Leaving directory 
> '/home/SOURCES/xen/xen.git/tools/firmware/seabios-dir-remote'
> /home/SOURCES/xen/xen.git/tools/firmware/../../tools/Rules.mk:218: recipe for 
> target 'subdir-all-seabios-dir' failed
> 
> Seabios folks may be aware of this already, as it looks very similar to
> this:
> https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1463516.html
> 
> And even more to this:
> https://lists.debian.org/debian-gcc/2016/10/msg00147.html
> 
> A colleague of mine (Cc-ed) said in chat that gcc 6.2.1 (don't know on
> what distro) seems to build all fine.

The SeaBIOS build was updated to work around this with commit
99e3316d59.  What version of SeaBIOS are you attempting to build?

-Kevin

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

Re: [Xen-devel] Test Xen 4.8 RC5 instable 04.11.16

[Dario Faggioli]

On Fri, 2016-11-04 at 18:11 +, Juergen Schinker wrote:
> - On 4 Nov, 2016, at 17:29, Dario Faggioli dario.faggioli@citrix.
> com wrote:
> > Also of interest (and in the meanwhile): have you done the same in
> > your
> > previous testing of previous rc-s and they did work?
> > 
> Yes and no it didn't work
> 
Ok.

> > In other word, would you say it is something in rc5 that is
> > introducing
> > this behavior, which was not happening of earlier versions?
>  
> it was introduced in rc4 and I consider rc3 stable.
> 
Ok. Well, we absolutely need serial output (either of the guest, of the
host, or of both) to be able to tell.

Info about how to setup them here:

https://wiki.xenproject.org/wiki/Xen_Serial_Console
https://wiki.xenproject.org/wiki/Xen_FAQ_Console

> the rtds sched has not been tested.
> 
I never asked about RTDS. I am interested in and did ask why you tested
Credit2, how you tested it, and how you do find it, though, if you're
keen on sharing that. :-D

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

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

Re: [Xen-devel] Test Xen 4.8 RC5 instable 04.11.16

[Juergen Schinker]

- On 4 Nov, 2016, at 17:29, Dario Faggioli dario.faggi...@citrix.com wrote:

> Also of interest (and in the meanwhile): have you done the same in your
> previous testing of previous rc-s and they did work?
> 
Yes and no it didn't work

> In other word, would you say it is something in rc5 that is introducing
> this behavior, which was not happening of earlier versions?
 
it was introduced in rc4 and I consider rc3 stable.

the rtds sched has not been tested.

J

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

[Xen-devel] Seabios build failure with gcc 6.2.0 in Debian Sid

[Dario Faggioli]

Hi,

I'm reporting a build issue that I'm seeing when building Xen's
userspace tools, when the build process clones and build Seabios, on
Debian Sid, with gcc '6.2.0 20161019 (Debian 6.2.0-9)'.

The error looks like this (http://pastebin.com/99cubDZ3):

make -C seabios-dir all
make[6]: Entering directory 
'/home/SOURCES/xen/xen.git/tools/firmware/seabios-dir-remote'
  Compile checking out/src/stacks.o
src/stacks.c: Assembler messages:
src/stacks.c:567: Error: found `(', expected: `)'
src/stacks.c:567: Error: junk `(%ebp))' after expression
src/stacks.c:568: Warning: indirect call without `*'
Makefile:133: recipe for target 'out/src/stacks.o' failed
make[6]: *** [out/src/stacks.o] Error 1
make[6]: Leaving directory 
'/home/SOURCES/xen/xen.git/tools/firmware/seabios-dir-remote'
/home/SOURCES/xen/xen.git/tools/firmware/../../tools/Rules.mk:218: recipe for 
target 'subdir-all-seabios-dir' failed

Seabios folks may be aware of this already, as it looks very similar to
this:
https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1463516.html

And even more to this:
https://lists.debian.org/debian-gcc/2016/10/msg00147.html

A colleague of mine (Cc-ed) said in chat that gcc 6.2.1 (don't know on
what distro) seems to build all fine.

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

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

[Xen-devel] [xen-4.7-testing test] 101925: regressions - FAIL

[osstest service owner]

flight 101925 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101925/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   5 xen-buildfail REGR. vs. 101683
 build-i3865 xen-buildfail REGR. vs. 101683
 build-i386-xsm5 xen-buildfail REGR. vs. 101683
 build-amd64   5 xen-buildfail REGR. vs. 101683

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 101683
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 101683
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 101683
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 101683

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-xtf-amd64-amd64-11 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 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-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 build-i386-rumprun1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   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
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-21 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 build-amd64-rumprun   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-41 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-31 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-xtf-amd64-amd64-51 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 

[Xen-devel] Fwd: Re: Error migrating VM to secondary host using COLO replication

[Sadi]

-- Forwarded message --
From: "Sadi" 
Date: Nov 3, 2016 20:34
Subject: Re: [Xen-devel] Error migrating VM to secondary host using COLO
replication
To: "Wen Congyang" 
Cc:

> Hi,

>
> Thanks for replying. Here is what i got from /var/log/syslog:
>
> Nov  3 20:04:07 colob-HP-Compaq-6005-Pro-MT-PC systemd[1]: Started LSB:
Start/stop xenstored and xenconsoled.
> Nov  3 20:04:10 colob-HP-Compaq-6005-Pro-MT-PC systemd-timesyncd[631]:
Timed out waiting for reply from 91.189.89.199:123 (ntp.ubuntu.com).
> Nov  3 20:04:20 colob-HP-Compaq-6005-Pro-MT-PC systemd-timesyncd[631]:
Timed out waiting for reply from 91.189.94.4:123 (ntp.ubuntu.com).
> Nov  3 20:04:49 colob-HP-Compaq-6005-Pro-MT-PC systemd[1]:
session-3.scope: Cannot determine UID from slice user-0.slice
> Nov  3 20:04:49 colob-HP-Compaq-6005-Pro-MT-PC systemd[1]: Started
Session 3 of user root.
> Nov  3 20:04:54 colob-HP-Compaq-6005-Pro-MT-PC NetworkManager[924]:
  (vif2.0-emu): new Tun device (carrier: OFF, driver: 'tun', ifindex:
7)
> Nov  3 20:04:54 colob-HP-Compaq-6005-Pro-MT-PC systemd-udevd[2063]: Could
not generate persistent MAC address for vif2.0-emu: No such file or
directory
> Nov  3 20:04:54 colob-HP-Compaq-6005-Pro-MT-PC NetworkManager[924]:
  devices added (path: /sys/devices/virtual/net/vif2.0-emu, iface:
vif2.0-emu)
> Nov  3 20:04:54 colob-HP-Compaq-6005-Pro-MT-PC NetworkManager[924]:
  device added (path: /sys/devices/virtual/net/vif2.0-emu, iface:
vif2.0-emu): no ifupdown configuration found.
> Nov  3 20:04:54 colob-HP-Compaq-6005-Pro-MT-PC NetworkManager[924]:
  (vif2.0): failed to find device 8 'vif2.0' with udev
> Nov  3 20:04:54 colob-HP-Compaq-6005-Pro-MT-PC NetworkManager[924]:
  (vif2.0): new Ethernet device (carrier: OFF, driver: 'vif',
ifindex: 8)
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC NetworkManager[924]:
  devices added (path: /sys/devices/vif-2-0/net/vif2.0, iface: vif2.0)
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC NetworkManager[924]:
  device added (path: /sys/devices/vif-2-0/net/vif2.0, iface:
vif2.0): no ifupdown configuration found.
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC NetworkManager[924]:
  (vif2.0): device state change: unmanaged -> unavailable (reason
'managed') [10 20 2]
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC kernel: [  464.363596]
IPv6: ADDRCONF(NETDEV_UP): vif2.0: link is not ready
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC kernel: [  464.363696]
IPv6: ADDRCONF(NETDEV_UP): vif2.0: link is not ready
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC root:
/etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/2/0
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC NetworkManager[924]:
  (br0): bridge port vif2.0 was attached
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC kernel: [  464.463896]
device vif2.0 entered promiscuous mode
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC NetworkManager[924]:
  (vif2.0): enslaved to br0
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC kernel: [  464.466360]
IPv6: ADDRCONF(NETDEV_UP): vif2.0: link is not ready
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC kernel: [  464.529006]
ip_tables: (C) 2000-2006 Netfilter Core Team
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC kernel: [  464.585769]
Bridge firewalling registered
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC root:
/etc/xen/scripts/vif-bridge: Successful vif-bridge online for vif2.0,
bridge br0.
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC root:
/etc/xen/scripts/vif-bridge: Writing backend/vif/2/0/hotplug-status
connected to xenstore.
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC root:
/etc/xen/scripts/vif-bridge: add type_if=tap XENBUS_PATH=backend/vif/2/0
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC NetworkManager[924]:
  (br0): bridge port vif2.0-emu was attached
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC NetworkManager[924]:
  (vif2.0-emu): enslaved to br0
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC NetworkManager[924]:
  (vif2.0-emu): link connected
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC kernel: [  464.693288]
device vif2.0-emu entered promiscuous mode
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC kernel: [  464.695493]
br0: port 3(vif2.0-emu) entered forwarding state
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC kernel: [  464.695500]
br0: port 3(vif2.0-emu) entered forwarding state
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC root:
/etc/xen/scripts/vif-bridge: Successful vif-bridge add for vif2.0-emu,
bridge br0.
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC root:
/etc/xen/scripts/colo-proxy-setup: setup XENBUS_PATH=
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC NetworkManager[924]:
  (br0): bridge port vif2.0-emu was detached
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC NetworkManager[924]:
  (vif2.0-emu): released from master br0
> Nov  3 20:04:55 colob-HP-Compaq-6005-Pro-MT-PC kernel: [  464.765881]
device vif2.0-emu left promiscuous mode

Re: [Xen-devel] Test Xen 4.8 RC5 instable 04.11.16

[Dario Faggioli]

On Fri, 2016-11-04 at 11:18 +, Wei Liu wrote:
> On Fri, Nov 04, 2016 at 11:13:29AM +, Juergen Schinker wrote:
> > 
> > * Functionality tested:
> > xl 
> > creating booting 
> > pygrub
> > credit2
> > 
> > * Comments:
> > 
> >  I compiled the latest vanilla kernel for gpu-passthrough with
> > single gpu -
> > 
> > rc5 runs ca. 1h then freeze - which log should i check for ?
> >  
> 
> If the guest freezes, you can have a look at guest serial output,
> Dom0
> dmesg and xen dmesg (xl dmesg).
> 
> If the host freezes, you will need to setup a serial console and uses
> another machine to capture the log as it goes.
> 
Also of interest (and in the meanwhile): have you done the same in your
previous testing of previous rc-s and they did work?

In other word, would you say it is something in rc5 that is introducing
this behavior, which was not happening of earlier versions?

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

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

Re: [Xen-devel] [PATCH v3.1 08/15] x86/vtd: fix mapping of RMRR regions

[Roger Pau Monne]

On Fri, Nov 04, 2016 at 11:08:21AM -0600, Jan Beulich wrote:
> >>> On 04.11.16 at 17:19,  wrote:
> > On Fri, Nov 04, 2016 at 10:13:08AM -0600, Jan Beulich wrote:
> >> >>> On 04.11.16 at 16:33,  wrote:
> >> > --- a/xen/include/asm-x86/p2m.h
> >> > +++ b/xen/include/asm-x86/p2m.h
> >> > @@ -834,6 +834,7 @@ static inline unsigned int 
> >> > p2m_get_iommu_flags(p2m_type_t p2mt)
> >> >  case p2m_grant_map_rw:
> >> >  case p2m_ram_logdirty:
> >> >  case p2m_map_foreign:
> >> > +case p2m_mmio_direct:
> >> >  flags =  IOMMUF_readable | IOMMUF_writable;
> >> >  break;
> >> >  case p2m_ram_ro:
> >> 
> >> Generally this may be the route to go. But if we want to do so, we
> >> need to throughly understand why this type wasn't included here
> >> before (and I don't know myself).
> > 
> > It was me that introduced p2m_get_iommu_flags, and I just didn't think it 
> > would be useful at that point, that's why it wasn't included.
> 
> But there must have been logic to set the permissions before that?

Previous to that only p2m_ram_rw would get IOMMU mappings. I've tracked this 
back to ff635e12, but there's no mention there about why only p2m_ram_rw 
would get IOMMU mappings.

Considering that on hw with shared page-tables this is already available, I 
don't see an issue with also doing it for the non-shared pt case.

Roger.

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

Re: [Xen-devel] [PATCH v3.1 08/15] x86/vtd: fix mapping of RMRR regions

[Jan Beulich]

>>> On 04.11.16 at 17:19,  wrote:
> On Fri, Nov 04, 2016 at 10:13:08AM -0600, Jan Beulich wrote:
>> >>> On 04.11.16 at 16:33,  wrote:
>> > --- a/xen/include/asm-x86/p2m.h
>> > +++ b/xen/include/asm-x86/p2m.h
>> > @@ -834,6 +834,7 @@ static inline unsigned int 
>> > p2m_get_iommu_flags(p2m_type_t p2mt)
>> >  case p2m_grant_map_rw:
>> >  case p2m_ram_logdirty:
>> >  case p2m_map_foreign:
>> > +case p2m_mmio_direct:
>> >  flags =  IOMMUF_readable | IOMMUF_writable;
>> >  break;
>> >  case p2m_ram_ro:
>> 
>> Generally this may be the route to go. But if we want to do so, we
>> need to throughly understand why this type wasn't included here
>> before (and I don't know myself).
> 
> It was me that introduced p2m_get_iommu_flags, and I just didn't think it 
> would be useful at that point, that's why it wasn't included.

But there must have been logic to set the permissions before that?

Jan


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 12a37b2ae19b1edabf390c0744ae0af9bb9d2b9a
baseline version:
 ovmf 669b6cc60bf610bbee32e79ed165ca604764c169

Last test of basis   101919  2016-11-04 08:15:24 Z0 days
Testing same since   101922  2016-11-04 10:17:15 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Laszlo Ersek 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=12a37b2ae19b1edabf390c0744ae0af9bb9d2b9a
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
12a37b2ae19b1edabf390c0744ae0af9bb9d2b9a
+ branch=ovmf
+ revision=12a37b2ae19b1edabf390c0744ae0af9bb9d2b9a
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x12a37b2ae19b1edabf390c0744ae0af9bb9d2b9a = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : 

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

[osstest service owner]

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

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  bd4d31be073166fc69b131e6375b55033b83b1c0
baseline version:
 xen  4ccb2adb96042e0d1e334c01fe260b32e6001db9

Last test of basis   101892  2016-11-03 18:02:24 Z0 days
Testing same since   101928  2016-11-04 15:02:29 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Jan Beulich 
  Luwei Kang 
  Roger Pau Monne 
  Roger Pau Monné 
  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=bd4d31be073166fc69b131e6375b55033b83b1c0
+ . ./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 
bd4d31be073166fc69b131e6375b55033b83b1c0
+ branch=xen-unstable-smoke
+ revision=bd4d31be073166fc69b131e6375b55033b83b1c0
+ . ./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.7-testing
+ '[' xbd4d31be073166fc69b131e6375b55033b83b1c0 = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : 

Re: [Xen-devel] [PATCH v3.1 08/15] x86/vtd: fix mapping of RMRR regions

[Jan Beulich]

>>> On 04.11.16 at 16:33,  wrote:
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -834,6 +834,7 @@ static inline unsigned int p2m_get_iommu_flags(p2m_type_t 
> p2mt)
>  case p2m_grant_map_rw:
>  case p2m_ram_logdirty:
>  case p2m_map_foreign:
> +case p2m_mmio_direct:
>  flags =  IOMMUF_readable | IOMMUF_writable;
>  break;
>  case p2m_ram_ro:

Generally this may be the route to go. But if we want to do so, we
need to throughly understand why this type wasn't included here
before (and I don't know myself).

Jan


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

Re: [Xen-devel] [PATCH v3.1 08/15] x86/vtd: fix mapping of RMRR regions

[Roger Pau Monne]

On Fri, Nov 04, 2016 at 10:13:08AM -0600, Jan Beulich wrote:
> >>> On 04.11.16 at 16:33,  wrote:
> > --- a/xen/include/asm-x86/p2m.h
> > +++ b/xen/include/asm-x86/p2m.h
> > @@ -834,6 +834,7 @@ static inline unsigned int 
> > p2m_get_iommu_flags(p2m_type_t p2mt)
> >  case p2m_grant_map_rw:
> >  case p2m_ram_logdirty:
> >  case p2m_map_foreign:
> > +case p2m_mmio_direct:
> >  flags =  IOMMUF_readable | IOMMUF_writable;
> >  break;
> >  case p2m_ram_ro:
> 
> Generally this may be the route to go. But if we want to do so, we
> need to throughly understand why this type wasn't included here
> before (and I don't know myself).

It was me that introduced p2m_get_iommu_flags, and I just didn't think it 
would be useful at that point, that's why it wasn't included.

The patch that introduced p2m_get_iommu_flags was focused on fixing DMA'ing 
from grant-pages on HVM guests with passed-through hardware, this was needed 
for driver domains and later on by classic PVH Dom0

Roger.

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

[Xen-devel] [ovmf baseline-only test] 67994: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67994 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67994/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 5f609eb837f235e28464285a2fb768e39cd51b56
baseline version:
 ovmf e9d0933d45e51027836f570427141fd2e3a7dfbd

Last test of basis67987  2016-11-03 13:47:59 Z1 days
Testing same since67994  2016-11-04 08:18:04 Z0 days1 attempts


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

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



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.


commit 5f609eb837f235e28464285a2fb768e39cd51b56
Author: Marvin Häuser 
Date:   Thu Nov 3 21:40:27 2016 +

OvmfPkg/ResetVector: Remove the unused ASM ResetVector.

Remove the ResetVector.asm file as it is no longer referenced since
the switch to ResetVector.nasmb.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
Reviewed-by: Jordan Justen 
Reviewed-by: Laszlo Ersek 

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

Re: [Xen-devel] [PATCH] xsm: add missing permissions discovered in testing

[Andrew Cooper]

On 04/11/16 15:35, Daniel De Graaf wrote:
> Add two missing allow rules:
>
> 1. Device model domain construction uses getvcpucontext, discovered by
> Andrew Cooper in an (apparently) unrelated bisection.

Merely observation of the logs while chasing an unrelated issue.

~Andrew

>
> 2. When a domain is destroyed with a device passthrough active, the
> calls to remove_{irq,ioport,iomem} can be made by the hypervisor itself
> (which results in an XSM check with the source xen_t).  It does not make
> sense to deny these permissions; no domain should be using xen_t, and
> forbidding the hypervisor from performing cleanup is not useful.
>
> Signed-off-by: Daniel De Graaf 
> Cc: Andrew Cooper 
> ---
>  tools/flask/policy/modules/xen.if | 2 +-
>  tools/flask/policy/modules/xen.te | 4 
>  2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/tools/flask/policy/modules/xen.if 
> b/tools/flask/policy/modules/xen.if
> index d83f031..eb646f5 100644
> --- a/tools/flask/policy/modules/xen.if
> +++ b/tools/flask/policy/modules/xen.if
> @@ -49,7 +49,7 @@ define(`create_domain_common', `
>   allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
>   getdomaininfo hypercall setvcpucontext getscheduler
>   getvcpuinfo getaddrsize getaffinity setaffinity
> - settime setdomainhandle };
> + settime setdomainhandle getvcpucontext };
>   allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
>   set_max_evtchn set_vnumainfo get_vnumainfo cacheflush
>   psr_cmt_op psr_cat_op soft_reset };
> diff --git a/tools/flask/policy/modules/xen.te 
> b/tools/flask/policy/modules/xen.te
> index b52edc2..0cff2df 100644
> --- a/tools/flask/policy/modules/xen.te
> +++ b/tools/flask/policy/modules/xen.te
> @@ -49,6 +49,10 @@ type ioport_t, resource_type;
>  type iomem_t, resource_type;
>  type device_t, resource_type;
>  
> +# Domain destruction can result in some access checks for actions performed 
> by
> +# the hypervisor.  These should always be allowed.
> +allow xen_t resource_type : resource { remove_irq remove_ioport remove_iomem 
> };
> +
>  
> 
>  #
>  # Policy constraints


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

Re: [Xen-devel] [RFC PATCH 13/24] ARM: vITS: handle CLEAR command

[Julien Grall]

Hi Andre,

On 28/09/16 19:24, Andre Przywara wrote:

This introduces the ITS command handler for the CLEAR command, which
clears the pending state of an LPI.
This removes a not-yet injected, but already queued IRQ from a VCPU.

In addition this patch introduces the lookup function which translates
a given DeviceID/EventID pair into a pointer to our vITTE structure.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-its.c | 115 
 1 file changed, 115 insertions(+)

diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
index 875b992..99d9e9c 100644
--- a/xen/arch/arm/vgic-its.c
+++ b/xen/arch/arm/vgic-its.c
@@ -61,6 +61,73 @@ struct vits_itte
 uint64_t collection:16;
 };

+#define UNMAPPED_COLLECTION  ((uint16_t)~0)
+
+/* Must be called with the ITS lock held. */


This comment is a call to have an ASSERT in the function.


+static struct vcpu *get_vcpu_from_collection(struct virt_its *its, int collid)


Please use unsigned int.


+{
+uint16_t vcpu_id;
+
+if ( collid >= its->max_collections )
+return NULL;
+
+vcpu_id = its->coll_table[collid];
+if ( vcpu_id == UNMAPPED_COLLECTION || vcpu_id >= its->d->max_vcpus )
+return NULL;
+
+return its->d->vcpu[vcpu_id];
+}
+
+#define DEV_TABLE_ITT_ADDR(x) ((x) & GENMASK(51, 8))
+#define DEV_TABLE_ITT_SIZE(x) (BIT(((x) & GENMASK(7, 0)) + 1))


The layout of dev_table[...] really needs to be explained. It took me 
quite a while to understand how it works. For instance why you skip the 
first 8 bits for the address...



+#define DEV_TABLE_ENTRY(addr, bits) \
+(((addr) & GENMASK(51, 8)) | (((bits) - 1) & GENMASK(7, 0)))
+
+static paddr_t get_itte_address(struct virt_its *its,
+uint32_t devid, uint32_t evid)
+{
+paddr_t addr;
+
+if ( devid >= its->max_devices )
+return ~0;


Please use INVALID_PADDR here.


+
+if ( evid >= DEV_TABLE_ITT_SIZE(its->dev_table[devid]) )
+return ~0;


Ditto.


+
+addr = DEV_TABLE_ITT_ADDR(its->dev_table[devid]);
+
+return addr + evid * sizeof(struct vits_itte);
+}
+
+/* Looks up a given deviceID/eventID pair on an ITS and returns a pointer to


Coding style:

/*
 * Foo


+ * the corresponding ITTE. This maps the respective guest page into Xen.
+ * Once finished with handling the ITTE, call put_devid_evid() to unmap
+ * the page again.
+ * Must be called with the ITS lock held.


This is a call for an ASSERT in the code.


+ */
+static struct vits_itte *get_devid_evid(struct virt_its *its,
+uint32_t devid, uint32_t evid)


The naming of the function is confusing. It doesn't look up a device 
ID/event ID but an IIT. So I would rename it to find_itte.



+{
+paddr_t addr = get_itte_address(its, devid, evid);
+struct vits_itte *itte;
+
+if (addr == ~0)


Coding style: if ( ... )

And return INVALID_PADDR.


+return NULL;
+
+/* TODO: check locking for map_guest_pages() */
+itte = map_guest_pages(its->d, addr & PAGE_MASK, 1);
+if ( !itte )
+return NULL;
+
+return itte + (addr & ~PAGE_MASK) / sizeof(struct vits_itte);
+}
+
+/* Must be called with the ITS lock held. */
+static void put_devid_evid(struct virt_its *its, struct vits_itte *itte)
+{
+unmap_guest_pages(itte, 1);
+}
+
 /**
  * Functions that handle ITS commands *
  **/
@@ -80,6 +147,51 @@ static uint64_t its_cmd_mask_field(uint64_t *its_cmd,
 #define its_cmd_get_target_addr(cmd)its_cmd_mask_field(cmd, 2, 16, 32)
 #define its_cmd_get_validbit(cmd)   its_cmd_mask_field(cmd, 2, 63,  1)

+static int its_handle_clear(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+struct pending_irq *pirq;
+struct vits_itte *itte;
+struct vcpu *vcpu;
+uint32_t vlpi;
+
+spin_lock(>its_lock);
+
+itte = get_devid_evid(its, devid, eventid);
+if ( !itte )
+{
+spin_unlock(>its_lock);
+return -1;
+}
+
+vcpu = get_vcpu_from_collection(its, itte->collection);
+if ( !vcpu )
+{
+spin_unlock(>its_lock);
+return -1;
+}
+
+vlpi = itte->vlpi;
+
+put_devid_evid(its, itte);
+spin_unlock(>its_lock);
+
+/* Remove a pending, but not yet injected guest IRQ. */
+pirq = lpi_to_pending(vcpu, vlpi, false);
+if ( pirq )
+{
+clear_bit(GIC_IRQ_GUEST_QUEUED, >status);
+gic_remove_from_queues(vcpu, vlpi);
+
+/* Mark this pending IRQ struct as availabe again. */


NIT: s/availabe/available/


+if ( !test_bit(GIC_IRQ_GUEST_VISIBLE, >status) )
+pirq->irq = 0;


This code should be in a separate helper. It will be helpful to make the 
structure available again easily without open coding it.



+}
+
+return 

Re: [Xen-devel] [RFC PATCH 08/24] ARM: GICv3: introduce separate pending_irq structs for LPIs

[Julien Grall]

Hi Andre,

On 28/09/16 19:24, Andre Przywara wrote:

+/*
+ * Holding struct pending_irq's for each possible virtual LPI in each domain
+ * requires too much Xen memory, also a malicious guest could potentially
+ * spam Xen with LPI map requests. We cannot cover those with (guest allocated)
+ * ITS memory, so we use a dynamic scheme of allocating struct pending_irq's
+ * on demand.
+ */
+struct pending_irq *lpi_to_pending(struct vcpu *v, unsigned int lpi,
+   bool allocate)
+{
+struct lpi_pending_irq *lpi_irq, *empty = NULL;
+
+/* TODO: locking! */
+list_for_each_entry(lpi_irq, >arch.vgic.pending_lpi_list, entry)
+{
+if ( lpi_irq->pirq.irq == lpi )
+return _irq->pirq;
+
+if ( lpi_irq->pirq.irq == 0 && !empty )
+empty = lpi_irq;
+}
+
+if ( !allocate )
+return NULL;
+
+if ( !empty )
+{
+empty = xzalloc(struct lpi_pending_irq);


xzalloc can return NULL if we fail to allocate memory.


+vgic_init_pending_irq(>pirq, lpi);
+list_add_tail(>entry, >arch.vgic.pending_lpi_list);
+} else
+{
+empty->pirq.status = 0;
+empty->pirq.irq = lpi;
+}
+
+return >pirq;
+}
+


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3.1 08/15] x86/vtd: fix mapping of RMRR regions

[Roger Pau Monne]

On Fri, Nov 04, 2016 at 07:16:08AM -0600, Jan Beulich wrote:
> >>> On 04.11.16 at 14:03,  wrote:
> > On Fri, Nov 04, 2016 at 06:53:09AM -0600, Jan Beulich wrote:
> >> >>> On 04.11.16 at 13:25,  wrote:
> >> > On Fri, Nov 04, 2016 at 04:34:58AM -0600, Jan Beulich wrote:
> >> >> >>> On 04.11.16 at 10:45,  wrote:
> >> >> > case p2m_invalid:
> >> >> > case p2m_mmio_dm:
> >> >> > ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K,
> >> >> > p2m_mmio_direct, p2ma);
> >> >> > if ( ret )
> >> >> > break;
> >> >> > if ( !iommu_use_hap_pt(d) )
> >> >> > ret = iommu_map_page(d, gfn, gfn, 
> > IOMMUF_readable|IOMMUF_writable);
> >> >> > break;
> >> >> > case p2m_mmio_direct:
> >> >> > if ( a != p2ma || gfn != mfn )
> >> >> > {
> >> >> > printk(XENLOG_G_WARNING
> >> >> >"Cannot setup identity map d%d:%lx, already mapped 
> >> >> > with "
> >> >> >"different access type or mfn\n", d->domain_id, gfn);
> >> >> > ret = (flag & XEN_DOMCTL_DEV_RDM_RELAXED) ? 0 : -EBUSY;
> >> >> > break;
> >> >> > }
> >> >> > if ( !iommu_use_hap_pt(d) )
> >> >> > ret = iommu_map_page(d, gfn, gfn, 
> > IOMMUF_readable|IOMMUF_writable);
> >> >> 
> >> >> Well, since according to what I've said above this code should
> >> >> really not be here, I think the code structuring question is moot
> >> >> now. The conditional call to iommu_map_page() really just needs
> >> >> adding alongside the p2m_set_entry() call.
> >> > 
> >> > OK, so if the gfn is already mapped into the p2m we don't care whether 
> >> > it 
> >> > has a valid IOMMU mapping or not?
> >> 
> >> We do care, but it is the responsibility of whoever established the
> >> first mapping to make sure it's present in both P2M and IOMMU.
> >> IOW if the GFN is already mapped, we should be able to imply that
> >> it's mapped in both places.
> > 
> > But how is the first caller that established the mapping supposed to know 
> > if 
> > it needs an IOMMU entry or not? (p2m_mmio_direct types don't get an IOMMU 
> > mapping at all)
> 
> And it's that fact stated in parentheses which I'd like to question.
> I don't see what's wrong with e.g. DMAing right into / out of a
> video frame buffer.

Right, so what about the following patch. It would fix my issues, and also 
remove the PVH hack in set_identity_p2m_entry:

---
x86/iommu: add IOMMU entries for p2m_mmio_direct pages

There's nothing wrong with allowing the domain to perform DMA transfers to 
MMIO areas that it already can access from the CPU, and this allows us to 
remove the hack in set_identity_p2m_entry for PVH Dom0.

Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/mm/p2m.c |9 -
 xen/include/asm-x86/p2m.h |1 +
 2 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 6a45185..7e33ab6 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1053,16 +1053,7 @@ int set_identity_p2m_entry(struct domain *d, unsigned 
long gfn,
 ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K,
 p2m_mmio_direct, p2ma);
 else if ( mfn_x(mfn) == gfn && p2mt == p2m_mmio_direct && a == p2ma )
-{
 ret = 0;
-/*
- * PVH fixme: during Dom0 PVH construction, p2m entries are being set
- * but iomem regions are not mapped with IOMMU. This makes sure that
- * RMRRs are correctly mapped with IOMMU.
- */
-if ( is_hardware_domain(d) && !iommu_use_hap_pt(d) )
-ret = iommu_map_page(d, gfn, gfn, IOMMUF_readable|IOMMUF_writable);
-}
 else
 {
 if ( flag & XEN_DOMCTL_DEV_RDM_RELAXED )
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 7035860..b562da3 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -834,6 +834,7 @@ static inline unsigned int 
p2m_get_iommu_flags(p2m_type_t p2mt)
 case p2m_grant_map_rw:
 case p2m_ram_logdirty:
 case p2m_map_foreign:
+case p2m_mmio_direct:
 flags =  IOMMUF_readable | IOMMUF_writable;
 break;
 case p2m_ram_ro:


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

[Xen-devel] [PATCH] xsm: add missing permissions discovered in testing

[Daniel De Graaf]

Add two missing allow rules:

1. Device model domain construction uses getvcpucontext, discovered by
Andrew Cooper in an (apparently) unrelated bisection.

2. When a domain is destroyed with a device passthrough active, the
calls to remove_{irq,ioport,iomem} can be made by the hypervisor itself
(which results in an XSM check with the source xen_t).  It does not make
sense to deny these permissions; no domain should be using xen_t, and
forbidding the hypervisor from performing cleanup is not useful.

Signed-off-by: Daniel De Graaf 
Cc: Andrew Cooper 
---
 tools/flask/policy/modules/xen.if | 2 +-
 tools/flask/policy/modules/xen.te | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/flask/policy/modules/xen.if 
b/tools/flask/policy/modules/xen.if
index d83f031..eb646f5 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -49,7 +49,7 @@ define(`create_domain_common', `
allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
getdomaininfo hypercall setvcpucontext getscheduler
getvcpuinfo getaddrsize getaffinity setaffinity
-   settime setdomainhandle };
+   settime setdomainhandle getvcpucontext };
allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
set_max_evtchn set_vnumainfo get_vnumainfo cacheflush
psr_cmt_op psr_cat_op soft_reset };
diff --git a/tools/flask/policy/modules/xen.te 
b/tools/flask/policy/modules/xen.te
index b52edc2..0cff2df 100644
--- a/tools/flask/policy/modules/xen.te
+++ b/tools/flask/policy/modules/xen.te
@@ -49,6 +49,10 @@ type ioport_t, resource_type;
 type iomem_t, resource_type;
 type device_t, resource_type;
 
+# Domain destruction can result in some access checks for actions performed by
+# the hypervisor.  These should always be allowed.
+allow xen_t resource_type : resource { remove_irq remove_ioport remove_iomem };
+
 

 #
 # Policy constraints
-- 
2.7.4


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

Re: [Xen-devel] [PATCH] stubdom: simplify and fix Makefile

[Wei Liu]

On Fri, Nov 04, 2016 at 03:44:12PM +0100, Juergen Gross wrote:
> On 04/11/16 15:31, Wei Liu wrote:
> > On Fri, Nov 04, 2016 at 03:29:01PM +0100, Juergen Gross wrote:
> >> On 04/11/16 15:20, Wei Liu wrote:
> >>> On Fri, Nov 04, 2016 at 10:53:29AM +0100, Juergen Gross wrote:
>  The stubdom Makefile is setting up links for various libraries. This
>  is done only once when qemu links are created and each library's links
>  are updated/created only if the link for the Makefile of the library
>  isn't already existing. In case a source is added to one library after
>  doing the first make of stubdom the new source won't be linked by a
>  new call of make.
> 
> >>>
> >>> I think this is a bug, hence I intend to take this patch in 4.8.
> >>
> >> I wouldn't mind. OTOH this bug will surface only when modifying the
> >> code, so it isn't a severe one. Normally you'll notice a build error
> >> which will be gone after cleaning the tree.
> >>
> > 
> > Alright. If you don't feel strongly about this, I'm fine with putting it
> > to my -next branch, too.
> 
> Fine with me.
> 
> > 
> >>
> >> Juergen
> >>
> >>>
>  Instead of testing the existence of the Makefile link use a make
>  dependency which will catch changes of the linked Makefile, too.
> 
>  At the same time don't repeat the same link pattern 7 times but use a
>  make macro to do the linking.
> 
>  Signed-off-by: Juergen Gross 
>  ---
>   stubdom/Makefile | 77 
>  ++--
>   1 file changed, 35 insertions(+), 42 deletions(-)
> 
>  diff --git a/stubdom/Makefile b/stubdom/Makefile
>  index 2921f30..9b30b58 100644
>  --- a/stubdom/Makefile
>  +++ b/stubdom/Makefile
>  @@ -305,7 +305,41 @@ ioemu/linkfarm.stamp:
>   touch ioemu/linkfarm.stamp
>   endif
>   
>  -mk-headers-$(XEN_TARGET_ARCH): $(IOEMU_LINKFARM_TARGET)
>  +define do_links
>  +  touch $@
> >>>
> >>> This should be moved to the last line of this macro.
> >>>
> >>> If you agree on this, I can fix it up while committing.
> >>>
> > 
> > What about this comment?
> 
> Aah, sorry. Didn't scroll down.
> 
> I agree.
> 

OK. Fixed it up and queued it for -next.

Wei.

> 
> Juergen
> 

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

Re: [Xen-devel] [PATCH] stubdom: simplify and fix Makefile

[Juergen Gross]

On 04/11/16 15:31, Wei Liu wrote:
> On Fri, Nov 04, 2016 at 03:29:01PM +0100, Juergen Gross wrote:
>> On 04/11/16 15:20, Wei Liu wrote:
>>> On Fri, Nov 04, 2016 at 10:53:29AM +0100, Juergen Gross wrote:
 The stubdom Makefile is setting up links for various libraries. This
 is done only once when qemu links are created and each library's links
 are updated/created only if the link for the Makefile of the library
 isn't already existing. In case a source is added to one library after
 doing the first make of stubdom the new source won't be linked by a
 new call of make.

>>>
>>> I think this is a bug, hence I intend to take this patch in 4.8.
>>
>> I wouldn't mind. OTOH this bug will surface only when modifying the
>> code, so it isn't a severe one. Normally you'll notice a build error
>> which will be gone after cleaning the tree.
>>
> 
> Alright. If you don't feel strongly about this, I'm fine with putting it
> to my -next branch, too.

Fine with me.

> 
>>
>> Juergen
>>
>>>
 Instead of testing the existence of the Makefile link use a make
 dependency which will catch changes of the linked Makefile, too.

 At the same time don't repeat the same link pattern 7 times but use a
 make macro to do the linking.

 Signed-off-by: Juergen Gross 
 ---
  stubdom/Makefile | 77 
 ++--
  1 file changed, 35 insertions(+), 42 deletions(-)

 diff --git a/stubdom/Makefile b/stubdom/Makefile
 index 2921f30..9b30b58 100644
 --- a/stubdom/Makefile
 +++ b/stubdom/Makefile
 @@ -305,7 +305,41 @@ ioemu/linkfarm.stamp:
touch ioemu/linkfarm.stamp
  endif
  
 -mk-headers-$(XEN_TARGET_ARCH): $(IOEMU_LINKFARM_TARGET)
 +define do_links
 +  touch $@
>>>
>>> This should be moved to the last line of this macro.
>>>
>>> If you agree on this, I can fix it up while committing.
>>>
> 
> What about this comment?

Aah, sorry. Didn't scroll down.

I agree.


Juergen


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

Re: [Xen-devel] [PATCH for-4.8 2/2] libxl: disallow enabling PoD and ALTP2M at the same time

[Ian Jackson]

Wei Liu writes ("[PATCH for-4.8 2/2] libxl: disallow enabling PoD and ALTP2M at 
the same time"):
> That combination would cause Xen to crash.
> 
> Note that although this is a security issue, is not XSA-worthy because
> ALTP2M is experimental.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH for-4.8 1/2] libxl: set ret in the check for nestedhvm and altp2m

[Ian Jackson]

Wei Liu writes ("[PATCH for-4.8 1/2] libxl: set ret in the check for nestedhvm 
and altp2m"):
> The error path expects ret to be set, otherwise an assertion is
> triggered.

Acked-by: Ian Jackson 

Ian.

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

[Xen-devel] [distros-debian-jessie test] 67993: tolerable FAIL

[Platform Team regression test user]

flight 67993 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67993/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-i386-jessie-netboot-pvgrub 10 guest-start  fail like 67954

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-jessie-netboot-pygrub 11 migrate-support-check fail 
never pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub 12 saverestore-support-check fail 
never pass

baseline version:
 flight   67954

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-jessie-netboot-pvgrub pass
 test-amd64-i386-i386-jessie-netboot-pvgrub   fail
 test-amd64-i386-amd64-jessie-netboot-pygrub  pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub pass
 test-amd64-amd64-i386-jessie-netboot-pygrub  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.


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

Re: [Xen-devel] [PATCH] stubdom: simplify and fix Makefile

[Wei Liu]

On Fri, Nov 04, 2016 at 03:29:01PM +0100, Juergen Gross wrote:
> On 04/11/16 15:20, Wei Liu wrote:
> > On Fri, Nov 04, 2016 at 10:53:29AM +0100, Juergen Gross wrote:
> >> The stubdom Makefile is setting up links for various libraries. This
> >> is done only once when qemu links are created and each library's links
> >> are updated/created only if the link for the Makefile of the library
> >> isn't already existing. In case a source is added to one library after
> >> doing the first make of stubdom the new source won't be linked by a
> >> new call of make.
> >>
> > 
> > I think this is a bug, hence I intend to take this patch in 4.8.
> 
> I wouldn't mind. OTOH this bug will surface only when modifying the
> code, so it isn't a severe one. Normally you'll notice a build error
> which will be gone after cleaning the tree.
> 

Alright. If you don't feel strongly about this, I'm fine with putting it
to my -next branch, too.

> 
> Juergen
> 
> > 
> >> Instead of testing the existence of the Makefile link use a make
> >> dependency which will catch changes of the linked Makefile, too.
> >>
> >> At the same time don't repeat the same link pattern 7 times but use a
> >> make macro to do the linking.
> >>
> >> Signed-off-by: Juergen Gross 
> >> ---
> >>  stubdom/Makefile | 77 
> >> ++--
> >>  1 file changed, 35 insertions(+), 42 deletions(-)
> >>
> >> diff --git a/stubdom/Makefile b/stubdom/Makefile
> >> index 2921f30..9b30b58 100644
> >> --- a/stubdom/Makefile
> >> +++ b/stubdom/Makefile
> >> @@ -305,7 +305,41 @@ ioemu/linkfarm.stamp:
> >>touch ioemu/linkfarm.stamp
> >>  endif
> >>  
> >> -mk-headers-$(XEN_TARGET_ARCH): $(IOEMU_LINKFARM_TARGET)
> >> +define do_links
> >> +  touch $@
> > 
> > This should be moved to the last line of this macro.
> > 
> > If you agree on this, I can fix it up while committing.
> > 

What about this comment?

Wei.

> >> +  mkdir -p $(dir $@)include
> >> +  cd $(dir $@); \
> >> +  ln -sf $(dir $<)include/*.h include/; \
> >> +  ln -sf $(dir $<)*.[ch] .; \
> >> +  ln -sf $(dir $<)Makefile .
> >> +endef
> >> +
> > 
> > Wei.
> > 
> 

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

Re: [Xen-devel] [PATCH] stubdom: simplify and fix Makefile

[Juergen Gross]

On 04/11/16 15:20, Wei Liu wrote:
> On Fri, Nov 04, 2016 at 10:53:29AM +0100, Juergen Gross wrote:
>> The stubdom Makefile is setting up links for various libraries. This
>> is done only once when qemu links are created and each library's links
>> are updated/created only if the link for the Makefile of the library
>> isn't already existing. In case a source is added to one library after
>> doing the first make of stubdom the new source won't be linked by a
>> new call of make.
>>
> 
> I think this is a bug, hence I intend to take this patch in 4.8.

I wouldn't mind. OTOH this bug will surface only when modifying the
code, so it isn't a severe one. Normally you'll notice a build error
which will be gone after cleaning the tree.


Juergen

> 
>> Instead of testing the existence of the Makefile link use a make
>> dependency which will catch changes of the linked Makefile, too.
>>
>> At the same time don't repeat the same link pattern 7 times but use a
>> make macro to do the linking.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>>  stubdom/Makefile | 77 
>> ++--
>>  1 file changed, 35 insertions(+), 42 deletions(-)
>>
>> diff --git a/stubdom/Makefile b/stubdom/Makefile
>> index 2921f30..9b30b58 100644
>> --- a/stubdom/Makefile
>> +++ b/stubdom/Makefile
>> @@ -305,7 +305,41 @@ ioemu/linkfarm.stamp:
>>  touch ioemu/linkfarm.stamp
>>  endif
>>  
>> -mk-headers-$(XEN_TARGET_ARCH): $(IOEMU_LINKFARM_TARGET)
>> +define do_links
>> +  touch $@
> 
> This should be moved to the last line of this macro.
> 
> If you agree on this, I can fix it up while committing.
> 
>> +  mkdir -p $(dir $@)include
>> +  cd $(dir $@); \
>> +  ln -sf $(dir $<)include/*.h include/; \
>> +  ln -sf $(dir $<)*.[ch] .; \
>> +  ln -sf $(dir $<)Makefile .
>> +endef
>> +
> 
> Wei.
> 


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

Re: [Xen-devel] [PATCH for-4.8] git: Add metadata to the result of `git archive`

[Wei Liu]

On Fri, Nov 04, 2016 at 10:54:25AM +, Wei Liu wrote:
> On Thu, Nov 03, 2016 at 05:57:57PM +, Andrew Cooper wrote:
> > When building Xen from a source tarball, commit information is usually lost,
> > especially if the tarball was generated from a tag.
> > 
> > Have `git archive` automatically fill in metadata at the point of creating 
> > the
> > archive, which is especially useful when using web snapshot links such as:
> > 
> >   http://xenbits.xen.org/gitweb/?p=xen.git;a=snapshot;h=HEAD;sf=tgz
> > 
> > to obtain the tarball.
> > 
> > Signed-off-by: Andrew Cooper 
> 
> Acked-by: Wei Liu 
> 
> > ---
> > CC: George Dunlap 
> > CC: Ian Jackson 
> > CC: Jan Beulich 
> > CC: Konrad Rzeszutek Wilk 
> > CC: Stefano Stabellini 
> > CC: Tim Deegan 
> > CC: Wei Liu 
> > 
> > It would be useful if this could be included in 4.8, and backported to older
> > releases  (Assuming noone has any objections)
> 
> Inclusion in 4.8 - fine by me. I will pick it up at some point.
> 

Applied.

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

Re: [Xen-devel] [PATCH for-4.8] flask: build policy in different locations

[Wei Liu]

On Thu, Nov 03, 2016 at 03:22:19PM +, Wei Liu wrote:
> On Thu, Nov 03, 2016 at 11:17:59AM -0400, Daniel De Graaf wrote:
> > On 10/28/2016 11:17 AM, Wei Liu wrote:
> > >The flask policy can be build twice -- one for hypervisor and one for
> > >tools.
> > >
> > >Before this patch, everything is built inside tools/flask/policy
> > >directory.  It is possible to have a race to write to the same output
> > >file when running parallel builds.
> > >
> > >Prepend output file names with FLASK_BUILD_DIR. Hypervisor and tools
> > >build will set that variable to different directories, so that we can
> > >be safe from races.
> > >
> > >Adjust other bits of the build system as needed.
> > >
> > >Signed-off-by: Wei Liu 
> > 
> > Acked-by: Daniel De Graaf 
> > 
> 
> Thanks.
> 
> > Pulling the definition of POLICY_FILENAME out of Makefile.common might
> > remove the need for the cmp||cp line in the xen-side Makefile, but that
> > probably belongs in another patch.
> > 
> 
> Yes, I think that's better done with another patch.
> 
> I will remove the redundant "tmp" in Makefile.common as discussed with
> Jan and commit the updated patch with your ack.

Now applied.

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

Re: [Xen-devel] [PATCH for-4.8] docs: replace hint with pointer in PVHv2 ACPI documentation

[Wei Liu]

On Thu, Nov 03, 2016 at 11:15:31AM -0600, Jan Beulich wrote:
> >>> On 03.11.16 at 17:48,  wrote:
> > Use pointer instead of hint, since this is the only way to get the address
> > of the RSDP.
> > 
> > Signed-off-by: Roger Pau Monné 
> > Reported-by: Jan Beulich 
> 
> Acked-by: Jan Beulich 
> 

Applied.

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

Re: [Xen-devel] [PATCH] tools/libxc: Add xstate cpuid leaf of avx512

[Wei Liu]

On Fri, Nov 04, 2016 at 09:40:20AM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 04, 2016 at 11:00:16AM +, Wei Liu wrote:
> > On Fri, Nov 04, 2016 at 10:20:24AM +, Andrew Cooper wrote:
> > > On 04/11/16 08:29, Luwei Kang wrote:
> > > > Enable get xstate cpuid leaf information regarding avx512 in guest.
> > > >
> > > > Signed-off-by: Luwei Kang 
> > > 
> > > Reviewed-by: Andrew Cooper 
> > > 
> > 
> > Oops, should have read all the entire thread.
> > 
> > I think we can sneak this in for 4.8 if we have some free cycles,
> > otherwise I will queue it up for -next.
> 
> It would be good to get it in as it provides some nice performance
> benefits for guests.
> 

Given that the queue is empty at the moment, I've pushed this patch.

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

Re: [Xen-devel] [PATCH] stubdom: simplify and fix Makefile

[Wei Liu]

On Fri, Nov 04, 2016 at 10:53:29AM +0100, Juergen Gross wrote:
> The stubdom Makefile is setting up links for various libraries. This
> is done only once when qemu links are created and each library's links
> are updated/created only if the link for the Makefile of the library
> isn't already existing. In case a source is added to one library after
> doing the first make of stubdom the new source won't be linked by a
> new call of make.
> 

I think this is a bug, hence I intend to take this patch in 4.8.

> Instead of testing the existence of the Makefile link use a make
> dependency which will catch changes of the linked Makefile, too.
> 
> At the same time don't repeat the same link pattern 7 times but use a
> make macro to do the linking.
> 
> Signed-off-by: Juergen Gross 
> ---
>  stubdom/Makefile | 77 
> ++--
>  1 file changed, 35 insertions(+), 42 deletions(-)
> 
> diff --git a/stubdom/Makefile b/stubdom/Makefile
> index 2921f30..9b30b58 100644
> --- a/stubdom/Makefile
> +++ b/stubdom/Makefile
> @@ -305,7 +305,41 @@ ioemu/linkfarm.stamp:
>   touch ioemu/linkfarm.stamp
>  endif
>  
> -mk-headers-$(XEN_TARGET_ARCH): $(IOEMU_LINKFARM_TARGET)
> +define do_links
> +  touch $@

This should be moved to the last line of this macro.

If you agree on this, I can fix it up while committing.

> +  mkdir -p $(dir $@)include
> +  cd $(dir $@); \
> +  ln -sf $(dir $<)include/*.h include/; \
> +  ln -sf $(dir $<)*.[ch] .; \
> +  ln -sf $(dir $<)Makefile .
> +endef
> +

Wei.

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

[Xen-devel] [linux-3.4 test] 101907: regressions - FAIL

[osstest service owner]

flight 101907 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101907/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl   6 xen-boot  fail REGR. vs. 92983
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 92983
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
92983
 test-amd64-amd64-libvirt-vhd  6 xen-boot  fail REGR. vs. 92983
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot  fail REGR. vs. 92983
 test-amd64-amd64-xl-qcow2 6 xen-boot  fail REGR. vs. 92983
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-bootfail REGR. vs. 92983
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 92983
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot fail REGR. vs. 92983
 test-amd64-amd64-qemuu-nested-intel  6 xen-boot   fail REGR. vs. 92983
 test-amd64-i386-xl6 xen-boot  fail REGR. vs. 92983
 test-amd64-amd64-xl-xsm   6 xen-boot  fail REGR. vs. 92983
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 92983

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail in 101695 pass 
in 101907
 test-amd64-amd64-i386-pvgrub  6 xen-boot   fail pass in 101695
 test-amd64-amd64-xl-rtds  6 xen-boot   fail pass in 101695
 test-amd64-i386-freebsd10-amd64  6 xen-bootfail pass in 101695
 test-amd64-i386-pair  9 xen-boot/src_host  fail pass in 101720
 test-amd64-i386-pair 10 xen-boot/dst_host  fail pass in 101720
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot   fail pass in 101822
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot   fail pass in 101840
 test-amd64-i386-xl-qemut-winxpsp3  6 xen-boot  fail pass in 101840
 test-amd64-amd64-amd64-pvgrub  6 xen-boot  fail pass in 101867
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host  fail pass in 101867
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host  fail pass in 101867

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   7 xen-buildfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 build-i386-rumprun7 xen-buildfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 linux8d1988f838a95e836342b505398d38b223181f17
baseline version:
 linux343a5fbeef08baf2097b8cf4e26137cebe3cfef4

Last test of basis92983  2016-04-27 16:21:44 Z  190 days
Testing same since   101695  2016-10-26 18:26:23 Z8 days   14 attempts


People who touched revisions under test:
  "Suzuki K. Poulose" 
  Aaro Koskinen 
  Al Viro 
  Alan Stern 
  Aleksander Morgado 
  Alex Thorlton 
  Alexandru Cornea 
  Alexey Khoroshilov 
  Amitkumar Karwar 
  Andrew Banman 
  Andrew Morton 
  Andrey Ryabinin 
  Anson Huang 
  Arnaldo Carvalho de Melo 
  Arnaldo Carvalho de Melo 
  Arnd Bergmann 
  Ben Hutchings 
  Bjørn Mork 
  Boris Brezillon 
  Borislav Petkov 
  Brian Norris 
  Charles Keepax 

Re: [Xen-devel] [PATCH] tools/libxc: Add xstate cpuid leaf of avx512

[Konrad Rzeszutek Wilk]

On Fri, Nov 04, 2016 at 11:00:16AM +, Wei Liu wrote:
> On Fri, Nov 04, 2016 at 10:20:24AM +, Andrew Cooper wrote:
> > On 04/11/16 08:29, Luwei Kang wrote:
> > > Enable get xstate cpuid leaf information regarding avx512 in guest.
> > >
> > > Signed-off-by: Luwei Kang 
> > 
> > Reviewed-by: Andrew Cooper 
> > 
> 
> Oops, should have read all the entire thread.
> 
> I think we can sneak this in for 4.8 if we have some free cycles,
> otherwise I will queue it up for -next.

It would be good to get it in as it provides some nice performance
benefits for guests.

> 
> > > ---
> > >  tools/libxc/xc_cpuid_x86.c | 6 ++
> > >  1 file changed, 6 insertions(+)
> > >
> > > diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
> > > index de06b32..d761805 100644
> > > --- a/tools/libxc/xc_cpuid_x86.c
> > > +++ b/tools/libxc/xc_cpuid_x86.c
> > > @@ -406,6 +406,9 @@ static void intel_xc_cpuid_policy(xc_interface *xch,
> > >  #define X86_XCR0_AVX(1ULL <<  2)
> > >  #define X86_XCR0_BNDREG (1ULL <<  3)
> > >  #define X86_XCR0_BNDCSR (1ULL <<  4)
> > > +#define X86_XCR0_OPMASK (1ULL <<  5)
> > > +#define X86_XCR0_ZMM(1ULL <<  6)
> > > +#define X86_XCR0_HI_ZMM (1ULL <<  7)
> > >  #define X86_XCR0_PKRU   (1ULL <<  9)
> > >  #define X86_XCR0_LWP(1ULL << 62)
> > >  
> > > @@ -437,6 +440,9 @@ static void xc_cpuid_config_xsave(xc_interface *xch,
> > >  if ( test_bit(X86_FEATURE_MPX, info->featureset) )
> > >  guest_xfeature_mask |= X86_XCR0_BNDREG | X86_XCR0_BNDCSR;
> > >  
> > > +if ( test_bit(X86_FEATURE_AVX512F, info->featureset) )
> > > +guest_xfeature_mask |= X86_XCR0_OPMASK | X86_XCR0_ZMM | 
> > > X86_XCR0_HI_ZMM;
> > > +
> > >  if ( test_bit(X86_FEATURE_PKU, info->featureset) )
> > >  guest_xfeature_mask |= X86_XCR0_PKRU;
> > >  
> > 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH v3.1 08/15] x86/vtd: fix mapping of RMRR regions

[Jan Beulich]

>>> On 04.11.16 at 14:03,  wrote:
> On Fri, Nov 04, 2016 at 06:53:09AM -0600, Jan Beulich wrote:
>> >>> On 04.11.16 at 13:25,  wrote:
>> > On Fri, Nov 04, 2016 at 04:34:58AM -0600, Jan Beulich wrote:
>> >> >>> On 04.11.16 at 10:45,  wrote:
>> >> > case p2m_invalid:
>> >> > case p2m_mmio_dm:
>> >> > ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K,
>> >> > p2m_mmio_direct, p2ma);
>> >> > if ( ret )
>> >> > break;
>> >> > if ( !iommu_use_hap_pt(d) )
>> >> > ret = iommu_map_page(d, gfn, gfn, 
> IOMMUF_readable|IOMMUF_writable);
>> >> > break;
>> >> > case p2m_mmio_direct:
>> >> > if ( a != p2ma || gfn != mfn )
>> >> > {
>> >> > printk(XENLOG_G_WARNING
>> >> >"Cannot setup identity map d%d:%lx, already mapped with "
>> >> >"different access type or mfn\n", d->domain_id, gfn);
>> >> > ret = (flag & XEN_DOMCTL_DEV_RDM_RELAXED) ? 0 : -EBUSY;
>> >> > break;
>> >> > }
>> >> > if ( !iommu_use_hap_pt(d) )
>> >> > ret = iommu_map_page(d, gfn, gfn, 
> IOMMUF_readable|IOMMUF_writable);
>> >> 
>> >> Well, since according to what I've said above this code should
>> >> really not be here, I think the code structuring question is moot
>> >> now. The conditional call to iommu_map_page() really just needs
>> >> adding alongside the p2m_set_entry() call.
>> > 
>> > OK, so if the gfn is already mapped into the p2m we don't care whether it 
>> > has a valid IOMMU mapping or not?
>> 
>> We do care, but it is the responsibility of whoever established the
>> first mapping to make sure it's present in both P2M and IOMMU.
>> IOW if the GFN is already mapped, we should be able to imply that
>> it's mapped in both places.
> 
> But how is the first caller that established the mapping supposed to know if 
> it needs an IOMMU entry or not? (p2m_mmio_direct types don't get an IOMMU 
> mapping at all)

And it's that fact stated in parentheses which I'd like to question.
I don't see what's wrong with e.g. DMAing right into / out of a
video frame buffer.

> Are we expecting the first caller that setup the mapping to also know about 
> RMRR regions and add the IOMMU entry if needed?

This has nothing to do with RMRR regions: Whoever establishes
_some_ P2M mapping ought to also establish an IOMMU one, if
the tables aren't shared (unless there is an explicit reason not do
so).

Jan


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

Re: [Xen-devel] [PATCH v3.1 08/15] x86/vtd: fix mapping of RMRR regions

[Roger Pau Monne]

On Fri, Nov 04, 2016 at 06:53:09AM -0600, Jan Beulich wrote:
> >>> On 04.11.16 at 13:25,  wrote:
> > On Fri, Nov 04, 2016 at 04:34:58AM -0600, Jan Beulich wrote:
> >> >>> On 04.11.16 at 10:45,  wrote:
> >> > case p2m_invalid:
> >> > case p2m_mmio_dm:
> >> > ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K,
> >> > p2m_mmio_direct, p2ma);
> >> > if ( ret )
> >> > break;
> >> > if ( !iommu_use_hap_pt(d) )
> >> > ret = iommu_map_page(d, gfn, gfn, 
> >> > IOMMUF_readable|IOMMUF_writable);
> >> > break;
> >> > case p2m_mmio_direct:
> >> > if ( a != p2ma || gfn != mfn )
> >> > {
> >> > printk(XENLOG_G_WARNING
> >> >"Cannot setup identity map d%d:%lx, already mapped with "
> >> >"different access type or mfn\n", d->domain_id, gfn);
> >> > ret = (flag & XEN_DOMCTL_DEV_RDM_RELAXED) ? 0 : -EBUSY;
> >> > break;
> >> > }
> >> > if ( !iommu_use_hap_pt(d) )
> >> > ret = iommu_map_page(d, gfn, gfn, 
> >> > IOMMUF_readable|IOMMUF_writable);
> >> 
> >> Well, since according to what I've said above this code should
> >> really not be here, I think the code structuring question is moot
> >> now. The conditional call to iommu_map_page() really just needs
> >> adding alongside the p2m_set_entry() call.
> > 
> > OK, so if the gfn is already mapped into the p2m we don't care whether it 
> > has a valid IOMMU mapping or not?
> 
> We do care, but it is the responsibility of whoever established the
> first mapping to make sure it's present in both P2M and IOMMU.
> IOW if the GFN is already mapped, we should be able to imply that
> it's mapped in both places.

But how is the first caller that established the mapping supposed to know if 
it needs an IOMMU entry or not? (p2m_mmio_direct types don't get an IOMMU 
mapping at all)

Are we expecting the first caller that setup the mapping to also know about 
RMRR regions and add the IOMMU entry if needed?

Roger.

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

Re: [Xen-devel] [PATCH v3.1 09/15] xen/x86: allow the emulated APICs to be enabled for the hardware domain

[Roger Pau Monne]

On Fri, Nov 04, 2016 at 06:50:10AM -0600, Jan Beulich wrote:
> >>> On 04.11.16 at 13:09,  wrote:
> > On Fri, Nov 04, 2016 at 04:21:02AM -0600, Jan Beulich wrote:
> >> >>> On 04.11.16 at 10:47,  wrote:
> >> > The local APIC and IO APIC are required in order to deliver interrupts 
> >> > from 
> >> > physical devices (this is only for PVHv2 hardware domains).
> >> 
> >> I can see the need for an LAPIC, but I don't think IO-APICs are
> >> strictly necessary. Therefore I'd like the option of it being optional
> >> at least to be considered (perhaps by way of a brief note in the
> >> commit message).
> > 
> > While it should be possible to run without an IO APIC, AFAICT most USB 
> > controllers still only support legacy PCI interrupts, and then the SCI ACPI 
> > interrupt is also delivered from a ISA IRQ. I could make the IO APIC 
> > optional, but it's going to hinder the functionality of a Dom0 IMHO if 
> > disabled.
> > 
> > What about adding a no-ioapic option to the dom0= list of options?
> 
> That's a possible route to go, but mostly orthogonal to the question
> here (you talk about mechanism to effect this being optional,
> whereas here the question is whether it should be optional in the
> first place).

As I've stated in the first paragraph, I think an IO APIC is needed 
for Dom0 to work properly.

Then I don't mind adding an option (disabled by default) if someone believes 
it can run a Dom0 without an IO APIC. In any case, this can always be 
modified later, because IO APIC presence is reported in the MADT, and it's 
not set in stone. 

Roger.

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101871
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101871
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 101871
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 101871
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 101871
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 101871
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101871
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 101871

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   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-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-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 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 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-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu199a5bde46b0eab898ab1ec591f423000302569f
baseline version:
 qemuu4eb28abd52d48657cff6ff45e8dbbbefe4dbb414

Last test of basis   101871  2016-11-03 06:24:13 Z1 days
Testing same since   101909  2016-11-03 23:21:40 Z0 days1 attempts


People who touched revisions under test:
  Alex Bennée 
  Alex Bennée 
  Changlong Xie 
  Christian Borntraeger 
  Corey Minyard 
  Cédric Le Goater 
  Dan Williams 
  Daniel P. Berrange 
  Dr. David Alan Gilbert 
  Eric Blake 
  Gonglei 
  Haozhong Zhang 
  Jeff Cody 
  Luwei Kang 
  Max Reitz 
  Michael S. Tsirkin 
  Paolo Bonzini 
  Piotr Luc 
  Pranith Kumar 
  Stefan Hajnoczi 
  Xiao Guangrong 

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

Re: [Xen-devel] [PATCH v3.1 08/15] x86/vtd: fix mapping of RMRR regions

[Jan Beulich]

>>> On 04.11.16 at 13:25,  wrote:
> On Fri, Nov 04, 2016 at 04:34:58AM -0600, Jan Beulich wrote:
>> >>> On 04.11.16 at 10:45,  wrote:
>> > case p2m_invalid:
>> > case p2m_mmio_dm:
>> > ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K,
>> > p2m_mmio_direct, p2ma);
>> > if ( ret )
>> > break;
>> > if ( !iommu_use_hap_pt(d) )
>> > ret = iommu_map_page(d, gfn, gfn, IOMMUF_readable|IOMMUF_writable);
>> > break;
>> > case p2m_mmio_direct:
>> > if ( a != p2ma || gfn != mfn )
>> > {
>> > printk(XENLOG_G_WARNING
>> >"Cannot setup identity map d%d:%lx, already mapped with "
>> >"different access type or mfn\n", d->domain_id, gfn);
>> > ret = (flag & XEN_DOMCTL_DEV_RDM_RELAXED) ? 0 : -EBUSY;
>> > break;
>> > }
>> > if ( !iommu_use_hap_pt(d) )
>> > ret = iommu_map_page(d, gfn, gfn, IOMMUF_readable|IOMMUF_writable);
>> 
>> Well, since according to what I've said above this code should
>> really not be here, I think the code structuring question is moot
>> now. The conditional call to iommu_map_page() really just needs
>> adding alongside the p2m_set_entry() call.
> 
> OK, so if the gfn is already mapped into the p2m we don't care whether it 
> has a valid IOMMU mapping or not?

We do care, but it is the responsibility of whoever established the
first mapping to make sure it's present in both P2M and IOMMU.
IOW if the GFN is already mapped, we should be able to imply that
it's mapped in both places.

Jan


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

Re: [Xen-devel] [PATCH v3.1 09/15] xen/x86: allow the emulated APICs to be enabled for the hardware domain

[Jan Beulich]

>>> On 04.11.16 at 13:09,  wrote:
> On Fri, Nov 04, 2016 at 04:21:02AM -0600, Jan Beulich wrote:
>> >>> On 04.11.16 at 10:47,  wrote:
>> > The local APIC and IO APIC are required in order to deliver interrupts 
>> > from 
>> > physical devices (this is only for PVHv2 hardware domains).
>> 
>> I can see the need for an LAPIC, but I don't think IO-APICs are
>> strictly necessary. Therefore I'd like the option of it being optional
>> at least to be considered (perhaps by way of a brief note in the
>> commit message).
> 
> While it should be possible to run without an IO APIC, AFAICT most USB 
> controllers still only support legacy PCI interrupts, and then the SCI ACPI 
> interrupt is also delivered from a ISA IRQ. I could make the IO APIC 
> optional, but it's going to hinder the functionality of a Dom0 IMHO if 
> disabled.
> 
> What about adding a no-ioapic option to the dom0= list of options?

That's a possible route to go, but mostly orthogonal to the question
here (you talk about mechanism to effect this being optional,
whereas here the question is whether it should be optional in the
first place).

Jan


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

Re: [Xen-devel] [PATCH v3.1 08/15] x86/vtd: fix mapping of RMRR regions

[Roger Pau Monne]

On Fri, Nov 04, 2016 at 04:34:58AM -0600, Jan Beulich wrote:
> >>> On 04.11.16 at 10:45,  wrote:
> > On Fri, Nov 04, 2016 at 03:16:47AM -0600, Jan Beulich wrote:
> >> >>> On 29.10.16 at 10:59,  wrote:
> >> > --- a/xen/arch/x86/mm/p2m.c
> >> > +++ b/xen/arch/x86/mm/p2m.c
> >> > @@ -1049,22 +1049,29 @@ int set_identity_p2m_entry(struct domain *d, 
> >> > unsigned long gfn,
> >> >  
> >> >  mfn = p2m->get_entry(p2m, gfn, , , 0, NULL, NULL);
> >> >  
> >> > -if ( p2mt == p2m_invalid || p2mt == p2m_mmio_dm )
> >> > +switch ( p2mt )
> >> > +{
> >> > +case p2m_invalid:
> >> > +case p2m_mmio_dm:
> >> >  ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K,
> >> >  p2m_mmio_direct, p2ma);
> >> > -else if ( mfn_x(mfn) == gfn && p2mt == p2m_mmio_direct && a == p2ma 
> >> > )
> >> > -{
> >> > -ret = 0;
> >> > -/*
> >> > - * PVH fixme: during Dom0 PVH construction, p2m entries are 
> >> > being set
> >> > - * but iomem regions are not mapped with IOMMU. This makes sure 
> >> > that
> >> > - * RMRRs are correctly mapped with IOMMU.
> >> > - */
> >> > -if ( is_hardware_domain(d) && !iommu_use_hap_pt(d) )
> >> > +if ( ret )
> >> > +break;
> >> > +/* fallthrough */
> >> > +case p2m_mmio_direct:
> >> > +if ( p2mt == p2m_mmio_direct && a != p2ma )
> >> 
> >> I don't understand the removal of the MFN == GFN check, and it
> >> also isn't being explained in the commit message.
> > 
> > Maybe I'm not understanding the logic of this function correctly, but it 
> > seems extremely bogus, and behaves quite differently depending on whether 
> > gfn == mfn and whether the domain is the hardware domain.
> 
> I can't exclude there's something wrong here, but you're removing
> a safety belt. Before touching this, did you go back in history to
> find out why things are the way they are? I remember it having
> taken quite a bit of discussion to reach a mostly acceptable flow
> here.

As said, I agree that the gfn == mfn check should be kept.

I've looked at 0e9e09 and 5ae039, but I cannot really understand how 5ae039 
was supposed to work in the first place, and to create the proper IOMMU 
mappings for RMRR regions. It replaced a call to intel_iommu_map_page with a 
call to set_identity_p2m_entry, and this newly introduced function 
(set_identity_p2m_entry) will only setup the p2m mappings for the required 
page, but it will completely ignore to setup any IOMMU mappings if the pt is 
not shared between HAP and the IOMMU.

Then 0e9e09 is a fixup for PVH guests, which really require RMRR regions 
properly mapped in the IOMMU in order to run. Since on PVH guests holes and 
reserved regions are identity mapped in the p2m, RMRR regions should already 
be mapped in the p2m, so 0e9e09 just added the IOMMU mappings if the pt was 
not shared.

But yet I think that 0e9e09 is wrong, and that it fixed RMRR mappings for 
hardware that shares the pt between HAP and the IOMMU while breaking it for 
hardware that doesn't share the pt between HAP and the IOMMU.
 
> > If gfn == mfn (so the page is already mapped in the p2m) and the domain is 
> > the hardware domain, an IOMMU mapping would be established. If gfn is not 
> > set, we will just set the p2m entry, but the IOMMU is not going to be 
> > properly configured, unless it shares the pt with p2m.
> 
> Well, that's why the comment says "PVH fixme". The issue is not
> the code here, but the code which established the mapping we
> found here. That code fails to also do the IOMMU mapping when
> needed. The only correct course of action, afaict, would be to
> fix that other code (wherever that is) and remove the comment
> together with the bogus code here (which would lead to just
> "ret = 0" remaining.

On classic PVH all holes or reserved regions in the memory map are identity 
mapped into the p2m, this is why RMRR regions where expected to be already 
mapped in the p2m. This is no longer true for PVHv2 domains, and holes or 
reserved regions are no longer mapped by default into the p2m.

> > This patch fixes the behavior of the function so it's consistent, and we 
> > can guarantee that after calling it a proper mapping in the p2m and the 
> > IOMMU 
> > will exist, and that it's going to be gfn == mfn, or else an error will be 
> > returned.
> > 
> > I agree with you that the mfn == gfn check should be kept, so the condition 
> > above should be:
> > 
> > if ( p2mt == p2m_mmio_direct && (a != p2ma || gfn != mfn) )
> > 
> > But please see below.
> > 
> >> And then following a case label with a comparison of the respective
> >> switch expression against the very value from the case label is
> >> certainly odd. I'm pretty sure a better structure of the code could be
> >> found.
> > 
> > Hm, the comparison is there because of the fallthrough in the above case. I 
> > could remove it by also 

Re: [Xen-devel] [PATCH v3.1 09/15] xen/x86: allow the emulated APICs to be enabled for the hardware domain

[Roger Pau Monne]

On Fri, Nov 04, 2016 at 04:21:02AM -0600, Jan Beulich wrote:
> >>> On 04.11.16 at 10:47,  wrote:
> > On Fri, Nov 04, 2016 at 03:19:11AM -0600, Jan Beulich wrote:
> >> >>> On 29.10.16 at 10:59,  wrote:
> >> > --- a/xen/arch/x86/domain.c
> >> > +++ b/xen/arch/x86/domain.c
> >> > @@ -509,6 +509,27 @@ void vcpu_destroy(struct vcpu *v)
> >> >  xfree(v->arch.pv_vcpu.trap_ctxt);
> >> >  }
> >> >  
> >> > +static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
> >> > +{
> >> > +
> >> > +if ( is_hvm_domain(d) )
> >> > +{
> >> > +if ( is_hardware_domain(d) &&
> >> > + emflags != 
> >> > (XEN_X86_EMU_PIT|XEN_X86_EMU_LAPIC|XEN_X86_EMU_IOAPIC) )
> >> > +return false;
> >> 
> >> Why are hardware domains required to get all three?
> > 
> > The PIT is always enabled for hardware domains, although we might consider 
> > disabling it for PVHv2 Dom0? TBH, I don't have a strong opinion here.
> 
> I think unless there's a reason to require it, it should be optional.

Ack.
 
> > The local APIC and IO APIC are required in order to deliver interrupts from 
> > physical devices (this is only for PVHv2 hardware domains).
> 
> I can see the need for an LAPIC, but I don't think IO-APICs are
> strictly necessary. Therefore I'd like the option of it being optional
> at least to be considered (perhaps by way of a brief note in the
> commit message).

While it should be possible to run without an IO APIC, AFAICT most USB 
controllers still only support legacy PCI interrupts, and then the SCI ACPI 
interrupt is also delivered from a ISA IRQ. I could make the IO APIC 
optional, but it's going to hinder the functionality of a Dom0 IMHO if 
disabled.

What about adding a no-ioapic option to the dom0= list of options?

Roger.

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

Re: [Xen-devel] [RFC PATCH 12/24] ARM: vGICv3: introduce basic ITS emulation bits

[Julien Grall]

Hello Andre,

On 03/11/16 19:26, Andre Przywara wrote:

On 24/10/16 16:31, Vijay Kilari wrote:

On Wed, Sep 28, 2016 at 11:54 PM, Andre Przywara  wrote:

+switch ( info->gpa & 0x )
+{
+case VREG32(GITS_CTLR):
+if ( info->dabt.size != DABT_WORD ) goto bad_width;
+*r = vgic_reg32_extract(its->enabled | BIT(31), info);
+   break;
+case VREG32(GITS_IIDR):
+if ( info->dabt.size != DABT_WORD ) goto bad_width;
+*r = vgic_reg32_extract(GITS_IIDR_VALUE, info);
+break;
+case VREG64(GITS_TYPER):
+if ( info->dabt.size < DABT_WORD ) goto bad_width;
+*r = vgic_reg64_extract(0x1eff1, info);

   GITS_TYPER.HCC is not set. Should be max vcpus of the domain


HCC is clear on purpose. We want the guest to provide memory for
everything that it allocates, to avoid it to hog Xen with allocations.


Whilst I agree that we want to limit the memory allocated by Xen itself,
each collection entry is just 16-bit. So unless we want to support a 
very big number of collection, I don't see any reason to request the 
guest to provision memory.


This makes the code more complex and you also have to validate the 
collection every time.


I remembered minimum number of collection an implementation has to 
support is "max_vcpus + 1" but I can't find again the statement in the spec.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH 11/24] ARM: vGICv3: handle virtual LPI pending and property tables

[Julien Grall]

Hi,

On 03/11/16 20:21, Andre Przywara wrote:

On 24/10/16 16:32, Vijay Kilari wrote:

On Wed, Sep 28, 2016 at 11:54 PM, Andre Przywara  wrote:

+va = (void *)((uintptr_t)va & PAGE_MASK);
+pa = virt_to_maddr(va);

  can use _pa()


Do you mean __pa()? Which is defined to be exactly virt_to_maddr()?
I prefer the more verbose version, which is more readable, IMHO.


FWIW, __pa tends to be more used than virt_to_maddr within the source base.

--
Julien Grall

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

Re: [Xen-devel] Test Xen 4.8 RC5 instable 04.11.16

[Wei Liu]

On Fri, Nov 04, 2016 at 11:13:29AM +, Juergen Schinker wrote:
> * Hardware:
>  Intel(R) Xeon(R) CPU E3-1220L V2 @ 2.30GHz
>  Sandisk SSD 1T
>  32G Ram
> * Software:
> 
> Debian Stretch/testing is dom0
>  
> * Guest operating systems:
> 
> Guests Ubuntu 14.04 LTS Debian Stretch/Sid 
> 
> Ubuntu 16.10 yakity yak with latest 4.8 kernel works 
>  
> * Functionality tested:
> xl 
> creating booting 
> pygrub
> credit2
> 
> * Comments:
> 
>  I compiled the latest vanilla kernel for gpu-passthrough with single gpu -
> 
> rc5 runs ca. 1h then freeze - which log should i check for ?
>  

If the guest freezes, you can have a look at guest serial output, Dom0
dmesg and xen dmesg (xl dmesg).

If the host freezes, you will need to setup a serial console and uses
another machine to capture the log as it goes.

> 
> host   : xen
> release: 4.8.5-xen
> version: #1 SMP PREEMPT Mon Oct 31 20:31:38 GMT 2016
> machine: x86_64
> nr_cpus: 4
> max_cpu_id : 3
> nr_nodes   : 1
> cores_per_socket   : 2
> threads_per_core   : 2
> cpu_mhz: 2312
> hw_caps: 
> b7ebfbff:77bae3ff:28100800:0001:0001:0281::0100
> virt_caps  : hvm hvm_directio
> total_memory   : 32711
> free_memory: 4133
> sharing_freed_memory   : 0
> sharing_used_memory: 0
> outstanding_claims : 0
> free_cpus  : 0
> xen_major  : 4
> xen_minor  : 8
> xen_extra  : .0-rc
> xen_version: 4.8.0-rc
> xen_caps   : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 
> hvm-3.0-x86_32p hvm-3.0-x86_64 
> xen_scheduler  : credit2
> xen_pagesize   : 4096
> platform_params: virt_start=0x8000
> xen_changeset  : Mon Oct 31 13:21:56 2016 + git:496673a
> xen_commandline: placeholder sched=credit2 iommu=1
> cc_compiler: gcc (Debian 6.2.0-9) 6.2.0 20161019
> cc_compile_by  : root
> cc_compile_domain  : 
> cc_compile_date: Thu Nov  3 20:55:16 GMT 2016
> build_id   : de5b411bee8c8590609ddfe7f425344deee707ba
> xend_config_format : 4

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

[Xen-devel] Test Xen 4.8 RC5 instable 04.11.16

[Juergen Schinker]

* Hardware:
 Intel(R) Xeon(R) CPU E3-1220L V2 @ 2.30GHz
 Sandisk SSD 1T
 32G Ram
* Software:

Debian Stretch/testing is dom0
 
* Guest operating systems:

Guests Ubuntu 14.04 LTS Debian Stretch/Sid 

Ubuntu 16.10 yakity yak with latest 4.8 kernel works 
 
* Functionality tested:
xl 
creating booting 
pygrub
credit2

* Comments:

 I compiled the latest vanilla kernel for gpu-passthrough with single gpu -

rc5 runs ca. 1h then freeze - which log should i check for ?
 

host   : xen
release: 4.8.5-xen
version: #1 SMP PREEMPT Mon Oct 31 20:31:38 GMT 2016
machine: x86_64
nr_cpus: 4
max_cpu_id : 3
nr_nodes   : 1
cores_per_socket   : 2
threads_per_core   : 2
cpu_mhz: 2312
hw_caps: 
b7ebfbff:77bae3ff:28100800:0001:0001:0281::0100
virt_caps  : hvm hvm_directio
total_memory   : 32711
free_memory: 4133
sharing_freed_memory   : 0
sharing_used_memory: 0
outstanding_claims : 0
free_cpus  : 0
xen_major  : 4
xen_minor  : 8
xen_extra  : .0-rc
xen_version: 4.8.0-rc
xen_caps   : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 
hvm-3.0-x86_32p hvm-3.0-x86_64 
xen_scheduler  : credit2
xen_pagesize   : 4096
platform_params: virt_start=0x8000
xen_changeset  : Mon Oct 31 13:21:56 2016 + git:496673a
xen_commandline: placeholder sched=credit2 iommu=1
cc_compiler: gcc (Debian 6.2.0-9) 6.2.0 20161019
cc_compile_by  : root
cc_compile_domain  : 
cc_compile_date: Thu Nov  3 20:55:16 GMT 2016
build_id   : de5b411bee8c8590609ddfe7f425344deee707ba
xend_config_format : 4

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

Re: [Xen-devel] [PATCH] tools/libxc: Add xstate cpuid leaf of avx512

[Wei Liu]

On Fri, Nov 04, 2016 at 10:20:24AM +, Andrew Cooper wrote:
> On 04/11/16 08:29, Luwei Kang wrote:
> > Enable get xstate cpuid leaf information regarding avx512 in guest.
> >
> > Signed-off-by: Luwei Kang 
> 
> Reviewed-by: Andrew Cooper 
> 

Oops, should have read all the entire thread.

I think we can sneak this in for 4.8 if we have some free cycles,
otherwise I will queue it up for -next.

> > ---
> >  tools/libxc/xc_cpuid_x86.c | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
> > index de06b32..d761805 100644
> > --- a/tools/libxc/xc_cpuid_x86.c
> > +++ b/tools/libxc/xc_cpuid_x86.c
> > @@ -406,6 +406,9 @@ static void intel_xc_cpuid_policy(xc_interface *xch,
> >  #define X86_XCR0_AVX(1ULL <<  2)
> >  #define X86_XCR0_BNDREG (1ULL <<  3)
> >  #define X86_XCR0_BNDCSR (1ULL <<  4)
> > +#define X86_XCR0_OPMASK (1ULL <<  5)
> > +#define X86_XCR0_ZMM(1ULL <<  6)
> > +#define X86_XCR0_HI_ZMM (1ULL <<  7)
> >  #define X86_XCR0_PKRU   (1ULL <<  9)
> >  #define X86_XCR0_LWP(1ULL << 62)
> >  
> > @@ -437,6 +440,9 @@ static void xc_cpuid_config_xsave(xc_interface *xch,
> >  if ( test_bit(X86_FEATURE_MPX, info->featureset) )
> >  guest_xfeature_mask |= X86_XCR0_BNDREG | X86_XCR0_BNDCSR;
> >  
> > +if ( test_bit(X86_FEATURE_AVX512F, info->featureset) )
> > +guest_xfeature_mask |= X86_XCR0_OPMASK | X86_XCR0_ZMM | 
> > X86_XCR0_HI_ZMM;
> > +
> >  if ( test_bit(X86_FEATURE_PKU, info->featureset) )
> >  guest_xfeature_mask |= X86_XCR0_PKRU;
> >  
> 

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

Re: [Xen-devel] [PATCH] tools/libxc: Add xstate cpuid leaf of avx512

[Wei Liu]

CC x86 maintainers. I will defer this patch to them.

On Fri, Nov 04, 2016 at 04:29:18PM +0800, Luwei Kang wrote:
> Enable get xstate cpuid leaf information regarding avx512 in guest.
> 
> Signed-off-by: Luwei Kang 
> ---
>  tools/libxc/xc_cpuid_x86.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
> index de06b32..d761805 100644
> --- a/tools/libxc/xc_cpuid_x86.c
> +++ b/tools/libxc/xc_cpuid_x86.c
> @@ -406,6 +406,9 @@ static void intel_xc_cpuid_policy(xc_interface *xch,
>  #define X86_XCR0_AVX(1ULL <<  2)
>  #define X86_XCR0_BNDREG (1ULL <<  3)
>  #define X86_XCR0_BNDCSR (1ULL <<  4)
> +#define X86_XCR0_OPMASK (1ULL <<  5)
> +#define X86_XCR0_ZMM(1ULL <<  6)
> +#define X86_XCR0_HI_ZMM (1ULL <<  7)
>  #define X86_XCR0_PKRU   (1ULL <<  9)
>  #define X86_XCR0_LWP(1ULL << 62)
>  
> @@ -437,6 +440,9 @@ static void xc_cpuid_config_xsave(xc_interface *xch,
>  if ( test_bit(X86_FEATURE_MPX, info->featureset) )
>  guest_xfeature_mask |= X86_XCR0_BNDREG | X86_XCR0_BNDCSR;
>  
> +if ( test_bit(X86_FEATURE_AVX512F, info->featureset) )
> +guest_xfeature_mask |= X86_XCR0_OPMASK | X86_XCR0_ZMM | 
> X86_XCR0_HI_ZMM;
> +
>  if ( test_bit(X86_FEATURE_PKU, info->featureset) )
>  guest_xfeature_mask |= X86_XCR0_PKRU;
>  
> -- 
> 2.7.4
> 

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

Re: [Xen-devel] [PATCH for-4.8] git: Add metadata to the result of `git archive`

[Wei Liu]

On Thu, Nov 03, 2016 at 05:57:57PM +, Andrew Cooper wrote:
> When building Xen from a source tarball, commit information is usually lost,
> especially if the tarball was generated from a tag.
> 
> Have `git archive` automatically fill in metadata at the point of creating the
> archive, which is especially useful when using web snapshot links such as:
> 
>   http://xenbits.xen.org/gitweb/?p=xen.git;a=snapshot;h=HEAD;sf=tgz
> 
> to obtain the tarball.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Wei Liu 

> ---
> CC: George Dunlap 
> CC: Ian Jackson 
> CC: Jan Beulich 
> CC: Konrad Rzeszutek Wilk 
> CC: Stefano Stabellini 
> CC: Tim Deegan 
> CC: Wei Liu 
> 
> It would be useful if this could be included in 4.8, and backported to older
> releases  (Assuming noone has any objections)

Inclusion in 4.8 - fine by me. I will pick it up at some point.

> ---
>  .gitarchive-info | 2 ++
>  .gitattributes   | 1 +
>  2 files changed, 3 insertions(+)
>  create mode 100644 .gitarchive-info
>  create mode 100644 .gitattributes
> 
> diff --git a/.gitarchive-info b/.gitarchive-info
> new file mode 100644
> index 000..83e5b86
> --- /dev/null
> +++ b/.gitarchive-info
> @@ -0,0 +1,2 @@
> +Changeset: $Format:%H$
> +Commit date: $Format:%cD$
> diff --git a/.gitattributes b/.gitattributes
> new file mode 100644
> index 000..f7bf506
> --- /dev/null
> +++ b/.gitattributes
> @@ -0,0 +1 @@
> +.gitarchive-info export-subst
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] [PATCH v3.1 08/15] x86/vtd: fix mapping of RMRR regions

[Jan Beulich]

>>> On 04.11.16 at 10:45,  wrote:
> On Fri, Nov 04, 2016 at 03:16:47AM -0600, Jan Beulich wrote:
>> >>> On 29.10.16 at 10:59,  wrote:
>> > --- a/xen/arch/x86/mm/p2m.c
>> > +++ b/xen/arch/x86/mm/p2m.c
>> > @@ -1049,22 +1049,29 @@ int set_identity_p2m_entry(struct domain *d, 
>> > unsigned long gfn,
>> >  
>> >  mfn = p2m->get_entry(p2m, gfn, , , 0, NULL, NULL);
>> >  
>> > -if ( p2mt == p2m_invalid || p2mt == p2m_mmio_dm )
>> > +switch ( p2mt )
>> > +{
>> > +case p2m_invalid:
>> > +case p2m_mmio_dm:
>> >  ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K,
>> >  p2m_mmio_direct, p2ma);
>> > -else if ( mfn_x(mfn) == gfn && p2mt == p2m_mmio_direct && a == p2ma )
>> > -{
>> > -ret = 0;
>> > -/*
>> > - * PVH fixme: during Dom0 PVH construction, p2m entries are being 
>> > set
>> > - * but iomem regions are not mapped with IOMMU. This makes sure 
>> > that
>> > - * RMRRs are correctly mapped with IOMMU.
>> > - */
>> > -if ( is_hardware_domain(d) && !iommu_use_hap_pt(d) )
>> > +if ( ret )
>> > +break;
>> > +/* fallthrough */
>> > +case p2m_mmio_direct:
>> > +if ( p2mt == p2m_mmio_direct && a != p2ma )
>> 
>> I don't understand the removal of the MFN == GFN check, and it
>> also isn't being explained in the commit message.
> 
> Maybe I'm not understanding the logic of this function correctly, but it 
> seems extremely bogus, and behaves quite differently depending on whether 
> gfn == mfn and whether the domain is the hardware domain.

I can't exclude there's something wrong here, but you're removing
a safety belt. Before touching this, did you go back in history to
find out why things are the way they are? I remember it having
taken quite a bit of discussion to reach a mostly acceptable flow
here.

> If gfn == mfn (so the page is already mapped in the p2m) and the domain is 
> the hardware domain, an IOMMU mapping would be established. If gfn is not 
> set, we will just set the p2m entry, but the IOMMU is not going to be 
> properly configured, unless it shares the pt with p2m.

Well, that's why the comment says "PVH fixme". The issue is not
the code here, but the code which established the mapping we
found here. That code fails to also do the IOMMU mapping when
needed. The only correct course of action, afaict, would be to
fix that other code (wherever that is) and remove the comment
together with the bogus code here (which would lead to just
"ret = 0" remaining.

> This patch fixes the behavior of the function so it's consistent, and we 
> can guarantee that after calling it a proper mapping in the p2m and the IOMMU 
> will exist, and that it's going to be gfn == mfn, or else an error will be 
> returned.
> 
> I agree with you that the mfn == gfn check should be kept, so the condition 
> above should be:
> 
>   if ( p2mt == p2m_mmio_direct && (a != p2ma || gfn != mfn) )
> 
> But please see below.
> 
>> And then following a case label with a comparison of the respective
>> switch expression against the very value from the case label is
>> certainly odd. I'm pretty sure a better structure of the code could be
>> found.
> 
> Hm, the comparison is there because of the fallthrough in the above case. I 
> could remove it by also setting the IOMMU entry in the above case, if that's 
> better, so it would look like:
> 
> case p2m_invalid:
> case p2m_mmio_dm:
> ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K,
> p2m_mmio_direct, p2ma);
> if ( ret )
> break;
> if ( !iommu_use_hap_pt(d) )
> ret = iommu_map_page(d, gfn, gfn, IOMMUF_readable|IOMMUF_writable);
> break;
> case p2m_mmio_direct:
> if ( a != p2ma || gfn != mfn )
> {
> printk(XENLOG_G_WARNING
>"Cannot setup identity map d%d:%lx, already mapped with "
>"different access type or mfn\n", d->domain_id, gfn);
> ret = (flag & XEN_DOMCTL_DEV_RDM_RELAXED) ? 0 : -EBUSY;
> break;
> }
> if ( !iommu_use_hap_pt(d) )
> ret = iommu_map_page(d, gfn, gfn, IOMMUF_readable|IOMMUF_writable);

Well, since according to what I've said above this code should
really not be here, I think the code structuring question is moot
now. The conditional call to iommu_map_page() really just needs
adding alongside the p2m_set_entry() call.

Jan

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

[Xen-devel] [linux-3.10 test] 101902: regressions - FAIL

[osstest service owner]

flight 101902 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101902/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-amd64-pvgrub  6 xen-bootfail REGR. vs. 100648
 test-amd64-i386-xl-xsm6 xen-boot fail REGR. vs. 100648
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot fail REGR. vs. 100648
 test-amd64-amd64-xl   6 xen-boot fail REGR. vs. 100648
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 100648
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 100648
 test-amd64-amd64-xl-credit2   6 xen-boot fail REGR. vs. 100648
 test-amd64-i386-xl6 xen-boot fail REGR. vs. 100648

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt-xsm   9 debian-install   fail in 101783 pass in 101902
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail pass in 101576
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail pass in 101594
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail pass in 
101663
 test-amd64-i386-libvirt   6 xen-boot   fail pass in 101680
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-boot  fail pass in 101680
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot   fail pass in 101731
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 
101731
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_host fail pass in 101731
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host fail pass in 101731
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-boot fail pass in 101783
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot   fail pass in 101783
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host  fail pass in 101800
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host  fail pass in 101800
 test-amd64-i386-pair  9 xen-boot/src_host  fail pass in 101800
 test-amd64-i386-pair 10 xen-boot/dst_host  fail pass in 101800
 test-amd64-amd64-qemuu-nested-intel  6 xen-bootfail pass in 101814
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 
101828
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot   fail pass in 101828
 test-amd64-amd64-pair 9 xen-boot/src_host  fail pass in 101828
 test-amd64-amd64-pair10 xen-boot/dst_host  fail pass in 101828
 test-amd64-i386-freebsd10-i386  6 xen-boot fail pass in 101837
 test-amd64-amd64-xl-multivcpu  6 xen-boot  fail pass in 101837
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot  fail pass in 101844
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot   fail pass in 101844
 test-amd64-amd64-xl-xsm   6 xen-boot   fail pass in 101856

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 fail in 101594 like 100646
 build-i386-rumprun5 rumprun-build fail in 101663 baseline untested
 build-amd64-rumprun   5 rumprun-build fail in 101663 baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100648
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100648

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt 12 migrate-support-check fail in 101680 never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 101731 never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 101731 never pass
 build-i386-rumprun7 xen-buildfail   never pass
 build-amd64-rumprun   7 xen-buildfail   never pass
 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-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 linux7828a9658951301a3fd83daa4ed0a607d370399e
baseline version:
 linux2ecaf1d025af0f481d00b3701ffbcc600dcab076

Last test of basis   100648  2016-08-28 23:14:14 Z   67 days
Testing same since   101576  2016-10-21 10:51:14 Z   13 days   22 

Re: [Xen-devel] [PATCH v3.1 09/15] xen/x86: allow the emulated APICs to be enabled for the hardware domain

[Jan Beulich]

>>> On 04.11.16 at 10:47,  wrote:
> On Fri, Nov 04, 2016 at 03:19:11AM -0600, Jan Beulich wrote:
>> >>> On 29.10.16 at 10:59,  wrote:
>> > --- a/xen/arch/x86/domain.c
>> > +++ b/xen/arch/x86/domain.c
>> > @@ -509,6 +509,27 @@ void vcpu_destroy(struct vcpu *v)
>> >  xfree(v->arch.pv_vcpu.trap_ctxt);
>> >  }
>> >  
>> > +static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
>> > +{
>> > +
>> > +if ( is_hvm_domain(d) )
>> > +{
>> > +if ( is_hardware_domain(d) &&
>> > + emflags != 
>> > (XEN_X86_EMU_PIT|XEN_X86_EMU_LAPIC|XEN_X86_EMU_IOAPIC) )
>> > +return false;
>> 
>> Why are hardware domains required to get all three?
> 
> The PIT is always enabled for hardware domains, although we might consider 
> disabling it for PVHv2 Dom0? TBH, I don't have a strong opinion here.

I think unless there's a reason to require it, it should be optional.

> The local APIC and IO APIC are required in order to deliver interrupts from 
> physical devices (this is only for PVHv2 hardware domains).

I can see the need for an LAPIC, but I don't think IO-APICs are
strictly necessary. Therefore I'd like the option of it being optional
at least to be considered (perhaps by way of a brief note in the
commit message).

Jan


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

Re: [Xen-devel] [PATCH] tools/libxc: Add xstate cpuid leaf of avx512

[Andrew Cooper]

On 04/11/16 08:29, Luwei Kang wrote:
> Enable get xstate cpuid leaf information regarding avx512 in guest.
>
> Signed-off-by: Luwei Kang 

Reviewed-by: Andrew Cooper 

> ---
>  tools/libxc/xc_cpuid_x86.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
> index de06b32..d761805 100644
> --- a/tools/libxc/xc_cpuid_x86.c
> +++ b/tools/libxc/xc_cpuid_x86.c
> @@ -406,6 +406,9 @@ static void intel_xc_cpuid_policy(xc_interface *xch,
>  #define X86_XCR0_AVX(1ULL <<  2)
>  #define X86_XCR0_BNDREG (1ULL <<  3)
>  #define X86_XCR0_BNDCSR (1ULL <<  4)
> +#define X86_XCR0_OPMASK (1ULL <<  5)
> +#define X86_XCR0_ZMM(1ULL <<  6)
> +#define X86_XCR0_HI_ZMM (1ULL <<  7)
>  #define X86_XCR0_PKRU   (1ULL <<  9)
>  #define X86_XCR0_LWP(1ULL << 62)
>  
> @@ -437,6 +440,9 @@ static void xc_cpuid_config_xsave(xc_interface *xch,
>  if ( test_bit(X86_FEATURE_MPX, info->featureset) )
>  guest_xfeature_mask |= X86_XCR0_BNDREG | X86_XCR0_BNDCSR;
>  
> +if ( test_bit(X86_FEATURE_AVX512F, info->featureset) )
> +guest_xfeature_mask |= X86_XCR0_OPMASK | X86_XCR0_ZMM | 
> X86_XCR0_HI_ZMM;
> +
>  if ( test_bit(X86_FEATURE_PKU, info->featureset) )
>  guest_xfeature_mask |= X86_XCR0_PKRU;
>  


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 669b6cc60bf610bbee32e79ed165ca604764c169
baseline version:
 ovmf 5f609eb837f235e28464285a2fb768e39cd51b56

Last test of basis   101912  2016-11-04 01:14:24 Z0 days
Testing same since   101919  2016-11-04 08:15:24 Z0 days1 attempts


People who touched revisions under test:
  Bell Song 
  Dandan Bi 
  Song, BinX 
  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 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=669b6cc60bf610bbee32e79ed165ca604764c169
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
669b6cc60bf610bbee32e79ed165ca604764c169
+ branch=ovmf
+ revision=669b6cc60bf610bbee32e79ed165ca604764c169
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x669b6cc60bf610bbee32e79ed165ca604764c169 = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : 

Re: [Xen-devel] [PATCH] stubdom: simplify and fix Makefile

[Samuel Thibault]

Juergen Gross, on Fri 04 Nov 2016 10:53:29 +0100, wrote:
> The stubdom Makefile is setting up links for various libraries. This
> is done only once when qemu links are created and each library's links
> are updated/created only if the link for the Makefile of the library
> isn't already existing. In case a source is added to one library after
> doing the first make of stubdom the new source won't be linked by a
> new call of make.
> 
> Instead of testing the existence of the Makefile link use a make
> dependency which will catch changes of the linked Makefile, too.
> 
> At the same time don't repeat the same link pattern 7 times but use a
> make macro to do the linking.
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Samuel Thibault 

> ---
>  stubdom/Makefile | 77 
> ++--
>  1 file changed, 35 insertions(+), 42 deletions(-)
> 
> diff --git a/stubdom/Makefile b/stubdom/Makefile
> index 2921f30..9b30b58 100644
> --- a/stubdom/Makefile
> +++ b/stubdom/Makefile
> @@ -305,7 +305,41 @@ ioemu/linkfarm.stamp:
>   touch ioemu/linkfarm.stamp
>  endif
>  
> -mk-headers-$(XEN_TARGET_ARCH): $(IOEMU_LINKFARM_TARGET)
> +define do_links
> +  touch $@
> +  mkdir -p $(dir $@)include
> +  cd $(dir $@); \
> +  ln -sf $(dir $<)include/*.h include/; \
> +  ln -sf $(dir $<)*.[ch] .; \
> +  ln -sf $(dir $<)Makefile .
> +endef
> +
> +libs-$(XEN_TARGET_ARCH)/toollog/stamp: 
> $(XEN_ROOT)/tools/libs/toollog/Makefile
> + $(do_links)
> +
> +libs-$(XEN_TARGET_ARCH)/evtchn/stamp: $(XEN_ROOT)/tools/libs/evtchn/Makefile
> + $(do_links)
> +
> +libs-$(XEN_TARGET_ARCH)/gnttab/stamp: $(XEN_ROOT)/tools/libs/gnttab/Makefile
> + $(do_links)
> +
> +libs-$(XEN_TARGET_ARCH)/call/stamp: $(XEN_ROOT)/tools/libs/call/Makefile
> + $(do_links)
> +
> +libs-$(XEN_TARGET_ARCH)/foreignmemory/stamp: 
> $(XEN_ROOT)/tools/libs/foreignmemory/Makefile
> + $(do_links)
> +
> +libxc-$(XEN_TARGET_ARCH)/stamp: $(XEN_ROOT)/tools/libxc/Makefile
> + $(do_links)
> +
> +xenstore/stamp: $(XEN_ROOT)/tools/xenstore/Makefile
> + $(do_links)
> +
> +LINK_LIBS_DIRS := toollog evtchn gnttab call foreignmemory
> +LINK_DIRS := libxc-$(XEN_TARGET_ARCH) xenstore $(foreach 
> dir,$(LINK_LIBS_DIRS),libs-$(XEN_TARGET_ARCH)/$(dir))
> +LINK_STAMPS := $(foreach dir,$(LINK_DIRS),$(dir)/stamp)
> +
> +mk-headers-$(XEN_TARGET_ARCH): $(IOEMU_LINKFARM_TARGET) $(LINK_STAMPS)
>   $(MAKE) -C $(XEN_ROOT)/tools/include
>   mkdir -p include/xen && \
>ln -sf $(wildcard $(XEN_ROOT)/xen/include/public/*.h) include/xen 
> && \
> @@ -316,47 +350,6 @@ mk-headers-$(XEN_TARGET_ARCH): $(IOEMU_LINKFARM_TARGET)
> ln -sf $(wildcard $(XEN_ROOT)/tools/include/xen-foreign/*) 
> include/xen-foreign/ && \
> $(MAKE) DESTDIR= -C include/xen-foreign/ && \
> ( [ -h include/xen/foreign ] || ln -sf ../xen-foreign 
> include/xen/foreign )
> - mkdir -p libs-$(XEN_TARGET_ARCH)/toollog/include
> - [ -h libs-$(XEN_TARGET_ARCH)/toollog/Makefile ] || ( cd 
> libs-$(XEN_TARGET_ARCH)/toollog && \
> -   ln -sf $(XEN_ROOT)/tools/libs/toollog/include/*.h include/ && \
> -   ln -sf $(XEN_ROOT)/tools/libs/toollog/*.c . && \
> -   ln -sf $(XEN_ROOT)/tools/libs/toollog/Makefile . )
> - mkdir -p libs-$(XEN_TARGET_ARCH)/evtchn/include
> - [ -h libs-$(XEN_TARGET_ARCH)/evtchn/Makefile ] || ( cd 
> libs-$(XEN_TARGET_ARCH)/evtchn && \
> -   ln -sf $(XEN_ROOT)/tools/libs/evtchn/*.h . && \
> -   ln -sf $(XEN_ROOT)/tools/libs/evtchn/include/*.h include/ && \
> -   ln -sf $(XEN_ROOT)/tools/libs/evtchn/*.c . && \
> -   ln -sf $(XEN_ROOT)/tools/libs/evtchn/Makefile . )
> - mkdir -p libs-$(XEN_TARGET_ARCH)/gnttab/include
> - [ -h libs-$(XEN_TARGET_ARCH)/gnttab/Makefile ] || ( cd 
> libs-$(XEN_TARGET_ARCH)/gnttab && \
> -   ln -sf $(XEN_ROOT)/tools/libs/gnttab/*.h . && \
> -   ln -sf $(XEN_ROOT)/tools/libs/gnttab/include/*.h include/ && \
> -   ln -sf $(XEN_ROOT)/tools/libs/gnttab/*.c . && \
> -   ln -sf $(XEN_ROOT)/tools/libs/gnttab/Makefile . )
> - mkdir -p libs-$(XEN_TARGET_ARCH)/call/include
> - [ -h libs-$(XEN_TARGET_ARCH)/call/Makefile ] || ( cd 
> libs-$(XEN_TARGET_ARCH)/call && \
> -   ln -sf $(XEN_ROOT)/tools/libs/call/*.h . && \
> -   ln -sf $(XEN_ROOT)/tools/libs/call/include/*.h include/ && \
> -   ln -sf $(XEN_ROOT)/tools/libs/call/*.c . && \
> -   ln -sf $(XEN_ROOT)/tools/libs/call/Makefile . )
> - mkdir -p libs-$(XEN_TARGET_ARCH)/foreignmemory/include
> - [ -h libs-$(XEN_TARGET_ARCH)/foreignmemory/Makefile ] || ( cd 
> libs-$(XEN_TARGET_ARCH)/foreignmemory && \
> -   ln -sf $(XEN_ROOT)/tools/libs/foreignmemory/*.h . && \
> -   ln -sf $(XEN_ROOT)/tools/libs/foreignmemory/include/*.h include/ && \
> -   ln -sf $(XEN_ROOT)/tools/libs/foreignmemory/*.c . && \
> -   ln -sf $(XEN_ROOT)/tools/libs/foreignmemory/Makefile . )
> - mkdir -p 

[Xen-devel] [PATCH] stubdom: simplify and fix Makefile

[Juergen Gross]

The stubdom Makefile is setting up links for various libraries. This
is done only once when qemu links are created and each library's links
are updated/created only if the link for the Makefile of the library
isn't already existing. In case a source is added to one library after
doing the first make of stubdom the new source won't be linked by a
new call of make.

Instead of testing the existence of the Makefile link use a make
dependency which will catch changes of the linked Makefile, too.

At the same time don't repeat the same link pattern 7 times but use a
make macro to do the linking.

Signed-off-by: Juergen Gross 
---
 stubdom/Makefile | 77 ++--
 1 file changed, 35 insertions(+), 42 deletions(-)

diff --git a/stubdom/Makefile b/stubdom/Makefile
index 2921f30..9b30b58 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -305,7 +305,41 @@ ioemu/linkfarm.stamp:
touch ioemu/linkfarm.stamp
 endif
 
-mk-headers-$(XEN_TARGET_ARCH): $(IOEMU_LINKFARM_TARGET)
+define do_links
+  touch $@
+  mkdir -p $(dir $@)include
+  cd $(dir $@); \
+  ln -sf $(dir $<)include/*.h include/; \
+  ln -sf $(dir $<)*.[ch] .; \
+  ln -sf $(dir $<)Makefile .
+endef
+
+libs-$(XEN_TARGET_ARCH)/toollog/stamp: $(XEN_ROOT)/tools/libs/toollog/Makefile
+   $(do_links)
+
+libs-$(XEN_TARGET_ARCH)/evtchn/stamp: $(XEN_ROOT)/tools/libs/evtchn/Makefile
+   $(do_links)
+
+libs-$(XEN_TARGET_ARCH)/gnttab/stamp: $(XEN_ROOT)/tools/libs/gnttab/Makefile
+   $(do_links)
+
+libs-$(XEN_TARGET_ARCH)/call/stamp: $(XEN_ROOT)/tools/libs/call/Makefile
+   $(do_links)
+
+libs-$(XEN_TARGET_ARCH)/foreignmemory/stamp: 
$(XEN_ROOT)/tools/libs/foreignmemory/Makefile
+   $(do_links)
+
+libxc-$(XEN_TARGET_ARCH)/stamp: $(XEN_ROOT)/tools/libxc/Makefile
+   $(do_links)
+
+xenstore/stamp: $(XEN_ROOT)/tools/xenstore/Makefile
+   $(do_links)
+
+LINK_LIBS_DIRS := toollog evtchn gnttab call foreignmemory
+LINK_DIRS := libxc-$(XEN_TARGET_ARCH) xenstore $(foreach 
dir,$(LINK_LIBS_DIRS),libs-$(XEN_TARGET_ARCH)/$(dir))
+LINK_STAMPS := $(foreach dir,$(LINK_DIRS),$(dir)/stamp)
+
+mk-headers-$(XEN_TARGET_ARCH): $(IOEMU_LINKFARM_TARGET) $(LINK_STAMPS)
$(MAKE) -C $(XEN_ROOT)/tools/include
mkdir -p include/xen && \
   ln -sf $(wildcard $(XEN_ROOT)/xen/include/public/*.h) include/xen && 
\
@@ -316,47 +350,6 @@ mk-headers-$(XEN_TARGET_ARCH): $(IOEMU_LINKFARM_TARGET)
  ln -sf $(wildcard $(XEN_ROOT)/tools/include/xen-foreign/*) 
include/xen-foreign/ && \
  $(MAKE) DESTDIR= -C include/xen-foreign/ && \
  ( [ -h include/xen/foreign ] || ln -sf ../xen-foreign 
include/xen/foreign )
-   mkdir -p libs-$(XEN_TARGET_ARCH)/toollog/include
-   [ -h libs-$(XEN_TARGET_ARCH)/toollog/Makefile ] || ( cd 
libs-$(XEN_TARGET_ARCH)/toollog && \
- ln -sf $(XEN_ROOT)/tools/libs/toollog/include/*.h include/ && \
- ln -sf $(XEN_ROOT)/tools/libs/toollog/*.c . && \
- ln -sf $(XEN_ROOT)/tools/libs/toollog/Makefile . )
-   mkdir -p libs-$(XEN_TARGET_ARCH)/evtchn/include
-   [ -h libs-$(XEN_TARGET_ARCH)/evtchn/Makefile ] || ( cd 
libs-$(XEN_TARGET_ARCH)/evtchn && \
- ln -sf $(XEN_ROOT)/tools/libs/evtchn/*.h . && \
- ln -sf $(XEN_ROOT)/tools/libs/evtchn/include/*.h include/ && \
- ln -sf $(XEN_ROOT)/tools/libs/evtchn/*.c . && \
- ln -sf $(XEN_ROOT)/tools/libs/evtchn/Makefile . )
-   mkdir -p libs-$(XEN_TARGET_ARCH)/gnttab/include
-   [ -h libs-$(XEN_TARGET_ARCH)/gnttab/Makefile ] || ( cd 
libs-$(XEN_TARGET_ARCH)/gnttab && \
- ln -sf $(XEN_ROOT)/tools/libs/gnttab/*.h . && \
- ln -sf $(XEN_ROOT)/tools/libs/gnttab/include/*.h include/ && \
- ln -sf $(XEN_ROOT)/tools/libs/gnttab/*.c . && \
- ln -sf $(XEN_ROOT)/tools/libs/gnttab/Makefile . )
-   mkdir -p libs-$(XEN_TARGET_ARCH)/call/include
-   [ -h libs-$(XEN_TARGET_ARCH)/call/Makefile ] || ( cd 
libs-$(XEN_TARGET_ARCH)/call && \
- ln -sf $(XEN_ROOT)/tools/libs/call/*.h . && \
- ln -sf $(XEN_ROOT)/tools/libs/call/include/*.h include/ && \
- ln -sf $(XEN_ROOT)/tools/libs/call/*.c . && \
- ln -sf $(XEN_ROOT)/tools/libs/call/Makefile . )
-   mkdir -p libs-$(XEN_TARGET_ARCH)/foreignmemory/include
-   [ -h libs-$(XEN_TARGET_ARCH)/foreignmemory/Makefile ] || ( cd 
libs-$(XEN_TARGET_ARCH)/foreignmemory && \
- ln -sf $(XEN_ROOT)/tools/libs/foreignmemory/*.h . && \
- ln -sf $(XEN_ROOT)/tools/libs/foreignmemory/include/*.h include/ && \
- ln -sf $(XEN_ROOT)/tools/libs/foreignmemory/*.c . && \
- ln -sf $(XEN_ROOT)/tools/libs/foreignmemory/Makefile . )
-   mkdir -p libxc-$(XEN_TARGET_ARCH)/include
-   [ -h libxc-$(XEN_TARGET_ARCH)/Makefile ] || ( cd 
libxc-$(XEN_TARGET_ARCH) && \
- ln -sf $(XEN_ROOT)/tools/libxc/*.h . && \
- ln -sf $(XEN_ROOT)/tools/libxc/include/*.h include/ && \
- ln -sf 

Re: [Xen-devel] [PATCH v3.1 09/15] xen/x86: allow the emulated APICs to be enabled for the hardware domain

[Roger Pau Monne]

On Fri, Nov 04, 2016 at 03:19:11AM -0600, Jan Beulich wrote:
> >>> On 29.10.16 at 10:59,  wrote:
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -509,6 +509,27 @@ void vcpu_destroy(struct vcpu *v)
> >  xfree(v->arch.pv_vcpu.trap_ctxt);
> >  }
> >  
> > +static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
> > +{
> > +
> > +if ( is_hvm_domain(d) )
> > +{
> > +if ( is_hardware_domain(d) &&
> > + emflags != 
> > (XEN_X86_EMU_PIT|XEN_X86_EMU_LAPIC|XEN_X86_EMU_IOAPIC) )
> > +return false;
> 
> Why are hardware domains required to get all three?

The PIT is always enabled for hardware domains, although we might consider 
disabling it for PVHv2 Dom0? TBH, I don't have a strong opinion here.

The local APIC and IO APIC are required in order to deliver interrupts from 
physical devices (this is only for PVHv2 hardware domains).

Roger.

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

Re: [Xen-devel] [PATCH v3.1 08/15] x86/vtd: fix mapping of RMRR regions

[Roger Pau Monne]

On Fri, Nov 04, 2016 at 03:16:47AM -0600, Jan Beulich wrote:
> >>> On 29.10.16 at 10:59,  wrote:
> > --- a/xen/arch/x86/mm/p2m.c
> > +++ b/xen/arch/x86/mm/p2m.c
> > @@ -1049,22 +1049,29 @@ int set_identity_p2m_entry(struct domain *d, 
> > unsigned long gfn,
> >  
> >  mfn = p2m->get_entry(p2m, gfn, , , 0, NULL, NULL);
> >  
> > -if ( p2mt == p2m_invalid || p2mt == p2m_mmio_dm )
> > +switch ( p2mt )
> > +{
> > +case p2m_invalid:
> > +case p2m_mmio_dm:
> >  ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K,
> >  p2m_mmio_direct, p2ma);
> > -else if ( mfn_x(mfn) == gfn && p2mt == p2m_mmio_direct && a == p2ma )
> > -{
> > -ret = 0;
> > -/*
> > - * PVH fixme: during Dom0 PVH construction, p2m entries are being 
> > set
> > - * but iomem regions are not mapped with IOMMU. This makes sure 
> > that
> > - * RMRRs are correctly mapped with IOMMU.
> > - */
> > -if ( is_hardware_domain(d) && !iommu_use_hap_pt(d) )
> > +if ( ret )
> > +break;
> > +/* fallthrough */
> > +case p2m_mmio_direct:
> > +if ( p2mt == p2m_mmio_direct && a != p2ma )
> 
> I don't understand the removal of the MFN == GFN check, and it
> also isn't being explained in the commit message.

Maybe I'm not understanding the logic of this function correctly, but it 
seems extremely bogus, and behaves quite differently depending on whether 
gfn == mfn and whether the domain is the hardware domain.

If gfn == mfn (so the page is already mapped in the p2m) and the domain is 
the hardware domain, an IOMMU mapping would be established. If gfn is not 
set, we will just set the p2m entry, but the IOMMU is not going to be 
properly configured, unless it shares the pt with p2m.

This patch fixes the behavior of the function so it's consistent, and we 
can guarantee that after calling it a proper mapping in the p2m and the IOMMU 
will exist, and that it's going to be gfn == mfn, or else an error will be 
returned.

I agree with you that the mfn == gfn check should be kept, so the condition 
above should be:

if ( p2mt == p2m_mmio_direct && (a != p2ma || gfn != mfn) )

But please see below.

> And then following a case label with a comparison of the respective
> switch expression against the very value from the case label is
> certainly odd. I'm pretty sure a better structure of the code could be
> found.

Hm, the comparison is there because of the fallthrough in the above case. I 
could remove it by also setting the IOMMU entry in the above case, if that's 
better, so it would look like:

case p2m_invalid:
case p2m_mmio_dm:
ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K,
p2m_mmio_direct, p2ma);
if ( ret )
break;
if ( !iommu_use_hap_pt(d) )
ret = iommu_map_page(d, gfn, gfn, IOMMUF_readable|IOMMUF_writable);
break;
case p2m_mmio_direct:
if ( a != p2ma || gfn != mfn )
{
printk(XENLOG_G_WARNING
   "Cannot setup identity map d%d:%lx, already mapped with "
   "different access type or mfn\n", d->domain_id, gfn);
ret = (flag & XEN_DOMCTL_DEV_RDM_RELAXED) ? 0 : -EBUSY;
break;
}
if ( !iommu_use_hap_pt(d) )
ret = iommu_map_page(d, gfn, gfn, IOMMUF_readable|IOMMUF_writable);
break;

Or I could add an if before entering the switch case that checks if type is
p2m_mmio_direct and if the access type and mfn matches what we expect, but I 
think that's not going to make the code easier.

> > +{
> > +printk(XENLOG_G_WARNING
> > +   "Cannot setup identity map d%d:%lx, already mapped with 
> > "
> > +   "different access type (current: %d, requested: %d).\n",
> 
> Please avoid full stops at the end of log messages.

Done.

Thanks, Roger.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-qcow2 14 guest-start/debian.repeat fail REGR. vs. 
101839

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 101839
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 101839
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 101839
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 101839

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 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-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass

version targeted for testing:
 libvirt  a55fdc3f251ab1800050505ac1e6158ee7535402
baseline version:
 libvirt  06a7b1ff4dbb1ed6a69e09765bef1f67a75a86eb

Last test of basis   101839  2016-11-01 04:20:30 Z3 days
Failing since101854  2016-11-02 04:23:30 Z2 days3 attempts
Testing same since   101915  2016-11-04 04:20:44 Z0 days1 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  Daniel Veillard 
  Jiri Denemark 
  Martin Kletzander 
  Michal Privoznik 
  Pavel Hrdina 
  Pavel Timofeev 

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



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

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

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

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


Not pushing.


commit a55fdc3f251ab1800050505ac1e6158ee7535402
Author: Pavel Hrdina 
Date:   Thu Nov 3 15:38:09 2016 +0100

configure: check gnutls related stuff only if 

Re: [Xen-devel] [Qemu-devel] [PULL 0/2] tags/xen-20161102-tag

[Stefan Hajnoczi]

On Wed, Nov 02, 2016 at 01:54:25PM -0700, Stefano Stabellini wrote:
> The following changes since commit 4eb28abd52d48657cff6ff45e8dbbbefe4dbb414:
> 
>   Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20161101-2' into 
> staging (2016-11-01 16:53:05 +)
> 
> are available in the git repository at:
> 
> 
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20161102-tag
> 
> for you to fetch changes up to 021746c131cdfeab9d82ff918795a9f18d20d7ae:
> 
>   PCMachineState: introduce acpi_build_enabled field (2016-11-02 12:26:12 
> -0700)
> 
> 
> Xen 2016/11/02
> 
> 
> Thomas Huth (1):
>   hw/xen/xen_pvdev: Include qemu/log.h for qemu_log_vprintf()
> 
> Wei Liu (1):
>   PCMachineState: introduce acpi_build_enabled field
> 
>  hw/i386/acpi-build.c | 2 +-
>  hw/i386/pc.c | 2 ++
>  hw/xen/xen_pvdev.c   | 2 +-
>  include/hw/i386/pc.h | 2 ++
>  xen-common.c | 6 ++
>  5 files changed, 12 insertions(+), 2 deletions(-)
> 

Thanks, applied to my staging tree:
https://github.com/stefanha/qemu/commits/staging

Stefan


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC PATCH 21/24] ARM: vITS: handle INVALL command

[Andre Przywara]

Hi,

On 24/10/16 16:32, Vijay Kilari wrote:
> On Wed, Sep 28, 2016 at 11:54 PM, Andre Przywara  
> wrote:
>> The INVALL command instructs an ITS to invalidate the configuration
>> data for all LPIs associated with a given redistributor (read: VCPU).
>> To avoid iterating (and mapping!) all guest tables, we instead go through
>> the host LPI table to find any LPIs targetting this VCPU. We then update
>> the configuration bits for the connected virtual LPIs.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  xen/arch/arm/gic-its.c| 58 
>> +++
>>  xen/arch/arm/vgic-its.c   | 30 ++
>>  xen/include/asm-arm/gic-its.h |  2 ++
>>  3 files changed, 90 insertions(+)
>>
>> diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
>> index 6f4329f..5129d6e 100644
>> --- a/xen/arch/arm/gic-its.c
>> +++ b/xen/arch/arm/gic-its.c
>> @@ -228,6 +228,18 @@ static int its_send_cmd_inv(struct host_its *its,
>>  return its_send_command(its, cmd);
>>  }
>>
>> +static int its_send_cmd_invall(struct host_its *its, int cpu)
>> +{
>> +uint64_t cmd[4];
>> +
>> +cmd[0] = GITS_CMD_INVALL;
>> +cmd[1] = 0x00;
>> +cmd[2] = cpu & GENMASK(15, 0);
>> +cmd[3] = 0x00;
>> +
>> +return its_send_command(its, cmd);
>> +}
>> +
>>  int gicv3_its_map_device(struct host_its *hw_its, struct domain *d,
>>   int devid, int bits, bool valid)
>>  {
>> @@ -668,6 +680,52 @@ uint32_t gicv3_lpi_lookup_lpi(struct domain *d, 
>> uint32_t host_lpi, int *vcpu_id)
>>  return hlpi.virt_lpi;
>>  }
>>
>> +/* Iterate over all host LPIs, and updating the "enabled" state for a given
>> + * guest redistributor (VCPU) given the respective state in the provided
>> + * proptable. This proptable is indexed by the stored virtual LPI number.
>> + * This is to implement a guest INVALL command.
>> + */
>> +void gicv3_lpi_update_configurations(struct vcpu *v, uint8_t *proptable)
>> +{
>> +int chunk, i;
>> +struct host_its *its;
>> +
>> +for (chunk = 0; chunk < MAX_HOST_LPIS / HOST_LPIS_PER_PAGE; chunk++)
>> +{
>> +if ( !lpi_data.host_lpis[chunk] )
>> +continue;
>> +
>> +for (i = 0; i < HOST_LPIS_PER_PAGE; i++)
>> +{
>> +union host_lpi *hlpip = _data.host_lpis[chunk][i], hlpi;
>> +uint32_t hlpi_nr;
>> +
>> +hlpi.data = hlpip->data;
>> +if ( !hlpi.virt_lpi )
>> +continue;
>> +
>> +if ( hlpi.dom_id != v->domain->domain_id )
>> +continue;
>> +
>> +if ( hlpi.vcpu_id != v->vcpu_id )
>> +continue;
>> +
>> +hlpi_nr = chunk * HOST_LPIS_PER_PAGE + i;
>> +
>> +if ( proptable[hlpi.virt_lpi] & LPI_PROP_ENABLED )
>> +lpi_data.lpi_property[hlpi_nr - 8192] |= LPI_PROP_ENABLED;
>> +else
>> +lpi_data.lpi_property[hlpi_nr - 8192] &= ~LPI_PROP_ENABLED;
>> +}
>> +}
> AFAIK, the initial design is to use tasklet to update property
> table as it consumes
> lot of time to update the table.

This is a possible, but premature optimization.
Linux (at the moment, at least) only calls INVALL _once_, just after
initialising the collections. And at this point no LPI is mapped, so the
whole routine does basically nothing - and that quite fast.
We can later have any kind of fancy algorithm if there is a need for.

Cheers,
Andre.


>> +
>> +/* Tell all ITSes that they should update the property table for CPU 0,
>> + * which is where we map all LPIs to.
>> + */
>> +list_for_each_entry(its, _its_list, entry)
>> +its_send_cmd_invall(its, 0);
>> +}
>> +
>>  void gicv3_lpi_set_enable(struct host_its *its,
>>uint32_t deviceid, uint32_t eventid,
>>uint32_t host_lpi, bool enabled)
>> diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
>> index 74da8fc..1e429b7 100644
>> --- a/xen/arch/arm/vgic-its.c
>> +++ b/xen/arch/arm/vgic-its.c
>> @@ -294,6 +294,33 @@ out_unlock:
>>  return ret;
>>  }
>>
>> +/* INVALL updates the per-LPI configuration status for every LPI mapped to
>> + * this redistributor. For the guest side we don't need to update anything,
>> + * as we always refer to the actual table for the enabled bit and the
>> + * priority.
>> + * Enabling or disabling a virtual LPI however needs to be propagated to
>> + * the respective host LPI. Instead of iterating over all mapped LPIs in our
>> + * emulated GIC (which is expensive due to the required on-demand mapping),
>> + * we iterate over all mapped _host_ LPIs and filter for those which are
>> + * forwarded to this virtual redistributor.
>> + */
>> +static int its_handle_invall(struct virt_its *its, uint64_t *cmdptr)
>> +{
>> +uint32_t collid = its_cmd_get_collection(cmdptr);
>> +struct vcpu *vcpu;
>> +
>> +spin_lock(>its_lock);
>> +  

Re: [Xen-devel] [PATCH v3.1 09/15] xen/x86: allow the emulated APICs to be enabled for the hardware domain

[Jan Beulich]

>>> On 29.10.16 at 10:59,  wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -509,6 +509,27 @@ void vcpu_destroy(struct vcpu *v)
>  xfree(v->arch.pv_vcpu.trap_ctxt);
>  }
>  
> +static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
> +{
> +
> +if ( is_hvm_domain(d) )
> +{
> +if ( is_hardware_domain(d) &&
> + emflags != 
> (XEN_X86_EMU_PIT|XEN_X86_EMU_LAPIC|XEN_X86_EMU_IOAPIC) )
> +return false;

Why are hardware domains required to get all three?

Jan


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

Re: [Xen-devel] [PATCH v3.1 08/15] x86/vtd: fix mapping of RMRR regions

[Jan Beulich]

>>> On 29.10.16 at 10:59,  wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1049,22 +1049,29 @@ int set_identity_p2m_entry(struct domain *d, unsigned 
> long gfn,
>  
>  mfn = p2m->get_entry(p2m, gfn, , , 0, NULL, NULL);
>  
> -if ( p2mt == p2m_invalid || p2mt == p2m_mmio_dm )
> +switch ( p2mt )
> +{
> +case p2m_invalid:
> +case p2m_mmio_dm:
>  ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K,
>  p2m_mmio_direct, p2ma);
> -else if ( mfn_x(mfn) == gfn && p2mt == p2m_mmio_direct && a == p2ma )
> -{
> -ret = 0;
> -/*
> - * PVH fixme: during Dom0 PVH construction, p2m entries are being set
> - * but iomem regions are not mapped with IOMMU. This makes sure that
> - * RMRRs are correctly mapped with IOMMU.
> - */
> -if ( is_hardware_domain(d) && !iommu_use_hap_pt(d) )
> +if ( ret )
> +break;
> +/* fallthrough */
> +case p2m_mmio_direct:
> +if ( p2mt == p2m_mmio_direct && a != p2ma )

I don't understand the removal of the MFN == GFN check, and it
also isn't being explained in the commit message.

And then following a case label with a comparison of the respective
switch expression against the very value from the case label is
certainly odd. I'm pretty sure a better structure of the code could be
found.

> +{
> +printk(XENLOG_G_WARNING
> +   "Cannot setup identity map d%d:%lx, already mapped with "
> +   "different access type (current: %d, requested: %d).\n",

Please avoid full stops at the end of log messages.

Jan


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 101869
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101869
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101869
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 101869
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101869
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101869
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 101869
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 101869
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101869

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 build-i386-rumprun7 xen-buildfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 build-amd64-rumprun   7 xen-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-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-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-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
 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-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 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-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass

version targeted for testing:
 xen  4ccb2adb96042e0d1e334c01fe260b32e6001db9
baseline version:
 xen  496673a2ada93c201fbe1cc83146c8bd8e79169d

Last test of basis   101869  2016-11-03 04:29:02 Z1 days
Testing same since   101905  2016-11-03 21:45:21 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Roger Pau Monne 
  Roger Pau Monné 
  Wei Liu 

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

[Xen-devel] [PATCH] tools/libxc: Add xstate cpuid leaf of avx512

[Luwei Kang]

Enable get xstate cpuid leaf information regarding avx512 in guest.

Signed-off-by: Luwei Kang 
---
 tools/libxc/xc_cpuid_x86.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index de06b32..d761805 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -406,6 +406,9 @@ static void intel_xc_cpuid_policy(xc_interface *xch,
 #define X86_XCR0_AVX(1ULL <<  2)
 #define X86_XCR0_BNDREG (1ULL <<  3)
 #define X86_XCR0_BNDCSR (1ULL <<  4)
+#define X86_XCR0_OPMASK (1ULL <<  5)
+#define X86_XCR0_ZMM(1ULL <<  6)
+#define X86_XCR0_HI_ZMM (1ULL <<  7)
 #define X86_XCR0_PKRU   (1ULL <<  9)
 #define X86_XCR0_LWP(1ULL << 62)
 
@@ -437,6 +440,9 @@ static void xc_cpuid_config_xsave(xc_interface *xch,
 if ( test_bit(X86_FEATURE_MPX, info->featureset) )
 guest_xfeature_mask |= X86_XCR0_BNDREG | X86_XCR0_BNDCSR;
 
+if ( test_bit(X86_FEATURE_AVX512F, info->featureset) )
+guest_xfeature_mask |= X86_XCR0_OPMASK | X86_XCR0_ZMM | 
X86_XCR0_HI_ZMM;
+
 if ( test_bit(X86_FEATURE_PKU, info->featureset) )
 guest_xfeature_mask |= X86_XCR0_PKRU;
 
-- 
2.7.4


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 5f609eb837f235e28464285a2fb768e39cd51b56
baseline version:
 ovmf e9d0933d45e51027836f570427141fd2e3a7dfbd

Last test of basis   101872  2016-11-03 06:22:51 Z1 days
Testing same since   101912  2016-11-04 01:14:24 Z0 days1 attempts


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

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=5f609eb837f235e28464285a2fb768e39cd51b56
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
5f609eb837f235e28464285a2fb768e39cd51b56
+ branch=ovmf
+ revision=5f609eb837f235e28464285a2fb768e39cd51b56
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x5f609eb837f235e28464285a2fb768e39cd51b56 = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : 

[Xen-devel] [qemu-mainline baseline-only test] 67991: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67991 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67991/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67975
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 67975

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

version targeted for testing:
 qemuu4eb28abd52d48657cff6ff45e8dbbbefe4dbb414
baseline version:
 qemuue80b4b8fb6babce7dcc91ea9ddeecbc351fd4646

Last test of basis67975  2016-11-01 09:46:14 Z2 days
Testing same since67991  2016-11-03 23:17:44 Z0 days1 attempts


People who touched revisions under test:
  Corey Minyard 
  Denis Plotnikov 
  Denis V. Lunev 
  Edgar E. Iglesias 
  Eduardo Habkost 
  Eric Blake 
  Fam Zheng 
  Greg Kurz 
  Jeff Cody 
  John Snow 
  Joseph Myers 
  Kevin Wolf 
  Li Qiang 
  Mark Cave-Ayland 
  Michael Roth 
  Peter Maydell 
  Pranith Kumar 
  Prasanna Kumar Kalever 
  Richard Henderson 
  Stefan Hajnoczi 
  Xiubo Li 

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

Re: [Xen-devel] [PATCH for-4.8] git: Add metadata to the result of `git archive`

[Jan Beulich]

>>> On 03.11.16 at 18:57,  wrote:
> When building Xen from a source tarball, commit information is usually lost,
> especially if the tarball was generated from a tag.
> 
> Have `git archive` automatically fill in metadata at the point of creating the
> archive, which is especially useful when using web snapshot links such as:
> 
>   http://xenbits.xen.org/gitweb/?p=xen.git;a=snapshot;h=HEAD;sf=tgz 
> 
> to obtain the tarball.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v2] VMX: fix realmode emulation SReg handling

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Saturday, October 29, 2016 12:21 AM
> 
> Commit 0888d36bb2 ("x86/emul: Correct the decoding of SReg3 operands")
> overlooked three places where x86_seg_cs was assumed to be zero.
> 
> Signed-off-by: Jan Beulich 
> Reviewed-by: Andrew Cooper 
> Release-acked-by: Wei Liu 
> ---
> v2: Add BUILD_BUG_ON() and use ARRAY_SIZE(reg) as loop bound.

Acked-by: Kevin Tian 

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