[Xen-devel] [xen-4.4-testing test] 86050: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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
 

[Xen-devel] [linux-linus test] 86047: regressions - FAIL

[osstest service owner]

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

[Platform Team regression test user]

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 

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

[Meng Xu]

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: 

[Xen-devel] [xen-4.3-testing test] 86035: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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
 

[Xen-devel] [linux-mingo-tip-master test] 86030: regressions - FAIL

[osstest service owner]

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

[Chen, Tianyang]

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

[Andrew Cooper]

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

[Chen, Tianyang]

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

[osstest service owner]

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

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

[Dushyant Behl]

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)   

[Xen-devel] [linux-4.1 test] 86019: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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:
 

[Xen-devel] [PATCH v4 4/5] x86/paravirt: Make "unsafe" MSR accesses unsafe even if PARAVIRT=y

[Andy Lutomirski]

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

[Andy Lutomirski]

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

[Andy Lutomirski]

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, );
+   *p = paravirt_read_msr_safe(msr, );
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 = 

[Xen-devel] [PATCH v4 3/5] x86/paravirt: Add paravirt_{read, write}_msr

[Andy Lutomirski]

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, );
+}
+
+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

[Andy Lutomirski]

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

[Andy Lutomirski]

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

[osstest service owner]

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
+ 

Re: [Xen-devel] [PATCH v3 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

[Andy Lutomirski]

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

[osstest service owner]

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 

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

[Ingo Molnar]

* 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

[Ingo Molnar]

* 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

[Ingo Molnar]

* 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

[Meng Xu]

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) 

Re: [Xen-devel] [PATCH 3/3] xenalyze: handle RTDS scheduler events

[Meng Xu]

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

[Meng Xu]

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

[Wei Liu]

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

[Wei Liu]

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

[Dushyant Behl]

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-devel] [xen-4.4-testing test] 85990: regressions - FAIL

[osstest service owner]

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
 

[Xen-devel] [PATCH 3/3] xenalyze: handle RTDS scheduler events

[Dario Faggioli]

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

[Dario Faggioli]

(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 = >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(>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

[Dario Faggioli]

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

[Dario Faggioli]

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 *) );
@@ -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 *) );


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

[Xen-devel] [linux-linus test] 85988: regressions - FAIL

[osstest service owner]

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 

Re: [Xen-devel] [patch 1/4] hotplug: Prevent alloc/free of irq descriptors during cpu up/down

[Thomas Gleixner]

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

[Platform Team regression test user]

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