[ovmf test] 168766: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf 267a92fef3b705e6a3ecbeaa4d4b58f7bfac9734
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   21 days
Failing since168258  2022-03-01 01:55:31 Z   21 days  218 attempts
Testing same since   168738  2022-03-21 02:39:18 Z1 days   17 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  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 859 lines long.)

[linux-linus test] 168760: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10   fail REGR. vs. 168733

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168733
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 168733
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 168733
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 168733
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 168733
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168733
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 168733
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 168733
 test-arm64-arm64-xl-seattle  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass
 test-arm64-arm64-xl-vhd  14 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-vhd  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-checkfail   never pass

version targeted for testing:
 linuxeaa54b1458ca84092e513d554dd6d234245e6bef
baseline version:
 linuxf443e374ae131c168a065ea1748feac6b2e76613

Last test of basis   168733  2022-03-20 22:40:53 Z1 days
Testing same since   168760  2022-03-21 19:41:16 Z0 days1 attempts


People who touched revisions under test:
  Adrian Hunter 
  Ahmad Fatoum 
  Alexey Makhalov 
  Andre Przywara 
  Andreas Rammhold 
  Andrey Konovalov 
  Anshuman Khandual 
  Ard Biesheuvel 
  Arnaldo Carvalho de Melo 
  Bharat Bhushan 
  Borislav Petkov 
  Branislav Rankov 
  Brijesh 

[ovmf test] 168762: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf 267a92fef3b705e6a3ecbeaa4d4b58f7bfac9734
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   21 days
Failing since168258  2022-03-01 01:55:31 Z   21 days  217 attempts
Testing same since   168738  2022-03-21 02:39:18 Z1 days   16 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  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 859 lines long.)

[qemu-mainline test] 168756: regressions - FAIL

[osstest service owner]

 pass
 test-armhf-armhf-libvirt-raw blocked 
 test-amd64-i386-libvirt-raw  pass
 test-amd64-amd64-xl-rtds pass
 test-armhf-armhf-xl-rtds blocked 
 test-arm64-arm64-xl-seattle  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow fail
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  pass
 test-amd64-amd64-xl-shadow   pass
 test-amd64-i386-xl-shadowpass
 test-arm64-arm64-xl-thunderx pass
 test-amd64-amd64-libvirt-vhd pass
 test-arm64-arm64-xl-vhd  pass
 test-armhf-armhf-xl-vhd  blocked 
 test-amd64-i386-xl-vhd   pass



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

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

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

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


Not pushing.


commit ecf1bbe3227cc1c54d7374aa737e7e0e60ee0c29
Merge: 2058fdbe81 3515553bf6
Author: Peter Maydell 
Date:   Mon Mar 21 11:16:56 2022 +

Merge tag 'pull-ppc-20220321' of https://github.com/legoater/qemu into 
staging

ppc-7.0 queue :

* ISA v3.1 vector instruction fixes
* Compilation fix regarding 'struct pt_regs' definition

# gpg: Signature made Mon 21 Mar 2022 06:43:22 GMT
# gpg:using RSA key A0F66548F04895EBFE6B0B6051A343C7CFFBECA1
# gpg: Good signature from "Cédric Le Goater " [undefined]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:  There is no indication that the signature belongs to the 
owner.
# Primary key fingerprint: A0F6 6548 F048 95EB FE6B  0B60 51A3 43C7 CFFB 
ECA1

* tag 'pull-ppc-20220321' of https://github.com/legoater/qemu:
  target/ppc: Replicate Double->Single-Precision result
  target/ppc: Replicate double->int32 result for some vector insns
  ppc64: Avoid pt_regs struct definition

Signed-off-by: Peter Maydell 

commit 3515553bf625ad48aa90210379c4f387c2596093
Author: Lucas Coutinho 
Date:   Sun Mar 20 23:35:27 2022 +0100

target/ppc: Replicate Double->Single-Precision result

Power ISA v3.1 formalizes the previously undefined result in
words 1 and 3 to be a copy of the result in words 0 and 2.

This affects: xvcvsxdsp, xvcvuxdsp, xvcvdpsp.

And the previously undefined result in word 1 to be a copy of
the result in word 0.

This affects: xscvdpsp.

Signed-off-by: Lucas Coutinho 
Message-Id: <20220316200427.3410437-1-lucas.couti...@eldorado.org.br>
Signed-off-by: Cédric Le Goater 

commit 217979d33e78ee64978295962c33d8525973c760
Author: Richard Henderson 
Date:   Sun Mar 20 23:35:27 2022 +0100

target/ppc: Replicate double->int32 result for some vector insns

Power ISA v3.1 formalizes the previously undefined result in
words 1 and 3 to be a copy of the result in words 0 and 2.

This affects: xscvdpsxws, xscvdpuxws, xvcvdpsxws, xvcvdpuxws.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/852
Signed-off-by: Richard Henderson 
[ clg: checkpatch fixes ]
Message-Id: <20220315053934.377519-1-richard.hender...@linaro.org>
Signed-off-by: Cédric Le Goater 

commit 9d1401b79463e74adbfac69d836789d4e103fb61
Author: Khem Raj 
Date:   Sun Mar 20 23:35:27 2022 +0100

ppc64: Avoid pt_regs struct definition

Remove pt_regs indirection and instead reference gp_regs directly, this
makes it portable across musl/glibc

Use PT_* constants defined in asm/ptrace.h

Move the file to ppc64 subdir and leave ppc empty

Fixes
../qemu-6.2.0/linux-user/host/ppc64/../ppc/host-signal.h:16:32: error: 
incomplete definition of type 'struct pt_regs'
return uc->uc_mcontext.regs->nip;
   ^

Signed-off-by: Khem Raj 
Cc: Peter Maydell 
Cc: Philippe Mathieu-Daudé 
Cc: Richard Henderson 
Reviewed-by: Richard Henderson 
Message-Id: <20220315015740.847370-1-raj.k...@gmail.com>
Signed-off-by: Cédric Le Goater 

[ovmf test] 168759: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf 267a92fef3b705e6a3ecbeaa4d4b58f7bfac9734
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   21 days
Failing since168258  2022-03-01 01:55:31 Z   20 days  216 attempts
Testing same since   168738  2022-03-21 02:39:18 Z0 days   15 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  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 859 lines long.)

[xen-unstable test] 168755: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-dom0pvh-xl-amd 22 guest-start/debian.repeat fail pass in 
168761-retest

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168737
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 168737
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 168737
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 168737
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 168737
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 168737
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 168737
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 168737
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 168737
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 168737
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 168737
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168737
 test-arm64-arm64-xl-seattle  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  16 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-vhd  14 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-vhd  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 15 migrate-support-check 

Re: [PATCH v3 5/6] arm/dom0less: assign dom0less guests to cpupools

[Stefano Stabellini]

On Fri, 18 Mar 2022, Luca Fancellu wrote:
> Introduce domain-cpupool property of a xen,domain device tree node,
> that specifies the cpupool device tree handle of a xen,cpupool node
> that identifies a cpupool created at boot time where the guest will
> be assigned on creation.
> 
> Add member to the xen_domctl_createdomain public interface so the
> XEN_DOMCTL_INTERFACE_VERSION version is bumped.
> 
> Add public function to retrieve a pool id from the device tree
> cpupool node.
> 
> Update documentation about the property.
> 
> Signed-off-by: Luca Fancellu 
> ---
> Changes in v3:
> - Use explicitely sized integer for struct xen_domctl_createdomain
>   cpupool_id member. (Stefano)
> - Changed code due to previous commit code changes
> Changes in v2:
> - Moved cpupool_id from arch specific to common part (Juergen)
> - Implemented functions to retrieve the cpupool id from the
>   cpupool dtb node.
> ---
>  docs/misc/arm/device-tree/booting.txt |  5 +
>  xen/arch/arm/domain_build.c   | 14 +-
>  xen/common/boot_cpupools.c| 24 
>  xen/common/domain.c   |  2 +-
>  xen/include/public/domctl.h   |  4 +++-
>  xen/include/xen/sched.h   |  9 +
>  6 files changed, 55 insertions(+), 3 deletions(-)
> 
> diff --git a/docs/misc/arm/device-tree/booting.txt 
> b/docs/misc/arm/device-tree/booting.txt
> index a94125394e35..7b4a29a2c293 100644
> --- a/docs/misc/arm/device-tree/booting.txt
> +++ b/docs/misc/arm/device-tree/booting.txt
> @@ -188,6 +188,11 @@ with the following properties:
>  An empty property to request the memory of the domain to be
>  direct-map (guest physical address == physical address).
>  
> +- domain-cpupool
> +
> +Optional. Handle to a xen,cpupool device tree node that identifies the
> +cpupool where the guest will be started at boot.
> +
>  Under the "xen,domain" compatible node, one or more sub-nodes are present
>  for the DomU kernel and ramdisk.
>  
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 8be01678de05..9c67a483d4a4 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -3172,7 +3172,8 @@ static int __init construct_domU(struct domain *d,
>  void __init create_domUs(void)
>  {
>  struct dt_device_node *node;
> -const struct dt_device_node *chosen = dt_find_node_by_path("/chosen");
> +const struct dt_device_node *cpupool_node,
> +*chosen = dt_find_node_by_path("/chosen");
>  
>  BUG_ON(chosen == NULL);
>  dt_for_each_child_node(chosen, node)
> @@ -3241,6 +3242,17 @@ void __init create_domUs(void)
>   vpl011_virq - 32 + 1);
>  }
>  
> +/* Get the optional property domain-cpupool */
> +cpupool_node = dt_parse_phandle(node, "domain-cpupool", 0);
> +if ( cpupool_node )
> +{
> +int pool_id = btcpupools_get_domain_pool_id(cpupool_node);
> +if ( pool_id < 0 )
> +panic("Error getting cpupool id from domain-cpupool (%d)\n",
> +  pool_id);
> +d_cfg.cpupool_id = pool_id;
> +}
> +
>  /*
>   * The variable max_init_domid is initialized with zero, so here it's
>   * very important to use the pre-increment operator to call
> diff --git a/xen/common/boot_cpupools.c b/xen/common/boot_cpupools.c
> index f6f2fa8f2701..feba93a243fc 100644
> --- a/xen/common/boot_cpupools.c
> +++ b/xen/common/boot_cpupools.c
> @@ -23,6 +23,8 @@ static unsigned int __initdata next_pool_id;
>  
>  #define BTCPUPOOLS_DT_NODE_NO_REG (-1)
>  #define BTCPUPOOLS_DT_NODE_NO_LOG_CPU (-2)
> +#define BTCPUPOOLS_DT_WRONG_NODE  (-3)
> +#define BTCPUPOOLS_DT_CORRUPTED_NODE  (-4)
>  
>  static int __init get_logical_cpu_from_hw_id(unsigned int hwid)
>  {
> @@ -55,6 +57,28 @@ get_logical_cpu_from_cpu_node(const struct dt_device_node 
> *cpu_node)
>  return cpu_num;
>  }
>  
> +int __init btcpupools_get_domain_pool_id(const struct dt_device_node *node)
> +{
> +const struct dt_device_node *phandle_node;
> +int cpu_num;
> +
> +if ( !dt_device_is_compatible(node, "xen,cpupool") )
> +return BTCPUPOOLS_DT_WRONG_NODE;
> +/*
> + * Get first cpu listed in the cpupool, from its reg it's possible to
> + * retrieve the cpupool id.
> + */
> +phandle_node = dt_parse_phandle(node, "cpupool-cpus", 0);
> +if ( !phandle_node )
> +return BTCPUPOOLS_DT_CORRUPTED_NODE;
> +
> +cpu_num = get_logical_cpu_from_cpu_node(phandle_node);
> +if ( cpu_num < 0 )
> +return cpu_num;
> +
> +return pool_cpu_map[cpu_num];
> +}
> +
>  static int __init check_and_get_sched_id(const char* scheduler_name)
>  {
>  int sched_id = sched_get_id_by_name(scheduler_name);
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 351029f8b239..0827400f4f49 100644
> --- a/xen/common/domain.c

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Stefano Stabellini]

On Fri, 18 Mar 2022, Luca Fancellu wrote:
> Introduce a way to create different cpupools at boot time, this is
> particularly useful on ARM big.LITTLE system where there might be the
> need to have different cpupools for each type of core, but also
> systems using NUMA can have different cpu pools for each node.
> 
> The feature on arm relies on a specification of the cpupools from the
> device tree to build pools and assign cpus to them.
> 
> Documentation is created to explain the feature.
> 
> Signed-off-by: Luca Fancellu 
> ---
> Changes in v3:
> - Add newline to cpupools.txt and removed "default n" from Kconfig (Jan)
> - Fixed comment, moved defines, used global cpu_online_map, use
>   HAS_DEVICE_TREE instead of ARM and place arch specific code in header
>   (Juergen)
> - Fix brakets, x86 code only panic, get rid of scheduler dt node, don't
>   save pool pointer and look for it from the pool list (Stefano)
> - Changed data structures to allow modification to the code.
> Changes in v2:
> - Move feature to common code (Juergen)
> - Try to decouple dtb parse and cpupool creation to allow
>   more way to specify cpupools (for example command line)
> - Created standalone dt node for the scheduler so it can
>   be used in future work to set scheduler specific
>   parameters
> - Use only auto generated ids for cpupools
> ---
>  docs/misc/arm/device-tree/cpupools.txt | 135 +++
>  xen/arch/arm/include/asm/smp.h |   3 +
>  xen/common/Kconfig |   7 +
>  xen/common/Makefile|   1 +
>  xen/common/boot_cpupools.c | 178 +
>  xen/common/sched/cpupool.c |   9 +-
>  xen/include/xen/sched.h|  19 +++
>  7 files changed, 351 insertions(+), 1 deletion(-)
>  create mode 100644 docs/misc/arm/device-tree/cpupools.txt
>  create mode 100644 xen/common/boot_cpupools.c
> 
> diff --git a/docs/misc/arm/device-tree/cpupools.txt 
> b/docs/misc/arm/device-tree/cpupools.txt
> new file mode 100644
> index ..6d7463736b48
> --- /dev/null
> +++ b/docs/misc/arm/device-tree/cpupools.txt
> @@ -0,0 +1,135 @@
> +Boot time cpupools
> +==
> +
> +When BOOT_TIME_CPUPOOLS is enabled in the Xen configuration, it is possible 
> to
> +create cpupools during boot phase by specifying them in the device tree.
> +
> +Cpupools specification nodes shall be direct childs of /chosen node.
> +Each cpupool node contains the following properties:
> +
> +- compatible (mandatory)
> +
> +Must always include the compatiblity string: "xen,cpupool".
> +
> +- cpupool-cpus (mandatory)
> +
> +Must be a list of device tree phandle to nodes describing cpus (e.g. 
> having
> +device_type = "cpu"), it can't be empty.
> +
> +- cpupool-sched (optional)
> +
> +Must be a string having the name of a Xen scheduler, it has no effect 
> when
> +used in conjunction of a cpupool-id equal to zero, in that case the
> +default Xen scheduler is selected (sched=<...> boot argument).
> +Check the sched=<...> boot argument for allowed values.

I am happy with this version of the device tree bindings, thanks for
your efforts to update them. Only one comment left: please update the
description not to include "cpupool-id" given that there is no
cpupool-id property anymore :-)


> +Constraints
> +===
> +
> +If no cpupools are specified, all cpus will be assigned to one cpupool
> +implicitly created (Pool-0).
> +
> +If cpupools node are specified, but not every cpu brought up by Xen is 
> assigned,
> +all the not assigned cpu will be assigned to an additional cpupool.
> +
> +If a cpu is assigned to a cpupool, but it's not brought up correctly, Xen 
> will
> +stop.
> +
> +
> +Examples
> +
> +
> +A system having two types of core, the following device tree specification 
> will
> +instruct Xen to have two cpupools:
> +
> +- The cpupool with id 0 will have 4 cpus assigned.
> +- The cpupool with id 1 will have 2 cpus assigned.
> +
> +The following example can work only if hmp-unsafe=1 is passed to Xen boot
> +arguments, otherwise not all cores will be brought up by Xen and the cpupool
> +creation process will stop Xen.
> +
> +
> +a72_1: cpu@0 {
> +compatible = "arm,cortex-a72";
> +reg = <0x0 0x0>;
> +device_type = "cpu";
> +[...]
> +};
> +
> +a72_2: cpu@1 {
> +compatible = "arm,cortex-a72";
> +reg = <0x0 0x1>;
> +device_type = "cpu";
> +[...]
> +};
> +
> +a53_1: cpu@100 {
> +compatible = "arm,cortex-a53";
> +reg = <0x0 0x100>;
> +device_type = "cpu";
> +[...]
> +};
> +
> +a53_2: cpu@101 {
> +compatible = "arm,cortex-a53";
> +reg = <0x0 0x101>;
> +device_type = "cpu";
> +[...]
> +};
> +
> +a53_3: cpu@102 {
> +compatible = "arm,cortex-a53";
> +reg = <0x0 0x102>;
> +device_type = "cpu";
> +[...]
> +};
> +
> +a53_4: cpu@103 {
> +compatible = 

"BUG: using smp_processor_id() in preemptible" on resume from S3

[Marek Marczykowski-Górecki]

Hi,

After updating from 5.14.15 dom0 kernel to 5.16.13 I started getting
this on resume from S3:

[   88.082751] ACPI: PM: Low-level resume complete
[   88.087933] ACPI: EC: EC started
[   88.091464] ACPI: PM: Restoring platform NVS memory
[   88.097166] xen_acpi_processor: Uploading Xen processor PM info
[   88.103850] Enabling non-boot CPUs ...
[   88.108128] installing Xen timer for CPU 1
[   88.112763] BUG: using smp_processor_id() in preemptible [] code: 
systemd-sleep/7138
[   88.122256] caller is is_xen_pmu+0x12/0x30
[   88.126937] CPU: 0 PID: 7138 Comm: systemd-sleep Tainted: GW 
5.16.13-2.fc32.qubes.x86_64 #1
[   88.137939] Hardware name: Star Labs StarBook/StarBook, BIOS 7.97 03/21/2022
[   88.145930] Call Trace:
[   88.148757]  
[   88.151193]  dump_stack_lvl+0x48/0x5e
[   88.155381]  check_preemption_disabled+0xde/0xe0
[   88.160641]  is_xen_pmu+0x12/0x30
[   88.164441]  xen_smp_intr_init_pv+0x75/0x100
[   88.169311]  ? xen_read_cr0+0x20/0x20
[   88.173502]  xen_cpu_up_prepare_pv+0x3e/0x90
[   88.178374]  cpuhp_invoke_callback+0x2b8/0x460
[   88.183440]  ? _raw_spin_unlock_irqrestore+0x25/0x40
[   88.189093]  cpuhp_up_callbacks+0x4b/0x170
[   88.193769]  _cpu_up+0xba/0x140
[   88.197374]  thaw_secondary_cpus.cold+0x50/0xaa
[   88.202538]  suspend_enter+0x11e/0x3b0
[   88.206825]  suspend_devices_and_enter+0x165/0x270
[   88.212281]  enter_state+0x125/0x176
[   88.216372]  pm_suspend.cold+0x20/0x6b
[   88.220658]  state_store+0x27/0x50
[   88.224557]  kernfs_fop_write_iter+0x121/0x1b0
[   88.229621]  new_sync_write+0x159/0x1f0
[   88.234006]  vfs_write+0x20d/0x2a0
[   88.237904]  ksys_write+0x67/0xe0
[   88.241703]  do_syscall_64+0x38/0x90
[   88.245797]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[   88.251544] RIP: 0033:0x7eae453da2f7
[   88.255637] Code: 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 
f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 
f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
[   88.276779] RSP: 002b:7ffcbc7d05e8 EFLAGS: 0246 ORIG_RAX: 
0001
[   88.285353] RAX: ffda RBX: 0004 RCX: 7eae453da2f7
[   88.293438] RDX: 0004 RSI: 7ffcbc7d06d0 RDI: 0004
[   88.301525] RBP: 7ffcbc7d06d0 R08: 5be912db7c00 R09: 000d
[   88.309613] R10: 5be912db3e10 R11: 0246 R12: 0004
[   88.317699] R13: 5be912db32d0 R14: 0004 R15: 7eae454ac700
[   88.325787]  
[   88.328711] cpu 1 spinlock event irq 131
[   88.333188] ACPI: \_SB_.CP01: Found 3 idle states
[   88.338833] CPU1 is up

and so on for all CPUs. 

In recent changes I see e25a8d959992 "x86/Xen: streamline (and fix) PV
CPU enumeration", which was backported to 5.16.11, although that's just
a hunch.

Any ideas? If necessary, I can run bisect to find specific commit, but I
hope the above message gives enough hints.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab


signature.asc
Description: PGP signature

Re: [PATCH v3 2/2] gitlab-ci: add an ARM32 qemu-based smoke test

[Stefano Stabellini]

On Mon, 21 Mar 2022, Julien Grall wrote:
> On 21/03/2022 19:47, Stefano Stabellini wrote:
> > On Sun, 20 Mar 2022, Julien Grall wrote:
> > > On 20/03/2022 01:46, Stefano Stabellini wrote:
> > > > On Fri, 18 Mar 2022, Stefano Stabellini wrote:
> > > > > Add a minimal ARM32 smoke test based on qemu-system-arm, as provided
> > > > > by
> > > > > the test-artifacts qemu container. The minimal test simply boots Xen
> > > > > (built from previous build stages) and Dom0. The test is fetching the
> > > > > Dom0 kernel and initrd from Debian Jessie: they work just fine and
> > > > > this
> > > > > way we don't have to maintain a build for them too.
> > > > 
> > > > 
> > > > Thanks to the Xen fix recently submitted
> > > > (https://marc.info/?l=xen-devel=164774063802402) I'll be able to
> > > > update this script to use Debian Bullseye. I am thinking of merging the
> > > > below directly with this patch.
> > > > 
> > > > 
> > > > ---
> > > > 
> > > > automation: upgrade Debian to Bullseye for testing Xen aarch32
> > > > 
> > > > Also change initrd. As the new netboot initrd from Debian Bullseye is
> > > > huge (22MB), use a tiny initrd from Alpine Linux instead (only 2.5MB).
> > > 
> > > This is sounds odd to me. So we are going to use Bullseye but not really
> > > because we want to use a different initrd.
> > > 
> > > Why can't you get everything from the same place?
> > 
> > Because it doesn't work :-(
> > 
> > 
> > > > Also note that the huge Debian Bullseye initrd would cause QEMU to
> > > > crash due to the -device loader parameter.
> > > 
> > > Can you provide more details? Was this reported to QEMU?
> > 
> > QEMU core dumps when provided with the Debian Bullseye initrd binary to
> > load. I guessed it was due to the size and tried with a smaller size.
> > Everything worked with a smaller initrd. I also think that it is not a
> > good idea to use a 22MB initrd anyway so decided against the Debian
> > Bullseye initrd. 
> 
> Why is it a bad idea? In general, bigger file allows us to test corner cases.

That is also true.

This test is minimal, there is only dom0 booting, no domUs. To me, it
makes sense that also the initrd is small. In general 20-25MB is the
regular full size of a Linux arm64 rootfs. I think it makes sense to
stay below 10-15MB for arm32 if we can.

We could go up in size if we added the Xen tools and a domU to the
initrd and tested xl create. There is a test like that for arm64.

We can add more tests like that.


> > (For reference 22MB is basically the size of a fully
> > featured Yocto-build rootfs.) I did not file a bug to qemu-devel yet and
> > didn't investigate further on the QEMU side as I ran out of time.
> > 
> > Alpine Linux provides a very nice 2.5MB initrd. I tried to use both
> > kernel and initrd from Alpine Linux but unfortunately the Alpine Linux
> > kernel doesn't boot. I don't know why but I think it is because it might
> > be missing the console driver. I am not sure. There are a lot of
> > combinations that don't work and it is time consuming to investigate
> > them all. I have been trying to investigate only the most critical
> > things -- they are too many!
> > 
> > I should add that the Debian initrd is not the ideal initrd because it
> > is made to start the Debian installer. Here we just want a tiny busybox
> > initrd.
> > 
> > In general, I think it would be better if we could use the kernel and
> > initrd from the same source but I couldn't find one that works. I could
> > build one myself but it would be one more thing to maintain in
> > gitlab-ci. Also using u-boot might solve the problem of loading the
> > binary but again we would have to maintain a u-boot arm32 build in
> > gitlab-ci.
> > 
> > So in order of preference best to worst in my opinion:
> > 
> > 1) kernel and initrd from the same source
> > 2) kernel and initrd from different sources
> > 3) build your own kernel/initrd/u-boot
> > 
> > So I ended up doing 2). I tested it and it is sufficient to get the test
> > up and running.
> 
> Thanks for the explanation. So I think we should not call that an "Upgrade to
> Bullseye" because you are not using Debian. Instead, you borrowed a working
> kernel that happens to have everything you need built-in.
> 
> Also, can you update the commit message and provide a summary of this
> discussion?

Yes I can do that, thanks for the review!

Re: [PATCH] xen/arm: skip first 32 bytes of zimage32

[Stefano Stabellini]

On Mon, 21 Mar 2022, Julien Grall wrote:
> > This is the list of kernels that I tried and failed:
> > 
> > - Debian Buster
> > - Debian Bullseye
> > - vanilla 4.9
> > - vanilla 4.10
> 
> Does this mean you where using v4.{9,10}.0 rather than the stable branch?
> 
> Note that AFAICT, 4.10 is not even supported by the kernel communinty (see
> [1]).

Yeah... I was trying to bisect the Debian kernel failure. That is how I
discovered that CONFIG_EFI was causing it. So yes, I only tried the
vanilla, now unsupported, releases.


> > The latest Alpine Linux kernel also doesn't boot, but that one doesn't
> > boot even with the fix for other reason. (More in the other email.)
> > 
> > 
> >  From a Xen gitlab-ci perspective, we just need a kernel that works.
> > Ideally, we wouldn't rebuild our own but reuse an existing kernel
> > because that is one less things to maintain in the gitlab-ci build.
> > 
> > We have a couple of options to make progress on the QEMU32 gitlab-ci
> > test:
> > 
> > 1) use Debian Jessie in gitlab-ci and do not commit the Xen-side fix,
> > file a Debian bug and revisit the situation in a couple of months
> > (Debian might get the fix in the meantime)
> 
> Why do we need to use Debian here? Couldn't we use Ubuntu (or any distros that
> have a newer kernel)?

We could use something else but see below.


> > 2) commit the Xen fix and use Debian Bullseye right now
> > 
> > 3) do not commit the Xen fix and build our own kernel now
> > 
> > 
> > All of these options work. My preference is 1) or 2).
> > 
> > Between 1) and 2) I have a slight preference for 2) for this reason: I
> > know that in Open Source we try to fix bugs wherever they are (kernel
> > project, QEMU project, Debian project) rather than working around them,
> > but in this case it looks like there is a significant amount of binaries
> > out there that require an update before they can boot on Xen. 
> 
> My problem here is the bug is not Xen specific. You would exactly have the
> same problem if you were booting on baremetal. But as Andre wrote in his
> commit message, this is only working by luck.
> 
> So we are setting another bad precendence by preserving the luck.
> 
> I appreciate we recently agreed to merge the code to emulate ldr/str. But this
> was based on the fact the Arm Arm doesn't clearly forbid such access. This is
> quite different here as the instructions are UNDEFINED.

Yeah, I understand your point and I also kind of agree.


> So I am not willing to accept a lot of code in Xen just to workaround a
> software bug (see more below).
> 
> > I think it
> > is one of those times where it is worth considering the Xen fix, or
> > should I say workaround, if it is considered harmless.
> 
> The problem with your workaround is now the zImage will be loaded in a
> different aligned. For instance, if the symbol  was 2MB aligned, now, it
> will be aligned to 2MB - 32. See kernel_zimage_load().
> 
> The booting protocol (see Documentation/arm/booting.rst). Doesn't look to
> impose an alignment. But I wouldn't be surprised if there is an assumption
> here.
> 
> Furthermore, there are some problem if the kernel is expected to be loaded a
> specific address.
> 
> I do expect the code to become more convoluted. This would also have to be
> duplicated in the tools side. Overall, this will likely be more than I am
> willing to accept for this issue.
> 
> Therefore I would like to suggest a more simple workaround. Per the commit
> message of the Linux bug fix, U-boot and direct loading are not affected
> because the bit "Z" is set.
> 
> So how about updating PSR_GUEST32_INIT to set Z?

That worked! Excellent suggestion and much safer than the 32 byte
workaround. I tested with the Debian Bullseye kernel.

I think you might have a better suggestion for the commit message.

---
xen/arm: set CPSR Z bit when creating aarch32 guests

The first 32 bytes of zImage32 are NOPs. When CONFIG_EFI is enabled in
the kernel, certain versions of Linux have a bug in the way the initial
NOP instructions gets encoded (invalid encoding), resulting in an
unbootable kernel. See commit a92882a4d270 in the Linux kernel for all
the details.

All kernel releases starting from Linux 4.9 without commit a92882a4d270
are affected.

Fortunately there is a simple workaround: setting the "Z" bit in CPSR
make it so those invalid  NOP instructions are never executed. Setting
the "Z" bit makes those kernel versions bootable again and it is
harmless in the other cases.

Signed-off-by: Stefano Stabellini 

diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 94b31511dd..309684e946 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -361,6 +361,7 @@ typedef uint64_t xen_callback_t;
 #define PSR_DBG_MASK(1<<9)/* arm64: Debug Exception mask */
 #define PSR_IT_MASK (0x0600fc00)  /* Thumb If-Then Mask */
 #define PSR_JAZELLE (1<<24)   /* Jazelle Mode */
+#define PSR_Z   (1<<30)

[PATCH v4] x86/vmx: save guest non-register state in hvm_hw_cpu

[Tamas K Lengyel]

During VM forking and resetting a failed vmentry has been observed due
to the guest non-register state going out-of-sync with the guest register
state. For example, a VM fork reset right after a STI instruction can trigger
the failed entry. This is due to the guest non-register state not being saved
from the parent VM, thus the reset operation only copies the register state.

Fix this by including the guest non-register state in hvm_hw_cpu so that when
its copied from the parent VM the vCPU state remains in sync.

SVM is not currently wired-in as VM forking is VMX only and saving non-register
state during normal save/restore/migration operation hasn't been needed. If
deemed necessary in the future it can be wired in by adding a svm-substructure
to hvm_hw_cpu.

Signed-off-by: Tamas K Lengyel 
Reviewed-by: Jan Beulich 
---
v4: Correct setting and checking new flag value in hvm.c
v3: Add XEN_X86_VMX flag and vmx-substructure in hvm_hw_cpu
v2: Include all CPU non-register state and fold the ops into vmx_vmcs_save &
vmx_vmcs_restore.
Note: no sanity checking is performed on the fields to reduce the cycles during
  fuzzing.
---
 xen/arch/x86/hvm/hvm.c |  4 ++--
 xen/arch/x86/hvm/vmx/vmx.c | 17 -
 xen/include/public/arch-x86/hvm/save.h | 13 +
 3 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 709a4191ef..c502d0851e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -894,7 +894,7 @@ static int cf_check hvm_save_cpu_ctxt(struct vcpu *v, 
hvm_domain_context_t *h)
 if ( v->fpu_initialised )
 {
 memcpy(ctxt.fpu_regs, v->arch.fpu_ctxt, sizeof(ctxt.fpu_regs));
-ctxt.flags = XEN_X86_FPU_INITIALISED;
+ctxt.flags |= XEN_X86_FPU_INITIALISED;
 }
 
 return hvm_save_entry(CPU, v->vcpu_id, h, );
@@ -1025,7 +1025,7 @@ static int cf_check hvm_load_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 return -EINVAL;
 }
 
-if ( (ctxt.flags & ~XEN_X86_FPU_INITIALISED) != 0 )
+if ( (ctxt.flags & ~(XEN_X86_FPU_INITIALISED | XEN_X86_VMX)) != 0 )
 {
 gprintk(XENLOG_ERR, "bad flags value in CPU context: %#x\n",
 ctxt.flags);
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index c075370f64..6da3842d6e 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -713,7 +713,7 @@ static void vmx_restore_dr(struct vcpu *v)
 
 static void vmx_vmcs_save(struct vcpu *v, struct hvm_hw_cpu *c)
 {
-unsigned long ev;
+unsigned long ev, activity_state, intr_info;
 
 vmx_vmcs_enter(v);
 
@@ -721,6 +721,10 @@ static void vmx_vmcs_save(struct vcpu *v, struct 
hvm_hw_cpu *c)
 __vmread(GUEST_SYSENTER_ESP, >sysenter_esp);
 __vmread(GUEST_SYSENTER_EIP, >sysenter_eip);
 
+__vmread(GUEST_ACTIVITY_STATE, _state);
+__vmread(GUEST_INTERRUPTIBILITY_INFO, _info);
+__vmread(GUEST_PENDING_DBG_EXCEPTIONS, >vmx.pending_dbg);
+
 __vmread(VM_ENTRY_INTR_INFO, );
 if ( (ev & INTR_INFO_VALID_MASK) &&
  hvm_event_needs_reinjection(MASK_EXTR(ev, INTR_INFO_INTR_TYPE_MASK),
@@ -732,6 +736,10 @@ static void vmx_vmcs_save(struct vcpu *v, struct 
hvm_hw_cpu *c)
 }
 
 vmx_vmcs_exit(v);
+
+c->vmx.activity_state = activity_state;
+c->vmx.interruptibility_info = intr_info;
+c->flags |= XEN_X86_VMX;
 }
 
 static int vmx_restore_cr0_cr3(
@@ -807,6 +815,13 @@ static int vmx_vmcs_restore(struct vcpu *v, struct 
hvm_hw_cpu *c)
 
 __vmwrite(GUEST_DR7, c->dr7);
 
+if ( c->flags & XEN_X86_VMX )
+{
+__vmwrite(GUEST_ACTIVITY_STATE, c->vmx.activity_state);
+__vmwrite(GUEST_INTERRUPTIBILITY_INFO, c->vmx.interruptibility_info);
+__vmwrite(GUEST_PENDING_DBG_EXCEPTIONS, c->vmx.pending_dbg);
+}
+
 if ( c->pending_valid &&
  hvm_event_needs_reinjection(c->pending_type, c->pending_vector) )
 {
diff --git a/xen/include/public/arch-x86/hvm/save.h 
b/xen/include/public/arch-x86/hvm/save.h
index 773a380bc2..0f728aa5d9 100644
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -52,6 +52,7 @@ DECLARE_HVM_SAVE_TYPE(HEADER, 1, struct hvm_save_header);
  * Compat:
  * - Pre-3.4 didn't have msr_tsc_aux
  * - Pre-4.7 didn't have fpu_initialised
+ * - Pre-4.17 didn't have non-register state
  */
 
 struct hvm_hw_cpu {
@@ -163,9 +164,21 @@ struct hvm_hw_cpu {
 uint32_t error_code;
 
 #define _XEN_X86_FPU_INITIALISED0
+#define _XEN_X86_VMX1
 #define XEN_X86_FPU_INITIALISED (1U<<_XEN_X86_FPU_INITIALISED)
+#define XEN_X86_VMX (1U<<_XEN_X86_VMX)
 uint32_t flags;
 uint32_t pad0;
+
+/* non-register state */
+union {
+/* if flags & XEN_X86_VMX */
+struct {
+uint32_t activity_state;
+uint32_t interruptibility_info;
+uint64_t pending_dbg;
+} 

Re: [PATCH v3] x86/vmx: save guest non-register state in hvm_hw_cpu

[Tamas K Lengyel]

On Mon, Mar 21, 2022, 12:41 PM Jan Beulich  wrote:

> On 21.03.2022 17:26, Tamas K Lengyel wrote:
> > During VM forking and resetting a failed vmentry has been observed due
> > to the guest non-register state going out-of-sync with the guest register
> > state. For example, a VM fork reset right after a STI instruction can
> trigger
> > the failed entry. This is due to the guest non-register state not being
> saved
> > from the parent VM, thus the reset operation only copies the register
> state.
> >
> > Fix this by including the guest non-register state in hvm_hw_cpu so that
> when
> > its copied from the parent VM the vCPU state remains in sync.
> >
> > SVM is not currently wired-in as VM forking is VMX only and saving
> non-register
> > state during normal save/restore/migration operation hasn't been needed.
> If
> > deemed necessary in the future it can be wired in by adding a
> svm-substructure
> > to hvm_hw_cpu.
> >
> > Signed-off-by: Tamas K Lengyel 
>
> Reviewed-by: Jan Beulich 
>

Thanks, will send v4 shortly, will need a couple fixes still.

Tamas

>

Re: [PATCH v3 2/2] gitlab-ci: add an ARM32 qemu-based smoke test

[Julien Grall]

Hi Stefano,

On 21/03/2022 19:47, Stefano Stabellini wrote:

On Sun, 20 Mar 2022, Julien Grall wrote:

On 20/03/2022 01:46, Stefano Stabellini wrote:

On Fri, 18 Mar 2022, Stefano Stabellini wrote:

Add a minimal ARM32 smoke test based on qemu-system-arm, as provided by
the test-artifacts qemu container. The minimal test simply boots Xen
(built from previous build stages) and Dom0. The test is fetching the
Dom0 kernel and initrd from Debian Jessie: they work just fine and this
way we don't have to maintain a build for them too.



Thanks to the Xen fix recently submitted
(https://marc.info/?l=xen-devel=164774063802402) I'll be able to
update this script to use Debian Bullseye. I am thinking of merging the
below directly with this patch.


---

automation: upgrade Debian to Bullseye for testing Xen aarch32

Also change initrd. As the new netboot initrd from Debian Bullseye is
huge (22MB), use a tiny initrd from Alpine Linux instead (only 2.5MB).


This is sounds odd to me. So we are going to use Bullseye but not really
because we want to use a different initrd.

Why can't you get everything from the same place?


Because it doesn't work :-(



Also note that the huge Debian Bullseye initrd would cause QEMU to
crash due to the -device loader parameter.


Can you provide more details? Was this reported to QEMU?


QEMU core dumps when provided with the Debian Bullseye initrd binary to
load. I guessed it was due to the size and tried with a smaller size.
Everything worked with a smaller initrd. I also think that it is not a
good idea to use a 22MB initrd anyway so decided against the Debian
Bullseye initrd. 


Why is it a bad idea? In general, bigger file allows us to test corner 
cases.



(For reference 22MB is basically the size of a fully
featured Yocto-build rootfs.) I did not file a bug to qemu-devel yet and
didn't investigate further on the QEMU side as I ran out of time.

Alpine Linux provides a very nice 2.5MB initrd. I tried to use both
kernel and initrd from Alpine Linux but unfortunately the Alpine Linux
kernel doesn't boot. I don't know why but I think it is because it might
be missing the console driver. I am not sure. There are a lot of
combinations that don't work and it is time consuming to investigate
them all. I have been trying to investigate only the most critical
things -- they are too many!

I should add that the Debian initrd is not the ideal initrd because it
is made to start the Debian installer. Here we just want a tiny busybox
initrd.

In general, I think it would be better if we could use the kernel and
initrd from the same source but I couldn't find one that works. I could
build one myself but it would be one more thing to maintain in
gitlab-ci. Also using u-boot might solve the problem of loading the
binary but again we would have to maintain a u-boot arm32 build in
gitlab-ci.

So in order of preference best to worst in my opinion:

1) kernel and initrd from the same source
2) kernel and initrd from different sources
3) build your own kernel/initrd/u-boot

So I ended up doing 2). I tested it and it is sufficient to get the test
up and running.


Thanks for the explanation. So I think we should not call that an 
"Upgrade to Bullseye" because you are not using Debian. Instead, you 
borrowed a working kernel that happens to have everything you need built-in.


Also, can you update the commit message and provide a summary of this 
discussion?


Cheers,

--
Julien Grall

Re: [PATCH] xen/arm: skip first 32 bytes of zimage32

[Julien Grall]

Hi,

On 21/03/2022 19:29, Stefano Stabellini wrote:

On Sun, 20 Mar 2022, Julien Grall wrote:

On 20/03/2022 07:47, Julien Grall wrote:

On 20/03/2022 01:05, Stefano Stabellini wrote:

From: Stefano Stabellini 

The first 32 bytes of zImage32 are NOPs, not useful just there for
compatibility. The reason is that some bootloaders skip the first 32
bytes when starting the kernel. See the comment in Linux
arch/arm/boot/compressed/head.S.


Please mention the Linux verson.


Since the introduction of CONFIG_EFI in Linux arm32, those NOPs
operations have changed implementation from:

  mov r0, r0

to:
  .inst   MZ_MAGIC | (0x1310 << 16)   @ tstne r0, #0x4d000


I have duplicated the comment and the instructions below:

      @ This is a two-instruction NOP, which happens to bear the
      @ PE/COFF signature "MZ" in the first two bytes, so the
kernel
      @ is accepted as an EFI binary. Booting via the UEFI stub
      @ will not execute those instructions, but the ARM/Linux
      @ boot protocol does, so we need some NOPs here.
      .inst   MZ_MAGIC | (0xe225 << 16)   @ eor r5, r5,
0x4d000
      eor r5, r5, 0x4d000 @ undo previous
insn


I read this as they are NOPs and this change should not break the ARM/Linux
boot protocol (we are using it in Xen).

BTW, the instruction decoding is different compare to me. Which version of
Linux are you using?



See arch/arm/boot/compressed/efi-header.S.

The new implementation doesn't work on Xen (at least on all versions of
QEMU I tried).


As I wrote above, they are NOPs. So why is this breaking?


I have tried to boot the latest Linux (commit 14702b3b2438) with CONFIG_EFI=y
on QEMU (commit fa435db8ce1d). This booted for me.

As I wrote earlier today, the instruction used as NOPs is slightly different.
So I had a look at the git history and found the following commit:

commit a92882a4d270
Author: Andre Przywara 
Date:   Mon Nov 22 16:28:43 2021 +0100

 ARM: 9159/1: decompressor: Avoid UNPREDICTABLE NOP encoding

 In the decompressor's head.S we need to start with an instruction that
 is some kind of NOP, but also mimics as the PE/COFF header, when the
 kernel is linked as an UEFI application. The clever solution here is
 "tstne r0, #0x4d000", which in the worst case just clobbers the
 condition flags, and bears the magic "MZ" signature in the lowest 16 bits.

 However the encoding used (0x13105a4d) is actually not valid, since bits
 [15:12] are supposed to be 0 (written as "(0)" in the ARM ARM).
 Violating this is UNPREDICTABLE, and *can* trigger an UNDEFINED
 exception. Common Cortex cores seem to ignore those bits, but QEMU
 chooses to trap, so the code goes fishing because of a missing exception
 handler at this point. We are just saved by the fact that commonly (with
 -kernel or when running from U-Boot) the "Z" bit is set, so the
 instruction is never executed. See [0] for more details.

 To make things more robust and avoid UNPREDICTABLE behaviour in the
 kernel code, lets replace this with a "two-instruction NOP":
 The first instruction is an exclusive OR, the effect of which the second
 instruction reverts. This does not leave any trace, neither in a
 register nor in the condition flags. Also it's a perfectly valid
 encoding. Kudos to Peter Maydell for coming up with this gem.

 [0]
https://lore.kernel.org/qemu-devel/ytpidbucmwagl5%...@os.inf.tu-dresden.de/T/

 Link:
https://lore.kernel.org/linux-arm-kernel/20210908162617.104962-1-andre.przyw...@arm.com/T/

So this is a bug in the kernel that has nothing to do with Xen.

Therefore, I am not in favor to workaround it in Xen. Where did you get your
kernel from? If this from a distro, then please work with them to ingest the
above patch.


Unfortunately all the kernels I tried failed without the Xen fix.

This is the list of kernels that I tried and failed:

- Debian Buster
- Debian Bullseye
- vanilla 4.9
- vanilla 4.10


Does this mean you where using v4.{9,10}.0 rather than the stable branch?

Note that AFAICT, 4.10 is not even supported by the kernel communinty 
(see [1]).




The latest Alpine Linux kernel also doesn't boot, but that one doesn't
boot even with the fix for other reason. (More in the other email.)


 From a Xen gitlab-ci perspective, we just need a kernel that works.
Ideally, we wouldn't rebuild our own but reuse an existing kernel
because that is one less things to maintain in the gitlab-ci build.

We have a couple of options to make progress on the QEMU32 gitlab-ci
test:

1) use Debian Jessie in gitlab-ci and do not commit the Xen-side fix,
file a Debian bug and revisit the situation in a couple of months
(Debian might get the fix in the meantime)


Why do we need to use Debian here? Couldn't we use Ubuntu (or any 
distros that have a newer kernel)?




2) commit the Xen fix and use 

Re: [PATCH v1 02/13] xen/arm: introduce a special domain DOMID_SHARED

[Stefano Stabellini]

On Mon, 21 Mar 2022, Jan Beulich wrote:
> On 18.03.2022 22:50, Stefano Stabellini wrote:
> > On Fri, 18 Mar 2022, Jan Beulich wrote:
> >> On 11.03.2022 07:11, Penny Zheng wrote:
> >>> In case to own statically shared pages when owner domain is not
> >>> explicitly defined, this commits propose a special domain DOMID_SHARED,
> >>> and we assign it 0x7FF5, as one of the system domains.
> >>>
> >>> Statically shared memory reuses the same way of initialization with static
> >>> memory, hence this commits proposes a new Kconfig CONFIG_STATIC_SHM to 
> >>> wrap
> >>> related codes, and this option depends on static 
> >>> memory(CONFIG_STATIC_MEMORY).
> >>>
> >>> We intends to do shared domain creation after setup_virt_paging so shared
> >>> domain could successfully do p2m initialization.
> >>
> >> There's nothing said here, in the earlier patch, or in the cover letter
> >> about the security aspects of this. There is a reason we haven't been
> >> allowing arbitrary, un-supervised sharing of memory between domains. It
> >> wants clarifying why e.g. grants aren't an option to achieve what you
> >> need, and how you mean to establish which domains are / aren't permitted
> >> to access any individual page owned by this domain.
> > 
> > 
> > I'll let Penny write a full reply but I'll chime in to try to help with
> > the explanation.
> > 
> > This is not arbitrary un-supervised sharing of memory between domains,
> > which indeed is concerning.
> > 
> > This is statically-configured, supervised by the system configurator,
> > sharing of memory between domains.
> > 
> > And in fact safety (which is just a different aspect of security) is one
> > of the primary goals for this work.
> > 
> > In safety-critical environments, it is not considered safe to
> > dynamically change important configurations at runtime. Everything
> > should be statically defined and statically verified.
> > 
> > In this case, if the system configuration knows a priori that there are
> > only 2 VM and they need to communication over shared memory, it is safer
> > to pre-configure the shared memory at build time rather than let the VMs
> > attempt to share memory at runtime. It is faster too.
> > 
> > The only way to trigger this static shared memory configuration should
> > be via device tree, which is at the same level as the XSM rules
> > themselves.
> > 
> > Hopefully I made things clearer and not murkier :-)
> 
> It adds some helpful background, yes, but at the same time it doesn't
> address the security concern at all: How are access permissions
> managed when the owning domain is a special one? I haven't spotted
> any recording of the domains which are actually permitted to map /
> access the pages in questions. (But of course I also only looked at
> non-Arm-specific code. I'd expect such code not to live in arch-
> specific files.)

All this static memory sharing is statically done at __init time only.
It should not be possible to trigger any further memory sharing at
runtime (if there is, that would be a bug).  In the Arm patches, all the
related functions are marked as __init and only called at boot time.
They map the memory owned by DOMID_SHARED at given guest
pseudo-physical addresses, also specified in device tree.

There are no new interfaces for the guest to map this memory because it
is already "pre-mapped".

Re: [PATCH RESEND 2/2] gitlab-ci: add an ARM32 qemu-based smoke test

[Stefano Stabellini]

On Mon, 21 Mar 2022, Anthony PERARD wrote:
> On Fri, Mar 18, 2022 at 05:15:06PM -0700, Stefano Stabellini wrote:
> > On Fri, 18 Mar 2022, Anthony PERARD wrote:
> > > On Wed, Mar 16, 2022 at 06:38:53PM -0700, Stefano Stabellini wrote:
> > > > Also considering the recent arm32 xen breakage, which could have been
> > > > caught by gitlab-ci before commit,
> > > 
> > > I'm not sure that's true. I think the commits you are speaking about
> > > also break the build on x86, which was caught by the gitlab ci.
> > > 
> > > Anyway, some arm32 smoke tests on gitlab should be useful.
> > 
> > I think we are probably talking about different breakages :-)
> > 
> > Ayan recently broke Xen on ARM32 (run-time not build-time) with the
> > commit 9e5a68a66 and fef5531fd. I verified that the QEMU32 test in this
> > series actually catches the failure.
> 
> See the pipeline on this commit:
> https://gitlab.com/xen-project/xen/-/commit/fef5531fd
> https://gitlab.com/xen-project/xen/-/pipelines/491963118
> 
> ;-)

Ah! Now I understand, thank you!

Re: [PATCH v3 2/2] gitlab-ci: add an ARM32 qemu-based smoke test

[Stefano Stabellini]

On Sun, 20 Mar 2022, Julien Grall wrote:
> On 20/03/2022 01:46, Stefano Stabellini wrote:
> > On Fri, 18 Mar 2022, Stefano Stabellini wrote:
> > > Add a minimal ARM32 smoke test based on qemu-system-arm, as provided by
> > > the test-artifacts qemu container. The minimal test simply boots Xen
> > > (built from previous build stages) and Dom0. The test is fetching the
> > > Dom0 kernel and initrd from Debian Jessie: they work just fine and this
> > > way we don't have to maintain a build for them too.
> > 
> > 
> > Thanks to the Xen fix recently submitted
> > (https://marc.info/?l=xen-devel=164774063802402) I'll be able to
> > update this script to use Debian Bullseye. I am thinking of merging the
> > below directly with this patch.
> > 
> > 
> > ---
> > 
> > automation: upgrade Debian to Bullseye for testing Xen aarch32
> > 
> > Also change initrd. As the new netboot initrd from Debian Bullseye is
> > huge (22MB), use a tiny initrd from Alpine Linux instead (only 2.5MB).
> 
> This is sounds odd to me. So we are going to use Bullseye but not really
> because we want to use a different initrd.
> 
> Why can't you get everything from the same place?

Because it doesn't work :-(


> > Also note that the huge Debian Bullseye initrd would cause QEMU to
> > crash due to the -device loader parameter.
> 
> Can you provide more details? Was this reported to QEMU?

QEMU core dumps when provided with the Debian Bullseye initrd binary to
load. I guessed it was due to the size and tried with a smaller size.
Everything worked with a smaller initrd. I also think that it is not a
good idea to use a 22MB initrd anyway so decided against the Debian
Bullseye initrd. (For reference 22MB is basically the size of a fully
featured Yocto-build rootfs.) I did not file a bug to qemu-devel yet and
didn't investigate further on the QEMU side as I ran out of time.

Alpine Linux provides a very nice 2.5MB initrd. I tried to use both
kernel and initrd from Alpine Linux but unfortunately the Alpine Linux
kernel doesn't boot. I don't know why but I think it is because it might
be missing the console driver. I am not sure. There are a lot of
combinations that don't work and it is time consuming to investigate
them all. I have been trying to investigate only the most critical
things -- they are too many! 

I should add that the Debian initrd is not the ideal initrd because it
is made to start the Debian installer. Here we just want a tiny busybox
initrd.

In general, I think it would be better if we could use the kernel and
initrd from the same source but I couldn't find one that works. I could
build one myself but it would be one more thing to maintain in
gitlab-ci. Also using u-boot might solve the problem of loading the
binary but again we would have to maintain a u-boot arm32 build in
gitlab-ci.

So in order of preference best to worst in my opinion:

1) kernel and initrd from the same source
2) kernel and initrd from different sources
3) build your own kernel/initrd/u-boot

So I ended up doing 2). I tested it and it is sufficient to get the test
up and running.

 
> > Signed-off-by: Stefano Stabellini 
> > 
> > diff --git a/automation/scripts/qemu-smoke-arm32.sh
> > b/automation/scripts/qemu-smoke-arm32.sh
> > index 162922ace5..d554de7939 100755
> > --- a/automation/scripts/qemu-smoke-arm32.sh
> > +++ b/automation/scripts/qemu-smoke-arm32.sh
> > @@ -5,11 +5,20 @@ set -ex
> >   export DEBIAN_FRONTENT=noninteractive
> >   apt-get -qy update
> >   apt-get -qy install --no-install-recommends device-tree-compiler \
> > -curl
> > +curl \
> > +cpio
> > cd binaries
> > -curl --fail --silent --show-error --location --output vmlinuz
> > http://http.us.debian.org/debian/dists/jessie/main/installer-armhf/current/images/netboot/vmlinuz
> > -curl --fail --silent --show-error --location --output initrd.gz
> > http://http.us.debian.org/debian/dists/jessie/main/installer-armhf/current/images/netboot/initrd.gz
> > +# Use the kernel from Debian
> > +curl --fail --silent --show-error --location --output vmlinuz
> > http://http.us.debian.org/debian/dists/bullseye/main/installer-armhf/current/images/netboot/vmlinuz
> > +# Use a tiny initrd based on busybox from Alpine Linux
> > +curl --fail --silent --show-error --location --output initrd.tar.gz
> > https://dl-cdn.alpinelinux.org/alpine/v3.15/releases/armhf/alpine-minirootfs-3.15.1-armhf.tar.gz
> > +
> > +mkdir rootfs
> > +cd rootfs
> > +tar xvzf ../initrd.tar.gz
> > +find . | cpio -H newc -o | gzip > ../initrd.gz
> > +cd ..
> > kernel=`stat -L --printf="%s" vmlinuz`
> >   initrd=`stat -L --printf="%s" initrd.gz`
> > @@ -68,5 +77,5 @@ timeout -k 1 240 \
> >  -device loader,file=./initrd.gz,addr=0x320 |& tee smoke.serial
> > set -e
> > -(grep -q "^BusyBox" smoke.serial) || exit 1
> > +(grep -q "^/ #" smoke.serial) || exit 1
> >   exit 0

Re: [PATCH 3/3] xen/arm: Add i.MX8QM platform support

[Julien Grall]

Hi Peng,

On 18/03/2022 05:24, Peng Fan wrote:

Subject: Re: [PATCH 3/3] xen/arm: Add i.MX8QM platform support
On 28/02/2022 01:07, Peng Fan (OSS) wrote:

+static const char * const imx8qm_dt_compat[] __initconst = {
+"fsl,imx8qm",
+NULL
+};
+
+PLATFORM_START(imx8qm, "i.MX 8")
+.compatible = imx8qm_dt_compat,
+PLATFORM_END


We are only adding new platform definition when quirks are necessary. Do
you need specific quirks for the i.MX8QM?

A somewhat related question, is this series enough to boot Xen upstream on
the board?


Boot xen upstream, no need specific quirk.


That's great to hear! Then this file should not be necessary at all. 
Please drop it.


Cheers,

--
Julien Grall

Re: [PATCH 1/3] xen/arm: Add i.MX lpuart driver

[Julien Grall]

Hi Peng,

On 18/03/2022 05:23, Peng Fan wrote:

Subject: Re: [PATCH 1/3] xen/arm: Add i.MX lpuart driver
On 28/02/2022 01:07, Peng Fan (OSS) wrote:

From: Peng Fan 
+
+imx_lpuart_write(uart, UARTDATA, c); }
+
+static int imx_lpuart_getc(struct serial_port *port, char *pc) {
+struct imx_lpuart *uart = port->uart;
+int ch;
+
+while ( !(imx_lpuart_read(uart, UARTSTAT) & UARTSTAT_RDRF))
+barrier();


Same remark about the barrier.

However, rather than waiting, shouldn't we check the watermark instead and
return 0 if there are no character to read?


We normally check status bit to check whether there are data to read.


I guess by "we", you mean the caller. In which case, there is at least 
one (i.e. serial_getc()) that will not check the status before calling 
getc(). Instead, it will wait if the helper returns 0.


Looking at the other UART driver, none of them seem to busy loop. So, at 
least for consistency, we should avoid the busy loop here.


Cheers,

--
Julien Grall

Re: [PATCH] xen/arm: skip first 32 bytes of zimage32

[Stefano Stabellini]

On Sun, 20 Mar 2022, Julien Grall wrote:
> On 20/03/2022 07:47, Julien Grall wrote:
> > On 20/03/2022 01:05, Stefano Stabellini wrote:
> > > From: Stefano Stabellini 
> > > 
> > > The first 32 bytes of zImage32 are NOPs, not useful just there for
> > > compatibility. The reason is that some bootloaders skip the first 32
> > > bytes when starting the kernel. See the comment in Linux
> > > arch/arm/boot/compressed/head.S.
> > 
> > Please mention the Linux verson.
> >
> > > Since the introduction of CONFIG_EFI in Linux arm32, those NOPs
> > > operations have changed implementation from:
> > > 
> > >  mov r0, r0
> > > 
> > > to:
> > >  .inst   MZ_MAGIC | (0x1310 << 16)   @ tstne r0, #0x4d000
> > 
> > I have duplicated the comment and the instructions below:
> > 
> >      @ This is a two-instruction NOP, which happens to bear the
> >      @ PE/COFF signature "MZ" in the first two bytes, so the
> > kernel
> >      @ is accepted as an EFI binary. Booting via the UEFI stub
> >      @ will not execute those instructions, but the ARM/Linux
> >      @ boot protocol does, so we need some NOPs here.
> >      .inst   MZ_MAGIC | (0xe225 << 16)   @ eor r5, r5,
> > 0x4d000
> >      eor r5, r5, 0x4d000 @ undo previous
> > insn
> > 
> > 
> > I read this as they are NOPs and this change should not break the ARM/Linux
> > boot protocol (we are using it in Xen).
> > 
> > BTW, the instruction decoding is different compare to me. Which version of
> > Linux are you using?
> > 
> > > 
> > > See arch/arm/boot/compressed/efi-header.S.
> > > 
> > > The new implementation doesn't work on Xen (at least on all versions of
> > > QEMU I tried).
> > 
> > As I wrote above, they are NOPs. So why is this breaking?
> 
> I have tried to boot the latest Linux (commit 14702b3b2438) with CONFIG_EFI=y
> on QEMU (commit fa435db8ce1d). This booted for me.
>
> As I wrote earlier today, the instruction used as NOPs is slightly different.
> So I had a look at the git history and found the following commit:
> 
> commit a92882a4d270
> Author: Andre Przywara 
> Date:   Mon Nov 22 16:28:43 2021 +0100
> 
> ARM: 9159/1: decompressor: Avoid UNPREDICTABLE NOP encoding
> 
> In the decompressor's head.S we need to start with an instruction that
> is some kind of NOP, but also mimics as the PE/COFF header, when the
> kernel is linked as an UEFI application. The clever solution here is
> "tstne r0, #0x4d000", which in the worst case just clobbers the
> condition flags, and bears the magic "MZ" signature in the lowest 16 bits.
> 
> However the encoding used (0x13105a4d) is actually not valid, since bits
> [15:12] are supposed to be 0 (written as "(0)" in the ARM ARM).
> Violating this is UNPREDICTABLE, and *can* trigger an UNDEFINED
> exception. Common Cortex cores seem to ignore those bits, but QEMU
> chooses to trap, so the code goes fishing because of a missing exception
> handler at this point. We are just saved by the fact that commonly (with
> -kernel or when running from U-Boot) the "Z" bit is set, so the
> instruction is never executed. See [0] for more details.
> 
> To make things more robust and avoid UNPREDICTABLE behaviour in the
> kernel code, lets replace this with a "two-instruction NOP":
> The first instruction is an exclusive OR, the effect of which the second
> instruction reverts. This does not leave any trace, neither in a
> register nor in the condition flags. Also it's a perfectly valid
> encoding. Kudos to Peter Maydell for coming up with this gem.
> 
> [0]
> https://lore.kernel.org/qemu-devel/ytpidbucmwagl5%...@os.inf.tu-dresden.de/T/
> 
> Link:
> https://lore.kernel.org/linux-arm-kernel/20210908162617.104962-1-andre.przyw...@arm.com/T/
> 
> So this is a bug in the kernel that has nothing to do with Xen.
> 
> Therefore, I am not in favor to workaround it in Xen. Where did you get your
> kernel from? If this from a distro, then please work with them to ingest the
> above patch.

Unfortunately all the kernels I tried failed without the Xen fix.

This is the list of kernels that I tried and failed:

- Debian Buster
- Debian Bullseye
- vanilla 4.9
- vanilla 4.10

The latest Alpine Linux kernel also doesn't boot, but that one doesn't
boot even with the fix for other reason. (More in the other email.)


>From a Xen gitlab-ci perspective, we just need a kernel that works.
Ideally, we wouldn't rebuild our own but reuse an existing kernel
because that is one less things to maintain in the gitlab-ci build.

We have a couple of options to make progress on the QEMU32 gitlab-ci
test:

1) use Debian Jessie in gitlab-ci and do not commit the Xen-side fix,
   file a Debian bug and revisit the situation in a couple of months
   (Debian might get the fix in the meantime)

2) commit the Xen fix and use Debian Bullseye right now

3) do not commit the Xen fix and 

[ovmf test] 168758: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf 267a92fef3b705e6a3ecbeaa4d4b58f7bfac9734
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   21 days
Failing since168258  2022-03-01 01:55:31 Z   20 days  215 attempts
Testing same since   168738  2022-03-21 02:39:18 Z0 days   14 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  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 859 lines long.)

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Julien Grall]

Hi Bertrand,

On 21/03/2022 17:19, Bertrand Marquis wrote:

On 21 Mar 2022, at 17:36, Julien Grall  wrote:

So I don’t know why on x86 we must have cpu0 in cpupool0, maybe x86 maintainer 
have more knowledge about that and
I can put a comment here.


On Arm, we are not yet supporting all the CPU features that x86 supports (e.g. 
CPU hotplug, suspend/resume...). So I a am bit concerned that the restriction 
is just not there yet (or possibly hidden).

Therefore, before lifting the restriction on Arm (and other arch), I would like 
us to understand why it is necessary on x86.

We may not have the answer quickly, so is it going to be a problem to keep the 
restriction on Arm?


I am ok to keep the limitation to have dom0 always running on cpu0.
Only limitation I can see is that on a big little system, dom0 needs to stay on 
the type of core of the first booted core.


Where does this limitation come from?

Cheers,

--
Julien Grall

Requesting Xen community's feedback on unikernelized driver domains

[tosher 1]

Hello,

This email is to request Xen community's feedback on our work on implementing 
Xen’s driver domains using the unikernel virtual machine model (as opposed to 
using general-purpose OSs like Linux) to reduce the attack surface, among other 
benefits. The effort, called Kite, has implemented driver domains for network 
and storage PV drivers using NetBSD’s rumprun unikernel.

Details of the work are available in a paper that will soon appear at the 2022 
ACM European Conference on Computer Systems (EuroSys’22), available here: 
https://www.ssrg.ece.vt.edu/papers/eurosys22.pdf.

Kite’s source code is available at: https://github.com/ssrg-vt/kite/.

We would love to hear the community’s thoughts and feedback.

Thank you, and looking forward,

Mehrab


P.S. This email is cross-posted in xen-users mailing list 
(https://lists.xenproject.org/archives/html/xen-users/2022-03/msg00013.html).

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Bertrand Marquis]

Hi Julien,

> On 21 Mar 2022, at 17:36, Julien Grall  wrote:
> 
> Hi,
> 
> On 21/03/2022 15:58, Luca Fancellu wrote:
>>> On 18 Mar 2022, at 16:12, Julien Grall  wrote:
>>> 
>>> Hi Luca,
>>> 
>>> I only skimmed through the series. I have one question below:
>>> 
>>> On 18/03/2022 15:25, Luca Fancellu wrote:
 +void __init btcpupools_allocate_pools(void)
 +{
 +unsigned int i;
 +bool add_extra_cpupool = false;
 +
 +/*
 + * If there are no cpupools, the value of next_pool_id is zero, so 
 the code
 + * below will assign every cpu to cpupool0 as the default behavior.
 + * When there are cpupools, the code below is assigning all the not
 + * assigned cpu to a new pool (next_pool_id value is the last id + 1).
 + * In the same loop we check if there is any assigned cpu that is not
 + * online.
 + */
 +for ( i = 0; i < nr_cpu_ids; i++ )
 +if ( cpumask_test_cpu(i, _online_map) )
 +{
 +/* Unassigned cpu gets next_pool_id pool id value */
 +if ( pool_cpu_map[i] < 0 )
 +{
 +pool_cpu_map[i] = next_pool_id;
 +add_extra_cpupool = true;
 +}
 +printk(XENLOG_INFO "Logical CPU %u in Pool-%u.\n", i,
 +   pool_cpu_map[i]);
 +}
 +else
 +{
 +if ( pool_cpu_map[i] >= 0 )
 +panic("Pool-%d contains cpu%u that is not online!\n",
 +  pool_cpu_map[i], i);
 +}
 +
 +if ( add_extra_cpupool )
 +next_pool_id++;
 +
 +/* Create cpupools with selected schedulers */
 +for ( i = 0; i < next_pool_id; i++ )
 +cpupool_create_pool(i, pool_sched_map[i]);
 +
 +#ifdef CONFIG_X86
 +/* Cpu0 must be in cpupool0 for x86 */
 +if ( pool_cpu_map[0] != 0 )
 +panic("Cpu0 must be in Pool-0\n");
 +#endif
>>> 
>>> Can you document why this is necessary on x86 but not on other 
>>> architectures?
>> Hi Julien,
>> I received the warning by Juergen here: 
>> https://patchwork.kernel.org/comment/24740762/ that at least on x86 there 
>> could be
>> some problems if cpu0 is not in cpupool0, I tested it on arm and it was 
>> working fine and I didn’t find any restriction.
> 
> What exactly did you test on Arm?
> 
>> So I don’t know why on x86 we must have cpu0 in cpupool0, maybe x86 
>> maintainer have more knowledge about that and
>> I can put a comment here.
> 
> On Arm, we are not yet supporting all the CPU features that x86 supports 
> (e.g. CPU hotplug, suspend/resume...). So I a am bit concerned that the 
> restriction is just not there yet (or possibly hidden).
> 
> Therefore, before lifting the restriction on Arm (and other arch), I would 
> like us to understand why it is necessary on x86.
> 
> We may not have the answer quickly, so is it going to be a problem to keep 
> the restriction on Arm?

I am ok to keep the limitation to have dom0 always running on cpu0.
Only limitation I can see is that on a big little system, dom0 needs to stay on 
the type of core of the first booted core.
But as the user could modify his firmware to boot on the type of core he wants, 
this limitation can usually be worked around.
So it is not a problem.
Maybe we could make that an unsupported feature that one could activate through 
the configuration ?

Cheers
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall

[ovmf test] 168757: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf 267a92fef3b705e6a3ecbeaa4d4b58f7bfac9734
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   21 days
Failing since168258  2022-03-01 01:55:31 Z   20 days  214 attempts
Testing same since   168738  2022-03-21 02:39:18 Z0 days   13 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  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 859 lines long.)

Re: [PATCH v3] x86/vmx: save guest non-register state in hvm_hw_cpu

[Jan Beulich]

On 21.03.2022 17:26, Tamas K Lengyel wrote:
> During VM forking and resetting a failed vmentry has been observed due
> to the guest non-register state going out-of-sync with the guest register
> state. For example, a VM fork reset right after a STI instruction can trigger
> the failed entry. This is due to the guest non-register state not being saved
> from the parent VM, thus the reset operation only copies the register state.
> 
> Fix this by including the guest non-register state in hvm_hw_cpu so that when
> its copied from the parent VM the vCPU state remains in sync.
> 
> SVM is not currently wired-in as VM forking is VMX only and saving 
> non-register
> state during normal save/restore/migration operation hasn't been needed. If
> deemed necessary in the future it can be wired in by adding a svm-substructure
> to hvm_hw_cpu.
> 
> Signed-off-by: Tamas K Lengyel 

Reviewed-by: Jan Beulich 

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Julien Grall]

Hi,

On 21/03/2022 15:58, Luca Fancellu wrote:




On 18 Mar 2022, at 16:12, Julien Grall  wrote:

Hi Luca,

I only skimmed through the series. I have one question below:

On 18/03/2022 15:25, Luca Fancellu wrote:

+void __init btcpupools_allocate_pools(void)
+{
+unsigned int i;
+bool add_extra_cpupool = false;
+
+/*
+ * If there are no cpupools, the value of next_pool_id is zero, so the code
+ * below will assign every cpu to cpupool0 as the default behavior.
+ * When there are cpupools, the code below is assigning all the not
+ * assigned cpu to a new pool (next_pool_id value is the last id + 1).
+ * In the same loop we check if there is any assigned cpu that is not
+ * online.
+ */
+for ( i = 0; i < nr_cpu_ids; i++ )
+if ( cpumask_test_cpu(i, _online_map) )
+{
+/* Unassigned cpu gets next_pool_id pool id value */
+if ( pool_cpu_map[i] < 0 )
+{
+pool_cpu_map[i] = next_pool_id;
+add_extra_cpupool = true;
+}
+printk(XENLOG_INFO "Logical CPU %u in Pool-%u.\n", i,
+   pool_cpu_map[i]);
+}
+else
+{
+if ( pool_cpu_map[i] >= 0 )
+panic("Pool-%d contains cpu%u that is not online!\n",
+  pool_cpu_map[i], i);
+}
+
+if ( add_extra_cpupool )
+next_pool_id++;
+
+/* Create cpupools with selected schedulers */
+for ( i = 0; i < next_pool_id; i++ )
+cpupool_create_pool(i, pool_sched_map[i]);
+
+#ifdef CONFIG_X86
+/* Cpu0 must be in cpupool0 for x86 */
+if ( pool_cpu_map[0] != 0 )
+panic("Cpu0 must be in Pool-0\n");
+#endif


Can you document why this is necessary on x86 but not on other architectures?


Hi Julien,

I received the warning by Juergen here: 
https://patchwork.kernel.org/comment/24740762/ that at least on x86 there could 
be
some problems if cpu0 is not in cpupool0, I tested it on arm and it was working 
fine and I didn’t find any restriction.


What exactly did you test on Arm?



So I don’t know why on x86 we must have cpu0 in cpupool0, maybe x86 maintainer 
have more knowledge about that and
I can put a comment here.


On Arm, we are not yet supporting all the CPU features that x86 supports 
(e.g. CPU hotplug, suspend/resume...). So I a am bit concerned that the 
restriction is just not there yet (or possibly hidden).


Therefore, before lifting the restriction on Arm (and other arch), I 
would like us to understand why it is necessary on x86.


We may not have the answer quickly, so is it going to be a problem to 
keep the restriction on Arm?


Cheers,

--
Julien Grall

[PATCH v3] x86/vmx: save guest non-register state in hvm_hw_cpu

[Tamas K Lengyel]

During VM forking and resetting a failed vmentry has been observed due
to the guest non-register state going out-of-sync with the guest register
state. For example, a VM fork reset right after a STI instruction can trigger
the failed entry. This is due to the guest non-register state not being saved
from the parent VM, thus the reset operation only copies the register state.

Fix this by including the guest non-register state in hvm_hw_cpu so that when
its copied from the parent VM the vCPU state remains in sync.

SVM is not currently wired-in as VM forking is VMX only and saving non-register
state during normal save/restore/migration operation hasn't been needed. If
deemed necessary in the future it can be wired in by adding a svm-substructure
to hvm_hw_cpu.

Signed-off-by: Tamas K Lengyel 
---
v3: Add XEN_X86_VMX flag and vmx-substructure in hvm_hw_cpu
v2: Include all CPU non-register state and fold the ops into vmx_vmcs_save &
vmx_vmcs_restore.
Note: no sanity checking is performed on the fields to reduce the cycles during
  fuzzing.
---
 xen/arch/x86/hvm/vmx/vmx.c | 17 -
 xen/include/public/arch-x86/hvm/save.h | 13 +
 2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index c075370f64..6da3842d6e 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -713,7 +713,7 @@ static void vmx_restore_dr(struct vcpu *v)
 
 static void vmx_vmcs_save(struct vcpu *v, struct hvm_hw_cpu *c)
 {
-unsigned long ev;
+unsigned long ev, activity_state, intr_info;
 
 vmx_vmcs_enter(v);
 
@@ -721,6 +721,10 @@ static void vmx_vmcs_save(struct vcpu *v, struct 
hvm_hw_cpu *c)
 __vmread(GUEST_SYSENTER_ESP, >sysenter_esp);
 __vmread(GUEST_SYSENTER_EIP, >sysenter_eip);
 
+__vmread(GUEST_ACTIVITY_STATE, _state);
+__vmread(GUEST_INTERRUPTIBILITY_INFO, _info);
+__vmread(GUEST_PENDING_DBG_EXCEPTIONS, >vmx.pending_dbg);
+
 __vmread(VM_ENTRY_INTR_INFO, );
 if ( (ev & INTR_INFO_VALID_MASK) &&
  hvm_event_needs_reinjection(MASK_EXTR(ev, INTR_INFO_INTR_TYPE_MASK),
@@ -732,6 +736,10 @@ static void vmx_vmcs_save(struct vcpu *v, struct 
hvm_hw_cpu *c)
 }
 
 vmx_vmcs_exit(v);
+
+c->vmx.activity_state = activity_state;
+c->vmx.interruptibility_info = intr_info;
+c->flags |= XEN_X86_VMX;
 }
 
 static int vmx_restore_cr0_cr3(
@@ -807,6 +815,13 @@ static int vmx_vmcs_restore(struct vcpu *v, struct 
hvm_hw_cpu *c)
 
 __vmwrite(GUEST_DR7, c->dr7);
 
+if ( c->flags & XEN_X86_VMX )
+{
+__vmwrite(GUEST_ACTIVITY_STATE, c->vmx.activity_state);
+__vmwrite(GUEST_INTERRUPTIBILITY_INFO, c->vmx.interruptibility_info);
+__vmwrite(GUEST_PENDING_DBG_EXCEPTIONS, c->vmx.pending_dbg);
+}
+
 if ( c->pending_valid &&
  hvm_event_needs_reinjection(c->pending_type, c->pending_vector) )
 {
diff --git a/xen/include/public/arch-x86/hvm/save.h 
b/xen/include/public/arch-x86/hvm/save.h
index 773a380bc2..0f728aa5d9 100644
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -52,6 +52,7 @@ DECLARE_HVM_SAVE_TYPE(HEADER, 1, struct hvm_save_header);
  * Compat:
  * - Pre-3.4 didn't have msr_tsc_aux
  * - Pre-4.7 didn't have fpu_initialised
+ * - Pre-4.17 didn't have non-register state
  */
 
 struct hvm_hw_cpu {
@@ -163,9 +164,21 @@ struct hvm_hw_cpu {
 uint32_t error_code;
 
 #define _XEN_X86_FPU_INITIALISED0
+#define _XEN_X86_VMX1
 #define XEN_X86_FPU_INITIALISED (1U<<_XEN_X86_FPU_INITIALISED)
+#define XEN_X86_VMX (1U<<_XEN_X86_VMX)
 uint32_t flags;
 uint32_t pad0;
+
+/* non-register state */
+union {
+/* if flags & XEN_X86_VMX */
+struct {
+uint32_t activity_state;
+uint32_t interruptibility_info;
+uint64_t pending_dbg;
+} vmx;
+};
 };
 
 struct hvm_hw_cpu_compat {
-- 
2.25.1

Re: [PATCH v2] x86/vmx: save guest non-register state in hvm_hw_cpu

[Jan Beulich]

On 21.03.2022 16:28, Tamas K Lengyel wrote:
> On Mon, Mar 21, 2022 at 10:58 AM Jan Beulich  wrote:
>> On 21.03.2022 15:39, Tamas K Lengyel wrote:
>>> On Mon, Mar 21, 2022 at 8:16 AM Jan Beulich  wrote:
 On 17.03.2022 16:57, Tamas K Lengyel wrote:
> @@ -166,6 +167,11 @@ struct hvm_hw_cpu {
>  #define XEN_X86_FPU_INITIALISED (1U<<_XEN_X86_FPU_INITIALISED)
>  uint32_t flags;
>  uint32_t pad0;
> +
> +/* non-register state */
> +uint32_t activity_state;
> +uint32_t interruptibility_state;
> +uint64_t pending_dbg;
>  };

 ... these fields now represent vendor state in a supposedly vendor
 independent structure. Besides my wish to see this represented in
 field naming (thus at least making provisions for SVM to gain
 similar support; perhaps easiest would be to include these in a
 sub-structure with a field name of "vmx"), I wonder in how far cross-
 vendor migration was taken into consideration. As long as the fields
 are zero / ignored, things wouldn't be worse than before your
 change, but I think it wants spelling out that the SVM counterpart(s)
 may not be added by way of making a VMX/SVM union.
>>>
>>> I wasn't aware cross-vendor migration is even a thing.
>>
>> It used to be a thing long ago; it may not work right now for no-one
>> testing it.
>>
>>> But adding a
>>> vmx sub-structure seems to me a workable route, we would perhaps just
>>> need an extra field that specifies where the fields were taken
>>> (vmx/svm) and ignore them if the place where the restore is taking
>>> place doesn't match where the save happened. That would be equivalent
>>> to how migration works today. Thoughts?
>>
>> I don't think such a field is needed, at least not right away, as
>> long as the respectively other vendor's fields are left zero when
>> storing the data. These fields being zero matches current behavior
>> of not communicating the values at all. A separate flag might be
>> needed if the receiving side would want to "emulate" settings from
>> incoming values from the respectively other vendor. Yet even then
>> only one of the two sets of fields could potentially be non-zero
>> (both being non-zero is an error imo); both fields being zero
>> would be compatible both ways. Hence it would be possible to
>> determine the source vendor without an extra field even then, I
>> would think.
>>
>> A separate flag would of course be needed if we meant to overlay
>> the vendors' data in a union. But as per my earlier reply I think
>> we're better off not using a union in this case.
> 
> Right, both structs being non-zero at the same time wouldn't make
> sense and would indicate corruption of the hvm save file. But I think
> the same would easily be achieved by defining a bit on the flags and
> then a union. If two vendor bits are set that would indicate an error
> without taking up the same with two separate structs. This is what I
> have right now and IMHO it looks good
> (https://xenbits.xen.org/gitweb/?p=people/tklengyel/xen.git;a=commitdiff;h=84f15b2e1bef6c901bbdf29a07c7904cb365c0b2):

Yeah, why not. With the separate flag all should be fine.

Jan

> --- a/xen/include/public/arch-x86/hvm/save.h
> +++ b/xen/include/public/arch-x86/hvm/save.h
> @@ -52,6 +52,7 @@ DECLARE_HVM_SAVE_TYPE(HEADER, 1, struct hvm_save_header);
>   * Compat:
>   * - Pre-3.4 didn't have msr_tsc_aux
>   * - Pre-4.7 didn't have fpu_initialised
> + * - Pre-4.17 didn't have non-register state
>   */
> 
>  struct hvm_hw_cpu {
> @@ -163,9 +164,21 @@ struct hvm_hw_cpu {
>  uint32_t error_code;
> 
>  #define _XEN_X86_FPU_INITIALISED0
> +#define _XEN_X86_VMX1
>  #define XEN_X86_FPU_INITIALISED (1U<<_XEN_X86_FPU_INITIALISED)
> +#define XEN_X86_VMX (1U<<_XEN_X86_VMX)
>  uint32_t flags;
>  uint32_t pad0;
> +
> +/* non-register state */
> +union {
> +/* if flags & XEN_X86_VMX */
> +struct {
> +uint32_t activity_state;
> +uint32_t interruptibility_info;
> +uint64_t pending_dbg;
> +} vmx;
> +};
>  };
> 
> Tamas
> 

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Luca Fancellu]

> On 18 Mar 2022, at 16:12, Julien Grall  wrote:
> 
> Hi Luca,
> 
> I only skimmed through the series. I have one question below:
> 
> On 18/03/2022 15:25, Luca Fancellu wrote:
>> +void __init btcpupools_allocate_pools(void)
>> +{
>> +unsigned int i;
>> +bool add_extra_cpupool = false;
>> +
>> +/*
>> + * If there are no cpupools, the value of next_pool_id is zero, so the 
>> code
>> + * below will assign every cpu to cpupool0 as the default behavior.
>> + * When there are cpupools, the code below is assigning all the not
>> + * assigned cpu to a new pool (next_pool_id value is the last id + 1).
>> + * In the same loop we check if there is any assigned cpu that is not
>> + * online.
>> + */
>> +for ( i = 0; i < nr_cpu_ids; i++ )
>> +if ( cpumask_test_cpu(i, _online_map) )
>> +{
>> +/* Unassigned cpu gets next_pool_id pool id value */
>> +if ( pool_cpu_map[i] < 0 )
>> +{
>> +pool_cpu_map[i] = next_pool_id;
>> +add_extra_cpupool = true;
>> +}
>> +printk(XENLOG_INFO "Logical CPU %u in Pool-%u.\n", i,
>> +   pool_cpu_map[i]);
>> +}
>> +else
>> +{
>> +if ( pool_cpu_map[i] >= 0 )
>> +panic("Pool-%d contains cpu%u that is not online!\n",
>> +  pool_cpu_map[i], i);
>> +}
>> +
>> +if ( add_extra_cpupool )
>> +next_pool_id++;
>> +
>> +/* Create cpupools with selected schedulers */
>> +for ( i = 0; i < next_pool_id; i++ )
>> +cpupool_create_pool(i, pool_sched_map[i]);
>> +
>> +#ifdef CONFIG_X86
>> +/* Cpu0 must be in cpupool0 for x86 */
>> +if ( pool_cpu_map[0] != 0 )
>> +panic("Cpu0 must be in Pool-0\n");
>> +#endif
> 
> Can you document why this is necessary on x86 but not on other architectures?

Hi Julien,

I received the warning by Juergen here: 
https://patchwork.kernel.org/comment/24740762/ that at least on x86 there could 
be
some problems if cpu0 is not in cpupool0, I tested it on arm and it was working 
fine and I didn’t find any restriction.

So I don’t know why on x86 we must have cpu0 in cpupool0, maybe x86 maintainer 
have more knowledge about that and
I can put a comment here.

Cheers,
Luca

> 
> Cheers,
> 
> -- 
> Julien Grall

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Luca Fancellu]

> On 21 Mar 2022, at 09:10, Jan Beulich  wrote:
> 
> On 18.03.2022 16:25, Luca Fancellu wrote:
>> --- a/xen/common/Makefile
>> +++ b/xen/common/Makefile
>> @@ -1,5 +1,6 @@
>> obj-$(CONFIG_ARGO) += argo.o
>> obj-y += bitmap.o
>> +obj-$(CONFIG_BOOT_TIME_CPUPOOLS) += boot_cpupools.o
> 
> By the looks of it you appear to want to specify boot_cpupools.init.o
> here: All functions there are __init and all data is __initdata. That
> was string literals (e.g. as used for printk() invocations) will also
> move to .init.*.
> 
>> --- a/xen/include/xen/sched.h
>> +++ b/xen/include/xen/sched.h
>> @@ -1176,6 +1176,25 @@ extern void cf_check dump_runq(unsigned char key);
>> 
>> void arch_do_physinfo(struct xen_sysctl_physinfo *pi);
>> 
>> +#ifdef CONFIG_BOOT_TIME_CPUPOOLS
>> +void btcpupools_allocate_pools(void);
>> +unsigned int btcpupools_get_cpupool_id(unsigned int cpu);
>> +
>> +#ifdef CONFIG_HAS_DEVICE_TREE
>> +void btcpupools_dtb_parse(void);
>> +#else
>> +static inline void btcpupools_dtb_parse(void) {}
> 
> I think you want to avoid having two stubs for this - one here and ...
> 
>> +#endif
>> +
>> +#else /* !CONFIG_BOOT_TIME_CPUPOOLS */
>> +static inline void btcpupools_allocate_pools(void) {}
>> +static inline void btcpupools_dtb_parse(void) {}
> 
> ... another one here.
> 

Hi Jan,

Thank you for your review, yes I will fix your findings in the next serie.

Cheers,
Luca

> Jan
> 
> 

Re: [PATCH v2] x86/vmx: save guest non-register state in hvm_hw_cpu

[Tamas K Lengyel]

On Mon, Mar 21, 2022 at 10:58 AM Jan Beulich  wrote:
>
> On 21.03.2022 15:39, Tamas K Lengyel wrote:
> > On Mon, Mar 21, 2022 at 8:16 AM Jan Beulich  wrote:
> >> On 17.03.2022 16:57, Tamas K Lengyel wrote:
> >>> @@ -166,6 +167,11 @@ struct hvm_hw_cpu {
> >>>  #define XEN_X86_FPU_INITIALISED (1U<<_XEN_X86_FPU_INITIALISED)
> >>>  uint32_t flags;
> >>>  uint32_t pad0;
> >>> +
> >>> +/* non-register state */
> >>> +uint32_t activity_state;
> >>> +uint32_t interruptibility_state;
> >>> +uint64_t pending_dbg;
> >>>  };
> >>
> >> ... these fields now represent vendor state in a supposedly vendor
> >> independent structure. Besides my wish to see this represented in
> >> field naming (thus at least making provisions for SVM to gain
> >> similar support; perhaps easiest would be to include these in a
> >> sub-structure with a field name of "vmx"), I wonder in how far cross-
> >> vendor migration was taken into consideration. As long as the fields
> >> are zero / ignored, things wouldn't be worse than before your
> >> change, but I think it wants spelling out that the SVM counterpart(s)
> >> may not be added by way of making a VMX/SVM union.
> >
> > I wasn't aware cross-vendor migration is even a thing.
>
> It used to be a thing long ago; it may not work right now for no-one
> testing it.
>
> > But adding a
> > vmx sub-structure seems to me a workable route, we would perhaps just
> > need an extra field that specifies where the fields were taken
> > (vmx/svm) and ignore them if the place where the restore is taking
> > place doesn't match where the save happened. That would be equivalent
> > to how migration works today. Thoughts?
>
> I don't think such a field is needed, at least not right away, as
> long as the respectively other vendor's fields are left zero when
> storing the data. These fields being zero matches current behavior
> of not communicating the values at all. A separate flag might be
> needed if the receiving side would want to "emulate" settings from
> incoming values from the respectively other vendor. Yet even then
> only one of the two sets of fields could potentially be non-zero
> (both being non-zero is an error imo); both fields being zero
> would be compatible both ways. Hence it would be possible to
> determine the source vendor without an extra field even then, I
> would think.
>
> A separate flag would of course be needed if we meant to overlay
> the vendors' data in a union. But as per my earlier reply I think
> we're better off not using a union in this case.

Right, both structs being non-zero at the same time wouldn't make
sense and would indicate corruption of the hvm save file. But I think
the same would easily be achieved by defining a bit on the flags and
then a union. If two vendor bits are set that would indicate an error
without taking up the same with two separate structs. This is what I
have right now and IMHO it looks good
(https://xenbits.xen.org/gitweb/?p=people/tklengyel/xen.git;a=commitdiff;h=84f15b2e1bef6c901bbdf29a07c7904cb365c0b2):

--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -52,6 +52,7 @@ DECLARE_HVM_SAVE_TYPE(HEADER, 1, struct hvm_save_header);
  * Compat:
  * - Pre-3.4 didn't have msr_tsc_aux
  * - Pre-4.7 didn't have fpu_initialised
+ * - Pre-4.17 didn't have non-register state
  */

 struct hvm_hw_cpu {
@@ -163,9 +164,21 @@ struct hvm_hw_cpu {
 uint32_t error_code;

 #define _XEN_X86_FPU_INITIALISED0
+#define _XEN_X86_VMX1
 #define XEN_X86_FPU_INITIALISED (1U<<_XEN_X86_FPU_INITIALISED)
+#define XEN_X86_VMX (1U<<_XEN_X86_VMX)
 uint32_t flags;
 uint32_t pad0;
+
+/* non-register state */
+union {
+/* if flags & XEN_X86_VMX */
+struct {
+uint32_t activity_state;
+uint32_t interruptibility_info;
+uint64_t pending_dbg;
+} vmx;
+};
 };

Tamas

[ovmf test] 168754: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf 267a92fef3b705e6a3ecbeaa4d4b58f7bfac9734
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   21 days
Failing since168258  2022-03-01 01:55:31 Z   20 days  213 attempts
Testing same since   168738  2022-03-21 02:39:18 Z0 days   12 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  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 859 lines long.)

Re: [PATCH] CI: Don't run Coverity on forks

[Roger Pau Monné]

On Mon, Mar 21, 2022 at 01:58:28PM +, Andrew Cooper wrote:
> By default, workflows run in all forks, but the Coverity token is specific to
> us, causing all other runs to fail.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Roger Pau Monné 

Albeit I have a suggestion to make this more useful I think

> ---
> CC: Roger Pau Monné 
> CC: George Dunlap 
> CC: Jan Beulich 
> CC: Stefano Stabellini 
> CC: Wei Liu 
> CC: Julien Grall 
> ---
>  .github/workflows/coverity.yml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/.github/workflows/coverity.yml b/.github/workflows/coverity.yml
> index 427fb86f947f..f613f9ed3652 100644
> --- a/.github/workflows/coverity.yml
> +++ b/.github/workflows/coverity.yml
> @@ -8,6 +8,7 @@ on:
>  
>  jobs:
>coverity:
> +if: github.repository_owner == 'xen-project'

Since I don't know anything else similar, why not make this a secret,
ie: ${{ secrets.RUN_COVERITY_SCAN }}? So that people could decide to
enable coverity on their own repos if desired.

We would also need to introduce a ${{ secrets.COVERITY_SCAN_PROJECT }}

To allow setting a different project name.

Thanks, Roger.

[xen-unstable-smoke test] 168750: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  8aa0e9d2d1a4815516607eabe9b2e850f284a2f8
baseline version:
 xen  fdfb07eb28e42b456e5e1ce999a47cc3ea439f7f

Last test of basis   168701  2022-03-19 05:00:29 Z2 days
Testing same since   168750  2022-03-21 12:00:27 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Luca Fancellu 
  Raphael Ning 

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
   fdfb07eb28..8aa0e9d2d1  8aa0e9d2d1a4815516607eabe9b2e850f284a2f8 -> smoke

Re: [PATCH v2] x86/vmx: save guest non-register state in hvm_hw_cpu

[Jan Beulich]

On 21.03.2022 15:39, Tamas K Lengyel wrote:
> On Mon, Mar 21, 2022 at 8:16 AM Jan Beulich  wrote:
>> On 17.03.2022 16:57, Tamas K Lengyel wrote:
>>> @@ -166,6 +167,11 @@ struct hvm_hw_cpu {
>>>  #define XEN_X86_FPU_INITIALISED (1U<<_XEN_X86_FPU_INITIALISED)
>>>  uint32_t flags;
>>>  uint32_t pad0;
>>> +
>>> +/* non-register state */
>>> +uint32_t activity_state;
>>> +uint32_t interruptibility_state;
>>> +uint64_t pending_dbg;
>>>  };
>>
>> ... these fields now represent vendor state in a supposedly vendor
>> independent structure. Besides my wish to see this represented in
>> field naming (thus at least making provisions for SVM to gain
>> similar support; perhaps easiest would be to include these in a
>> sub-structure with a field name of "vmx"), I wonder in how far cross-
>> vendor migration was taken into consideration. As long as the fields
>> are zero / ignored, things wouldn't be worse than before your
>> change, but I think it wants spelling out that the SVM counterpart(s)
>> may not be added by way of making a VMX/SVM union.
> 
> I wasn't aware cross-vendor migration is even a thing.

It used to be a thing long ago; it may not work right now for no-one
testing it.

> But adding a
> vmx sub-structure seems to me a workable route, we would perhaps just
> need an extra field that specifies where the fields were taken
> (vmx/svm) and ignore them if the place where the restore is taking
> place doesn't match where the save happened. That would be equivalent
> to how migration works today. Thoughts?

I don't think such a field is needed, at least not right away, as
long as the respectively other vendor's fields are left zero when
storing the data. These fields being zero matches current behavior
of not communicating the values at all. A separate flag might be
needed if the receiving side would want to "emulate" settings from
incoming values from the respectively other vendor. Yet even then
only one of the two sets of fields could potentially be non-zero
(both being non-zero is an error imo); both fields being zero
would be compatible both ways. Hence it would be possible to
determine the source vendor without an extra field even then, I
would think.

A separate flag would of course be needed if we meant to overlay
the vendors' data in a union. But as per my earlier reply I think
we're better off not using a union in this case.

Jan

Re: [PATCH v2] x86/vmx: save guest non-register state in hvm_hw_cpu

[Tamas K Lengyel]

On Mon, Mar 21, 2022 at 8:16 AM Jan Beulich  wrote:
>
> On 17.03.2022 16:57, Tamas K Lengyel wrote:
> > During VM forking and resetting a failed vmentry has been observed due
> > to the guest non-register state going out-of-sync with the guest register
> > state. For example, a VM fork reset right after a STI instruction can 
> > trigger
> > the failed entry. This is due to the guest non-register state not being 
> > saved
> > from the parent VM, thus the reset operation only copies the register state.
> >
> > Fix this by including the guest non-register state in hvm_hw_cpu so that 
> > when
> > its copied from the parent VM the vCPU state remains in sync.
> >
> > SVM is not currently wired-in as VM forking is VMX only and saving 
> > non-register
> > state during normal save/restore/migration operation hasn't been needed.
>
> Given that it was pointed out that e.g. STI- and MOV-SS-shadow aren't
> VMX specific and also aren't impossible to hit with ordinary save /
> restore / migrate, I'm not convinced of this argumentation. But of
> course fixing VMX alone is better than nothing. However, ...
>
> > @@ -166,6 +167,11 @@ struct hvm_hw_cpu {
> >  #define XEN_X86_FPU_INITIALISED (1U<<_XEN_X86_FPU_INITIALISED)
> >  uint32_t flags;
> >  uint32_t pad0;
> > +
> > +/* non-register state */
> > +uint32_t activity_state;
> > +uint32_t interruptibility_state;
> > +uint64_t pending_dbg;
> >  };
>
> ... these fields now represent vendor state in a supposedly vendor
> independent structure. Besides my wish to see this represented in
> field naming (thus at least making provisions for SVM to gain
> similar support; perhaps easiest would be to include these in a
> sub-structure with a field name of "vmx"), I wonder in how far cross-
> vendor migration was taken into consideration. As long as the fields
> are zero / ignored, things wouldn't be worse than before your
> change, but I think it wants spelling out that the SVM counterpart(s)
> may not be added by way of making a VMX/SVM union.

I wasn't aware cross-vendor migration is even a thing. But adding a
vmx sub-structure seems to me a workable route, we would perhaps just
need an extra field that specifies where the fields were taken
(vmx/svm) and ignore them if the place where the restore is taking
place doesn't match where the save happened. That would be equivalent
to how migration works today. Thoughts?

Tamas

[ovmf test] 168753: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf 267a92fef3b705e6a3ecbeaa4d4b58f7bfac9734
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   21 days
Failing since168258  2022-03-01 01:55:31 Z   20 days  212 attempts
Testing same since   168738  2022-03-21 02:39:18 Z0 days   11 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  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 859 lines long.)

Re: [PATCH] x86/apic: Fix function typechecking in TSC Deadline errata check

[Jan Beulich]

On 21.03.2022 15:12, Andrew Cooper wrote:
> --- a/xen/arch/x86/apic.c
> +++ b/xen/arch/x86/apic.c
> @@ -1092,12 +1092,17 @@ static void setup_APIC_timer(void)
>  local_irq_restore(flags);
>  }
>  
> +#define DEADLINE_MODEL_FUNCT(m, fn) \
> +{ .vendor = X86_VENDOR_INTEL, .family = 6, .model = (m), \
> +  .feature = X86_FEATURE_TSC_DEADLINE, \
> +  .driver_data = fn + (0 * sizeof(fn == ((unsigned int (*)(void))NULL))) 
> }

Are you sure all compiler versions we support are happy about +
of a function pointer and a constant? Even if that constant is zero,
this is not legal as per the plain C spec.

Also strictly speaking you would want to parenthesize both uses of
fn.

>  #define DEADLINE_MODEL_MATCH(m, fr) \
>  { .vendor = X86_VENDOR_INTEL, .family = 6, .model = (m), \
>.feature = X86_FEATURE_TSC_DEADLINE, \
>.driver_data = (void *)(unsigned long)(fr) }

As long as we leave this in place, there's a (small) risk of the
wrong macro being used again if another hook would need adding here.
We might be safer if driver_data became "unsigned long" and the
void * cast was dropped from here (with an "unsigned long" cast
added in the new macro, which at the same time would address my
other concern above).

Jan

Re: [PATCH] xen/x86/hvm: add missing cf_check for hvm_physdev_op()

[Andrew Cooper]

On 21/03/2022 07:53, Juergen Gross wrote:
> The hypercall handler hvm_physdev_op() is missing a cf_check attribute.
>
> Fixes: cdbe2b0a1aec ("x86: Enable CET Indirect Branch Tracking")
> Signed-off-by: Juergen Gross 

https://lore.kernel.org/xen-devel/20220309152009.10449-1-andrew.coop...@citrix.com/

The only reason I haven't committed it is because I was chasing
someone's bug report against compat_vcpu_op()...

~Andrew

> ---
>  xen/arch/x86/hvm/hypercall.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
> index 030243810e..62b5349e7d 100644
> --- a/xen/arch/x86/hvm/hypercall.c
> +++ b/xen/arch/x86/hvm/hypercall.c
> @@ -78,7 +78,7 @@ static long cf_check hvm_grant_table_op(
>  }
>  #endif
>  
> -static long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> +static long cf_check hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) 
> arg)
>  {
>  const struct vcpu *curr = current;
>  const struct domain *currd = curr->domain;

[PATCH] x86/apic: Fix function typechecking in TSC Deadline errata check

[Andrew Cooper]

Sadly, cf_check typechecking doesn't work through casts.  Introduce an ad-hoc
typecheck and fix *_readline_rev() checks to be cf_check.

This is a latent bug.  The affected models don't have CET-IBT, so won't
actually explode from lacking endbr64 instructions.

Reported-by: Jan Beulich 
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Wei Liu 
---
 xen/arch/x86/apic.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
index 96d73a744964..794bbc21ae2c 100644
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -1092,12 +1092,17 @@ static void setup_APIC_timer(void)
 local_irq_restore(flags);
 }
 
+#define DEADLINE_MODEL_FUNCT(m, fn) \
+{ .vendor = X86_VENDOR_INTEL, .family = 6, .model = (m), \
+  .feature = X86_FEATURE_TSC_DEADLINE, \
+  .driver_data = fn + (0 * sizeof(fn == ((unsigned int (*)(void))NULL))) }
+
 #define DEADLINE_MODEL_MATCH(m, fr) \
 { .vendor = X86_VENDOR_INTEL, .family = 6, .model = (m), \
   .feature = X86_FEATURE_TSC_DEADLINE, \
   .driver_data = (void *)(unsigned long)(fr) }
 
-static unsigned int __init hsx_deadline_rev(void)
+static unsigned int __init cf_check hsx_deadline_rev(void)
 {
 switch ( boot_cpu_data.x86_mask )
 {
@@ -1108,7 +1113,7 @@ static unsigned int __init hsx_deadline_rev(void)
 return ~0U;
 }
 
-static unsigned int __init bdx_deadline_rev(void)
+static unsigned int __init cf_check bdx_deadline_rev(void)
 {
 switch ( boot_cpu_data.x86_mask )
 {
@@ -1121,7 +1126,7 @@ static unsigned int __init bdx_deadline_rev(void)
 return ~0U;
 }
 
-static unsigned int __init skx_deadline_rev(void)
+static unsigned int __init cf_check skx_deadline_rev(void)
 {
 switch ( boot_cpu_data.x86_mask )
 {
@@ -1135,17 +1140,17 @@ static unsigned int __init skx_deadline_rev(void)
 
 static const struct x86_cpu_id __initconstrel deadline_match[] = {
 DEADLINE_MODEL_MATCH(0x3c, 0x22), /* Haswell */
-DEADLINE_MODEL_MATCH(0x3f, hsx_deadline_rev), /* Haswell EP/EX */
+DEADLINE_MODEL_FUNCT(0x3f, hsx_deadline_rev), /* Haswell EP/EX */
 DEADLINE_MODEL_MATCH(0x45, 0x20), /* Haswell D */
 DEADLINE_MODEL_MATCH(0x46, 0x17), /* Haswell H */
 
 DEADLINE_MODEL_MATCH(0x3d, 0x25), /* Broadwell */
 DEADLINE_MODEL_MATCH(0x47, 0x17), /* Broadwell H */
 DEADLINE_MODEL_MATCH(0x4f, 0x0b20),   /* Broadwell EP/EX */
-DEADLINE_MODEL_MATCH(0x56, bdx_deadline_rev), /* Broadwell D */
+DEADLINE_MODEL_FUNCT(0x56, bdx_deadline_rev), /* Broadwell D */
 
 DEADLINE_MODEL_MATCH(0x4e, 0xb2), /* Skylake M */
-DEADLINE_MODEL_MATCH(0x55, skx_deadline_rev), /* Skylake X */
+DEADLINE_MODEL_FUNCT(0x55, skx_deadline_rev), /* Skylake X */
 DEADLINE_MODEL_MATCH(0x5e, 0xb2), /* Skylake D */
 
 DEADLINE_MODEL_MATCH(0x8e, 0x52), /* Kabylake M */
-- 
2.11.0

[ovmf test] 168752: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf 267a92fef3b705e6a3ecbeaa4d4b58f7bfac9734
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   21 days
Failing since168258  2022-03-01 01:55:31 Z   20 days  211 attempts
Testing same since   168738  2022-03-21 02:39:18 Z0 days   10 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  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 859 lines long.)

[PATCH] CI: Don't run Coverity on forks

[Andrew Cooper]

By default, workflows run in all forks, but the Coverity token is specific to
us, causing all other runs to fail.

Signed-off-by: Andrew Cooper 
---
CC: Roger Pau Monné 
CC: George Dunlap 
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Wei Liu 
CC: Julien Grall 
---
 .github/workflows/coverity.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.github/workflows/coverity.yml b/.github/workflows/coverity.yml
index 427fb86f947f..f613f9ed3652 100644
--- a/.github/workflows/coverity.yml
+++ b/.github/workflows/coverity.yml
@@ -8,6 +8,7 @@ on:
 
 jobs:
   coverity:
+if: github.repository_owner == 'xen-project'
 runs-on: ubuntu-latest
 steps:
 - name: Install build dependencies
-- 
2.11.0

Re: [PATCH v2] codeql: add support for analyzing C, Python and Go

[Roger Pau Monné]

On Mon, Mar 21, 2022 at 01:02:30PM +, Andrew Cooper wrote:
> On 21/03/2022 09:54, Roger Pau Monné wrote:
> 
> Ping?
> 
> On Mon, Mar 07, 2022 at 05:45:52PM +0100, Roger Pau Monne wrote:
> 
> 
> Introduce CodeQL support for Xen and analyze the C, Python and Go
> files.
> 
> Note than when analyzing Python or Go we avoid building the hypervisor
> and only build the tools.
> 
> Requested-by: Andrew Cooper 
> 
> Signed-off-by: Roger Pau Monné 
> 
> ---
> Changes since v1:
>  - Rename to note it's x86 specific right now.
>  - Merge the ignored path patch.
> ---
> It's my understanding that we need to force the checkout action to
> fetch 'staging' branch, or else for the scheduled runs we would end up
> picking the current default branch (master).
> 
> Forcing to staging necessary due to a limitation in Coverity.
> 
> CodeQL explicitly can cope with multiple branches, so when a user asks for a 
> specific branch, they'd better get a run on the branch they asked for, not 
> have it forced to staging.
> 
> It also breaks any fork which has a different default branch.
> 
> 
> 
> 
> Maybe we want to remove the scheduled action and just rely on pushes
> and manually triggered workflows?
> ---
>  .github/codeql/codeql-config.yml |  3 ++
>  .github/workflows/codeql-x86.yml | 60 
>  2 files changed, 63 insertions(+)
>  create mode 100644 .github/codeql/codeql-config.yml
>  create mode 100644 .github/workflows/codeql-x86.yml
> 
> diff --git a/.github/codeql/codeql-config.yml 
> b/.github/codeql/codeql-config.yml
> new file mode 100644
> index 00..721640c2a5
> --- /dev/null
> +++ b/.github/codeql/codeql-config.yml
> @@ -0,0 +1,3 @@
> +paths-ignore:
> +  - xen/tools/kconfig
> +  - tools/firmware/xen-dir/xen-root/xen/tools/kconfig
> 
> From actually running this:
> 
> Annotations
> 2 warnings
> analyse (go)
> The "paths"/"paths-ignore" fields of the config only have effect for 
> JavaScript, Python, and Ruby
> analyse (cpp)
> The "paths"/"paths-ignore" fields of the config only have effect for 
> JavaScript, Python, and Ruby
> 
> So this obviously can't be used like this.  You'll have to add them to the 
> prebuild step.

Right, paths-ignore can only be used for interpreted languages, so
not really useful in order to ignore the content in Kconfig.

Pre-building the Kconfig in tools/firmware/ will be complicated. I
will leave ignoring those paths to a further patch, we can always
filter from the queries.

Thanks, Roger.

[ovmf test] 168751: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf 267a92fef3b705e6a3ecbeaa4d4b58f7bfac9734
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   21 days
Failing since168258  2022-03-01 01:55:31 Z   20 days  210 attempts
Testing same since   168738  2022-03-21 02:39:18 Z0 days9 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  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 859 lines long.)

Re: [PATCH] x86/build: work around older GNU ld not leaving .got.plt empty

[Julien Grall]

Hi Jan,

On 21/03/2022 11:46, Jan Beulich wrote:

The initial three entries in .got.plt are "static", i.e. present
independent of actual entries allocation of which is triggered by
respective relocations. When no real entries are needed, halfway recent
ld discards the "static" portion of the table as well, but older GNU ld
fails to do so.

Fixes: dedb0aa42c6d ("x86/build: use --orphan-handling linker option if 
available")
Reported-by: Julien Grall 
Signed-off-by: Jan Beulich 


Thanks for the patch. I applied the patch and can confirm the build 
issue is gone.


Tested-by: Julien Grall 

Cheers,

--
Julien Grall

Re: [PATCH v2] codeql: add support for analyzing C, Python and Go

[Andrew Cooper]

On 21/03/2022 09:54, Roger Pau Monné wrote:

Ping?

On Mon, Mar 07, 2022 at 05:45:52PM +0100, Roger Pau Monne wrote:


Introduce CodeQL support for Xen and analyze the C, Python and Go
files.

Note than when analyzing Python or Go we avoid building the hypervisor
and only build the tools.

Requested-by: Andrew Cooper 

Signed-off-by: Roger Pau Monné 

---
Changes since v1:
 - Rename to note it's x86 specific right now.
 - Merge the ignored path patch.
---
It's my understanding that we need to force the checkout action to
fetch 'staging' branch, or else for the scheduled runs we would end up
picking the current default branch (master).

Forcing to staging necessary due to a limitation in Coverity.

CodeQL explicitly can cope with multiple branches, so when a user asks for a 
specific branch, they'd better get a run on the branch they asked for, not have 
it forced to staging.

It also breaks any fork which has a different default branch.




Maybe we want to remove the scheduled action and just rely on pushes
and manually triggered workflows?
---
 .github/codeql/codeql-config.yml |  3 ++
 .github/workflows/codeql-x86.yml | 60 
 2 files changed, 63 insertions(+)
 create mode 100644 .github/codeql/codeql-config.yml
 create mode 100644 .github/workflows/codeql-x86.yml

diff --git a/.github/codeql/codeql-config.yml b/.github/codeql/codeql-config.yml
new file mode 100644
index 00..721640c2a5
--- /dev/null
+++ b/.github/codeql/codeql-config.yml
@@ -0,0 +1,3 @@
+paths-ignore:
+  - xen/tools/kconfig
+  - tools/firmware/xen-dir/xen-root/xen/tools/kconfig

From actually running this:

Annotations
2 warnings
analyse (go)
The "paths"/"paths-ignore" fields of the config only have effect for 
JavaScript, Python, and Ruby
analyse (cpp)
The "paths"/"paths-ignore" fields of the config only have effect for 
JavaScript, Python, and Ruby

So this obviously can't be used like this.  You'll have to add them to the 
prebuild step.



diff --git a/.github/workflows/codeql-x86.yml b/.github/workflows/codeql-x86.yml
new file mode 100644
index 00..a3ec6236c4
--- /dev/null
+++ b/.github/workflows/codeql-x86.yml
@@ -0,0 +1,60 @@
+name: CodeQL x86
+
+on:
+  workflow_dispatch:
+  push:
+branches: [staging]
+  schedule:
+- cron: '18 10 * * WED,SUN' # Bi-weekly at 10:18 UTC
+
+jobs:
+  analyse:
+
+strategy:
+  matrix:
+language: [ 'cpp', 'python', 'go' ]
+
+runs-on: ubuntu-latest
+
+steps:
+- name: Install build dependencies
+  run: |
+sudo apt-get install -y wget git \
+  libbz2-dev build-essential \
+  zlib1g-dev libncurses5-dev iasl \
+  libbz2-dev e2fslibs-dev uuid-dev libyajl-dev \
+  autoconf libtool liblzma-dev \
+  python3-dev golang python-dev libsystemd-dev
+
+- uses: actions/checkout@v2
+  with:
+ref: staging
+
+- name: Configure Xen
+  run: |
+./configure --with-system-qemu=/bin/true \
+--with-system-seabios=/bin/true \
+--with-system-ovmf=/bin/true
+
+- name: Pre build stuff
+  run: |
+make -j`nproc` mini-os-dir
+
+- uses: github/codeql-action/init@v1
+  with:
+config-file: ./.github/codeql/codeql-config.yml
+languages: ${{matrix.language}}
+queries: security-and-quality

This generates 1117 alerts, lots of which are of dubious utility.  I'd drop the 
queries line and go with the default, to reduce the triage initially.

~Andrew



+
+- if: matrix.language == 'cpp'
+  name: Full Build
+  run: |
+make -j`nproc` build-xen build-tools
+make -j`nproc` -C extras/mini-os/
+
+- if: matrix.language == 'python' || matrix.language == 'go'
+  name: Tools Build
+  run: |
+make -j`nproc` build-tools
+
+- uses: github/codeql-action/analyze@v1
--
2.34.1

Re: [PATCH 1/1] xen/blkfront: fix comment for need_copy

[Jens Axboe]

On Thu, 17 Mar 2022 15:09:30 -0700, Dongli Zhang wrote:
> The 'need_copy' is set when rq_data_dir(req) returns WRITE, in order to
> copy the written data to persistent page.
> 
> ".need_copy = rq_data_dir(req) && info->feature_persistent,"
> 
> 

Applied, thanks!

[1/1] xen/blkfront: fix comment for need_copy
  commit: 08719dd9176b4c55f547bd11812fd6cc35907d37

Best regards,
-- 
Jens Axboe

Re: [PATCH] xen-blkback: remove redundant assignment to variable i

[Jens Axboe]

On Thu, 17 Mar 2022 23:46:46 +, Colin Ian King wrote:
> Variable i is being assigned a value that is never read, it is being
> re-assigned later in a for-loop. The assignment is redundant and can
> be removed.
> 
> Cleans up clang scan build warning:
> drivers/block/xen-blkback/blkback.c:934:14: warning: Although the value
> stored to 'i' is used in the enclosing expression, the value is never
> actually read from 'i' [deadcode.DeadStores]
> 
> [...]

Applied, thanks!

[1/1] xen-blkback: remove redundant assignment to variable i
  commit: 93b4e74789dbdefcffc7baac107069e74d98513c

Best regards,
-- 
Jens Axboe

Re: [PATCH] x86/build: work around older GNU ld not leaving .got.plt empty

[Jan Beulich]

On 21.03.2022 12:57, Roger Pau Monné wrote:
> On Mon, Mar 21, 2022 at 12:46:54PM +0100, Jan Beulich wrote:
>> The initial three entries in .got.plt are "static", i.e. present
>> independent of actual entries allocation of which is triggered by
>> respective relocations. When no real entries are needed, halfway recent
>> ld discards the "static" portion of the table as well, but older GNU ld
>> fails to do so.
> 
> Do you know what this 'static' entries refer to?

I didn't take the time to look this up, and I don't know off the top of
my head.

>> Fixes: dedb0aa42c6d ("x86/build: use --orphan-handling linker option if 
>> available")
>> Reported-by: Julien Grall 
>> Signed-off-by: Jan Beulich 
> 
> Reviewed-by: Roger Pau Monné 

Thanks.

Jan

Re: [PATCH v2] x86/vmx: save guest non-register state in hvm_hw_cpu

[Jan Beulich]

On 17.03.2022 16:57, Tamas K Lengyel wrote:
> During VM forking and resetting a failed vmentry has been observed due
> to the guest non-register state going out-of-sync with the guest register
> state. For example, a VM fork reset right after a STI instruction can trigger
> the failed entry. This is due to the guest non-register state not being saved
> from the parent VM, thus the reset operation only copies the register state.
> 
> Fix this by including the guest non-register state in hvm_hw_cpu so that when
> its copied from the parent VM the vCPU state remains in sync.
> 
> SVM is not currently wired-in as VM forking is VMX only and saving 
> non-register
> state during normal save/restore/migration operation hasn't been needed.

Given that it was pointed out that e.g. STI- and MOV-SS-shadow aren't
VMX specific and also aren't impossible to hit with ordinary save /
restore / migrate, I'm not convinced of this argumentation. But of
course fixing VMX alone is better than nothing. However, ...

> @@ -166,6 +167,11 @@ struct hvm_hw_cpu {
>  #define XEN_X86_FPU_INITIALISED (1U<<_XEN_X86_FPU_INITIALISED)
>  uint32_t flags;
>  uint32_t pad0;
> +
> +/* non-register state */
> +uint32_t activity_state;
> +uint32_t interruptibility_state;
> +uint64_t pending_dbg;
>  };

... these fields now represent vendor state in a supposedly vendor
independent structure. Besides my wish to see this represented in
field naming (thus at least making provisions for SVM to gain
similar support; perhaps easiest would be to include these in a
sub-structure with a field name of "vmx"), I wonder in how far cross-
vendor migration was taken into consideration. As long as the fields
are zero / ignored, things wouldn't be worse than before your
change, but I think it wants spelling out that the SVM counterpart(s)
may not be added by way of making a VMX/SVM union.

Jan

[ovmf test] 168749: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf 267a92fef3b705e6a3ecbeaa4d4b58f7bfac9734
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   21 days
Failing since168258  2022-03-01 01:55:31 Z   20 days  209 attempts
Testing same since   168738  2022-03-21 02:39:18 Z0 days8 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  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 859 lines long.)

Re: [PATCH] x86/build: also handle .comment.* in linker script

[Roger Pau Monné]

On Mon, Mar 21, 2022 at 12:47:27PM +0100, Jan Beulich wrote:
> Oldish SUSE compilers generate .comment.SUSE.OPTS sections. Just like we
> already discard such for xen.efi, fold them into .comment for xen-syms.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Roger Pau Monné 

> ---
> Just like for .comment itself I also wouldn't mind discarding these also
> for the non-EFI case.

I guess there's a reason for compilers to add additional comments, and
we shouldn't discard those randomly?

In any case they won't be loaded, so I don't see much issue with
having them on the binary image.

Thanks, Roger.

Re: [PATCH] x86/build: work around older GNU ld not leaving .got.plt empty

[Roger Pau Monné]

On Mon, Mar 21, 2022 at 12:46:54PM +0100, Jan Beulich wrote:
> The initial three entries in .got.plt are "static", i.e. present
> independent of actual entries allocation of which is triggered by
> respective relocations. When no real entries are needed, halfway recent
> ld discards the "static" portion of the table as well, but older GNU ld
> fails to do so.

Do you know what this 'static' entries refer to?

> Fixes: dedb0aa42c6d ("x86/build: use --orphan-handling linker option if 
> available")
> Reported-by: Julien Grall 
> Signed-off-by: Jan Beulich 

Reviewed-by: Roger Pau Monné 

Thanks, Roger.

[PATCH] x86/build: also handle .comment.* in linker script

[Jan Beulich]

Oldish SUSE compilers generate .comment.SUSE.OPTS sections. Just like we
already discard such for xen.efi, fold them into .comment for xen-syms.

Signed-off-by: Jan Beulich 
---
Just like for .comment itself I also wouldn't mind discarding these also
for the non-EFI case.

--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -454,7 +454,7 @@ SECTIONS
   .stab.exclstr 0 : { *(.stab.exclstr) }
   .stab.index 0 : { *(.stab.index) }
   .stab.indexstr 0 : { *(.stab.indexstr) }
-  .comment 0 : { *(.comment) }
+  .comment 0 : { *(.comment) *(.comment.*) }
   /*
* LLVM ld also wants .symtab, .strtab, and .shstrtab placed. These look to
* be benign to GNU ld, so we can have them here unconditionally.

[PATCH] x86/build: work around older GNU ld not leaving .got.plt empty

[Jan Beulich]

The initial three entries in .got.plt are "static", i.e. present
independent of actual entries allocation of which is triggered by
respective relocations. When no real entries are needed, halfway recent
ld discards the "static" portion of the table as well, but older GNU ld
fails to do so.

Fixes: dedb0aa42c6d ("x86/build: use --orphan-handling linker option if 
available")
Reported-by: Julien Grall 
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -497,7 +497,13 @@ ASSERT(IS_ALIGNED(__bss_end,8),
 
 #ifndef EFI
 ASSERT(!SIZEOF(.got),  ".got non-empty")
-ASSERT(!SIZEOF(.got.plt),  ".got.plt non-empty")
+/*
+ * At least GNU ld 2.30 and earlier fail to discard the generic part of
+ * .got.plt when no actual entries were allocated. Permit this case alongside
+ * the section being empty.
+ */
+ASSERT(!SIZEOF(.got.plt) || SIZEOF(.got.plt) == 3 * 8,
+   "unexpected .got.plt size")
 ASSERT(!SIZEOF(.igot.plt), ".igot.plt non-empty")
 ASSERT(!SIZEOF(.iplt), ".iplt non-empty")
 ASSERT(!SIZEOF(.plt),  ".plt non-empty")

[ovmf test] 168748: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf 267a92fef3b705e6a3ecbeaa4d4b58f7bfac9734
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   21 days
Failing since168258  2022-03-01 01:55:31 Z   20 days  208 attempts
Testing same since   168738  2022-03-21 02:39:18 Z0 days7 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  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 859 lines long.)

[xen-unstable test] 168737: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail pass in 168722
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 
168722

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168722
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 168722
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 168722
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 168722
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 168722
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 168722
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 168722
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 168722
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 168722
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 168722
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 168722
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168722
 test-arm64-arm64-xl-seattle  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  16 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-vhd  14 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-vhd  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass
 

Re: [PATCH 1/3] xen: Introduce a header to store common linker scripts content

[Michal Orzel]

Hi Jan,

On 21.03.2022 11:23, Jan Beulich wrote:
> Note: please properly quote your replies. As you'll see what you said
> in reply to my remarks is not properly separated from my remarks, and
> hence hard to read.
> 
Sorry about that. I had some issues with my e-mail client and had to use the 
non-default one.

> On 21.03.2022 11:14, Michal Orzel wrote:
>> On 21.03.2022 09:21, Michal Orzel wrote:
>>> --- /dev/null
>>> +++ b/xen/include/xen/xen_lds.h
>>> @@ -0,0 +1,114 @@
>>> +#ifndef __XEN_LDS_H__
>>> +#define __XEN_LDS_H__
>>> +
>>> +/*
>>> + * Common macros to be used in architecture specific linker scripts.
>>> + */
>>> +
>>> +/* Macros to declare debug sections. */
>>> +#ifdef EFI
>>> +/*
>>> + * Use the NOLOAD directive, despite currently ignored by (at least) GNU ld
>>> + * for PE output, in order to record that we'd prefer these sections to not
>>> + * be loaded into memory.
>>> + */
>>> +#define DECL_DEBUG(x, a) #x ALIGN(a) (NOLOAD) : { *(x) }
>>> +#define DECL_DEBUG2(x, y, a) #x ALIGN(a) (NOLOAD) : { *(x) *(y) }
>>> +#else
>>> +#define DECL_DEBUG(x, a) #x 0 : { *(x) }
>>> +#define DECL_DEBUG2(x, y, a) #x 0 : { *(x) *(y) }
>>> +#endif
>>> +
>>> +/* DWARF debug sections. */
>>> +#define DWARF_DEBUG_SECTIONS  \
>>> +  DECL_DEBUG(.debug_abbrev, 1)    \
>>> +  DECL_DEBUG2(.debug_info, .gnu.linkonce.wi.*, 1) \
>>> +  DECL_DEBUG(.debug_types, 1) \
>>> +  DECL_DEBUG(.debug_str, 1)   \
>>> +  DECL_DEBUG2(.debug_line, .debug_line.*, 1)  \
>>> +  DECL_DEBUG(.debug_line_str, 1)  \
>>> +  DECL_DEBUG(.debug_names, 4) \
>>> +  DECL_DEBUG(.debug_frame, 4) \
>>> +  DECL_DEBUG(.debug_loc, 1)   \
>>> +  DECL_DEBUG(.debug_loclists, 4)  \
>>> +  DECL_DEBUG(.debug_macinfo, 1)   \
>>> +  DECL_DEBUG(.debug_macro, 1) \
>>> +  DECL_DEBUG(.debug_ranges, 8)    \
>>> +  DECL_DEBUG(.debug_rnglists, 4)  \
>>> +  DECL_DEBUG(.debug_addr, 8)  \
>>> +  DECL_DEBUG(.debug_aranges, 1)   \
>>> +  DECL_DEBUG(.debug_pubnames, 1)  \
>>> +  DECL_DEBUG(.debug_pubtypes, 1)
>>> +
>>> +/*
>>> + * Stabs debug sections.
>>> + *
>>> + * LLVM ld also wants .symtab, .strtab, and .shstrtab placed. These look to
>>> + * be benign to GNU ld, so we can have them here unconditionally.
>>> + */
>>> +#define STABS_DEBUG_SECTIONS \
>>> +  .stab 0 : { *(.stab) } \
>>> +  .stabstr 0 : { *(.stabstr) }   \
>>> +  .stab.excl 0 : { *(.stab.excl) }   \
>>> +  .stab.exclstr 0 : { *(.stab.exclstr) } \
>>> +  .stab.index 0 : { *(.stab.index) } \
>>> +  .stab.indexstr 0 : { *(.stab.indexstr) }   \
>>> +  .comment 0 : { *(.comment) }   \
>>> +  .symtab 0 : { *(.symtab) } \
>>> +  .strtab 0 : { *(.strtab) } \
>>> +  .shstrtab 0 : { *(.shstrtab) }
>>
>> Please don't add non-Stabs sections to this macro.
>>
>> Ok, I will add a new macro storing the last 4 sections called 
>> ELF_DETAILS_SECTIONS,
>> to be coherent with what Linux does (ELF_DETAILS).
>>
>>> +#ifdef EFI
>>> +#define DISCARD_EFI_SECTIONS \
>>> +   *(.comment)   \
>>> +   *(.comment.*) \
>>> +   *(.note.*)
>>> +#else
>>> +#define DISCARD_EFI_SECTIONS
>>> +#endif
>>> +
>>> +/* Sections to be discarded. */
>>> +#define DISCARD_SECTIONS \
>>> +  /DISCARD/ : {  \
>>> +   *(.text.exit) \
>>> +   *(.exit.text) \
>>> +   *(.exit.data) \
>>> +   *(.exitcall.exit) \
>>> +   *(.discard)   \
>>> +   *(.discard.*) \
>>> +   *(.eh_frame)  \
>>> +   *(.dtors) \
>>> +   *(.dtors.*)   \
>>> +   *(.fini_array)    \
>>> +   *(.fini_array.*)  \
>>> +   DISCARD_EFI_SECTIONS  \
>>> +  }
>>> +
>>> +#define CTORS_SECTION   \
>>> +   . = ALIGN(8);    \
>>> +   __ctors_start = .;   \
>>> +   *(SORT_BY_INIT_PRIORITY(.init_array.*))  \
>>> +   *(SORT_BY_INIT_PRIORITY(.ctors.*))   \
>>> +   *(.init_array)   \
>>> +   *(.ctors)    \
>>> +   __ctors_end = .;
>>> +
>>> +#define VPCI_SECTION \
>>> +   . = ALIGN(POINTER_ALIGN); \
>>> +   __start_vpci_array = .;   \
>>> +   *(SORT(.data.vpci.*)) \
>>> +   __end_vpci_array = .;
>>> +
>>> +#define HYPFS_SECTION    \
>>> +   . = ALIGN(8); \
>>> +   __paramhypfs_start = .;   \
>>> +   *(.data.paramhypfs)   \
>>> +   __paramhypfs_end = .;
>>> +
>>> +#define LOCK_PROFILE_SECTION \
>>> +   . = ALIGN(POINTER_ALIGN); \
>>> +   __lock_profile_start = .; \
>>> +   *(.lockprofile.data)  \
>>> +   

[ovmf test] 168747: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf 267a92fef3b705e6a3ecbeaa4d4b58f7bfac9734
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   21 days
Failing since168258  2022-03-01 01:55:31 Z   20 days  207 attempts
Testing same since   168738  2022-03-21 02:39:18 Z0 days6 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  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 859 lines long.)

Re: [PATCH RESEND 2/2] gitlab-ci: add an ARM32 qemu-based smoke test

[Anthony PERARD]

On Fri, Mar 18, 2022 at 05:15:06PM -0700, Stefano Stabellini wrote:
> On Fri, 18 Mar 2022, Anthony PERARD wrote:
> > On Wed, Mar 16, 2022 at 06:38:53PM -0700, Stefano Stabellini wrote:
> > > Also considering the recent arm32 xen breakage, which could have been
> > > caught by gitlab-ci before commit,
> > 
> > I'm not sure that's true. I think the commits you are speaking about
> > also break the build on x86, which was caught by the gitlab ci.
> > 
> > Anyway, some arm32 smoke tests on gitlab should be useful.
> 
> I think we are probably talking about different breakages :-)
> 
> Ayan recently broke Xen on ARM32 (run-time not build-time) with the
> commit 9e5a68a66 and fef5531fd. I verified that the QEMU32 test in this
> series actually catches the failure.

See the pipeline on this commit:
https://gitlab.com/xen-project/xen/-/commit/fef5531fd
https://gitlab.com/xen-project/xen/-/pipelines/491963118

;-)

-- 
Anthony PERARD

[ovmf test] 168746: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf 267a92fef3b705e6a3ecbeaa4d4b58f7bfac9734
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   20 days
Failing since168258  2022-03-01 01:55:31 Z   20 days  206 attempts
Testing same since   168738  2022-03-21 02:39:18 Z0 days5 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  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 859 lines long.)

Re: [PATCH 1/1] xen/blkfront: fix comment for need_copy

[Juergen Gross]

On 21.03.22 11:05, Roger Pau Monné wrote:

On Thu, Mar 17, 2022 at 03:09:30PM -0700, Dongli Zhang wrote:

The 'need_copy' is set when rq_data_dir(req) returns WRITE, in order to
copy the written data to persistent page.

".need_copy = rq_data_dir(req) && info->feature_persistent,"


I would also add:

Fixes: c004a6fe0c40 ('block/xen-blkfront: Make it running on 64KB page 
granularity')


Hmm, a "Fixes:" tag for a change in a comment?

This might generate additional work e.g. for downstreams (we at SUSE have
scripts checking "Fixes:" tags and require such changes to be applied to
kernels having the fixed patch applied).

That said I'd prefer not having a "Fixes:" tag for such changes, but maybe
this is just due to the fact that it would be me having to apply this
patch to the SUSE kernels...


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH 4/4] livepatch: differentiate between old and new build systems

[Roger Pau Monné]

On Fri, Mar 11, 2022 at 09:33:15AM +0100, Roger Pau Monné wrote:
> On Thu, Mar 10, 2022 at 06:01:48PM +, Andrew Cooper wrote:
> > On 08/03/2022 14:52, Roger Pau Monne wrote:
> > > On Tue, Mar 08, 2022 at 02:38:47PM +, Andrew Cooper wrote:
> > >> On 02/03/2022 14:27, Roger Pau Monne wrote:
> > >>> diff --git a/livepatch-build b/livepatch-build
> > >>> index 38a92be..656cdac 100755
> > >>> --- a/livepatch-build
> > >>> +++ b/livepatch-build
> > >>> @@ -98,14 +98,20 @@ function build_special()
> > >>>  
> > >>>  # Build with special GCC flags
> > >>>  cd "${SRCDIR}/xen" || die
> > >>> -sed -i 's/CFLAGS += -nostdinc/CFLAGS += -nostdinc 
> > >>> -ffunction-sections -fdata-sections/' Rules.mk
> > >>> -cp -p arch/x86/Makefile arch/x86/Makefile.bak
> > >>> -sed -i 
> > >>> 's/--section-alignment=0x20/--section-alignment=0x1000/' 
> > >>> arch/x86/Makefile
> > >>> -# Restore timestamps to prevent spurious rebuilding
> > >>> -touch --reference=arch/x86/Makefile.bak arch/x86/Makefile
> > >>> -make "-j$CPUS" $XEN_DEBUG &> "${OUTPUT}/build_${name}_compile.log" 
> > >>> || die
> > >>> -sed -i 's/CFLAGS += -nostdinc -ffunction-sections 
> > >>> -fdata-sections/CFLAGS += -nostdinc/' Rules.mk
> > >>> -mv -f arch/x86/Makefile.bak arch/x86/Makefile
> > >>> +if grep -q 'nostdinc' Rules.mk; then
> > >>> + # Support for old build system, attempt to set 
> > >>> -f{function,data}-sections and rebuild
> > >>> +sed -i 's/CFLAGS += -nostdinc/CFLAGS += -nostdinc 
> > >>> -ffunction-sections -fdata-sections/' Rules.mk
> > >>> +cp -p arch/x86/Makefile arch/x86/Makefile.bak
> > >>> +sed -i 
> > >>> 's/--section-alignment=0x20/--section-alignment=0x1000/' 
> > >>> arch/x86/Makefile
> > >>> +# Restore timestamps to prevent spurious rebuilding
> > >>> +touch --reference=arch/x86/Makefile.bak arch/x86/Makefile
> > >>> +make "-j$CPUS" $XEN_DEBUG &> 
> > >>> "${OUTPUT}/build_${name}_compile.log" || die
> > >>> +sed -i 's/CFLAGS += -nostdinc -ffunction-sections 
> > >>> -fdata-sections/CFLAGS += -nostdinc/' Rules.mk
> > >>> +mv -f arch/x86/Makefile.bak arch/x86/Makefile
> > >>> +else
> > >>> +# -f{function,data}-sections set by CONFIG_LIVEPATCH
> > >>> +make "-j$CPUS" $XEN_DEBUG &> 
> > >>> "${OUTPUT}/build_${name}_compile.log" || die
> > >>> +fi
> > >> This really ought to be the other way around, by spotting the thing we
> > >> know is good, and then falling back to the heuristics.  In light of the
> > >> updates to the Xen side, something like:
> > > I'm not sure I agree. I do prefer to spot the 'bad' one, and just
> > > fallback to expecting Xen to correctly set -f{function,data}-sections
> > > otherwise.
> > >
> > >> if grep -q CC_SPLIT_SECTIONS Kconfig; then
> > > Because this logic ties us to not moving CC_SPLIT_SECTIONS from being
> > > defined in xen/Kconfig (or even changing it's name), and gain ties the
> > > livepatch tools to internal details about the Xen build system.
> > 
> > It doesn't particularly matter which way around the if/else is.  It does
> > matter that we're choosing based on something relevant.
> > 
> > nostdinc in Rules.mk has exactly the same amount of "magic string in
> > magic file" as CC_SPLIT_SECTIONS in Kconfig, but has absolutely nothing
> > to do with the property we actually care about.
> > 
> > Really what you actually want is
> > 
> > if grep -q CC_SPLIT_SECTIONS Kconfig; then
> >     # Xen behaves sensibly
> > elif grep -q 'nostdinc' Rules.mk; then
> >     # Legacy mess with Rules.mk
> > else
> >     die "Help with build system divination"
> > fi
> > 
> > The "behaves sensibly" case is unlikely to change name and unlikely to
> > move locations, but each are easy to cope with via `grep -e FOO -e BAR
> > file1 file2`, and this approach avoids the problem of blindly (and
> > falsely) assuming that anything which is 4.14 and later splits sections
> > correctly, and that this will remain true even when someone adds "# use
> > to have -nostdinc here" to Rules.mk.
> 
> TBH, I don't find the proposed solution is much better to what's in
> this patch, and as said I really dislike tying the behavior of the
> livepatch build tools to heuristics against Xen internal build files -
> be it a Kconfig or a Makefile. Specially because your proposed
> approach adds heuristics to detect the 'good' case which should be the
> default one going forward.
> 
> A better option might be to just make the 'build adjustments' a
> command line option that the user can pass to the tools, ie:
> --build-adjust and let the user decide whether it needs the
> adjustments or not. If I was a livepatch user myself I would seriously
> consider picking the linker script changes and backport that to my
> production version.

Ping?

Is the proposed command line option an acceptable way to move this
forward?

Can I have an opinion from the maintainers?

Thanks, Roger.

Re: [PATCH 1/3] xen: Introduce a header to store common linker scripts content

[Jan Beulich]

Note: please properly quote your replies. As you'll see what you said
in reply to my remarks is not properly separated from my remarks, and
hence hard to read.

On 21.03.2022 11:14, Michal Orzel wrote:
> On 21.03.2022 09:21, Michal Orzel wrote:
>> --- /dev/null
>> +++ b/xen/include/xen/xen_lds.h
>> @@ -0,0 +1,114 @@
>> +#ifndef __XEN_LDS_H__
>> +#define __XEN_LDS_H__
>> +
>> +/*
>> + * Common macros to be used in architecture specific linker scripts.
>> + */
>> +
>> +/* Macros to declare debug sections. */
>> +#ifdef EFI
>> +/*
>> + * Use the NOLOAD directive, despite currently ignored by (at least) GNU ld
>> + * for PE output, in order to record that we'd prefer these sections to not
>> + * be loaded into memory.
>> + */
>> +#define DECL_DEBUG(x, a) #x ALIGN(a) (NOLOAD) : { *(x) }
>> +#define DECL_DEBUG2(x, y, a) #x ALIGN(a) (NOLOAD) : { *(x) *(y) }
>> +#else
>> +#define DECL_DEBUG(x, a) #x 0 : { *(x) }
>> +#define DECL_DEBUG2(x, y, a) #x 0 : { *(x) *(y) }
>> +#endif
>> +
>> +/* DWARF debug sections. */
>> +#define DWARF_DEBUG_SECTIONS  \
>> +  DECL_DEBUG(.debug_abbrev, 1)    \
>> +  DECL_DEBUG2(.debug_info, .gnu.linkonce.wi.*, 1) \
>> +  DECL_DEBUG(.debug_types, 1) \
>> +  DECL_DEBUG(.debug_str, 1)   \
>> +  DECL_DEBUG2(.debug_line, .debug_line.*, 1)  \
>> +  DECL_DEBUG(.debug_line_str, 1)  \
>> +  DECL_DEBUG(.debug_names, 4) \
>> +  DECL_DEBUG(.debug_frame, 4) \
>> +  DECL_DEBUG(.debug_loc, 1)   \
>> +  DECL_DEBUG(.debug_loclists, 4)  \
>> +  DECL_DEBUG(.debug_macinfo, 1)   \
>> +  DECL_DEBUG(.debug_macro, 1) \
>> +  DECL_DEBUG(.debug_ranges, 8)    \
>> +  DECL_DEBUG(.debug_rnglists, 4)  \
>> +  DECL_DEBUG(.debug_addr, 8)  \
>> +  DECL_DEBUG(.debug_aranges, 1)   \
>> +  DECL_DEBUG(.debug_pubnames, 1)  \
>> +  DECL_DEBUG(.debug_pubtypes, 1)
>> +
>> +/*
>> + * Stabs debug sections.
>> + *
>> + * LLVM ld also wants .symtab, .strtab, and .shstrtab placed. These look to
>> + * be benign to GNU ld, so we can have them here unconditionally.
>> + */
>> +#define STABS_DEBUG_SECTIONS \
>> +  .stab 0 : { *(.stab) } \
>> +  .stabstr 0 : { *(.stabstr) }   \
>> +  .stab.excl 0 : { *(.stab.excl) }   \
>> +  .stab.exclstr 0 : { *(.stab.exclstr) } \
>> +  .stab.index 0 : { *(.stab.index) } \
>> +  .stab.indexstr 0 : { *(.stab.indexstr) }   \
>> +  .comment 0 : { *(.comment) }   \
>> +  .symtab 0 : { *(.symtab) } \
>> +  .strtab 0 : { *(.strtab) } \
>> +  .shstrtab 0 : { *(.shstrtab) }
> 
> Please don't add non-Stabs sections to this macro.
> 
> Ok, I will add a new macro storing the last 4 sections called 
> ELF_DETAILS_SECTIONS,
> to be coherent with what Linux does (ELF_DETAILS).
> 
>> +#ifdef EFI
>> +#define DISCARD_EFI_SECTIONS \
>> +   *(.comment)   \
>> +   *(.comment.*) \
>> +   *(.note.*)
>> +#else
>> +#define DISCARD_EFI_SECTIONS
>> +#endif
>> +
>> +/* Sections to be discarded. */
>> +#define DISCARD_SECTIONS \
>> +  /DISCARD/ : {  \
>> +   *(.text.exit) \
>> +   *(.exit.text) \
>> +   *(.exit.data) \
>> +   *(.exitcall.exit) \
>> +   *(.discard)   \
>> +   *(.discard.*) \
>> +   *(.eh_frame)  \
>> +   *(.dtors) \
>> +   *(.dtors.*)   \
>> +   *(.fini_array)    \
>> +   *(.fini_array.*)  \
>> +   DISCARD_EFI_SECTIONS  \
>> +  }
>> +
>> +#define CTORS_SECTION   \
>> +   . = ALIGN(8);    \
>> +   __ctors_start = .;   \
>> +   *(SORT_BY_INIT_PRIORITY(.init_array.*))  \
>> +   *(SORT_BY_INIT_PRIORITY(.ctors.*))   \
>> +   *(.init_array)   \
>> +   *(.ctors)    \
>> +   __ctors_end = .;
>> +
>> +#define VPCI_SECTION \
>> +   . = ALIGN(POINTER_ALIGN); \
>> +   __start_vpci_array = .;   \
>> +   *(SORT(.data.vpci.*)) \
>> +   __end_vpci_array = .;
>> +
>> +#define HYPFS_SECTION    \
>> +   . = ALIGN(8); \
>> +   __paramhypfs_start = .;   \
>> +   *(.data.paramhypfs)   \
>> +   __paramhypfs_end = .;
>> +
>> +#define LOCK_PROFILE_SECTION \
>> +   . = ALIGN(POINTER_ALIGN); \
>> +   __lock_profile_start = .; \
>> +   *(.lockprofile.data)  \
>> +   __lock_profile_end = .;
>> +
>> +#endif /* __XEN_LDS_H__ */
> 
> I'm not sure _SECTION is a good suffix to use in the four names above:
> These aren't individual sections in the output, and for CTORS_SECTION
> it's also not even a single input section.
> 
> How about _ENTRY suffix?
> 

Re: [XEN PATCH] evtchn/fifo: Don't set PENDING bit if guest misbehaves

[Julien Grall]

Hi Andrew,

On 16/03/2022 18:58, Andrew Cooper wrote:

diff --git a/xen/common/event_fifo.c b/xen/common/event_fifo.c
index ed4d3beb10f3..6c74ccebebb7 100644
--- a/xen/common/event_fifo.c
+++ b/xen/common/event_fifo.c
@@ -165,7 +165,7 @@ static void cf_check evtchn_fifo_set_pending(
  unsigned int port;
  event_word_t *word;
  unsigned long flags;
-bool_t was_pending;
+bool_t check_pollers = false;


Considering your commit message, did you intend to change this to bool?

Can be fixed on commit.  Acked-by: Andrew Cooper 


So far, tools like b4 [1] are not able to find your tag on lore.kernel.org:

42sh> b4 am 
6b84a20b2753130cc62406a0fd14d2708f6f504b.1647455219.git.raphn...@amazon.com


Looking up 
https://lore.kernel.org/r/6b84a20b2753130cc62406a0fd14d2708f6f504b.1647455219.git.raphning%40amazon.com

Analyzing 8 messages in the thread
Checking attestation on all messages, may take a moment...
---
  ✓ [PATCH] evtchn/fifo: Don't set PENDING bit if guest misbehaves
+ Reviewed-by: David Vrabel 
+ Tested-by: Luca Fancellu  (✓ 
DKIM/armh.onmicrosoft.com)

  ---
  ✓ Signed: DKIM/gmail.com
---
Total patches: 1
---
 Link: 
https://lore.kernel.org/r/6b84a20b2753130cc62406a0fd14d2708f6f504b.1647455219.git.raphn...@amazon.com

 Base: not specified
   git am 
./20220316_raphning_evtchn_fifo_don_t_set_pending_bit_if_guest_misbehaves.mbx


This is because they are not at the start of the line. In the future, 
would you mind write the tag on a separate line?


Cheers,

[1] 
https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation


--
Julien Grall

Re: [PATCH 1/3] xen: Introduce a header to store common linker scripts content

[Michal Orzel]

Hi Jan,
 
On 21.03.2022 09:21, Michal Orzel wrote:
> Both x86 and arm linker scripts share quite a lot of common content.
> It is difficult to keep syncing them up, thus introduce a new header
> in include/xen called xen_lds.h to store the internals mutual to all
> the linker scripts.
> 
> Populate xen_lds.h with the first portion of the common sections.
> Some of them are not yet added/completed in arm linker script but they
> definitely should be. Please note that this patch does not aim to
> perform the full sync up between the linker scripts. It creates a base
> for further work.
> 
> Signed-off-by: Michal Orzel 
> ---
>  xen/include/xen/xen_lds.h | 114 ++
>  1 file changed, 114 insertions(+)
>  create mode 100644 xen/include/xen/xen_lds.h

While perhaps just minor, I'm not happy about new files added with underscores
in their names. Dashes are easier to type. Plus, looking at Linux, it may make
sense to name this xen.lds.h.

I'm ok to change the name to xen.lds.h.

> --- /dev/null
> +++ b/xen/include/xen/xen_lds.h
> @@ -0,0 +1,114 @@
> +#ifndef __XEN_LDS_H__
> +#define __XEN_LDS_H__
> +
> +/*
> + * Common macros to be used in architecture specific linker scripts.
> + */
> +
> +/* Macros to declare debug sections. */
> +#ifdef EFI
> +/*
> + * Use the NOLOAD directive, despite currently ignored by (at least) GNU ld
> + * for PE output, in order to record that we'd prefer these sections to not
> + * be loaded into memory.
> + */
> +#define DECL_DEBUG(x, a) #x ALIGN(a) (NOLOAD) : { *(x) }
> +#define DECL_DEBUG2(x, y, a) #x ALIGN(a) (NOLOAD) : { *(x) *(y) }
> +#else
> +#define DECL_DEBUG(x, a) #x 0 : { *(x) }
> +#define DECL_DEBUG2(x, y, a) #x 0 : { *(x) *(y) }
> +#endif
> +
> +/* DWARF debug sections. */
> +#define DWARF_DEBUG_SECTIONS  \
> +  DECL_DEBUG(.debug_abbrev, 1)    \
> +  DECL_DEBUG2(.debug_info, .gnu.linkonce.wi.*, 1) \
> +  DECL_DEBUG(.debug_types, 1) \
> +  DECL_DEBUG(.debug_str, 1)   \
> +  DECL_DEBUG2(.debug_line, .debug_line.*, 1)  \
> +  DECL_DEBUG(.debug_line_str, 1)  \
> +  DECL_DEBUG(.debug_names, 4) \
> +  DECL_DEBUG(.debug_frame, 4) \
> +  DECL_DEBUG(.debug_loc, 1)   \
> +  DECL_DEBUG(.debug_loclists, 4)  \
> +  DECL_DEBUG(.debug_macinfo, 1)   \
> +  DECL_DEBUG(.debug_macro, 1) \
> +  DECL_DEBUG(.debug_ranges, 8)    \
> +  DECL_DEBUG(.debug_rnglists, 4)  \
> +  DECL_DEBUG(.debug_addr, 8)  \
> +  DECL_DEBUG(.debug_aranges, 1)   \
> +  DECL_DEBUG(.debug_pubnames, 1)  \
> +  DECL_DEBUG(.debug_pubtypes, 1)
> +
> +/*
> + * Stabs debug sections.
> + *
> + * LLVM ld also wants .symtab, .strtab, and .shstrtab placed. These look to
> + * be benign to GNU ld, so we can have them here unconditionally.
> + */
> +#define STABS_DEBUG_SECTIONS \
> +  .stab 0 : { *(.stab) } \
> +  .stabstr 0 : { *(.stabstr) }   \
> +  .stab.excl 0 : { *(.stab.excl) }   \
> +  .stab.exclstr 0 : { *(.stab.exclstr) } \
> +  .stab.index 0 : { *(.stab.index) } \
> +  .stab.indexstr 0 : { *(.stab.indexstr) }   \
> +  .comment 0 : { *(.comment) }   \
> +  .symtab 0 : { *(.symtab) } \
> +  .strtab 0 : { *(.strtab) } \
> +  .shstrtab 0 : { *(.shstrtab) }

Please don't add non-Stabs sections to this macro.

Ok, I will add a new macro storing the last 4 sections called 
ELF_DETAILS_SECTIONS,
to be coherent with what Linux does (ELF_DETAILS).

> +#ifdef EFI
> +#define DISCARD_EFI_SECTIONS \
> +   *(.comment)   \
> +   *(.comment.*) \
> +   *(.note.*)
> +#else
> +#define DISCARD_EFI_SECTIONS
> +#endif
> +
> +/* Sections to be discarded. */
> +#define DISCARD_SECTIONS \
> +  /DISCARD/ : {  \
> +   *(.text.exit) \
> +   *(.exit.text) \
> +   *(.exit.data) \
> +   *(.exitcall.exit) \
> +   *(.discard)   \
> +   *(.discard.*) \
> +   *(.eh_frame)  \
> +   *(.dtors) \
> +   *(.dtors.*)   \
> +   *(.fini_array)    \
> +   *(.fini_array.*)  \
> +   DISCARD_EFI_SECTIONS  \
> +  }
> +
> +#define CTORS_SECTION   \
> +   . = ALIGN(8);    \
> +   __ctors_start = .;   \
> +   *(SORT_BY_INIT_PRIORITY(.init_array.*))  \
> +   *(SORT_BY_INIT_PRIORITY(.ctors.*))   \
> +   *(.init_array)   \
> +   *(.ctors)    \
> +   __ctors_end = .;
> +
> +#define VPCI_SECTION \
> +   . = ALIGN(POINTER_ALIGN); \
> +   __start_vpci_array = .;   \
> +   *(SORT(.data.vpci.*)) \
> +   

Re: [PATCH 1/1] xen/blkfront: fix comment for need_copy

[Roger Pau Monné]

On Thu, Mar 17, 2022 at 03:09:30PM -0700, Dongli Zhang wrote:
> The 'need_copy' is set when rq_data_dir(req) returns WRITE, in order to
> copy the written data to persistent page.
> 
> ".need_copy = rq_data_dir(req) && info->feature_persistent,"

I would also add:

Fixes: c004a6fe0c40 ('block/xen-blkfront: Make it running on 64KB page 
granularity')

> Signed-off-by: Dongli Zhang 

Acked-by: Roger Pau Monné 

Albeit I have one nit since you are already changing the line.

> ---
>  drivers/block/xen-blkfront.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 03b5fb341e58..dbc32d0a4b1a 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -576,7 +576,7 @@ struct setup_rw_req {
>   struct blkif_request *ring_req;
>   grant_ref_t gref_head;
>   unsigned int id;
> - /* Only used when persistent grant is used and it's a read request */
> + /* Only used when persistent grant is used and it's a write request */

While there you might want to adjust the comment to:

"... persistent grants are used ..."

Thanks, Roger.

Re: [PATCH] xen-blkback: remove redundant assignment to variable i

[Roger Pau Monné]

On Thu, Mar 17, 2022 at 11:46:46PM +, Colin Ian King wrote:
> Variable i is being assigned a value that is never read, it is being
> re-assigned later in a for-loop. The assignment is redundant and can
> be removed.
> 
> Cleans up clang scan build warning:
> drivers/block/xen-blkback/blkback.c:934:14: warning: Although the value
> stored to 'i' is used in the enclosing expression, the value is never
> actually read from 'i' [deadcode.DeadStores]
> 
> Signed-off-by: Colin Ian King 

Acked-by: Roger Pau Monné 

Thanks, Roger.

Re: [XEN PATCH] evtchn/fifo: Don't set PENDING bit if guest misbehaves

[David Vrabel]

On 16/03/2022 18:38, Raphael Ning wrote:

Currently, evtchn_fifo_set_pending() will mark the event as PENDING even
if it fails to lock the FIFO event queue(s), or if the guest has not
initialized the FIFO control block for the target vCPU. A well-behaved
guest should never trigger either of these cases.


Reviewed-by: David Vrabel 

David

Re: [PATCH v2] codeql: add support for analyzing C, Python and Go

[Roger Pau Monné]

Ping?

On Mon, Mar 07, 2022 at 05:45:52PM +0100, Roger Pau Monne wrote:
> Introduce CodeQL support for Xen and analyze the C, Python and Go
> files.
> 
> Note than when analyzing Python or Go we avoid building the hypervisor
> and only build the tools.
> 
> Requested-by: Andrew Cooper 
> Signed-off-by: Roger Pau Monné 
> ---
> Changes since v1:
>  - Rename to note it's x86 specific right now.
>  - Merge the ignored path patch.
> ---
> It's my understanding that we need to force the checkout action to
> fetch 'staging' branch, or else for the scheduled runs we would end up
> picking the current default branch (master).
> 
> Maybe we want to remove the scheduled action and just rely on pushes
> and manually triggered workflows?
> ---
>  .github/codeql/codeql-config.yml |  3 ++
>  .github/workflows/codeql-x86.yml | 60 
>  2 files changed, 63 insertions(+)
>  create mode 100644 .github/codeql/codeql-config.yml
>  create mode 100644 .github/workflows/codeql-x86.yml
> 
> diff --git a/.github/codeql/codeql-config.yml 
> b/.github/codeql/codeql-config.yml
> new file mode 100644
> index 00..721640c2a5
> --- /dev/null
> +++ b/.github/codeql/codeql-config.yml
> @@ -0,0 +1,3 @@
> +paths-ignore:
> +  - xen/tools/kconfig
> +  - tools/firmware/xen-dir/xen-root/xen/tools/kconfig
> diff --git a/.github/workflows/codeql-x86.yml 
> b/.github/workflows/codeql-x86.yml
> new file mode 100644
> index 00..a3ec6236c4
> --- /dev/null
> +++ b/.github/workflows/codeql-x86.yml
> @@ -0,0 +1,60 @@
> +name: CodeQL x86
> +
> +on:
> +  workflow_dispatch:
> +  push:
> +branches: [staging]
> +  schedule:
> +- cron: '18 10 * * WED,SUN' # Bi-weekly at 10:18 UTC
> +
> +jobs:
> +  analyse:
> +
> +strategy:
> +  matrix:
> +language: [ 'cpp', 'python', 'go' ]
> +
> +runs-on: ubuntu-latest
> +
> +steps:
> +- name: Install build dependencies
> +  run: |
> +sudo apt-get install -y wget git \
> +  libbz2-dev build-essential \
> +  zlib1g-dev libncurses5-dev iasl \
> +  libbz2-dev e2fslibs-dev uuid-dev libyajl-dev \
> +  autoconf libtool liblzma-dev \
> +  python3-dev golang python-dev libsystemd-dev
> +
> +- uses: actions/checkout@v2
> +  with:
> +ref: staging
> +
> +- name: Configure Xen
> +  run: |
> +./configure --with-system-qemu=/bin/true \
> +--with-system-seabios=/bin/true \
> +--with-system-ovmf=/bin/true
> +
> +- name: Pre build stuff
> +  run: |
> +make -j`nproc` mini-os-dir
> +
> +- uses: github/codeql-action/init@v1
> +  with:
> +config-file: ./.github/codeql/codeql-config.yml
> +languages: ${{matrix.language}}
> +queries: security-and-quality
> +
> +- if: matrix.language == 'cpp'
> +  name: Full Build
> +  run: |
> +make -j`nproc` build-xen build-tools
> +make -j`nproc` -C extras/mini-os/
> +
> +- if: matrix.language == 'python' || matrix.language == 'go'
> +  name: Tools Build
> +  run: |
> +make -j`nproc` build-tools
> +
> +- uses: github/codeql-action/analyze@v1
> -- 
> 2.34.1
> 

[ovmf test] 168745: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf 267a92fef3b705e6a3ecbeaa4d4b58f7bfac9734
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   20 days
Failing since168258  2022-03-01 01:55:31 Z   20 days  205 attempts
Testing same since   168738  2022-03-21 02:39:18 Z0 days4 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  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 859 lines long.)

Re: [PATCH 3/3] xen/arm: Make use of helpers defined in xen_lds.h

[Jan Beulich]

On 21.03.2022 09:21, Michal Orzel wrote:
> Header file xen_lds.h defines common macros to be used in arch specific
> linker scripts. Include this header and make use of its helpers.
> 
> Making use of common helpers defined based on x86 linker script
> improves arm linker script with:
> -explicit list of debug sections that otherwise are seen as "orphans"
> by the linker. This will allow to fix issues after enabling linker
> option --orphan-handling one day
> -re-arrangement of ordering/sorting in constructors section to match the
> default linker script

As said in reply to patch 1 - I don't think this is correct on x86 right
now, and hence I don't think you want to propagate the same (at least
latent) issue to Arm.

Jan

Re: [PATCH 1/3] xen: Introduce a header to store common linker scripts content

[Jan Beulich]

On 21.03.2022 09:21, Michal Orzel wrote:
> Both x86 and arm linker scripts share quite a lot of common content.
> It is difficult to keep syncing them up, thus introduce a new header
> in include/xen called xen_lds.h to store the internals mutual to all
> the linker scripts.
> 
> Populate xen_lds.h with the first portion of the common sections.
> Some of them are not yet added/completed in arm linker script but they
> definitely should be. Please note that this patch does not aim to
> perform the full sync up between the linker scripts. It creates a base
> for further work.
> 
> Signed-off-by: Michal Orzel 
> ---
>  xen/include/xen/xen_lds.h | 114 ++
>  1 file changed, 114 insertions(+)
>  create mode 100644 xen/include/xen/xen_lds.h

While perhaps just minor, I'm not happy about new files added with underscores
in their names. Dashes are easier to type. Plus, looking at Linux, it may make
sense to name this xen.lds.h.

> --- /dev/null
> +++ b/xen/include/xen/xen_lds.h
> @@ -0,0 +1,114 @@
> +#ifndef __XEN_LDS_H__
> +#define __XEN_LDS_H__
> +
> +/*
> + * Common macros to be used in architecture specific linker scripts.
> + */
> +
> +/* Macros to declare debug sections. */
> +#ifdef EFI
> +/*
> + * Use the NOLOAD directive, despite currently ignored by (at least) GNU ld
> + * for PE output, in order to record that we'd prefer these sections to not
> + * be loaded into memory.
> + */
> +#define DECL_DEBUG(x, a) #x ALIGN(a) (NOLOAD) : { *(x) }
> +#define DECL_DEBUG2(x, y, a) #x ALIGN(a) (NOLOAD) : { *(x) *(y) }
> +#else
> +#define DECL_DEBUG(x, a) #x 0 : { *(x) }
> +#define DECL_DEBUG2(x, y, a) #x 0 : { *(x) *(y) }
> +#endif
> +
> +/* DWARF debug sections. */
> +#define DWARF_DEBUG_SECTIONS  \
> +  DECL_DEBUG(.debug_abbrev, 1)\
> +  DECL_DEBUG2(.debug_info, .gnu.linkonce.wi.*, 1) \
> +  DECL_DEBUG(.debug_types, 1) \
> +  DECL_DEBUG(.debug_str, 1)   \
> +  DECL_DEBUG2(.debug_line, .debug_line.*, 1)  \
> +  DECL_DEBUG(.debug_line_str, 1)  \
> +  DECL_DEBUG(.debug_names, 4) \
> +  DECL_DEBUG(.debug_frame, 4) \
> +  DECL_DEBUG(.debug_loc, 1)   \
> +  DECL_DEBUG(.debug_loclists, 4)  \
> +  DECL_DEBUG(.debug_macinfo, 1)   \
> +  DECL_DEBUG(.debug_macro, 1) \
> +  DECL_DEBUG(.debug_ranges, 8)\
> +  DECL_DEBUG(.debug_rnglists, 4)  \
> +  DECL_DEBUG(.debug_addr, 8)  \
> +  DECL_DEBUG(.debug_aranges, 1)   \
> +  DECL_DEBUG(.debug_pubnames, 1)  \
> +  DECL_DEBUG(.debug_pubtypes, 1)
> +
> +/*
> + * Stabs debug sections.
> + *
> + * LLVM ld also wants .symtab, .strtab, and .shstrtab placed. These look to
> + * be benign to GNU ld, so we can have them here unconditionally.
> + */
> +#define STABS_DEBUG_SECTIONS \
> +  .stab 0 : { *(.stab) } \
> +  .stabstr 0 : { *(.stabstr) }   \
> +  .stab.excl 0 : { *(.stab.excl) }   \
> +  .stab.exclstr 0 : { *(.stab.exclstr) } \
> +  .stab.index 0 : { *(.stab.index) } \
> +  .stab.indexstr 0 : { *(.stab.indexstr) }   \
> +  .comment 0 : { *(.comment) }   \
> +  .symtab 0 : { *(.symtab) } \
> +  .strtab 0 : { *(.strtab) } \
> +  .shstrtab 0 : { *(.shstrtab) }

Please don't add non-Stabs sections to this macro.

> +#ifdef EFI
> +#define DISCARD_EFI_SECTIONS \
> +   *(.comment)   \
> +   *(.comment.*) \
> +   *(.note.*)
> +#else
> +#define DISCARD_EFI_SECTIONS
> +#endif
> +
> +/* Sections to be discarded. */
> +#define DISCARD_SECTIONS \
> +  /DISCARD/ : {  \
> +   *(.text.exit) \
> +   *(.exit.text) \
> +   *(.exit.data) \
> +   *(.exitcall.exit) \
> +   *(.discard)   \
> +   *(.discard.*) \
> +   *(.eh_frame)  \
> +   *(.dtors) \
> +   *(.dtors.*)   \
> +   *(.fini_array)\
> +   *(.fini_array.*)  \
> +   DISCARD_EFI_SECTIONS  \
> +  }
> +
> +#define CTORS_SECTION   \
> +   . = ALIGN(8);\
> +   __ctors_start = .;   \
> +   *(SORT_BY_INIT_PRIORITY(.init_array.*))  \
> +   *(SORT_BY_INIT_PRIORITY(.ctors.*))   \
> +   *(.init_array)   \
> +   *(.ctors)\
> +   __ctors_end = .;
> +
> +#define VPCI_SECTION \
> +   . = ALIGN(POINTER_ALIGN); \
> +   __start_vpci_array = .;   \
> +   *(SORT(.data.vpci.*)) \
> +   __end_vpci_array = .;
> +
> +#define HYPFS_SECTION\
> +   . = ALIGN(8); \
> +   __paramhypfs_start = .;   \
> +   *(.data.paramhypfs)   \
> +   

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Jan Beulich]

On 18.03.2022 16:25, Luca Fancellu wrote:
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -1,5 +1,6 @@
>  obj-$(CONFIG_ARGO) += argo.o
>  obj-y += bitmap.o
> +obj-$(CONFIG_BOOT_TIME_CPUPOOLS) += boot_cpupools.o

By the looks of it you appear to want to specify boot_cpupools.init.o
here: All functions there are __init and all data is __initdata. That
was string literals (e.g. as used for printk() invocations) will also
move to .init.*.

> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -1176,6 +1176,25 @@ extern void cf_check dump_runq(unsigned char key);
>  
>  void arch_do_physinfo(struct xen_sysctl_physinfo *pi);
>  
> +#ifdef CONFIG_BOOT_TIME_CPUPOOLS
> +void btcpupools_allocate_pools(void);
> +unsigned int btcpupools_get_cpupool_id(unsigned int cpu);
> +
> +#ifdef CONFIG_HAS_DEVICE_TREE
> +void btcpupools_dtb_parse(void);
> +#else
> +static inline void btcpupools_dtb_parse(void) {}

I think you want to avoid having two stubs for this - one here and ...

> +#endif
> +
> +#else /* !CONFIG_BOOT_TIME_CPUPOOLS */
> +static inline void btcpupools_allocate_pools(void) {}
> +static inline void btcpupools_dtb_parse(void) {}

... another one here.

Jan

Re: [PATCH v3 5/6] arm/dom0less: assign dom0less guests to cpupools

[Jan Beulich]

On 18.03.2022 16:25, Luca Fancellu wrote:
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -1182,6 +1182,7 @@ unsigned int btcpupools_get_cpupool_id(unsigned int 
> cpu);
>  
>  #ifdef CONFIG_HAS_DEVICE_TREE
>  void btcpupools_dtb_parse(void);
> +int btcpupools_get_domain_pool_id(const struct dt_device_node *node);
>  #else
>  static inline void btcpupools_dtb_parse(void) {}
>  #endif
> @@ -1193,6 +1194,14 @@ static inline unsigned int 
> btcpupools_get_cpupool_id(unsigned int cpu)
>  {
>  return 0;
>  }
> +#ifdef CONFIG_HAS_DEVICE_TREE
> +static inline int
> +btcpupools_get_domain_pool_id(const struct dt_device_node *node)
> +{
> +return 0;
> +}
> +#endif

Was this perhaps meant to go inside the #else visible in the context of
the earlier hunk? It's odd in any event that you have #ifdef twice, not
once #ifdef and once #ifndef.

Jan

Re: [PATCH] xen/x86/hvm: add missing cf_check for hvm_physdev_op()

[Jan Beulich]

On 21.03.2022 08:53, Juergen Gross wrote:
> The hypercall handler hvm_physdev_op() is missing a cf_check attribute.
> 
> Fixes: cdbe2b0a1aec ("x86: Enable CET Indirect Branch Tracking")
> Signed-off-by: Juergen Gross 

Reviewed-by: Jan Beulich 

Re: [PATCH v1 02/13] xen/arm: introduce a special domain DOMID_SHARED

[Jan Beulich]

On 18.03.2022 22:50, Stefano Stabellini wrote:
> On Fri, 18 Mar 2022, Jan Beulich wrote:
>> On 11.03.2022 07:11, Penny Zheng wrote:
>>> In case to own statically shared pages when owner domain is not
>>> explicitly defined, this commits propose a special domain DOMID_SHARED,
>>> and we assign it 0x7FF5, as one of the system domains.
>>>
>>> Statically shared memory reuses the same way of initialization with static
>>> memory, hence this commits proposes a new Kconfig CONFIG_STATIC_SHM to wrap
>>> related codes, and this option depends on static 
>>> memory(CONFIG_STATIC_MEMORY).
>>>
>>> We intends to do shared domain creation after setup_virt_paging so shared
>>> domain could successfully do p2m initialization.
>>
>> There's nothing said here, in the earlier patch, or in the cover letter
>> about the security aspects of this. There is a reason we haven't been
>> allowing arbitrary, un-supervised sharing of memory between domains. It
>> wants clarifying why e.g. grants aren't an option to achieve what you
>> need, and how you mean to establish which domains are / aren't permitted
>> to access any individual page owned by this domain.
> 
> 
> I'll let Penny write a full reply but I'll chime in to try to help with
> the explanation.
> 
> This is not arbitrary un-supervised sharing of memory between domains,
> which indeed is concerning.
> 
> This is statically-configured, supervised by the system configurator,
> sharing of memory between domains.
> 
> And in fact safety (which is just a different aspect of security) is one
> of the primary goals for this work.
> 
> In safety-critical environments, it is not considered safe to
> dynamically change important configurations at runtime. Everything
> should be statically defined and statically verified.
> 
> In this case, if the system configuration knows a priori that there are
> only 2 VM and they need to communication over shared memory, it is safer
> to pre-configure the shared memory at build time rather than let the VMs
> attempt to share memory at runtime. It is faster too.
> 
> The only way to trigger this static shared memory configuration should
> be via device tree, which is at the same level as the XSM rules
> themselves.
> 
> Hopefully I made things clearer and not murkier :-)

It adds some helpful background, yes, but at the same time it doesn't
address the security concern at all: How are access permissions
managed when the owning domain is a special one? I haven't spotted
any recording of the domains which are actually permitted to map /
access the pages in questions. (But of course I also only looked at
non-Arm-specific code. I'd expect such code not to live in arch-
specific files.)

Jan

[ovmf test] 168741: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf 267a92fef3b705e6a3ecbeaa4d4b58f7bfac9734
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   20 days
Failing since168258  2022-03-01 01:55:31 Z   20 days  204 attempts
Testing same since   168738  2022-03-21 02:39:18 Z0 days3 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  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 859 lines long.)

[PATCH 3/3] xen/arm: Make use of helpers defined in xen_lds.h

[Michal Orzel]

Header file xen_lds.h defines common macros to be used in arch specific
linker scripts. Include this header and make use of its helpers.

Making use of common helpers defined based on x86 linker script
improves arm linker script with:
-explicit list of debug sections that otherwise are seen as "orphans"
by the linker. This will allow to fix issues after enabling linker
option --orphan-handling one day
-re-arrangement of ordering/sorting in constructors section to match the
default linker script
-extended list of discarded section to include: .discard, desctructors
related sections, .fini_array which can reference .text.exit
-extended list of stabs section to include sections placed by ld.lld.
Even though Xen on arm compilation with LLVM support is not ready yet,
these sections do not cause problem to GNU ld

Signed-off-by: Michal Orzel 
---
 xen/arch/arm/xen.lds.S | 37 -
 1 file changed, 12 insertions(+), 25 deletions(-)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 7921d8fa28..9e1832e94c 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -3,6 +3,7 @@
 /* Modified for ARM Xen by Ian Campbell */
 
 #include 
+#include 
 #include 
 #undef ENTRY
 #undef ALIGN
@@ -68,10 +69,7 @@ SECTIONS
__proc_info_end = .;
 
 #ifdef CONFIG_HAS_VPCI
-   . = ALIGN(POINTER_ALIGN);
-   __start_vpci_array = .;
-   *(SORT(.data.vpci.*))
-   __end_vpci_array = .;
+   VPCI_SECTION
 #endif
   } :text
 
@@ -109,10 +107,7 @@ SECTIONS
__end_schedulers_array = .;
 
 #ifdef CONFIG_HYPFS
-   . = ALIGN(8);
-   __paramhypfs_start = .;
-   *(.data.paramhypfs)
-   __paramhypfs_end = .;
+   HYPFS_SECTION
 #endif
 
*(.data .data.*)
@@ -178,10 +173,7 @@ SECTIONS
__alt_instructions_end = .;
 
 #ifdef CONFIG_DEBUG_LOCK_PROFILE
-   . = ALIGN(POINTER_ALIGN);
-   __lock_profile_start = .;
-   *(.lockprofile.data)
-   __lock_profile_end = .;
+   LOCK_PROFILE_SECTION
 #endif
 
*(.init.data)
@@ -221,22 +213,17 @@ SECTIONS
   /* Section for the device tree blob (if any). */
   .dtb : { *(.dtb) } :text
 
+  /*
+   * Explicitly list debug sections, to avoid these sections being viewed as
+   * "orphan" by the linker.
+   */
+  DWARF_DEBUG_SECTIONS
+
   /* Sections to be discarded */
-  /DISCARD/ : {
-   *(.exit.text)
-   *(.exit.data)
-   *(.exitcall.exit)
-   *(.eh_frame)
-  }
+  DISCARD_SECTIONS
 
   /* Stabs debugging sections.  */
-  .stab 0 : { *(.stab) }
-  .stabstr 0 : { *(.stabstr) }
-  .stab.excl 0 : { *(.stab.excl) }
-  .stab.exclstr 0 : { *(.stab.exclstr) }
-  .stab.index 0 : { *(.stab.index) }
-  .stab.indexstr 0 : { *(.stab.indexstr) }
-  .comment 0 : { *(.comment) }
+  STABS_DEBUG_SECTIONS
 }
 
 /*
-- 
2.25.1

[PATCH 2/3] xen/x86: Make use of helpers defined in xen_lds.h

[Michal Orzel]

Header file xen_lds.h defines common macros to be used in arch specific
linker scripts. Include this header and make use of its helpers.

Signed-off-by: Michal Orzel 
---
 xen/arch/x86/xen.lds.S | 86 --
 1 file changed, 8 insertions(+), 78 deletions(-)

diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d33e295320..e82a148e08 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -2,6 +2,7 @@
 /* Modified for i386/x86-64 Xen by Keir Fraser */
 
 #include 
+#include 
 #include 
 #undef ENTRY
 #undef ALIGN
@@ -12,13 +13,6 @@
 #undef __XEN_VIRT_START
 #define __XEN_VIRT_START __image_base__
 #define DECL_SECTION(x) x :
-/*
- * Use the NOLOAD directive, despite currently ignored by (at least) GNU ld
- * for PE output, in order to record that we'd prefer these sections to not
- * be loaded into memory.
- */
-#define DECL_DEBUG(x, a) #x ALIGN(a) (NOLOAD) : { *(x) }
-#define DECL_DEBUG2(x, y, a) #x ALIGN(a) (NOLOAD) : { *(x) *(y) }
 
 ENTRY(efi_start)
 
@@ -26,8 +20,6 @@ ENTRY(efi_start)
 
 #define FORMAT "elf64-x86-64"
 #define DECL_SECTION(x) #x : AT(ADDR(#x) - __XEN_VIRT_START)
-#define DECL_DEBUG(x, a) #x 0 : { *(x) }
-#define DECL_DEBUG2(x, y, a) #x 0 : { *(x) *(y) }
 
 ENTRY(start_pa)
 
@@ -159,10 +151,7 @@ SECTIONS
__note_gnu_build_id_end = .;
 #endif
 #ifdef CONFIG_HAS_VPCI
-   . = ALIGN(POINTER_ALIGN);
-   __start_vpci_array = .;
-   *(SORT(.data.vpci.*))
-   __end_vpci_array = .;
+   VPCI_SECTION
 #endif
   } PHDR(text)
 
@@ -278,19 +267,10 @@ SECTIONS
 __alt_instructions_end = .;
 
 #ifdef CONFIG_DEBUG_LOCK_PROFILE
-   . = ALIGN(POINTER_ALIGN);
-   __lock_profile_start = .;
-   *(.lockprofile.data)
-   __lock_profile_end = .;
+   LOCK_PROFILE_SECTION
 #endif
 
-   . = ALIGN(8);
-   __ctors_start = .;
-   *(SORT_BY_INIT_PRIORITY(.init_array.*))
-   *(SORT_BY_INIT_PRIORITY(.ctors.*))
-   *(.init_array)
-   *(.ctors)
-   __ctors_end = .;
+   CTORS_SECTION
   } PHDR(text)
 
 #ifndef EFI
@@ -335,10 +315,7 @@ SECTIONS
__end_schedulers_array = .;
 
 #ifdef CONFIG_HYPFS
-   . = ALIGN(8);
-   __paramhypfs_start = .;
-   *(.data.paramhypfs)
-   __paramhypfs_end = .;
+   HYPFS_SECTION
 #endif
   } PHDR(text)
 
@@ -395,24 +372,7 @@ SECTIONS
* _end here, so if these sections get loaded they'll be discarded at runtime
* anyway.
*/
-  DECL_DEBUG(.debug_abbrev, 1)
-  DECL_DEBUG2(.debug_info, .gnu.linkonce.wi.*, 1)
-  DECL_DEBUG(.debug_types, 1)
-  DECL_DEBUG(.debug_str, 1)
-  DECL_DEBUG2(.debug_line, .debug_line.*, 1)
-  DECL_DEBUG(.debug_line_str, 1)
-  DECL_DEBUG(.debug_names, 4)
-  DECL_DEBUG(.debug_frame, 4)
-  DECL_DEBUG(.debug_loc, 1)
-  DECL_DEBUG(.debug_loclists, 4)
-  DECL_DEBUG(.debug_macinfo, 1)
-  DECL_DEBUG(.debug_macro, 1)
-  DECL_DEBUG(.debug_ranges, 8)
-  DECL_DEBUG(.debug_rnglists, 4)
-  DECL_DEBUG(.debug_addr, 8)
-  DECL_DEBUG(.debug_aranges, 1)
-  DECL_DEBUG(.debug_pubnames, 1)
-  DECL_DEBUG(.debug_pubtypes, 1)
+  DWARF_DEBUG_SECTIONS
 
 #ifdef EFI
   /* Trick the linker into setting the image size to no less than 16Mb. */
@@ -427,41 +387,11 @@ SECTIONS
 #endif
 
   /* Sections to be discarded */
-  /DISCARD/ : {
-   *(.text.exit)
-   *(.exit.text)
-   *(.exit.data)
-   *(.exitcall.exit)
-   *(.discard)
-   *(.discard.*)
-   *(.eh_frame)
-   *(.dtors)
-   *(.dtors.*)
-   *(.fini_array)
-   *(.fini_array.*)
-#ifdef EFI
-   *(.comment)
-   *(.comment.*)
-   *(.note.*)
-#endif
-  }
+  DISCARD_SECTIONS
 
 #ifndef EFI
   /* Stabs debugging sections.  */
-  .stab 0 : { *(.stab) }
-  .stabstr 0 : { *(.stabstr) }
-  .stab.excl 0 : { *(.stab.excl) }
-  .stab.exclstr 0 : { *(.stab.exclstr) }
-  .stab.index 0 : { *(.stab.index) }
-  .stab.indexstr 0 : { *(.stab.indexstr) }
-  .comment 0 : { *(.comment) }
-  /*
-   * LLVM ld also wants .symtab, .strtab, and .shstrtab placed. These look to
-   * be benign to GNU ld, so we can have them here unconditionally.
-   */
-  .symtab 0 : { *(.symtab) }
-  .strtab 0 : { *(.strtab) }
-  .shstrtab 0 : { *(.shstrtab) }
+  STABS_DEBUG_SECTIONS
 #endif
 }
 
-- 
2.25.1

[PATCH 1/3] xen: Introduce a header to store common linker scripts content

[Michal Orzel]

Both x86 and arm linker scripts share quite a lot of common content.
It is difficult to keep syncing them up, thus introduce a new header
in include/xen called xen_lds.h to store the internals mutual to all
the linker scripts.

Populate xen_lds.h with the first portion of the common sections.
Some of them are not yet added/completed in arm linker script but they
definitely should be. Please note that this patch does not aim to
perform the full sync up between the linker scripts. It creates a base
for further work.

Signed-off-by: Michal Orzel 
---
 xen/include/xen/xen_lds.h | 114 ++
 1 file changed, 114 insertions(+)
 create mode 100644 xen/include/xen/xen_lds.h

diff --git a/xen/include/xen/xen_lds.h b/xen/include/xen/xen_lds.h
new file mode 100644
index 00..f1ca67ecfd
--- /dev/null
+++ b/xen/include/xen/xen_lds.h
@@ -0,0 +1,114 @@
+#ifndef __XEN_LDS_H__
+#define __XEN_LDS_H__
+
+/*
+ * Common macros to be used in architecture specific linker scripts.
+ */
+
+/* Macros to declare debug sections. */
+#ifdef EFI
+/*
+ * Use the NOLOAD directive, despite currently ignored by (at least) GNU ld
+ * for PE output, in order to record that we'd prefer these sections to not
+ * be loaded into memory.
+ */
+#define DECL_DEBUG(x, a) #x ALIGN(a) (NOLOAD) : { *(x) }
+#define DECL_DEBUG2(x, y, a) #x ALIGN(a) (NOLOAD) : { *(x) *(y) }
+#else
+#define DECL_DEBUG(x, a) #x 0 : { *(x) }
+#define DECL_DEBUG2(x, y, a) #x 0 : { *(x) *(y) }
+#endif
+
+/* DWARF debug sections. */
+#define DWARF_DEBUG_SECTIONS  \
+  DECL_DEBUG(.debug_abbrev, 1)\
+  DECL_DEBUG2(.debug_info, .gnu.linkonce.wi.*, 1) \
+  DECL_DEBUG(.debug_types, 1) \
+  DECL_DEBUG(.debug_str, 1)   \
+  DECL_DEBUG2(.debug_line, .debug_line.*, 1)  \
+  DECL_DEBUG(.debug_line_str, 1)  \
+  DECL_DEBUG(.debug_names, 4) \
+  DECL_DEBUG(.debug_frame, 4) \
+  DECL_DEBUG(.debug_loc, 1)   \
+  DECL_DEBUG(.debug_loclists, 4)  \
+  DECL_DEBUG(.debug_macinfo, 1)   \
+  DECL_DEBUG(.debug_macro, 1) \
+  DECL_DEBUG(.debug_ranges, 8)\
+  DECL_DEBUG(.debug_rnglists, 4)  \
+  DECL_DEBUG(.debug_addr, 8)  \
+  DECL_DEBUG(.debug_aranges, 1)   \
+  DECL_DEBUG(.debug_pubnames, 1)  \
+  DECL_DEBUG(.debug_pubtypes, 1)
+
+/*
+ * Stabs debug sections.
+ *
+ * LLVM ld also wants .symtab, .strtab, and .shstrtab placed. These look to
+ * be benign to GNU ld, so we can have them here unconditionally.
+ */
+#define STABS_DEBUG_SECTIONS \
+  .stab 0 : { *(.stab) } \
+  .stabstr 0 : { *(.stabstr) }   \
+  .stab.excl 0 : { *(.stab.excl) }   \
+  .stab.exclstr 0 : { *(.stab.exclstr) } \
+  .stab.index 0 : { *(.stab.index) } \
+  .stab.indexstr 0 : { *(.stab.indexstr) }   \
+  .comment 0 : { *(.comment) }   \
+  .symtab 0 : { *(.symtab) } \
+  .strtab 0 : { *(.strtab) } \
+  .shstrtab 0 : { *(.shstrtab) }
+
+#ifdef EFI
+#define DISCARD_EFI_SECTIONS \
+   *(.comment)   \
+   *(.comment.*) \
+   *(.note.*)
+#else
+#define DISCARD_EFI_SECTIONS
+#endif
+
+/* Sections to be discarded. */
+#define DISCARD_SECTIONS \
+  /DISCARD/ : {  \
+   *(.text.exit) \
+   *(.exit.text) \
+   *(.exit.data) \
+   *(.exitcall.exit) \
+   *(.discard)   \
+   *(.discard.*) \
+   *(.eh_frame)  \
+   *(.dtors) \
+   *(.dtors.*)   \
+   *(.fini_array)\
+   *(.fini_array.*)  \
+   DISCARD_EFI_SECTIONS  \
+  }
+
+#define CTORS_SECTION   \
+   . = ALIGN(8);\
+   __ctors_start = .;   \
+   *(SORT_BY_INIT_PRIORITY(.init_array.*))  \
+   *(SORT_BY_INIT_PRIORITY(.ctors.*))   \
+   *(.init_array)   \
+   *(.ctors)\
+   __ctors_end = .;
+
+#define VPCI_SECTION \
+   . = ALIGN(POINTER_ALIGN); \
+   __start_vpci_array = .;   \
+   *(SORT(.data.vpci.*)) \
+   __end_vpci_array = .;
+
+#define HYPFS_SECTION\
+   . = ALIGN(8); \
+   __paramhypfs_start = .;   \
+   *(.data.paramhypfs)   \
+   __paramhypfs_end = .;
+
+#define LOCK_PROFILE_SECTION \
+   . = ALIGN(POINTER_ALIGN); \
+   __lock_profile_start = .; \
+   *(.lockprofile.data)  \
+   __lock_profile_end = .;
+
+#endif /* __XEN_LDS_H__ */
-- 
2.25.1

[PATCH 0/3] xen: Linker scripts synchronization

[Michal Orzel]

This patch series aims to do the first step towards linker scripts
synchronization. Linker scripts for arm and x86 share a lot of common
sections and in order to make the process of changing/improving/syncing
them, these sections shall be defined in just one place.

The first patch creates a header file to store the first portion of the
content mutual to both x86 and arm linker scripts. When populating this
file, we are taking an example from x86 script as it is more improved and
up-to-date.

The last two patches make use of the common macros in x86 and arm linker
scripts respectively.

Michal Orzel (3):
  xen: Introduce a header to store common linker scripts content
  x86: Make use of helpers defined in xen_lds.h
  xen/arm: Make use of helpers defined in xen_lds.h

 xen/arch/arm/xen.lds.S|  37 -
 xen/arch/x86/xen.lds.S|  86 +++-
 xen/include/xen/xen_lds.h | 114 ++
 3 files changed, 134 insertions(+), 103 deletions(-)
 create mode 100644 xen/include/xen/xen_lds.h

-- 
2.25.1

[libvirt test] 168740: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 libvirt  af6f6091e02bb46633666ce30d4c6533a52688a5
baseline version:
 libvirt  2c846fa6bcc11929c9fb857a22430fb9945654ad

Last test of basis   151777  2020-07-10 04:19:19 Z  619 days
Failing since151818  2020-07-11 04:18:52 Z  618 days  600 attempts
Testing same since   168699  2022-03-19 04:19:02 Z2 days3 attempts


People who touched revisions under test:
Adolfo Jayme Barrientos 
  Aleksandr Alekseev 
  Aleksei Zakharov 
  Andika Triwidada 
  Andrea Bolognani 
  Ani Sinha 
  Balázs Meskó 
  Barrett Schonefeld 
  Bastian Germann 
  Bastien Orivel 
  BiaoXiang Ye 
  Bihong Yu 
  Binfeng Wu 
  Bjoern Walk 
  Boris Fiuczynski 
  Brad Laue 
  Brian Turek 
  Bruno Haible 
  Chris Mayo 
  Christian Borntraeger 
  Christian Ehrhardt 
  Christian Kirbach 
  Christian Schoenebeck 
  Christophe Fergeau 
  Cole Robinson 
  Collin Walling 
  Cornelia Huck 
  Cédric Bosdonnat 
  Côme Borsoi 
  Daniel Henrique Barboza 
  Daniel Letai 
  Daniel P. Berrange 
  Daniel P. Berrangé 
  Didik Supriadi 
  dinglimin 
  Divya Garg 
  Dmitrii Shcherbakov 
  Dmytro Linkin 
  Eiichi Tsukata 
  Emilio Herrera 
  Eric Farman 
  Erik Skultety 
  Fabian Affolter 
  Fabian Freyer 
  Fabiano Fidêncio 
  Fangge Jin 
  Farhan Ali 
  Fedora Weblate Translation 
  Franck Ridel 
  Gavi Teitz 
  gongwei 
  Guoyi Tu
  Göran Uddeborg 
  Halil Pasic 
  Han Han 
  Hao Wang 
  Haonan Wang 
  Hela Basa 
  Helmut Grohne 
  Hiroki Narukawa 
  Hyman Huang(黄勇) 
  Ian Wienand 
  Ioanna Alifieraki 
  Ivan Teterevkov 
  Jakob Meng 
  Jamie Strandboge 
  Jamie Strandboge 
  Jan Kuparinen 
  jason lee 
  Jean-Baptiste Holcroft 
  Jia Zhou 
  Jianan Gao 
  Jim Fehlig 
  Jin Yan 
  Jing Qi 
  Jinsheng Zhang 
  Jiri Denemark 
  Joachim Falk 
  John Ferlan 
  Jonathan Watt 
  Jonathon Jongsma 
  Julio Faracco 
  Justin Gatzen 
  Ján Tomko 
  Kashyap Chamarthy 
  Kevin Locke 
  Kim InSoo 
  Koichi Murase 
  Kristina Hanicova 
  Laine Stump 
  Laszlo Ersek 
  Lee Yarwood 
  Lei Yang 
  Liao Pingfang 
  Lin Ma 
  Lin Ma 
  Lin Ma 
  Liu Yiding 
  Lubomir Rintel 
  Luke Yue 
  Luyao Zhong 
  Marc Hartmayer 
  Marc-André Lureau 
  Marek Marczykowski-Górecki 
  Markus Schade 
  Martin Kletzander 
  Martin Pitt 
  Masayoshi Mizuma 
  Matej Cepl 
  Matt Coleman 
  Matt Coleman 
  Mauro Matteo Cascella 
  Meina Li 
  Michal Privoznik 
  Michał Smyk 
  Milo Casagrande 
  Moshe Levi 
  Muha Aliss 
  Nathan 
  Neal Gompa 
  Nick Chevsky 
  Nick Shyrokovskiy 
  Nickys Music Group 
  Nico Pache 
  Nicolas Lécureuil 
  Nicolas Lécureuil 
  Nikolay Shirokovskiy 
  Olaf Hering 
  Olesya Gerasimenko 
  Or Ozeri 
  Orion Poplawski 
  Pany 
  Patrick Magauran 
  Paulo de Rezende Pinatti 
  Pavel Hrdina 
  Peng Liang 
  Peter Krempa 
  Pino Toscano 
  Pino Toscano 
  Piotr Drąg 
  Prathamesh Chavan 
  Praveen K Paladugu 
  Richard W.M. Jones 
  Ricky Tigg 
  Robin Lee 
  Rohit Kumar 
  Roman Bogorodskiy 
  Roman Bolshakov 
  Ryan Gahagan 
  Ryan Schmidt 
  Sam Hartman 
  Scott Shambarger 
  Sebastian Mitterle 
  SeongHyun Jo 
  

[PATCH] xen/x86/hvm: add missing cf_check for hvm_physdev_op()

[Juergen Gross]

The hypercall handler hvm_physdev_op() is missing a cf_check attribute.

Fixes: cdbe2b0a1aec ("x86: Enable CET Indirect Branch Tracking")
Signed-off-by: Juergen Gross 
---
 xen/arch/x86/hvm/hypercall.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index 030243810e..62b5349e7d 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -78,7 +78,7 @@ static long cf_check hvm_grant_table_op(
 }
 #endif
 
-static long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
+static long cf_check hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
 const struct vcpu *curr = current;
 const struct domain *currd = curr->domain;
-- 
2.34.1

Re: [PATCH 1/3] tools/xenstore: add documentation for new set/get-feature commands

[Juergen Gross]

On 18.03.22 19:40, Julien Grall wrote:

Hi Juergen,

On 17/03/2022 11:19, Juergen Gross wrote:

On 17.03.22 12:07, Julien Grall wrote:

On 16/03/2022 16:10, Juergen Gross wrote:

Add documentation for two new Xenstore wire commands SET_FEATURE and
GET_FEATURE used to set or query the Xenstore features visible in the
ring page of a given domain.

Signed-off-by: Juergen Gross 
---
  docs/misc/xenstore-ring.txt |  1 +
  docs/misc/xenstore.txt  | 12 
  2 files changed, 13 insertions(+)

diff --git a/docs/misc/xenstore-ring.txt b/docs/misc/xenstore-ring.txt
index f91accb5b0..bd000f694e 100644
--- a/docs/misc/xenstore-ring.txt
+++ b/docs/misc/xenstore-ring.txt
@@ -68,6 +68,7 @@ Mask    Description


I find a bit odd we describe the feature in term of mask rather bit. This 
will get more difficult to read as we add more bits.


Maybe this is in order to avoid big/little endian issues (which bit is
bit 0?)


Both end have to talk the same endianess. Otherwise, one may read the wrong 
value.

So long they are using the same endianess, bit 0 is not going to be matter.


  The "Connection state" field is used to request a ring close and reconnect.
  The "Connection state" field only contains valid data if the server has
diff --git a/docs/misc/xenstore.txt b/docs/misc/xenstore.txt
index ea3d8be177..31e3d53c52 100644
--- a/docs/misc/xenstore.txt
+++ b/docs/misc/xenstore.txt
@@ -332,6 +332,18 @@ SET_TARGET    ||
  xenstored prevents the use of SET_TARGET other than by dom0.
+GET_FEATURE    |    |


Did you indented to add many spaces before ?


+SET_FEATURE    ||
+    Returns or sets the contents of the "feature" field located at
+    offset 2064 of the Xenstore ring page of the domain specified by
+    .  is a decimal number being a logical or of the
+    feature bits as defined in docs/misc/xenstore-ring.txt. Trying
+    to set a bit for a feature not being supported by the running
+    Xenstore will be denied.
How will the caller know which feature is supported? Also, what happen if a 
client decided to overwrite 'feature'? Could the result potentially prevent 
migration/liveupdate or else?


The caller could use "GET_FEATURE 0" to see the available features, assuming
that nobody would have changed dom0's features.

I'm not sure whether we should prevent dom0's features to be overwritten.


I think it would be better to have a separate "domid" (maybe "server" or 
"global") to retrieve features supported by the server.


This would give us some flexibility to update dom0 features in the future if the 
needs arise (the first implementation may forbid it).


Fine with me.


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

[PATCH v4.1 11/11] xen/x86: remove cf_check attribute from hypercall handlers

[Juergen Gross]

Now that the hypercall handlers are all being called directly instead
through a function vector, the "cf_check" attribute can be removed.

Signed-off-by: Juergen Gross 
Reviewed-by: Daniel P. Smith  # xsm parts
Acked-by: Jan Beulich 
---
V4:
- new patch
---
 xen/arch/x86/compat.c   |  6 +++---
 xen/arch/x86/cpu/mcheck/mce.c   |  2 +-
 xen/arch/x86/cpu/vpmu.c |  2 +-
 xen/arch/x86/domain.c   |  3 +--
 xen/arch/x86/hvm/dm.c   |  2 +-
 xen/arch/x86/hvm/hvm.c  |  2 +-
 xen/arch/x86/hvm/hypercall.c|  6 +++---
 xen/arch/x86/mm.c   | 12 ++--
 xen/arch/x86/mm/paging.c|  2 +-
 xen/arch/x86/physdev.c  |  2 +-
 xen/arch/x86/platform_hypercall.c   |  2 +-
 xen/arch/x86/pv/callback.c  | 16 
 xen/arch/x86/pv/descriptor-tables.c |  8 
 xen/arch/x86/pv/iret.c  |  4 ++--
 xen/arch/x86/pv/misc-hypercalls.c   | 10 +-
 xen/arch/x86/pv/shim.c  |  4 ++--
 xen/arch/x86/x86_64/compat/mm.c |  2 +-
 xen/arch/x86/x86_64/domain.c|  2 +-
 xen/common/argo.c   |  4 ++--
 xen/common/compat/grant_table.c |  2 +-
 xen/common/compat/kernel.c  |  2 +-
 xen/common/compat/memory.c  |  3 +--
 xen/common/dm.c |  2 +-
 xen/common/domain.c |  2 +-
 xen/common/domctl.c |  2 +-
 xen/common/event_channel.c  |  2 +-
 xen/common/grant_table.c|  3 +--
 xen/common/hypfs.c  |  2 +-
 xen/common/kernel.c |  2 +-
 xen/common/kexec.c  |  4 ++--
 xen/common/memory.c |  2 +-
 xen/common/multicall.c  |  3 +--
 xen/common/sched/compat.c   |  2 +-
 xen/common/sched/core.c |  4 ++--
 xen/common/sysctl.c |  2 +-
 xen/common/xenoprof.c   |  2 +-
 xen/drivers/char/console.c  |  2 +-
 xen/scripts/gen_hypercall.awk   |  2 +-
 xen/xsm/xsm_core.c  |  4 ++--
 39 files changed, 68 insertions(+), 72 deletions(-)

diff --git a/xen/arch/x86/compat.c b/xen/arch/x86/compat.c
index 28281a262a..a031062830 100644
--- a/xen/arch/x86/compat.c
+++ b/xen/arch/x86/compat.c
@@ -15,7 +15,7 @@ typedef long ret_t;
 #endif
 
 /* Legacy hypercall (as of 0x00030202). */
-ret_t cf_check do_physdev_op_compat(XEN_GUEST_HANDLE_PARAM(physdev_op_t) uop)
+ret_t do_physdev_op_compat(XEN_GUEST_HANDLE_PARAM(physdev_op_t) uop)
 {
 struct physdev_op op;
 
@@ -28,7 +28,7 @@ ret_t cf_check 
do_physdev_op_compat(XEN_GUEST_HANDLE_PARAM(physdev_op_t) uop)
 #ifndef COMPAT
 
 /* Legacy hypercall (as of 0x00030101). */
-long cf_check do_sched_op_compat(int cmd, unsigned long arg)
+long do_sched_op_compat(int cmd, unsigned long arg)
 {
 switch ( cmd )
 {
@@ -50,7 +50,7 @@ long cf_check do_sched_op_compat(int cmd, unsigned long arg)
 }
 
 /* Legacy hypercall (as of 0x00030202). */
-long cf_check do_event_channel_op_compat(
+long do_event_channel_op_compat(
 XEN_GUEST_HANDLE_PARAM(evtchn_op_t) uop)
 {
 struct evtchn_op op;
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 275c54be7c..f68e31b643 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1351,7 +1351,7 @@ CHECK_mcinfo_recovery;
 # endif /* CONFIG_COMPAT */
 
 /* Machine Check Architecture Hypercall */
-long cf_check do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
+long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
 {
 long ret = 0;
 struct xen_mc curop, *op = 
diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index 51d171615f..d2c03a1104 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -672,7 +672,7 @@ void vpmu_dump(struct vcpu *v)
 alternative_vcall(vpmu_ops.arch_vpmu_dump, v);
 }
 
-long cf_check do_xenpmu_op(
+long do_xenpmu_op(
 unsigned int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
 {
 int ret;
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index d566fc82b4..ddf969f76e 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1489,8 +1489,7 @@ int arch_vcpu_reset(struct vcpu *v)
 return 0;
 }
 
-long cf_check do_vcpu_op(int cmd, unsigned int vcpuid,
- XEN_GUEST_HANDLE_PARAM(void) arg)
+long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
 long rc = 0;
 struct domain *d = current->domain;
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index d80975efcf..f8e6089870 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -654,7 +654,7 @@ CHECK_dm_op_relocate_memory;
 CHECK_dm_op_pin_memory_cacheattr;
 CHECK_dm_op_nr_vcpus;
 
-int cf_check compat_dm_op(
+int compat_dm_op(
 domid_t domid, unsigned int nr_bufs, XEN_GUEST_HANDLE_PARAM(void) bufs)
 {
 struct dmop_args args;
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 

[PATCH v4.1 02/11] xen: move do_vcpu_op() to arch specific code

[Juergen Gross]

The entry point used for the vcpu_op hypercall on Arm is different
from the one on x86 today, as some of the common sub-ops are not
supported on Arm. The Arm specific handler filters out the not
supported sub-ops and then calls the common handler. This leads to the
weird call hierarchy:

  do_arm_vcpu_op()
do_vcpu_op()
  arch_do_vcpu_op()

Clean this up by renaming do_vcpu_op() to common_vcpu_op() and
arch_do_vcpu_op() in each architecture to do_vcpu_op(). This way one
of above calls can be avoided without restricting any potential
future use of common sub-ops for Arm.

Signed-off-by: Juergen Gross 
---
V4:
- don't remove HYPERCALL_ARM()
V4.1:
- add missing cf_check (Andrew Cooper)
---
 xen/arch/arm/domain.c| 15 ---
 xen/arch/arm/include/asm/hypercall.h |  2 --
 xen/arch/arm/traps.c |  2 +-
 xen/arch/x86/domain.c| 12 
 xen/arch/x86/include/asm/hypercall.h |  2 +-
 xen/arch/x86/x86_64/domain.c | 18 +-
 xen/common/compat/domain.c   | 15 ++-
 xen/common/domain.c  | 12 
 xen/include/xen/hypercall.h  |  2 +-
 9 files changed, 42 insertions(+), 38 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 8110c1df86..2f8eaab7b5 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -1079,23 +1079,24 @@ void arch_dump_domain_info(struct domain *d)
 }
 
 
-long do_arm_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) 
arg)
+long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
+struct domain *d = current->domain;
+struct vcpu *v;
+
+if ( (v = domain_vcpu(d, vcpuid)) == NULL )
+return -ENOENT;
+
 switch ( cmd )
 {
 case VCPUOP_register_vcpu_info:
 case VCPUOP_register_runstate_memory_area:
-return do_vcpu_op(cmd, vcpuid, arg);
+return common_vcpu_op(cmd, v, arg);
 default:
 return -EINVAL;
 }
 }
 
-long arch_do_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
-{
-return -ENOSYS;
-}
-
 void arch_dump_vcpu_info(struct vcpu *v)
 {
 gic_dump_info(v);
diff --git a/xen/arch/arm/include/asm/hypercall.h 
b/xen/arch/arm/include/asm/hypercall.h
index 39d2e7889d..fac4d60f17 100644
--- a/xen/arch/arm/include/asm/hypercall.h
+++ b/xen/arch/arm/include/asm/hypercall.h
@@ -4,8 +4,6 @@
 #include  /* for arch_do_domctl */
 int do_arm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
 
-long do_arm_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) 
arg);
-
 long subarch_do_domctl(struct xen_domctl *domctl, struct domain *d,
XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl);
 
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index f8c3ef0ca2..deb07784d9 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1380,7 +1380,7 @@ static arm_hypercall_t arm_hypercall_table[] = {
 #endif
 HYPERCALL(multicall, 2),
 HYPERCALL(platform_op, 1),
-HYPERCALL_ARM(vcpu_op, 3),
+HYPERCALL(vcpu_op, 3),
 HYPERCALL(vm_assist, 2),
 #ifdef CONFIG_ARGO
 HYPERCALL(argo_op, 5),
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index a5048ed654..d566fc82b4 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1489,11 +1489,15 @@ int arch_vcpu_reset(struct vcpu *v)
 return 0;
 }
 
-long
-arch_do_vcpu_op(
-int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
+long cf_check do_vcpu_op(int cmd, unsigned int vcpuid,
+ XEN_GUEST_HANDLE_PARAM(void) arg)
 {
 long rc = 0;
+struct domain *d = current->domain;
+struct vcpu *v;
+
+if ( (v = domain_vcpu(d, vcpuid)) == NULL )
+return -ENOENT;
 
 switch ( cmd )
 {
@@ -1545,7 +1549,7 @@ arch_do_vcpu_op(
 }
 
 default:
-rc = -ENOSYS;
+rc = common_vcpu_op(cmd, v, arg);
 break;
 }
 
diff --git a/xen/arch/x86/include/asm/hypercall.h 
b/xen/arch/x86/include/asm/hypercall.h
index 61bf897147..d6daa7e4cb 100644
--- a/xen/arch/x86/include/asm/hypercall.h
+++ b/xen/arch/x86/include/asm/hypercall.h
@@ -145,7 +145,7 @@ compat_physdev_op(
 XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern int
-arch_compat_vcpu_op(
+compat_common_vcpu_op(
 int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern int cf_check compat_mmuext_op(
diff --git a/xen/arch/x86/x86_64/domain.c b/xen/arch/x86/x86_64/domain.c
index c46dccc25a..9c559aa3ea 100644
--- a/xen/arch/x86/x86_64/domain.c
+++ b/xen/arch/x86/x86_64/domain.c
@@ -12,11 +12,15 @@
 CHECK_vcpu_get_physid;
 #undef xen_vcpu_get_physid
 
-int
-arch_compat_vcpu_op(
-int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
+int cf_check
+compat_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
-int rc = -ENOSYS;
+int rc;
+struct domain *d = current->domain;
+struct vcpu *v;
+
+if