[Xen-devel] [xen-4.8-testing baseline-only test] 72462: regressions - FAIL
This run is configured for baseline tests only. flight 72462 xen-4.8-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72462/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 72353 test-armhf-armhf-libvirt-raw 10 debian-di-install fail REGR. vs. 72353 test-amd64-amd64-xl-qemut-win10-i386 16 guest-localmigrate/x10 fail REGR. vs. 72353 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail blocked in 72353 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail blocked in 72353 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 72353 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 72353 build-i386-prev 7 xen-build/dist-test fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-armhf-armhf-xl-midway 13 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass build-amd64-prev 7 xen-build/dist-test fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-qemuu-nested-intel 18 capture-logs/l1(18) fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win10-i386 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 9ba6783e47db71379c5120039b878f605bdf31f3 baseline version: xen 03af24c35ed38967ab8151fdb53da3f6f6cc0872 Last test of basis72353 2017-10-26 06:14:10 Z 23 days Testing same since72462 2017-11-17 17:46:10 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Eric Chanudet George Dunlap Jan Beulich Min He Yi Zhang Yu Zhang 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-amd6
[Xen-devel] [xen-4.6-testing test] 116250: regressions - FAIL
flight 116250 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/116250/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stopfail REGR. vs. 115190 Tests which are failing intermittently (not blocking): test-xtf-amd64-amd64-1 49 xtf/test-hvm64-lbr-tsx-vmentry fail in 116222 pass in 116250 test-xtf-amd64-amd64-3 49 xtf/test-hvm64-lbr-tsx-vmentry fail in 116222 pass in 116250 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 116222 pass in 116250 test-xtf-amd64-amd64-5 49 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 116222 test-xtf-amd64-amd64-4 49 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 116222 Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-2 49 xtf/test-hvm64-lbr-tsx-vmentry fail like 115190 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 115190 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 115190 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 115190 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115190 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 115190 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 115190 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115190 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 115190 test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-xtf-amd64-amd64-5 73 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-1 73 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-2 73 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-4 73 xtf/test-pv32pae-xsa-194 fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-xtf-amd64-amd64-3 73 xtf/test-pv32pae-xsa-194 fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: xen 9b0c2a223132a07f06f0be8e85da390defe998f5 baseline version: xen 9454e3030ae0835c11aa66471238a9e09db5074e Last test of basis 115190 2017-10-24 15:13:45 Z
[Xen-devel] [xen-4.5-testing test] 116245: regressions - FAIL
flight 116245 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/116245/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115226 test-amd64-i386-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail in 116223 REGR. vs. 115226 Tests which are failing intermittently (not blocking): test-amd64-i386-libvirt-qcow2 15 guest-saverestore.2 fail in 116223 pass in 116245 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 16 guest-localmigrate/x10 fail in 116223 pass in 116245 test-amd64-i386-xl-qemuu-winxpsp3 16 guest-localmigrate/x10 fail pass in 116223 test-amd64-i386-xl-qemuu-ws16-amd64 14 guest-localmigrate fail pass in 116223 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 115226 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stopfail REGR. vs. 115226 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-vhd 10 debian-di-install fail in 116223 like 115191 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 115191 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115191 test-amd64-amd64-xl-rtds 7 xen-boot fail like 115226 test-xtf-amd64-amd64-2 60 leak-check/check fail like 115226 test-xtf-amd64-amd64-3 60 leak-check/check fail like 115226 test-xtf-amd64-amd64-4 60 leak-check/check fail like 115226 test-xtf-amd64-amd64-1 60 leak-check/check fail like 115226 test-xtf-amd64-amd64-5 60 leak-check/check fail like 115226 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 115226 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 115226 test-xtf-amd64-amd64-2 19 xtf/test-hvm32-cpuid-faulting fail never pass test-xtf-amd64-amd64-2 34 xtf/test-hvm32pae-cpuid-faulting fail never pass test-xtf-amd64-amd64-2 41 xtf/test-hvm32pse-cpuid-faulting fail never pass test-xtf-amd64-amd64-2 45 xtf/test-hvm64-cpuid-faulting fail never pass test-xtf-amd64-amd64-4 19 xtf/test-hvm32-cpuid-faulting fail never pass test-xtf-amd64-amd64-1 19 xtf/test-hvm32-cpuid-faulting fail never pass test-xtf-amd64-amd64-5 19 xtf/test-hvm32-cpuid-faulting fail never pass test-xtf-amd64-amd64-4 34 xtf/test-hvm32pae-cpuid-faulting fail never pass test-xtf-amd64-amd64-1 34 xtf/test-hvm32pae-cpuid-faulting fail never pass test-xtf-amd64-amd64-5 34 xtf/test-hvm32pae-cpuid-faulting fail never pass test-xtf-amd64-amd64-4 41 xtf/test-hvm32pse-cpuid-faulting fail never pass test-xtf-amd64-amd64-4 45 xtf/test-hvm64-cpuid-faulting fail never pass test-xtf-amd64-amd64-1 41 xtf/test-hvm32pse-cpuid-faulting fail never pass test-xtf-amd64-amd64-5 41 xtf/test-hvm32pse-cpuid-faulting fail never pass test-xtf-amd64-amd64-1 45 xtf/test-hvm64-cpuid-faulting fail never pass test-xtf-amd64-amd64-5 45 xtf/test-hvm64-cpuid-faulting fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass test-xtf-amd64-amd64-2 59 xtf/test-hvm64-xsa-195 fail never pass test-xtf-amd64-amd64-3 59 xtf/test-hvm64-xsa-195 fail never pass test-xtf-amd64-amd64-4 59 xtf/test-hvm64-xsa-195 fail never pass test-xtf-amd64-amd64-1 59 xtf/test-hvm64-xsa-195 fail never pass test-xtf-amd64-amd64-5 59 xtf/test-hvm64-xsa-195 fail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubie
[Xen-devel] [xen-4.7-testing test] 116240: regressions - FAIL
flight 116240 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/116240/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-xsm 6 xen-build fail in 116219 REGR. vs. 115210 Tests which are failing intermittently (not blocking): test-xtf-amd64-amd64-1 49 xtf/test-hvm64-lbr-tsx-vmentry fail in 116219 pass in 116240 test-amd64-i386-qemuu-rhel6hvm-intel 12 guest-start/redhat.repeat fail in 116219 pass in 116240 test-armhf-armhf-xl-rtds 12 guest-start fail in 116219 pass in 116240 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 116219 test-amd64-amd64-xl-qemut-ws16-amd64 15 guest-saverestore.2 fail pass in 116219 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 17 guest-stopfail REGR. vs. 115210 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 115210 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked in 116219 n/a test-armhf-armhf-xl-xsm 1 build-check(1) blocked in 116219 n/a test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail in 116219 like 115210 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail in 116219 like 115210 test-xtf-amd64-amd64-5 49 xtf/test-hvm64-lbr-tsx-vmentry fail like 115189 test-xtf-amd64-amd64-4 49 xtf/test-hvm64-lbr-tsx-vmentry fail like 115189 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 115210 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 115210 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 115210 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 115210 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 115210 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 115210 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115210 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen 259a5c3000d840f244dbb30f2b47b95f2dc0f80f baseline version: xen 830224431b67fd2afad9bdc532dc1bede20032d5 Last test of basis 115210 2017-10-25 09:01:33 Z 23 days Testing same since 116219 2017-11-16 11:17:46 Z1 days2 attempts --
[Xen-devel] [xen-4.8-testing test] 116237: regressions - FAIL
flight 116237 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/116237/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 115205 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115205 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 116221 pass in 116237 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat fail pass in 116221 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail REGR. vs. 115205 Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-5 49 xtf/test-hvm64-lbr-tsx-vmentry fail in 116221 like 115205 test-xtf-amd64-amd64-4 49 xtf/test-hvm64-lbr-tsx-vmentry fail like 115185 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115185 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 115185 test-xtf-amd64-amd64-3 49 xtf/test-hvm64-lbr-tsx-vmentry fail like 115205 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 115205 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 115205 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 115205 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115205 build-i386-prev 7 xen-build/dist-test fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass build-amd64-prev 7 xen-build/dist-test fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: xen 9ba6783e47db71379c5120039b878f605bdf31f3 baseline version: xen 03af24c35ed38967ab8151fdb53da3f6f6cc0872 Last test of basis 115205 2017-10-25 06:31:45 Z 23 days Testing same since 116221 2017-11-16 11:17:40 Z1 days2 attempts People who touched revisions under test: Andrew Cooper Eric Chanudet George Dunlap Jan Beulich Min He
[Xen-devel] [libvirt test] 116248: regressions - FAIL
flight 116248 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/116248/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 115476 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 115476 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass version targeted for testing: libvirt 2dd70901db8b7fd62592b1332370148e97062431 baseline version: libvirt 1bf893406637e852daeaafec6617d3ee3716de25 Last test of basis 115476 2017-11-02 04:22:37 Z 15 days Failing since115509 2017-11-03 04:20:26 Z 14 days 14 attempts Testing same since 116248 2017-11-17 04:28:32 Z0 days1 attempts People who touched revisions under test: Andrea Bolognani Chen Hanxiao Christian Ehrhardt Daniel Veillard Dawid Zamirski Erik Skultety Jim Fehlig Jiri Denemark John Ferlan Julio Faracco Michal Privoznik Nikolay Shirokovskiy Pavel Hrdina Peter Krempa Pino Toscano Viktor Mihajlovski Wim ten Have xinhua.Cao 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 fail build-i386-libvirt fail 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-xsmblocked test-amd64-amd64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair blocked test-amd64-i386-libvirt-qcow2blocked test-armhf-armhf-libvirt-raw blocked test-amd64-amd64-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1767 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [linux-linus bisection] complete test-amd64-i386-freebsd10-amd64
branch xen-unstable xenbranch xen-unstable job test-amd64-i386-freebsd10-amd64 testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Bug introduced: e60e1ee60630cafef5e430c2ae364877e061d980 Bug not present: 3a99df9a3d14cd866b5516f8cba515a3bfd554ab Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/116288/ (Revision log too long, omitted.) For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-i386-freebsd10-amd64.xen-boot.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-freebsd10-amd64.xen-boot --summary-out=tmp/116288.bisection-summary --basis-template=115643 --blessings=real,real-bisect linux-linus test-amd64-i386-freebsd10-amd64 xen-boot Searching for failure / basis pass: 116226 fail [host=pinot1] / 116182 [host=baroque1] 116164 [host=fiano0] 116152 [host=fiano1] 116136 [host=elbling0] 116119 [host=nobling0] 116103 [host=rimava1] 115718 [host=pinot0] 115690 [host=nocera0] 115678 [host=chardonnay0] 115643 [host=huxelrebe1] 115628 [host=chardonnay1] 115615 [host=nocera1] 115599 [host=rimava0] 115573 [host=merlot0] 115543 [host=italia1] 115487 [host=nobling1] 115475 ok. Failure / basis pass flights: 116226 / 115475 (tree with no url: minios) (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest e60e1ee60630cafef5e430c2ae364877e061d980 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 b79708a8ed1b3d18bee67baeaf33b3fa529493e2 b9ee1fd7b98064cf27d0f8f1adf1f5359b72c97f Basis pass 3a99df9a3d14cd866b5516f8cba515a3bfd554ab c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 5cd7ce5dde3f228b3b669ed9ca432f588947bd40 24fb44e971a62b345c7b6ca3c03b454a1e150abe Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#3a99df9a3d14cd866b5516f8cba515a3bfd554ab-e60e1ee60630cafef5e430c2ae364877e061d980 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-c8ea0457495342c417c3dc033bba25148b279f60 git://xenbits.xen.org/qemu-xen.git#5cd7ce5dde3f228b3b669ed9ca432f588947bd40-b79708a8ed1b3d18bee67baeaf33b3fa529493e2 git://xenbits.xen.org/xen.git#24fb44e971a62b345c7b6ca3c03b454a1e150abe-b9ee1fd7b98064cf27d0f8f1adf1f5359b72c97f From git://cache:9419/git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 a3841f9..b04a234 master -> origin/master adhoc-revtuple-generator: tree discontiguous: linux-2.6 Loaded 2006 nodes in revision graph Searching for test results: 114643 [host=baroque1] 114658 [host=huxelrebe0] 114781 [host=elbling1] 114682 [host=merlot1] 114820 [host=italia1] 114883 [host=nobling0] 115009 pass irrelevant 115121 [host=nocera1] 115153 [host=baroque0] 115182 [host=nobling1] 115203 [host=huxelrebe1] 115244 [host=nocera0] 115279 [host=rimava0] 115321 [host=rimava1] 115302 [host=chardonnay1] 115338 [host=fiano0] 115353 [host=elbling0] 115387 [host=italia0] 115373 [host=chardonnay0] 115469 [host=nobling0] 115414 [host=fiano1] 115459 [host=baroque1] 115438 [host=huxelrebe0] 115475 pass 3a99df9a3d14cd866b5516f8cba515a3bfd554ab c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 5cd7ce5dde3f228b3b669ed9ca432f588947bd40 24fb44e971a62b345c7b6ca3c03b454a1e150abe 115487 [host=nobling1] 115599 [host=rimava0] 115543 [host=italia1] 115573 [host=merlot0] 115615 [host=nocera1] 115628 [host=chardonnay1] 115643 [host=huxelrebe1] 115678 [host=chardonnay0] 115690 [host=nocera0] 115718 [host=pinot0] 116103 [host=rimava1] 116152 [host=fiano1] 116119 [host=nobling0] 116136 [host=elbling0] 116164 [host=fiano0] 116182 [host=baroque1] 116215 fail irrelevant 116281 pass 3a99df9a3d14cd866b5516f8cba515a3bfd554ab c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 b79708a8ed1b3d18bee67baeaf33b3fa529493e2 b9ee1fd7b98064cf27d0f8f1adf1f5359b72c97f 116225 pass 3a99df
Re: [Xen-devel] [PATCH 10/13] x86/alternative: Support indirect call replacement
On 10/04/17 08:58, Josh Poimboeuf wrote: > Add alternative patching support for replacing an instruction with an > indirect call. This will be needed for the paravirt alternatives. I have a patchset that generalizes the alternatives in what I think is a more robust way. I really, really want to get rid of these hacks. Let me clean it up an post it... -hpa ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 03/13] x86/paravirt: Convert native patch assembly code strings to macros
On Fri, Nov 17, 2017 at 08:10:13PM +0100, Juergen Gross wrote: > On 17/11/17 19:07, Borislav Petkov wrote: > > On Wed, Oct 04, 2017 at 10:58:24AM -0500, Josh Poimboeuf wrote: > >> Convert the hard-coded native patch assembly code strings to macros to > >> facilitate sharing common code between 32-bit and 64-bit. > >> > >> These macros will also be used by a future patch which requires the GCC > >> extended asm syntax of two '%' characters instead of one when specifying > >> a register name. > >> > >> Signed-off-by: Josh Poimboeuf > >> --- > >> arch/x86/include/asm/special_insns.h | 24 > >> arch/x86/kernel/paravirt_patch_32.c | 21 +++-- > >> arch/x86/kernel/paravirt_patch_64.c | 29 +++-- > >> 3 files changed, 50 insertions(+), 24 deletions(-) > >> > >> diff --git a/arch/x86/include/asm/special_insns.h > >> b/arch/x86/include/asm/special_insns.h > >> index ac402c6fc24b..0549c5f2c1b3 100644 > >> --- a/arch/x86/include/asm/special_insns.h > >> +++ b/arch/x86/include/asm/special_insns.h > >> @@ -6,6 +6,30 @@ > >> > >> #include > >> > >> +#ifdef CONFIG_X86_64 > >> +# define _REG_ARG1"%rdi" > >> +# define NATIVE_IDENTITY_32 "mov %edi, %eax" > > > > Yeah, that "identity" looks strange. How about NATIVE_NOOP and > > NATIVE_NOOP_32 ? > > Those are not NOPs. They return the identical value which was passed to > them. So identity isn't a bad name after all. Right, like the math identity function: https://en.wikipedia.org/wiki/Identity_function > >> +# define NATIVE_USERGS_SYSRET64 "swapgs; sysretq" > >> +#else > >> +# define _REG_ARG1"%eax" > >> +#endif > >> + > >> +#define _REG_RET "%" _ASM_AX > >> + > >> +#define NATIVE_ZERO "xor " _REG_ARG1 ", " _REG_ARG1 > > > > NATIVE_ZERO_OUT > > > > I guess. NATIVE_ZERO reads like the native representation of 0 :-) > > NATIVE_ZERO_ARG1? On a slight tangent, does anybody know why it zeros the arg? The only place it's used is here: #if defined(CONFIG_PARAVIRT_SPINLOCKS) DEF_NATIVE(pv_lock_ops, queued_spin_unlock, NATIVE_QUEUED_SPIN_UNLOCK); DEF_NATIVE(pv_lock_ops, vcpu_is_preempted, NATIVE_ZERO); #endif Isn't that a bug? Seems like it should _return_ zero. Zeroing the arg shouldn't have any effect. If I'm right, we could call it NATIVE_FALSE. -- Josh ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Unable to create guest PV domain on OMAP5432
Hello, On 15 November 2017 at 11:34, Jayadev Kumaran wrote: >>> What defconfig are you based on? Do you have a device-tree support >>> enabled? > I use omap2plus_defconfig . Yes , device tree support is there and the dts > file used is omap5-uevm.dts Some options in omap2plus_defconfig might upset the kernel such as CONFIG_ARM_APPENDED_DTB. > >>> But it did not get a command line to setup console on hvc0, or the kernel >>> crashed in earliest stages. > > Is there a way to debug which one of the above two possibilities has lead to > the issue ? As I'm using the dom0 kernel image for my guest, is it still > possible that it could be a kernel crash since it has already booted up for > dom0. From a previous e-mail I see you are using 3.15. Is there any particular reason to not use at least a stable kernel if not a new one? Cheers, ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 03/13] x86/paravirt: Convert native patch assembly code strings to macros
On 17/11/17 19:07, Borislav Petkov wrote: > On Wed, Oct 04, 2017 at 10:58:24AM -0500, Josh Poimboeuf wrote: >> Convert the hard-coded native patch assembly code strings to macros to >> facilitate sharing common code between 32-bit and 64-bit. >> >> These macros will also be used by a future patch which requires the GCC >> extended asm syntax of two '%' characters instead of one when specifying >> a register name. >> >> Signed-off-by: Josh Poimboeuf >> --- >> arch/x86/include/asm/special_insns.h | 24 >> arch/x86/kernel/paravirt_patch_32.c | 21 +++-- >> arch/x86/kernel/paravirt_patch_64.c | 29 +++-- >> 3 files changed, 50 insertions(+), 24 deletions(-) >> >> diff --git a/arch/x86/include/asm/special_insns.h >> b/arch/x86/include/asm/special_insns.h >> index ac402c6fc24b..0549c5f2c1b3 100644 >> --- a/arch/x86/include/asm/special_insns.h >> +++ b/arch/x86/include/asm/special_insns.h >> @@ -6,6 +6,30 @@ >> >> #include >> >> +#ifdef CONFIG_X86_64 >> +# define _REG_ARG1 "%rdi" >> +# define NATIVE_IDENTITY_32 "mov %edi, %eax" > > Yeah, that "identity" looks strange. How about NATIVE_NOOP and > NATIVE_NOOP_32 ? Those are not NOPs. They return the identical value which was passed to them. So identity isn't a bad name after all. > >> +# define NATIVE_USERGS_SYSRET64 "swapgs; sysretq" >> +#else >> +# define _REG_ARG1 "%eax" >> +#endif >> + >> +#define _REG_RET"%" _ASM_AX >> + >> +#define NATIVE_ZERO "xor " _REG_ARG1 ", " _REG_ARG1 > > NATIVE_ZERO_OUT > > I guess. NATIVE_ZERO reads like the native representation of 0 :-) NATIVE_ZERO_ARG1? Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Unable to create guest PV domain on OMAP5432
On 17 November 2017 at 12:15, Volodymyr Babchuk wrote: > Hi Jayadev, > > On 17 November 2017 at 13:53, Andrii Anisov wrote: >>> >>> Is there a way to debug which one of the above two possibilities has lead >>> to the issue ? >> >> Four years ago I did it in a following way: >> - wire up to UART2 pins on an expansion connector (this sheet might be >> useful for you: http://www.ti.com/lit/ug/swcu130/swcu130.pdf) >> - assign UART2 IOMEM ranges to DomU >> - enable in domu kernel earlyprintk and patch it to output to omap UART2 >> >> Nowadays assigning UART2 IOMEM ranges might be a bit more complex due to XEN >> evolution. >> >> Another way is to use JTAG which understands virtualization, and allows you >> to debug DomU. > I want to add some debugging techniques: > - By tapping CTRL+A three times to switch to XEN console. Then `d` > will show you CPU register states. You will be able to see where your > DomU executes right now. This can help along with addr2line, objdump > and other tools. > > - You can modify traps.c in XEN to crash domain when SMC instruction > is trapped. Then you can put SMC invocation into various parts of > kernel code, to see if it reaches that place. This can help on early > stages, when console is not available. No need for modifying the Xen. Xen already provides debug facilities when CONFIG_DEBUG=y. You can have a look at do_debug_trap. The ones you likely want are: - hvc 0x will show the state of the vCPU - hvc 0xfffe will print the PC Cheers, ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Unable to create guest PV domain on OMAP5432
On 8 November 2017 at 14:52, Konrad Rzeszutek Wilk wrote: > On Wed, Nov 08, 2017 at 10:47:20AM +0530, Jayadev Kumaran wrote: >> Hello all, >> >> I'm trying to implement Xen hypervisor support on OMAP5432.I have followed >> the steps as in >> https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/OMAP5432_uEVM >> for the initial setup. I'm able to see the domain 0 successfully up. >> >> >> >> >> >> >> >> *root@omap5-evm:~# /etc/init.d/xencommons startStarting >> /usr/local/sbin/xenstored...Setting domain 0 name, domid and JSON >> config...Done setting up Dom0Starting xenconsoled...Starting QEMU as disk >> backend for dom0* >> >> >> >> *root@omap5-evm:~# xl listNameID >> Mem VCPUs State Time(s)Domain-0 >> 0 512 2 r- 11.5* > > What does 'xl info' say? B/c: > .. >> Expanding d4 grant table from 0 to 1 frames(XEN) memory.c:238:d0v0 Could >> not allocate order=18 extent: id=4 memflags=0xc0 (0 of 1)libxl: error: > > .. looks like it could not allocate memory? This message is not important. The toolstack will always try to use very big mapping first and then scale down if it is not possible to allocate. In this case, the platform does not have 1G contiguous, and will fallback to 2M mapping. Cheers, ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH 00/31] CPUFreq on ARM
On Fri, Nov 17, 2017 at 4:01 PM, Julien Grall wrote: > Hi, Hi, Julien. > > First of all, thank you Oleksandr for starting a thread around CPUFreq > support. Thank you for the valued comments. > > On 11/16/2017 05:04 PM, Andre Przywara wrote: >> >> On 16/11/17 14:57, Oleksandr Tyshchenko wrote: >>> >>> On Wed, Nov 15, 2017 at 4:28 PM, Andre Przywara >>> wrote: >>> Anyway, I think we should go step-by-step. >>> If community agreed that CPUFreq feature in Xen on ARM was needed and >>> SCPI/SCMI based approach >>> was the right thing to do in general I would stick to next taking into >>> the account Andre's suggestions >>> regarding some guest input: >>> >>> 1. Xen do have CPUFreq logic. It measures CPUs utilization by itself. >>> 2. In addition it can collect OPP change requests from the guests: >>>- There are some politics describing which guest is allowed to send >>> OPP change request. >>>- Of course, involved guests have CPUFreq enabled. All we need is >>> these OPP change requests don't lead to >>> any physical changes and be picked up by Xen. Here we could use >>> Andre's idea here (SCPI CPUFreq + SMC mailbox with hvc method). >>> 3. Xen makes a decision based on the whole system status it measures >>> periodically and guests input (OPP change requests) if present. >>> 4. Xen actually issues command to change the CPU frequency (sends OPP >>> change request to SCP). >>> >>> How does it sound? >> >> >> 0. Decide whether CPUFreq justifies 1.-4. in the first place. That >> sounds like a lot of work and code, so we should be sure it's worth it. >> >> I wonder if you could provide some input, ideally measurements on the >> actual power savings CPUFreq provides. >> >> Does the wish to have CPUFreq purely come from some "tick-the-box" >> exercise? As in: We have it on native Linux, so we need it in Xen? >> >> What power savings can we expect from CPUFreq? Can those possible >> savings be transferred into a virtualized environment at all? And do >> those saving justify all the extra code in Xen? >> >> I think those questions need to be answered first, then we can discuss >> about the implementation details. > > > I am going to throw a bit more ideas. From the discussion, it look like to > me the story is around power saving when using Xen. Am I right? Yes. > > Have you explored some other possibility to save power? I am asking that, > because the topic is fairly new with Xen. As for me, no, I haven't. > > Once area where power could be saved is the idle loop (see idle_loop in > arch/arm/domain.c). At the momment only WFI is used. It would be possible to > go in deeper low-power state by using PSCI. > > Similarly, the virtual PSCI implementation for suspend is quite simple. You > could potentially use those information to decide what to do with the pCPU > (suspend, turning off...). Is vPSCI implementation already present? If so, could you point me some pointers to look at? > > Cheers, > > -- > Julien Grall What I was thinking too is "boot time". For example, there is strict boot time requirement for some embedded/industrial system powered by Xen hypervisor. So the whole system should up and running as soon as possible. Together with other boot time optimization techniques the CPU boost feature (if present) can help here. Usually firmware sets some initial frequency (possibly nominal frequency, possibly, the highest frequency, I am not really sure, what "boot" frequencies are across other ARM SoCs), which is used until CPUFreq comes into play. And If we don't have CPUFreq in system, we can't set the highest(or even turbo) frequency in firmware (or in Xen before starting dom0) to speed up booting. Because there is nothing is the system who will scale the CPU frequency down then, and it is may be "not safe" from the silicon viewpoint as well as "not optimal" from the power consumption viewpoint to run at such high frequency "all the time". -- Regards, Oleksandr Tyshchenko ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 03/13] x86/paravirt: Convert native patch assembly code strings to macros
On Wed, Oct 04, 2017 at 10:58:24AM -0500, Josh Poimboeuf wrote: > Convert the hard-coded native patch assembly code strings to macros to > facilitate sharing common code between 32-bit and 64-bit. > > These macros will also be used by a future patch which requires the GCC > extended asm syntax of two '%' characters instead of one when specifying > a register name. > > Signed-off-by: Josh Poimboeuf > --- > arch/x86/include/asm/special_insns.h | 24 > arch/x86/kernel/paravirt_patch_32.c | 21 +++-- > arch/x86/kernel/paravirt_patch_64.c | 29 +++-- > 3 files changed, 50 insertions(+), 24 deletions(-) > > diff --git a/arch/x86/include/asm/special_insns.h > b/arch/x86/include/asm/special_insns.h > index ac402c6fc24b..0549c5f2c1b3 100644 > --- a/arch/x86/include/asm/special_insns.h > +++ b/arch/x86/include/asm/special_insns.h > @@ -6,6 +6,30 @@ > > #include > > +#ifdef CONFIG_X86_64 > +# define _REG_ARG1 "%rdi" > +# define NATIVE_IDENTITY_32 "mov %edi, %eax" Yeah, that "identity" looks strange. How about NATIVE_NOOP and NATIVE_NOOP_32 ? > +# define NATIVE_USERGS_SYSRET64 "swapgs; sysretq" > +#else > +# define _REG_ARG1 "%eax" > +#endif > + > +#define _REG_RET "%" _ASM_AX > + > +#define NATIVE_ZERO "xor " _REG_ARG1 ", " _REG_ARG1 NATIVE_ZERO_OUT I guess. NATIVE_ZERO reads like the native representation of 0 :-) ... -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [libvirt test] 116216: regressions - FAIL
On 11/16/2017 11:51 AM, Julien Grall wrote: Hi all, On 16 November 2017 at 09:40, osstest service owner wrote: flight 116216 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/116216/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 115476 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 115476 This is failing with: xenconfig/xen_xl.c: In function 'xenFormatXLVnuma': xenconfig/xen_xl.c:1264:5: error: format '%ld' expects argument of type 'long int', but argument 3 has type 'size_t' [-Werror=format=] virBufferAsprintf(&buf, "pnode=%ld", node); ^ xenconfig/xen_xl.c:1268:5: error: format '%ld' expects argument of type 'long int', but argument 3 has type 'size_t' [-Werror=format=] virBufferAsprintf(&buf, "size=%ld", nodeSize); ^ cc1: all warnings being treated as errors I think this was introduced with 03d0959af "xenconfig: add domxml conversions for xen-xl". Thanks. I've pushed a patch to fix this https://libvirt.org/git/?p=libvirt.git;a=commit;h=ce3b585bc4cec7db88da010651fe9fad15bf7173 Regards, Jim ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-4.9-testing test] 116234: tolerable FAIL - PUSHED
flight 116234 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/116234/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail in 116220 pass in 116234 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 116220 pass in 116234 test-armhf-armhf-xl-arndale 6 xen-installfail pass in 116220 test-amd64-i386-xl-qemuu-ws16-amd64 15 guest-saverestore.2 fail pass in 116220 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail pass in 116220 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail pass in 116220 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail in 116220 like 115186 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail in 116220 like 115206 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 116220 like 115206 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail in 116220 like 115206 test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 116220 never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 116220 never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 115186 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115186 test-amd64-amd64-xl-qemuu-ws16-amd64 14 guest-localmigratefail like 115206 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 115206 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115206 test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail like 115206 test-amd64-amd64-xl-rtds 10 debian-install fail like 115206 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen d6ce860bbdf9dbdc88e4f2692e16776a622b2949 baseline version: xen 61b6df9d821481ba4e26e5843aa9320345077319 Last test of basis 115206 2017-10-25 06:55:19 Z 23 days Testing same since 116220 2017-11-16 11:15:57 Z1 days2 attempts People who touched revisions under test: Andrew Cooper Boris Ostrovsky David Esler Eric Chanudet George Dunlap Jan Be
Re: [Xen-devel] [xen-4.6-testing test] 116222: regressions - FAIL
On 17/11/17 17:21, Ian Jackson wrote:
> osstest service owner writes ("[xen-4.6-testing test] 116222: regressions -
> FAIL"):
>> flight 116222 xen-4.6-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/116222/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>> test-xtf-amd64-amd64-3 49 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs.
>> 115190
>> test-xtf-amd64-amd64-1 49 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs.
>> 115190
> Are these somehow expected ?
The hypervisor fix required to cause these to pass won't be backported
to 4.6.
~Andrew
> If this is a host-specific expected
> regression, then the others
>
>> test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR.
>> vs. 115190
>> test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stopfail REGR. vs.
>> 115190
> are just the known Windows problem, and this should be forced.
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-4.6-testing test] 116222: regressions - FAIL
osstest service owner writes ("[xen-4.6-testing test] 116222: regressions -
FAIL"):
> flight 116222 xen-4.6-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/116222/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-xtf-amd64-amd64-3 49 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs.
> 115190
> test-xtf-amd64-amd64-1 49 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs.
> 115190
Are these somehow expected ? If this is a host-specific expected
regression, then the others
> test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR.
> vs. 115190
> test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stopfail REGR. vs.
> 115190
are just the known Windows problem, and this should be forced.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH 00/31] CPUFreq on ARM
On Fri, Nov 17, 2017 at 6:41 PM, Andre Przywara wrote: > Hi, Hi Andre > > > >>> So Xen does not need to throw in its own ideas here. Which would avoid >>> some of the hard problems we encountered. >> I got all your point. >> Just question. Why does existing CPUFreq on x86 have own logic? Do we have >> something yet another on ARM that having own logic in Xen doesn't make >> any sense? > > That's a good question. From quickly poking some people in #xendevel, > Julien learnt that CPUFreq on x86 might not really work well or at least > not as expected. > So the benefit is not even clear there. It just went in the tree once, > and possibly nobody ever revisited it since. > And even if there were good reasons back then, modern CPUs tend to be > quite different in terms of power characteristics. Thank you for the clarification. It is clear now. > > > >>> 0. Decide whether CPUFreq justifies 1.-4. in the first place. >> Sure, >>> That sounds like a lot of work and code, so we should be sure it's worth it. >>> >>> I wonder if you could provide some input, ideally measurements on the >>> actual power savings CPUFreq provides. >> Well, I think I will be able to provide some numbers when a firmware, >> which runs on the SoC >> I am using, is ready. Actually, currently I have an emulator without >> any real freq/volt changes. > > Yes, some actual numbers would very much help the case. I don't think > you need very sophisticated equipment, just running a workload once with > and once without CPUFreq and compare the power consumption would be a > good start. This could be as easy as measuring the (m)Wh consumed with > some wall-plug type power meter. I use some very cheap USB power > meter[1], which I put between the PSU and some single board computer to > get an idea on what the power consumption is. Surely not really > reliable, but better than nothing. Thank you for the pointer. I am afraid, it is going to be a question how measure power consumption on my developing board) Most effectively would be measure a current via CPU power rail(s). I think, I could collect some statistics (Px vs time) for different use-cases using xenpm tool. Where "without CPUFReq" means just to set "userspace" governor and exactly the same frequency, on which we come from the firmware. > >>> Does the wish to have CPUFreq purely come from some "tick-the-box" >>> exercise? As in: We have it on native Linux, so we need it in Xen? >> As I said before, we are interesting in purely embedded use-cases >> where power consumption is a question. >> If you know how to save power without having CPUFreq involved I would >> appreciate the pointers. > > As Julien said, I guess idling and CPU offlining/CPU suspend (via PSCI) > would be a good start to look at. You could try to get some numbers on > this as well. Yes. > > Cheers, > Andre. > > [1] > https://www.ebay.co.uk/itm/USB-Charger-Doctor-Voltage-Current-Meter-Mobile-Battery-Tester-Power-Detector-UK/263220956905 > >>> What power savings can we expect from CPUFreq? Can those possible >>> savings be transferred into a virtualized environment at all? And do >>> those saving justify all the extra code in Xen? >>> >>> I think those questions need to be answered first, then we can discuss >>> about the implementation details. >> OK. >> -- Regards, Oleksandr Tyshchenko ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-4.8-testing test] 116221: regressions - FAIL
osstest service owner writes ("[xen-4.8-testing test] 116221: regressions -
FAIL"):
> flight 116221 xen-4.8-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/116221/
>
> Regressions :-(
...
> version targeted for testing:
> xen 9ba6783e47db71379c5120039b878f605bdf31f3
> baseline version:
> xen 03af24c35ed38967ab8151fdb53da3f6f6cc0872
Force pushed.
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs.
> 115205
> test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR.
> vs. 115205
> test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs.
> 115205
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.10] tools/libxl: mark hvm mmio area as reserved in e820 map
On 17/11/17 12:47, Juergen Gross wrote: > Make sure the HVM mmio area (especially console and Xenstore pages) is > marked as "reserved" in the guest's E820 map, as otherwise conflicts > might arise later, e.g. when hotplugging memory into the guest. > > Signed-off-by: Juergen Gross > --- > This is a bugfix for PVH and HVM guests. Please consider for 4.10. Please ignore this patch, it upsets HVMloader. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH 00/31] CPUFreq on ARM
Hi, >> So Xen does not need to throw in its own ideas here. Which would avoid >> some of the hard problems we encountered. > I got all your point. > Just question. Why does existing CPUFreq on x86 have own logic? Do we have > something yet another on ARM that having own logic in Xen doesn't make > any sense? That's a good question. From quickly poking some people in #xendevel, Julien learnt that CPUFreq on x86 might not really work well or at least not as expected. So the benefit is not even clear there. It just went in the tree once, and possibly nobody ever revisited it since. And even if there were good reasons back then, modern CPUs tend to be quite different in terms of power characteristics. >> 0. Decide whether CPUFreq justifies 1.-4. in the first place. > Sure, >> That sounds like a lot of work and code, so we should be sure it's worth it. >> >> I wonder if you could provide some input, ideally measurements on the >> actual power savings CPUFreq provides. > Well, I think I will be able to provide some numbers when a firmware, > which runs on the SoC > I am using, is ready. Actually, currently I have an emulator without > any real freq/volt changes. Yes, some actual numbers would very much help the case. I don't think you need very sophisticated equipment, just running a workload once with and once without CPUFreq and compare the power consumption would be a good start. This could be as easy as measuring the (m)Wh consumed with some wall-plug type power meter. I use some very cheap USB power meter[1], which I put between the PSU and some single board computer to get an idea on what the power consumption is. Surely not really reliable, but better than nothing. >> Does the wish to have CPUFreq purely come from some "tick-the-box" >> exercise? As in: We have it on native Linux, so we need it in Xen? > As I said before, we are interesting in purely embedded use-cases > where power consumption is a question. > If you know how to save power without having CPUFreq involved I would > appreciate the pointers. As Julien said, I guess idling and CPU offlining/CPU suspend (via PSCI) would be a good start to look at. You could try to get some numbers on this as well. Cheers, Andre. [1] https://www.ebay.co.uk/itm/USB-Charger-Doctor-Voltage-Current-Meter-Mobile-Battery-Tester-Power-Detector-UK/263220956905 >> What power savings can we expect from CPUFreq? Can those possible >> savings be transferred into a virtualized environment at all? And do >> those saving justify all the extra code in Xen? >> >> I think those questions need to be answered first, then we can discuss >> about the implementation details. > OK. > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [seabios test] 116229: regressions - FAIL
flight 116229 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/116229/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail in 116217 REGR. vs. 115539 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail in 116217 pass in 116229 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail pass in 116217 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115539 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: seabios df46d10c8a7b88eb82f3ceb2aa31782dee15593d baseline version: seabios 0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea Last test of basis 115539 2017-11-03 20:48:58 Z 13 days Failing since115733 2017-11-10 17:19:59 Z6 days 13 attempts Testing same since 116211 2017-11-16 00:20:45 Z1 days3 attempts People who touched revisions under test: Kevin O'Connor Stefan Berger 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-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-amd64-amd64-xl-qemuu-win10-i386 fail test-amd64-i386-xl-qemuu-win10-i386 fail test-amd64-amd64-qemuu-nested-intel pass test-amd64-i386-qemuu-rhel6hvm-intel 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 df46d10c8a7b88eb82f3ceb2aa31782dee15593d Author: Stefan Berger Date: Tue Nov 14 15:03:47 2017 -0500 tpm: Add support for TPM2 ACPI table Add support for the TPM2 ACPI table. If we find it and its of the appropriate size, we can get the log_area_start_address and log_area_minimum_size from it. The latest version of the spec can be found here: https://trustedcomputinggroup.org/tcg-acpi-specification/ Signed-off-by: Stefan Berger commit 0541f2f0f246e77d7c726926976920e8072d1119 Author: Kevin O'Connor Date: Fri Nov 10 12:20:35 2017 -0500 paravirt: Only enable sercon in NOGRAPHIC mode if no other console specified Signed-off-by: Kevin O'Connor commit 9ce6778f08c632c52b25bc8f754291ef18710d53 Author: Kevin O'Connor Date: Fri Nov 10 12:16:36 2017 -0500 docs: Add sercon-port to Runt
[Xen-devel] [qemu-mainline test] 116227: regressions - FAIL
flight 116227 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/116227/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 6 xen-install fail REGR. vs. 116190 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 116190 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 116190 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 116190 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 116190 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 116190 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 116190 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: qemuu8048082f7a11040a366942a2de8abb4c3d0020c9 baseline version: qemuu1fa0f627d03cd0d0755924247cafeb42969016bf Last test of basis 116190 2017-11-15 06:53:12 Z2 days Testing same since 116227 2017-11-16 13:17:17 Z1 days1 attempts People who touched revisions under test: Marc-André Lureau Peter Maydell Stefan Berger jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpas
Re: [Xen-devel] [RFC PATCH 00/31] CPUFreq on ARM
On Thu, Nov 16, 2017 at 7:04 PM, Andre Przywara wrote: > Hi, Hi Andre Thank you for your comments! > > On 16/11/17 14:57, Oleksandr Tyshchenko wrote: >> On Wed, Nov 15, 2017 at 4:28 PM, Andre Przywara >> wrote: >>> Hi, >> Hi Andre, Jassi >> >> Thank you for your comments! >> >>> >>> On 14/11/17 20:46, Oleksandr Tyshchenko wrote: On Tue, Nov 14, 2017 at 12:49 PM, Andre Przywara wrote: > Hi, Hi Andre > > On 13/11/17 19:40, Oleksandr Tyshchenko wrote: >> On Mon, Nov 13, 2017 at 5:21 PM, Andre Przywara >> wrote: >>> Hi, >> Hi Andre, >> >>> >>> thanks very much for your work on this! >> Thank you for your comments. >> >>> >>> On 09/11/17 17:09, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko Hi, all. The purpose of this RFC patch series is to add CPUFreq support to Xen on ARM. Motivation of hypervisor based CPUFreq is to enable one of the main PM use-cases in virtualized system powered by Xen hypervisor. Rationale behind this activity is that CPU virtualization is done by hypervisor and the guest OS doesn't actually know anything about physical CPUs because it is running on virtual CPUs. It is quite clear that a decision about frequency change should be taken by hypervisor as only it has information about actual CPU load. >>> >>> Can you please sketch your usage scenario or workloads here? I can think >>> of quite different scenarios (oversubscribed server vs. partitioning >>> RTOS guests, for instance). The usefulness of CPUFreq and the trade-offs >>> in the design are quite different between those. >> We keep embedded use-cases in mind. For example, it is a system with >> several domains, >> where one domain has most critical SW running on and other domain(s) >> are, let say, for entertainment purposes. >> I think, the CPUFreq is useful where power consumption is a question. > > Does the SoC you use allow different frequencies for each core? Or is it > one frequency for all cores? Most x86 CPU allow different frequencies > for each core, AFAIK. Just having the same OPP for the whole SoC might > limit the usefulness of this approach in general. Good question. All cores in a cluster share the same clock. It is impossible to set different frequencies on the cores inside one cluster. > >>> In general I doubt that a hypervisor scheduling vCPUs is in a good >>> position to make a decision on the proper frequency physical CPUs should >>> run with. From all I know it's already hard for an OS kernel to make >>> that call. So I would actually expect that guests provide some input, >>> for instance by signalling OPP change request up to the hypervisor. This >>> could then decide to act on it - or not. >> Each running guest sees only part of the picture, but hypervisor has >> the whole picture, it knows all about CPU, measures CPU load and able >> to choose required CPU frequency to run on. > > But based on what data? All Xen sees is a vCPU trapping on MMIO, a > hypercall or on WFI, for that matter. It does not know much more about > the guest, especially it's rather clueless about what the guest OS > actually intended to do. > For instance Linux can track the actual utilization of a core by keeping > statistics of runnable processes and monitoring their time slice usage. > It can see that a certain process exhibits periodical, but bursty CPU > usage, which may hint that is could run at lower frequency. Xen does not > see this fine granular information. > >> I am wondering, does Xen >> need additional input from guests for make a decision? > > I very much believe so. The guest OS is in a much better position to > make that call. > >> BTW, currently guest domain on ARM doesn't even know how many physical >> CPUs the system has and what are these OPPs. When creating guest >> domain Xen inserts only dummy CPU nodes. All CPU info, such as clocks, >> OPPs, thermal, etc are not passed to guest. > > Sure, because this is what virtualization is about. And I am not asking > for unconditionally allowing any guest to change frequency. > But there could be certain use cases where this could be considered: > Think about your "critical SW" mentioned above, which is probably some > RTOS, also possibly running on pinned vCPUs. For that > (latency-sensitive) guest it might be well suited to run at a lower > frequency for some time, but how should Xen know about this? > "Normally" the best strategy to save power is to run as fast as > possible, finish all outstanding work, then put the core to sleep. > Because not running at all consumes much less energy than running at a > reduced
Re: [Xen-devel] [PATCH 01/13] x86/paravirt: remove wbinvd() paravirt interface
On Wed, Oct 04, 2017 at 10:58:22AM -0500, Josh Poimboeuf wrote: > Since lguest was removed, only the native version of wbinvd() is used. > The paravirt interface is no longer needed. > > Signed-off-by: Josh Poimboeuf > --- > arch/x86/include/asm/paravirt.h | 5 - > arch/x86/include/asm/paravirt_types.h | 1 - > arch/x86/include/asm/special_insns.h | 7 +-- > arch/x86/kernel/paravirt.c| 1 - > arch/x86/kernel/paravirt_patch_64.c | 2 -- > arch/x86/xen/enlighten_pv.c | 2 -- > 6 files changed, 1 insertion(+), 17 deletions(-) Reviewed-by: Borislav Petkov -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [linux-linus test] 116226: regressions - FAIL
flight 116226 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/116226/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 115643 test-amd64-amd64-xl-pvhv2-amd 7 xen-bootfail REGR. vs. 115643 test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 115643 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 115643 test-amd64-i386-freebsd10-amd64 7 xen-boot fail REGR. vs. 115643 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 115643 test-amd64-amd64-xl-multivcpu 7 xen-bootfail REGR. vs. 115643 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 115643 test-amd64-i386-libvirt-qcow2 7 xen-bootfail REGR. vs. 115643 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 115643 test-amd64-amd64-xl-xsm 7 xen-boot fail REGR. vs. 115643 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-boot fail REGR. vs. 115643 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 115643 test-amd64-amd64-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 115643 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-boot fail REGR. vs. 115643 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 115643 test-armhf-armhf-libvirt-xsm 6 xen-install fail REGR. vs. 115643 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 115643 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115643 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 115643 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 115643 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 115643 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 115643 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 115643 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: linuxe60e1ee60630cafef5e430c2ae364877e061d980 baseline version: linuxe4880bc5dfb1f02b152e62a894b5c6f3e995b3cf Last test of basis 115643 2017-11-07 12:06:20 Z 10 days Failing since115658 2017-11-08 02:33:06 Z9 days 15 attempts Testing same since 116226 2017-11-16 12:48:28 Z1 days1 attempts -
Re: [Xen-devel] [RFC PATCH 00/31] CPUFreq on ARM
Hi, First of all, thank you Oleksandr for starting a thread around CPUFreq support. On 11/16/2017 05:04 PM, Andre Przywara wrote: On 16/11/17 14:57, Oleksandr Tyshchenko wrote: On Wed, Nov 15, 2017 at 4:28 PM, Andre Przywara wrote: Anyway, I think we should go step-by-step. If community agreed that CPUFreq feature in Xen on ARM was needed and SCPI/SCMI based approach was the right thing to do in general I would stick to next taking into the account Andre's suggestions regarding some guest input: 1. Xen do have CPUFreq logic. It measures CPUs utilization by itself. 2. In addition it can collect OPP change requests from the guests: - There are some politics describing which guest is allowed to send OPP change request. - Of course, involved guests have CPUFreq enabled. All we need is these OPP change requests don't lead to any physical changes and be picked up by Xen. Here we could use Andre's idea here (SCPI CPUFreq + SMC mailbox with hvc method). 3. Xen makes a decision based on the whole system status it measures periodically and guests input (OPP change requests) if present. 4. Xen actually issues command to change the CPU frequency (sends OPP change request to SCP). How does it sound? 0. Decide whether CPUFreq justifies 1.-4. in the first place. That sounds like a lot of work and code, so we should be sure it's worth it. I wonder if you could provide some input, ideally measurements on the actual power savings CPUFreq provides. Does the wish to have CPUFreq purely come from some "tick-the-box" exercise? As in: We have it on native Linux, so we need it in Xen? What power savings can we expect from CPUFreq? Can those possible savings be transferred into a virtualized environment at all? And do those saving justify all the extra code in Xen? I think those questions need to be answered first, then we can discuss about the implementation details. I am going to throw a bit more ideas. From the discussion, it look like to me the story is around power saving when using Xen. Am I right? Have you explored some other possibility to save power? I am asking that, because the topic is fairly new with Xen. Once area where power could be saved is the idle loop (see idle_loop in arch/arm/domain.c). At the momment only WFI is used. It would be possible to go in deeper low-power state by using PSCI. Similarly, the virtual PSCI implementation for suspend is quite simple. You could potentially use those information to decide what to do with the pCPU (suspend, turning off...). Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.10] tools/libxl: mark hvm mmio area as reserved in e820 map
On 17/11/17 13:26, Jan Beulich wrote: On 17.11.17 at 12:47, wrote: >> Make sure the HVM mmio area (especially console and Xenstore pages) is >> marked as "reserved" in the guest's E820 map, as otherwise conflicts >> might arise later, e.g. when hotplugging memory into the guest. > > This is very certainly wrong. Have you looked at a couple of physical > machines? Have you found an E820_RESERVED area on any of them for > the MMIO hole? Two examples I can present right away: > > <6>BIOS-e820: [mem 0xc93f-0xc9f8cfff] reserved > <6>BIOS-e820: [mem 0xc9f8d000-0xc9fdefff] ACPI data > <6>BIOS-e820: [mem 0xc9fdf000-0xcac82fff] ACPI NVS > <6>BIOS-e820: [mem 0xcac83000-0xcb172fff] reserved > <6>BIOS-e820: [mem 0xcb173000-0xcb173fff] usable > <6>BIOS-e820: [mem 0xcb174000-0xcb181fff] reserved > <6>BIOS-e820: [mem 0xcb182000-0xccff] usable > <6>BIOS-e820: [mem 0xcd00-0xcdff] reserved > <6>BIOS-e820: [mem 0xd000-0xdfff] reserved > <6>BIOS-e820: [mem 0xfed1c000-0xfed1] reserved > <6>BIOS-e820: [mem 0xff00-0x] reserved > > and > > (XEN) cf4bd000 - cf4bf000 (reserved) > (XEN) cf4bf000 - cf636000 (usable) > (XEN) cf636000 - cf7bf000 (ACPI NVS) > (XEN) cf7bf000 - cf7df000 (usable) > (XEN) cf7df000 - cf7ff000 (ACPI data) > (XEN) cf7ff000 - cf80 (usable) > (XEN) cf80 - d000 (reserved) > (XEN) f800 - fd00 (reserved) > (XEN) ffe0 - 0001 (reserved) > > Things covered by E820_RESERVED include the MCFG area, yes, but > not most other parts. The OS has to either be careful or consult > ACPI for further resource usage details. In particular, the ACPI spec > says > > "The platform boot firmware does not return a range description for > the memory mapping of PCI devices, ISA Option ROMs, and ISA Plug > and Play cards because the OS has mechanisms available to detect > them." > > See the section "E820 Assumptions and Limitations" for further details. So is it _wrong_ to return the mmio area as reserved? We at least want the shared console and Xenstore page to be marked as reserved, and those are part of the mmio area. We could, of course, just report the HVM special pages as reserved, but this would IMO be more hacky than reporting just the mmio area. Oh yes, and the LAPIC, of course. Again part of mmio area. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.10] tools/libxl: mark hvm mmio area as reserved in e820 map
>>> On 17.11.17 at 12:47, wrote: > Make sure the HVM mmio area (especially console and Xenstore pages) is > marked as "reserved" in the guest's E820 map, as otherwise conflicts > might arise later, e.g. when hotplugging memory into the guest. This is very certainly wrong. Have you looked at a couple of physical machines? Have you found an E820_RESERVED area on any of them for the MMIO hole? Two examples I can present right away: <6>BIOS-e820: [mem 0xc93f-0xc9f8cfff] reserved <6>BIOS-e820: [mem 0xc9f8d000-0xc9fdefff] ACPI data <6>BIOS-e820: [mem 0xc9fdf000-0xcac82fff] ACPI NVS <6>BIOS-e820: [mem 0xcac83000-0xcb172fff] reserved <6>BIOS-e820: [mem 0xcb173000-0xcb173fff] usable <6>BIOS-e820: [mem 0xcb174000-0xcb181fff] reserved <6>BIOS-e820: [mem 0xcb182000-0xccff] usable <6>BIOS-e820: [mem 0xcd00-0xcdff] reserved <6>BIOS-e820: [mem 0xd000-0xdfff] reserved <6>BIOS-e820: [mem 0xfed1c000-0xfed1] reserved <6>BIOS-e820: [mem 0xff00-0x] reserved and (XEN) cf4bd000 - cf4bf000 (reserved) (XEN) cf4bf000 - cf636000 (usable) (XEN) cf636000 - cf7bf000 (ACPI NVS) (XEN) cf7bf000 - cf7df000 (usable) (XEN) cf7df000 - cf7ff000 (ACPI data) (XEN) cf7ff000 - cf80 (usable) (XEN) cf80 - d000 (reserved) (XEN) f800 - fd00 (reserved) (XEN) ffe0 - 0001 (reserved) Things covered by E820_RESERVED include the MCFG area, yes, but not most other parts. The OS has to either be careful or consult ACPI for further resource usage details. In particular, the ACPI spec says "The platform boot firmware does not return a range description for the memory mapping of PCI devices, ISA Option ROMs, and ISA Plug and Play cards because the OS has mechanisms available to detect them." See the section "E820 Assumptions and Limitations" for further details. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path
On 2017-11-17 19:36, Thomas Gleixner wrote: On Fri, 17 Nov 2017, Quan Xu wrote: On 2017-11-16 17:53, Thomas Gleixner wrote: That's just plain wrong. We don't want to see any of this PARAVIRT crap in anything outside the architecture/hypervisor interfacing code which really needs it. The problem can and must be solved at the generic level in the first place to gather the data which can be used to make such decisions. How that information is used might be either completely generic or requires system specific variants. But as long as we don't have any information at all we cannot discuss that. Please sit down and write up which data needs to be considered to make decisions about probabilistic polling. Then we need to compare and contrast that with the data which is necessary to make power/idle state decisions. I would be very surprised if this data would not overlap by at least 90%. 1. which data needs to considerd to make decisions about probabilistic polling I really need to write up which data needs to considerd to make decisions about probabilistic polling. At last several months, I always focused on the data _from idle to reschedule_, then to bypass the idle loops. unfortunately, this makes me touch scheduler/idle/nohz code inevitably. with tglx's suggestion, the data which is necessary to make power/idle state decisions, is the last idle state's residency time. IIUC this data is duration from idle to wakeup, which maybe by reschedule irq or other irq. That's part of the picture, but not complete. tglx, could you share more? I am very curious about it.. I also test that the reschedule irq overlap by more than 90% (trace the need_resched status after cpuidle_idle_call), when I run ctxsw/netperf for one minute. as the overlap, I think I can input the last idle state's residency time to make decisions about probabilistic polling, as @dev->last_residency does. it is much easier to get data. That's only true for your particular use case. 2. do a HV specific idle driver (function) so far, power management is not exposed to guest.. idle is simple for KVM guest, calling "sti" / "hlt"(cpuidle_idle_call() --> default_idle_call()).. thanks Xen guys, who has implemented the paravirt framework. I can implement it as easy as following: --- a/arch/x86/kernel/kvm.c Your email client is using a very strange formatting. my bad, I insert space to highlight these code. This is definitely better than what you proposed so far and implementing it as a prove of concept seems to be worthwhile. But I doubt that this is the final solution. It's not generic and not necessarily suitable for all use case scenarios. yes, I am exhausted :):) could you tell me the gap to be generic and necessarily suitable for all use case scenarios? as lack of irq/idle predictors? I really want to upstream it for all of public cloud users/providers.. as kvm host has a similar one, is it possible to upstream with following conditions? : 1). add a QEMU configuration, whether enable or not, by default disable. 2). add some "TODO" comments near the code. 3). ... anyway, thanks for your help.. Quan Alibaba Cloud ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Unable to create guest PV domain on OMAP5432
Hi Jayadev, On 17 November 2017 at 13:53, Andrii Anisov wrote: >> >> Is there a way to debug which one of the above two possibilities has lead >> to the issue ? > > Four years ago I did it in a following way: > - wire up to UART2 pins on an expansion connector (this sheet might be > useful for you: http://www.ti.com/lit/ug/swcu130/swcu130.pdf) > - assign UART2 IOMEM ranges to DomU > - enable in domu kernel earlyprintk and patch it to output to omap UART2 > > Nowadays assigning UART2 IOMEM ranges might be a bit more complex due to XEN > evolution. > > Another way is to use JTAG which understands virtualization, and allows you > to debug DomU. I want to add some debugging techniques: - By tapping CTRL+A three times to switch to XEN console. Then `d` will show you CPU register states. You will be able to see where your DomU executes right now. This can help along with addr2line, objdump and other tools. - You can modify traps.c in XEN to crash domain when SMC instruction is trapped. Then you can put SMC invocation into various parts of kernel code, to see if it reaches that place. This can help on early stages, when console is not available. -- WBR Volodymyr Babchuk aka lorc [+380976646013] mailto: vlad.babc...@gmail.com ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.10] x86/hvm: Don't corrupt the HVM context stream when writing the MSR record
>>> On 16.11.17 at 23:45, wrote:
> Ever since it was introduced in c/s bd1f0b45ff, hvm_save_cpu_msrs() has had a
> bug whereby it corrupts the HVM context stream if some, but fewer than the
> maximum number of MSRs are written.
>
> _hvm_init_entry() creates an hvm_save_descriptor with length for
> msr_count_max, but in the case that we write fewer than max, h->cur only moves
> forward by the amount of space used, causing the subsequent
> hvm_save_descriptor to be written within the bounds of the previous one.
>
> To resolve this, reduce the length reported by the descriptor to match the
> actual number of bytes used.
>
> A typical failure on the destination side looks like:
>
> (XEN) HVM4 restore: CPU_MSR 0
> (XEN) HVM4.0 restore: not enough data left to read 56 MSR bytes
> (XEN) HVM4 restore: failed to load entry 20/0
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1330,6 +1330,7 @@ static int hvm_save_cpu_msrs(struct domain *d,
> hvm_domain_context_t *h)
>
> for_each_vcpu ( d, v )
> {
> +struct hvm_save_descriptor *d = _p(&h->data[h->cur]);
> struct hvm_msr *ctxt;
> unsigned int i;
>
> @@ -1348,8 +1349,13 @@ static int hvm_save_cpu_msrs(struct domain *d,
> hvm_domain_context_t *h)
> ctxt->msr[i]._rsvd = 0;
>
> if ( ctxt->count )
> +{
> +/* Rewrite length to indicate how much space we actually used. */
> +d->length = HVM_CPU_MSR_SIZE(ctxt->count);
Would of course be nice if we had a function to do this, such that
the (sufficiently hidden) cast above also wouldn't be necessary to
open code in places like this one.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.10] tools/libxc: Fix restoration of PV MSRs after migrate
>>> On 16.11.17 at 22:13, wrote: > There are two bugs in process_vcpu_msrs() which clearly demonstrate that I > didn't test this bit of Migration v2 very well when writing it... > > vcpu->msrsz is always expected to be a multiple of xen_domctl_vcpu_msr_t > records in a spec-compliant stream, so the modulo yields 0 for the msr_count, > rather than the actual number sent in the stream. > > Passing 0 for the msr_count causes the hypercall to exit early, and hides the > fact that the guest handle is inserted into the wrong field in the domctl > union. Oops. > The reason that these bugs have gone unnoticed for so long is that the only > MSRs passed like this for PV guests are the AMD DBGEXT MSRs, which only exist > in fairly modern hardware, and whose use doesn't appear to be implemented in > any contemporary PV guests. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.10] x86/hvm: Don't ignore unknown MSRs in the migration stream
>>> On 16.11.17 at 20:15, wrote:
> Doing so amounts to silent state corruption, and must be avoided.
I think a little more explanation is needed on why the current code
is insufficient. Note specifically this
for ( i = 0; !err && i < ctxt->count; ++i )
{
switch ( ctxt->msr[i].index )
{
default:
if ( !ctxt->msr[i]._rsvd )
err = -ENXIO;
break;
}
}
in hvm_load_cpu_msrs(), intended to give vendor code a first
shot, but allowing for vendor independent MSRs to be handled
here.
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -450,7 +450,7 @@ static int svm_load_msr(struct vcpu *v, struct hvm_msr
> *ctxt)
> break;
>
> default:
> -continue;
> +err = -ENXIO;
> }
If the change was nevertheless needed, please add break
statements here (and in VMX code as well), despite this
currently being the last label in the switch() block.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Unable to create guest PV domain on OMAP5432
Hello Jayadev, On 15.11.17 13:34, Jayadev Kumaran wrote: Hello Andrii, >> What defconfig are you based on? Do you have a device-tree support enabled? I use /omap2plus_defconfig/ . Yes , device tree support is there and the dts file used is /omap5-uevm.dts >> /But it did not get a command line to setup console on hvc0, or the kernel crashed in earliest stages. Is there a way to debug which one of the above two possibilities has lead to the issue ? Four years ago I did it in a following way: - wire up to UART2 pins on an expansion connector (this sheet might be useful for you: http://www.ti.com/lit/ug/swcu130/swcu130.pdf) - assign UART2 IOMEM ranges to DomU - enable in domu kernel earlyprintk and patch it to output to omap UART2 Nowadays assigning UART2 IOMEM ranges might be a bit more complex due to XEN evolution. Another way is to use JTAG which understands virtualization, and allows you to debug DomU. -- *Andrii Anisov* ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.10] tools/libxl: mark hvm mmio area as reserved in e820 map
On Fri, Nov 17, 2017 at 12:47:33PM +0100, Juergen Gross wrote: > Make sure the HVM mmio area (especially console and Xenstore pages) is > marked as "reserved" in the guest's E820 map, as otherwise conflicts > might arise later, e.g. when hotplugging memory into the guest. > > Signed-off-by: Juergen Gross Acked-by: Wei Liu > --- > This is a bugfix for PVH and HVM guests. Please consider for 4.10. I agree this is 4.10 material. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH for-4.10] tools/libxl: mark hvm mmio area as reserved in e820 map
Make sure the HVM mmio area (especially console and Xenstore pages) is
marked as "reserved" in the guest's E820 map, as otherwise conflicts
might arise later, e.g. when hotplugging memory into the guest.
Signed-off-by: Juergen Gross
---
This is a bugfix for PVH and HVM guests. Please consider for 4.10.
---
tools/libxl/libxl_x86.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 5f91fe4f92..664bf8bd64 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -530,6 +530,9 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
if (d_config->rdms[i].policy != LIBXL_RDM_RESERVE_POLICY_INVALID)
e820_entries++;
+/* Add mmio entry. */
+if (dom->mmio_size)
+e820_entries++;
/* If we should have a highmem range. */
if (highmem_size)
@@ -564,6 +567,14 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
nr++;
}
+/* mmio area */
+if (dom->mmio_size) {
+e820[nr].addr = dom->mmio_start;
+e820[nr].size = dom->mmio_size;
+e820[nr].type = E820_RESERVED;
+nr++;
+}
+
for (i = 0; i < MAX_ACPI_MODULES; i++) {
if (dom->acpi_modules[i].length) {
e820[nr].addr = dom->acpi_modules[i].guest_addr_out & ~(page_size
- 1);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path
On Fri, 17 Nov 2017, Quan Xu wrote:
> On 2017-11-16 17:53, Thomas Gleixner wrote:
> > That's just plain wrong. We don't want to see any of this PARAVIRT crap in
> > anything outside the architecture/hypervisor interfacing code which really
> > needs it.
> >
> > The problem can and must be solved at the generic level in the first place
> > to gather the data which can be used to make such decisions.
> >
> > How that information is used might be either completely generic or requires
> > system specific variants. But as long as we don't have any information at
> > all we cannot discuss that.
> >
> > Please sit down and write up which data needs to be considered to make
> > decisions about probabilistic polling. Then we need to compare and contrast
> > that with the data which is necessary to make power/idle state decisions.
> >
> > I would be very surprised if this data would not overlap by at least 90%.
> >
> 1. which data needs to considerd to make decisions about probabilistic polling
>
> I really need to write up which data needs to considerd to make
> decisions about probabilistic polling. At last several months,
> I always focused on the data _from idle to reschedule_, then to bypass
> the idle loops. unfortunately, this makes me touch scheduler/idle/nohz
> code inevitably.
>
> with tglx's suggestion, the data which is necessary to make power/idle
> state decisions, is the last idle state's residency time. IIUC this data
> is duration from idle to wakeup, which maybe by reschedule irq or other irq.
That's part of the picture, but not complete.
> I also test that the reschedule irq overlap by more than 90% (trace the
> need_resched status after cpuidle_idle_call), when I run ctxsw/netperf for
> one minute.
>
> as the overlap, I think I can input the last idle state's residency time
> to make decisions about probabilistic polling, as @dev->last_residency does.
> it is much easier to get data.
That's only true for your particular use case.
>
> 2. do a HV specific idle driver (function)
>
> so far, power management is not exposed to guest.. idle is simple for KVM
> guest,
> calling "sti" / "hlt"(cpuidle_idle_call() --> default_idle_call())..
> thanks Xen guys, who has implemented the paravirt framework. I can implement
> it
> as easy as following:
>
> --- a/arch/x86/kernel/kvm.c
Your email client is using a very strange formatting.
> +++ b/arch/x86/kernel/kvm.c
> @@ -465,6 +465,12 @@ static void __init kvm_apf_trap_init(void)
> update_intr_gate(X86_TRAP_PF, async_page_fault);
> }
>
> +static __cpuidle void kvm_safe_halt(void)
> +{
> + /* 1. POLL, if need_resched() --> return */
> +
> + asm volatile("sti; hlt": : :"memory"); /* 2. halt */
> +
> + /* 3. get the last idle state's residency time */
> +
> + /* 4. update poll duration based on last idle state's
> residency time */
> +}
> +
> void __init kvm_guest_init(void)
> {
> int i;
> @@ -490,6 +496,8 @@ void __init kvm_guest_init(void)
> if (kvmclock_vsyscall)
> kvm_setup_vsyscall_timeinfo();
>
> + pv_irq_ops.safe_halt = kvm_safe_halt;
> +
> #ifdef CONFIG_SMP
>
>
> then, I am no need to introduce a new pvops, and never modify
> schedule/idle/nohz code again.
> also I can narrow all of the code down in arch/x86/kernel/kvm.c.
>
> If this is in the right direction, I will send a new patch set next week..
This is definitely better than what you proposed so far and implementing it
as a prove of concept seems to be worthwhile.
But I doubt that this is the final solution. It's not generic and not
necessarily suitable for all use case scenarios.
Thanks,
tglx___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path
On 2017-11-16 17:53, Thomas Gleixner wrote:
On Thu, 16 Nov 2017, Quan Xu wrote:
On 2017-11-16 06:03, Thomas Gleixner wrote:
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -210,6 +210,13 @@ int cpuidle_enter_state(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
target_state = &drv->states[index];
}
+#ifdef CONFIG_PARAVIRT
+ paravirt_idle_poll();
+
+ if (need_resched())
+ return -EBUSY;
+#endif
That's just plain wrong. We don't want to see any of this PARAVIRT crap in
anything outside the architecture/hypervisor interfacing code which really
needs it.
The problem can and must be solved at the generic level in the first place
to gather the data which can be used to make such decisions.
How that information is used might be either completely generic or requires
system specific variants. But as long as we don't have any information at
all we cannot discuss that.
Please sit down and write up which data needs to be considered to make
decisions about probabilistic polling. Then we need to compare and contrast
that with the data which is necessary to make power/idle state decisions.
I would be very surprised if this data would not overlap by at least 90%.
Peter, tglx
Thanks for your comments..
rethink of this patch set,
1. which data needs to considerd to make decisions about probabilistic
polling
I really need to write up which data needs to considerd to make
decisions about probabilistic polling. At last several months,
I always focused on the data _from idle to reschedule_, then to bypass
the idle loops. unfortunately, this makes me touch scheduler/idle/nohz
code inevitably.
with tglx's suggestion, the data which is necessary to make power/idle
state decisions, is the last idle state's residency time. IIUC this data
is duration from idle to wakeup, which maybe by reschedule irq or other irq.
I also test that the reschedule irq overlap by more than 90% (trace the
need_resched status after cpuidle_idle_call), when I run ctxsw/netperf for
one minute.
as the overlap, I think I can input the last idle state's residency time
to make decisions about probabilistic polling, as @dev->last_residency does.
it is much easier to get data.
2. do a HV specific idle driver (function)
so far, power management is not exposed to guest.. idle is simple for
KVM guest,
calling "sti" / "hlt"(cpuidle_idle_call() --> default_idle_call())..
thanks Xen guys, who has implemented the paravirt framework. I can
implement it
as easy as following:
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -465,6 +465,12 @@ static void __init
kvm_apf_trap_init(void)
update_intr_gate(X86_TRAP_PF, async_page_fault);
}
+static __cpuidle void kvm_safe_halt(void)
+{
+ /* 1. POLL, if need_resched() --> return */
+
+ asm volatile("sti; hlt": : :"memory"); /* 2. halt */
+
+ /* 3. get the last idle state's residency time */
+
+ /* 4. update poll duration based on last idle state's
residency time */
+}
+
void __init kvm_guest_init(void)
{
int i;
@@ -490,6 +496,8 @@ void __init kvm_guest_init(void)
if (kvmclock_vsyscall)
kvm_setup_vsyscall_timeinfo();
+ pv_irq_ops.safe_halt = kvm_safe_halt;
+
#ifdef CONFIG_SMP
then, I am no need to introduce a new pvops, and never modify
schedule/idle/nohz code again.
also I can narrow all of the code down in arch/x86/kernel/kvm.c.
If this is in the right direction, I will send a new patch set next week..
thanks,
Quan
Alibaba Cloud
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.10] x86/hvm: Don't corrupt the HVM context stream when writing the MSR record
On Thu, Nov 16, 2017 at 10:45:16PM +, Andrew Cooper wrote: > Ever since it was introduced in c/s bd1f0b45ff, hvm_save_cpu_msrs() has had a > bug whereby it corrupts the HVM context stream if some, but fewer than the > maximum number of MSRs are written. > > _hvm_init_entry() creates an hvm_save_descriptor with length for > msr_count_max, but in the case that we write fewer than max, h->cur only moves > forward by the amount of space used, causing the subsequent > hvm_save_descriptor to be written within the bounds of the previous one. > > To resolve this, reduce the length reported by the descriptor to match the > actual number of bytes used. > > A typical failure on the destination side looks like: > > (XEN) HVM4 restore: CPU_MSR 0 > (XEN) HVM4.0 restore: not enough data left to read 56 MSR bytes > (XEN) HVM4 restore: failed to load entry 20/0 > > Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.10] tools/libxc: Fix restoration of PV MSRs after migrate
On Thu, Nov 16, 2017 at 09:13:22PM +, Andrew Cooper wrote: > There are two bugs in process_vcpu_msrs() which clearly demonstrate that I > didn't test this bit of Migration v2 very well when writing it... > > vcpu->msrsz is always expected to be a multiple of xen_domctl_vcpu_msr_t > records in a spec-compliant stream, so the modulo yields 0 for the msr_count, > rather than the actual number sent in the stream. > > Passing 0 for the msr_count causes the hypercall to exit early, and hides the > fact that the guest handle is inserted into the wrong field in the domctl > union. > > The reason that these bugs have gone unnoticed for so long is that the only > MSRs passed like this for PV guests are the AMD DBGEXT MSRs, which only exist > in fairly modern hardware, and whose use doesn't appear to be implemented in > any contemporary PV guests. > > Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.10] x86/hvm: Don't ignore unknown MSRs in the migration stream
On Thu, Nov 16, 2017 at 07:15:32PM +, Andrew Cooper wrote: > Doing so amounts to silent state corruption, and must be avoided. > > Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] XSA 243 v5 is missing the second patch for xen 4.8
>>> On 16.11.17 at 21:01, wrote:
> Hello,
> Looking at
> https://xenbits.xen.org/xsa/advisory-243.html,
> I cannot find the second patch for xen 4.8, xsa243-4.8-2.patch.
> The text of the advisory leads me to believe that it should be there, so
> it seems to be missing.
The text has xsa243-{4.8-1,2}.patch, which expands to
xsa243-4.8-1.patch and xsa243-2.patch.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [distros-debian-jessie test] 72458: tolerable all pass
flight 72458 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72458/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-jessie-netboot-pygrub 12 migrate-support-check fail like 72438 test-armhf-armhf-armhf-jessie-netboot-pygrub 13 saverestore-support-check fail like 72438 baseline version: flight 72438 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 pass 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
[Xen-devel] [xen-unstable test] 116224: regressions - FAIL
flight 116224 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/116224/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 116214 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 116199 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 116214 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 116214 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 116214 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 116214 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 116214 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 116214 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 116214 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 116214 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 116214 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: xen ca4b2e52a894845f26fc5b784f465e31c4cef90b baseline version: xen b9ee1fd7b98064cf27d0f8f1adf1f5359b72c97f Last test of basis 116214 2017-11-16 02:14:29 Z1 days Testing same since 116224 2017-11-16 11:51:35 Z0 days1 attempts People who touched revisions under test: Julien Grall Stefano Stabellini 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
Re: [Xen-devel] [RFC v1] ALSA: xen-front: Add Xen para-virtualized frontend driver
ping On 11/02/2017 03:11 PM, Oleksandr Andrushchenko wrote: Hi, all! Foreword This RFC is aimed to introduce support of para-virtualized sound frontend driver for Xen [1] and gather opinions from the relevant communities (ALSA, Xen). It implements the protocol from [2] with the following limitations: - mute/unmute is not supported - get/set volume is not supported Volume control is not supported for the reason that most of the use-cases (at the moment) are based on scenarios where unprivileged OS (e.g. Android, AGL etc) uses software mixers. Both capture and playback are supported. The relevant backend is implemented as a user-space application [3] and uses accompanying helper library [4]. Both frontend driver and backend were tested on real HW running Xen hypervisor (Renesas R-Car ARM based H3/M3 boards, x86). Discussion == During the first attempt to upstream the driver [5] number of comments and concerns were raised, one of the biggest flaws in the design were questioned by both Clemens Ladisch [6] and Takashi Sakamoto [7]: the absence of synchronization between frontend and backend during capture/playback. Two options were discussed: “In design of ALSA PCM core, drivers are expected to synchronize to actual hardwares for semi-realtime data transmission. The synchronization is done by two points: 1) Interrupts to respond events from actual hardwares. 2) Positions of actual data transmission in any serial sound interfaces of actual hardwares. “ and finally a change to the existing protocol was suggested: “In 'include/xen/interface/io/sndif.h', there's no functionalities I described the above: 1. notifications from DomU to Dom0 about the size of period for interrupts from actual hardwares. Or no way from Dom0 to DomU about the configured size of the period. 2. notifications of the interrupts from actual hardwares to DomU.” This is implemented as a change to the sndif protocol [8] and allows removing period emulation: 1. Introduced a new event channel from back to front 2. New event with number of bytes played/captured (XENSND_EVT_CUR_POS, to be used for sending snd_pcm_period_elapsed at frontend (in Linux implementation). Sent in bytes, not frames to make the protocol generic and consistent) 3. New request for playback/capture control (XENSND_OP_TRIGGER) with start/pause/stop/resume sub-ops. Along with these changes other comments on the driver were addressed, e.g. split into smaller chunks, moved the driver from misc to xen etc. Hope, this helps to get the full picture of what was discussed and makes it possible to move forward. Waiting for your valuable comments, Thank you, Oleksandr [1] https://github.com/andr2000/linux/commits/snd_upstream_v1 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/xen/interface/io/sndif.h [3] https://github.com/xen-troops/snd_be [4] https://github.com/xen-troops/libxenbe [5] https://lkml.org/lkml/2017/8/7/363 [6] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123617.html [7] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123744.html [8] https://github.com/andr2000/linux/commit/095d7feae00bf00c852c67c4f1044de5601678ed ___ 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
