[Xen-devel] [xen-4.7-testing test] 101932: regressions - FAIL
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 tes
[Xen-devel] [qemu-mainline baseline-only test] 67996: regressions - FAIL
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 pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-ar
[Xen-devel] [linux-3.10 test] 101923: regressions - FAIL
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 attempts
[Xen-devel] [ovmf test] 101930: all pass - PUSHED
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 ++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.g
[Xen-devel] [ovmf baseline-only test] 67997: trouble: broken/pass
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
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
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é Wei Liu jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm
[Xen-devel] [xen-4.6-testing test] 101924: regressions - FAIL
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 build-i386-pvops
[Xen-devel] [PATCH v2 1/2] Revert "xen/arm: platform: Drop the quirks callback"
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 2/2] Partially revert 21550029f709072aacf3b90edd574e7d3021b400
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 0/2] Fix Xen boot on XGene
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
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.
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 Para-virtual sound card driver utilize nodes within the + * XenStore to communicate capabilities and to negotiate op
Re: [Xen-devel] [PATCH 0/2] Fix Xen boot on XGene
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
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
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 ++ : git://git.kernel.org/pub/scm/linux/kernel/gi
Re: [Xen-devel] Test Xen 4.8 RC5 instable 04.11.16
- 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
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
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&D 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
- 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
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&D 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
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 test-amd64-amd64-lib
[Xen-devel] Fwd: Re: Error migrating VM to secondary host using COLO replication
-- 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 > Nov 3 20:04:55 colob-HP-Compaq-6005-Pr
Re: [Xen-devel] Test Xen 4.8 RC5 instable 04.11.16
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&D 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
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
>>> 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
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 ++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git ++ : osst...@xenbits.xen.org:/home/x
[Xen-devel] [xen-unstable-smoke test] 101928: tolerable all pass - PUSHED
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 ++ : 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.o
Re: [Xen-devel] [PATCH v3.1 08/15] x86/vtd: fix mapping of RMRR regions
>>> 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
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
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
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
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->its_lock); + +itte = get_devid_evid(its, devid, eventid); +if ( !itte ) +{ +spin_unlock(&its->its_lock); +return -1; +} + +vcpu = get_vcpu_from_collection(its, itte->collection); +if ( !vcpu ) +{ +spin_unlock(&its->its_lock); +return -1; +} + +vlpi = itte->vlpi; + +put_devid_evid(its, itte); +spin_unlock(&its->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, &pirq->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, &pirq->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. +} + +
Re: [Xen-devel] [RFC PATCH 08/24] ARM: GICv3: introduce separate pending_irq structs for LPIs
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, &v->arch.vgic.pending_lpi_list, entry) +{ +if ( lpi_irq->pirq.irq == lpi ) +return &lpi_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(&empty->pirq, lpi); +list_add_tail(&empty->entry, &v->arch.vgic.pending_lpi_list); +} else +{ +empty->pirq.status = 0; +empty->pirq.irq = lpi; +} + +return &empty->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
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
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
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
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
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
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
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
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
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`
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
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
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
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
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
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 Chen Yu Christoph Hellwig Chunfeng Yun Clemens Ladisch Colin Ian King Cong Wang Daeho Jeong Dan Carpenter Darren Hart Dave Airlie David Howells David Rientjes David S. Miller David Turner David Vrabel David Woodhouse Dmitry Tunin Dmitry V. Levin Dmitry Vyukov Eric Dumazet Eric Dumazet Felipe Balbi Filipe Manana Francesco Ruggeri Francesco Ruggeri Greg Kroah-Hartman Helge Deller Herbert Xu Hillf Danton Hobin Woo
Re: [Xen-devel] [PATCH] tools/libxc: Add xstate cpuid leaf of avx512
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
>>> 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
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
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
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 build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl
Re: [Xen-devel] [PATCH v3.1 08/15] x86/vtd: fix mapping of RMRR regions
>>> 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
>>> 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
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, &p2mt, &a, 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 setting the IOMMU entry in the above case,
Re: [Xen-devel] [PATCH v3.1 09/15] xen/x86: allow the emulated APICs to be enabled for the hardware domain
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
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
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
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
* 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
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
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`
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
>>> 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, &p2mt, &a, 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
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 attempts
Re: [Xen-devel] [PATCH v3.1 09/15] xen/x86: allow the emulated APICs to be enabled for the hardware domain
>>> 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
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
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 ++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git ++ : osst...@x
Re: [Xen-devel] [PATCH] stubdom: simplify and fix Makefile
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 libxc-$(XEN_TARGET_ARCH)/include > - [ -h libxc-$(XEN_TARGET_
[Xen-devel] [PATCH] stubdom: simplify and fix Makefile
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 $(XEN_ROOT)/tools/libxc/*.c . && \
Re: [Xen-devel] [PATCH v3.1 09/15] xen/x86: allow the emulated APICs to be enabled for the hardware domain
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
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, &p2mt, &a, 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
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 gnutls was found This fixes a build issue with old gnutls. Broken by commit 680d2f49da. Reported-by: Olga Krishtal Signed-off-by: Pavel Hrdi
Re: [Xen-devel] [Qemu-devel] [PULL 0/2] tags/xen-20161102-tag
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
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 = &lpi_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, &host_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->its_lock); >> +vcpu = get_vcpu_from_collection(
Re: [Xen-devel] [PATCH v3.1 09/15] xen/x86: allow the emulated APICs to be enabled for the hardware domain
>>> 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
>>> 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, &p2mt, &a, 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
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 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt p
[Xen-devel] [PATCH] tools/libxc: Add xstate cpuid leaf of avx512
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
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 ++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git ++ : osst...@xenbits.xen.org:/home
[Xen-devel] [qemu-mainline baseline-only test] 67991: tolerable FAIL
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 pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl
Re: [Xen-devel] [PATCH for-4.8] git: Add metadata to the result of `git archive`
>>> 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