[Xen-devel] [qemu-mainline test] 143104: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 142915
 test-amd64-amd64-xl-pvshim   12 guest-start  fail REGR. vs. 142915

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 16 guest-localmigrate   fail REGR. vs. 142915

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds   16 guest-start/debian.repeat fail blocked in 142915
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 142915
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 142915
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 142915
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 142915
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 142915
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuuea0ec714d3109e0d0523b9dacb38030e4cb142a8
baseline version:
 qemuue9d42461920f6f40f4d847a5ba18e90d095ed0b9

Last test of basis   142915  2019-10-19 14:49:41 Z5 days
Failing since143030  2019-10-22 11:08:39 Z2 days4 attempts
Testing same since   143104  2019-10-24 12:17:20 Z0 days1 attempts

Re: [Xen-devel] Debugging Windows HVM crashes on Ryzen 3xxx series CPUs.

[Steven Haigh]

Just to make things annoying, I also get the following message in the 
logs for correctly operating Linux PVH DomU's:


(XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x2600, fault 
address = 0xfffdf800, flags = 0x8


As such, I think we're back to zero clues at the moment as to what is 
going on.


Suggestions welcome :)

On 2019-10-25 01:45, Paul Durrant wrote:

Not much clue in the logs. The crash params are weird though...
certainly not matching the doc.
(https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0xac--hal-memory-allocation)
but then again they are not always to be believed.
There are some odd looking IOMMU faults in there too.

 Paul

On Thu, 24 Oct 2019 at 13:01, Steven Haigh  wrote:


Hi all,

I've managed to get the git master version of Xen on this affected
system and tries to boot a Windows Server 2016 system. It crashes as

per normal.

I managed to get these logs, but I'm not quite sure what else to do
to
debug this issue further.

Suggestions welcome.

The boot log in /var/log/xen/ shows:
Waiting for domain soti.vm (domid 4) to die [pid 9174]
Domain 4 has shut down, reason code 3 0x3
Action for shutdown reason code 3 is destroy
Domain 4 needs to be cleaned up: destroying the domain
Done. Exiting now

For some reason I'm not getting any serial output - so I'll have to
take a look at that tomorrow - but if you need anything further,
please
let me know and I'll see what I can turn up.

Windows config file:

type = "hvm"
name = "$vmname.vm"
viridian = 1
#viridian = ['base']
memory = 8192
vcpus = 4
vif = ['bridge=br51, mac=00:16:3E:64:CC:A0']
#disk = [ '/dev/vg_hosting/$vmname.vm,raw,xvda,rw',


'file:/root/SW_DVD9_NTRL_Windows_Svrs_2016_English_2_Std_DC_FPP_OEM_X21-22567.ISO,hdc:cdrom,r'


]
disk = [ '/dev/vg_hosting/$vmname.vm,raw,hda,rw' ]
boot = 'cd'
vnc = 2
vnclisten = "0.0.0.0"
#vncpasswd = ''

## Set the clock to localtime - not UTC...
localtime = 1

## Fix the mouse cursor for VNC usage
usbdevice = 'tablet'

## Lower CPU prio that other VMs...
cpu_weight = 128

on_poweroff = 'destroy'
on_reboot = 'destroy'
on_crash = 'destroy'

Steven Haigh

 net...@crc.id.au  https://www.crc.id.au
 +613 9001 6090    +614 1293 5897

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

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


--
Steven Haigh

? net...@crc.id.au ? http://www.crc.id.au
? +61 (3) 9001 6090? 0412 935 897

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

[Xen-devel] [libvirt bisection] complete build-amd64-libvirt

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job build-amd64-libvirt
testid libvirt-build

Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  libvirt git://libvirt.org/libvirt.git
  Bug introduced:  3097282d8668693eb4b7c3fb1b4fe5b474996b9c
  Bug not present: 32ea231b21d8d7b88d2f2a7d57916098baf8cfa2
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/143136/


  commit 3097282d8668693eb4b7c3fb1b4fe5b474996b9c
  Author: Pavel Hrdina 
  Date:   Tue Oct 15 12:41:29 2019 +0200
  
  build: move admin code into admin directory
  
  There is no need to have the libvirt-admin.so library definition in the
  src directory.  In addition the library uses directly code from admin
  sub-directory so move the remaining bits there as well.
  
  Signed-off-by: Pavel Hrdina 
  Reviewed-by: Ján Tomko 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/libvirt/build-amd64-libvirt.libvirt-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/libvirt/build-amd64-libvirt.libvirt-build 
--summary-out=tmp/143136.bisection-summary --basis-template=143023 
--blessings=real,real-bisect libvirt build-amd64-libvirt libvirt-build
Searching for failure / basis pass:
 143085 fail [host=italia0] / 143051 [host=huxelrebe1] 143023 [host=debina0] 
142949 [host=huxelrebe1] 142904 ok.
Failure / basis pass flights: 143085 / 142904
(tree with no url: minios)
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Latest b3739aa63f89fdb426226027f0b244cb15c1ea10 
1f6fb368c04919243e2c70f2aa514a5f88e95309 
6280c94f306df6a20bbc100ba15a5a81af0366e6 
53b1dd1036df3839d46bb150f7a8b2037390093a 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
933ebad2470a169504799a1d95b8e410bd9847ef 
120996f147131eca8af90e30c900bc14bc824d9f 
518c935fac4d30b3ec35d4b6add82b17b7d7aca3
Basis pass 313a71ee7b424126a4507b12335fd77b51dab433 
1f6fb368c04919243e2c70f2aa514a5f88e95309 
6280c94f306df6a20bbc100ba15a5a81af0366e6 
e026bb4c39a28ca9be5dc994c14bb21cc283c9e8 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
933ebad2470a169504799a1d95b8e410bd9847ef 
43f5df79dad6738d52ea79d072de2b56eb96a91f 
518c935fac4d30b3ec35d4b6add82b17b7d7aca3
Generating revisions with ./adhoc-revtuple-generator  
git://libvirt.org/libvirt.git#313a71ee7b424126a4507b12335fd77b51dab433-b3739aa63f89fdb426226027f0b244cb15c1ea10
 
https://git.savannah.gnu.org/git/gnulib.git/#1f6fb368c04919243e2c70f2aa514a5f88e95309-1f6fb368c04919243e2c70f2aa514a5f88e95309
 
https://gitlab.com/keycodemap/keycodemapdb.git#6280c94f306df6a20bbc100ba15a5a81af0366e6-6280c94f306df6a20bbc100ba15a5a81af0366e6
 git://xenbits.xen.org/osstest/ovmf.git#e026bb4c39a28ca9be5dc994c14bb21cc283c9e\
 8-53b1dd1036df3839d46bb150f7a8b2037390093a 
git://xenbits.xen.org/qemu-xen-traditional.git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798
 
git://xenbits.xen.org/qemu-xen.git#933ebad2470a169504799a1d95b8e410bd9847ef-933ebad2470a169504799a1d95b8e410bd9847ef
 
git://xenbits.xen.org/osstest/seabios.git#43f5df79dad6738d52ea79d072de2b56eb96a91f-120996f147131eca8af90e30c900bc14bc824d9f
 
git://xenbits.xen.org/xen.git#518c935fac4d30b3ec35d4b6add82b17b7d7aca3-518c935fac4d30b3\
 ec35d4b6add82b17b7d7aca3
>From git://cache:9419/git://libvirt.org/libvirt
 - [deleted]   (none) -> origin/osstest/frozen/xen-4.0-testing
 - [deleted]   (none) -> origin/osstest/frozen/xen-4.1-testing
 - [deleted]   (none) -> origin/osstest/frozen/xen-4.10-testing
 - [deleted]   (none) -> origin/osstest/frozen/xen-4.11-testing
 - [deleted]   (none) -> origin/osstest/frozen/xen-4.12-testing
 - [deleted]   (none) -> origin/osstest/frozen/xen-4.2-testing
 - [deleted]   (none) -> origin/osstest/frozen/xen-4.3-testing
 - [deleted]   (none) -> origin/osstest/frozen/xen-4.4-testing
 - [deleted]   (none) -> origin/osstest/frozen/xen-4.5-testing
 - [deleted]   (none) 

[Xen-devel] [linux-4.4 test] 143097: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail in 143009 REGR. vs. 
139698

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt-pair 21 guest-start/debian fail in 142901 pass in 
143097
 test-armhf-armhf-libvirt-raw 10 debian-di-install fail in 142901 pass in 143097
 test-amd64-amd64-xl-pvshim 16 guest-localmigrate fail in 143063 pass in 143009
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 143063 pass in 
143097
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail pass in 142901
 test-amd64-amd64-xl-pvshim   12 guest-startfail pass in 143063
 test-armhf-armhf-xl   8 host-ping-check-xenfail pass in 143063
 test-armhf-armhf-xl-cubietruck  7 xen-boot fail pass in 143063
 test-armhf-armhf-xl-vhd  10 debian-di-install  fail pass in 143063

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl 13 migrate-support-check fail in 143063 never pass
 test-armhf-armhf-xl 14 saverestore-support-check fail in 143063 never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail in 143063 never 
pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail in 143063 
never pass
 test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 143063 never pass
 test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 143063 never pass
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-arm64-arm64-examine  8 reboot   fail   never pass
 test-arm64-arm64-xl-credit2   7 xen-boot fail   never pass
 test-arm64-arm64-xl-seattle   7 xen-boot fail   never pass
 test-arm64-arm64-xl-xsm   7 xen-boot fail   never pass
 test-arm64-arm64-libvirt-xsm  7 xen-boot fail   never pass
 test-arm64-arm64-xl-credit1   7 xen-boot fail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx  7 xen-boot fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-arm64-arm64-xl   7 xen-boot fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  333d7412796e8fd485bfbb79180a520f7e08bc27
baseline version:
 xen  4f05a0c775871abd4b8147048f067c1cfe408645

Last test of basis   143111  2019-10-24 15:01:54 Z0 days
Testing same since   143118  2019-10-24 18:08:35 Z0 days2 attempts


People who touched revisions under test:
  Anthony PERARD 
  Ian Jackson 
  Wei Liu 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   4f05a0c775..333d741279  333d7412796e8fd485bfbb79180a520f7e08bc27 -> smoke

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

[Xen-devel] [xen-unstable test] 143089: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-xsm broken
 test-amd64-amd64-xl-credit1  broken
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm   broken
 test-amd64-amd64-xl-credit1   4 host-install(4)broken REGR. vs. 142750
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 4 host-install(4) broken 
REGR. vs. 142750
 test-amd64-amd64-libvirt-xsm  4 host-install(4)broken REGR. vs. 142750
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12 
guest-start/debianhvm.repeat fail REGR. vs. 142750

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 142750
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 142750
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 142750
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 142750
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 142750
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 142750
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 142750
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 142750
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 142750
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 142750
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 

Re: [Xen-devel] [PATCH] x86/VT-d: Misc initialisation cleanup

[Tian, Kevin]

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, October 25, 2019 1:28 AM
> 
>  * Initialise all spinlock fields together
>  * No need for an atomic set_bit() to initialise domid_bitmap
>  * Avoid using partial-line printk()'s.
>  * Style fixes (too many, and too few spaces)
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Kevin Tian 
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 133580
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
133580
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 
133580
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 133580
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 133580
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
133580
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 133580
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-pvshim 7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 
133580
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 133580
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 133580
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 133580
 test-armhf-armhf-xl   7 xen-boot fail REGR. vs. 133580
 test-arm64-arm64-libvirt-xsm 17 guest-start.2fail REGR. vs. 133580
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 133580

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 133580

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  7 xen-boot fail baseline untested
 test-arm64-arm64-xl-seattle   7 xen-bootfail baseline untested
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  7 xen-boot fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133580
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 133580
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 133580
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 133580
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 133580
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 133580
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 

[Xen-devel] [xen-unstable-smoke test] 143118: trouble: blocked/broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64  broken
 build-amd64   4 host-install(4)broken REGR. vs. 143111

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  333d7412796e8fd485bfbb79180a520f7e08bc27
baseline version:
 xen  4f05a0c775871abd4b8147048f067c1cfe408645

Last test of basis   143111  2019-10-24 15:01:54 Z0 days
Testing same since   143118  2019-10-24 18:08:35 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Ian Jackson 
  Wei Liu 

jobs:
 build-arm64-xsm  pass
 build-amd64  broken  
 build-armhf  pass
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

broken-job build-amd64 broken
broken-step build-amd64 host-install(4)

Not pushing.


commit 333d7412796e8fd485bfbb79180a520f7e08bc27
Author: Ian Jackson 
Date:   Wed Oct 23 13:55:54 2019 +0100

libxl: On ARM, reject future new passthrough modes too

This is most pleasantly done by also changing the if to a switch.

Suggested-by: Julien Grall 
CC: Julien Grall 
CC: Stefano Stabellini 
Signed-off-by: Ian Jackson 
Release-acked-by: Juergen Gross 
Acked-by: Anthony PERARD 

commit ad011ad08843f60f9ae17b9ae4aa5907674d72af
Author: Ian Jackson 
Date:   Mon Oct 7 17:59:15 2019 +0100

libxl/xl: Overhaul passthrough setting logic

LIBXL_PASSTHROUGH_UNKNOWN (aka "ENABLED" in an earlier uncommitted
version of this code) is doing double duty.  We actually need all of
the following to be specifiable:
  * "default": enable PT iff we have devices to
pass through specified in the initial config file.
  * "enabled" (and fail if the platform doesn't support it).
  * "disabled" (and reject future PT hotplug).
  * "share_pt"/"sync_pt": enable PT and set a specific PT mode.

Defaulting and error checking should be done in libxl.  So, we make
several changes here.

We introduce "enabled", and rename "unknown" to "default".

We move all of the error checking and defaulting code from xl into
libxl.  Now, libxl__domain_config_setdefault has all of the necessary
information to get this right.  So we can do it all there.  Choosing
the specific mode is arch-specific.

We can also arrange to have only one place each which calculates
(i) whether passthrough needs to be enabled because pt devices were
specified (ii) whether pt_share can be used (for each arch).

xl now only has to parse the enum in the same way as it parses all
other enums.

This change fixes a regression from earlier 4.13-pre: until recent
changes, passthrough was only enabled by default if passthrough
devices were specified.  We restore this behaviour.

Signed-off-by: Ian Jackson 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Andrew Cooper 
CC: Paul Durrant 
CC: Jan Beulich 
Release-acked-by: Juergen Gross 
Acked-by: Anthony PERARD 

commit 

[Xen-devel] [ovmf test] 143094: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 broken
 test-amd64-i386-xl-qemuu-ovmf-amd64  4 host-install(4) broken REGR. vs. 143072
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail REGR. vs. 143072

version targeted for testing:
 ovmf 703232b8e8889e908771b64e22b5ed94e403aa0a
baseline version:
 ovmf 95d2883647dd8bf91f65cde87e73cede1dcc6574

Last test of basis   143072  2019-10-23 17:09:39 Z1 days
Testing same since   143094  2019-10-24 10:02:58 Z0 days1 attempts


People who touched revisions under test:
  Laszlo Ersek 
  Liming Gao 
  Michael D Kinney 
  Sean Brogan 

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  broken  



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

broken-job test-amd64-i386-xl-qemuu-ovmf-amd64 broken
broken-step test-amd64-i386-xl-qemuu-ovmf-amd64 host-install(4)

Not pushing.


commit 703232b8e8889e908771b64e22b5ed94e403aa0a
Author: Liming Gao 
Date:   Tue Oct 22 22:44:05 2019 +0800

OvmfPkg: Enable CLANG9 tool chain

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
1. Apply CLANG9 Linker option.
2. Exclude -mno-mmx -mno-sse compiler option for CLANG9
These two options will cause CLANG Linker crush.

Signed-off-by: Liming Gao 
Reviewed-by: Laszlo Ersek 

commit 2737037a417a97de8153ebc5e4556bdf38f765c6
Author: Liming Gao 
Date:   Thu Oct 17 14:55:54 2019 +0800

EmulatorPkg: Enable CLANG9 tool chain

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
1. Add WIN_HOST_BUILD macro check for CLANG9 tool chain
build -p EmulatorPkg\EmulatorPkg.dsc -a IA32 -DWIN_HOST_BUILD=TRUE -t CLANG9
build -p EmulatorPkg\EmulatorPkg.dsc -a X64 -DWIN_HOST_BUILD=TRUE -t CLANG9
2. Append CLANG CC and LINK flags to generate windows HOST.
3. Fix WinHost issue to call GetProcessAffinityMask() API.
   The input parameter should be UINTN pointer instead of UINT32 pointer.

Cc: Jordan Justen 
Cc: Andrew Fish 
Cc: Ray Ni 
Signed-off-by: Liming Gao 
Reviewed-by: Ray Ni 

commit 933681b2084435ec2744e7042e3864cabd4fa879
Author: Liming Gao 
Date:   Thu Oct 17 14:55:53 2019 +0800

CryptoPkg IntrinsicLib: Make _fltused always be used

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
With this change, global variable _fltused will not be removed by LTO

Signed-off-by: Liming Gao 
Reviewed-by: Jian J Wang 
Reviewed-by: Philippe Mathieu-Daude 

commit 3d61650f95193694fb00e1e6863ef09c5ecba090
Author: Liming Gao 
Date:   Thu Oct 17 14:55:52 2019 +0800

CryptoPkg: Append options to make CLANG9 tool chain pass build

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
Disable warning reported from CLANG9.

Signed-off-by: Liming Gao 
Reviewed-by: Jian J Wang 

commit 55863be1fc341bd37d4077ecdbb7ff12f673dc89
Author: Liming Gao 
Date:   Thu Oct 17 14:55:51 2019 +0800

MdeModulePkg RegularExpressionDxe: Disable warning for CLANG9 tool chain

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603

Signed-off-by: Liming Gao 
Reviewed-by: Hao A Wu 

commit 7d9ba361cc79dcba667bc3e2dc45ac0ef1756cbb
Author: Liming Gao 
Date:   Thu Oct 17 14:55:50 2019 +0800

MdeModulePkg LzmaCustomDecompressLib: Update macro to be same in CLANG tool

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
Define the same macro in the different OS. It can make CLANG generate the 
same
image in the 

Re: [Xen-devel] [PATCH v2 00/20] hw/i386/pc: Split PIIX3 southbridge from i440FX northbridge

[Aleksandar Markovic]

On Friday, October 18, 2019, Philippe Mathieu-Daudé 
wrote:

> Changes since v1 [0]:
> - Removed patch reintroducing DO_UPCAST() use (thuth)
> - Took various patches out to reduce series (thuth)
> - Added review tags (thanks all for reviewing!)
>
>
Philippe,

Do you intend to submit v3? The softfreeze is close.

A.



> $ git backport-diff -u pc_split_i440fx_piix-v1 -r mc146818rtc_init..
> Key:
> [] : patches are identical
> [] : number of functional differences between upstream/downstream patch
> [down] : patch is downstream-only
> The flags [FC] indicate (F)unctional and (C)ontextual differences,
> respectively
>
> 001/20:[] [--] 'MAINTAINERS: Keep PIIX4 South Bridge separate from PC
> Chipsets'
> 002/20:[0011] [FC] 'piix4: add Reset Control Register'
> 003/20:[0014] [FC] 'piix4: add a i8259 interrupt controller as specified
> in datasheet'
> 004/20:[] [--] 'Revert "irq: introduce qemu_irq_proxy()"'
> 005/20:[] [--] 'piix4: rename PIIX4 object to piix4-isa'
> 006/20:[] [-C] 'piix4: add a i8257 dma controller as specified in
> datasheet'
> 007/20:[] [-C] 'piix4: add a i8254 pit controller as specified in
> datasheet'
> 008/20:[] [-C] 'piix4: add a mc146818rtc controller as specified in
> datasheet'
> 009/20:[] [--] 'hw/mips/mips_malta: Create IDE hard drive array
> dynamically'
> 010/20:[] [--] 'hw/mips/mips_malta: Extract the PIIX4 creation code as
> piix4_create()'
> 011/20:[] [--] 'hw/isa/piix4: Move piix4_create() to hw/isa/piix4.c'
> 012/20:[] [--] 'hw/i386: Remove obsolete LoadStateHandler::load_state_old
> handlers'
> 013/20:[] [--] 'hw/pci-host/piix: Extract piix3_create()'
> 014/20:[0010] [FC] 'hw/pci-host/piix: Move RCR_IOPORT register definition'
> 015/20:[] [--] 'hw/pci-host/piix: Define and use the PIIX IRQ Route
> Control Registers'
> 016/20:[] [--] 'hw/pci-host/piix: Move i440FX declarations to
> hw/pci-host/i440fx.h'
> 017/20:[] [--] 'hw/pci-host/piix: Fix code style issues'
> 018/20:[0012] [FC] 'hw/pci-host/piix: Extract PIIX3 functions to
> hw/isa/piix3.c'
> 019/20:[] [--] 'hw/pci-host: Rename incorrectly named 'piix' as
> 'i440fx''
> 020/20:[] [-C] 'hw/pci-host/i440fx: Remove the last PIIX3 traces'
>
> Previous cover:
>
> This series is a rework of "piix4: cleanup and improvements" [1]
> from Hervé, and my "remove i386/pc dependency: PIIX cleanup" [2].
>
> Still trying to remove the strong X86/PC dependency 2 years later,
> one step at a time.
> Here we split the PIIX3 southbridge from i440FX northbridge.
> The i440FX northbridge is only used by the PC machine, while the
> PIIX southbridge is also used by the Malta MIPS machine.
>
> This is also a step forward using KConfig with the Malta board.
> Without this split, it was impossible to compile the Malta without
> pulling various X86 pieces of code.
>
> The overall design cleanup is not yet perfect, but enough to post
> as a series.
>
> Now that the PIIX3 code is extracted, the code duplication with the
> PIIX4 chipset is obvious. Not worth improving for now because it
> isn't broken.
>
> [0] https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg03685.html
> [1] https://www.mail-archive.com/qemu-devel@nongnu.org/msg500737.html
> [2] https://www.mail-archive.com/qemu-devel@nongnu.org/msg504081.html
>
> Based-on: <20191018133547.10936-1-phi...@redhat.com>
> mc146818rtc: Allow call object_initialize(MC146818_RTC) instead of
> rtc_init()
> https://mid.mail-archive.com/20191018133547.10936-1-philmd@redhat.com
>
> Hervé Poussineau (5):
>   piix4: Add the Reset Control Register
>   piix4: Add a i8259 Interrupt Controller as specified in datasheet
>   piix4: Rename PIIX4 object to piix4-isa
>   piix4: Add a i8257 DMA Controller as specified in datasheet
>   piix4: Add a i8254 PIT Controller as specified in datasheet
>
> Philippe Mathieu-Daudé (15):
>   MAINTAINERS: Keep PIIX4 South Bridge separate from PC Chipsets
>   Revert "irq: introduce qemu_irq_proxy()"
>   piix4: Add a MC146818 RTC Controller as specified in datasheet
>   hw/mips/mips_malta: Create IDE hard drive array dynamically
>   hw/mips/mips_malta: Extract the PIIX4 creation code as piix4_create()
>   hw/isa/piix4: Move piix4_create() to hw/isa/piix4.c
>   hw/i386: Remove obsolete LoadStateHandler::load_state_old handlers
>   hw/pci-host/piix: Extract piix3_create()
>   hw/pci-host/piix: Move RCR_IOPORT register definition
>   hw/pci-host/piix: Define and use the PIIX IRQ Route Control Registers
>   hw/pci-host/piix: Move i440FX declarations to hw/pci-host/i440fx.h
>   hw/pci-host/piix: Fix code style issues
>   hw/pci-host/piix: Extract PIIX3 functions to hw/isa/piix3.c
>   hw/pci-host: Rename incorrectly named 'piix' as 'i440fx'
>   hw/pci-host/i440fx: Remove the last PIIX3 traces
>
>  MAINTAINERS  |  14 +-
>  hw/acpi/pcihp.c  |   2 +-
>  hw/acpi/piix4.c  |  42 +--
>  hw/core/irq.c|  14 -
>  hw/i386/Kconfig  |   3 +-
> 

Re: [Xen-devel] [PATCH 05/24] golang/xenlight: define KeyValueList builtin type

[Nick Rosbrook]

> So we *could* actually just `type KeyValueList struct { }`, and punt on
> all these initialization questions until such time as it turns out that
> they're needed.

If there is no clear need for this type to be implemented in the Go
package, then I would be in favor of not doing so. IMO, a smaller,
more focused package is ideal.

> On the other hand, I think we may need to actually think about
> initializing structures.  You've carefully coded DefBool such that the
> "zero" value is undefined; but for DevId, for instance, the "initial"
> value is supposed to be -1; but the way it's coded, an uninitialized Go
> structure will end up as 0, which may be a valid devid.
>
> [...]
>
> Anyway, perhaps we can think about structure initialization, and
> implement it after we do the basic structure /  marshalling implementaiton.

That's probably best. However, at a quick glance it seems like it
would be pretty straight-forward to generate NewStructType functions
analogous to libxl_struct_type_init, if that's the desired behavior.

> In the mean time, we could either keep the KeyValueList you've
> implemented here (perhaps adding a make() to the fromC method, and
> having toC return NULL if kvl is NULL), or just replace it with a
> placeholder until it's needed.
>
> What do you think?

Based on what you said above, I think I would like to drop the
implementation for now. But, if we keep the current implementation, I
will make those corrections.

-NR

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

Re: [Xen-devel] [PATCH 24/24] golang/xenlight: add make target for generated files

[Nick Rosbrook]

> One standard practice when making a series is to try to avoid any
> regressions, including build regressions, in the middle of the series.
> This is particularly helpful to aid in bisections, but in this case it
> makes it easier to observe the action of the `gengotypes.py` script (and
> how it's meant to be called).
>
> So I would basically make this part of patch 2, except remove references
> to xenlight_helpers.go until the patch where that file is generated.

Ah yeah that makes sense, I'll correct this in v2.

> It might be nice to have a naming convention for the generated files
> that clues people in to the fact that they're generated (other than the
> comment at the top of course).  In libxl, this is done by giving them a
> leading underscore (e.g., _libxl_type.h); but the go compiler will
> helpfully ignore such files. :-)
>
> The go compiler will also do special things sometimes with things after
> a `_`; e.g., "${foo}_test.go" will only be compiled for `go test`,
> "${foo}_linux.go" will only be compiled on Linux, and so on.  I'm pretty
> sure these names will be safe, but it might be slightly more
> future-proof to avoid using an underscore in the names.

+1 for a naming convention that says "this file is generated." But,
the only special
cases that I'm aware of for go file name suffixes are "test", and
valid GOOS and GOARCH
values. It's conventional to use underscores for compounded file
names, and unnecessary
to avoid them.

To reference gRPC again, their protobuf compiler writes file names
like 'package.pb.go', where
pb is short for protobuf. So, I think something like
'_generated.go', or '.idl.go'
could work.

> Kind of random, but would it make sense to `rm -rf` the whole directory
> here instead?

Yeah probably :)

-NR

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

Re: [Xen-devel] [xen-unstable test] 143061: regressions - trouble: broken/fail/pass

[Stefano Stabellini]

On Thu, 24 Oct 2019, Julien Grall wrote:
> (+Ian and Stefano)
> 
> Hi,
> 
> On 10/24/19 8:13 AM, Jürgen Groß wrote:
> > On 24.10.19 08:47, osstest service owner wrote:
> > > flight 143061 xen-unstable real [real]
> > > http://logs.test-lab.xenproject.org/osstest/logs/143061/
> > > 
> > > Regressions :-(
> > > 
> > > Tests which did not succeed and are blocking,
> > > including tests which could not be run:
> > >   test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm      
> > > broken
> > >   test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 4 host-install(4)
> > > broken REGR. vs. 142750
> > 
> > Why is Linux kernel 5.4.0-rc4 being used for testing xen-unstable here?
> > Or am I reading the logs wrong?
> > 
> > >   test-arm64-arm64-examine    11 examine-serial/bootloader fail REGR. vs.
> > > 142750
> > 
> > I'm not sure what has gone wrong here? The serial logs seem to be fine
> > for me, but maybe I'm missing something?
> 
> This is a known issue on rochesters for the past 6 months (see [1]). In short,
> Osstest is checking the sanity of the platform by adding cookie in the
> bootloader output. However, this cookie is lost.
> 
> Stefano promised to investigate it back then. Last time I heard, he had access
> to the colo. Stefano where are we with this?
> 
> Cheers,
> 
> [1] https://lists.xen.org/archives/html/xen-devel/2019-05/msg00018.html

I haven't had any time to look at this so far yet unfortunately, I am on
the hot path for too many things at the moment. If somebody else would
like to step forward in analyzing the issue they would be very welcome.

And I do have a suggestion for somebody else to pick this up: Brian
(CC'ed) has joined Xilinx recently and might be willing to help on this.
However, we would need to give him access to the colo for him to be able
to make any progress.___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl
testid xen-boot

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  3b7c59a1950c75f2c0152e5a9cd77675b09233d6
  Bug not present: 223cea6a4f0552b86fb25e3b8bbd00469816cd7a
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/143114/


  (Revision log too long, omitted.)


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-i386-xl.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-xl.xen-boot 
--summary-out=tmp/143114.bisection-summary --basis-template=133580 
--blessings=real,real-bisect linux-linus test-amd64-i386-xl xen-boot
Searching for failure / basis pass:
 143060 fail [host=fiano0] / 138849 ok.
Failure / basis pass flights: 143060 / 138849
(tree with no url: minios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 3b7c59a1950c75f2c0152e5a9cd77675b09233d6 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
46bb81200742fabfe5c5624c22e72f036af02869 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
933ebad2470a169504799a1d95b8e410bd9847ef 
120996f147131eca8af90e30c900bc14bc824d9f 
518c935fac4d30b3ec35d4b6add82b17b7d7aca3
Basis pass 223cea6a4f0552b86fb25e3b8bbd00469816cd7a 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d031fc07eb83c9d13bff3ebac25da458d5a47917 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
9cca02d8ffc23e9688a971d858e4ffdff5389b11 
30f1e41f04fb4c715d27f987f003cfc31c9ff4f3 
843cec0de800a5f925f8071a7f58f3fb1c6b6eb6
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#223cea6a4f0552b86fb25e3b8bbd00469816cd7a-3b7c59a1950c75f2c0152e5a9cd77675b09233d6
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/osstest/ovmf.git#d031fc07eb83c9d13bff3ebac25da458d5a47917-46bb81200742fabfe5c5624c22e72f036af02869
 git://xenbits.xen.org/qemu-xen-traditional.\
 
git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798
 
git://xenbits.xen.org/qemu-xen.git#9cca02d8ffc23e9688a971d858e4ffdff5389b11-933ebad2470a169504799a1d95b8e410bd9847ef
 
git://xenbits.xen.org/osstest/seabios.git#30f1e41f04fb4c715d27f987f003cfc31c9ff4f3-120996f147131eca8af90e30c900bc14bc824d9f
 
git://xenbits.xen.org/xen.git#843cec0de800a5f925f8071a7f58f3fb1c6b6eb6-518c935fac4d30b3ec35d4b6add82b17b7d7aca3
adhoc-revtuple-generator: tree discontiguous: linux-2.6
adhoc-revtuple-generator: tree discontiguous: qemu-xen
From git://cache:9419/git://xenbits.xen.org/xen
   3f82eb9740..4f05a0c775  smoke  -> origin/smoke
Loaded 3003 nodes in revision graph
Searching for test results:
 138780 [host=italia0]
 138813 [host=albana0]
 138849 pass 223cea6a4f0552b86fb25e3b8bbd00469816cd7a 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d031fc07eb83c9d13bff3ebac25da458d5a47917 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
9cca02d8ffc23e9688a971d858e4ffdff5389b11 
30f1e41f04fb4c715d27f987f003cfc31c9ff4f3 
843cec0de800a5f925f8071a7f58f3fb1c6b6eb6
 138878 fail irrelevant
 138902 fail irrelevant
 138962 fail irrelevant
 139003 fail irrelevant
 139068 fail irrelevant
 139134 fail irrelevant
 139237 fail irrelevant
 139223 fail irrelevant
 139257 fail irrelevant
 139324 fail irrelevant
 139306 fail irrelevant
 139286 fail irrelevant
 139338 fail irrelevant
 139361 fail irrelevant
 139383 fail irrelevant
 139408 fail irrelevant
 139478 fail irrelevant
 139532 fail irrelevant
 139584 fail irrelevant
 139555 fail irrelevant
 139687 fail irrelevant
 139616 fail irrelevant
 139669 fail irrelevant
 139711 fail irrelevant
 139735 fail irrelevant
 139792 fail irrelevant
 139832 fail irrelevant
 139942 fail irrelevant
 139866 fail irrelevant
 139907 fail irrelevant
 139996 fail irrelevant
 140038 fail irrelevant
 140128 fail irrelevant
 140163 fail irrelevant
 140251 fail irrelevant
 140188 fail irrelevant
 140216 fail irrelevant
 

Re: [Xen-devel] [PATCH] MAINTAINERS: correct decription of M:

[Wei Liu]

On Thu, Oct 24, 2019 at 03:45:20PM +0200, Jan Beulich wrote:
> Let's reflect reality, its use by add_maintainers.pl / get_maintainer.pl,
> as well as what
> https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches says.
> 
> Signed-off-by: Jan Beulich 

Acked-by: Wei Liu 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  4f05a0c775871abd4b8147048f067c1cfe408645
baseline version:
 xen  3f82eb9740cacf417576387c398c9a543ab05c60

Last test of basis   143103  2019-10-24 12:11:31 Z0 days
Testing same since   143111  2019-10-24 15:01:54 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Boris Ostrovsky 
  Jan Beulich 
  Julien Grall 
  Oleksandr Tyshchenko 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   3f82eb9740..4f05a0c775  4f05a0c775871abd4b8147048f067c1cfe408645 -> smoke

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

[Xen-devel] [PATCH] x86/VT-d: Misc initialisation cleanup

[Andrew Cooper]

 * Initialise all spinlock fields together
 * No need for an atomic set_bit() to initialise domid_bitmap
 * Avoid using partial-line printk()'s.
 * Style fixes (too many, and too few spaces)

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Jun Nakajima 
CC: Kevin Tian 
CC: Juergen Gross 

This isn't required for 4.13, but it is a couple of nice-to-have's and we're
still at the early RC phase.
---
 xen/drivers/passthrough/vtd/iommu.c | 24 +---
 1 file changed, 9 insertions(+), 15 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index 0522ecd3bc..4a759d33cd 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1145,6 +1145,8 @@ int __init iommu_alloc(struct acpi_drhd_unit *drhd)
 iommu->msi.irq = -1; /* No irq assigned yet. */
 iommu->node = NUMA_NO_NODE;
 INIT_LIST_HEAD(>ats_devices);
+spin_lock_init(>lock);
+spin_lock_init(>register_lock);
 spin_lock_init(>intremap.lock);
 
 iommu->drhd = drhd;
@@ -1197,21 +1199,18 @@ int __init iommu_alloc(struct acpi_drhd_unit *drhd)
 nr_dom = cap_ndoms(iommu->cap);
 iommu->domid_bitmap = xzalloc_array(unsigned long, BITS_TO_LONGS(nr_dom));
 if ( !iommu->domid_bitmap )
-return -ENOMEM ;
+return -ENOMEM;
 
 /*
  * if Caching mode is set, then invalid translations are tagged with
  * domain id 0, Hence reserve bit 0 for it
  */
 if ( cap_caching_mode(iommu->cap) )
-set_bit(0, iommu->domid_bitmap);
+__set_bit(0, iommu->domid_bitmap);
 
 iommu->domid_map = xzalloc_array(u16, nr_dom);
 if ( !iommu->domid_map )
-return -ENOMEM ;
-
-spin_lock_init(>lock);
-spin_lock_init(>register_lock);
+return -ENOMEM;
 
 return 0;
 }
@@ -2272,15 +2271,10 @@ static int __init vtd_setup(void)
 {
 iommu = drhd->iommu;
 
-printk("Intel VT-d iommu %"PRIu32" supported page sizes: 4kB",
-   iommu->index);
-if (cap_sps_2mb(iommu->cap))
-printk(", 2MB");
-
-if (cap_sps_1gb(iommu->cap))
-printk(", 1GB");
-
-printk(".\n");
+printk("Intel VT-d iommu %u supported page sizes: 4kB%s%s\n",
+   iommu->index,
+   cap_sps_2mb(iommu->cap) ? ", 2MB" : "",
+   cap_sps_1gb(iommu->cap) ? ", 1GB" : "");
 
 if ( iommu_snoop && !ecap_snp_ctl(iommu->ecap) )
 iommu_snoop = 0;
-- 
2.11.0


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

Re: [Xen-devel] [PATCH 05/24] golang/xenlight: define KeyValueList builtin type

[George Dunlap]

On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook 
> 
> Define KeyValueList builtin type, analagous to libxl_key_value_list as
> map[string]string, and implement its fromC and toC functions.
> 
> Signed-off-by: Nick Rosbrook 
> ---
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> 
>  tools/golang/xenlight/xenlight.go | 33 ++-
>  1 file changed, 32 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/golang/xenlight/xenlight.go 
> b/tools/golang/xenlight/xenlight.go
> index 4d4fad2a9d..8196a42855 100644
> --- a/tools/golang/xenlight/xenlight.go
> +++ b/tools/golang/xenlight/xenlight.go
> @@ -202,11 +202,42 @@ func (chwcap C.libxl_hwcap) toGo() (ghwcap Hwcap) {
>   return
>  }
>  
> +// KeyValueList represents a libxl_key_value_list.
> +type KeyValueList map[string]string
> +
> +func (kvl KeyValueList) fromC(ckvl *C.libxl_key_value_list) error {
> + size := int(C.libxl_key_value_list_length(ckvl))
> + list := (*[1 << 30]*C.char)(unsafe.Pointer(ckvl))[:size:size]
> +
> + for i := 0; i < size*2; i += 2 {
> + kvl[C.GoString(list[i])] = C.GoString(list[i+1])
> + }

It looks like when you use this, you use patterns like this:

var keyValueListXsdata KeyValueList
if err := keyValueListXsdata.fromC(); err != nil {

But this never calls make(); so won't this crash with a null pointer
deref?  Or am I missing something?

Would it be better to take a pointer method here, and set `*kvl =
make(map[string]string)` before copying the strings over?

That would also very naturally take care of the case where you called
the .fromC() method twice with two different key value lists.  As it is,
if the caller had to initialize it, you'd get a "clobbered union" of the
two lists (where in the case of duplicate keys, the second value
clobbers the first); this way, you only get the most recent list, which
is probably closer to what you wanted.

Also, when going the other direction, how are callers of, say,
libxl_domain_create_new() supposed to initialize this and fill in values?

Looking through the code -- it seems that this type is somewhat
vestigal.  It's only used for two fields of a single struct, and those
fields aren't actually used by xl or libvirt at the moment; and after
some discussion it was determined that anything they might be used to
achieve should probably be done a different way.

So we *could* actually just `type KeyValueList struct { }`, and punt on
all these initialization questions until such time as it turns out that
they're needed.

On the other hand, I think we may need to actually think about
initializing structures.  You've carefully coded DefBool such that the
"zero" value is undefined; but for DevId, for instance, the "initial"
value is supposed to be -1; but the way it's coded, an uninitialized Go
structure will end up as 0, which may be a valid devid.

At the moment, all implemented methods take scalar arguments; but when
they take structs, having  non-default values means "try to get this
specific devid", as opposed to "just choose a free one for me".

Anyway, perhaps we can think about structure initialization, and
implement it after we do the basic structure /  marshalling implementaiton.

In the mean time, we could either keep the KeyValueList you've
implemented here (perhaps adding a make() to the fromC method, and
having toC return NULL if kvl is NULL), or just replace it with a
placeholder until it's needed.

What do you think?

 -George

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

Re: [Xen-devel] [PATCH] x86/stackframe/32: repair 32-bit Xen PV

[Andy Lutomirski]

On Thu, Oct 24, 2019 at 9:32 AM Andrew Cooper  wrote:
>
> On 24/10/2019 17:11, Andy Lutomirski wrote:
> >> +# define USER_SEGMENT_RPL_MASK (SEGMENT_RPL_MASK & ~1)
> >> +#endif
> >> +
> >> .section .entry.text, "ax"
> >>
> >>  /*
> >> @@ -172,7 +183,7 @@
> >> ALTERNATIVE "jmp .Lend_\@", "", X86_FEATURE_PTI
> >> .if \no_user_check == 0
> >> /* coming from usermode? */
> >> -   testl   $SEGMENT_RPL_MASK, PT_CS(%esp)
> >> +   testl   $USER_SEGMENT_RPL_MASK, PT_CS(%esp)
> > Shouldn't PT_CS(%esp) be 0 if we came from the kernel?  I'm guessing
> > the actual bug is in whatever code put 1 in here in the first place.
>
> Ring1 kernels (32bit) consistently see RPL1 everywhere under Xen.
>
> Back in the days of a 32bit Xen, int $0x80 really was wired directly
> from ring 3 to 1, and didn't bounce through Xen.  This isn't possible in
> long mode, because all IDT gates are required to be 64bit code segments.
>
> Ring3 kernels (64bit) consistently see RPL0 everywhere under Xen,
> because presumably this was less invasive when designing the ABI.
>

OK, gotcha.

So I'm fine with this patch if you improve the comment and definition.

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

Re: [Xen-devel] [PATCH] x86/stackframe/32: repair 32-bit Xen PV

[Andrew Cooper]

On 24/10/2019 17:11, Andy Lutomirski wrote:
>> +# define USER_SEGMENT_RPL_MASK (SEGMENT_RPL_MASK & ~1)
>> +#endif
>> +
>> .section .entry.text, "ax"
>>
>>  /*
>> @@ -172,7 +183,7 @@
>> ALTERNATIVE "jmp .Lend_\@", "", X86_FEATURE_PTI
>> .if \no_user_check == 0
>> /* coming from usermode? */
>> -   testl   $SEGMENT_RPL_MASK, PT_CS(%esp)
>> +   testl   $USER_SEGMENT_RPL_MASK, PT_CS(%esp)
> Shouldn't PT_CS(%esp) be 0 if we came from the kernel?  I'm guessing
> the actual bug is in whatever code put 1 in here in the first place.

Ring1 kernels (32bit) consistently see RPL1 everywhere under Xen.

Back in the days of a 32bit Xen, int $0x80 really was wired directly
from ring 3 to 1, and didn't bounce through Xen.  This isn't possible in
long mode, because all IDT gates are required to be 64bit code segments.

Ring3 kernels (64bit) consistently see RPL0 everywhere under Xen,
because presumably this was less invasive when designing the ABI.

~Andrew

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

Re: [Xen-devel] [PATCH] MAINTAINERS: Add DornerWorks maintainers email

[Stewart Hildebrand]

On Thursday, October 24, 2019 9:37 AM, Julien Grall wrote:
>Hi,
>
>Jumping into the conversation.
>
>On 24/10/2019 14:06, Jeff Kubascik wrote:
>> We would like to remove our current two developers who are listed as M: for 
>> the
>> ARINC653 scheduler code. Since M: is just a "Mail patches to" designation, 
>> I'm
>> now leaning towards the L: designation, as the two appear roughly equivalent 
>> in
>> their role. Does that sound reasonable?
>
>I don't think you can treat "L:" and "M:" the same way.
>
>"M:" is a single person that we know.
>
>"L:" is a list of person that we don't know.
>
>xen-de...@dornerworks.com definitely falls into the "L:" category. That clearly
>raises a few questions here.
>
>- How do we know when the list of person change?
>- How acked-by/reviewed-by will be done? Will it be Acked-by 
> "Dornerworks
><>"? If not, then we still need "M:" around to which acked-by is 
>sufficient.
>If yes, how do we know all the person on that list can be trusted?

The rationale for removing Robbie and Josh is that they are currently 
active on other projects that don't involve Xen. I'm involved with Xen
and I'm the tech lead for our product that actually uses the ARINC 653
scheduler, so I'll volunteer myself to replace Robbie and Josh. This
way we will still have a real person with an M: for the ARINC 653
scheduler in MANTAINERS.

We would still like to add our internal list. It seems L: is a fairly
agreeable designation for the list.

L:DornerWorks Xen-Devel 

Thanks,
Stew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/stackframe/32: repair 32-bit Xen PV

[Andy Lutomirski]

On Mon, Oct 7, 2019 at 3:41 AM Jan Beulich  wrote:
>
> Once again RPL checks have been introduced which don't account for a
> 32-bit kernel living in ring 1 when running in a PV Xen domain. The
> case in FIXUP_FRAME has been preventing boot; adjust BUG_IF_WRONG_CR3
> as well just in case.

I'm okay with the generated code, but IMO the macro is too indirect
for something that's trivial.

>
> Fixes: 3c88c692c287 ("x86/stackframe/32: Provide consistent pt_regs")
> Signed-off-by: Jan Beulich 
>
> --- a/arch/x86/entry/entry_32.S
> +++ b/arch/x86/entry/entry_32.S
> @@ -48,6 +48,17 @@
>
>  #include "calling.h"
>
> +#ifndef CONFIG_XEN_PV
> +# define USER_SEGMENT_RPL_MASK SEGMENT_RPL_MASK
> +#else
> +/*
> + * When running paravirtualized on Xen the kernel runs in ring 1, and hence
> + * simple mask based tests (i.e. ones not comparing against USER_RPL) have to
> + * ignore bit 0. See also the C-level get_kernel_rpl().
> + */

How about:

/*
 * When running on Xen PV, the actual %cs register in the kernel is 1, not 0.
 * If we need to distinguish between a %cs from kernel mode and a %cs from
 * user mode, we can do test $2 instead of test $3.
 */
#define USER_SEGMENT_RPL_MASK 2

but...

> +# define USER_SEGMENT_RPL_MASK (SEGMENT_RPL_MASK & ~1)
> +#endif
> +
> .section .entry.text, "ax"
>
>  /*
> @@ -172,7 +183,7 @@
> ALTERNATIVE "jmp .Lend_\@", "", X86_FEATURE_PTI
> .if \no_user_check == 0
> /* coming from usermode? */
> -   testl   $SEGMENT_RPL_MASK, PT_CS(%esp)
> +   testl   $USER_SEGMENT_RPL_MASK, PT_CS(%esp)

Shouldn't PT_CS(%esp) be 0 if we came from the kernel?  I'm guessing
the actual bug is in whatever code put 1 in here in the first place.

In other words, I'm having trouble understanding why there is any
context in which some value would be 3 for user mode and 1 for kernel
mode.  Obviously if we're manually IRETing to kernel mode, we need to
set CS to 1, but if we're filling in our own PT_CS, we should just
write 0.

The supposedly offending commit (""x86/stackframe/32: Provide
consistent pt_regs") looks correct to me, so I suspect that the
problem is elsewhere.  Or is it intentional that Xen PV's asm
(arch/x86/xen/whatever) sticks 1 into the CS field on the stack?

Also, why are we supporting 32-bit Linux PV guests at all?  Can we
just delete this code instead?

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

[Xen-devel] rochester and Debian buster

[Ian Jackson]

We discussed on irc the problems I have been having trying to get
buster's released kernel to run on the rochesters, which is wanted to
upgrade osstest to buster (which is currently Debian stable).

Unfortunately our previous conversations don't seem to have been
recorded anywhere.  Let's try at least to write things down now.

The symptom is that the machine thinks the network link is down, and
no network stuff happens, so the installer doesn't work.  (I don't
think I have checked at the switch end whether the link is actually
up.)

You suggested that maybe adding
  iommu.passthrough=1
to the kernel command line might help.  But it hasn't.

I have a memory of discussing the next steps and I think we discussed
upgrading the firmware.  If I remember rightly we agreed (with
Juergen) that upgrading the firmware on one of the two rochester
machines would be an acceptable risk.  Can we file a ticket to have
that done by our onsite technician ?

Other options would include trying a buster-backports kernel, if we
had some reason to think that a newer kernel would be better.
Certainly if this turns out to be a kernel bug, and a workaround is
awkward, the best fix would be to get the bugfix backported to the
Debian buster kernel (either the stable series, or -backports).

Currently I have rochester1 booked out and you are free to play with
it if you like.  We'll negotiate about that on irc.

Ian.

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

Re: [Xen-devel] [PATCH 04/24] golang/xenlight: define Devid type as int

[George Dunlap]

On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook 
> 
> Signed-off-by: Nick Rosbrook 

Reviewed-by: George Dunlap 

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

Re: [Xen-devel] [PATCH 03/24] golang/xenlight: define Defbool builtin type

[George Dunlap]

On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook 
> 
> Define Defbool as struct analagous to the C type, and define the type
> 'defboolVal' that represent true, false, and default defbool values.
> 
> Implement Set, Unset, SetIfDefault, IsDefault, Val, and String functions
> on Defbool so that the type can be used in Go analagously to how its
> used in C.
> 
> Finally, implement fromC and toC functions.
> 
> Signed-off-by: Nick Rosbrook 

Looks good:

Reviewed-by: George Dunlap 

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

Re: [Xen-devel] [XEN PATCH for-4.13 v7 11/11] libxl: On ARM, reject future new passthrough modes too

[Ian Jackson]

Anthony PERARD writes ("Re: [XEN PATCH for-4.13 v7 11/11] libxl: On ARM, reject 
future new passthrough modes too"):
> On Wed, Oct 23, 2019 at 02:00:13PM +0100, Ian Jackson wrote:
> > +case LIBXL_PASSTHROUGH_DISABLED;
> 
> That looks strange, there a semicolon ^ here instead of a colon ':'.
> 
> > - "passthrough=\"sync_pt\" not supported on ARM\n");
> > + "passthrough=\"%s\" not supported on ARM\n",
> > + libxl__passthrough_mode_to_string(c_info->passthrough);
> 
> I can't find where this function is defined. Does it exist?
> You probably want libxl_passthrough_to_string().
> Also there's a missing ) to terminate LOGD list of args.

I managed to get osstest to let me have one of its arm boxes for long
enough to actually build test this and your list of issues was
comprehensive.

> I think that's it. With those 3 things fixed:
> Acked-by: Anthony PERARD 

So, thanks.  FTR here is the final version.

This now has all the required acks and I will build test it again
against staging and push it.

Ian.

From 324f7b4092da65dae6aec978a89966b8ecff3a9d Mon Sep 17 00:00:00 2001
From: Ian Jackson 
Date: Wed, 23 Oct 2019 13:55:54 +0100
Subject: [XEN PATCH for-4.13 v7 11/11] libxl: On ARM, reject future new
 passthrough modes too
Cc: Jürgen Groß 

This is most pleasantly done by also changing the if to a switch.

Suggested-by: Julien Grall 
CC: Julien Grall 
CC: Stefano Stabellini 
Signed-off-by: Ian Jackson 
Release-acked-by: Juergen Gross 
Acked-by: Anthony PERARD 

---
v8: Fix many idioticy compile errors in this patch.

v7: New patch in this version of the series.
---
 tools/libxl/libxl_arm.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 2f1ca69431..34f8a29056 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -1203,9 +1203,15 @@ int libxl__arch_passthrough_mode_setdefault(libxl__gc 
*gc,
 c_info->passthrough = LIBXL_PASSTHROUGH_SHARE_PT;
 }
 
-if (c_info->passthrough == LIBXL_PASSTHROUGH_SYNC_PT) {
+switch (c_info->passthrough) {
+case LIBXL_PASSTHROUGH_DISABLED:
+case LIBXL_PASSTHROUGH_SHARE_PT:
+break;
+
+default:
 LOGD(ERROR, domid,
- "passthrough=\"sync_pt\" not supported on ARM\n");
+ "passthrough=\"%s\" not supported on ARM\n",
+ libxl_passthrough_to_string(c_info->passthrough));
 rc = ERROR_INVAL;
 goto out;
 }
-- 
2.11.0


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  3f82eb9740cacf417576387c398c9a543ab05c60
baseline version:
 xen  7eee9c16d6405a1a1f2e8c6472923db842c90cfb

Last test of basis   143074  2019-10-23 19:02:54 Z0 days
Testing same since   143103  2019-10-24 12:11:31 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   7eee9c16d6..3f82eb9740  3f82eb9740cacf417576387c398c9a543ab05c60 -> smoke

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

Re: [Xen-devel] Debugging Windows HVM crashes on Ryzen 3xxx series CPUs.

[Paul Durrant]

Not much clue in the logs. The crash params are weird though... certainly
not matching the doc. (
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0xac--hal-memory-allocation)
but then again they are not always to be believed.
There are some odd looking IOMMU faults in there too.

 Paul

On Thu, 24 Oct 2019 at 13:01, Steven Haigh  wrote:

> Hi all,
>
> I've managed to get the git master version of Xen on this affected
> system and tries to boot a Windows Server 2016 system. It crashes as
> per normal.
>
> I managed to get these logs, but I'm not quite sure what else to do to
> debug this issue further.
>
> Suggestions welcome.
>
> The boot log in /var/log/xen/ shows:
> Waiting for domain soti.vm (domid 4) to die [pid 9174]
> Domain 4 has shut down, reason code 3 0x3
> Action for shutdown reason code 3 is destroy
> Domain 4 needs to be cleaned up: destroying the domain
> Done. Exiting now
>
> For some reason I'm not getting any serial output - so I'll have to
> take a look at that tomorrow - but if you need anything further, please
> let me know and I'll see what I can turn up.
>
> Windows config file:
>
> type = "hvm"
> name = "$vmname.vm"
> viridian = 1
> #viridian = ['base']
> memory = 8192
> vcpus = 4
> vif = ['bridge=br51, mac=00:16:3E:64:CC:A0']
> #disk = [ '/dev/vg_hosting/$vmname.vm,raw,xvda,rw',
> 'file:/root/SW_DVD9_NTRL_Windows_Svrs_2016_English_2_Std_DC_FPP_OEM_X21-22567.ISO,hdc:cdrom,r'
>
> ]
> disk = [ '/dev/vg_hosting/$vmname.vm,raw,hda,rw' ]
> boot = 'cd'
> vnc = 2
> vnclisten = "0.0.0.0"
> #vncpasswd = ''
>
> ## Set the clock to localtime - not UTC...
> localtime = 1
>
> ## Fix the mouse cursor for VNC usage
> usbdevice = 'tablet'
>
> ## Lower CPU prio that other VMs...
> cpu_weight = 128
>
> on_poweroff = 'destroy'
> on_reboot = 'destroy'
> on_crash = 'destroy'
>
> Steven Haigh
>
>  net...@crc.id.au  https://www.crc.id.au
>  +613 9001 6090    +614 1293 5897
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 02/24] golang/xenlight: generate enum types from IDL

[George Dunlap]

On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook 
> 
> Introduce gengotypes.py to generate Go code the from IDL. As a first step,
> implement 'enum' type generation.
> 
> As a result of the newly-generated code, remove the existing, and now
> conflicting definitions in xenlight.go. In the case of the Error type,
> rename the slice 'errors' to 'libxlErrors' so that it does not conflict
> with the standard library package 'errors.' And, negate the values used
> in 'libxlErrors' since the generated error values are negative.
> 
> Signed-off-by: Nick Rosbrook 

This looks good, thanks.  Just needs to be ported after and/or merged
with the Makefile changes from 24/24.

 -George

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

Re: [Xen-devel] [PATCH 24/24] golang/xenlight: add make target for generated files

[George Dunlap]

On 10/7/19 4:13 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook 
> 
> Remove the PKGSOURCES variable since adding xenlight_types.go
> and xenlight_helpers.go to this list breaks the rest of the
> Makefile.
> 
> Add xenlight_%.go target for generated files, and use full
> file names within install, uninstall and $(XEN_GOPATH)$(GOXL_PKG_DIR)
> rule.
> 
> Signed-off-by: Nick Rosbrook 

Hey Nick!  Thanks for breaking down the series this way -- this is much
easier to review.

One standard practice when making a series is to try to avoid any
regressions, including build regressions, in the middle of the series.
This is particularly helpful to aid in bisections, but in this case it
makes it easier to observe the action of the `gengotypes.py` script (and
how it's meant to be called).

So I would basically make this part of patch 2, except remove references
to xenlight_helpers.go until the patch where that file is generated.

One other comment...

> ---
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> 
>  tools/golang/xenlight/Makefile | 22 ++
>  1 file changed, 14 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/golang/xenlight/Makefile b/tools/golang/xenlight/Makefile
> index 0987305224..821a5d48fa 100644
> --- a/tools/golang/xenlight/Makefile
> +++ b/tools/golang/xenlight/Makefile
> @@ -7,20 +7,22 @@ GOCODE_DIR ?= $(prefix)/share/gocode/
>  GOXL_PKG_DIR = /src/$(XEN_GOCODE_URL)/xenlight/
>  GOXL_INSTALL_DIR = $(GOCODE_DIR)$(GOXL_PKG_DIR)
>  
> -# PKGSOURCES: Files which comprise the distributed source package
> -PKGSOURCES = xenlight.go
> -
>  GO ?= go
>  
>  .PHONY: all
>  all: build
>  
>  .PHONY: package
> -package: $(XEN_GOPATH)$(GOXL_PKG_DIR)$(PKGSOURCES)
> +package: $(XEN_GOPATH)$(GOXL_PKG_DIR)
>  
> -$(XEN_GOPATH)/src/$(XEN_GOCODE_URL)/xenlight/$(PKGSOURCES): $(PKGSOURCES)
> +$(XEN_GOPATH)/src/$(XEN_GOCODE_URL)/xenlight/: xenlight_%.go
>   $(INSTALL_DIR) $(XEN_GOPATH)$(GOXL_PKG_DIR)
> - $(INSTALL_DATA) $(PKGSOURCES) $(XEN_GOPATH)$(GOXL_PKG_DIR)
> + $(INSTALL_DATA) xenlight.go $(XEN_GOPATH)$(GOXL_PKG_DIR)
> + $(INSTALL_DATA) xenlight_types.go $(XEN_GOPATH)$(GOXL_PKG_DIR)
> + $(INSTALL_DATA) xenlight_helpers.go $(XEN_GOPATH)$(GOXL_PKG_DIR)

It might be nice to have a naming convention for the generated files
that clues people in to the fact that they're generated (other than the
comment at the top of course).  In libxl, this is done by giving them a
leading underscore (e.g., _libxl_type.h); but the go compiler will
helpfully ignore such files. :-)

The go compiler will also do special things sometimes with things after
a `_`; e.g., "${foo}_test.go" will only be compiled for `go test`,
"${foo}_linux.go" will only be compiled on Linux, and so on.  I'm pretty
sure these names will be safe, but it might be slightly more
future-proof to avoid using an underscore in the names.

What about something like "gentypes.go" or "idltypes.go"?

Just a suggestion.

> +
> +xenlight_%.go: gengotypes.py $(XEN_ROOT)/tools/libxl/libxl_types.idl 
> $(XEN_ROOT)/tools/libxl/idl.py
> + XEN_ROOT=$(XEN_ROOT) $(PYTHON) gengotypes.py ../../libxl/libxl_types.idl
>  
>  # Go will do its own dependency checking, and not actuall go through
>  # with the build if none of the input files have changed.
> @@ -36,10 +38,14 @@ build: package
>  .PHONY: install
>  install: build
>   $(INSTALL_DIR) $(DESTDIR)$(GOXL_INSTALL_DIR)
> - $(INSTALL_DATA) $(XEN_GOPATH)$(GOXL_PKG_DIR)$(PKGSOURCES) 
> $(DESTDIR)$(GOXL_INSTALL_DIR)
> + $(install_data) $(xen_gopath)$(goxl_pkg_dir)xenlight.go 
> $(destdir)$(goxl_install_dir)
> + $(install_data) $(xen_gopath)$(goxl_pkg_dir)xenlight_types.go 
> $(destdir)$(goxl_install_dir)
> + $(install_data) $(xen_gopath)$(goxl_pkg_dir)xenlight_helpers.go 
> $(destdir)$(goxl_install_dir)
>  
>  .PHONY: uninstall
> - rm -f $(addprefix $(DESTDIR)$(GOXL_INSTALL_DIR)/, $(PKGSOURCES))
> + rm -f $(addprefix $(DESTDIR)$(GOXL_INSTALL_DIR)/, xenlight.go)
> + rm -f $(addprefix $(DESTDIR)$(GOXL_INSTALL_DIR)/, xenlight_types.go)
> + rm -f $(addprefix $(DESTDIR)$(GOXL_INSTALL_DIR)/, xenlight_helpers.go)

Kind of random, but would it make sense to `rm -rf` the whole directory
here instead?

 -George

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

[Xen-devel] [PATCH] tools/hotpug: only attempt to call 'ip route' if there is valid command

[paul]

From: Paul Durrant 

The vif-route script should only call 'ip route' when 'ipcmd' has been
set, otherwise it will fail due to an incorrect command string.

Signed-off-by: Paul Durrant 
---
Cc: Ian Jackson 
Cc: Wei Liu 

This appears to have been broken forever.
---
 tools/hotplug/Linux/vif-route | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/hotplug/Linux/vif-route b/tools/hotplug/Linux/vif-route
index c149ffca73..98893d90b6 100644
--- a/tools/hotplug/Linux/vif-route
+++ b/tools/hotplug/Linux/vif-route
@@ -35,7 +35,7 @@ case "${command}" in
 ;;
 esac
 
-if [ "${ip}" ] ; then
+if [ "${ipcmd}" ] ; then
 # If we've been given a list of IP addresses, then add routes from dom0 to
 # the guest using those addresses.
 for addr in ${ip} ; do
-- 
2.17.1


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

Re: [Xen-devel] [XEN PATCH for-4.13 v1] Reset iomem's gfn to LIBXL_INVALID_GFN on reboot

[Oleksandr Grytsov]

On Tue, Oct 22, 2019 at 9:14 PM Julien Grall  wrote:
>
> Hi Oleksandr,
>
> Apologies for the late answer.
>
> On 16/10/2019 14:09, Oleksandr Grytsov wrote:
> > On Mon, Oct 14, 2019 at 12:28 PM Julien Grall  wrote:
> > Thanks to point me out for this old thread. I completely forgot about it
> > (I haven't worked with xen since long time). I've performed additional
> > investigation
> > and found the root cause of the issue. It doesn't relate to iomem GFN 
> > directly.
> > The problem is in type from json parsing at place where libxl creates array 
> > of
> > struct.
> >
> > For example, libxl_domain_config_from_json calls libxl_domain_config_init
> > which initializes all child structures and arrays. But then when libxl 
> > parses
> > json and creates the array of structure, it doesn't initialize array 
> > elements
> > properly (see libxl__domain_build_info_parse_json iomem parsing):
> >
> > p->num_iomem = x->u.array->count;
> > p->iomem = libxl__calloc(NOGC, p->num_iomem, sizeof(*p->iomem));
> > if (!p->iomem && p->num_iomem != 0) {
> >  rc = -1;
> >  goto out;
> > }
> > for (i=0; (t=libxl__json_array_get(x,i)); i++) {
> >  rc = libxl__iomem_range_parse_json(gc, t, >iomem[i]);
> >  if (rc)
> > goto out;
> > }
> >
> > libxl creates array element with calloc function, so all element
> > fields are initialized
> > with zero values. Even some of them have default value different from zero.
> > For these purpose dedicated init function should be called for each element.
> > Above example should be:
> >
> > for (i=0; (t=libxl__json_array_get(x,i)); i++) {
> >  libxl_iomem_range_init(>iomem[i]);
> >  rc = libxl__iomem_range_parse_json(gc, t, >iomem[i]);
> >  if (rc)
> > goto out;
> > }
>
> Not initializing the values is fine as long as the JSON describes all the 
> fields
> of the structure.
>
> The key point here is the GFN is not described in the JSON (see
> libxl_iomem_range_gen_json) if it is equal to LIBXL_INVALID_GFN. As the field 
> is
> not described, it will be defaulted to 0.
>

Yes. So, either  ..._gen_json should generate entries for default
values or ..._parse_json
should set missing entries to its default values. Second solution looks more
correct.

> >
> > I've changes gentypes.py as following:
> >
> > diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
> > index 88e5c5f30e..92e28be469 100644
> > --- a/tools/libxl/gentypes.py
> > +++ b/tools/libxl/gentypes.py
> > @@ -454,6 +454,8 @@ def libxl_C_type_parse_json(ty, w, v, indent = "
> >   ", parent = None, discrimina
> >   s += "goto out;\n"
> >   s += "}\n"
> >   s += "for (i=0; (t=libxl__json_array_get(x,i)); i++) {\n"
> > +if ty.elem_type.init_fn is not None and
> > ty.elem_type.autogenerate_init_fn:
>
> My knowledge of libxl is quite limited. But I don't think this is correct, you
> want to call init_fn whether this has been autogenerated or not.
>
> > +s += indent + ""+"%s_init(&%s[i]);\n" %
> > (ty.elem_type.typename, v)
>
> Looking at the other usage (like _libxl_C_type_init), init_fn is called with
>
>  s += "%s(%s);\n" % (ty.init_fn, ty.pass_arg(v, parent is None))
>
> I am also not entirely sure whether we should also cater the ty.init_val != 
> None
> as well here.
>
> >   s += libxl_C_type_parse_json(ty.elem_type, "t", v+"[i]",
> >indent + "", parent)
> >   s += "}\n"
> >
> > I'm not sure is it right and complete fix.
> >
> > Ian, could you review?
> >
> > If the fix is ok, I will submit the patch.
>
> IHMO, the idea is there. The code may need some modifications (see above).
> Please post a patch so we can go forward in the process to review it.

Thanks. I will post the separate path.

>
> Cheers,
>
> --
> Julien Grall



-- 
Best Regards,
Oleksandr Grytsov.

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

Re: [Xen-devel] [PATCH v4 3/3] xen/efi: use directmap to access runtime services table

[marma...@invisiblethingslab.com]

On Thu, Oct 24, 2019 at 01:11:22PM +, Xia, Hongyan wrote:
> It is certainly nice to have less users of the direct map. My non-EFI
> builds already work without the direct map now but once I start testing
> EFI, it is nice to have one less thing to worry about.

Note this is just yet another EFI info that's included there. Others
are: efi_ct, efi_memmap, efi_fw_vendor. So, if you'd like to get rid of
directmap, you'll need to handle the others too in some way. Doing that
for 3 or 4 tables shouldn't make significant difference.

> How important and performance-critical is this? If we really want to
> avoid switching the page table, we could reserve a virtual range and
> map it to runtime services in Xen.

Honestly I don't think that's very critical. The biggest improvement is
for XEN_FW_EFI_RT_VERSION, where you avoid switching page tables at all.
In other cases, you avoid that for too old UEFIs only. Anyway, I think
none of it is on a hot path.
This is an optimization suggested by Jan, which is nice to have, but
definitely isn't the only possible option.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


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

Re: [Xen-devel] [PATCH] MAINTAINERS: correct decription of M:

[Jürgen Groß]

On 24.10.19 15:45, Jan Beulich wrote:

Let's reflect reality, its use by add_maintainers.pl / get_maintainer.pl,
as well as what
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches says.

Signed-off-by: Jan Beulich 


Release-acked-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH] MAINTAINERS: correct decription of M:

[George Dunlap]

On 10/24/19 2:45 PM, Jan Beulich wrote:
> Let's reflect reality, its use by add_maintainers.pl / get_maintainer.pl,
> as well as what
> https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches says.
> 
> Signed-off-by: Jan Beulich 

LGTM.

Acked-by: George Dunlap 


> 
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -59,7 +59,9 @@ appropriate branch.
>  
>  Descriptions of section entries:
>  
> - M: Mail patches to: FullName 
> + M: Maintainer: FullName 
> +Maintainers should be CCed on patches.  At least one of them
> +needs to approve changes to the covered files.
>   R: Designated reviewer: FullName 
>  Reviewers should be CCed on patches.  However, they do not
>  have a formal governance role, and are listed here
> 


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

[Xen-devel] [PATCH] MAINTAINERS: correct decription of M:

[Jan Beulich]

Let's reflect reality, its use by add_maintainers.pl / get_maintainer.pl,
as well as what
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches says.

Signed-off-by: Jan Beulich 

--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -59,7 +59,9 @@ appropriate branch.
 
 Descriptions of section entries:
 
-   M: Mail patches to: FullName 
+   M: Maintainer: FullName 
+  Maintainers should be CCed on patches.  At least one of them
+  needs to approve changes to the covered files.
R: Designated reviewer: FullName 
   Reviewers should be CCed on patches.  However, they do not
   have a formal governance role, and are listed here

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

Re: [Xen-devel] [PATCH] MAINTAINERS: Add DornerWorks maintainers email

[Jan Beulich]

On 24.10.2019 15:06, Jeff Kubascik wrote:
> We would like to remove our current two developers who are listed as M: for 
> the
> ARINC653 scheduler code. Since M: is just a "Mail patches to" designation, I'm
> now leaning towards the L: designation, as the two appear roughly equivalent 
> in
> their role. Does that sound reasonable?

While I realize what you say matches what the description of
M: says in ./MAINTAINERS, I'm afraid we also assign the
meaning of "is the maintainer of" to it, i.e. L: is not a
suitable equivalent (at least I don't think a list can
reasonably be considered a "maintainer"). It should perhaps
rather be R: the have this meaning.

As a side note, in addition I notice that M: says to mail
patches _to_ the listed people, which contradicts information
on e.g. the wiki where people are asked to send patches _to_
the list, with maintainers _cc_-ed (personally I prefer the
latter very much).

Jan

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

Re: [Xen-devel] [PATCH] MAINTAINERS: Add DornerWorks maintainers email

[Julien Grall]

Hi,

Jumping into the conversation.

On 24/10/2019 14:06, Jeff Kubascik wrote:

On 10/21/2019 7:43 AM, Wei Liu wrote:

CAUTION: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

On Mon, Oct 21, 2019 at 12:29:45PM +0100, George Dunlap wrote:

On 8/30/19 10:28 AM, Wei Liu wrote:

On Fri, Aug 23, 2019 at 10:08:55AM -0400, Jeff Kubascik wrote:

We would like to have a common maintainers email address for DornerWorks
maintained code, which currently is the ARINC653 scheduler. This will
enable us to better monitor and respond to the Xen community. This patch
adds a maintainer line with the DornerWorks maintainers email address.
---
  MAINTAINERS | 1 +
  1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 77413e0d9e..3cce253931 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -168,6 +168,7 @@ F: xen/common/argo.c
  ARINC653 SCHEDULER
  M:Josh Whitehead 
  M:Robert VanVossen 
+M:DornerWorks Xen-Devel 


The correct symbol here is L.

 L: Mailing list that is relevant to this area


But this isn't exactly a mailing list, is it?  The 'L:' tag is normally
for things like the Linux Arm mailing list, the Linux Net mailing list,
and so on -- *public* lists where discussions about that subsystem happen.

This isn't a public list where discussion happens.  At the moment, in
fact, it looks like it might be a *single email account*, to which
several people have access; at best it would be an alias that would go
to a number of interested parties.  That seems closer to 'R:'.

I admit this is getting into the minutia of technicalities here. :-)



My understanding is that the list being public is a not a requirement.
For example, Linux has this:

   L:  sparmaintai...@unisys.com (Unisys internal)

An alias for several people still qualifies as a list to me.

Anyway, either R or L works. I don't want to bikeshed further...

Wei.


  -George


We would like to remove our current two developers who are listed as M: for the
ARINC653 scheduler code. Since M: is just a "Mail patches to" designation, I'm
now leaning towards the L: designation, as the two appear roughly equivalent in
their role. Does that sound reasonable?


I don't think you can treat "L:" and "M:" the same way.

"M:" is a single person that we know.

"L:" is a list of person that we don't know.

xen-de...@dornerworks.com definitely falls into the "L:" category. That clearly 
raises a few questions here.


- How do we know when the list of person change?
	- How acked-by/reviewed-by will be done? Will it be Acked-by "Dornerworks 
<>"? If not, then we still need "M:" around to which acked-by is sufficient. 
If yes, how do we know all the person on that list can be trusted?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [xen-unstable test] 143061: regressions - trouble: broken/fail/pass

[Jürgen Groß]

On 24.10.19 14:13, Ian Jackson wrote:

Jürgen Groß writes ("Re: [Xen-devel] [xen-unstable test] 143061: regressions - 
trouble: broken/fail/pass"):

On 24.10.19 12:48, Ian Jackson wrote:

There is a known bug with two of our arm64 boxes, where they lose some
of the output during boot.  This is not important for operational use
of those boxes in a normal context, but in our context being able to
get all the boot messages is important for debugging hypervisors and
kernels, so osstest has a test that this works properly.  It is that
test that fails.

If this is the only failure, we should force push.


Agreed. Can you do so, please?


But it isn't in this flight.


Oh, sorry, then I misunderstood you. I thought the italia1 failure
would be regarded as non-blocking due to obvious hardware problem.


test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
didn't run because of the problem with italia1.  Force pushing would
be saying we don't mind about that.


Lets wait for the next run then.


Juergen


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

[Xen-devel] [PATCH] build: provide option to disambiguate symbol names

[Jan Beulich]

The .file assembler directives generated by the compiler do not include
any path components (gcc) or just the ones specified on the command line
(clang, at least version 5), and hence multiple identically named source
files (in different directories) may produce identically named static
symbols (in their kallsyms representation). The binary diffing algorithm
used by xen-livepatch, however, depends on having unique symbols.

Provide a Kconfig option to control the (build) behavior, and if enabled
use objcopy to prepend the (relative to the xen/ subdirectory) path to
the compiler invoked STT_FILE symbols.

Conditionalize explicit .file directive insertion in C files where it
exists just to disambiguate names in a less generic manner; note that
at the same time the redundant emission of STT_FILE symbols gets
suppressed for clang. Assembler files as well as multiply compiled C
ones using __OBJECT_FILE__ are left alone for the time being.

Signed-off-by: Jan Beulich 
---
Kconfig change taken from "[PATCH v3 5/7] x86/livepatch: Fail the build
if duplicate symbols exist". When re-basing onto that other patch I
think we will also want to drop that other patch'es adjustment to
allrandom.config again.

The clang behavior may require further tweaking if different versions
behave differently. Alternatively we could pass two --redefine-sym
arguments to objcopy.

--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -194,12 +194,24 @@ FORCE:
 
 .PHONY: clean
 clean:: $(addprefix _clean_, $(subdir-all))
-   rm -f *.o *~ core $(DEPS_RM)
+   rm -f *.o .*.o.tmp *~ core $(DEPS_RM)
 _clean_%/: FORCE
$(MAKE) -f $(BASEDIR)/Rules.mk -C $* clean
 
+SRCPATH := $(patsubst $(BASEDIR)/%,%,$(CURDIR))
+
 %.o: %.c Makefile
+ifeq ($(CONFIG_ENFORCE_UNIQUE_SYMBOLS),y)
+   $(CC) $(CFLAGS) -c $< -o $(@D)/.$(@F).tmp
+ifeq ($(clang),y)
+   $(OBJCOPY) --redefine-sym $<=$(SRCPATH)/$< $(@D)/.$(@F).tmp $@
+else
+   $(OBJCOPY) --redefine-sym $(
 #include 
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -16,7 +16,7 @@
  * with this program; If not, see .
  */
 
-asm(".file \"" __FILE__ "\"");
+EMIT_FILE;
 
 #include 
 #include 
--- a/xen/arch/x86/x86_64/physdev.c
+++ b/xen/arch/x86/x86_64/physdev.c
@@ -2,7 +2,7 @@
  * physdev.c
  */
 
-asm(".file \"" __FILE__ "\"");
+EMIT_FILE;
 
 #include 
 #include 
--- a/xen/arch/x86/x86_64/platform_hypercall.c
+++ b/xen/arch/x86/x86_64/platform_hypercall.c
@@ -2,7 +2,7 @@
  * platform_hypercall.c
  */
 
-asm(".file \"" __FILE__ "\"");
+EMIT_FILE;
 
 #include 
 #include 
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -338,9 +338,23 @@ config FAST_SYMBOL_LOOKUP
 
  If unsure, say Y.
 
+config ENFORCE_UNIQUE_SYMBOLS
+   bool "Enforce unique symbols"
+   default LIVEPATCH
+   ---help---
+ Multiple symbols with the same name aren't generally a problem
+ unless Live patching is to be used.
+
+ Livepatch loading involves resolving relocations against symbol
+ names, and attempting to a duplicate symbol in a livepatch will
+ result in incorrect livepatch application.
+
+ This option should be used to ensure that a build of Xen can have a
+ livepatch build and apply correctly.
+
 config SUPPRESS_DUPLICATE_SYMBOL_WARNINGS
-   bool "Suppress duplicate symbol warnings" if !LIVEPATCH
-   default y if !LIVEPATCH
+   bool "Suppress duplicate symbol warnings"
+   depends on !ENFORCE_UNIQUE_SYMBOLS
---help---
  Multiple symbols with the same name aren't generally a problem
  unless Live patching is to be used, so these warnings can be
--- a/xen/common/compat/domain.c
+++ b/xen/common/compat/domain.c
@@ -3,7 +3,7 @@
  *
  */
 
-asm(".file \"" __FILE__ "\"");
+EMIT_FILE;
 
 #include 
 #include 
--- a/xen/common/compat/kernel.c
+++ b/xen/common/compat/kernel.c
@@ -2,7 +2,7 @@
  * kernel.c
  */
 
-asm(".file \"" __FILE__ "\"");
+EMIT_FILE;
 
 #include 
 #include 
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -1,4 +1,4 @@
-asm(".file \"" __FILE__ "\"");
+EMIT_FILE;
 
 #include 
 #include 
--- a/xen/common/compat/multicall.c
+++ b/xen/common/compat/multicall.c
@@ -2,7 +2,7 @@
  * multicall.c
  */
 
-asm(".file \"" __FILE__ "\"");
+EMIT_FILE;
 
 #include 
 #include 
--- a/xen/include/xen/config.h
+++ b/xen/include/xen/config.h
@@ -11,7 +11,15 @@
 
 #ifndef __ASSEMBLY__
 #include 
+
+#if defined(CONFIG_ENFORCE_UNIQUE_SYMBOLS) || defined(__clang__)
+# define EMIT_FILE asm ( "" )
+#else
+# define EMIT_FILE asm ( ".file \"" __FILE__ "\"" )
+#endif
+
 #endif
+
 #include 
 
 #define EXPORT_SYMBOL(var)

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

Re: [Xen-devel] [PATCH v4 3/3] xen/efi: use directmap to access runtime services table

[Xia, Hongyan]

It is certainly nice to have less users of the direct map. My non-EFI
builds already work without the direct map now but once I start testing
EFI, it is nice to have one less thing to worry about.

How important and performance-critical is this? If we really want to
avoid switching the page table, we could reserve a virtual range and
map it to runtime services in Xen.

Hongyan

On Thu, 2019-10-24 at 05:45 +0200, Marek Marczykowski-Górecki wrote:
> Do not require switching page tables to access (static) information
> in
> the runtime services table itself, use directmap for this. This
> allows
> exiting early from XEN_EFI_query_capsule_capabilities,
> XEN_EFI_update_capsule and XEN_EFI_query_variable_info (in case of
> not
> supported call) without all the impact of page table switch.
> 
> Signed-off-by: Marek Marczykowski-Górecki <
> marma...@invisiblethingslab.com>
> ---
> New patch in v4. Can be applied independently of the other two.
> Specifically can be defered beyond 4.13.
> I'm also fine with dropping it, if adding directmap users is
> undesired.
> 
> Cc: Juergen Gross 
> ---
>  xen/common/efi/boot.c|  1 +
>  xen/common/efi/runtime.c | 19 ---
>  2 files changed, 5 insertions(+), 15 deletions(-)
> 
> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index 9debc5b..89b1c8a 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -1122,6 +1122,7 @@ static void __init efi_exit_boot(EFI_HANDLE
> ImageHandle, EFI_SYSTEM_TABLE *Syste
>  
>  /* Adjust pointers into EFI. */
>  efi_ct = (void *)efi_ct + DIRECTMAP_VIRT_START;
> +efi_rs = (void *)efi_rs + DIRECTMAP_VIRT_START;
>  efi_memmap = (void *)efi_memmap + DIRECTMAP_VIRT_START;
>  efi_fw_vendor = (void *)efi_fw_vendor + DIRECTMAP_VIRT_START;
>  }
> diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
> index ab53ebc..22fd6c9 100644
> --- a/xen/common/efi/runtime.c
> +++ b/xen/common/efi/runtime.c
> @@ -211,12 +211,7 @@ int efi_get_info(uint32_t idx, union
> xenpf_efi_info *info)
>  break;
>  case XEN_FW_EFI_RT_VERSION:
>  {
> -struct efi_rs_state state = efi_rs_enter();
> -
> -if ( !state.cr3 )
> -return -EOPNOTSUPP;
>  info->version = efi_rs->Hdr.Revision;
> -efi_rs_leave();
>  break;
>  }
>  case XEN_FW_EFI_CONFIG_TABLE:
> @@ -618,12 +613,11 @@ int efi_runtime_call(struct
> xenpf_efi_runtime_call *op)
>  break;
>  }
>  
> +if ( (efi_rs->Hdr.Revision >> 16) < 2 )
> +return -EOPNOTSUPP;
>  state = efi_rs_enter();
> -if ( !state.cr3 || (efi_rs->Hdr.Revision >> 16) < 2 )
> -{
> -efi_rs_leave();
> +if ( !state.cr3 )
>  return -EOPNOTSUPP;
> -}
>  status = efi_rs->QueryVariableInfo(
>  op->u.query_variable_info.attr,
>  >u.query_variable_info.max_store_size,
> @@ -637,13 +631,8 @@ int efi_runtime_call(struct
> xenpf_efi_runtime_call *op)
>  if ( op->misc )
>  return -EINVAL;
>  
> -state = efi_rs_enter();
> -if ( !state.cr3 || (efi_rs->Hdr.Revision >> 16) < 2 )
> -{
> -efi_rs_leave();
> +if ( (efi_rs->Hdr.Revision >> 16) < 2 )
>  return -EOPNOTSUPP;
> -}
> -efi_rs_leave();
>  /* XXX fall through for now */
>  default:
>  return -ENOSYS;
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] MAINTAINERS: Add DornerWorks maintainers email

[Jeff Kubascik]

On 10/21/2019 7:43 AM, Wei Liu wrote:
> CAUTION: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> On Mon, Oct 21, 2019 at 12:29:45PM +0100, George Dunlap wrote:
>> On 8/30/19 10:28 AM, Wei Liu wrote:
>>> On Fri, Aug 23, 2019 at 10:08:55AM -0400, Jeff Kubascik wrote:
 We would like to have a common maintainers email address for DornerWorks
 maintained code, which currently is the ARINC653 scheduler. This will
 enable us to better monitor and respond to the Xen community. This patch
 adds a maintainer line with the DornerWorks maintainers email address.
 ---
  MAINTAINERS | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/MAINTAINERS b/MAINTAINERS
 index 77413e0d9e..3cce253931 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -168,6 +168,7 @@ F: xen/common/argo.c
  ARINC653 SCHEDULER
  M:Josh Whitehead 
  M:Robert VanVossen 
 +M:DornerWorks Xen-Devel 
>>>
>>> The correct symbol here is L.
>>>
>>> L: Mailing list that is relevant to this area
>>
>> But this isn't exactly a mailing list, is it?  The 'L:' tag is normally
>> for things like the Linux Arm mailing list, the Linux Net mailing list,
>> and so on -- *public* lists where discussions about that subsystem happen.
>>
>> This isn't a public list where discussion happens.  At the moment, in
>> fact, it looks like it might be a *single email account*, to which
>> several people have access; at best it would be an alias that would go
>> to a number of interested parties.  That seems closer to 'R:'.
>>
>> I admit this is getting into the minutia of technicalities here. :-)
>>
> 
> My understanding is that the list being public is a not a requirement.
> For example, Linux has this:
> 
>   L:  sparmaintai...@unisys.com (Unisys internal)
> 
> An alias for several people still qualifies as a list to me.
> 
> Anyway, either R or L works. I don't want to bikeshed further...
> 
> Wei.
> 
>>  -George

We would like to remove our current two developers who are listed as M: for the
ARINC653 scheduler code. Since M: is just a "Mail patches to" designation, I'm
now leaning towards the L: designation, as the two appear roughly equivalent in
their role. Does that sound reasonable?

-Jeff K

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

[Xen-devel] [PATCH v2 for-4.13] CONTRIBUTING: drop blktap2 and add tools/libs

[Wei Liu]

Blktap2 is gone and tools/libs is missing in the document.

Signed-off-by: Wei Liu 
Reviewed-by: Juergen Gross 
Release-acked-by: Juergen Gross https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13] CONTRIBUTING: drop reference to blktap2

[Jürgen Groß]

On 24.10.19 14:14, Lars Kurth wrote:



On 24/10/2019, 12:22, "Wei Liu"  wrote:

 On Thu, Oct 24, 2019 at 01:13:13PM +0200, Jürgen Groß wrote:
 > On 24.10.19 13:06, Wei Liu wrote:
 > > Blktap2 is gone.
 > >
 > > Signed-off-by: Wei Liu 
 > > ---
 > >   CONTRIBUTING | 1 -
 > >   1 file changed, 1 deletion(-)
 > >
 > > diff --git a/CONTRIBUTING b/CONTRIBUTING
 > > index 47f53e9a49..4fff4fd9f6 100644
 > > --- a/CONTRIBUTING
 > > +++ b/CONTRIBUTING
 > > @@ -13,7 +13,6 @@ Most of the Xen Project code is licensed under 
GPLv2, but a number of
 > >   directories are primarily licensed under different licenses.
 > >   Most notably:
 > > - - tools/blktap2  : BSD-Modified
 > >- tools/libxc: LGPL v2.1
 > >- tools/libxl: LGPL v2.1
 > >- tools/xl   : LGPL v2.1
 > >
 >
 > Mind adding tools/libs instead?
 
 Sure. That can be done.
 
 Because tools/libs' code is mostly split from libxc and friends, I

 assume it is going to be LGPL v2.1 as well.
 
 Lars and Ian, your opinion?
 
Tools/libs does not have a COPYING file, so it is GPL by default. However, all the files I checked appear to have LGPL v2.1

So, the directory should probably have an appropriate COPYING file, but we do 
need to check all files in it


tools/libs/*/private.h have no license remark, all other *.c and *.h are
LGPL 2.1.


Juergen

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

Re: [Xen-devel] [PATCH RFC v1 00/12] mm: Don't mark hotplugged pages PG_reserved (including ZONE_DEVICE)

[David Hildenbrand]

On 23.10.19 09:26, David Hildenbrand wrote:

On 22.10.19 23:54, Dan Williams wrote:

Hi David,

Thanks for tackling this!


Thanks for having a look :)

[...]



I am probably a little bit too careful (but I don't want to break things).
In most places (besides KVM and vfio that are nuts), the
pfn_to_online_page() check could most probably be avoided by a
is_zone_device_page() check. However, I usually get suspicious when I see
a pfn_valid() check (especially after I learned that people mmap parts of
/dev/mem into user space, including memory without memmaps. Also, people
could memmap offline memory blocks this way :/). As long as this does not
hurt performance, I think we should rather do it the clean way.


I'm concerned about using is_zone_device_page() in places that are not
known to already have a reference to the page. Here's an audit of
current usages, and the ones I think need to cleaned up. The "unsafe"
ones do not appear to have any protections against the device page
being removed (get_dev_pagemap()). Yes, some of these were added by
me. The "unsafe? HMM" ones need HMM eyes because HMM leaks device
pages into anonymous memory paths and I'm not up to speed on how it
guarantees 'struct page' validity vs device shutdown without using
get_dev_pagemap().

smaps_pmd_entry(): unsafe

put_devmap_managed_page(): safe, page reference is held

is_device_private_page(): safe? gpu driver manages private page lifetime

is_pci_p2pdma_page(): safe, page reference is held

uncharge_page(): unsafe? HMM

add_to_kill(): safe, protected by get_dev_pagemap() and dax_lock_page()

soft_offline_page(): unsafe

remove_migration_pte(): unsafe? HMM

move_to_new_page(): unsafe? HMM

migrate_vma_pages() and helpers: unsafe? HMM

try_to_unmap_one(): unsafe? HMM

__put_page(): safe

release_pages(): safe

I'm hoping all the HMM ones can be converted to
is_device_private_page() directlly and have that routine grow a nice
comment about how it knows it can always safely de-reference its @page
argument.

For the rest I'd like to propose that we add a facility to determine
ZONE_DEVICE by pfn rather than page. The most straightforward why I
can think of would be to just add another bitmap to mem_section_usage
to indicate if a subsection is ZONE_DEVICE or not.


(it's a somewhat unrelated bigger discussion, but we can start discussing it in 
this thread)

I dislike this for three reasons

a) It does not protect against any races, really, it does not improve things.
b) We do have the exact same problem with pfn_to_online_page(). As long as we
don't hold the memory hotplug lock, memory can get offlined and remove any 
time. Racy.
c) We mix in ZONE specific stuff into the core. It should be "just another zone"

What I propose instead (already discussed in 
https://lkml.org/lkml/2019/10/10/87)

1. Convert SECTION_IS_ONLINE to SECTION_IS_ACTIVE
2. Convert SECTION_IS_ACTIVE to a subsection bitmap
3. Introduce pfn_active() that checks against the subsection bitmap
4. Once the memmap was initialized / prepared, set the subsection active
(similar to SECTION_IS_ONLINE in the buddy right now)
5. Before the memmap gets invalidated, set the subsection inactive
(similar to SECTION_IS_ONLINE in the buddy right now)
5. pfn_to_online_page() = pfn_active() && zone != ZONE_DEVICE
6. pfn_to_device_page() = pfn_active() && zone == ZONE_DEVICE



Dan, I am suspecting that you want a pfn_to_zone() that will not touch 
the memmap, because it could potentially (altmap) lie on slow memory, right?


A modification might make this possible (but I am not yet sure if we 
want a less generic MM implementation just to fine tune slow memmap 
access here)


1. Keep SECTION_IS_ONLINE as it is with the same semantics
2. Introduce a subsection bitmap to record active ("initialized memmap")
   PFNs. E.g., also set it when setting sections online.
3. Introduce pfn_active() that checks against the subsection bitmap
4. Once the memmap was initialized / prepared, set the subsection active
   (similar to SECTION_IS_ONLINE in the buddy right now)
5. Before the memmap gets invalidated, set the subsection inactive
   (similar to SECTION_IS_ONLINE in the buddy right now)
5. pfn_to_online_page() = pfn_active() && section == SECTION_IS_ONLINE
   (or keep it as is, depends on the RCU locking we eventually
implement)
6. pfn_to_device_page() = pfn_active() && section != SECTION_IS_ONLINE
7. use pfn_active() whenever we don't care about the zone.

Again, not really a friend of that, it hardcodes ZONE_DEVICE vs. 
!ZONE_DEVICE. When we do a random "pfn_to_page()" (e.g., a pfn walker) 
we really want to touch the memmap right away either way. So we can also 
directly read the zone from it. I really do prefer right now a more 
generic implementation.


--

Thanks,

David / dhildenb


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

Re: [Xen-devel] [PATCH for-4.13] CONTRIBUTING: drop reference to blktap2

[Ian Jackson]

Wei Liu writes ("Re: [Xen-devel] [PATCH for-4.13] CONTRIBUTING: drop reference 
to blktap2"):
> On Thu, Oct 24, 2019 at 01:13:13PM +0200, Jürgen Groß wrote:
> > Mind adding tools/libs instead?
> 
> Sure. That can be done.
> 
> Because tools/libs' code is mostly split from libxc and friends, I
> assume it is going to be LGPL v2.1 as well.
> 
> Lars and Ian, your opinion?

Err, this is surely a mechanical question ?  Ie, what licence are
these files in already.

I did
  git-grep -i -l copyright | xargs git-grep -L 'GNU Lesser General'
in tools/libs and there were no hits.

So I think the answer is indeed LGPL.

Ian.

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

[Xen-devel] [PATCH v1 09/10] mm/memory_hotplug: Don't mark pages PG_reserved when initializing the memmap

[David Hildenbrand]

Everything should be prepared to stop setting pages PG_reserved when
initializing the memmap on memory hotplug. Most importantly, we
stop marking ZONE_DEVICE pages PG_reserved.

a) We made sure that any code that relied on PG_reserved to detect
   ZONE_DEVICE memory will no longer rely on PG_reserved (especially,
   by relying on pfn_to_online_page() for now). Details can be found
   below.
b) We made sure that memory blocks with holes cannot be offlined and
   therefore also not onlined. We have quite some code that relies on
   memory holes being marked PG_reserved. This is now not an issue
   anymore.

generic_online_page() still calls __free_pages_core(), which performs
__ClearPageReserved(p). AFAIKS, this should not hurt.

It is worth nothing that the users of online_page_callback_t might see a
change. E.g., until now, pages not freed to the buddy by the HyperV
balloonm were set PG_reserved until freed via generic_online_page(). Now,
they would look like ordinarily allocated pages (refcount == 1). This
callback is used by the XEN balloon and the HyperV balloon. To not
introduce any silent errors, keep marking the pages PG_reserved. We can
most probably stop doing that, but have to double check if there are
issues (e.g., offlining code aborts right away in has_unmovable_pages()
when it runs into a PageReserved(page))

Update the documentation at various places in the MM core.

There are three PageReserved() users that might be affected by this change.
 - drivers/staging/gasket/gasket_page_table.c:gasket_release_page()
   -> We might (unlikely) set SetPageDirty() on a ZONE_DEVICE page
   -> I assume "we don't care"
 - drivers/staging/kpc2000/kpc_dma/fileops.c:transfer_complete_cb()
   -> We might (unlikely) set SetPageDirty() on a ZONE_DEVICE page
   -> I assume "we don't care"
 - mm/usercopy.c: check_page_span()
   -> According to Dan, non-HMM ZONE_DEVICE usage excluded this code since
  commit 52f476a323f9 ("libnvdimm/pmem: Bypass CONFIG_HARDENED_USERCOPY
  overhead")
   -> It is unclear whether we rally cared about ZONE_DEVICE here (HMM) or
  simply about "PG_reserved". The worst thing that could happen is a
  false negative with CONFIG_HARDENED_USERCOPY we should be able to
  identify easily.
   -> There is a discussion to rip out that code completely
   -> I assume "not relevant" / "we don't care"

I audited the other PageReserved() users. They don't affect ZONE_DEVICE:
 - mm/page_owner.c:pagetypeinfo_showmixedcount_print()
   -> Never called for ZONE_DEVICE, (+ pfn_to_online_page(pfn))
 - mm/page_owner.c:init_pages_in_zone()
   -> Never called for ZONE_DEVICE (!populated_zone(zone))
 - mm/page_ext.c:free_page_ext()
   -> Only a BUG_ON(PageReserved(page)), not relevant
 - mm/page_ext.c:has_unmovable_pages()
   -> Not releveant for ZONE_DEVICE
 - mm/page_ext.c:pfn_range_valid_contig()
   -> pfn_to_online_page() already guards us
 - mm/mempolicy.c:queue_pages_pte_range()
   -> vm_normal_page() checks against pte_devmap()
 - mm/memory-failure.c:hwpoison_user_mappings()
   -> Not reached via memory_failure() due to pfn_to_online_page()
   -> Also not reached indirectly via memory_failure_hugetlb()
 - mm/hugetlb.c:gather_bootmem_prealloc()
   -> Only a WARN_ON(PageReserved(page)), not relevant
 - kernel/power/snapshot.c:saveable_highmem_page()
   -> pfn_to_online_page() already guards us
 - kernel/power/snapshot.c:saveable_page()
   -> pfn_to_online_page() already guards us
 - fs/proc/task_mmu.c:can_gather_numa_stats()
   -> vm_normal_page() checks against pte_devmap()
 - fs/proc/task_mmu.c:can_gather_numa_stats_pmd
   -> vm_normal_page_pmd() checks against pte_devmap()
 - fs/proc/page.c:stable_page_flags()
   -> The reserved bit is simply copied, irrelevant
 - drivers/firmware/memmap.c:release_firmware_map_entry()
   -> really only a check to detect bootmem. Not relevant for ZONE_DEVICE
 - arch/ia64/kernel/mca_drv.c
 - arch/mips/mm/init.c
 - arch/mips/mm/ioremap.c
 - arch/nios2/mm/ioremap.c
 - arch/parisc/mm/ioremap.c
 - arch/sparc/mm/tlb.c
 - arch/xtensa/mm/cache.c
   -> No ZONE_DEVICE support
 - arch/powerpc/mm/init_64.c:vmemmap_free()
   -> Special-cases memmap on altmap
   -> Only a check for bootmem
 - arch/x86/kernel/alternative.c:__text_poke()
   -> Only a WARN_ON(!PageReserved(pages[0])) to verify it is bootmem
 - arch/x86/mm/init_64.c
   -> Only a check for bootmem

Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: Sasha Levin 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: Andrew Morton 
Cc: Alexander Duyck 
Cc: Pavel Tatashin 
Cc: Vlastimil Babka 
Cc: Johannes Weiner 
Cc: Anthony Yznaga 
Cc: Michal Hocko 
Cc: Oscar Salvador 
Cc: Dan Williams 
Cc: Mel Gorman 
Cc: Mike Rapoport 
Cc: Anshuman Khandual 
Cc: Matt Sickler 
Cc: Kees Cook 
Suggested-by: Michal Hocko 
Signed-off-by: David Hildenbrand 
---
 drivers/hv/hv_balloon.c|  6 ++
 drivers/xen/balloon.c  |  7 +++
 include/linux/page-flags.h |  8 +---
 

[Xen-devel] [PATCH v1 10/10] mm/usercopy.c: Update comment in check_page_span() regarding ZONE_DEVICE

[David Hildenbrand]

ZONE_DEVICE (a.k.a. device memory) is no longer marked PG_reserved. Update
the comment.

While at it, make it match what the code is acutally doing (reject vs.
accept).

Cc: Kees Cook 
Cc: Andrew Morton 
Cc: "Isaac J. Manjarres" 
Cc: "Matthew Wilcox (Oracle)" 
Cc: Qian Cai 
Cc: Thomas Gleixner 
Signed-off-by: David Hildenbrand 
---
 mm/usercopy.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/mm/usercopy.c b/mm/usercopy.c
index 660717a1ea5c..80f254024c97 100644
--- a/mm/usercopy.c
+++ b/mm/usercopy.c
@@ -199,9 +199,9 @@ static inline void check_page_span(const void *ptr, 
unsigned long n,
return;
 
/*
-* Reject if range is entirely either Reserved (i.e. special or
-* device memory), or CMA. Otherwise, reject since the object spans
-* several independently allocated pages.
+* Accept if the range is entirely either Reserved ("special") or
+* CMA. Otherwise, reject since the object spans several independently
+* allocated pages.
 */
is_reserved = PageReserved(page);
is_cma = is_migrate_cma_page(page);
-- 
2.21.0


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

Re: [Xen-devel] [xen-unstable test] 143061: regressions - trouble: broken/fail/pass

[Ian Jackson]

Jürgen Groß writes ("Re: [Xen-devel] [xen-unstable test] 143061: regressions - 
trouble: broken/fail/pass"):
> On 24.10.19 12:48, Ian Jackson wrote:
> > There is a known bug with two of our arm64 boxes, where they lose some
> > of the output during boot.  This is not important for operational use
> > of those boxes in a normal context, but in our context being able to
> > get all the boot messages is important for debugging hypervisors and
> > kernels, so osstest has a test that this works properly.  It is that
> > test that fails.
> > 
> > If this is the only failure, we should force push.
> 
> Agreed. Can you do so, please?

But it isn't in this flight.

test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
didn't run because of the problem with italia1.  Force pushing would
be saying we don't mind about that.

Ian.

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

Re: [Xen-devel] [PATCH for-4.13] CONTRIBUTING: drop reference to blktap2

[Lars Kurth]

On 24/10/2019, 12:22, "Wei Liu"  wrote:

On Thu, Oct 24, 2019 at 01:13:13PM +0200, Jürgen Groß wrote:
> On 24.10.19 13:06, Wei Liu wrote:
> > Blktap2 is gone.
> > 
> > Signed-off-by: Wei Liu 
> > ---
> >   CONTRIBUTING | 1 -
> >   1 file changed, 1 deletion(-)
> > 
> > diff --git a/CONTRIBUTING b/CONTRIBUTING
> > index 47f53e9a49..4fff4fd9f6 100644
> > --- a/CONTRIBUTING
> > +++ b/CONTRIBUTING
> > @@ -13,7 +13,6 @@ Most of the Xen Project code is licensed under GPLv2, 
but a number of
> >   directories are primarily licensed under different licenses.
> >   Most notably:
> > - - tools/blktap2  : BSD-Modified
> >- tools/libxc: LGPL v2.1
> >- tools/libxl: LGPL v2.1
> >- tools/xl   : LGPL v2.1
> > 
> 
> Mind adding tools/libs instead?

Sure. That can be done.

Because tools/libs' code is mostly split from libxc and friends, I
assume it is going to be LGPL v2.1 as well.

Lars and Ian, your opinion?

Tools/libs does not have a COPYING file, so it is GPL by default. However, all 
the files I checked appear to have LGPL v2.1
So, the directory should probably have an appropriate COPYING file, but we do 
need to check all files in it

Regards
Lars 

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

[Xen-devel] [qemu-mainline test] 143070: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvshim   12 guest-start  fail REGR. vs. 142915
 test-armhf-armhf-libvirt-raw 18 leak-check/check fail REGR. vs. 142915

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds 17 guest-start.2   fail blocked in 142915
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 142915
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 142915
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 142915
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 142915
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 142915
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuu69717d0f890e14cbdd668297751f9446d2e2a8fd
baseline version:
 qemuue9d42461920f6f40f4d847a5ba18e90d095ed0b9

Last test of basis   142915  2019-10-19 14:49:41 Z4 days
Failing since143030  2019-10-22 11:08:39 Z2 days3 attempts
Testing same since   143070  2019-10-23 16:06:20 Z0 days1 attempts


People who touched revisions under test:
  Andreas Schwab 
  Andrew Jones 
  Cornelia Huck 
  David 

[Xen-devel] [PATCH v1 08/10] x86/mm: Prepare __ioremap_check_ram() for PG_reserved changes

[David Hildenbrand]

Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.

Rewrite __ioremap_check_ram() to make sure the function produces the
same result once we stop setting ZONE_DEVICE pages PG_reserved.

Cc: Dave Hansen 
Cc: Andy Lutomirski 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Signed-off-by: David Hildenbrand 
---
 arch/x86/mm/ioremap.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index a39dcdb5ae34..db6913b48edf 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -77,10 +77,17 @@ static unsigned int __ioremap_check_ram(struct resource 
*res)
start_pfn = (res->start + PAGE_SIZE - 1) >> PAGE_SHIFT;
stop_pfn = (res->end + 1) >> PAGE_SHIFT;
if (stop_pfn > start_pfn) {
-   for (i = 0; i < (stop_pfn - start_pfn); ++i)
-   if (pfn_valid(start_pfn + i) &&
-   !PageReserved(pfn_to_page(start_pfn + i)))
+   for (i = 0; i < (stop_pfn - start_pfn); ++i) {
+   struct page *page;
+/*
+ * We treat any pages that are not online (not managed
+ * by the buddy) as not being RAM. This includes
+ * ZONE_DEVICE pages.
+ */
+   page = pfn_to_online_page(start_pfn + i);
+   if (page && !PageReserved(page))
return IORES_MAP_SYSTEM_RAM;
+   }
}
 
return 0;
-- 
2.21.0


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

[Xen-devel] [PATCH v1 07/10] powerpc/mm: Prepare maybe_pte_to_page() for PG_reserved changes

[David Hildenbrand]

Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.

Rewrite maybe_pte_to_page() to make sure the function produces the
same result once we stop setting ZONE_DEVICE pages PG_reserved.

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Christophe Leroy 
Cc: "Aneesh Kumar K.V" 
Cc: Allison Randal 
Cc: Nicholas Piggin 
Cc: Thomas Gleixner 
Signed-off-by: David Hildenbrand 
---
 arch/powerpc/mm/pgtable.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
index e3759b69f81b..613c98fa7dc0 100644
--- a/arch/powerpc/mm/pgtable.c
+++ b/arch/powerpc/mm/pgtable.c
@@ -55,10 +55,12 @@ static struct page *maybe_pte_to_page(pte_t pte)
unsigned long pfn = pte_pfn(pte);
struct page *page;
 
-   if (unlikely(!pfn_valid(pfn)))
-   return NULL;
-   page = pfn_to_page(pfn);
-   if (PageReserved(page))
+   /*
+* We reject any pages that are not online (not managed by the buddy).
+* This includes ZONE_DEVICE pages.
+*/
+   page = pfn_to_online_page(pfn);
+   if (unlikely(!page || PageReserved(page)))
return NULL;
return page;
 }
-- 
2.21.0


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

[Xen-devel] [PATCH v1 06/10] powerpc/64s: Prepare hash_page_do_lazy_icache() for PG_reserved changes

[David Hildenbrand]

Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.

Rewrite hash_page_do_lazy_icache() to make sure the function produces the
same result once we stop setting ZONE_DEVICE pages PG_reserved.

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: "Aneesh Kumar K.V" 
Cc: Christophe Leroy 
Cc: Nicholas Piggin 
Cc: Andrew Morton 
Cc: Mike Rapoport 
Cc: YueHaibing 
Signed-off-by: David Hildenbrand 
---
 arch/powerpc/mm/book3s64/hash_utils.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/mm/book3s64/hash_utils.c 
b/arch/powerpc/mm/book3s64/hash_utils.c
index 6c123760164e..a1566039e747 100644
--- a/arch/powerpc/mm/book3s64/hash_utils.c
+++ b/arch/powerpc/mm/book3s64/hash_utils.c
@@ -1084,13 +1084,15 @@ void hash__early_init_mmu_secondary(void)
  */
 unsigned int hash_page_do_lazy_icache(unsigned int pp, pte_t pte, int trap)
 {
-   struct page *page;
+   struct page *page = pfn_to_online_page(pte_pfn(pte));
 
-   if (!pfn_valid(pte_pfn(pte)))
+   /*
+* We ignore any pages that are not online (not managed by the buddy).
+* This includes ZONE_DEVICE pages.
+*/
+   if (!page)
return pp;
 
-   page = pte_page(pte);
-
/* page is dirty */
if (!test_bit(PG_arch_1, >flags) && !PageReserved(page)) {
if (trap == 0x400) {
-- 
2.21.0


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

[Xen-devel] [PATCH v1 05/10] powerpc/book3s: Prepare kvmppc_book3s_instantiate_page() for PG_reserved changes

[David Hildenbrand]

Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.

KVM has this weird use case that you can map anything from /dev/mem
into the guest. pfn_valid() is not a reliable check whether the memmap
was initialized and can be touched. pfn_to_online_page() makes sure
that we have an initialized memmap (and don't have ZONE_DEVICE memory).

Rewrite kvmppc_book3s_instantiate_page() similar to kvm_is_reserved_pfn()
to make sure the function produces the same result once we stop setting
ZONE_DEVICE pages PG_reserved.

Cc: Paul Mackerras 
Cc: Benjamin Herrenschmidt 
Cc: Michael Ellerman 
Signed-off-by: David Hildenbrand 
---
 arch/powerpc/kvm/book3s_64_mmu_radix.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c 
b/arch/powerpc/kvm/book3s_64_mmu_radix.c
index 2d415c36a61d..05397c0561fc 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
@@ -801,12 +801,14 @@ int kvmppc_book3s_instantiate_page(struct kvm_vcpu *vcpu,
   writing, upgrade_p);
if (is_error_noslot_pfn(pfn))
return -EFAULT;
-   page = NULL;
-   if (pfn_valid(pfn)) {
-   page = pfn_to_page(pfn);
-   if (PageReserved(page))
-   page = NULL;
-   }
+   /*
+* We treat any pages that are not online (not managed by the
+* buddy) as reserved - this includes ZONE_DEVICE pages and
+* pages without a memmap (e.g., mapped via /dev/mem).
+*/
+   page = pfn_to_online_page(pfn);
+   if (page && PageReserved(page))
+   page = NULL;
}
 
/*
-- 
2.21.0


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

[Xen-devel] [PATCH v1 04/10] vfio/type1: Prepare is_invalid_reserved_pfn() for PG_reserved changes

[David Hildenbrand]

Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.

KVM has this weird use case that you can map anything from /dev/mem
into the guest. pfn_valid() is not a reliable check whether the memmap
was initialized and can be touched. pfn_to_online_page() makes sure
that we have an initialized memmap (and don't have ZONE_DEVICE memory).

Rewrite is_invalid_reserved_pfn() similar to kvm_is_reserved_pfn() to make
sure the function produces the same result once we stop setting ZONE_DEVICE
pages PG_reserved.

Cc: Alex Williamson 
Cc: Cornelia Huck 
Signed-off-by: David Hildenbrand 
---
 drivers/vfio/vfio_iommu_type1.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 2ada8e6cdb88..f8ce8c408ba8 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -299,9 +299,15 @@ static int vfio_lock_acct(struct vfio_dma *dma, long 
npage, bool async)
  */
 static bool is_invalid_reserved_pfn(unsigned long pfn)
 {
-   if (pfn_valid(pfn))
-   return PageReserved(pfn_to_page(pfn));
+   struct page *page = pfn_to_online_page(pfn);
 
+   /*
+* We treat any pages that are not online (not managed by the buddy)
+* as reserved - this includes ZONE_DEVICE pages and pages without
+* a memmap (e.g., mapped via /dev/mem).
+*/
+   if (page)
+   return PageReserved(page);
return true;
 }
 
-- 
2.21.0


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

[Xen-devel] [PATCH v1 03/10] KVM: Prepare kvm_is_reserved_pfn() for PG_reserved changes

[David Hildenbrand]

Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.

KVM has this weird use case that you can map anything from /dev/mem
into the guest. pfn_valid() is not a reliable check whether the memmap
was initialized and can be touched. pfn_to_online_page() makes sure
that we have an initialized memmap (and don't have ZONE_DEVICE memory).

Rewrite kvm_is_reserved_pfn() to make sure the function produces the
same result once we stop setting ZONE_DEVICE pages PG_reserved.

Cc: Paolo Bonzini 
Cc: "Radim Krčmář" 
Cc: Michal Hocko 
Cc: Dan Williams 
Cc: KarimAllah Ahmed 
Signed-off-by: David Hildenbrand 
---
 virt/kvm/kvm_main.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index e9eb666eb6e8..9d18cc67d124 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -151,9 +151,15 @@ __weak int kvm_arch_mmu_notifier_invalidate_range(struct 
kvm *kvm,
 
 bool kvm_is_reserved_pfn(kvm_pfn_t pfn)
 {
-   if (pfn_valid(pfn))
-   return PageReserved(pfn_to_page(pfn));
+   struct page *page = pfn_to_online_page(pfn);
 
+   /*
+* We treat any pages that are not online (not managed by the buddy)
+* as reserved - this includes ZONE_DEVICE pages and pages without
+* a memmap (e.g., mapped via /dev/mem).
+*/
+   if (page)
+   return PageReserved(page);
return true;
 }
 
-- 
2.21.0


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

[Xen-devel] [PATCH v1 01/10] mm/memory_hotplug: Don't allow to online/offline memory blocks with holes

[David Hildenbrand]

Our onlining/offlining code is unnecessarily complicated. Only memory
blocks added during boot can have holes (a range that is not
IORESOURCE_SYSTEM_RAM). Hotplugged memory never has holes (e.g., see
add_memory_resource()). All boot memory is alread online.

Therefore, when we stop allowing to offline memory blocks with holes, we
implicitly no longer have to deal with onlining memory blocks with holes.

This allows to simplify the code. For example, we no longer have to
worry about marking pages that fall into memory holes PG_reserved when
onlining memory. We can stop setting pages PG_reserved.

Offlining memory blocks added during boot is usually not guranteed to work
either way (unmovable data might have easily ended up on that memory during
boot). So stopping to do that should not really hurt (+ people are not
even aware of a setup where that used to work and that the existing code
still works correctly with memory holes). For the use case of offlining
memory to unplug DIMMs, we should see no change. (holes on DIMMs would be
weird).

Please note that hardware errors (PG_hwpoison) are not memory holes and
not affected by this change when offlining.

Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Oscar Salvador 
Cc: Pavel Tatashin 
Cc: Dan Williams 
Cc: Anshuman Khandual 
Signed-off-by: David Hildenbrand 
---
 mm/memory_hotplug.c | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 561371ead39a..8d81730cf036 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1447,10 +1447,19 @@ static void node_states_clear_node(int node, struct 
memory_notify *arg)
node_clear_state(node, N_MEMORY);
 }
 
+static int count_system_ram_pages_cb(unsigned long start_pfn,
+unsigned long nr_pages, void *data)
+{
+   unsigned long *nr_system_ram_pages = data;
+
+   *nr_system_ram_pages += nr_pages;
+   return 0;
+}
+
 static int __ref __offline_pages(unsigned long start_pfn,
  unsigned long end_pfn)
 {
-   unsigned long pfn, nr_pages;
+   unsigned long pfn, nr_pages = 0;
unsigned long offlined_pages = 0;
int ret, node, nr_isolate_pageblock;
unsigned long flags;
@@ -1461,6 +1470,20 @@ static int __ref __offline_pages(unsigned long start_pfn,
 
mem_hotplug_begin();
 
+   /*
+* Don't allow to offline memory blocks that contain holes.
+* Consecuently, memory blocks with holes can never get onlined
+* (hotplugged memory has no holes and all boot memory is online).
+* This allows to simplify the onlining/offlining code quite a lot.
+*/
+   walk_system_ram_range(start_pfn, end_pfn - start_pfn, _pages,
+ count_system_ram_pages_cb);
+   if (nr_pages != end_pfn - start_pfn) {
+   ret = -EINVAL;
+   reason = "memory holes";
+   goto failed_removal;
+   }
+
/* This makes hotplug much easier...and readable.
   we assume this for now. .*/
if (!test_pages_in_a_zone(start_pfn, end_pfn, _start,
@@ -1472,7 +1495,6 @@ static int __ref __offline_pages(unsigned long start_pfn,
 
zone = page_zone(pfn_to_page(valid_start));
node = zone_to_nid(zone);
-   nr_pages = end_pfn - start_pfn;
 
/* set above range as isolated */
ret = start_isolate_page_range(start_pfn, end_pfn,
-- 
2.21.0


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

[Xen-devel] [PATCH v1 02/10] KVM: x86/mmu: Prepare kvm_is_mmio_pfn() for PG_reserved changes

[David Hildenbrand]

Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.

KVM has this weird use case that you can map anything from /dev/mem
into the guest. pfn_valid() is not a reliable check whether the memmap
was initialized and can be touched. pfn_to_online_page() makes sure
that we have an initialized memmap (and don't have ZONE_DEVICE memory).

Rewrite kvm_is_mmio_pfn() to make sure the function produces the
same result once we stop setting ZONE_DEVICE pages PG_reserved.

Cc: Paolo Bonzini 
Cc: "Radim Krčmář" 
Cc: Sean Christopherson 
Cc: Vitaly Kuznetsov 
Cc: Wanpeng Li 
Cc: Jim Mattson 
Cc: Joerg Roedel 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: KarimAllah Ahmed 
Cc: Michal Hocko 
Cc: Dan Williams 
Signed-off-by: David Hildenbrand 
---
 arch/x86/kvm/mmu.c | 29 +
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 24c23c66b226..f03089a336de 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2962,20 +2962,25 @@ static bool mmu_need_write_protect(struct kvm_vcpu 
*vcpu, gfn_t gfn,
 
 static bool kvm_is_mmio_pfn(kvm_pfn_t pfn)
 {
+   struct page *page = pfn_to_online_page(pfn);
+
+   /*
+* ZONE_DEVICE pages are never online. Online pages that are reserved
+* either indicate the zero page or MMIO pages.
+*/
+   if (page)
+   return !is_zero_pfn(pfn) && PageReserved(pfn_to_page(pfn));
+
+   /*
+* Anything with a valid (but not online) memmap could be ZONE_DEVICE.
+* Treat only UC/UC-/WC pages as MMIO.
+*/
if (pfn_valid(pfn))
-   return !is_zero_pfn(pfn) && PageReserved(pfn_to_page(pfn)) &&
-   /*
-* Some reserved pages, such as those from NVDIMM
-* DAX devices, are not for MMIO, and can be mapped
-* with cached memory type for better performance.
-* However, the above check misconceives those pages
-* as MMIO, and results in KVM mapping them with UC
-* memory type, which would hurt the performance.
-* Therefore, we check the host memory type in addition
-* and only treat UC/UC-/WC pages as MMIO.
-*/
-   (!pat_enabled() || pat_pfn_immune_to_uc_mtrr(pfn));
+   return !pat_enabled() || pat_pfn_immune_to_uc_mtrr(pfn);
 
+   /*
+* Any RAM that has no memmap (e.g., mapped via /dev/mem) is not MMIO.
+*/
return !e820__mapped_raw_any(pfn_to_hpa(pfn),
 pfn_to_hpa(pfn + 1) - 1,
 E820_TYPE_RAM);
-- 
2.21.0


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

[Xen-devel] [PATCH v1 00/10] mm: Don't mark hotplugged pages PG_reserved (including ZONE_DEVICE)

[David Hildenbrand]

This is the result of a recent discussion with Michal ([1], [2]). Right
now we set all pages PG_reserved when initializing hotplugged memmaps. This
includes ZONE_DEVICE memory. In case of system memory, PG_reserved is
cleared again when onlining the memory, in case of ZONE_DEVICE memory
never.

In ancient times, we needed PG_reserved, because there was no way to tell
whether the memmap was already properly initialized. We now have
SECTION_IS_ONLINE for that in the case of !ZONE_DEVICE memory. ZONE_DEVICE
memory is already initialized deferred, and there shouldn't be a visible
change in that regard.

One of the biggest fears were side effects. I went ahead and audited all
users of PageReserved(). The details can be found in "mm/memory_hotplug:
Don't mark pages PG_reserved when initializing the memmap".

This patch set adapts all relevant users of PageReserved() to keep the
existing behavior in respect to ZONE_DEVICE pages. The biggest part part
that needs changes is KVM, to keep the existing behavior (that's all I
care about in this series).

Note that this series is able to rely completely on pfn_to_online_page().
No new is_zone_device_page() calles are introduced (as requested by Dan).
We are currently discussing a way to mark also ZONE_DEVICE memmaps as
active/initialized - pfn_active() - and lightweight locking to make sure
memmaps remain active (e.g., using RCU). We might later be able to convert
some suers of pfn_to_online_page() to pfn_active(). Details can be found
in [3], however, this represents yet another cleanup/fix we'll perform
on top of this cleanup.

I only gave it a quick test with DIMMs on x86-64, but didn't test the
ZONE_DEVICE part at all (any tips for a nice QEMU setup?). Also, I didn't
test the KVM parts (especially with ZONE_DEVICE pages or no memmap at all).
Compile-tested on x86-64 and PPC.

Based on next/master. The current version (kept updated) can be found at:
https://github.com/davidhildenbrand/linux.git online_reserved_cleanup

RFC -> v1:
- Dropped "staging/gasket: Prepare gasket_release_page() for PG_reserved
  changes"
- Dropped "staging: kpc2000: Prepare transfer_complete_cb() for PG_reserved
  changes"
- Converted "mm/usercopy.c: Prepare check_page_span() for PG_reserved
  changes" to "mm/usercopy.c: Update comment in check_page_span()
  regarding ZONE_DEVICE"
- No new users of is_zone_device_page() are introduced.
- Rephrased comments and patch descriptions.

[1] https://lkml.org/lkml/2019/10/21/736
[2] https://lkml.org/lkml/2019/10/21/1034
[3] https://www.spinics.net/lists/linux-mm/msg194112.html

Cc: Michal Hocko 
Cc: Dan Williams 
Cc: kvm-...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: k...@vger.kernel.org
Cc: linux-hyp...@vger.kernel.org
Cc: de...@driverdev.osuosl.org
Cc: xen-devel@lists.xenproject.org
Cc: x...@kernel.org
Cc: Alexander Duyck 

David Hildenbrand (10):
  mm/memory_hotplug: Don't allow to online/offline memory blocks with
holes
  KVM: x86/mmu: Prepare kvm_is_mmio_pfn() for PG_reserved changes
  KVM: Prepare kvm_is_reserved_pfn() for PG_reserved changes
  vfio/type1: Prepare is_invalid_reserved_pfn() for PG_reserved changes
  powerpc/book3s: Prepare kvmppc_book3s_instantiate_page() for
PG_reserved changes
  powerpc/64s: Prepare hash_page_do_lazy_icache() for PG_reserved
changes
  powerpc/mm: Prepare maybe_pte_to_page() for PG_reserved changes
  x86/mm: Prepare __ioremap_check_ram() for PG_reserved changes
  mm/memory_hotplug: Don't mark pages PG_reserved when initializing the
memmap
  mm/usercopy.c: Update comment in check_page_span() regarding
ZONE_DEVICE

 arch/powerpc/kvm/book3s_64_mmu_radix.c | 14 +
 arch/powerpc/mm/book3s64/hash_utils.c  | 10 +++---
 arch/powerpc/mm/pgtable.c  | 10 +++---
 arch/x86/kvm/mmu.c | 29 ++---
 arch/x86/mm/ioremap.c  | 13 ++--
 drivers/hv/hv_balloon.c|  6 
 drivers/vfio/vfio_iommu_type1.c| 10 --
 drivers/xen/balloon.c  |  7 +
 include/linux/page-flags.h |  8 +
 mm/memory_hotplug.c| 43 +++---
 mm/page_alloc.c| 11 ---
 mm/usercopy.c  |  6 ++--
 virt/kvm/kvm_main.c| 10 --
 13 files changed, 111 insertions(+), 66 deletions(-)

-- 
2.21.0


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

Re: [Xen-devel] [PATCH v3 5/7] x86/livepatch: Fail the build if duplicate symbols exist

[Jan Beulich]

On 23.10.2019 15:58, Andrew Cooper wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -361,9 +361,23 @@ config FAST_SYMBOL_LOOKUP
>  
> If unsure, say Y.
>  
> +config ENFORCE_UNIQUE_SYMBOLS
> + bool "Enforce unique symbols" if LIVEPATCH
> + default y if LIVEPATCH

Instead of two identical "if", why not "depends on LIVEPATCH"?

> + ---help---
> +   Multiple symbols with the same name aren't generally a problem
> +   unless Live patching is to be used.
> +
> +   Livepatch loading involves resolving relocations against symbol
> +   names, and attempting to a duplicate symbol in a livepatch will
> +   result in incorrect livepatch application.
> +
> +   This option should be used to ensure that a build of Xen can have a
> +   livepatch build and apply correctly.
> +
>  config SUPPRESS_DUPLICATE_SYMBOL_WARNINGS
> - bool "Suppress duplicate symbol warnings" if !LIVEPATCH
> - default y if !LIVEPATCH
> + bool "Suppress duplicate symbol warnings" if !ENFORCE_UNIQUE_SYMBOLS
> + default y if !ENFORCE_UNIQUE_SYMBOLS

Similarly here then. With this changed, or with a proper reason
supplied
Reviewed-by: Jan Beulich 

Jan

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

[Xen-devel] Debugging Windows HVM crashes on Ryzen 3xxx series CPUs.

[Steven Haigh]

Hi all,

I've managed to get the git master version of Xen on this affected 
system and tries to boot a Windows Server 2016 system. It crashes as 
per normal.


I managed to get these logs, but I'm not quite sure what else to do to 
debug this issue further.


Suggestions welcome.

The boot log in /var/log/xen/ shows:
Waiting for domain soti.vm (domid 4) to die [pid 9174]
Domain 4 has shut down, reason code 3 0x3
Action for shutdown reason code 3 is destroy
Domain 4 needs to be cleaned up: destroying the domain
Done. Exiting now

For some reason I'm not getting any serial output - so I'll have to 
take a look at that tomorrow - but if you need anything further, please 
let me know and I'll see what I can turn up.


Windows config file:

type = "hvm"
name = "$vmname.vm"
viridian = 1
#viridian = ['base']
memory = 8192
vcpus = 4
vif = ['bridge=br51, mac=00:16:3E:64:CC:A0']
#disk = [ '/dev/vg_hosting/$vmname.vm,raw,xvda,rw', 
'file:/root/SW_DVD9_NTRL_Windows_Svrs_2016_English_2_Std_DC_FPP_OEM_X21-22567.ISO,hdc:cdrom,r' 
]

disk = [ '/dev/vg_hosting/$vmname.vm,raw,hda,rw' ]
boot = 'cd'
vnc = 2
vnclisten = "0.0.0.0"
#vncpasswd = ''

## Set the clock to localtime - not UTC...
localtime = 1

## Fix the mouse cursor for VNC usage
usbdevice = 'tablet'

## Lower CPU prio that other VMs...
cpu_weight = 128

on_poweroff = 'destroy'
on_reboot = 'destroy'
on_crash = 'destroy'

Steven Haigh

 net...@crc.id.au  https://www.crc.id.au
 +613 9001 6090    +614 1293 5897


(XEN) HVM d4v0 save: CPU
(XEN) HVM d4v1 save: CPU
(XEN) HVM d4v2 save: CPU
(XEN) HVM d4v3 save: CPU
(XEN) HVM d4 save: PIC
(XEN) HVM d4 save: IOAPIC
(XEN) HVM d4v0 save: LAPIC
(XEN) HVM d4v1 save: LAPIC
(XEN) HVM d4v2 save: LAPIC
(XEN) HVM d4v3 save: LAPIC
(XEN) HVM d4v0 save: LAPIC_REGS
(XEN) HVM d4v1 save: LAPIC_REGS
(XEN) HVM d4v2 save: LAPIC_REGS
(XEN) HVM d4v3 save: LAPIC_REGS
(XEN) HVM d4 save: PCI_IRQ
(XEN) HVM d4 save: ISA_IRQ
(XEN) HVM d4 save: PCI_LINK
(XEN) HVM d4 save: PIT
(XEN) HVM d4 save: RTC
(XEN) HVM d4 save: HPET
(XEN) HVM d4 save: PMTIMER
(XEN) HVM d4v0 save: MTRR
(XEN) HVM d4v1 save: MTRR
(XEN) HVM d4v2 save: MTRR
(XEN) HVM d4v3 save: MTRR
(XEN) HVM d4 save: VIRIDIAN_DOMAIN
(XEN) HVM d4v0 save: CPU_XSAVE
(XEN) HVM d4v1 save: CPU_XSAVE
(XEN) HVM d4v2 save: CPU_XSAVE
(XEN) HVM d4v3 save: CPU_XSAVE
(XEN) HVM d4v0 save: VIRIDIAN_VCPU
(XEN) HVM d4v1 save: VIRIDIAN_VCPU
(XEN) HVM d4v2 save: VIRIDIAN_VCPU
(XEN) HVM d4v3 save: VIRIDIAN_VCPU
(XEN) HVM d4v0 save: VMCE_VCPU
(XEN) HVM d4v1 save: VMCE_VCPU
(XEN) HVM d4v2 save: VMCE_VCPU
(XEN) HVM d4v3 save: VMCE_VCPU
(XEN) HVM d4v0 save: TSC_ADJUST
(XEN) HVM d4v1 save: TSC_ADJUST
(XEN) HVM d4v2 save: TSC_ADJUST
(XEN) HVM d4v3 save: TSC_ADJUST
(XEN) HVM d4v0 save: CPU_MSR
(XEN) HVM d4v1 save: CPU_MSR
(XEN) HVM d4v2 save: CPU_MSR
(XEN) HVM d4v3 save: CPU_MSR
(XEN) HVM4 restore: CPU 0
(XEN) emul-priv-op.c::d0v3 Domain attempted WRMSR c0011020 from 
0x00064040 to 0x000640400400
(XEN) emul-priv-op.c::d0v3 Domain attempted WRMSR c0011020 from 
0x00064040 to 0x000640400400
(XEN) emul-priv-op.c::d0v2 Domain attempted WRMSR c0011020 from 
0x00064040 to 0x000640400400
(XEN) emul-priv-op.c::d0v3 Domain attempted WRMSR c0011020 from 
0x00064040 to 0x000640400400
(XEN) emul-priv-op.c::d0v3 Domain attempted WRMSR c0011020 from 
0x00064040 to 0x000640400400
(XEN) emul-priv-op.c::d0v3 Domain attempted WRMSR c0011020 from 
0x00064040 to 0x000640400400
(XEN) emul-priv-op.c::d0v3 Domain attempted WRMSR c0011020 from 
0x00064040 to 0x000640400400
(XEN) emul-priv-op.c::d0v3 Domain attempted WRMSR c0011020 from 
0x00064040 to 0x000640400400
(XEN) emul-priv-op.c::d0v2 Domain attempted WRMSR c0011020 from 
0x00064040 to 0x000640400400
(XEN) emul-priv-op.c::d0v3 Domain attempted WRMSR c0011020 from 
0x00064040 to 0x000640400400
(XEN) emul-priv-op.c::d0v3 Domain attempted WRMSR c0011020 from 
0x00064040 to 0x000640400400
(XEN) emul-priv-op.c::d0v2 Domain attempted WRMSR c0011020 from 
0x00064040 to 0x000640400400
(XEN) emul-priv-op.c::d0v3 Domain attempted WRMSR c0011020 from 
0x00064040 to 0x000640400400
(XEN) emul-priv-op.c::d0v3 Domain attempted WRMSR c0011020 from 
0x00064040 to 0x000640400400
(XEN) emul-priv-op.c::d0v0 Domain attempted WRMSR c0011020 from 
0x00064040 to 0x000640400400
(XEN) emul-priv-op.c::d0v3 Domain attempted WRMSR c0011020 from 
0x00064040 to 0x000640400400
(XEN) emul-priv-op.c::d0v3 Domain attempted WRMSR c0011020 from 
0x00064040 to 0x000640400400
(XEN) emul-priv-op.c::d0v3 Domain attempted WRMSR c0011020 from 
0x00064040 to 0x000640400400
(XEN) emul-priv-op.c::d0v3 Domain attempted WRMSR c0011020 from 
0x00064040 to 0x000640400400
(XEN) emul-priv-op.c::d0v1 Domain attempted WRMSR 

[Xen-devel] [PATCH v4 3/3] x86/boot: Introduce the setup_indirect

[Daniel Kiper]

The setup_data is a bit awkward to use for extremely large data objects,
both because the setup_data header has to be adjacent to the data object
and because it has a 32-bit length field. However, it is important that
intermediate stages of the boot process have a way to identify which
chunks of memory are occupied by kernel data. Thus we introduce an uniform
way to specify such indirect data as setup_indirect struct and
SETUP_INDIRECT type.

Suggested-by: H. Peter Anvin (Intel) 
Signed-off-by: Daniel Kiper 
Acked-by: Konrad Rzeszutek Wilk 
Reviewed-by: Ross Philipson 
Reviewed-by: H. Peter Anvin (Intel) 
---
v4 - suggestions/fixes:
   - change "Note:" to ".. note::".

v3 - suggestions/fixes:
   - add setup_indirect mapping/KASLR avoidance/etc. code
 (suggested by H. Peter Anvin),
   - the SETUP_INDIRECT sets most significant bit right now;
 this way it is possible to differentiate regular setup_data
 and setup_indirect objects in the debugfs filesystem.

v2 - suggestions/fixes:
   - add setup_indirect usage example
 (suggested by Eric Snowberg and Ross Philipson).
---
 Documentation/x86/boot.rst| 41 +++
 arch/x86/boot/compressed/kaslr.c  | 12 ++
 arch/x86/include/uapi/asm/bootparam.h | 16 +++---
 arch/x86/kernel/e820.c| 11 ++
 arch/x86/kernel/kdebugfs.c| 20 +
 arch/x86/kernel/ksysfs.c  | 30 +++--
 arch/x86/kernel/setup.c   |  4 
 arch/x86/mm/ioremap.c | 11 ++
 8 files changed, 131 insertions(+), 14 deletions(-)

diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
index 8e523c23ede3..38155ba8740f 100644
--- a/Documentation/x86/boot.rst
+++ b/Documentation/x86/boot.rst
@@ -827,6 +827,47 @@ Protocol:  2.09+
   sure to consider the case where the linked list already contains
   entries.
 
+  The setup_data is a bit awkward to use for extremely large data objects,
+  both because the setup_data header has to be adjacent to the data object
+  and because it has a 32-bit length field. However, it is important that
+  intermediate stages of the boot process have a way to identify which
+  chunks of memory are occupied by kernel data.
+
+  Thus setup_indirect struct and SETUP_INDIRECT type were introduced in
+  protocol 2.15.
+
+  struct setup_indirect {
+__u32 type;
+__u32 reserved;  /* Reserved, must be set to zero. */
+__u64 len;
+__u64 addr;
+  };
+
+  The type member is a SETUP_INDIRECT | SETUP_* type. However, it cannot be
+  SETUP_INDIRECT itself since making the setup_indirect a tree structure
+  could require a lot of stack space in something that needs to parse it
+  and stack space can be limited in boot contexts.
+
+  Let's give an example how to point to SETUP_E820_EXT data using 
setup_indirect.
+  In this case setup_data and setup_indirect will look like this:
+
+  struct setup_data {
+__u64 next = 0 or ;
+__u32 type = SETUP_INDIRECT;
+__u32 len = sizeof(setup_data);
+__u8 data[sizeof(setup_indirect)] = struct setup_indirect {
+  __u32 type = SETUP_INDIRECT | SETUP_E820_EXT;
+  __u32 reserved = 0;
+  __u64 len = ;
+  __u64 addr = ;
+}
+  }
+
+.. note::
+ SETUP_INDIRECT | SETUP_NONE objects cannot be properly distinguished
+ from SETUP_INDIRECT itself. So, this kind of objects cannot be provided
+ by the bootloaders.
+
    
 Field name:pref_address
 Type:  read (reloc)
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 2e53c056ba20..bb9bfef174ae 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -459,6 +459,18 @@ static bool mem_avoid_overlap(struct mem_vector *img,
is_overlapping = true;
}
 
+   if (ptr->type == SETUP_INDIRECT &&
+   ((struct setup_indirect *)ptr->data)->type != 
SETUP_INDIRECT) {
+   avoid.start = ((struct setup_indirect 
*)ptr->data)->addr;
+   avoid.size = ((struct setup_indirect *)ptr->data)->len;
+
+   if (mem_overlaps(img, ) && (avoid.start < 
earliest)) {
+   *overlap = avoid;
+   earliest = overlap->start;
+   is_overlapping = true;
+   }
+   }
+
ptr = (struct setup_data *)(unsigned long)ptr->next;
}
 
diff --git a/arch/x86/include/uapi/asm/bootparam.h 
b/arch/x86/include/uapi/asm/bootparam.h
index dbb41128e5a0..949066b5398a 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -2,7 +2,7 @@
 #ifndef _ASM_X86_BOOTPARAM_H
 #define _ASM_X86_BOOTPARAM_H
 
-/* setup_data types */
+/* setup_data/setup_indirect types */
 #define SETUP_NONE 0
 #define SETUP_E820_EXT 

[Xen-devel] [PATCH v4 2/3] x86/boot: Introduce the kernel_info.setup_type_max

[Daniel Kiper]

This field contains maximal allowed type for setup_data.

Now bump the setup_header version in arch/x86/boot/header.S.

Suggested-by: H. Peter Anvin (Intel) 
Signed-off-by: Daniel Kiper 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Ross Philipson 
Reviewed-by: H. Peter Anvin (Intel) 
---
 Documentation/x86/boot.rst | 9 -
 arch/x86/boot/compressed/kernel_info.S | 5 +
 arch/x86/boot/header.S | 2 +-
 arch/x86/include/uapi/asm/bootparam.h  | 3 +++
 4 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
index c60fafda9427..8e523c23ede3 100644
--- a/Documentation/x86/boot.rst
+++ b/Documentation/x86/boot.rst
@@ -73,7 +73,7 @@ Protocol 2.14:BURNT BY INCORRECT COMMIT 
ae7e1238e68f2a472a125673ab506d49158c188
(x86/boot: Add ACPI RSDP address to setup_header)
DO NOT USE!!! ASSUME SAME AS 2.13.
 
-Protocol 2.15: (Kernel 5.5) Added the kernel_info.
+Protocol 2.15: (Kernel 5.5) Added the kernel_info and 
kernel_info.setup_type_max.
 =  
 
 .. note::
@@ -981,6 +981,13 @@ Offset/size:   0x0008/4
   This field contains the size of the kernel_info including kernel_info.header
   and kernel_info.kernel_info_var_len_data.
 
+   ==
+Field name:setup_type_max
+Offset/size:   0x0008/4
+   ==
+
+  This field contains maximal allowed type for setup_data and setup_indirect 
structs.
+
 
 The Image Checksum
 ==
diff --git a/arch/x86/boot/compressed/kernel_info.S 
b/arch/x86/boot/compressed/kernel_info.S
index 8ea6f6e3feef..f818ee8fba38 100644
--- a/arch/x86/boot/compressed/kernel_info.S
+++ b/arch/x86/boot/compressed/kernel_info.S
@@ -1,5 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 
+#include 
+
.section ".rodata.kernel_info", "a"
 
.global kernel_info
@@ -12,6 +14,9 @@ kernel_info:
/* Size total. */
.long   kernel_info_end - kernel_info
 
+   /* Maximal allowed type for setup_data and setup_indirect structs. */
+   .long   SETUP_TYPE_MAX
+
 kernel_info_var_len_data:
/* Empty for time being... */
 kernel_info_end:
diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 22dcecaaa898..97d9b6d6c1af 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -300,7 +300,7 @@ _start:
# Part 2 of the header, from the old setup.S
 
.ascii  "HdrS"  # header signature
-   .word   0x020d  # header version number (>= 0x0105)
+   .word   0x020f  # header version number (>= 0x0105)
# or else old loadlin-1.5 will fail)
.globl realmode_swtch
 realmode_swtch:.word   0, 0# default_switch, SETUPSEG
diff --git a/arch/x86/include/uapi/asm/bootparam.h 
b/arch/x86/include/uapi/asm/bootparam.h
index a1ebcd7a991c..dbb41128e5a0 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -11,6 +11,9 @@
 #define SETUP_APPLE_PROPERTIES 5
 #define SETUP_JAILHOUSE6
 
+/* max(SETUP_*) */
+#define SETUP_TYPE_MAX SETUP_JAILHOUSE
+
 /* ram_size flags */
 #define RAMDISK_IMAGE_START_MASK   0x07FF
 #define RAMDISK_PROMPT_FLAG0x8000
-- 
2.11.0


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

[Xen-devel] [PATCH v4 1/3] x86/boot: Introduce the kernel_info

[Daniel Kiper]

The relationships between the headers are analogous to the various data
sections:

  setup_header = .data
  boot_params/setup_data = .bss

What is missing from the above list? That's right:

  kernel_info = .rodata

We have been (ab)using .data for things that could go into .rodata or .bss for
a long time, for lack of alternatives and -- especially early on -- inertia.
Also, the BIOS stub is responsible for creating boot_params, so it isn't
available to a BIOS-based loader (setup_data is, though).

setup_header is permanently limited to 144 bytes due to the reach of the
2-byte jump field, which doubles as a length field for the structure, combined
with the size of the "hole" in struct boot_params that a protected-mode loader
or the BIOS stub has to copy it into. It is currently 119 bytes long, which
leaves us with 25 very precious bytes. This isn't something that can be fixed
without revising the boot protocol entirely, breaking backwards compatibility.

boot_params proper is limited to 4096 bytes, but can be arbitrarily extended
by adding setup_data entries. It cannot be used to communicate properties of
the kernel image, because it is .bss and has no image-provided content.

kernel_info solves this by providing an extensible place for information about
the kernel image. It is readonly, because the kernel cannot rely on a
bootloader copying its contents anywhere, but that is OK; if it becomes
necessary it can still contain data items that an enabled bootloader would be
expected to copy into a setup_data chunk.

This patch does not bump setup_header version in arch/x86/boot/header.S
because it will be followed by additional changes coming into the
Linux/x86 boot protocol.

Suggested-by: H. Peter Anvin (Intel) 
Signed-off-by: Daniel Kiper 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Ross Philipson 
Reviewed-by: H. Peter Anvin (Intel) 
---
v4 - suggestions/fixes:
   - improve the documentation
 (suggested by Randy Dunlap and Konrad Rzeszutek Wilk).

v3 - suggestions/fixes:
   - split kernel_info data into fixed and variable sized regions,
 (suggested by H. Peter Anvin),
   - change kernel_info.header value to "LToP" (0x506f544c),
 (suggested by H. Peter Anvin),
   - improve the comments,
   - improve the documentation.

v2 - suggestions/fixes:
   - rename setup_header2 to kernel_info,
 (suggested by H. Peter Anvin),
   - change kernel_info.header value to "InfO" (0x4f666e49),
   - new kernel_info description in Documentation/x86/boot.rst,
 (suggested by H. Peter Anvin),
   - drop kernel_info_offset_update() as an overkill and
 update kernel_info offset directly from main(),
 (suggested by Eric Snowberg),
   - new commit message
 (suggested by H. Peter Anvin),
   - fix some commit message misspellings
 (suggested by Eric Snowberg).
---
 Documentation/x86/boot.rst | 126 +
 arch/x86/boot/Makefile |   2 +-
 arch/x86/boot/compressed/Makefile  |   4 +-
 arch/x86/boot/compressed/kernel_info.S |  17 +
 arch/x86/boot/header.S |   1 +
 arch/x86/boot/tools/build.c|   5 ++
 arch/x86/include/uapi/asm/bootparam.h  |   1 +
 7 files changed, 153 insertions(+), 3 deletions(-)
 create mode 100644 arch/x86/boot/compressed/kernel_info.S

diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
index 08a2f100c0e6..c60fafda9427 100644
--- a/Documentation/x86/boot.rst
+++ b/Documentation/x86/boot.rst
@@ -68,8 +68,25 @@ Protocol 2.12(Kernel 3.8) Added the xloadflags field 
and extension fields
 Protocol 2.13  (Kernel 3.14) Support 32- and 64-bit flags being set in
xloadflags to support booting a 64-bit kernel from 32-bit
EFI
+
+Protocol 2.14: BURNT BY INCORRECT COMMIT 
ae7e1238e68f2a472a125673ab506d49158c1889
+   (x86/boot: Add ACPI RSDP address to setup_header)
+   DO NOT USE!!! ASSUME SAME AS 2.13.
+
+Protocol 2.15: (Kernel 5.5) Added the kernel_info.
 =  
 
+.. note::
+ The protocol version number should be changed only if the setup header
+ is changed. There is no need to update the version number if boot_params
+ or kernel_info are changed. Additionally, it is recommended to use
+ xloadflags (in this case the protocol version number should not be
+ updated either) or kernel_info to communicate supported Linux kernel
+ features to the boot loader. Due to very limited space available in
+ the original setup header every update to it should be considered
+ with great care. Starting from the protocol 2.15 the primary way to
+ communicate things to the boot loader is the kernel_info.
+
 
 Memory Layout
 =
@@ -207,6 +224,7 @@ Offset/Size Proto   NameMeaning
 0258/8 2.10+   pref_addressPreferred loading 
address
 0260/4 2.10+   

[Xen-devel] [PATCH v4 0/3] x86/boot: Introduce the kernel_info et consortes

[Daniel Kiper]

Hi,

Due to very limited space in the setup_header this patch series introduces new
kernel_info struct which will be used to convey information from the kernel to
the bootloader. This way the boot protocol can be extended regardless of the
setup_header limitations. Additionally, the patch series introduces some
convenience features like the setup_indirect struct and the
kernel_info.setup_type_max field.

Daniel

 Documentation/x86/boot.rst | 174 
++
 arch/x86/boot/Makefile |   2 +-
 arch/x86/boot/compressed/Makefile  |   4 +-
 arch/x86/boot/compressed/kaslr.c   |  12 ++
 arch/x86/boot/compressed/kernel_info.S |  22 ++
 arch/x86/boot/header.S |   3 +-
 arch/x86/boot/tools/build.c|   5 +++
 arch/x86/include/uapi/asm/bootparam.h  |  16 +++-
 arch/x86/kernel/e820.c |  11 +
 arch/x86/kernel/kdebugfs.c |  20 +++--
 arch/x86/kernel/ksysfs.c   |  30 ++
 arch/x86/kernel/setup.c|   4 ++
 arch/x86/mm/ioremap.c  |  11 +
 13 files changed, 298 insertions(+), 16 deletions(-)

Daniel Kiper (3):
  x86/boot: Introduce the kernel_info
  x86/boot: Introduce the kernel_info.setup_type_max
  x86/boot: Introduce the setup_indirect


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

Re: [Xen-devel] [PATCH for-4.13] CONTRIBUTING: drop reference to blktap2

[Wei Liu]

On Thu, Oct 24, 2019 at 01:13:13PM +0200, Jürgen Groß wrote:
> On 24.10.19 13:06, Wei Liu wrote:
> > Blktap2 is gone.
> > 
> > Signed-off-by: Wei Liu 
> > ---
> >   CONTRIBUTING | 1 -
> >   1 file changed, 1 deletion(-)
> > 
> > diff --git a/CONTRIBUTING b/CONTRIBUTING
> > index 47f53e9a49..4fff4fd9f6 100644
> > --- a/CONTRIBUTING
> > +++ b/CONTRIBUTING
> > @@ -13,7 +13,6 @@ Most of the Xen Project code is licensed under GPLv2, but 
> > a number of
> >   directories are primarily licensed under different licenses.
> >   Most notably:
> > - - tools/blktap2  : BSD-Modified
> >- tools/libxc: LGPL v2.1
> >- tools/libxl: LGPL v2.1
> >- tools/xl   : LGPL v2.1
> > 
> 
> Mind adding tools/libs instead?

Sure. That can be done.

Because tools/libs' code is mostly split from libxc and friends, I
assume it is going to be LGPL v2.1 as well.

Lars and Ian, your opinion?

Wei.

> 
> With that:
> 
> Reviewed-by: Juergen Gross 
> Release-acked-by: Juergen Gross 
> 
> 
> Juergen
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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

Re: [Xen-devel] [PATCH for-4.13] CONTRIBUTING: drop reference to blktap2

[Jürgen Groß]

On 24.10.19 13:06, Wei Liu wrote:

Blktap2 is gone.

Signed-off-by: Wei Liu 
---
  CONTRIBUTING | 1 -
  1 file changed, 1 deletion(-)

diff --git a/CONTRIBUTING b/CONTRIBUTING
index 47f53e9a49..4fff4fd9f6 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -13,7 +13,6 @@ Most of the Xen Project code is licensed under GPLv2, but a 
number of
  directories are primarily licensed under different licenses.
  
  Most notably:

- - tools/blktap2  : BSD-Modified
   - tools/libxc: LGPL v2.1
   - tools/libxl: LGPL v2.1
   - tools/xl   : LGPL v2.1



Mind adding tools/libs instead?

With that:

Reviewed-by: Juergen Gross 
Release-acked-by: Juergen Gross 


Juergen

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

[Xen-devel] [PATCH for-4.13] CONTRIBUTING: drop reference to blktap2

[Wei Liu]

Blktap2 is gone.

Signed-off-by: Wei Liu 
---
 CONTRIBUTING | 1 -
 1 file changed, 1 deletion(-)

diff --git a/CONTRIBUTING b/CONTRIBUTING
index 47f53e9a49..4fff4fd9f6 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -13,7 +13,6 @@ Most of the Xen Project code is licensed under GPLv2, but a 
number of
 directories are primarily licensed under different licenses.
 
 Most notably:
- - tools/blktap2  : BSD-Modified
  - tools/libxc: LGPL v2.1
  - tools/libxl: LGPL v2.1
  - tools/xl   : LGPL v2.1
-- 
2.20.1


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   6 libvirt-buildfail REGR. vs. 143023
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 143023
 build-arm64-libvirt   6 libvirt-buildfail REGR. vs. 143023
 build-armhf-libvirt   6 libvirt-buildfail REGR. vs. 143023

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a

version targeted for testing:
 libvirt  b3739aa63f89fdb426226027f0b244cb15c1ea10
baseline version:
 libvirt  2cff65e4c60ed7b3c0c6a97d526d1f8d52c0e919

Last test of basis   143023  2019-10-22 04:19:26 Z2 days
Failing since143051  2019-10-23 04:18:57 Z1 days2 attempts
Testing same since   143085  2019-10-24 04:18:59 Z0 days1 attempts


People who touched revisions under test:
  Ján Tomko 
  Maya Rashish 
  Michal Privoznik 
  Pavel Hrdina 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-arm64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-libvirt-xsm blocked 
 test-arm64-arm64-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  blocked 
 test-amd64-amd64-libvirt blocked 
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-libvirt-pairblocked 
 test-amd64-i386-libvirt-pair blocked 
 test-arm64-arm64-libvirt-qcow2   blocked 
 test-armhf-armhf-libvirt-raw blocked 
 test-amd64-amd64-libvirt-vhd blocked 



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

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

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

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


Not pushing.

(No revision log; it would be 470 lines long.)

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org

Re: [Xen-devel] [PATCH for-4.13 v3] xen/arm: domain_build: Don't expose IOMMU specific properties to hwdom

[Oleksandr]

On 24.10.19 12:05, Jürgen Groß wrote:

On 24.10.19 10:57, Julien Grall wrote:

Hi Oleksandr,

On 10/16/19 11:08 AM, Oleksandr Tyshchenko wrote:

From: Oleksandr Tyshchenko 

We always skip the IOMMU device when creating DT for hwdom if there is
an appropriate driver for it in Xen (device_get_class(iommu_node)
returns DEVICE_IOMMU). So, even if it is not used by Xen it will be 
skipped.


We should also skip the IOMMU specific properties of the master device
behind that IOMMU in order to avoid exposing an half complete IOMMU
bindings to hwdom.

According to the Linux's docs:
1. Documentation/devicetree/bindings/iommu/iommu.txt
2. Documentation/devicetree/bindings/pci/pci-iommu.txt

Signed-off-by: Oleksandr Tyshchenko 


Acked-by: Julien Grall 

@Juergen: while the driver relying on those bindings is experimental 
for Xen 4.13, it would be good to avoid exposing half the bindings of 
IOMMU.


The bindings are generic but it is not used by the SMMU driver yet 
and therefore should not affect platform using SMMUs.


Thanks for the background info. With that:

Release-acked-by: Juergen Gross 


Juergen


Great,

I thank you all.


--
Regards,

Oleksandr Tyshchenko


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

Re: [Xen-devel] [xen-unstable test] 143061: regressions - trouble: broken/fail/pass

[Jürgen Groß]

On 24.10.19 12:48, Ian Jackson wrote:

Jürgen Groß writes ("Re: [Xen-devel] [xen-unstable test] 143061: regressions - 
trouble: broken/fail/pass"):

On 24.10.19 08:47, osstest service owner wrote:

   test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 
142750


I'm not sure what has gone wrong here? The serial logs seem to be fine
for me, but maybe I'm missing something?


There is a known bug with two of our arm64 boxes, where they lose some
of the output during boot.  This is not important for operational use
of those boxes in a normal context, but in our context being able to
get all the boot messages is important for debugging hypervisors and
kernels, so osstest has a test that this works properly.  It is that
test that fails.

If this is the only failure, we should force push.


Agreed. Can you do so, please?


Juergen

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

Re: [Xen-devel] [PATCH for-4.13 01/23] xen: Fix strange byte in common/Kconfig

[Jürgen Groß]

On 24.10.19 12:41, Andrew Cooper wrote:

On 23/10/2019 17:48, Anthony PERARD wrote:

Current description of the file by `file`:
 common/Kconfig: Non-ISO extended-ASCII text

Change that byte to an ascii quote so the file can become properly
encoded, and all ASCII.

Signed-off-by: Anthony PERARD


Acked-by: Andrew Cooper 

I see "about Xen~Rs execution" in menuconfig, and this is new content in 
4.13 so wants fixing.


Agreed.

Release-acked-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [xen-unstable test] 143061: regressions - trouble: broken/fail/pass

[Ian Jackson]

Jürgen Groß writes ("Re: [Xen-devel] [xen-unstable test] 143061: regressions - 
trouble: broken/fail/pass"):
> On 24.10.19 08:47, osstest service owner wrote:
> >   test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 
> > 142750
> 
> I'm not sure what has gone wrong here? The serial logs seem to be fine
> for me, but maybe I'm missing something?

There is a known bug with two of our arm64 boxes, where they lose some
of the output during boot.  This is not important for operational use
of those boxes in a normal context, but in our context being able to
get all the boot messages is important for debugging hypervisors and
kernels, so osstest has a test that this works properly.  It is that
test that fails.

If this is the only failure, we should force push.

Ian.

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

[Xen-devel] [OSSTEST PATCH] power_cycle_sleep: Change default sleep to 15s

[Ian Jackson]

5s is so short that when a host fails to respond we aren't sure if it
was just very idle and ran off its PSU's internal energy storage for
that period.

Signed-off-by: Ian Jackson 
---
 Osstest/TestSupport.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 6b0ee7a2..9c99ee17 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1097,7 +1097,7 @@ sub power_reboot_attempts ($$$;$$) {
 
 sub power_cycle_sleep ($) {
 my ($ho) = @_;
-my $to = get_host_property($ho, 'power-cycle-time', 5);
+my $to = get_host_property($ho, 'power-cycle-time', 15);
 logm("power-cycle: waiting ${to}s");
 sleep($to);
 }
-- 
2.11.0


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

[Xen-devel] italia1 Re: [xen-unstable test] 143061: regressions - trouble: broken/fail/pass

[Ian Jackson]

Roger Pau Monné writes ("Re: [Xen-devel] [xen-unstable test] 143061: 
regressions - trouble: broken/fail/pass"):
> 2019-10-23 23:16:59 Z power: failed to reboot (using SSH): status 65280 at 
> Osstest/TestSupport.pm line 550.
...
> power: all approaches to rebooting italia1 failed!
> 
> It seems like osstest failed to reboot the box, adding Ian for more
> input, but I guess the box can be unblessed until this is sorted out.

http://logs.test-lab.xenproject.org/osstest/results/host/italia1.html

The box seems basically fine at the moment, so I have left it blessed.

Looking at the logs, it appears that the previous flight left the box
crashed.  (This is not wholly unusual.)  osstest used the PDU to turn
italia1 off for 5s and then on again.  But it didn't seem to have any
effect.

There are two possible causes:

1. italia1's PDU relay got stuck.  This is not wholly implausible.
The earlier logs do show some phases of repeated failures of
host-install.

2. 5s is too short.

For now, I am going to change the default.

Ian.

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

Re: [Xen-devel] [PATCH for-4.13 01/23] xen: Fix strange byte in common/Kconfig

[Andrew Cooper]

On 23/10/2019 17:48, Anthony PERARD wrote:
> Current description of the file by `file`:
> common/Kconfig: Non-ISO extended-ASCII text
>
> Change that byte to an ascii quote so the file can become properly
> encoded, and all ASCII.
>
> Signed-off-by: Anthony PERARD 

Acked-by: Andrew Cooper 

I see "about Xen~Rs execution" in menuconfig, and this is new content in
4.13 so wants fixing.

> ---
>  xen/common/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 7b5dd9d49596..5c0f8d30c709 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -386,7 +386,7 @@ config TRACEBUFFER
>   default y
>   ---help---
> Enable tracing infrastructure and pre-defined tracepoints within Xen.
> -   This will allow live information about Xen�s execution and performance
> +   This will allow live information about Xen's execution and performance
> to be collected at run time for debugging or performance analysis.
> Memory and execution overhead when not active is minimal.
>  
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[Xen-devel] [linux-4.4 test] 143063: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl-credit1  broken  in 143025
 test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail in 143009 REGR. vs. 
139698

Tests which are failing intermittently (not blocking):
 test-arm64-arm64-xl-credit1  4 host-install(4) broken in 143025 pass in 143063
 test-amd64-amd64-xl-pvshim   12 guest-start  fail in 142901 pass in 143063
 test-amd64-i386-libvirt-pair 21 guest-start/debian fail in 142901 pass in 
143063
 test-armhf-armhf-libvirt-raw 10 debian-di-install fail in 142901 pass in 143063
 test-amd64-amd64-xl-xsm   7 xen-boot fail in 143025 pass in 143063
 test-armhf-armhf-xl-vhd 10 debian-di-install fail in 143025 pass in 143063
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail pass in 142901
 test-amd64-amd64-xl-pvshim   16 guest-localmigrate fail pass in 143009
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat  fail pass in 143025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-arm64-arm64-examine  8 reboot   fail   never pass
 test-arm64-arm64-xl-credit2   7 xen-boot fail   never pass
 test-arm64-arm64-libvirt-xsm  7 xen-boot fail   never pass
 test-arm64-arm64-xl-seattle   7 xen-boot fail   never pass
 test-arm64-arm64-xl-xsm   7 xen-boot fail   never pass
 test-arm64-arm64-xl-credit1   7 xen-boot fail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx  7 xen-boot fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-arm64-arm64-xl   7 xen-boot fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 95d2883647dd8bf91f65cde87e73cede1dcc6574
baseline version:
 ovmf 53b1dd1036df3839d46bb150f7a8b2037390093a

Last test of basis   143054  2019-10-23 06:17:13 Z1 days
Testing same since   143072  2019-10-23 17:09:39 Z0 days1 attempts


People who touched revisions under test:
  Bob Feng 
  Michael D Kinney 
  Sean Brogan 
  Vitaly Cheptsov >
  Vitaly Cheptsov via Groups.Io 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   53b1dd1036..95d2883647  95d2883647dd8bf91f65cde87e73cede1dcc6574 -> 
xen-tested-master

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

Re: [Xen-devel] [PATCH for-4.13 v3] xen/arm: domain_build: Don't expose IOMMU specific properties to hwdom

[Jürgen Groß]

On 24.10.19 10:57, Julien Grall wrote:

Hi Oleksandr,

On 10/16/19 11:08 AM, Oleksandr Tyshchenko wrote:

From: Oleksandr Tyshchenko 

We always skip the IOMMU device when creating DT for hwdom if there is
an appropriate driver for it in Xen (device_get_class(iommu_node)
returns DEVICE_IOMMU). So, even if it is not used by Xen it will be 
skipped.


We should also skip the IOMMU specific properties of the master device
behind that IOMMU in order to avoid exposing an half complete IOMMU
bindings to hwdom.

According to the Linux's docs:
1. Documentation/devicetree/bindings/iommu/iommu.txt
2. Documentation/devicetree/bindings/pci/pci-iommu.txt

Signed-off-by: Oleksandr Tyshchenko 


Acked-by: Julien Grall 

@Juergen: while the driver relying on those bindings is experimental for 
Xen 4.13, it would be good to avoid exposing half the bindings of IOMMU.


The bindings are generic but it is not used by the SMMU driver yet and 
therefore should not affect platform using SMMUs.


Thanks for the background info. With that:

Release-acked-by: Juergen Gross 


Juergen


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

Re: [Xen-devel] [PATCH for-4.13 v3] xen/arm: domain_build: Don't expose IOMMU specific properties to hwdom

[Julien Grall]

Hi Oleksandr,

On 10/16/19 11:08 AM, Oleksandr Tyshchenko wrote:

From: Oleksandr Tyshchenko 

We always skip the IOMMU device when creating DT for hwdom if there is
an appropriate driver for it in Xen (device_get_class(iommu_node)
returns DEVICE_IOMMU). So, even if it is not used by Xen it will be skipped.

We should also skip the IOMMU specific properties of the master device
behind that IOMMU in order to avoid exposing an half complete IOMMU
bindings to hwdom.

According to the Linux's docs:
1. Documentation/devicetree/bindings/iommu/iommu.txt
2. Documentation/devicetree/bindings/pci/pci-iommu.txt

Signed-off-by: Oleksandr Tyshchenko 


Acked-by: Julien Grall 

@Juergen: while the driver relying on those bindings is experimental for 
Xen 4.13, it would be good to avoid exposing half the bindings of IOMMU.


The bindings are generic but it is not used by the SMMU driver yet and 
therefore should not affect platform using SMMUs.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [xen-unstable test] 143061: regressions - trouble: broken/fail/pass

[Julien Grall]

(+Ian and Stefano)

Hi,

On 10/24/19 8:13 AM, Jürgen Groß wrote:

On 24.10.19 08:47, osstest service owner wrote:

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
  test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm    status>   broken
  test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 4 
host-install(4) broken REGR. vs. 142750


Why is Linux kernel 5.4.0-rc4 being used for testing xen-unstable here?
Or am I reading the logs wrong?

  test-arm64-arm64-examine    11 examine-serial/bootloader fail REGR. 
vs. 142750


I'm not sure what has gone wrong here? The serial logs seem to be fine
for me, but maybe I'm missing something?


This is a known issue on rochesters for the past 6 months (see [1]). In 
short, Osstest is checking the sanity of the platform by adding cookie 
in the bootloader output. However, this cookie is lost.


Stefano promised to investigate it back then. Last time I heard, he had 
access to the colo. Stefano where are we with this?


Cheers,

[1] https://lists.xen.org/archives/html/xen-devel/2019-05/msg00018.html




Juergen

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


--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 3/4] x2APIC: translate IO-APIC entries when enabling the IOMMU

[Jan Beulich]

On 15.10.2019 17:47, Roger Pau Monne wrote:
> When interrupt remapping is enabled as part of enabling x2APIC the
> IO-APIC entries also need to be translated to the new format and added
> to the interrupt remapping table.
> 
> This prevents IOMMU interrupt remapping faults when booting on
> hardware that has unmasked IO-APIC pins.
> 
> Reported-by: Andrew Cooper 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Jan Beulich 

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

Re: [Xen-devel] [PATCH v3 2/4] x2APIC: simplify resume

[Jan Beulich]

On 15.10.2019 17:47, Roger Pau Monne wrote:
> There's no need to save and restore the IO-APIC entries, the entries
> prior to suspension have already been saved by ioapic_suspend, and
> will be restored by ioapic_resume. Note that at the point where
> resume_x2apic gets called the IO-APIC has not yet resumed, and hence
> all entries should be masked.
> 
> Note this shouldn't introduce any functional change.
> 
> Suggested-by: Jan Beulich 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Jan Beulich 

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

Re: [Xen-devel] bug: unable to LZ4 decompress ub1910 installer kernel when launching domU

[Jan Beulich]

On 23.10.2019 22:33, Pry Mar wrote:
> Hello xen-devel,
> 
> https://paste.debian.net/plain/1109374
> 
> shows my traces from a healthy CentOS 8, xen-4.12.1 dom0 when trying
> to launch a pv install of the newly released ub1910. The source is a
> block-attached ISO and the kernel/ramdisk was copied off locally.

Would you please increase verbosity (xl -vvv create ...) such that we
can see what exactly the decompression code doesn't like about this
kernel image?

Jan

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

Re: [Xen-devel] [PATCH] golang/xenlight: Fix libxl_domain_shutdown and libxl_domain_reboot as well

[Jürgen Groß]

On 23.10.19 18:23, George Dunlap wrote:

Both are now potentially asynchronous; pass in 'nil' to retain
synchronous behavior.

Signed-off-by: George Dunlap 


Release-acked-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH RFC v1 01/12] mm/memory_hotplug: Don't allow to online/offline memory blocks with holes

[David Hildenbrand]

On 24.10.19 05:53, Anshuman Khandual wrote:


On 10/22/2019 10:42 PM, David Hildenbrand wrote:

Our onlining/offlining code is unnecessarily complicated. Only memory
blocks added during boot can have holes. Hotplugged memory never has
holes. That memory is already online.


Why hot plugged memory at runtime cannot have holes (e.g a semi bad DIMM).


Important: HWPoison != memory hole

A memory hole is memory that is not "IORESOURCE_SYSRAM". These pages are 
currently marked PG_reserved. Such holes are sometimes used for mapping 
something into kernel space. Some archs use the PG_reserved to detect 
the memory hole ("not ram") and ignore the memmap.


Poisoned pages are marked PG_hwpoison.


Currently, do we just abort adding that memory block if there are holes ?


There is no interface to do that.

E.g., have a look at add_memory() add_memory_resource(). You can only 
pass one memory resource (that is all IORESOURCE_SYSRAM | IORESOURCE_BUSY)


Hotplugging memory with holes is not supported (nor can I imagine a use 
case for that).




When we stop allowing to offline memory blocks with holes, we implicitly
stop to online memory blocks with holes.


Reducing hotplug support for memory blocks with holes just to simplify
the code. Is it worth ?


Me and Michal are not aware of a users, not even aware of a use case. 
Keeping code around that nobody really needs that limits cleanups, no 
thanks. Similar to us not supporting to offline memory blocks that span 
multiple nodes/zones.


E.g., have a look at the isolation code. It is full of code that jumps 
over memory holes (start_isolate_page_range() -> __first_valid_page()). 
That made sense for our complicated memory offlining code, but it is 
actually harmful when dealing with alloc_contig_range(). Allocation 
never wants to jump over memory holes. After this patch, we can just 
fail hard on any memory hole we detect, instead of ignoring it (or 
special-casing it).






This allows to simplify the code. For example, we no longer have to
worry about marking pages that fall into memory holes PG_reserved when
onlining memory. We can stop setting pages PG_reserved.


Could not there be any other way of tracking these holes if not the page
reserved bit. In the memory section itself and corresponding struct pages
just remained poisoned ? Just wondering, might be all wrong here.


Of course there could be ways (e.g., using PG_offline eventually), but 
it boils down to us having to deal with it in onlining/offlining code. 
And that is some handling nobody really seems to need.






Offlining memory blocks added during boot is usually not guranteed to work
either way. So stopping to do that (if anybody really used and tested


That guarantee does not exist right now because how boot memory could have
been used after boot not from a limitation of the memory hot remove itself.


Yep. However, Michal and I are not even aware of a setup that would made 
this work and guarantee that the existing code actually still is able to 
deal with holes. Are you?





this over the years) should not really hurt. For the use case of
offlining memory to unplug DIMMs, we should see no change. (holes on
DIMMs would be weird)


Holes on DIMM could be due to HW errors affecting only parts of it. By not


Again, HW errors != holes. We have PG_hwpoison for that.


allowing such DIMM's hot add and remove, we are definitely reducing the
scope of overall hotplug functionality. Is code simplification in itself
is worth this reduction in functionality ?


What you describe is not affected.

Thanks!

--

Thanks,

David / dhildenb


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

Re: [Xen-devel] [PATCH v2 0/6] Code of Conduct + Extra Guides and Best Practices

[Felipe Huici]

Hi Lars,

Sorry for the late response, the Unikraft team is certainly happy to support 
this code of conduct.

Thanks,

-- Felipe

On 27.09.19, 06:22, "Xen-devel on behalf of Lars Kurth" 
 
wrote:

From: Lars Kurth 

This series proposes a concrete version of the Xen Project
CoC based on v1.4 of the Contributor Covenant. See [1]

It contains *ALL* the portions I was still going to add.
I spent a bit of time on word-smithing, but I am not a native English 
speaker
So there is probably time for improvement

The series also reflects the discussion in [2] and some private
discussions on IRC to identify initial members of the Xen
Project’s CoC team.

For convenience of review and in line with other policy documents
I created a git repository at [3]. This series can be found at [5].

[1] https://www.contributor-covenant.org/version/1/4/code-of-conduct.md
[2] https://xen.markmail.org/thread/56ao2gyhpltqmrew 
[3] 
http://xenbits.xen.org/gitweb/?p=people/larsk/code-of-conduct.git;a=summary
[4] 
https://www.slideshare.net/xen_com_mgr/xpdds19-keynote-patch-review-for-nonmaintainers-george-dunlap-citrix-systems-uk-ltd
[5] 
http://xenbits.xen.org/gitweb/?p=people/larsk/code-of-conduct.git;a=shortlog;h=refs/heads/CoC-v2

Changes since v1
* Code of Conduct 
  Only whitespace changes

* Added Communication Guide
  Contains values and a process based on advice and mediation in case of 
issues
  This is the primary portal for 

* Added Code Review Guide
  Which is based on [4] with some additions for completeness
  It primarily sets expectations and anything communication related is 
removed

* Added guide on Communication Best Practice
  Takes the communication section from [4] and expands on it with more 
examples
  and cases. This is probably where we may need some discussion

* Added document on Resolving Disagreement
  A tiny bit of theory to set the scene
  It covers some common cases of disagreements and how we may approach them
  Again, this probably needs some discussion

Cc: minios-de...@lists.xenproject.org
Cc: xen-...@lists.xenproject.org
Cc: win-pv-de...@lists.xenproject.org
Cc: mirageos-de...@lists.xenproject.org
Cc: committ...@xenproject.org

Lars Kurth (6):
  Import v1.4 of Contributor Covenant CoC
  Xen Project Code of Conduct
  Add Communication Guide
  Add Code Review Guide
  Add guide on Communication Best Practice
  Added Resolving Disagreement

-- 
2.13.0


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

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

[Xen-devel] Ping: [PATCH] x86/stackframe/32: repair 32-bit Xen PV

[Jan Beulich]

On 07.10.2019 12:41, Jan Beulich wrote:
> Once again RPL checks have been introduced which don't account for a
> 32-bit kernel living in ring 1 when running in a PV Xen domain. The
> case in FIXUP_FRAME has been preventing boot; adjust BUG_IF_WRONG_CR3
> as well just in case.
> 
> Fixes: 3c88c692c287 ("x86/stackframe/32: Provide consistent pt_regs")
> Signed-off-by: Jan Beulich 

Ping?

I'd like to further note that there appears to a likely related
2nd problem - I'm seeing seemingly random attempts to enter VM86
mode when running PV under Xen. I suspect a never written eflags
value to get inspected. While the issue here kills the kernel
reliably during boot, that other issue sometimes allows the
system to at least come up in a partly functional way (depending
on which user processes get killed because of there not being
any VM86 mode available when running PV under [64-bit] Xen).

Jan

> --- a/arch/x86/entry/entry_32.S
> +++ b/arch/x86/entry/entry_32.S
> @@ -48,6 +48,17 @@
>  
>  #include "calling.h"
>  
> +#ifndef CONFIG_XEN_PV
> +# define USER_SEGMENT_RPL_MASK SEGMENT_RPL_MASK
> +#else
> +/*
> + * When running paravirtualized on Xen the kernel runs in ring 1, and hence
> + * simple mask based tests (i.e. ones not comparing against USER_RPL) have to
> + * ignore bit 0. See also the C-level get_kernel_rpl().
> + */
> +# define USER_SEGMENT_RPL_MASK (SEGMENT_RPL_MASK & ~1)
> +#endif
> +
>   .section .entry.text, "ax"
>  
>  /*
> @@ -172,7 +183,7 @@
>   ALTERNATIVE "jmp .Lend_\@", "", X86_FEATURE_PTI
>   .if \no_user_check == 0
>   /* coming from usermode? */
> - testl   $SEGMENT_RPL_MASK, PT_CS(%esp)
> + testl   $USER_SEGMENT_RPL_MASK, PT_CS(%esp)
>   jz  .Lend_\@
>   .endif
>   /* On user-cr3? */
> @@ -217,7 +228,7 @@
>   testl   $X86_EFLAGS_VM, 4*4(%esp)
>   jnz .Lfrom_usermode_no_fixup_\@
>  #endif
> - testl   $SEGMENT_RPL_MASK, 3*4(%esp)
> + testl   $USER_SEGMENT_RPL_MASK, 3*4(%esp)
>   jnz .Lfrom_usermode_no_fixup_\@
>  
>   orl $CS_FROM_KERNEL, 3*4(%esp)
> 


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

Re: [Xen-devel] [xen-unstable test] 143061: regressions - trouble: broken/fail/pass

[Roger Pau Monné]

On Thu, Oct 24, 2019 at 09:13:14AM +0200, Jürgen Groß wrote:
> On 24.10.19 08:47, osstest service owner wrote:
> > flight 143061 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/143061/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >   test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm   
> > broken
> >   test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 4 host-install(4) 
> > broken REGR. vs. 142750
> 
> Why is Linux kernel 5.4.0-rc4 being used for testing xen-unstable here?
> Or am I reading the logs wrong?

AFAICT what's on the serial log is the output from the previous job on
that box, according to the osstest log:

ssh: connect to host 172.16.144.41 port 22: No route to host
2019-10-23 23:16:59 Z command nonzero waitstatus 65280: timeout 60 ssh -o 
StrictHostKeyChecking=no -o BatchMode=yes -o ConnectTimeout=100 -o 
ServerAliveInterval=100 -o PasswordAuthentication=no -o 
ChallengeResponseAuthentication=no -o 
UserKnownHostsFile=tmp/t.known_hosts_143061.test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
 root@172.16.144.41  set -e
 type reboot
 exec >>/var/log/osstest-reboot.log
 date
 exec &1
 set -x
 (
set +e
sleep 5
reboot -f -n -d   # Linux sysvinit/systemd
reboot -nq# FreeBSD (rejects above due to -f)
 )&
 
2019-10-23 23:16:59 Z power: failed to reboot (using SSH): status 65280 at 
Osstest/TestSupport.pm line 550.
 
2019-10-23 23:16:59 Z power: trying to reboot italia1 (using PDU) 
2019-10-23 23:16:59 Z power: setting 0 (using PDU) for italia1 
was: pdu-msw pdu2: #12 "Outlet 12" = on
now: pdu-msw pdu2: #12 "Outlet 12" = on
2019-10-23 23:16:59 Z using persistent-net-generator: cp -dR 
overlay-persistent-net/. tmp/t.italia1.initrd.d/. 
2019-10-23 23:16:59 Z Forcing interface auto 
tmp/t.italia1.initrd.cpio:   65.7% -- replaced with 
tmp/t.italia1.initrd.cpio.gz
2019-10-23 23:16:59 Z using initrds: 
/home/tftp//osstest/debian-installer/amd64/2019-09-10-stretch/initrd.gz 
tmp/t.italia1.initrd.cpio.gz 
2019-10-23 23:16:59 Z wrote /home/tftp//italia1/pxelinux.cfg (stashed as 
italia1-netboot.cfg+1) 
2019-10-23 23:16:59 Z power-cycle: waiting 5s 
2019-10-23 23:17:04 Z power: setting 1 (using PDU) for italia1 
was: pdu-msw pdu2: #12 "Outlet 12" = off
now: pdu-msw pdu2: #12 "Outlet 12" = off
2019-10-23 23:17:04 Z fetch italia1_preseed: waiting 350s... 
2019-10-23 23:17:04 Z fetch italia1_preseed: (none) (waiting) ... 
...
2019-10-23 23:22:55 Z FAILURE: fetch italia1_preseed: wait timed out: (none). 
2019-10-23 23:22:55 Z power: failed to reboot (using PDU): failure: fetch 
italia1_preseed: wait timed out: (none).
 
power: all approaches to rebooting italia1 failed!

It seems like osstest failed to reboot the box, adding Ian for more
input, but I guess the box can be unblessed until this is sorted out.

Roger.

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

Re: [Xen-devel] [xen-unstable test] 143061: regressions - trouble: broken/fail/pass

[Jürgen Groß]

On 24.10.19 08:47, osstest service owner wrote:

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
  test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm   broken
  test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 4 host-install(4) 
broken REGR. vs. 142750


Why is Linux kernel 5.4.0-rc4 being used for testing xen-unstable here?
Or am I reading the logs wrong?


  test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 142750


I'm not sure what has gone wrong here? The serial logs seem to be fine
for me, but maybe I'm missing something?


Juergen

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

[Xen-devel] [xen-unstable test] 143061: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm   broken
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 4 host-install(4) broken 
REGR. vs. 142750
 test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 142750

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 142750
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 142750
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 142750
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 142750
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 142750
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 142750
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 142750
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 142750
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 142750
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 142750
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail