[Xen-devel] [xen-4.4-testing test] 86050: regressions - trouble: blocked/broken/fail/pass
flight 86050 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/86050/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 16 guest-start.2fail REGR. vs. 85031 Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-qcow2 3 host-install(3) broken pass in 85990 test-amd64-amd64-xl-qemuu-win7-amd64 9 windows-install fail in 85990 pass in 86050 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail pass in 85990 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 85031 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 85031 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 85031 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail like 85031 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 9 debian-di-install fail in 85990 never pass build-amd64-rumpuserxen 6 xen-buildfail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass build-i386-rumpuserxen6 xen-buildfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 11 guest-start fail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass version targeted for testing: xen 0ae1e719118d8aa6754b19fb388038632fa768b3 baseline version: xen 83c5e46c5d6af7adc4bc46cf41e415e34846c719 Last test of basis85031 2016-03-02 06:38:02 Z 10 days Testing same since85888 2016-03-10 07:45:07 Z2 days3 attempts People who touched revisions under test: Konrad Rzeszutek Wilk jobs: build-amd64-xend pass build-i386-xend 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 build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd
[Xen-devel] [linux-linus test] 86047: regressions - FAIL
flight 86047 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/86047/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254 build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 59254 test-amd64-amd64-xl-credit2 15 guest-localmigratefail REGR. vs. 59254 test-amd64-amd64-xl-xsm 15 guest-localmigratefail REGR. vs. 59254 test-amd64-i386-xl 14 guest-saverestore fail REGR. vs. 59254 test-amd64-amd64-xl 14 guest-saverestore fail REGR. vs. 59254 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate fail REGR. vs. 59254 test-amd64-i386-xl-xsm 15 guest-localmigratefail REGR. vs. 59254 test-amd64-amd64-pair 22 guest-migrate/dst_host/src_host fail REGR. vs. 59254 test-amd64-i386-pair 22 guest-migrate/dst_host/src_host fail REGR. vs. 59254 test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-cubietruck 6 xen-bootfail REGR. vs. 59254 test-armhf-armhf-xl-multivcpu 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-xsm 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 59254 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 17 guest-localmigrate/x10fail REGR. vs. 59254 test-armhf-armhf-xl-rtds 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline untested test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline untested test-armhf-armhf-xl-vhd 6 xen-bootfail baseline untested test-amd64-i386-libvirt-xsm 14 guest-saverestorefail blocked in 59254 test-amd64-amd64-libvirt 15 guest-saverestore.2 fail blocked in 59254 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2 fail blocked in 59254 test-amd64-i386-libvirt 15 guest-saverestore.2 fail blocked in 59254 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 59254 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass version targeted for testing: linux03c668a93187fe7fba9464f96fbe7c22eebd9897 baseline version: linux45820c294fe1b1a9df495d57f40585ef2d069a39 Last test of basis59254 2015-07-09 04:20:48 Z 248 days Failing since 59348 2015-07-10 04:24:05 Z 247 days 175 attempts Testing same since86047 2016-03-12 11:26:29 Z0 days1 attempts 4182 people touched revisions under test, not listing them all jobs: build-amd64-xsm
[Xen-devel] [xen-unstable baseline-only test] 44245: regressions - FAIL
This run is configured for baseline tests only. flight 44245 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44245/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-midway 15 guest-start/debian.repeat fail REGR. vs. 44238 Regressions which are regarded as allowable (not blocking): build-i386-rumpuserxen6 xen-buildfail like 44238 test-amd64-amd64-xl-xsm 19 guest-start/debian.repeatfail like 44238 build-amd64-rumpuserxen 6 xen-buildfail like 44238 test-amd64-amd64-xl-credit2 19 guest-start/debian.repeatfail like 44238 test-amd64-amd64-xl 19 guest-start/debian.repeatfail like 44238 test-amd64-amd64-amd64-pvgrub 10 guest-start fail like 44238 test-amd64-amd64-i386-pvgrub 10 guest-start fail like 44238 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 44238 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 44238 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass version targeted for testing: xen e46a729b18af85b4dd040578643f7fa430b22a48 baseline version: xen 6890e07e483673ec5f946b7c4654275707924d6d Last test of basis44238 2016-03-10 17:23:16 Z2 days Testing same since44245 2016-03-12 17:19:39 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Dario Faggioli David Vrabel Doug Goldstein George Dunlap Ian Jackson Jan Beulich Julien Grall Meng Xu Razvan Cojocaru Roger Pau Monne Stefano Stabellini Wei Liu jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass
Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1
On Sat, Mar 12, 2016 at 3:23 PM, Dushyant Behl wrote: > Hi Meng, > > On Sat, Mar 12, 2016 at 8:57 PM, Meng Xu wrote: >> >> On Sat, Mar 12, 2016 at 9:20 AM, Dushyant Behl >> wrote: >> > Hi Julien, >> > >> > Thanks for the quick reply. >> > >> > On Thu, Mar 10, 2016 at 10:38 AM, Julien Grall >> > wrote: >> >> >> >> Hi Dushyant, >> >> >> >> On 09/03/2016 20:37, Wei Liu wrote: >> >>> >> >>> On Tue, Mar 08, 2016 at 08:23:29AM +, Dushyant K Behl wrote: >> >> I'm working on a research project with IBM, and I want to run Xen on >> Nvidia >> Tegra Jetson-tk1 board. >> I looked at a post on this mailing list >> (http://lists.xenproject.org/archives/ >> html/xen-devel/2015-03/msg01122.html), >> and I am using this git tree - >> >> git://xenbits.xen.org/people/ianc/xen.git >> and branch - tegra-tk1-jetson-v1 >> >> But when I try to boot Xen on the board I am not able to see any >> output >> (even >> with earlyprintk enabled). >> After jumping to Xen the board just resets without showing any >> output. >> >> I am using upstream u-boot with non secure mode enabled. I have also >> tested >> booting the Linux kernel on the same setup >> and Linux 4.0 is able to boot with all 4 cores in HYP mode and kvm >> enabled. >> >> Can anyone help me as to what I might have done wrong while using >> Xen? >> >> >> >> >> >> I never tried to boot Xen on Jetson-TK1 myself. >> >> >> >> Could you provide the command line you use to compile Xen (with >> >> earlyprintk enabled) and the U-boot runes? >> > >> > >> > I am running a ubuntu trusty schroot and I am using the Ubuntu/Linaro >> > arm-linux-gnueabihf-gcc 4.7.3 >> > as the cross compiler to compile everything. The tree which I pointed >> > towards (in my previous mail) >> > contains the earlyprintk configurations for Jetson-TK1, so I am using >> > this >> > command to compile Xen with earlyprintk - >> > >> > make dist-xen debug=y CONFIG_EARLY_PRINTK=jetson XEN_TARGET_ARCH=arm32 >> > >> > I want to update my current stage with Xen, after using this toolchain I >> > am >> > able to get Xen to print output >> > on the Jetson-TK1's serial console and Xen is able to boot correctly >> > with >> > all 4 cores in HYP mode. >> > >> > But the problem is when Xen tries to boot the dom0 kernel and transfer >> > control, I receive no output on the serial port. >> > I am using Linux 4.1.0 as the dom0 kernel and the kernel is compiled >> > with >> > Xen specific options enabled. >> > Also the same linux kernel is able to boot on the board without Xen. >> > >> > I am passing the dom0 kernel argument to Xen in the /chosen node in the >> > device tree using these commands - >> > >> > fdt mknod /chosen module >> > fdt set /chosen/module compatible "xen,linux-zimage" >> > "xen,multiboot-module" >> > fdt set /chosen/module reg <0x0 $kernel_addr_r 0x0 0x$filesize> >> > fdt set /chosen/module bootargs "$bootargs" >> >> I haven't run Xen on ARM yet. But just a random thought: >> Is it possible that you need to provide the console=hvc0 for the boot >> cmdline of dom0? >> >> dom0 needs share the serial port with Xen. > > > I have added the serial port in the bootargs passed to the kernel. The > bootargs > passed to the dom0 when executing with Xen are the same bootargs which I > pass > when I run the kernel standalone without Xen and at that time I am able to > see the > kernel bootlog and a tty console on the serial port. Ahha, that's the problem! when Linux runs in native env., it will use serial port, say com1, you can use console=com1 or console ttyS0 for the boot cmd. However, when you run linux in dom0, linux won't see the hardware ttyS0 directly. It must go through Xen to see it. So the linux's cmdline in dom0 must be console=hvc0, instead of ttyS0 or com1. Can you try this and see if it fix the problem? > >> >> > >> > I am loading Xen at top of the ram and linux and device tree at their >> > default locations (near starting of ram). >> > >> > This is the Xen BootLog which I receive through the earlyprintk serial >> > port >> > - >> > >> > - UART enabled - >> > - CPU booting - >> > - Xen starting in Hyp mode - >> > - Zero BSS - >> > - Setting up control registers - >> > - CPU Init Done -- Turning on paging - >> > - Ready - >> > (XEN) Checking for initrd in /chosen >> > (XEN) RAM: 8000 - ffef >> > (XEN) >> > (XEN) MODULE[0]: 8200 - 8201 Device Tree >> > (XEN) MODULE[1]: 8100 - 8158 Kernel >> > (XEN) RESVD[0]: 8200 - 8201 >> > (XEN) >> > (XEN) Command line: >> > (XEN) Placing Xen at 0xffc0-0xffe0 >> > (XEN) Update BOOTMOD_XEN from fd00-fd0f9701 => >> > ffc0-ffcf9701 >> > (XEN) Xen heap: fa00-fe00 (16384 pages) >> > (XEN) Dom heap: 507648 pages >> > (XEN) Domain heap in
[Xen-devel] [xen-4.3-testing test] 86035: regressions - trouble: blocked/broken/fail/pass
flight 86035 xen-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/86035/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 3 host-install(3) broken REGR. vs. 83004 build-armhf-pvops 3 host-install(3) broken REGR. vs. 83004 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 83004 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 83004 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 83004 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 83004 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 83004 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 83004 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 83004 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass build-amd64-rumpuserxen 6 xen-buildfail never pass build-i386-rumpuserxen6 xen-buildfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass version targeted for testing: xen 4db81940ee9eb82b3b3895c449ccbbab4a7147a4 baseline version: xen ccc7adf9cff5d5f93720afcc1d0f7227d50feab2 Last test of basis83004 2016-02-18 14:47:44 Z 23 days Failing since 84923 2016-03-01 13:41:07 Z 11 days 13 attempts Testing same since85979 2016-03-11 05:16:24 Z1 days2 attempts People who touched revisions under test: Ian Campbell Ian Jackson Konrad Rzeszutek Wilk Wei Liu jobs: build-amd64 pass build-armhf broken build-i386 pass build-amd64-libvirt pass build-armhf-libvirt blocked build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopsbroken build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl pass test-armhf-armhf-xl blocked test-amd64-i386-xl pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64fail test-amd64-i386-xl-qemut-debianhvm-amd64 fail test-amd64-amd64-xl-qemuu-debianhvm-amd64fail test-amd64-i386-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64
[Xen-devel] [linux-mingo-tip-master test] 86030: regressions - FAIL
flight 86030 linux-mingo-tip-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/86030/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684 build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 60684 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate fail REGR. vs. 60684 test-amd64-amd64-libvirt 15 guest-saverestore.2 fail REGR. vs. 60684 test-amd64-amd64-xl-xsm 15 guest-localmigratefail REGR. vs. 60684 test-amd64-amd64-xl 15 guest-localmigratefail REGR. vs. 60684 test-amd64-amd64-libvirt-xsm 14 guest-saverestore fail REGR. vs. 60684 test-amd64-amd64-xl-credit2 15 guest-localmigratefail REGR. vs. 60684 test-amd64-amd64-pair 22 guest-migrate/dst_host/src_host fail REGR. vs. 60684 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 14 guest-saverestore fail REGR. vs. 60684 test-amd64-i386-libvirt-xsm 15 guest-saverestore.2 fail blocked in 60684 test-amd64-i386-xl 15 guest-localmigrate fail blocked in 60684 test-amd64-i386-libvirt 15 guest-saverestore.2 fail blocked in 60684 test-amd64-i386-xl-xsm 15 guest-localmigrate fail blocked in 60684 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail blocked in 60684 test-amd64-i386-pair 22 guest-migrate/dst_host/src_host fail blocked in 60684 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked in 60684 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail like 60684 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 60684 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 60684 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 60684 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass version targeted for testing: linux89456cf74dc22a96c35f78b2f780a7ea5d26f326 baseline version: linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0 Last test of basis60684 2015-08-13 04:21:46 Z 212 days Failing since 60712 2015-08-15 18:33:48 Z 210 days 155 attempts Testing same since86030 2016-03-12 05:46:42 Z0 days1 attempts 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 build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl fail test-amd64-i386-xl fail test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 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-xl-qemut-stubdom-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm fail test-amd64-i386-libvirt-xsm
Re: [Xen-devel] [PATCH v8]xen: sched: convert RTDS from time to event driven model
On 03/12/2016 05:36 PM, Andrew Cooper wrote: On 12/03/2016 22:21, Chen, Tianyang wrote: On 03/11/2016 11:54 PM, Meng Xu wrote: I'm focusing on the style and the logic in the replenish handler: /* @@ -160,6 +180,7 @@ struct rt_private { */ struct rt_vcpu { struct list_head q_elem;/* on the runq/depletedq list */ +struct list_head replq_elem;/* on the repl event list */ missing space before /* I wasn't sure if all the comments should be lined up or not. Maybe there should be one more space for all the fields so they nicely line up? At the very least, there should be a space between the ; and / If you were introducing the entire structure at once then aligned comments would be better, or if you were submitting a larger series with some cleanup patches, then modifying the existing layout would be acceptable. In this case however, I would avoid aligning all the comments, as it detracts from the clarity of the patch (whose purpose is a functional change). Right. +static int +deadline_queue_insert(struct rt_vcpu * (*_get_q_elem)(struct list_head *elem), +struct rt_vcpu *svc, struct list_head *elem, struct list_head *queue) +{ +struct list_head *iter; +int pos = 0; + +list_for_each(iter, queue) space after ( and before ) If not sure about the space, we can refer to the sched_credit.c for the style as well, beside the CODING_STYLE file. :-) Ok. But in __runq_pick() there is no space. Also there is no space in the definition of this macro: #define list_for_each(pos, head) \ Which one should I follow? Apologies for that. The code is not in a particularly good state, but we do request that all new code adheres to the guidelines, in a hope that eventually it will be consistent. The macro definition won't have spaces because CPP syntax requires that the ( be immediately following the macro name. The Xen coding guidelines require that control structures including if, for, while, and these macro structures (being an extension of a for loop) have spaces between the control name, and immediately inside the control brackets. Therefore, it should end up as ... list_for_each ( iter, queue ) { ... If you wish, you are more than welcome to submit an additional patch whose purpose is to specifically fix the pre-existing style issues, but you are under no obligation to. ~Andrew Thanks for the clarification. Tianyang Chen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8]xen: sched: convert RTDS from time to event driven model
On 12/03/2016 22:21, Chen, Tianyang wrote: > > > On 03/11/2016 11:54 PM, Meng Xu wrote: >> I'm focusing on the style and the logic in the replenish handler: >> >>> /* >>> @@ -160,6 +180,7 @@ struct rt_private { >>>*/ >>> struct rt_vcpu { >>> struct list_head q_elem;/* on the runq/depletedq list */ >>> +struct list_head replq_elem;/* on the repl event list */ >> >> missing space before /* >> > > I wasn't sure if all the comments should be lined up or not. Maybe > there should be one more space for all the fields so they nicely line up? At the very least, there should be a space between the ; and / If you were introducing the entire structure at once then aligned comments would be better, or if you were submitting a larger series with some cleanup patches, then modifying the existing layout would be acceptable. In this case however, I would avoid aligning all the comments, as it detracts from the clarity of the patch (whose purpose is a functional change). > >>> +static int >>> +deadline_queue_insert(struct rt_vcpu * (*_get_q_elem)(struct >>> list_head *elem), >>> +struct rt_vcpu *svc, struct list_head *elem, struct list_head >>> *queue) >>> +{ >>> +struct list_head *iter; >>> +int pos = 0; >>> + >>> +list_for_each(iter, queue) >> >> space after ( and before ) >> If not sure about the space, we can refer to the sched_credit.c for >> the style as well, beside the CODING_STYLE file. :-) >> > > Ok. But in __runq_pick() there is no space. Also there is no space in > the definition of this macro: > #define list_for_each(pos, head) \ > Which one should I follow? > Apologies for that. The code is not in a particularly good state, but we do request that all new code adheres to the guidelines, in a hope that eventually it will be consistent. The macro definition won't have spaces because CPP syntax requires that the ( be immediately following the macro name. The Xen coding guidelines require that control structures including if, for, while, and these macro structures (being an extension of a for loop) have spaces between the control name, and immediately inside the control brackets. Therefore, it should end up as ... list_for_each ( iter, queue ) { ... If you wish, you are more than welcome to submit an additional patch whose purpose is to specifically fix the pre-existing style issues, but you are under no obligation to. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8]xen: sched: convert RTDS from time to event driven model
On 03/11/2016 11:54 PM, Meng Xu wrote: I'm focusing on the style and the logic in the replenish handler: /* @@ -160,6 +180,7 @@ struct rt_private { */ struct rt_vcpu { struct list_head q_elem;/* on the runq/depletedq list */ +struct list_head replq_elem;/* on the repl event list */ missing space before /* I wasn't sure if all the comments should be lined up or not. Maybe there should be one more space for all the fields so they nicely line up? +static int +deadline_queue_insert(struct rt_vcpu * (*_get_q_elem)(struct list_head *elem), +struct rt_vcpu *svc, struct list_head *elem, struct list_head *queue) +{ +struct list_head *iter; +int pos = 0; + +list_for_each(iter, queue) space after ( and before ) If not sure about the space, we can refer to the sched_credit.c for the style as well, beside the CODING_STYLE file. :-) Ok. But in __runq_pick() there is no space. Also there is no space in the definition of this macro: #define list_for_each(pos, head) \ Which one should I follow? @@ -707,7 +888,14 @@ burn_budget(const struct scheduler *ops, struct rt_vcpu *svc, s_time_t now) svc->cur_budget -= delta; if ( svc->cur_budget < 0 ) Although this line is not changed in the patch. I'm thinking maybe it should be if ( svc->cur_budget <= 0 ) because budget == 0 also means depleted budget. Right. +/* + * If the vcpu is running, let the head + * of the run queue tickle if it has a + * higher priority. + */ +struct rt_vcpu *next_on_runq = __q_elem(runq->next); +if ( svc->cur_deadline >= next_on_runq->cur_deadline ) It's better to be if ( svc->cur_deadline > next_on_runq->cur_deadline ), to avoid the unnecessary tickle when they have same priority. We assume priority tie is broken arbitrarily. OK. Great and expedite work, Tianyang! This version looks good. Can you set up a repo. with the previous version of the patch and this version of the patch so that I can diff. these two versions to make sure I didn't miss anything you modified from the last version. Sure. One more thing we should think about is: How can we "prove/test" the correctness of the scheduler? Can we use xentrace to record the scheduling trace and then write a userspace program to check the scheduling trace is obeying the priority rules of the scheduler. Thanks for the review Meng, I am still exploring xentrace and it can output scheduling events such as which vcpu is running on a pcpu. I think it's possible for the userspace program to check RTDS, based on cur_budget and cur_deadline. We need to have a very clear outline of rules, for the things we are concerned about. When you say correctness, what does it include? I'm thinking about rules for when a vcpu should preempt, tickle and actually be picked. Thanks, Tianyang ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 86033: regressions - FAIL
flight 86033 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/86033/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 version targeted for testing: ovmf ec3a1a11dc90d46c87a70327c87d139d12eccdcb baseline version: ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1 Last test of basis65543 2015-12-08 08:45:15 Z 95 days Failing since 65593 2015-12-08 23:44:51 Z 94 days 101 attempts Testing same since86033 2016-03-12 06:32:19 Z0 days1 attempts People who touched revisions under test: "Samer El-Haj-Mahmoud" "Wu, Hao A" "Yao, Jiewen" Alcantara, Paulo Anbazhagan Baraneedharan Andrew Fish Ard Biesheuvel Arthur Crippa Burigo Cecil Sheng Chao Zhang Chao Zhang Charles Duffy Cinnamon Shia Cohen, Eugene Dandan Bi Daocheng Bu Daryl McDaniel David Woodhouse edk2 dev edk2-devel Eric Dong Eric Dong Eugene Cohen Evan Lloyd Feng Tian Fu Siyuan Gabriel Somlo Gary Ching-Pang Lin Gary Lin Ghazi Belaam Hao Wu Haojian Zhuang Hess Chen Heyi Guo Jaben Carsey Jeff Fan Jiaxin Wu jiewen yao Jim Dailey jim_dai...@dell.com Jordan Justen Karyne Mayer Larry Hauch Laszlo Ersek Leahy, Leroy P Leahy, Leroy P Lee Leahy Leekha Shaveta Leif Lindholm Liming Gao Mark Rutland Marvin Haeuser Michael Kinney Michael LeMay Michael Thomas MichaÅ Zegan Ni, Ruiyu Paolo Bonzini Paulo Alcantara Paulo Alcantara Cavalcanti Qin Long Qiu Shumin Rodrigo Dias Correa Ruiyu Ni Ryan Harkin Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud Star Zeng Supreeth Venkatesh Tapan Shah Tian, Feng Vladislav Vovchenko Yao Jiewen Yao, Jiewen Ye Ting Yonghong Zhu Zhang Lubo Zhang, Chao B Zhang, Lubo Zhangfei Gao jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 12812 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1
Hi Meng, On Sat, Mar 12, 2016 at 8:57 PM, Meng Xu wrote: > On Sat, Mar 12, 2016 at 9:20 AM, Dushyant Behl > wrote: > > Hi Julien, > > > > Thanks for the quick reply. > > > > On Thu, Mar 10, 2016 at 10:38 AM, Julien Grall > wrote: > >> > >> Hi Dushyant, > >> > >> On 09/03/2016 20:37, Wei Liu wrote: > >>> > >>> On Tue, Mar 08, 2016 at 08:23:29AM +, Dushyant K Behl wrote: > > I'm working on a research project with IBM, and I want to run Xen on > Nvidia > Tegra Jetson-tk1 board. > I looked at a post on this mailing list > (http://lists.xenproject.org/archives/ > html/xen-devel/2015-03/msg01122.html), > and I am using this git tree - > > git://xenbits.xen.org/people/ianc/xen.git > and branch - tegra-tk1-jetson-v1 > > But when I try to boot Xen on the board I am not able to see any > output > (even > with earlyprintk enabled). > After jumping to Xen the board just resets without showing any output. > > I am using upstream u-boot with non secure mode enabled. I have also > tested > booting the Linux kernel on the same setup > and Linux 4.0 is able to boot with all 4 cores in HYP mode and kvm > enabled. > > Can anyone help me as to what I might have done wrong while using Xen? > >> > >> > >> I never tried to boot Xen on Jetson-TK1 myself. > >> > >> Could you provide the command line you use to compile Xen (with > >> earlyprintk enabled) and the U-boot runes? > > > > > > I am running a ubuntu trusty schroot and I am using the Ubuntu/Linaro > > arm-linux-gnueabihf-gcc 4.7.3 > > as the cross compiler to compile everything. The tree which I pointed > > towards (in my previous mail) > > contains the earlyprintk configurations for Jetson-TK1, so I am using > this > > command to compile Xen with earlyprintk - > > > > make dist-xen debug=y CONFIG_EARLY_PRINTK=jetson XEN_TARGET_ARCH=arm32 > > > > I want to update my current stage with Xen, after using this toolchain I > am > > able to get Xen to print output > > on the Jetson-TK1's serial console and Xen is able to boot correctly with > > all 4 cores in HYP mode. > > > > But the problem is when Xen tries to boot the dom0 kernel and transfer > > control, I receive no output on the serial port. > > I am using Linux 4.1.0 as the dom0 kernel and the kernel is compiled with > > Xen specific options enabled. > > Also the same linux kernel is able to boot on the board without Xen. > > > > I am passing the dom0 kernel argument to Xen in the /chosen node in the > > device tree using these commands - > > > > fdt mknod /chosen module > > fdt set /chosen/module compatible "xen,linux-zimage" > "xen,multiboot-module" > > fdt set /chosen/module reg <0x0 $kernel_addr_r 0x0 0x$filesize> > > fdt set /chosen/module bootargs "$bootargs" > > I haven't run Xen on ARM yet. But just a random thought: > Is it possible that you need to provide the console=hvc0 for the boot > cmdline of dom0? > > dom0 needs share the serial port with Xen. I have added the serial port in the bootargs passed to the kernel. The bootargs passed to the dom0 when executing with Xen are the same bootargs which I pass when I run the kernel standalone without Xen and at that time I am able to see the kernel bootlog and a tty console on the serial port. > > > > I am loading Xen at top of the ram and linux and device tree at their > > default locations (near starting of ram). > > > > This is the Xen BootLog which I receive through the earlyprintk serial > port > > - > > > > - UART enabled - > > - CPU booting - > > - Xen starting in Hyp mode - > > - Zero BSS - > > - Setting up control registers - > > - CPU Init Done -- Turning on paging - > > - Ready - > > (XEN) Checking for initrd in /chosen > > (XEN) RAM: 8000 - ffef > > (XEN) > > (XEN) MODULE[0]: 8200 - 8201 Device Tree > > (XEN) MODULE[1]: 8100 - 8158 Kernel > > (XEN) RESVD[0]: 8200 - 8201 > > (XEN) > > (XEN) Command line: > > (XEN) Placing Xen at 0xffc0-0xffe0 > > (XEN) Update BOOTMOD_XEN from fd00-fd0f9701 => > > ffc0-ffcf9701 > > (XEN) Xen heap: fa00-fe00 (16384 pages) > > (XEN) Dom heap: 507648 pages > > (XEN) Domain heap initialised > > (XEN) Platform: TEGRA124 > > (XEN) No dtuart path configured > > (XEN) Bad console= option 'dtuart' > > Xen 4.6-unstable > > (XEN) Xen version 4.6-unstable (root@) (arm-linux-gnueabihf-gcc > > (Ubuntu/Linaro 4.7.3-11ubuntu1) 4.7.3) debug=y Fri Mar 11 10:09:07 UTC > 2016 > > (XEN) Latest ChangeSet: > > (XEN) Processor: 413fc0f3: "ARM Limited", variant: 0x3, part 0xc0f, rev > 0x3 > > (XEN) 32-bit Execution: > > (XEN) Processor Features: 1131:00011011 > > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle > > (XEN) Extensions: GenericTimer Security > > (XEN) Debug Features: 02010555 >
[Xen-devel] [linux-4.1 test] 86019: regressions - trouble: blocked/broken/fail/pass
flight 86019 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/86019/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 66399 build-i386-rumpuserxen6 xen-build fail REGR. vs. 66399 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 66399 test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail REGR. vs. 66399 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-winxpsp3 3 host-install(3) broken pass in 85972 test-armhf-armhf-xl-credit2 6 xen-boot fail in 85641 pass in 86019 test-armhf-armhf-xl 15 guest-start/debian.repeat fail in 85641 pass in 86019 test-armhf-armhf-xl-xsm 11 guest-startfail in 85972 pass in 86019 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail pass in 85641 test-armhf-armhf-libvirt-xsm 6 xen-bootfail pass in 85972 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail pass in 85972 test-armhf-armhf-xl-rtds 11 guest-start fail pass in 85972 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 85972 like 66399 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 66399 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 66399 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 66399 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66399 test-armhf-armhf-xl-vhd 9 debian-di-installfail like 66399 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail in 85972 never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestore fail in 85972 never pass test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 85972 never pass test-armhf-armhf-xl-rtds 12 migrate-support-check fail in 85972 never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass version targeted for testing: linuxb9a9cfdbf7254f4a231cc8ddf685cc29d3a9c6e5 baseline version: linux07cc49f66973f49a391c91bf4b158fa0f2562ca8 Last test of basis66399 2015-12-15 18:20:39 Z 88 days Failing since 78925 2016-01-24 13:50:39 Z 48 days 50 attempts Testing same since85582 2016-03-06 13:53:34 Z6 days8 attempts 431 people touched revisions under test, not listing them all jobs: build-amd6
[Xen-devel] [PATCH v4 4/5] x86/paravirt: Make "unsafe" MSR accesses unsafe even if PARAVIRT=y
Enabling CONFIG_PARAVIRT had an unintended side effect: rdmsr turned into rdmsr_safe and wrmsr turned into wrmsr_safe, even on bare metal. Undo that by using the new unsafe paravirt MSR hooks. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/paravirt.h | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index 68297d87e85c..0c99f10874e4 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -151,24 +151,21 @@ static inline int paravirt_write_msr_safe(unsigned msr, return PVOP_CALL3(int, pv_cpu_ops.write_msr_safe, msr, low, high); } -/* These should all do BUG_ON(_err), but our headers are too tangled. */ #define rdmsr(msr, val1, val2) \ do { \ - int _err; \ - u64 _l = paravirt_read_msr_safe(msr, &_err);\ + u64 _l = paravirt_read_msr(msr);\ val1 = (u32)_l; \ val2 = _l >> 32;\ } while (0) #define wrmsr(msr, val1, val2) \ do { \ - paravirt_write_msr_safe(msr, val1, val2); \ + paravirt_write_msr(msr, val1, val2);\ } while (0) #define rdmsrl(msr, val) \ do { \ - int _err; \ - val = paravirt_read_msr_safe(msr, &_err); \ + val = paravirt_read_msr(msr); \ } while (0) static inline void wrmsrl(unsigned msr, u64 val) -- 2.5.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops
This demotes an OOPS and likely panic due to a failed non-"safe" MSR access to a WARN_ONCE and, for RDMSR, a return value of zero. If panic_on_oops is set, then failed unsafe MSR accesses will still oops and panic. To be clear, this type of failure should *not* happen. This patch exists to minimize the chance of nasty undebuggable failures due on systems that used to work due to a now-fixed CONFIG_PARAVIRT=y bug. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/msr.h | 10 -- arch/x86/mm/extable.c | 33 + 2 files changed, 41 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h index 93fb7c1cffda..1487054a1a70 100644 --- a/arch/x86/include/asm/msr.h +++ b/arch/x86/include/asm/msr.h @@ -92,7 +92,10 @@ static inline unsigned long long native_read_msr(unsigned int msr) { DECLARE_ARGS(val, low, high); - asm volatile("rdmsr" : EAX_EDX_RET(val, low, high) : "c" (msr)); + asm volatile("1: rdmsr\n" +"2:\n" +_ASM_EXTABLE_HANDLE(1b, 2b, ex_handler_rdmsr_unsafe) +: EAX_EDX_RET(val, low, high) : "c" (msr)); if (msr_tracepoint_active(__tracepoint_read_msr)) do_trace_read_msr(msr, EAX_EDX_VAL(val, low, high), 0); return EAX_EDX_VAL(val, low, high); @@ -119,7 +122,10 @@ static inline unsigned long long native_read_msr_safe(unsigned int msr, static inline void native_write_msr(unsigned int msr, unsigned low, unsigned high) { - asm volatile("wrmsr" : : "c" (msr), "a"(low), "d" (high) : "memory"); + asm volatile("1: wrmsr\n" +"2:\n" +_ASM_EXTABLE_HANDLE(1b, 2b, ex_handler_wrmsr_unsafe) +: : "c" (msr), "a"(low), "d" (high) : "memory"); if (msr_tracepoint_active(__tracepoint_read_msr)) do_trace_write_msr(msr, ((u64)high << 32 | low), 0); } diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c index 9dd7e4b7fcde..9e6749b34524 100644 --- a/arch/x86/mm/extable.c +++ b/arch/x86/mm/extable.c @@ -49,6 +49,39 @@ bool ex_handler_ext(const struct exception_table_entry *fixup, } EXPORT_SYMBOL(ex_handler_ext); +bool ex_handler_rdmsr_unsafe(const struct exception_table_entry *fixup, +struct pt_regs *regs, int trapnr) +{ + WARN_ONCE(1, "unchecked MSR access error: RDMSR from 0x%x", + (unsigned int)regs->cx); + + /* If panic_on_oops is set, don't try to recover. */ + if (panic_on_oops) + return false; + + regs->ip = ex_fixup_addr(fixup); + regs->ax = 0; + regs->dx = 0; + return true; +} +EXPORT_SYMBOL(ex_handler_rdmsr_unsafe); + +bool ex_handler_wrmsr_unsafe(const struct exception_table_entry *fixup, +struct pt_regs *regs, int trapnr) +{ + WARN_ONCE(1, "unchecked MSR access error: WRMSR to 0x%x (tried to write 0x%08x%08x)\n", + (unsigned int)regs->cx, + (unsigned int)regs->dx, (unsigned int)regs->ax); + + /* If panic_on_oops is set, don't try to recover. */ + if (panic_on_oops) + return false; + + regs->ip = ex_fixup_addr(fixup); + return true; +} +EXPORT_SYMBOL(ex_handler_wrmsr_unsafe); + bool ex_has_fault_handler(unsigned long ip) { const struct exception_table_entry *e; -- 2.5.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 1/5] x86/paravirt: Add _safe to the read_msr and write_msr PV hooks
These hooks match the _safe variants, so name them accordingly. This will make room for unsafe PV hooks. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/paravirt.h | 33 + arch/x86/include/asm/paravirt_types.h | 8 arch/x86/kernel/paravirt.c| 4 ++-- arch/x86/xen/enlighten.c | 4 ++-- 4 files changed, 25 insertions(+), 24 deletions(-) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index f6192502149e..2e49228ed9a3 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -129,34 +129,35 @@ static inline void wbinvd(void) #define get_kernel_rpl() (pv_info.kernel_rpl) -static inline u64 paravirt_read_msr(unsigned msr, int *err) +static inline u64 paravirt_read_msr_safe(unsigned msr, int *err) { - return PVOP_CALL2(u64, pv_cpu_ops.read_msr, msr, err); + return PVOP_CALL2(u64, pv_cpu_ops.read_msr_safe, msr, err); } -static inline int paravirt_write_msr(unsigned msr, unsigned low, unsigned high) +static inline int paravirt_write_msr_safe(unsigned msr, + unsigned low, unsigned high) { - return PVOP_CALL3(int, pv_cpu_ops.write_msr, msr, low, high); + return PVOP_CALL3(int, pv_cpu_ops.write_msr_safe, msr, low, high); } /* These should all do BUG_ON(_err), but our headers are too tangled. */ #define rdmsr(msr, val1, val2) \ do { \ int _err; \ - u64 _l = paravirt_read_msr(msr, &_err); \ + u64 _l = paravirt_read_msr_safe(msr, &_err);\ val1 = (u32)_l; \ val2 = _l >> 32;\ } while (0) #define wrmsr(msr, val1, val2) \ do { \ - paravirt_write_msr(msr, val1, val2);\ + paravirt_write_msr_safe(msr, val1, val2); \ } while (0) #define rdmsrl(msr, val) \ do { \ int _err; \ - val = paravirt_read_msr(msr, &_err);\ + val = paravirt_read_msr_safe(msr, &_err); \ } while (0) static inline void wrmsrl(unsigned msr, u64 val) @@ -164,23 +165,23 @@ static inline void wrmsrl(unsigned msr, u64 val) wrmsr(msr, (u32)val, (u32)(val>>32)); } -#define wrmsr_safe(msr, a, b) paravirt_write_msr(msr, a, b) +#define wrmsr_safe(msr, a, b) paravirt_write_msr_safe(msr, a, b) /* rdmsr with exception handling */ -#define rdmsr_safe(msr, a, b) \ -({ \ - int _err; \ - u64 _l = paravirt_read_msr(msr, &_err); \ - (*a) = (u32)_l; \ - (*b) = _l >> 32;\ - _err; \ +#define rdmsr_safe(msr, a, b) \ +({ \ + int _err; \ + u64 _l = paravirt_read_msr_safe(msr, &_err);\ + (*a) = (u32)_l; \ + (*b) = _l >> 32;\ + _err; \ }) static inline int rdmsrl_safe(unsigned msr, unsigned long long *p) { int err; - *p = paravirt_read_msr(msr, &err); + *p = paravirt_read_msr_safe(msr, &err); return err; } diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index 77db5616a473..5a06cccd36f0 100644 --- a/arch/x86/include/asm/paravirt_types.h +++ b/arch/x86/include/asm/paravirt_types.h @@ -155,10 +155,10 @@ struct pv_cpu_ops { void (*cpuid)(unsigned int *eax, unsigned int *ebx, unsigned int *ecx, unsigned int *edx); - /* MSR, PMC and TSR operations. - err = 0/-EFAULT. wrmsr returns 0/-EFAULT. */ - u64 (*read_msr)(unsigned int msr, int *err); - int (*write_msr)(unsigned int msr, unsigned low, unsigned high); + /* MSR operations. + err = 0/-EIO. wrmsr returns 0/-EIO. */ + u64 (*read_msr_safe)(unsigned int msr, int *err); + int (*write_msr_safe)(unsigned int msr, unsigned low, unsigned high); u64 (*read_pmc)(int counter); diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c index f08ac28b8136..8aad95478ae5 100644 --- a/arch/x86/kernel/paravirt.c +++ b/arch/x86/kernel/paravirt.c @@ -339,8 +339,8 @@ __visible struct pv_cpu_ops pv_cpu_ops = { .write_cr8 = native_write_cr8, #endif .wbinvd = native_wbinvd, - .read_msr = native_read_msr_safe, - .write_msr = native_write_msr_safe, + .read_msr_safe = native_read_msr_safe, + .write_msr_safe = native_write_msr_safe, .read_pmc = native_read
[Xen-devel] [PATCH v4 3/5] x86/paravirt: Add paravirt_{read, write}_msr
This adds paravirt hooks for unsafe MSR access. On native, they call native_{read,write}_msr. On Xen, they use xen_{read,write}_msr_safe. Nothing uses them yet for ease of bisection. The next patch will use them in rdmsrl, wrmsrl, etc. I intentionally didn't make them OOPS on #GP on Xen. I think that should be done separately by the Xen maintainers. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/msr.h| 5 +++-- arch/x86/include/asm/paravirt.h | 11 +++ arch/x86/include/asm/paravirt_types.h | 10 -- arch/x86/kernel/paravirt.c| 2 ++ arch/x86/xen/enlighten.c | 23 +++ 5 files changed, 47 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h index 1487054a1a70..13da359881d7 100644 --- a/arch/x86/include/asm/msr.h +++ b/arch/x86/include/asm/msr.h @@ -119,8 +119,9 @@ static inline unsigned long long native_read_msr_safe(unsigned int msr, return EAX_EDX_VAL(val, low, high); } -static inline void native_write_msr(unsigned int msr, - unsigned low, unsigned high) +/* Can be uninlined because referenced by paravirt */ +notrace static inline void native_write_msr(unsigned int msr, + unsigned low, unsigned high) { asm volatile("1: wrmsr\n" "2:\n" diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index 2e49228ed9a3..68297d87e85c 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -129,6 +129,17 @@ static inline void wbinvd(void) #define get_kernel_rpl() (pv_info.kernel_rpl) +static inline u64 paravirt_read_msr(unsigned msr) +{ + return PVOP_CALL1(u64, pv_cpu_ops.read_msr, msr); +} + +static inline void paravirt_write_msr(unsigned msr, + unsigned low, unsigned high) +{ + return PVOP_VCALL3(pv_cpu_ops.write_msr, msr, low, high); +} + static inline u64 paravirt_read_msr_safe(unsigned msr, int *err) { return PVOP_CALL2(u64, pv_cpu_ops.read_msr_safe, msr, err); diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index 5a06cccd36f0..b85aec45a1b8 100644 --- a/arch/x86/include/asm/paravirt_types.h +++ b/arch/x86/include/asm/paravirt_types.h @@ -155,8 +155,14 @@ struct pv_cpu_ops { void (*cpuid)(unsigned int *eax, unsigned int *ebx, unsigned int *ecx, unsigned int *edx); - /* MSR operations. - err = 0/-EIO. wrmsr returns 0/-EIO. */ + /* Unsafe MSR operations. These will warn or panic on failure. */ + u64 (*read_msr)(unsigned int msr); + void (*write_msr)(unsigned int msr, unsigned low, unsigned high); + + /* +* Safe MSR operations. +* read sets err to 0 or -EIO. write returns 0 or -EIO. +*/ u64 (*read_msr_safe)(unsigned int msr, int *err); int (*write_msr_safe)(unsigned int msr, unsigned low, unsigned high); diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c index 8aad95478ae5..f9583917c7c4 100644 --- a/arch/x86/kernel/paravirt.c +++ b/arch/x86/kernel/paravirt.c @@ -339,6 +339,8 @@ __visible struct pv_cpu_ops pv_cpu_ops = { .write_cr8 = native_write_cr8, #endif .wbinvd = native_wbinvd, + .read_msr = native_read_msr, + .write_msr = native_write_msr, .read_msr_safe = native_read_msr_safe, .write_msr_safe = native_write_msr_safe, .read_pmc = native_read_pmc, diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index ff2df20d0067..548cd3e02b9e 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -1092,6 +1092,26 @@ static int xen_write_msr_safe(unsigned int msr, unsigned low, unsigned high) return ret; } +static u64 xen_read_msr(unsigned int msr) +{ + /* +* This will silently swallow a #GP from RDMSR. It may be worth +* changing that. +*/ + int err; + + return xen_read_msr_safe(msr, &err); +} + +static void xen_write_msr(unsigned int msr, unsigned low, unsigned high) +{ + /* +* This will silently swallow a #GP from WRMSR. It may be worth +* changing that. +*/ + xen_write_msr_safe(msr, low, high); +} + void xen_setup_shared_info(void) { if (!xen_feature(XENFEAT_auto_translated_physmap)) { @@ -1222,6 +1242,9 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = { .wbinvd = native_wbinvd, + .read_msr = xen_read_msr, + .write_msr = xen_write_msr, + .read_msr_safe = xen_read_msr_safe, .write_msr_safe = xen_write_msr_safe, -- 2.5.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 5/5] x86/msr: Set the return value to zero when native_rdmsr_safe fails
This will cause unchecked native_rdmsr_safe failures to return deterministic results. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/msr.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h index 13da359881d7..e97e79f8a22b 100644 --- a/arch/x86/include/asm/msr.h +++ b/arch/x86/include/asm/msr.h @@ -109,7 +109,10 @@ static inline unsigned long long native_read_msr_safe(unsigned int msr, asm volatile("2: rdmsr ; xor %[err],%[err]\n" "1:\n\t" ".section .fixup,\"ax\"\n\t" -"3: mov %[fault],%[err] ; jmp 1b\n\t" +"3: mov %[fault],%[err]\n\t" +"xorl %%eax, %%eax\n\t" +"xorl %%edx, %%edx\n\t" +"jmp 1b\n\t" ".previous\n\t" _ASM_EXTABLE(2b, 3b) : [err] "=r" (*err), EAX_EDX_RET(val, low, high) -- 2.5.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 0/5] [PATCH v3 0/5] Improve non-"safe" MSR access failure handling
Setting CONFIG_PARAVIRT=y has an unintended side effect: it silently turns all rdmsr and wrmsr operations into the safe variants without any checks that the operations actually succeed. With CONFIG_PARAVIRT=n, unchecked MSR failures OOPS and probably cause boot to fail if they happen before init starts. Neither behavior is very good, and it's particularly unfortunate that the behavior changes depending on CONFIG_PARAVIRT. In particular, KVM guests might be unwittingly depending on the PARAVIRT=y behavior because CONFIG_KVM_GUEST currently depends on CONFIG_PARAVIRT, and, because accesses in that case are completely unchecked, we wouldn't even see a warning. This series changes the native behavior, regardless of CONFIG_PARAVIRT. A non-"safe" MSR failure will give an informative warning once and will be fixed up -- native_read_msr will return zero, and both reads and writes will continue where they left off. If panic_on_oops is set, they will still OOPS and panic. By using the shiny new custom exception handler infrastructure, there should be no overhead on the success paths. I didn't change the behavior on Xen, but, with this series applied, it would be straightforward for the Xen maintainers to make the corresponding change -- knowledge of whether the access is "safe" is now propagated into the pvops. Doing this is probably a prerequisite to sanely decoupling CONFIG_KVM_GUEST and CONFIG_PARAVIRT, which would probably make Arjan and the rest of the Clear Containers people happy :) There's also room to reduce the code size of the "safe" variants using custom exception handlers in the future. Changes from v3: - WARN_ONCE instead of WARN (Ingo) - In the warning text, s/unsafe/unchecked/ (Ingo, sort of) Changes from earlier versions: lots of changes! Andy Lutomirski (5): x86/paravirt: Add _safe to the read_msr and write_msr PV hooks x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops x86/paravirt: Add paravirt_{read,write}_msr x86/paravirt: Make "unsafe" MSR accesses unsafe even if PARAVIRT=y x86/msr: Set the return value to zero when native_rdmsr_safe fails arch/x86/include/asm/msr.h| 20 arch/x86/include/asm/paravirt.h | 45 +-- arch/x86/include/asm/paravirt_types.h | 14 +++ arch/x86/kernel/paravirt.c| 6 +++-- arch/x86/mm/extable.c | 33 + arch/x86/xen/enlighten.c | 27 +++-- 6 files changed, 114 insertions(+), 31 deletions(-) -- 2.5.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 86026: tolerable FAIL - PUSHED
flight 86026 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/86026/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass version targeted for testing: libvirt 95ca4fe2f272d1c751acd278cc1617fe2aa1b94b baseline version: libvirt 1e34a8f91962a9a85ee6fc1478754736a5c36ff9 Last test of basis85976 2016-03-11 04:25:00 Z1 days Testing same since86026 2016-03-12 04:21:44 Z0 days1 attempts People who touched revisions under test: John Ferlan Martin Kletzander jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt fail test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-armhf-armhf-libvirt-qcow2 fail test-armhf-armhf-libvirt-raw fail test-amd64-amd64-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : + branch=libvirt + revision=95ca4fe2f272d1c751acd278cc1617fe2aa1b94b + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x '!=' x/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock ++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push libvirt 95ca4fe2f272d1c751acd278cc1617fe2aa1b94b + branch=libvirt + revision=95ca4fe2f272d1c
Re: [Xen-devel] [PATCH v3 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops
On Sat, Mar 12, 2016 at 7:36 AM, Ingo Molnar wrote: > > * Andy Lutomirski wrote: > >> This demotes an OOPS and likely panic due to a failed non-"safe" MSR >> access to a WARN and, for RDMSR, a return value of zero. If >> panic_on_oops is set, then failed unsafe MSR accesses will still >> oops and panic. >> >> To be clear, this type of failure should *not* happen. This patch >> exists to minimize the chance of nasty undebuggable failures due on >> systems that used to work due to a now-fixed CONFIG_PARAVIRT=y bug. >> >> Signed-off-by: Andy Lutomirski >> --- >> arch/x86/include/asm/msr.h | 10 -- >> arch/x86/mm/extable.c | 33 + >> 2 files changed, 41 insertions(+), 2 deletions(-) >> >> diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h >> index 93fb7c1cffda..1487054a1a70 100644 >> --- a/arch/x86/include/asm/msr.h >> +++ b/arch/x86/include/asm/msr.h >> @@ -92,7 +92,10 @@ static inline unsigned long long native_read_msr(unsigned >> int msr) >> { >> DECLARE_ARGS(val, low, high); >> >> - asm volatile("rdmsr" : EAX_EDX_RET(val, low, high) : "c" (msr)); >> + asm volatile("1: rdmsr\n" >> + "2:\n" >> + _ASM_EXTABLE_HANDLE(1b, 2b, ex_handler_rdmsr_unsafe) >> + : EAX_EDX_RET(val, low, high) : "c" (msr)); >> if (msr_tracepoint_active(__tracepoint_read_msr)) >> do_trace_read_msr(msr, EAX_EDX_VAL(val, low, high), 0); >> return EAX_EDX_VAL(val, low, high); >> @@ -119,7 +122,10 @@ static inline unsigned long long >> native_read_msr_safe(unsigned int msr, >> static inline void native_write_msr(unsigned int msr, >> unsigned low, unsigned high) >> { >> - asm volatile("wrmsr" : : "c" (msr), "a"(low), "d" (high) : "memory"); >> + asm volatile("1: wrmsr\n" >> + "2:\n" >> + _ASM_EXTABLE_HANDLE(1b, 2b, ex_handler_wrmsr_unsafe) >> + : : "c" (msr), "a"(low), "d" (high) : "memory"); >> if (msr_tracepoint_active(__tracepoint_read_msr)) >> do_trace_write_msr(msr, ((u64)high << 32 | low), 0); >> } >> diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c >> index 9dd7e4b7fcde..f310714e6e6d 100644 >> --- a/arch/x86/mm/extable.c >> +++ b/arch/x86/mm/extable.c >> @@ -49,6 +49,39 @@ bool ex_handler_ext(const struct exception_table_entry >> *fixup, >> } >> EXPORT_SYMBOL(ex_handler_ext); >> >> +bool ex_handler_rdmsr_unsafe(const struct exception_table_entry *fixup, >> + struct pt_regs *regs, int trapnr) >> +{ >> + WARN(1, "unsafe MSR access error: RDMSR from 0x%x", >> + (unsigned int)regs->cx); > > Btw., instead of the safe/unsafe naming (which has an emotional and security > secondary attribute), shouldn't we move this over to a _check() (or > _checking()) > naming instead that we do in other places in the kernel? > > I.e.: > > rdmsr(msr, l, h); > > and: > > if (rdmsr_check(msr, l, h)) { > ... > } > > and then we could name the helpers as _check() and _nocheck() - which is > neutral > naming. Will do as a separate followup series. At least with this series applied, the functions named _safe all point to each other correctly. --Andy ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 85995: tolerable FAIL - PUSHED
flight 85995 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/85995/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 85924 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 85850 build-amd64-rumpuserxen 6 xen-buildfail like 85924 build-i386-rumpuserxen6 xen-buildfail like 85924 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 85924 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 85924 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 85924 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeatfail like 85924 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass version targeted for testing: xen e46a729b18af85b4dd040578643f7fa430b22a48 baseline version: xen 6890e07e483673ec5f946b7c4654275707924d6d Last test of basis85924 2016-03-10 17:18:07 Z1 days Testing same since85995 2016-03-11 19:49:10 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Dario Faggioli David Vrabel Doug Goldstein George Dunlap Ian Jackson Jan Beulich Julien Grall Meng Xu Razvan Cojocaru Roger Pau Monne Stefano Stabellini Wei Liu jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i
Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops
* Andy Lutomirski wrote: > On Thu, Oct 1, 2015 at 12:15 AM, Ingo Molnar wrote: > > > > * Andy Lutomirski wrote: > > > >> > These could still be open coded in an inlined fashion, like the > >> > scheduler usage. > >> > >> We could have a raw_rdmsr for those. > >> > >> OTOH, I'm still not 100% convinced that this warn-but-don't-die behavior is > >> worth the effort. This isn't a frequent source of bugs to my knowledge, > >> and we > >> don't try to recover from incorrect cr writes, out-of-bounds MMIO, etc, so > >> do we > >> really gain much by rigging a recovery mechanism for rdmsr and wrmsr > >> failures > >> for code that doesn't use the _safe variants? > > > > It's just the general principle really: don't crash the kernel on bootup. > > There's > > few things more user hostile than that. > > > > Also, this would maintain the status quo: since we now (accidentally) don't > > crash > > the kernel on distro kernels (but silently and unsafely ignore the faulting > > instruction), we should not regress that behavior (by adding the chance to > > crash > > again), but improve upon it. > > Just a heads up: the extable improvements in tip:ras/core make it > straightforward to get the best of all worlds: explicit failure > handling (written in C!), no fast path overhead whatsoever, and no new > garbage in the exception handlers. I _knew_ I should have merged them into tip:x86/mm, not tip:ras/core ;-) I had a quick look at your new MSR series and I'm very happy with that direction! Thanks, Ingo ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops
* Andy Lutomirski wrote: > This demotes an OOPS and likely panic due to a failed non-"safe" MSR > access to a WARN and, for RDMSR, a return value of zero. If > panic_on_oops is set, then failed unsafe MSR accesses will still > oops and panic. > > To be clear, this type of failure should *not* happen. This patch > exists to minimize the chance of nasty undebuggable failures due on > systems that used to work due to a now-fixed CONFIG_PARAVIRT=y bug. > > Signed-off-by: Andy Lutomirski > --- > arch/x86/include/asm/msr.h | 10 -- > arch/x86/mm/extable.c | 33 + > 2 files changed, 41 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h > index 93fb7c1cffda..1487054a1a70 100644 > --- a/arch/x86/include/asm/msr.h > +++ b/arch/x86/include/asm/msr.h > @@ -92,7 +92,10 @@ static inline unsigned long long native_read_msr(unsigned > int msr) > { > DECLARE_ARGS(val, low, high); > > - asm volatile("rdmsr" : EAX_EDX_RET(val, low, high) : "c" (msr)); > + asm volatile("1: rdmsr\n" > + "2:\n" > + _ASM_EXTABLE_HANDLE(1b, 2b, ex_handler_rdmsr_unsafe) > + : EAX_EDX_RET(val, low, high) : "c" (msr)); > if (msr_tracepoint_active(__tracepoint_read_msr)) > do_trace_read_msr(msr, EAX_EDX_VAL(val, low, high), 0); > return EAX_EDX_VAL(val, low, high); > @@ -119,7 +122,10 @@ static inline unsigned long long > native_read_msr_safe(unsigned int msr, > static inline void native_write_msr(unsigned int msr, > unsigned low, unsigned high) > { > - asm volatile("wrmsr" : : "c" (msr), "a"(low), "d" (high) : "memory"); > + asm volatile("1: wrmsr\n" > + "2:\n" > + _ASM_EXTABLE_HANDLE(1b, 2b, ex_handler_wrmsr_unsafe) > + : : "c" (msr), "a"(low), "d" (high) : "memory"); > if (msr_tracepoint_active(__tracepoint_read_msr)) > do_trace_write_msr(msr, ((u64)high << 32 | low), 0); > } > diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c > index 9dd7e4b7fcde..f310714e6e6d 100644 > --- a/arch/x86/mm/extable.c > +++ b/arch/x86/mm/extable.c > @@ -49,6 +49,39 @@ bool ex_handler_ext(const struct exception_table_entry > *fixup, > } > EXPORT_SYMBOL(ex_handler_ext); > > +bool ex_handler_rdmsr_unsafe(const struct exception_table_entry *fixup, > + struct pt_regs *regs, int trapnr) > +{ > + WARN(1, "unsafe MSR access error: RDMSR from 0x%x", > + (unsigned int)regs->cx); Btw., instead of the safe/unsafe naming (which has an emotional and security secondary attribute), shouldn't we move this over to a _check() (or _checking()) naming instead that we do in other places in the kernel? I.e.: rdmsr(msr, l, h); and: if (rdmsr_check(msr, l, h)) { ... } and then we could name the helpers as _check() and _nocheck() - which is neutral naming. Thanks, Ingo ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops
* Andy Lutomirski wrote: > +bool ex_handler_rdmsr_unsafe(const struct exception_table_entry *fixup, > + struct pt_regs *regs, int trapnr) > +{ > + WARN(1, "unsafe MSR access error: RDMSR from 0x%x", > + (unsigned int)regs->cx); Please make this WARN_ONCE(). There's no point in locking up the system with WARN() spam, should this trigger frequently. > + WARN(1, "unsafe MSR access error: WRMSR to 0x%x (tried to write > 0x%08x%08x)\n", > + (unsigned int)regs->cx, > + (unsigned int)regs->dx, (unsigned int)regs->ax); Ditto. Thanks, Ingo ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1
On Sat, Mar 12, 2016 at 9:20 AM, Dushyant Behl wrote: > Hi Julien, > > Thanks for the quick reply. > > On Thu, Mar 10, 2016 at 10:38 AM, Julien Grall wrote: >> >> Hi Dushyant, >> >> On 09/03/2016 20:37, Wei Liu wrote: >>> >>> On Tue, Mar 08, 2016 at 08:23:29AM +, Dushyant K Behl wrote: I'm working on a research project with IBM, and I want to run Xen on Nvidia Tegra Jetson-tk1 board. I looked at a post on this mailing list (http://lists.xenproject.org/archives/ html/xen-devel/2015-03/msg01122.html), and I am using this git tree - git://xenbits.xen.org/people/ianc/xen.git and branch - tegra-tk1-jetson-v1 But when I try to boot Xen on the board I am not able to see any output (even with earlyprintk enabled). After jumping to Xen the board just resets without showing any output. I am using upstream u-boot with non secure mode enabled. I have also tested booting the Linux kernel on the same setup and Linux 4.0 is able to boot with all 4 cores in HYP mode and kvm enabled. Can anyone help me as to what I might have done wrong while using Xen? >> >> >> I never tried to boot Xen on Jetson-TK1 myself. >> >> Could you provide the command line you use to compile Xen (with >> earlyprintk enabled) and the U-boot runes? > > > I am running a ubuntu trusty schroot and I am using the Ubuntu/Linaro > arm-linux-gnueabihf-gcc 4.7.3 > as the cross compiler to compile everything. The tree which I pointed > towards (in my previous mail) > contains the earlyprintk configurations for Jetson-TK1, so I am using this > command to compile Xen with earlyprintk - > > make dist-xen debug=y CONFIG_EARLY_PRINTK=jetson XEN_TARGET_ARCH=arm32 > > I want to update my current stage with Xen, after using this toolchain I am > able to get Xen to print output > on the Jetson-TK1's serial console and Xen is able to boot correctly with > all 4 cores in HYP mode. > > But the problem is when Xen tries to boot the dom0 kernel and transfer > control, I receive no output on the serial port. > I am using Linux 4.1.0 as the dom0 kernel and the kernel is compiled with > Xen specific options enabled. > Also the same linux kernel is able to boot on the board without Xen. > > I am passing the dom0 kernel argument to Xen in the /chosen node in the > device tree using these commands - > > fdt mknod /chosen module > fdt set /chosen/module compatible "xen,linux-zimage" "xen,multiboot-module" > fdt set /chosen/module reg <0x0 $kernel_addr_r 0x0 0x$filesize> > fdt set /chosen/module bootargs "$bootargs" I haven't run Xen on ARM yet. But just a random thought: Is it possible that you need to provide the console=hvc0 for the boot cmdline of dom0? dom0 needs share the serial port with Xen. > > I am loading Xen at top of the ram and linux and device tree at their > default locations (near starting of ram). > > This is the Xen BootLog which I receive through the earlyprintk serial port > - > > - UART enabled - > - CPU booting - > - Xen starting in Hyp mode - > - Zero BSS - > - Setting up control registers - > - CPU Init Done -- Turning on paging - > - Ready - > (XEN) Checking for initrd in /chosen > (XEN) RAM: 8000 - ffef > (XEN) > (XEN) MODULE[0]: 8200 - 8201 Device Tree > (XEN) MODULE[1]: 8100 - 8158 Kernel > (XEN) RESVD[0]: 8200 - 8201 > (XEN) > (XEN) Command line: > (XEN) Placing Xen at 0xffc0-0xffe0 > (XEN) Update BOOTMOD_XEN from fd00-fd0f9701 => > ffc0-ffcf9701 > (XEN) Xen heap: fa00-fe00 (16384 pages) > (XEN) Dom heap: 507648 pages > (XEN) Domain heap initialised > (XEN) Platform: TEGRA124 > (XEN) No dtuart path configured > (XEN) Bad console= option 'dtuart' > Xen 4.6-unstable > (XEN) Xen version 4.6-unstable (root@) (arm-linux-gnueabihf-gcc > (Ubuntu/Linaro 4.7.3-11ubuntu1) 4.7.3) debug=y Fri Mar 11 10:09:07 UTC 2016 > (XEN) Latest ChangeSet: > (XEN) Processor: 413fc0f3: "ARM Limited", variant: 0x3, part 0xc0f, rev 0x3 > (XEN) 32-bit Execution: > (XEN) Processor Features: 1131:00011011 > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle > (XEN) Extensions: GenericTimer Security > (XEN) Debug Features: 02010555 > (XEN) Auxiliary Features: > (XEN) Memory Model Features: 10201105 4000 0124 02102211 > (XEN) ISA Features: 02101110 13112111 21232041 2131 10011142 > (XEN) Using PSCI-0.1 for SMP bringup > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 12000 KHz > (XEN) GICv2 initialization: > (XEN) gic_dist_addr=50041000 > (XEN) gic_cpu_addr=50042000 > (XEN) gic_hyp_addr=50044000 > (XEN) gic_vcpu_addr=50046000 > (XEN) gic_maintenance_irq=25 > (XEN) GICv2: 192 lines, 4 cpus, secure (IID 043b). > (XEN)
Re: [Xen-devel] [PATCH 3/3] xenalyze: handle RTDS scheduler events
On Sat, Mar 12, 2016 at 6:34 AM, Dario Faggioli wrote: > so the trace will show properly decoded info, > rather than just a bunch of hex codes. > > Signed-off-by: Dario Faggioli > Reviewed-by: Konrad Rzeszutek Wilk > --- > Cc: George Dunlap > Cc: Meng Xu > Cc: Tianyang Chen > Cc: Ian Jackson > Cc: Wei Liu > --- > Changes from v2: > * use 64 bits ints for time values (now that the scheduler >does that too), as suggested during review. > > Changes from v1: > * '} * r =' turned into '} *r =', as requested >during review. > --- Reviewed-by: Meng Xu Thanks, --- Meng Xu PhD Student in Computer and Information Science University of Pennsylvania http://www.cis.upenn.edu/~mengxu/ ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/3] xen: sched RTDS: use uint64_t for tracing time values
On Sat, Mar 12, 2016 at 6:34 AM, Dario Faggioli wrote: > such as deadline and budget. Packing is necessary to make > it possible for xentrace_format to properly interpreet the > records. > > Signed-off-by: Dario Faggioli > --- > Cc: George Dunlap > Cc: Meng Xu > --- Reviewed-by: Meng Xu --- Meng Xu PhD Student in Computer and Information Science University of Pennsylvania http://www.cis.upenn.edu/~mengxu/ ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/3] xenalyze: handle DOM0 operaions events
Typo in email title "operaions". Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] tools: don't use qemu default config
On Fri, Mar 11, 2016 at 03:08:30PM -0700, Jim Fehlig wrote: > I recently changed SUSE's Xen package to use the distro qemu instead of > building > qemu-xen. This got some other eyes looking at Xen's use of qemu and it was > noticed that libxl and xen-qemu-dom0-disk-backend.service do not include > '-no-user-config' when invoking qemu. The latter also does not include > '-nodefaults'. Commit 6ef823fd added '-nodefaults' to the qemu args created by > libxl, but missed adding it to the qemu args in > xen-qemu-dom0-disk-backend.service. > Right. That's probably an oversight. > I _think_ adding '-nodefaults' to the qemu args in the service file is > non-controversial. What do folks think of also adding '-no-user-config'? It > seems the global config in /etc/qemu/qemu.conf would end up being more > problematic than helpful for Xen. > > As a side note, the libvirt qemu driver includes '-no-user-config -nodefaults' > in all its qemu invocations to avoid configuration which it doesn't control. > I think this is also a sensible thing to do. > WRT qemu args, another suggestion was to explicitly specify 'accel=xen' in the > machine arg. Together, these changes would e.g. result in the service file > qemu > args changing slightly to > > -machine xenpv,accel=xen -xen-domid 0 -xen-attach -name dom0 \ > -daemonize -no-user-config -nodefaults -display none \ > -pidfile /var/run/xen/qemu-dom0.pid > As for accel=xen, that's not strictly necessary because that's the default machine option for xenpv machine. > If folks agree with these changes, I'll be happy to provide a patches for > libxl > and the systemd service file. Thanks for your comments. > > Regards, > Jim ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1
Hi Julien, Thanks for the quick reply. On Thu, Mar 10, 2016 at 10:38 AM, Julien Grall wrote: > Hi Dushyant, > > On 09/03/2016 20:37, Wei Liu wrote: > >> On Tue, Mar 08, 2016 at 08:23:29AM +, Dushyant K Behl wrote: >> >>> I'm working on a research project with IBM, and I want to run Xen on >>> Nvidia >>> Tegra Jetson-tk1 board. >>> I looked at a post on this mailing list ( >>> http://lists.xenproject.org/archives/ >>> html/xen-devel/2015-03/msg01122.html), >>> and I am using this git tree - >>> >>> git://xenbits.xen.org/people/ianc/xen.git >>> and branch - tegra-tk1-jetson-v1 >>> >>> But when I try to boot Xen on the board I am not able to see any output >>> (even >>> with earlyprintk enabled). >>> After jumping to Xen the board just resets without showing any output. >>> >>> I am using upstream u-boot with non secure mode enabled. I have also >>> tested >>> booting the Linux kernel on the same setup >>> and Linux 4.0 is able to boot with all 4 cores in HYP mode and kvm >>> enabled. >>> >>> Can anyone help me as to what I might have done wrong while using Xen? >>> >> > I never tried to boot Xen on Jetson-TK1 myself. > > Could you provide the command line you use to compile Xen (with > earlyprintk enabled) and the U-boot runes? > I am running a ubuntu trusty schroot and I am using the Ubuntu/Linaro arm-linux-gnueabihf-gcc 4.7.3 as the cross compiler to compile everything. The tree which I pointed towards (in my previous mail) contains the earlyprintk configurations for Jetson-TK1, so I am using this command to compile Xen with earlyprintk - make dist-xen debug=y CONFIG_EARLY_PRINTK=jetson XEN_TARGET_ARCH=arm32 I want to update my current stage with Xen, after using this toolchain I am able to get Xen to print output on the Jetson-TK1's serial console and Xen is able to boot correctly with all 4 cores in HYP mode. But the problem is when Xen tries to boot the dom0 kernel and transfer control, I receive no output on the serial port. I am using Linux 4.1.0 as the dom0 kernel and the kernel is compiled with Xen specific options enabled. Also the same linux kernel is able to boot on the board without Xen. I am passing the dom0 kernel argument to Xen in the /chosen node in the device tree using these commands - fdt mknod /chosen module fdt set /chosen/module compatible "xen,linux-zimage" "xen,multiboot-module" fdt set /chosen/module reg <0x0 $kernel_addr_r 0x0 0x$filesize> fdt set /chosen/module bootargs "$bootargs" I am loading Xen at top of the ram and linux and device tree at their default locations (near starting of ram). This is the Xen BootLog which I receive through the earlyprintk serial port - - UART enabled - - CPU booting - - Xen starting in Hyp mode - - Zero BSS - - Setting up control registers - - CPU Init Done -- Turning on paging - - Ready - (XEN) Checking for initrd in /chosen (XEN) RAM: 8000 - ffef (XEN) (XEN) MODULE[0]: 8200 - 8201 Device Tree (XEN) MODULE[1]: 8100 - 8158 Kernel (XEN) RESVD[0]: 8200 - 8201 (XEN) (XEN) Command line: (XEN) Placing Xen at 0xffc0-0xffe0 (XEN) Update BOOTMOD_XEN from fd00-fd0f9701 => ffc0-ffcf9701 (XEN) Xen heap: fa00-fe00 (16384 pages) (XEN) Dom heap: 507648 pages (XEN) Domain heap initialised (XEN) Platform: TEGRA124 (XEN) No dtuart path configured (XEN) Bad console= option 'dtuart' Xen 4.6-unstable (XEN) Xen version 4.6-unstable (root@) (arm-linux-gnueabihf-gcc (Ubuntu/Linaro 4.7.3-11ubuntu1) 4.7.3) debug=y Fri Mar 11 10:09:07 UTC 2016 (XEN) Latest ChangeSet: (XEN) Processor: 413fc0f3: "ARM Limited", variant: 0x3, part 0xc0f, rev 0x3 (XEN) 32-bit Execution: (XEN) Processor Features: 1131:00011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 02010555 (XEN) Auxiliary Features: (XEN) Memory Model Features: 10201105 4000 0124 02102211 (XEN) ISA Features: 02101110 13112111 21232041 2131 10011142 (XEN) Using PSCI-0.1 for SMP bringup (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 12000 KHz (XEN) GICv2 initialization: (XEN) gic_dist_addr=50041000 (XEN) gic_cpu_addr=50042000 (XEN) gic_hyp_addr=50044000 (XEN) gic_vcpu_addr=50046000 (XEN) gic_maintenance_irq=25 (XEN) GICv2: 192 lines, 4 cpus, secure (IID 043b). (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) I/O virtualisation disabled (XEN) Allocated console ring of 32 KiB. (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0 (XEN) Bringing up CPU1 - CPU 0001 booting - - Xen starting in Hyp mode - - Setting up control registers - - CPU Init Done -- Turning on paging - - Ready - (XEN) CPU 1 booted. (XEN) Bringing up CPU2 - CPU 0002 booting - - Xen starting in Hyp m
[Xen-devel] [xen-4.4-testing test] 85990: regressions - FAIL
flight 85990 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/85990/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 16 guest-start.2fail REGR. vs. 85031 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail in 85888 pass in 85990 test-amd64-amd64-xl-qemuu-win7-amd64 9 windows-install fail pass in 85888 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-localmigrate fail in 85888 REGR. vs. 85031 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 85031 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 85031 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a build-amd64-rumpuserxen 6 xen-buildfail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass build-i386-rumpuserxen6 xen-buildfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 11 guest-start fail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass version targeted for testing: xen 0ae1e719118d8aa6754b19fb388038632fa768b3 baseline version: xen 83c5e46c5d6af7adc4bc46cf41e415e34846c719 Last test of basis85031 2016-03-02 06:38:02 Z 10 days Testing same since85888 2016-03-10 07:45:07 Z2 days2 attempts People who touched revisions under test: Konrad Rzeszutek Wilk jobs: build-amd64-xend pass build-i386-xend 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 build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64
[Xen-devel] [PATCH 3/3] xenalyze: handle RTDS scheduler events
so the trace will show properly decoded info, rather than just a bunch of hex codes. Signed-off-by: Dario Faggioli Reviewed-by: Konrad Rzeszutek Wilk --- Cc: George Dunlap Cc: Meng Xu Cc: Tianyang Chen Cc: Ian Jackson Cc: Wei Liu --- Changes from v2: * use 64 bits ints for time values (now that the scheduler does that too), as suggested during review. Changes from v1: * '} * r =' turned into '} *r =', as requested during review. --- tools/xentrace/xenalyze.c | 52 + 1 file changed, 52 insertions(+) diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c index 353bed7..b949986 100644 --- a/tools/xentrace/xenalyze.c +++ b/tools/xentrace/xenalyze.c @@ -7823,6 +7823,58 @@ void sched_process(struct pcpu_info *p) r->rq_avgload, r->b_avgload); } break; +/* RTDS (TRC_RTDS_xxx) */ +case TRC_SCHED_CLASS_EVT(RTDS, 1): /* TICKLE */ +if(opt.dump_all) { +struct { +unsigned int cpu:16; +} *r = (typeof(r))ri->d; + +printf(" %s rtds:runq_tickle cpu %u\n", + ri->dump_header, r->cpu); +} +break; +case TRC_SCHED_CLASS_EVT(RTDS, 2): /* RUNQ_PICK*/ +if(opt.dump_all) { +struct { +unsigned int vcpuid:16, domid:16; +uint64_t cur_dl, cur_bg; +} __attribute__((packed)) *r = (typeof(r))ri->d; + +printf(" %s rtds:runq_pick d%uv%u, deadline = %"PRIu64", " + "budget = %"PRIu64"\n", ri->dump_header, + r->domid, r->vcpuid, r->cur_dl, r->cur_bg); +} +break; +case TRC_SCHED_CLASS_EVT(RTDS, 3): /* BUDGET_BURN */ +if(opt.dump_all) { +struct { +unsigned int vcpuid:16, domid:16; +uint64_t cur_bg; +int delta; +} __attribute__((packed)) *r = (typeof(r))ri->d; + +printf(" %s rtds:burn_budget d%uv%u, budget = %"PRIu64", " + "delta = %d\n", ri->dump_header, r->domid, + r->vcpuid, r->cur_bg, r->delta); +} +break; +case TRC_SCHED_CLASS_EVT(RTDS, 4): /* BUDGET_REPLENISH */ +if(opt.dump_all) { +struct { +unsigned int vcpuid:16, domid:16; +uint64_t cur_dl, cur_bg; +} __attribute__((packed)) *r = (typeof(r))ri->d; + +printf(" %s rtds:repl_budget d%uv%u, deadline = %"PRIu64", " + "budget = %"PRIu64"\n", ri->dump_header, + r->domid, r->vcpuid, r->cur_dl, r->cur_bg); +} +break; +case TRC_SCHED_CLASS_EVT(RTDS, 5): /* SCHED_TASKLET*/ +if(opt.dump_all) +printf(" %s rtds:sched_tasklet\n", ri->dump_header); +break; default: process_generic(ri); } ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/3] xenalyze: handle DOM0 operaions events
(i.e., domain creation and destruction) so the trace will show properly decoded info, rather than just a bunch of hex codes. --- Cc: George Dunlap Cc: Ian Jackson Cc: Wei Liu Cc: Konrad Rzeszutek Wilk --- Changes from v1: * new patch in the series. --- tools/xentrace/xenalyze.c | 26 ++ 1 file changed, 26 insertions(+) diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c index d4a5b0c..353bed7 100644 --- a/tools/xentrace/xenalyze.c +++ b/tools/xentrace/xenalyze.c @@ -8388,6 +8388,30 @@ void hw_process(struct pcpu_info *p) } } + +#define TRC_DOM0_SUB_DOMOPS 1 +void dom0_process(struct pcpu_info *p) +{ +struct record_info *ri = &p->ri; + +switch(ri->evt.sub) +{ +case TRC_DOM0_SUB_DOMOPS: +if(opt.dump_all) { +struct { +unsigned int domid; +} *r = (typeof(r))ri->d; + +printf(" %s %s domain d%u\n", ri->dump_header, + ri->event == TRC_DOM0_DOM_ADD ? "creating" : "destroying", + r->domid); +} +break; +default: +process_generic(&p->ri); +} +} + /* Base - */ void dump_generic(FILE * f, struct record_info *ri) { @@ -9224,6 +9248,8 @@ void process_record(struct pcpu_info *p) { hw_process(p); break; case TRC_DOM0OP_MAIN: +dom0_process(p); +break; default: process_generic(ri); } ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/3] xen: more scheduler tracing improvement
Hi, this is what remained uncommitted of these other series: "Scheduling related tracing improvements" v1: http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01016.html v2: http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg02233.html What is patch 1 here, was there already in v2 of the previous submission, but it did not got reviewed. What is patch 2 here, was not there before. George suggested doing it, to do better what is done in what is patch 3 here (which was there before, in a slightly different form). Thanks and Regards, Dario --- Dario Faggioli (3): xenalyze: handle DOM0 operaions events xen: sched RTDS: use uint64_t for tracing time values xenalyze: handle RTDS scheduler events tools/xentrace/xenalyze.c | 78 + xen/common/sched_rt.c | 30 ++--- 2 files changed, 89 insertions(+), 19 deletions(-) -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/3] xen: sched RTDS: use uint64_t for tracing time values
such as deadline and budget. Packing is necessary to make it possible for xentrace_format to properly interpreet the records. Signed-off-by: Dario Faggioli --- Cc: George Dunlap Cc: Meng Xu --- xen/common/sched_rt.c | 30 +++--- 1 file changed, 11 insertions(+), 19 deletions(-) diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c index bfed2e2..8e51abe 100644 --- a/xen/common/sched_rt.c +++ b/xen/common/sched_rt.c @@ -361,17 +361,14 @@ rt_update_deadline(s_time_t now, struct rt_vcpu *svc) /* TRACE */ { -struct { +struct __packed { unsigned vcpu:16, dom:16; -unsigned cur_deadline_lo, cur_deadline_hi; -unsigned cur_budget_lo, cur_budget_hi; +uint64_t cur_deadline, cur_budget; } d; d.dom = svc->vcpu->domain->domain_id; d.vcpu = svc->vcpu->vcpu_id; -d.cur_deadline_lo = (unsigned) svc->cur_deadline; -d.cur_deadline_hi = (unsigned) (svc->cur_deadline >> 32); -d.cur_budget_lo = (unsigned) svc->cur_budget; -d.cur_budget_hi = (unsigned) (svc->cur_budget >> 32); +d.cur_deadline = (uint64_t) svc->cur_deadline; +d.cur_budget = (uint64_t) svc->cur_budget; trace_var(TRC_RTDS_BUDGET_REPLENISH, 1, sizeof(d), (unsigned char *) &d); @@ -711,16 +708,14 @@ burn_budget(const struct scheduler *ops, struct rt_vcpu *svc, s_time_t now) /* TRACE */ { -struct { +struct __packed { unsigned vcpu:16, dom:16; -unsigned cur_budget_lo; -unsigned cur_budget_hi; +uint64_t cur_budget; int delta; } d; d.dom = svc->vcpu->domain->domain_id; d.vcpu = svc->vcpu->vcpu_id; -d.cur_budget_lo = (unsigned) svc->cur_budget; -d.cur_budget_hi = (unsigned) (svc->cur_budget >> 32); +d.cur_budget = (uint64_t) svc->cur_budget; d.delta = delta; trace_var(TRC_RTDS_BUDGET_BURN, 1, sizeof(d), @@ -763,17 +758,14 @@ __runq_pick(const struct scheduler *ops, const cpumask_t *mask) { if( svc != NULL ) { -struct { +struct __packed { unsigned vcpu:16, dom:16; -unsigned cur_deadline_lo, cur_deadline_hi; -unsigned cur_budget_lo, cur_budget_hi; +uint64_t cur_deadline, cur_budget; } d; d.dom = svc->vcpu->domain->domain_id; d.vcpu = svc->vcpu->vcpu_id; -d.cur_deadline_lo = (unsigned) svc->cur_deadline; -d.cur_deadline_hi = (unsigned) (svc->cur_deadline >> 32); -d.cur_budget_lo = (unsigned) svc->cur_budget; -d.cur_budget_hi = (unsigned) (svc->cur_budget >> 32); +d.cur_deadline = (uint64_t) svc->cur_deadline; +d.cur_budget = (uint64_t) svc->cur_budget; trace_var(TRC_RTDS_RUNQ_PICK, 1, sizeof(d), (unsigned char *) &d); ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-linus test] 85988: regressions - FAIL
flight 85988 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/85988/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254 build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 59254 test-amd64-amd64-xl-credit2 15 guest-localmigratefail REGR. vs. 59254 test-amd64-i386-xl 15 guest-localmigratefail REGR. vs. 59254 test-amd64-amd64-xl-xsm 15 guest-localmigratefail REGR. vs. 59254 test-amd64-amd64-xl 15 guest-localmigratefail REGR. vs. 59254 test-amd64-i386-xl-xsm 15 guest-localmigratefail REGR. vs. 59254 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate fail REGR. vs. 59254 test-amd64-amd64-pair 22 guest-migrate/dst_host/src_host fail REGR. vs. 59254 test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-cubietruck 6 xen-bootfail REGR. vs. 59254 test-armhf-armhf-xl-multivcpu 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-xsm 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail REGR. vs. 59254 test-amd64-i386-pair 22 guest-migrate/dst_host/src_host fail REGR. vs. 59254 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 59254 test-armhf-armhf-xl-rtds 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline untested test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline untested test-armhf-armhf-xl-vhd 6 xen-bootfail baseline untested test-amd64-i386-libvirt-xsm 15 guest-saverestore.2 fail blocked in 59254 test-amd64-amd64-libvirt 15 guest-saverestore.2 fail blocked in 59254 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2 fail blocked in 59254 test-amd64-i386-libvirt 15 guest-saverestore.2 fail blocked in 59254 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 59254 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass version targeted for testing: linuxf2c1242194c7af9b26f53359ab2b23df36d3a643 baseline version: linux45820c294fe1b1a9df495d57f40585ef2d069a39 Last test of basis59254 2015-07-09 04:20:48 Z 247 days Failing since 59348 2015-07-10 04:24:05 Z 246 days 174 attempts Testing same since85988 2016-03-11 09:18:08 Z1 days1 attempts 4179 people touched revisions under
Re: [Xen-devel] [patch 1/4] hotplug: Prevent alloc/free of irq descriptors during cpu up/down
Boris, On Tue, 14 Jul 2015, Boris Ostrovsky wrote: > On 07/14/2015 04:15 PM, Thomas Gleixner wrote: > > > > The issue here is that all architectures need that protection and just > > > > Xen does irq allocations in cpu_up. > > > > > > > > So moving that protection into architecture code is not really an > > > > option. > > > > > > > > > > > Otherwise we will need to have something like arch_post_cpu_up() > > > > > > > after the lock is released. > > > > I'm not sure, that this will work. You probably want to do this in the > > > > cpu prepare stage, i.e. before calling __cpu_up(). > > > For PV guests (the ones that use xen_cpu_up()) it will work either before > > > or > > > after __cpu_up(). At least my (somewhat limited) testing didn't show any > > > problems so far. > > > > > > However, HVM CPUs use xen_hvm_cpu_up() and if you read comments there you > > > will > > > see that xen_smp_intr_init() needs to be called before native_cpu_up() but > > > xen_init_lock_cpu() (which eventually calls irq_alloc_descs()) needs to be > > > called after. > > > > > > I think I can split xen_init_lock_cpu() so that the part that needs to be > > > called after will avoid going into irq core code. And then the rest will > > > go > > > into arch_cpu_prepare(). > > I think we should revisit this for 4.3. For 4.2 we can do the trivial > > variant and move the locking in native_cpu_up() and x86 only. x86 was > > the only arch on which such wreckage has been seen in the wild, but we > > should have that protection for all archs in the long run. > > > > Patch below should fix the issue. > > Thanks! Most of my tests passed, I had a couple of failures but I will need to > see whether they are related to this patch. Did you ever come around to address that irq allocation from within cpu_up()? I really want to generalize the protection instead of carrying that x86 only hack forever. Thanks, tglx ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [distros-debian-stretch test] 44244: trouble: blocked/broken
flight 44244 distros-debian-stretch real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44244/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-pvops 3 host-install(3) broken REGR. vs. 44222 build-armhf-pvops 3 host-install(3) broken REGR. vs. 44222 build-armhf 3 host-install(3) broken REGR. vs. 44222 build-amd64 3 host-install(3) broken REGR. vs. 44222 build-i386-pvops 3 host-install(3) broken REGR. vs. 44222 build-i3863 host-install(3) broken REGR. vs. 44222 Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-stretch-netboot-pygrub 1 build-check(1)blocked n/a test-amd64-i386-i386-stretch-netboot-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-amd64-stretch-netboot-pvgrub 1 build-check(1)blocked n/a test-amd64-i386-amd64-stretch-netboot-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-i386-stretch-netboot-pygrub 1 build-check(1) blocked n/a baseline version: flight 44222 jobs: build-amd64 broken build-armhf broken build-i386 broken build-amd64-pvopsbroken build-armhf-pvopsbroken build-i386-pvops broken test-amd64-amd64-amd64-stretch-netboot-pvgrubblocked test-amd64-i386-i386-stretch-netboot-pvgrub blocked test-amd64-i386-amd64-stretch-netboot-pygrub blocked test-armhf-armhf-armhf-stretch-netboot-pygrubblocked test-amd64-amd64-i386-stretch-netboot-pygrub blocked 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 http://lists.xen.org/xen-devel