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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  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-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 

[Xen-devel] [ovmf test] 146581: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
145767

version targeted for testing:
 ovmf 83357313dd6750e5c3c4e290676acee9d391d9e3
baseline version:
 ovmf 70911f1f4aee0366b6122f2b90d367ec0f066beb

Last test of basis   145767  2020-01-08 00:39:09 Z   22 days
Failing since145774  2020-01-08 02:50:20 Z   22 days   83 attempts
Testing same since   146581  2020-01-29 21:09:58 Z0 days1 attempts


People who touched revisions under test:
  Aaron Li 
  Albecki, Mateusz 
  Anthony PERARD 
  Ard Biesheuvel 
  Ashish Singhal 
  Bob Feng 
  Brian R Haug 
  Eric Dong 
  Fan, ZhijuX 
  Hao A Wu 
  Jason Voelz 
  Jian J Wang 
  Krzysztof Koch 
  Laszlo Ersek 
  Leif Lindholm 
  Li, Aaron 
  Liming Gao 
  Mateusz Albecki 
  Michael D Kinney 
  Michael Kubacki 
  Pavana.K 
  Philippe Mathieu-Daud? 
  Philippe Mathieu-Daude 
  Siyuan Fu 
  Siyuan, Fu 
  Sudipto Paul 
  Vitaly Cheptsov 
  Vitaly Cheptsov via Groups.Io 
  Wei6 Xu 
  Xu, Wei6 
  Zhiguang Liu 
  Zhiju.Fan 

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



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

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

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

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


Not pushing.

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

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

[Xen-devel] [linux-5.4 test] 146580: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs. 
146121
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
146121
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
146121
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install   fail REGR. vs. 146121

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10   fail REGR. vs. 146121
 test-armhf-armhf-xl-rtds 12 guest-start  fail REGR. vs. 146121

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

version targeted for testing:
 linux60b6aa2b71efa7e0bd5393ce292ace4a0cf2e71b
baseline version:
 linux122179cb7d648a6f36b20dd6bf34f953cb384c30

Last test of basis   146121  2020-01-15 17:42:04 Z   14 days

[Xen-devel] [xen-unstable test] 146578: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64  7 xen-boot fail REGR. vs. 146563
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 15 
depriv-audit-qemu/create fail REGR. vs. 146563

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

version targeted for testing:
 xen  a29f19f7476a13cd6d7757b3aa5eb26ffd9e3c54
baseline version:
 xen  f910c3ebc6a178c5cbbc0868134be536fae7f7cf

Last test of basis   146563  2020-01-29 01:55:30 Z1 days
Testing same since   146578  2020-01-29 17:06:19 Z0 days1 attempts

Re: [Xen-devel] libvirt support for scheduler credit2

[Jim Fehlig]

On 1/29/20 4:10 AM, Dario Faggioli wrote:
> On Wed, 2020-01-22 at 18:56 +, Jim Fehlig wrote:
>> On 1/21/20 10:05 AM, Jürgen Groß wrote:
>>> On 21.01.20 17:56, Kevin Stange wrote:

 Since Xen 4.12, credit2 is the default scheduler, but at least as
 of
 libvirt 5.1.0 virsh doesn't appear to understand credit2 and
 produces
 this sort of output:
>>
>> You would see the same with libvirt.git master, sorry. ATM the
>> libvirt libxl
>> driver is unaware of the credit2 scheduler.
>>
> Right. I Just sent the patch:
> https://www.redhat.com/archives/libvir-list/2020-January/msg01292.html

Thanks! I tweaked it a bit and committed to libvirt.git

https://libvirt.org/git/?p=libvirt.git;a=commit;h=849052ec61e18780713bec171748e859e32dfd6d

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 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-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 

Re: [Xen-devel] [PATCH] golang/xenlight: implement constructor generation

[Nick Rosbrook]

George,

Note that without your patch "golang/xenlight: Don't try to marshall
zero-length arrays in fromC", some of these constructors will panic.

Thanks,
-NR

On Wed, Jan 29, 2020 at 7:09 PM Nick Rosbrook  wrote:
>
> Generate constructors for generated Go types. Call libxl__init so
> the Go type can be properly initialized.
>
> If a type has a keyed union field, add a parameter to the function
> signature to set the key variable, and call the init function for the
> keyed union.
>
> Signed-off-by: Nick Rosbrook 
> ---
>  tools/golang/xenlight/gengotypes.py  |   65 ++
>  tools/golang/xenlight/helpers.gen.go | 1002 +-
>  2 files changed, 1049 insertions(+), 18 deletions(-)
>
> diff --git a/tools/golang/xenlight/gengotypes.py 
> b/tools/golang/xenlight/gengotypes.py
> index b09cffb829..aec153098d 100644
> --- a/tools/golang/xenlight/gengotypes.py
> +++ b/tools/golang/xenlight/gengotypes.py
> @@ -225,6 +225,9 @@ def xenlight_golang_generate_helpers(path = None, types = 
> None, comment = None):
>  if not isinstance(ty, idl.Struct):
>  continue
>
> +f.write(xenlight_golang_define_constructor(ty))
> +f.write('\n')
> +
>  (fdef, extras) = xenlight_golang_define_from_C(ty)
>
>  f.write(fdef)
> @@ -619,6 +622,68 @@ def xenlight_golang_array_to_C(ty = None):
>
>  return s
>
> +def xenlight_golang_define_constructor(ty = None):
> +s = ''
> +
> +ctypename  = ty.typename
> +gotypename = xenlight_golang_fmt_name(ctypename)
> +
> +# Since this func is exported, add a comment as per Go conventions.
> +s += '// New{} returns an instance of {}'.format(gotypename,gotypename)
> +s += ' initialized with defaults.\n'
> +
> +# If a struct has a keyed union, an extra argument is
> +# required in the function signature, and an extra _init
> +# call is needed.
> +params   = []
> +init_fns = []
> +
> +# Add call to parent init_fn first.
> +init_fns.append('C.{}()'.format(ty.init_fn))
> +
> +for f in ty.fields:
> +if not isinstance(f.type, idl.KeyedUnion):
> +continue
> +
> +param = f.type.keyvar
> +
> +param_ctype  = param.type.typename
> +param_gotype = xenlight_golang_fmt_name(param_ctype)
> +param_goname = xenlight_golang_fmt_name(param.name,exported=False)
> +
> +# Serveral keyed unions use 'type' as the key variable name. In
> +# that case, prepend the first letter of the Go type name.
> +if param_goname == 'type':
> +param_goname = '{}type'.format(param_gotype.lower()[0])
> +
> +# Add call to keyed union's init_fn.
> +init_fns.append('C.{}_{}(, C.{}({}))'.format(ty.init_fn,
> +param.name,
> +param_ctype,
> +param_goname))
> +
> +# Add to params list.
> +params.append('{} {}'.format(param_goname, param_gotype))
> +
> +# Define function
> +s += 'func New{}({}) (*{}, error) {{\n'.format(gotypename,
> +   ','.join(params),
> +   gotypename)
> +
> +# Declare variables.
> +s += 'var (\nx {}\nxc C.{})\n\n'.format(gotypename, ctypename)
> +
> +# Write init_fn calls.
> +s += '\n'.join(init_fns)
> +s += '\n\n'
> +
> +# Call fromC to initialize Go type.
> +s += 'if err := x.fromC(); err != nil {\n'
> +s += 'return nil, err }\n\n'
> +s += 'return , nil}\n'
> +
> +return s
> +
>  def xenlight_golang_fmt_name(name, exported = True):
>  """
>  Take a given type name and return an
> diff --git a/tools/golang/xenlight/helpers.gen.go 
> b/tools/golang/xenlight/helpers.gen.go
> index 746d99b5ba..225ba6868e 100644
> --- a/tools/golang/xenlight/helpers.gen.go
> +++ b/tools/golang/xenlight/helpers.gen.go
> @@ -30,6 +30,22 @@ typedef typeof(((struct libxl_psr_hw_info 
> *)NULL)->u.mba)libxl_psr_hw_info_type_
>  */
>  import "C"
>
> +// NewIoportRange returns an instance of IoportRange initialized with 
> defaults.
> +func NewIoportRange() (*IoportRange, error) {
> +   var (
> +   x  IoportRange
> +   xc C.libxl_ioport_range
> +   )
> +
> +   C.libxl_ioport_range_init()
> +
> +   if err := x.fromC(); err != nil {
> +   return nil, err
> +   }
> +
> +   return , nil
> +}
> +
>  func (x *IoportRange) fromC(xc *C.libxl_ioport_range) error {
> x.First = uint32(xc.first)
> x.Number = uint32(xc.number)
> @@ -50,6 +66,22 @@ func (x *IoportRange) toC(xc *C.libxl_ioport_range) (err 
> error) {
> return nil
>  }
>
> +// NewIomemRange returns an instance of IomemRange initialized with defaults.
> +func NewIomemRange() (*IomemRange, error) {
> +   var (
> +   x  IomemRange

[Xen-devel] [PATCH] golang/xenlight: implement constructor generation

[Nick Rosbrook]

Generate constructors for generated Go types. Call libxl__init so
the Go type can be properly initialized.

If a type has a keyed union field, add a parameter to the function
signature to set the key variable, and call the init function for the
keyed union.

Signed-off-by: Nick Rosbrook 
---
 tools/golang/xenlight/gengotypes.py  |   65 ++
 tools/golang/xenlight/helpers.gen.go | 1002 +-
 2 files changed, 1049 insertions(+), 18 deletions(-)

diff --git a/tools/golang/xenlight/gengotypes.py 
b/tools/golang/xenlight/gengotypes.py
index b09cffb829..aec153098d 100644
--- a/tools/golang/xenlight/gengotypes.py
+++ b/tools/golang/xenlight/gengotypes.py
@@ -225,6 +225,9 @@ def xenlight_golang_generate_helpers(path = None, types = 
None, comment = None):
 if not isinstance(ty, idl.Struct):
 continue
 
+f.write(xenlight_golang_define_constructor(ty))
+f.write('\n')
+
 (fdef, extras) = xenlight_golang_define_from_C(ty)
 
 f.write(fdef)
@@ -619,6 +622,68 @@ def xenlight_golang_array_to_C(ty = None):
 
 return s
 
+def xenlight_golang_define_constructor(ty = None):
+s = ''
+
+ctypename  = ty.typename
+gotypename = xenlight_golang_fmt_name(ctypename)
+
+# Since this func is exported, add a comment as per Go conventions.
+s += '// New{} returns an instance of {}'.format(gotypename,gotypename)
+s += ' initialized with defaults.\n'
+
+# If a struct has a keyed union, an extra argument is
+# required in the function signature, and an extra _init
+# call is needed.
+params   = []
+init_fns = []
+
+# Add call to parent init_fn first.
+init_fns.append('C.{}()'.format(ty.init_fn))
+
+for f in ty.fields:
+if not isinstance(f.type, idl.KeyedUnion):
+continue
+
+param = f.type.keyvar
+
+param_ctype  = param.type.typename
+param_gotype = xenlight_golang_fmt_name(param_ctype)
+param_goname = xenlight_golang_fmt_name(param.name,exported=False)
+
+# Serveral keyed unions use 'type' as the key variable name. In
+# that case, prepend the first letter of the Go type name.
+if param_goname == 'type':
+param_goname = '{}type'.format(param_gotype.lower()[0])
+
+# Add call to keyed union's init_fn.
+init_fns.append('C.{}_{}(, C.{}({}))'.format(ty.init_fn,
+param.name,
+param_ctype,
+param_goname))
+
+# Add to params list.
+params.append('{} {}'.format(param_goname, param_gotype))
+
+# Define function
+s += 'func New{}({}) (*{}, error) {{\n'.format(gotypename,
+   ','.join(params),
+   gotypename)
+
+# Declare variables.
+s += 'var (\nx {}\nxc C.{})\n\n'.format(gotypename, ctypename)
+
+# Write init_fn calls.
+s += '\n'.join(init_fns)
+s += '\n\n'
+
+# Call fromC to initialize Go type.
+s += 'if err := x.fromC(); err != nil {\n'
+s += 'return nil, err }\n\n'
+s += 'return , nil}\n'
+
+return s
+
 def xenlight_golang_fmt_name(name, exported = True):
 """
 Take a given type name and return an
diff --git a/tools/golang/xenlight/helpers.gen.go 
b/tools/golang/xenlight/helpers.gen.go
index 746d99b5ba..225ba6868e 100644
--- a/tools/golang/xenlight/helpers.gen.go
+++ b/tools/golang/xenlight/helpers.gen.go
@@ -30,6 +30,22 @@ typedef typeof(((struct libxl_psr_hw_info 
*)NULL)->u.mba)libxl_psr_hw_info_type_
 */
 import "C"
 
+// NewIoportRange returns an instance of IoportRange initialized with defaults.
+func NewIoportRange() (*IoportRange, error) {
+   var (
+   x  IoportRange
+   xc C.libxl_ioport_range
+   )
+
+   C.libxl_ioport_range_init()
+
+   if err := x.fromC(); err != nil {
+   return nil, err
+   }
+
+   return , nil
+}
+
 func (x *IoportRange) fromC(xc *C.libxl_ioport_range) error {
x.First = uint32(xc.first)
x.Number = uint32(xc.number)
@@ -50,6 +66,22 @@ func (x *IoportRange) toC(xc *C.libxl_ioport_range) (err 
error) {
return nil
 }
 
+// NewIomemRange returns an instance of IomemRange initialized with defaults.
+func NewIomemRange() (*IomemRange, error) {
+   var (
+   x  IomemRange
+   xc C.libxl_iomem_range
+   )
+
+   C.libxl_iomem_range_init()
+
+   if err := x.fromC(); err != nil {
+   return nil, err
+   }
+
+   return , nil
+}
+
 func (x *IomemRange) fromC(xc *C.libxl_iomem_range) error {
x.Start = uint64(xc.start)
x.Number = uint64(xc.number)
@@ -72,6 +104,22 @@ func (x *IomemRange) toC(xc *C.libxl_iomem_range) (err 
error) {
return nil
 }
 
+// NewVgaInterfaceInfo returns an 

Re: [Xen-devel] HVM Driver Domain

[tosher 1]

 > BTW, are you creating the driver domain with 'driver_domain=1' in the xl 
 > config file?

No, I wasn't aware of the 'driver_domain' configuration option before, and this 
is what I was missing. With this configuration option, I was able to make the 
HVM driver domain work. However, the PV driver domain worked fine without this 
option configured.

> Are you sure this command is run on the driver domain?

Since I had installed xen-utils in the driver domain for the bridge to work, it 
installed Xen hypervisor in the driver domain. As a result, my driver domain 
became another Dom0. Realizing that I ran regular Ubuntu in the driver domain. 
This was another key point to make the driver domain work.

Thanks for all your help, which made it possible for me to test the HVM driver 
domain.

One last thing, backend interfaces are not being added to the bridge 
automatically.  Do you think it is because regular Ubuntu doesn't have Xen vif 
scripts? If yes, what is the proper thing to do in this case?

Please let me know.

Thanks,
Mehrab


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

Re: [Xen-devel] [PATCH] xen-bus/block: explicitly assign event channels to an AioContext

[Julien Grall]

Hi Anthony,

On 19/12/2019 17:11, Anthony PERARD wrote:

On Mon, Dec 16, 2019 at 02:34:51PM +, Paul Durrant wrote:

It is not safe to close an event channel from the QEMU main thread when
that channel's poller is running in IOThread context.

This patch adds a new xen_device_set_event_channel_context() function
to explicitly assign the channel AioContext, and modifies
xen_device_bind_event_channel() to initially assign the channel's poller
to the QEMU main thread context. The code in xen-block's dataplane is
then modified to assign the channel to IOThread context during
xen_block_dataplane_start() and de-assign it during in
xen_block_dataplane_stop(), such that the channel is always assigned
back to main thread context before it is closed. aio_set_fd_handler()
already deals with all the necessary synchronization when moving an fd
between AioContext-s so no extra code is needed to manage this.

Reported-by: Julien Grall 
Signed-off-by: Paul Durrant 


Reviewed-by: Anthony PERARD 


I can't find the patch in QEMU upstream. Are we missing any ack/review 
for this patch?





Tested against an HVM debian guest with a QCOW2 image as system disk, and
as a hot-plugged/unplgged secondary disk.


And I've run an osstest flight with the patch.

Thanks,



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] Introduce a description of a new optional tag for Backports

[Julien Grall]

Hi,

I have noticed Wei began to use the tag today. It reminded me that I 
never followed-up on the patch, sorry for that.


On 08/11/2019 19:09, Stefano Stabellini wrote:

Signed-off-by: Stefano Stabellini 
CC: jbeul...@suse.com
CC: george.dun...@citrix.com
CC: jul...@xen.org
CC: lars.ku...@citrix.com
CC: andrew.coop...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: konrad.w...@oracle.com
CC: w...@xen.org
---
  docs/process/backport-tag.pandoc | 23 +++
  1 file changed, 23 insertions(+)
  create mode 100644 docs/process/backport-tag.pandoc

diff --git a/docs/process/backport-tag.pandoc b/docs/process/backport-tag.pandoc
new file mode 100644
index 00..e570efdcc8
--- /dev/null
+++ b/docs/process/backport-tag.pandoc
@@ -0,0 +1,23 @@
+Backport Tag
+
+
+A backport tag is an optional tag in the commit message to request a
+given commit to be backported to the stable trees:
+
+Backport: all
+
+It marks a commit for being a candidate for backports to all relevant
+trees.
+
+Backport: 4.9+
+
+It marks a commit for being a candidate for backports to all stable
+trees from 4.9 onward.
+
+Maintainers request the Backport tag to be added on commit.
+Contributors are also welcome to mark their patches with the Backport
+tag when they deem appropriate. Maintainers will request for it to be
+removed when that is not the case.
+
+Please note that the Backport tag is a **request** for backport, which
+will still need to be evaluated by the stable tree maintainers.


This proposal look good to me. Are you planning to resend the patch with 
George's suggestion?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [Vote] Approve hypervisor project check-in policy

[Julien Grall]

Hi all,

+1.

Cheers,

On 27/01/2020 14:12, George Dunlap wrote:

I have drafted an explicit policy on what is (generally) required to
check a patch in.  It's been through several rounds, and v4 has been
acked [1].

I've had informal assent from all committers, but just to dot all our
i's and cross all our t's, it's probably worth having a vote of the
committers, in line with the XenProject governance policy [1].

Please respond by 10 February with your vote:
+1: for proposal
-1: against proposal
in public or private.

Thanks,
  -George

[1] https://marc.info/?i=<20200113150455.400733-1-george.dun...@citrix.com>
[2] https://xenproject.org/developers/governance/

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



--
Julien Grall

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

Re: [Xen-devel] [PATCH] xen/arm: Implement GICD_IGRPMODR as RAZ/WI for VGICv3

[Julien Grall]

Hi Jeff,

On 21/01/2020 14:39, Jeff Kubascik wrote:

The VGICv3 module does not implement security extensions for guests.
Furthermore, per the ARM Generic Interrupt Controller Architecture
Specification (ARM IHI 0069E), section 9.9.15, the GICD_IGRPMODR
register should be RAZ/WI to non-secure accesses when GICD_CTLR.DS = 0.
This implements the GICD_IGRPMODR register for guest VMs as RAZ/WI, to
avoid a data abort in the case the guest attempts to read or write the
register.


Per the spec, all reserved registers should be RAZ/WI. So how about 
implementing the default case as read_as_zero/write_ignore?


This would also cover some problem that may arise with future Linux. I 
have actually been told that Linux will access registers (IIRC GICv4 
specific) that may not have been implemented by Xen and should be RAZ/WI.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 2/2] docs/designs: Add a design document for migration of xenstore data

[Marek Marczykowski-Górecki]

On Wed, Jan 29, 2020 at 02:47:02PM +, Paul Durrant wrote:



> +**node data**
> +
> +
> +`|||`
> +
> +
> +`` is considered relative to the domain path `/local/domain/$domid`
> +and hence must not begin with `/`.

How backend settings are going to be serialized? For example vif backend
has a bunch of feature-* entries, which should not change under the
guest feet during non-cooperative migration.

> +`` and `` should be suitable to formulate a `WRITE` operation
> +to the receiving xenstore and `` should be similarly suitable
> +to formulate a subsequent `SET_PERMS` operation.
> +
> +**watch data**
> +
> +
> +`||`
> +
> +`` again is considered relative and, together with ``, should
> +be suitable to formulate an `ADD_DOMAIN_WATCHES` operation (see below).
> +
> +
> +### Protocol Extension
> +
> +The `WATCH` operation does not allow specification of a ``; it is
> +assumed that the watch pertains to the domain that owns the shared ring
> +over which the operation is passed. Hence, for the tool-stack to be able
> +to register a watch on behalf of a domain a new operation is needed:
> +
> +```
> +ADD_DOMAIN_WATCHES  ||+
> +
> +Adds watches on behalf of the specified domain.
> +
> + is a NUL separated tuple of |. The semantics of this
> +operation are identical to the domain issuing WATCH || for
> +each .
> +```

Normal WATCH operation triggers an event immediately. Is it intended in
this case too? On the other hand, guest should cope with spurious watch
events, so probably not an issue.

> +The watch information for a domain also needs to be extracted from the
> +sending xenstored so the following operation is also needed:
> +
> +```
> +GET_DOMAIN_WATCHES  |   ||* 
> +
> +Gets the list of watches that are currently registered for the domain.
> +
> + is a NUL separated tuple of |. The sub-list returned
> +will start at  into the the overall list of watches and may be
> +truncated such that the returned data fits within XENSTORE_PAYLOAD_MAX.
> +If  is beyond the end of the overall list then the returned sub-
> +list will be empty. If the value of  changes then it indicates
> +that the overall watch list has changed and thus it may be necessary
> +to re-issue the operation for previous values of .
> +```

In what units  is expressed? bytes? entries?
Can the response be truncated at arbitrary place, or only between
records?

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


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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-shadow

[Xen-devel] [ovmf test] 146575: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
145767

version targeted for testing:
 ovmf c8b8157e126ae2fb6f65842677251d300ceff104
baseline version:
 ovmf 70911f1f4aee0366b6122f2b90d367ec0f066beb

Last test of basis   145767  2020-01-08 00:39:09 Z   21 days
Failing since145774  2020-01-08 02:50:20 Z   21 days   82 attempts
Testing same since   146482  2020-01-24 19:39:39 Z5 days   21 attempts


People who touched revisions under test:
  Aaron Li 
  Albecki, Mateusz 
  Ard Biesheuvel 
  Ashish Singhal 
  Bob Feng 
  Brian R Haug 
  Eric Dong 
  Fan, ZhijuX 
  Hao A Wu 
  Jason Voelz 
  Jian J Wang 
  Krzysztof Koch 
  Laszlo Ersek 
  Leif Lindholm 
  Li, Aaron 
  Liming Gao 
  Mateusz Albecki 
  Michael D Kinney 
  Michael Kubacki 
  Pavana.K 
  Philippe Mathieu-Daud? 
  Philippe Mathieu-Daude 
  Siyuan Fu 
  Siyuan, Fu 
  Sudipto Paul 
  Vitaly Cheptsov 
  Vitaly Cheptsov via Groups.Io 
  Wei6 Xu 
  Xu, Wei6 
  Zhiguang Liu 
  Zhiju.Fan 

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



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

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

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

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


Not pushing.

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

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

[Xen-devel] [linux-5.4 test] 146574: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
146121
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
146121

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

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

version targeted for testing:
 linux111e415c94f5c299de1ee50c825b60e63d5919e9
baseline version:
 linux122179cb7d648a6f36b20dd6bf34f953cb384c30

Last test of basis   146121  2020-01-15 17:42:04 Z   14 days
Failing 

[Xen-devel] [PATCH v5 07/12] x86/hyperv: setup hypercall page

[Wei Liu]

Hyper-V uses a technique called overlay page for its hypercall page. It
will insert a backing page to the guest when the hypercall functionality
is enabled. That means we can use a page that is not backed by real
memory for hypercall page.

Use the top-most addressable page for that purpose. Adjust e820 code
accordingly.

We also need to register Xen's guest OS ID to Hyper-V. Use 0x3 as the
vendor ID. Fix the comment in hyperv-tlfs.h while at it.

Signed-off-by: Wei Liu 
---
v5:
1. use hypervisor_reserve_top_pages
2. add a macro for hypercall page mfn
3. address other misc comments

v4:
1. Use fixmap
2. Follow routines listed in TLFS
---
 xen/arch/x86/e820.c |  5 +++
 xen/arch/x86/guest/hyperv/hyperv.c  | 57 +++--
 xen/include/asm-x86/guest/hyperv-tlfs.h |  5 ++-
 xen/include/asm-x86/guest/hyperv.h  |  3 ++
 4 files changed, 65 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
index 3892c9cfb7..99643f3ea0 100644
--- a/xen/arch/x86/e820.c
+++ b/xen/arch/x86/e820.c
@@ -343,6 +343,7 @@ static unsigned long __init find_max_pfn(void)
 {
 unsigned int i;
 unsigned long max_pfn = 0;
+unsigned long top_pfn = ((1ull << paddr_bits) - 1) >> PAGE_SHIFT;
 
 for (i = 0; i < e820.nr_map; i++) {
 unsigned long start, end;
@@ -357,6 +358,10 @@ static unsigned long __init find_max_pfn(void)
 max_pfn = end;
 }
 
+top_pfn -= hypervisor_reserve_top_pages();
+if ( max_pfn >= top_pfn )
+max_pfn = top_pfn;
+
 return max_pfn;
 }
 
diff --git a/xen/arch/x86/guest/hyperv/hyperv.c 
b/xen/arch/x86/guest/hyperv/hyperv.c
index 8d38313d7a..2bedcc438c 100644
--- a/xen/arch/x86/guest/hyperv/hyperv.c
+++ b/xen/arch/x86/guest/hyperv/hyperv.c
@@ -19,15 +19,26 @@
  * Copyright (c) 2019 Microsoft.
  */
 #include 
+#include 
 
+#include 
 #include 
 #include 
+#include 
 
 struct ms_hyperv_info __read_mostly ms_hyperv;
 
-static const struct hypervisor_ops ops = {
-.name = "Hyper-V",
-};
+static uint64_t generate_guest_id(void)
+{
+uint64_t id;
+
+id = (uint64_t)HV_XEN_VENDOR_ID << 48;
+id |= (xen_major_version() << 16) | xen_minor_version();
+
+return id;
+}
+
+static const struct hypervisor_ops ops;
 
 const struct hypervisor_ops *__init hyperv_probe(void)
 {
@@ -72,6 +83,46 @@ const struct hypervisor_ops *__init hyperv_probe(void)
 return 
 }
 
+static void __init setup_hypercall_page(void)
+{
+union hv_x64_msr_hypercall_contents hypercall_msr;
+union hv_guest_os_id guest_id;
+unsigned long mfn;
+
+rdmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id.raw);
+if ( !guest_id.raw )
+{
+guest_id.raw = generate_guest_id();
+wrmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id.raw);
+}
+
+rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
+if ( !hypercall_msr.enable )
+{
+mfn = HV_HCALL_MFN;
+hypercall_msr.enable = 1;
+hypercall_msr.guest_physical_address = mfn;
+wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
+} else {
+mfn = hypercall_msr.guest_physical_address;
+}
+
+rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
+BUG_ON(!hypercall_msr.enable);
+
+set_fixmap_x(FIX_X_HYPERV_HCALL, mfn << PAGE_SHIFT);
+}
+
+static void __init setup(void)
+{
+setup_hypercall_page();
+}
+
+static const struct hypervisor_ops ops = {
+.name = "Hyper-V",
+.setup = setup,
+};
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-x86/guest/hyperv-tlfs.h 
b/xen/include/asm-x86/guest/hyperv-tlfs.h
index 05c4044976..07db57b55f 100644
--- a/xen/include/asm-x86/guest/hyperv-tlfs.h
+++ b/xen/include/asm-x86/guest/hyperv-tlfs.h
@@ -318,15 +318,16 @@ struct ms_hyperv_tsc_page {
  *
  * Bit(s)
  * 63 - Indicates if the OS is Open Source or not; 1 is Open Source
- * 62:56 - Os Type; Linux is 0x100
+ * 62:56 - Os Type; Linux 0x1, FreeBSD 0x2, Xen 0x3
  * 55:48 - Distro specific identification
- * 47:16 - Linux kernel version number
+ * 47:16 - Guest OS version number
  * 15:0  - Distro specific identification
  *
  *
  */
 
 #define HV_LINUX_VENDOR_ID  0x8100
+#define HV_XEN_VENDOR_ID0x8300
 union hv_guest_os_id
 {
 uint64_t raw;
diff --git a/xen/include/asm-x86/guest/hyperv.h 
b/xen/include/asm-x86/guest/hyperv.h
index c7a7f32bd5..0dcd8082ad 100644
--- a/xen/include/asm-x86/guest/hyperv.h
+++ b/xen/include/asm-x86/guest/hyperv.h
@@ -21,6 +21,9 @@
 
 #include 
 
+/* Use top-most MFN for hypercall page */
+#define HV_HCALL_MFN (((1ull << paddr_bits) - 1) >> HV_HYP_PAGE_SHIFT)
+
 /*
  * The specification says: "The partition reference time is computed
  * by the following formula:
-- 
2.20.1


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

[Xen-devel] [PATCH v5 01/12] MAINTAINERS: put Hyper-V code under Viridian maintainership

[Wei Liu]

And add myself as a maintainer.

Sort the list alphabetically while at it.

Signed-off-by: Wei Liu 
Signed-off-by: Wei Liu 
---
 MAINTAINERS | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1915e09f8b..04d91482cd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -514,10 +514,13 @@ F:xen/arch/x86/mm/shadow/
 
 X86 VIRIDIAN ENLIGHTENMENTS
 M: Paul Durrant 
+M: Wei Liu 
 S: Supported
+F: xen/arch/x86/guest/hyperv/
 F: xen/arch/x86/hvm/viridian/
-F: xen/include/asm-x86/hvm/viridian.h
+F: xen/include/asm-x86/guest/hyperv.h
 F: xen/include/asm-x86/guest/hyperv-tlfs.h
+F: xen/include/asm-x86/hvm/viridian.h
 
 XENTRACE
 M: George Dunlap 
-- 
2.20.1


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

[Xen-devel] [PATCH v5 10/12] x86/hyperv: provide percpu hypercall input page

[Wei Liu]

Hyper-V's input / output argument must be 8 bytes aligned an not cross
page boundary. One way to satisfy those requirements is to use percpu
page.

For the foreseeable future we only need to provide input for TLB
and APIC hypercalls, so skip setting up an output page.

We will also need to provide an ap_setup hook for secondary cpus to
setup its own input page.

Signed-off-by: Wei Liu 
---
v5:
1. Adjust to new ap_setup
2. Change variable name to hv_pcpu_input_page

v4:
1. Change wording in commit message
2. Prevent leak
3. Introduce a private header

v3:
1. Use xenheap page instead
2. Drop page tracking structure
3. Drop Paul's review tag
---
 xen/arch/x86/guest/hyperv/hyperv.c  | 31 +
 xen/arch/x86/guest/hyperv/private.h | 29 +++
 2 files changed, 60 insertions(+)
 create mode 100644 xen/arch/x86/guest/hyperv/private.h

diff --git a/xen/arch/x86/guest/hyperv/hyperv.c 
b/xen/arch/x86/guest/hyperv/hyperv.c
index 4387b6541e..f0facccbad 100644
--- a/xen/arch/x86/guest/hyperv/hyperv.c
+++ b/xen/arch/x86/guest/hyperv/hyperv.c
@@ -27,7 +27,10 @@
 #include 
 #include 
 
+#include "private.h"
+
 struct ms_hyperv_info __read_mostly ms_hyperv;
+DEFINE_PER_CPU_READ_MOSTLY(void *, hv_pcpu_input_page);
 
 static uint64_t generate_guest_id(void)
 {
@@ -127,14 +130,42 @@ static void __init setup_hypercall_page(void)
 }
 }
 
+static int setup_hypercall_pcpu_arg(void)
+{
+void *mapping;
+
+if ( this_cpu(hv_pcpu_input_page) )
+return 0;
+
+mapping = alloc_xenheap_page();
+if ( !mapping )
+{
+printk("Failed to allocate hypercall input page for CPU%u\n",
+   smp_processor_id());
+return -ENOMEM;
+}
+
+this_cpu(hv_pcpu_input_page) = mapping;
+
+return 0;
+}
+
 static void __init setup(void)
 {
 setup_hypercall_page();
+if ( setup_hypercall_pcpu_arg() )
+panic("Hypercall percpu arg setup failed\n");
+}
+
+static int ap_setup(void)
+{
+return setup_hypercall_pcpu_arg();
 }
 
 static const struct hypervisor_ops ops = {
 .name = "Hyper-V",
 .setup = setup,
+.ap_setup = ap_setup,
 };
 
 static void __maybe_unused build_assertions(void)
diff --git a/xen/arch/x86/guest/hyperv/private.h 
b/xen/arch/x86/guest/hyperv/private.h
new file mode 100644
index 00..a339274985
--- /dev/null
+++ b/xen/arch/x86/guest/hyperv/private.h
@@ -0,0 +1,29 @@
+/**
+ * arch/x86/guest/hyperv/private.h
+ *
+ * Definitions / declarations only useful to Hyper-V code.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see .
+ *
+ * Copyright (c) 2020 Microsoft.
+ */
+
+#ifndef __XEN_HYPERV_PRIVIATE_H__
+#define __XEN_HYPERV_PRIVIATE_H__
+
+#include 
+
+DECLARE_PER_CPU(void *, hv_pcpu_input_page);
+
+#endif /* __XEN_HYPERV_PRIVIATE_H__  */
-- 
2.20.1


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

[Xen-devel] [PATCH v5 08/12] x86/hyperv: provide Hyper-V hypercall functions

[Wei Liu]

These functions will be used later to make hypercalls to Hyper-V.

Signed-off-by: Wei Liu 
---
v5:
1. Switch back to direct call
2. Fix some issues pointed out by Jan

I tried using the asm(".equ ..") trick but hit a problem with %c again.

mm.c:5736:5: error: invalid 'asm': operand is not a condition code, invalid 
operand code 'c'
   asm ( ".equ HV_HCALL_PAGE, %c0; .global HV_HCALL_PAGE"
---
 MAINTAINERS  |  1 +
 xen/arch/x86/guest/hyperv/hyperv.c   |  6 ++
 xen/arch/x86/xen.lds.S   |  4 +
 xen/include/asm-x86/fixmap.h |  3 +-
 xen/include/asm-x86/guest/hyperv-hcall.h | 96 
 5 files changed, 108 insertions(+), 2 deletions(-)
 create mode 100644 xen/include/asm-x86/guest/hyperv-hcall.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 04d91482cd..d0a5ed635b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -519,6 +519,7 @@ S:  Supported
 F: xen/arch/x86/guest/hyperv/
 F: xen/arch/x86/hvm/viridian/
 F: xen/include/asm-x86/guest/hyperv.h
+F: xen/include/asm-x86/guest/hyperv-hcall.h
 F: xen/include/asm-x86/guest/hyperv-tlfs.h
 F: xen/include/asm-x86/hvm/viridian.h
 
diff --git a/xen/arch/x86/guest/hyperv/hyperv.c 
b/xen/arch/x86/guest/hyperv/hyperv.c
index 2bedcc438c..932a648ff7 100644
--- a/xen/arch/x86/guest/hyperv/hyperv.c
+++ b/xen/arch/x86/guest/hyperv/hyperv.c
@@ -123,6 +123,12 @@ static const struct hypervisor_ops ops = {
 .setup = setup,
 };
 
+static void __maybe_unused build_assertions(void)
+{
+/* We use 1 in linker script */
+BUILD_BUG_ON(FIX_X_HYPERV_HCALL != 1);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 97f9c07891..8e02b4c648 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -329,6 +329,10 @@ SECTIONS
   efi = .;
 #endif
 
+#ifdef CONFIG_HYPERV_GUEST
+  hv_hcall_page = ABSOLUTE(__fix_x_to_virt(1));
+#endif
+
   /* Sections to be discarded */
   /DISCARD/ : {
*(.exit.text)
diff --git a/xen/include/asm-x86/fixmap.h b/xen/include/asm-x86/fixmap.h
index 8094546b75..a9bcb068cb 100644
--- a/xen/include/asm-x86/fixmap.h
+++ b/xen/include/asm-x86/fixmap.h
@@ -16,6 +16,7 @@
 
 #define FIXADDR_TOP (VMAP_VIRT_END - PAGE_SIZE)
 #define FIXADDR_X_TOP (XEN_VIRT_END - PAGE_SIZE)
+#define __fix_x_to_virt(x) (FIXADDR_X_TOP - ((x) << PAGE_SHIFT))
 
 #ifndef __ASSEMBLY__
 
@@ -110,8 +111,6 @@ extern void __set_fixmap_x(
 
 #define clear_fixmap_x(idx) __set_fixmap_x(idx, 0, 0)
 
-#define __fix_x_to_virt(x) (FIXADDR_X_TOP - ((x) << PAGE_SHIFT))
-
 #define fix_x_to_virt(x)   ((void *)__fix_x_to_virt(x))
 
 #endif /* __ASSEMBLY__ */
diff --git a/xen/include/asm-x86/guest/hyperv-hcall.h 
b/xen/include/asm-x86/guest/hyperv-hcall.h
new file mode 100644
index 00..5b7509b3b5
--- /dev/null
+++ b/xen/include/asm-x86/guest/hyperv-hcall.h
@@ -0,0 +1,96 @@
+/**
+ * asm-x86/guest/hyperv-hcall.h
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; If not, see .
+ *
+ * Copyright (c) 2019 Microsoft.
+ */
+
+#ifndef __X86_HYPERV_HCALL_H__
+#define __X86_HYPERV_HCALL_H__
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+static inline uint64_t hv_do_hypercall(uint64_t control, paddr_t input_addr,
+   paddr_t output_addr)
+{
+uint64_t status;
+register unsigned long r8 asm("r8") = output_addr;
+
+asm volatile ( "call hv_hcall_page"
+   : "=a" (status), "+c" (control),
+ "+d" (input_addr) ASM_CALL_CONSTRAINT
+   : "r" (r8)
+   : "memory" );
+
+return status;
+}
+
+static inline uint64_t hv_do_fast_hypercall(uint16_t code,
+uint64_t input1, uint64_t input2)
+{
+uint64_t status;
+uint64_t control = code | HV_HYPERCALL_FAST_BIT;
+register unsigned long r8 asm("r8") = input2;
+
+asm volatile ( "call hv_hcall_page"
+   : "=a" (status), "+c" (control),
+ "+d" (input1) ASM_CALL_CONSTRAINT
+   : "r" (r8)
+   : );
+
+return status;
+}
+
+static inline uint64_t hv_do_rep_hypercall(uint16_t code, uint16_t rep_count,
+   uint16_t varhead_size,
+   paddr_t input, 

[Xen-devel] [PATCH v5 11/12] x86/hyperv: retrieve vp_index from Hyper-V

[Wei Liu]

This will be useful when invoking hypercall that targets specific
vcpu(s).

Signed-off-by: Wei Liu 
Reviewed-by: Paul Durrant 
Acked-by: Jan Beulich 
---
v5:
1. Add Jan's Ack.

v4:
1. Use private.h
2. Add Paul's review tag

v2:
1. Fold into setup_pcpu_arg function
---
 xen/arch/x86/guest/hyperv/hyperv.c  | 5 +
 xen/arch/x86/guest/hyperv/private.h | 1 +
 2 files changed, 6 insertions(+)

diff --git a/xen/arch/x86/guest/hyperv/hyperv.c 
b/xen/arch/x86/guest/hyperv/hyperv.c
index f0facccbad..af0d6ed692 100644
--- a/xen/arch/x86/guest/hyperv/hyperv.c
+++ b/xen/arch/x86/guest/hyperv/hyperv.c
@@ -31,6 +31,7 @@
 
 struct ms_hyperv_info __read_mostly ms_hyperv;
 DEFINE_PER_CPU_READ_MOSTLY(void *, hv_pcpu_input_page);
+DEFINE_PER_CPU_READ_MOSTLY(unsigned int, hv_vp_index);
 
 static uint64_t generate_guest_id(void)
 {
@@ -133,6 +134,7 @@ static void __init setup_hypercall_page(void)
 static int setup_hypercall_pcpu_arg(void)
 {
 void *mapping;
+uint64_t vp_index_msr;
 
 if ( this_cpu(hv_pcpu_input_page) )
 return 0;
@@ -147,6 +149,9 @@ static int setup_hypercall_pcpu_arg(void)
 
 this_cpu(hv_pcpu_input_page) = mapping;
 
+rdmsrl(HV_X64_MSR_VP_INDEX, vp_index_msr);
+this_cpu(hv_vp_index) = vp_index_msr;
+
 return 0;
 }
 
diff --git a/xen/arch/x86/guest/hyperv/private.h 
b/xen/arch/x86/guest/hyperv/private.h
index a339274985..c1c2431eff 100644
--- a/xen/arch/x86/guest/hyperv/private.h
+++ b/xen/arch/x86/guest/hyperv/private.h
@@ -25,5 +25,6 @@
 #include 
 
 DECLARE_PER_CPU(void *, hv_pcpu_input_page);
+DECLARE_PER_CPU(unsigned int, hv_vp_index);
 
 #endif /* __XEN_HYPERV_PRIVIATE_H__  */
-- 
2.20.1


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

[Xen-devel] [PATCH v5 02/12] x86/hypervisor: make hypervisor_ap_setup return an error code

[Wei Liu]

We want to be able to handle AP setup error in the upper layer.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/guest/hypervisor.c|  6 --
 xen/arch/x86/guest/xen/xen.c   | 11 +--
 xen/include/asm-x86/guest/hypervisor.h |  6 +++---
 3 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/guest/hypervisor.c b/xen/arch/x86/guest/hypervisor.c
index 4f27b98740..e72c92ffdf 100644
--- a/xen/arch/x86/guest/hypervisor.c
+++ b/xen/arch/x86/guest/hypervisor.c
@@ -52,10 +52,12 @@ void __init hypervisor_setup(void)
 ops->setup();
 }
 
-void hypervisor_ap_setup(void)
+int hypervisor_ap_setup(void)
 {
 if ( ops && ops->ap_setup )
-ops->ap_setup();
+return ops->ap_setup();
+
+return 0;
 }
 
 void hypervisor_resume(void)
diff --git a/xen/arch/x86/guest/xen/xen.c b/xen/arch/x86/guest/xen/xen.c
index 6dbc5f953f..eed8a6edae 100644
--- a/xen/arch/x86/guest/xen/xen.c
+++ b/xen/arch/x86/guest/xen/xen.c
@@ -257,11 +257,18 @@ static void __init setup(void)
 init_evtchn();
 }
 
-static void ap_setup(void)
+static int ap_setup(void)
 {
+int rc;
+
 set_vcpu_id();
-map_vcpuinfo();
+rc = map_vcpuinfo();
+if ( rc )
+return rc;
+
 init_evtchn();
+
+return 0;
 }
 
 int xg_alloc_unused_page(mfn_t *mfn)
diff --git a/xen/include/asm-x86/guest/hypervisor.h 
b/xen/include/asm-x86/guest/hypervisor.h
index 392f4b90ae..b503854c5b 100644
--- a/xen/include/asm-x86/guest/hypervisor.h
+++ b/xen/include/asm-x86/guest/hypervisor.h
@@ -25,7 +25,7 @@ struct hypervisor_ops {
 /* Main setup routine */
 void (*setup)(void);
 /* AP setup */
-void (*ap_setup)(void);
+int (*ap_setup)(void);
 /* Resume from suspension */
 void (*resume)(void);
 };
@@ -34,7 +34,7 @@ struct hypervisor_ops {
 
 const char *hypervisor_probe(void);
 void hypervisor_setup(void);
-void hypervisor_ap_setup(void);
+int hypervisor_ap_setup(void);
 void hypervisor_resume(void);
 
 #else
@@ -44,7 +44,7 @@ void hypervisor_resume(void);
 
 static inline const char *hypervisor_probe(void) { return NULL; }
 static inline void hypervisor_setup(void) { ASSERT_UNREACHABLE(); }
-static inline void hypervisor_ap_setup(void) { ASSERT_UNREACHABLE(); }
+static inline int hypervisor_ap_setup(void) { ASSERT_UNREACHABLE(); return 0; }
 static inline void hypervisor_resume(void) { ASSERT_UNREACHABLE(); }
 
 #endif  /* CONFIG_GUEST */
-- 
2.20.1


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

[Xen-devel] [PATCH v5 00/12] More Hyper-V infrastructures

[Wei Liu]

This patch sereis implements several important functionalities to run
Xen on top of Hyper-V.

See individual patches for more details. First few patches are generic
x86 changes. The rest is Hyper-V specific.

I've checked the assembly code as well as putting in a test patch to
make sure the hypercall interface is implemented correctly.

Wei.

Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: Roger Pau Monné 
Cc: Michael Kelley 
Cc: Paul Durrant 

Wei Liu (12):
  MAINTAINERS: put Hyper-V code under Viridian maintainership
  x86/hypervisor: make hypervisor_ap_setup return an error code
  x86/smp: don't online cpu if hypervisor_ap_setup fails
  x86: make paddr_bits available earlier
  x86: provide executable fixmap facility
  x86/hypervisor: provide hypervisor_reserve_top_pages
  x86/hyperv: setup hypercall page
  x86/hyperv: provide Hyper-V hypercall functions
  DO NOT APPLY: x86/hyperv: issue an hypercall
  x86/hyperv: provide percpu hypercall input page
  x86/hyperv: retrieve vp_index from Hyper-V
  x86/hyperv: setup VP assist page

 MAINTAINERS  |   6 +-
 xen/arch/x86/boot/x86_64.S   |  15 ++-
 xen/arch/x86/e820.c  |  19 ++-
 xen/arch/x86/guest/hyperv/hyperv.c   | 155 ++-
 xen/arch/x86/guest/hyperv/private.h  |  31 +
 xen/arch/x86/guest/hypervisor.c  |  14 +-
 xen/arch/x86/guest/xen/xen.c |  11 +-
 xen/arch/x86/livepatch.c |   3 +-
 xen/arch/x86/mm.c|  15 ++-
 xen/arch/x86/setup.c |   5 +-
 xen/arch/x86/smpboot.c   |  12 +-
 xen/arch/x86/xen.lds.S   |   7 +
 xen/include/asm-x86/config.h |   2 +-
 xen/include/asm-x86/fixmap.h |  24 
 xen/include/asm-x86/guest/hyperv-hcall.h |  96 ++
 xen/include/asm-x86/guest/hyperv-tlfs.h  |   5 +-
 xen/include/asm-x86/guest/hyperv.h   |   3 +
 xen/include/asm-x86/guest/hypervisor.h   |  10 +-
 18 files changed, 398 insertions(+), 35 deletions(-)
 create mode 100644 xen/arch/x86/guest/hyperv/private.h
 create mode 100644 xen/include/asm-x86/guest/hyperv-hcall.h

-- 
2.20.1


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

[Xen-devel] [PATCH v5 04/12] x86: make paddr_bits available earlier

[Wei Liu]

Move early_cpu_init before init_e820, such that paddr_bits can be used
by e820 code.

This will reduce code repetition and prepare for further adjustment when
L0 hypervisor comes into play.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/e820.c  | 14 --
 xen/arch/x86/setup.c |  5 +++--
 2 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
index 082f9928a1..3892c9cfb7 100644
--- a/xen/arch/x86/e820.c
+++ b/xen/arch/x86/e820.c
@@ -420,7 +420,7 @@ static uint64_t __init mtrr_top_of_ram(void)
 {
 uint32_t eax, ebx, ecx, edx;
 uint64_t mtrr_cap, mtrr_def, addr_mask, base, mask, top;
-unsigned int i, phys_bits = 36;
+unsigned int i;
 
 /* By default we check only Intel systems. */
 if ( e820_mtrr_clip == -1 )
@@ -445,15 +445,9 @@ static uint64_t __init mtrr_top_of_ram(void)
 if ( !test_bit(X86_FEATURE_MTRR & 31, ) )
  return 0;
 
-/* Find the physical address size for this CPU. */
-eax = cpuid_eax(0x8000);
-if ( (eax >> 16) == 0x8000 && eax >= 0x8008 )
-{
-phys_bits = (uint8_t)cpuid_eax(0x8008);
-if ( phys_bits > PADDR_BITS )
-phys_bits = PADDR_BITS;
-}
-addr_mask = ((1ull << phys_bits) - 1) & ~((1ull << 12) - 1);
+/* paddr_bits must have been set at this point */
+ASSERT(paddr_bits);
+addr_mask = ((1ull << paddr_bits) - 1) & PAGE_MASK;
 
 rdmsrl(MSR_MTRRcap, mtrr_cap);
 rdmsrl(MSR_MTRRdefType, mtrr_def);
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index d858883404..89fe49149f 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -954,6 +954,9 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 else
 panic("Bootloader provided no memory information\n");
 
+/* This must come before e820 code becuause it sets paddr_bits. */
+early_cpu_init();
+
 /* Sanitise the raw E820 map to produce a final clean version. */
 max_page = raw_max_page = init_e820(memmap_type, _raw);
 
@@ -1532,8 +1535,6 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 softirq_init();
 tasklet_subsys_init();
 
-early_cpu_init();
-
 paging_init();
 
 tboot_probe();
-- 
2.20.1


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

[Xen-devel] [PATCH v5 05/12] x86: provide executable fixmap facility

[Wei Liu]

This allows us to set aside some address space for executable mapping.
This fixed map range starts from XEN_VIRT_END so that it is within reach
of the .text section.

Shift the percpu stub range and shrink livepatch range accordingly.

Signed-off-by: Wei Liu 
---
v5:
1. drop __virt_to_fix_x
2. also check FIX*_RESERVED in __set_fixmap*
3. generate global symbol to be used in linker script
4. address other misc comments
---
 xen/arch/x86/boot/x86_64.S   | 15 ---
 xen/arch/x86/livepatch.c |  3 ++-
 xen/arch/x86/mm.c| 15 ++-
 xen/arch/x86/smpboot.c   |  2 +-
 xen/arch/x86/xen.lds.S   |  3 +++
 xen/include/asm-x86/config.h |  2 +-
 xen/include/asm-x86/fixmap.h | 25 +
 7 files changed, 58 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
index 1cbf5acdfb..314a32a19f 100644
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -81,11 +81,20 @@ GLOBAL(l2_directmap)
 .size l2_directmap, . - l2_directmap
 
 /*
- * L2 mapping the Xen text/data/bss region, constructed dynamically.  Uses 1x
- * 4k page.
+ * L2 mapping the Xen text/data/bss region, constructed dynamically.
+ * Executable fixmap is hooked up statically.
+ * Uses 1x 4k page.
  */
 GLOBAL(l2_xenmap)
-.fill L2_PAGETABLE_ENTRIES, 8, 0
+idx = 0
+.rept L2_PAGETABLE_ENTRIES
+.if idx == l2_table_offset(FIXADDR_X_TOP - 1)
+.quad sym_offs(l1_fixmap_x) + __PAGE_HYPERVISOR
+.else
+.quad 0
+.endif
+idx = idx + 1
+.endr
 .size l2_xenmap, . - l2_xenmap
 
 /* L2 mapping the fixmap.  Uses 1x 4k page. */
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index 2749cbc5cf..513b0f3841 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -311,7 +312,7 @@ void __init arch_livepatch_init(void)
 void *start, *end;
 
 start = (void *)xen_virt_end;
-end = (void *)(XEN_VIRT_END - NR_CPUS * PAGE_SIZE);
+end = (void *)(XEN_VIRT_END - FIXADDR_X_SIZE - NR_CPUS * PAGE_SIZE);
 
 BUG_ON(end <= start);
 
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index f50c065af3..44abde24b2 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -157,6 +157,8 @@
 /* Mapping of the fixmap space needed early. */
 l1_pgentry_t __section(".bss.page_aligned") __aligned(PAGE_SIZE)
 l1_fixmap[L1_PAGETABLE_ENTRIES];
+l1_pgentry_t __section(".bss.page_aligned") __aligned(PAGE_SIZE)
+l1_fixmap_x[L1_PAGETABLE_ENTRIES];
 
 paddr_t __read_mostly mem_hotplug;
 
@@ -5718,10 +5720,21 @@ int destroy_xen_mappings(unsigned long s, unsigned long 
e)
 void __set_fixmap(
 enum fixed_addresses idx, unsigned long mfn, unsigned long flags)
 {
-BUG_ON(idx >= __end_of_fixed_addresses);
+BUG_ON(idx >= __end_of_fixed_addresses || idx <= FIX_RESERVED);
 map_pages_to_xen(__fix_to_virt(idx), _mfn(mfn), 1, flags);
 }
 
+void __set_fixmap_x(
+enum fixed_addresses_x idx, unsigned long mfn, unsigned long flags)
+{
+BUG_ON(idx >= __end_of_fixed_addresses_x || idx <= FIX_X_RESERVED);
+map_pages_to_xen(__fix_x_to_virt(idx), _mfn(mfn), 1, flags);
+
+/* Generate a symbol to be used in linker script */
+asm ( ".equ FIXADDR_X_SIZE, %c0; .global FIXADDR_X_SIZE"
+  :: "i" (__end_of_fixed_addresses_x << PAGE_SHIFT) );
+}
+
 void *__init arch_vmap_virt_end(void)
 {
 return fix_to_virt(__end_of_fixed_addresses);
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 93b86a09e9..e83e4564a4 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -644,7 +644,7 @@ unsigned long alloc_stub_page(unsigned int cpu, unsigned 
long *mfn)
 unmap_domain_page(memset(__map_domain_page(pg), 0xcc, PAGE_SIZE));
 }
 
-stub_va = XEN_VIRT_END - (cpu + 1) * PAGE_SIZE;
+stub_va = XEN_VIRT_END - FIXADDR_X_SIZE - (cpu + 1) * PAGE_SIZE;
 if ( map_pages_to_xen(stub_va, page_to_mfn(pg), 1,
   PAGE_HYPERVISOR_RX | MAP_SMALL_PAGES) )
 {
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 07c6448dbb..97f9c07891 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -3,6 +3,8 @@
 
 #include 
 #include 
+
+#include 
 #include 
 #undef ENTRY
 #undef ALIGN
@@ -353,6 +355,7 @@ SECTIONS
 }
 
 ASSERT(__2M_rwdata_end <= XEN_VIRT_END - XEN_VIRT_START + __XEN_VIRT_START -
+  FIXADDR_X_SIZE -
   DIV_ROUND_UP(NR_CPUS, STUBS_PER_PAGE) * PAGE_SIZE,
"Xen image overlaps stubs area")
 
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index d0cfbb70a8..a34053c4c0 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -218,7 +218,7 @@ extern unsigned char boot_edid_info[128];
 /* Slot 261: high read-only compat machine-to-phys conversion table (1GB). */
 #define 

[Xen-devel] [PATCH v5 12/12] x86/hyperv: setup VP assist page

[Wei Liu]

VP assist page is rather important as we need to toggle some bits in it
for efficient nested virtualisation.

Signed-off-by: Wei Liu 
---
v5:
1. Deal with error properly instead of always panicking
2. Swap percpu variables declarations' location

v4:
1. Use private.h
2. Prevent leak

v3:
1. Use xenheap page
2. Drop set_vp_assist

v2:
1. Use HV_HYP_PAGE_SHIFT instead
---
 xen/arch/x86/guest/hyperv/hyperv.c  | 44 -
 xen/arch/x86/guest/hyperv/private.h |  1 +
 2 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/guest/hyperv/hyperv.c 
b/xen/arch/x86/guest/hyperv/hyperv.c
index af0d6ed692..bc40a3d338 100644
--- a/xen/arch/x86/guest/hyperv/hyperv.c
+++ b/xen/arch/x86/guest/hyperv/hyperv.c
@@ -31,6 +31,7 @@
 
 struct ms_hyperv_info __read_mostly ms_hyperv;
 DEFINE_PER_CPU_READ_MOSTLY(void *, hv_pcpu_input_page);
+DEFINE_PER_CPU_READ_MOSTLY(void *, hv_vp_assist);
 DEFINE_PER_CPU_READ_MOSTLY(unsigned int, hv_vp_index);
 
 static uint64_t generate_guest_id(void)
@@ -155,16 +156,57 @@ static int setup_hypercall_pcpu_arg(void)
 return 0;
 }
 
+static int setup_vp_assist(void)
+{
+void *mapping;
+uint64_t val;
+
+mapping = this_cpu(hv_vp_assist);
+
+if ( !mapping )
+{
+mapping = alloc_xenheap_page();
+if ( !mapping )
+{
+printk("Failed to allocate vp_assist page for CPU%u\n",
+   smp_processor_id());
+return -ENOMEM;
+}
+
+clear_page(mapping);
+this_cpu(hv_vp_assist) = mapping;
+}
+
+val = (virt_to_mfn(mapping) << HV_HYP_PAGE_SHIFT)
+| HV_X64_MSR_VP_ASSIST_PAGE_ENABLE;
+wrmsrl(HV_X64_MSR_VP_ASSIST_PAGE, val);
+
+return 0;
+}
+
 static void __init setup(void)
 {
 setup_hypercall_page();
+
 if ( setup_hypercall_pcpu_arg() )
 panic("Hypercall percpu arg setup failed\n");
+
+if ( setup_vp_assist() )
+panic("VP assist page setup failed\n");
 }
 
 static int ap_setup(void)
 {
-return setup_hypercall_pcpu_arg();
+int rc;
+
+rc = setup_hypercall_pcpu_arg();
+if ( rc )
+goto out;
+
+rc = setup_vp_assist();
+
+ out:
+return rc;
 }
 
 static const struct hypervisor_ops ops = {
diff --git a/xen/arch/x86/guest/hyperv/private.h 
b/xen/arch/x86/guest/hyperv/private.h
index c1c2431eff..fcddc47544 100644
--- a/xen/arch/x86/guest/hyperv/private.h
+++ b/xen/arch/x86/guest/hyperv/private.h
@@ -25,6 +25,7 @@
 #include 
 
 DECLARE_PER_CPU(void *, hv_pcpu_input_page);
+DECLARE_PER_CPU(void *, hv_vp_assist);
 DECLARE_PER_CPU(unsigned int, hv_vp_index);
 
 #endif /* __XEN_HYPERV_PRIVIATE_H__  */
-- 
2.20.1


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

[Xen-devel] [PATCH v5 09/12] DO NOT APPLY: x86/hyperv: issue an hypercall

[Wei Liu]

Test if the infrastructure works.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/guest/hyperv/hyperv.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/xen/arch/x86/guest/hyperv/hyperv.c 
b/xen/arch/x86/guest/hyperv/hyperv.c
index 932a648ff7..4387b6541e 100644
--- a/xen/arch/x86/guest/hyperv/hyperv.c
+++ b/xen/arch/x86/guest/hyperv/hyperv.c
@@ -23,6 +23,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -111,6 +112,19 @@ static void __init setup_hypercall_page(void)
 BUG_ON(!hypercall_msr.enable);
 
 set_fixmap_x(FIX_X_HYPERV_HCALL, mfn << PAGE_SHIFT);
+
+/* XXX Wei: Issue an hypercall here to make sure things are set up
+ * correctly.  When there is actual use of the hypercall facility,
+ * this can be removed.
+ */
+{
+uint16_t r = hv_do_hypercall(0x, 0, 0);
+BUG_ON(r != HV_STATUS_INVALID_HYPERCALL_CODE);
+r = hv_do_fast_hypercall(0x, 0, 0);
+BUG_ON(r != HV_STATUS_INVALID_HYPERCALL_CODE);
+
+printk("Successfully issued Hyper-V hypercalls\n");
+}
 }
 
 static void __init setup(void)
-- 
2.20.1


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

[Xen-devel] [PATCH v5 03/12] x86/smp: don't online cpu if hypervisor_ap_setup fails

[Wei Liu]

Push hypervisor_ap_setup down to smp_callin.

Take the chance to replace xen_guest with cpu_has_hypervisor.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/smpboot.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index c9d1ab4423..93b86a09e9 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -199,6 +199,13 @@ static void smp_callin(void)
 goto halt;
 }
 
+if ( cpu_has_hypervisor && (rc = hypervisor_ap_setup()) != 0 )
+{
+printk("CPU%d: Failed to initialise hypervisor functions. Not coming 
online.\n", cpu);
+cpu_error = rc;
+goto halt;
+}
+
 if ( (rc = hvm_cpu_up()) != 0 )
 {
 printk("CPU%d: Failed to initialise HVM. Not coming online.\n", cpu);
@@ -371,9 +378,6 @@ void start_secondary(void *unused)
 
 tsx_init(); /* Needs microcode.  May change HLE/RTM feature bits. */
 
-if ( xen_guest )
-hypervisor_ap_setup();
-
 smp_callin();
 
 set_cpu_sibling_map(cpu);
-- 
2.20.1


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

[Xen-devel] [PATCH v5 06/12] x86/hypervisor: provide hypervisor_reserve_top_pages

[Wei Liu]

This function will return the number of pages that need to be reserved
in the machine address space.

E820 code will use that number to adjust the maximum PFN available to
Xen.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/guest/hypervisor.c| 8 
 xen/include/asm-x86/guest/hypervisor.h | 4 
 2 files changed, 12 insertions(+)

diff --git a/xen/arch/x86/guest/hypervisor.c b/xen/arch/x86/guest/hypervisor.c
index e72c92ffdf..8b9cf1ce4c 100644
--- a/xen/arch/x86/guest/hypervisor.c
+++ b/xen/arch/x86/guest/hypervisor.c
@@ -66,6 +66,14 @@ void hypervisor_resume(void)
 ops->resume();
 }
 
+unsigned int hypervisor_reserve_top_pages(void)
+{
+if ( ops && ops->reserve_top_pages )
+return ops->reserve_top_pages();
+
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-x86/guest/hypervisor.h 
b/xen/include/asm-x86/guest/hypervisor.h
index b503854c5b..37eb9d531e 100644
--- a/xen/include/asm-x86/guest/hypervisor.h
+++ b/xen/include/asm-x86/guest/hypervisor.h
@@ -28,6 +28,8 @@ struct hypervisor_ops {
 int (*ap_setup)(void);
 /* Resume from suspension */
 void (*resume)(void);
+/* How many top pages to be reserved in machine address space? */
+unsigned int (*reserve_top_pages)(void);
 };
 
 #ifdef CONFIG_GUEST
@@ -36,6 +38,7 @@ const char *hypervisor_probe(void);
 void hypervisor_setup(void);
 int hypervisor_ap_setup(void);
 void hypervisor_resume(void);
+unsigned int hypervisor_reserve_top_pages(void);
 
 #else
 
@@ -46,6 +49,7 @@ static inline const char *hypervisor_probe(void) { return 
NULL; }
 static inline void hypervisor_setup(void) { ASSERT_UNREACHABLE(); }
 static inline int hypervisor_ap_setup(void) { ASSERT_UNREACHABLE(); return 0; }
 static inline void hypervisor_resume(void) { ASSERT_UNREACHABLE(); }
+static inline unsigned int hypervisor_reserve_top_pages(void) { return 0; }
 
 #endif  /* CONFIG_GUEST */
 
-- 
2.20.1


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

Re: [Xen-devel] [PATCH v4 1/2] docs/designs: Add a design document for non-cooperative live migration

[Andrew Cooper]

On 29/01/2020 14:47, Paul Durrant wrote:
> diff --git a/docs/designs/non-cooperative-migration.md 
> b/docs/designs/non-cooperative-migration.md
> new file mode 100644
> index 00..5db3939db5
> --- /dev/null
> +++ b/docs/designs/non-cooperative-migration.md
> @@ -0,0 +1,272 @@
> +# Non-Cooperative Migration of Guests on Xen
> +
> +## Background
> +
> +The normal model of migration in Xen is driven by the guest because it was
> +originally implemented for PV guests, where the guest must be aware it is
> +running under Xen and is hence expected to co-operate. 

For PV guests, is more than "expected to co-operate".

Migrating a PV guest involves rewriting every pagetable entry with a
different MFN, so even before you consider things like the PV protocols,
there is no way this could be done without the cooperation of the guest.

Sadly, this fact was depended upon for migration of the PV protocols,
and has migrated (excuse the pun) into the HVM world as well.

> This model dates from
> +an era when it was assumed that the host administrator had control of at 
> least
> +the privileged software running in the guest (i.e. the guest kernel) which 
> may
> +still be true in an enterprise deployment but is not generally true in a 
> cloud
> +environment.

I haven't seen it discussed elsewhere, but even enterprise environments
have problems.

Having host admin == guest admin doesn't mean that guest drivers aren't
buggy, or that the VM doesn't explode on migrate.

The simple fact is that involving the guest kernel adds unnecessary
moving parts which can (and do with a non-zero probability) go wrong.

>  The aim of this design is to provide a model which is purely host
> +driven, requiring no co-operation from the software running in the
> +guest, and is thus suitable for cloud scenarios.
> +
> +PV guests are out of scope for this project because, as is outlined above, 
> they
> +have a symbiotic relationship with the hypervisor and therefore a certain 
> level
> +of co-operation can be assumed.

If nothing else, I'd at least suggest s/can be assumed/is necessary/.

> +Because the service domain’s domid is used directly by the guest in setting
> +up grant entries and event channels, the backend drivers in the new host
> +environment must be provided by service domain with the same domid. Also,
> +because the guest can sample its own domid from the frontend area and use it 
> in
> +hypercalls (e.g. HVMOP_set_param) rather than DOMID_SELF, the guest domid 
> must
> +also be preserved to maintain the ABI.

Has this been true since forever?  The grant and event APIs took some
care to avoid the guest needing to know its own domid.

> +
> +Furthermore, it will necessary to modify backend drivers to re-establish
> +communication with frontend drivers without perturbing the content of the
> +backend area or requiring any changes to the values of the xenstore state 
> nodes.
> +
> +## Other Para-Virtual State
> +
> +### Shared Rings
> +
> +Because the console and store protocol shared pages are actually part of the
> +guest memory image (in an E820 reserved region just below 4G) 

Typically*.

Their exact location is entirely up to the domain builder, and tend not
to be there for PVH guests which aren't trying to fit the two frames
into a BAR.

> then the content
> +will get migrated as part of the guest memory image. Hence no additional code
> +is require to prevent any guest visible change in the content.

I do agree with this conclusion however.

> +### Shared Info
> +
> +There is already a record defined in *libxenctrl Domain Image Format* [3]
> +called `SHARED_INFO` which simply contains a complete copy of the domain’s
> +shared info page. It is not currently incuded in an HVM (type `0x0002`)
> +migration stream. It may be feasible to include it as an optional record
> +but it is not clear that the content of the shared info page ever needs
> +to be preserved for an HVM guest.
> +
> +For a PV guest the `arch_shared_info` sub-structure contains important
> +information about the guest’s P2M, but this information is not relevant for
> +an HVM guest where the P2M is not directly manipulated via the guest. The 
> other
> +state contained in the `shared_info` structure relates the domain wall-clock
> +(the state of which should already be transferred by the `RTC` HVM context
> +information which contained in the `HVM_CONTEXT` save record) and some event
> +channel state (particularly if using the *2l* protocol). Event channel state
> +will need to be fully transferred if we are not going to require the guest
> +co-operation to re-open the channels and so it should be possible to 
> re-build a
> +shared info page for an HVM guest from such other state.
> +
> +Note that the shared info page also contains an array of 
> `XEN_LEGACY_MAX_VCPUS`
> +(32) `vcpu_info` structures. A domain may nominate a different guest physical
> +address to use for the vcpu info. This is mandatory for if a domain wants to
> +use more than 32 

Re: [Xen-devel] FAILED/MISSING cstate/cpufreq/cpupower support with Xen 4.13 + kernel 5.4.14; withOUT xen/hypervisor, WORKS. bug or config?

[PGNet Dev]

with xen cmd line opts reduced to

options=dom0_max_vcpus=4 dom0_mem=4016M,max:4096M loglvl=all 
guest_loglvl=all noreboot=false sync_console=true sched_debug iommu=verbose 
apic_verbosity=verbose

still no freq data/control

and,

xl dmesg
(XEN)  92118000 - 9213c000 (usable)
(XEN)  9213c000 - 921e (reserved)
(XEN)  921e - 921ea000 (usable)
(XEN)  921ea000 - 92438000 (reserved)
(XEN)  92438000 - 9243a000 (usable)
(XEN)  9243a000 - 9243f000 (reserved)
(XEN)  9243f000 - 92441000 (usable)
(XEN)  92441000 - 92448000 (reserved)
(XEN)  92448000 - 9244a000 (usable)
(XEN)  9244a000 - 92451000 (reserved)
(XEN)  92451000 - 92454000 (usable)
(XEN)  92454000 - 92467000 (reserved)
(XEN)  92467000 - 9246a000 (usable)
(XEN)  9246a000 - 92565000 (reserved)
(XEN)  92565000 - 92568000 (usable)
(XEN)  92568000 - 926a8000 (reserved)
(XEN)  926a8000 - 926ab000 (usable)
(XEN)  926ab000 - 926e7000 (reserved)
(XEN)  926e7000 - 926e9000 (usable)
(XEN)  926e9000 - 926ee000 (reserved)
(XEN)  926ee000 - 926ef000 (usable)
(XEN)  926ef000 - 9e024000 (reserved)
(XEN)  9e024000 - 9e2ba000 (usable)
(XEN)  9e2ba000 - 9e6c9000 (reserved)
(XEN)  9e6c9000 - 9e716000 (usable)
(XEN)  9e716000 - 9e849000 (ACPI NVS)
(XEN)  9e849000 - 9f00 (reserved)
(XEN)  f000 - f800 (reserved)
(XEN)  fec0 - fec01000 (reserved)
(XEN)  fed0 - fed04000 (reserved)
(XEN)  fed1c000 - fed2 (reserved)
(XEN)  fee0 - fee01000 (reserved)
(XEN)  ff00 - 0001 (reserved)
(XEN)  0001 - 00085e00 (usable)
(XEN) ACPI: XSDT 9E81A088, 008C (r1 SUPERM SMCI--MB  1072009 AMI 
10013)
(XEN) ACPI: FACP 9E8282D0, 010C (r5 SUPERM SMCI--MB  1072009 AMI 
10013)
(XEN) ACPI: DSDT 9E81A1A8, E121 (r2 SUPERM SMCI--MB0 INTL 
20120711)
(XEN) ACPI: FACS 9E848F80, 0040
(XEN) ACPI: APIC 9E8283E0, 0072 (r3 SUPERM SMCI--MB  1072009 AMI 
10013)
(XEN) ACPI: FPDT 9E828458, 0044 (r1 SUPERM SMCI--MB  1072009 AMI 
10013)
(XEN) ACPI: FIDT 9E8284A0, 009C (r1 SUPERM SMCI--MB  1072009 AMI 
10013)
(XEN) ACPI: SSDT 9E828540, 0C7D (r2 Ther_R Ther_Rvp 1000 INTL 
20120711)
(XEN) ACPI: SSDT 9E8291C0, 0539 (r2  PmRef  Cpu0Ist 3000 INTL 
20051117)
(XEN) ACPI: SSDT 9E829700, 0B74 (r2 CpuRef  CpuSsdt 3000 INTL 
20051117)
(XEN) ACPI: MCFG 9E82A278, 003C (r1 SUPERM SMCI--MB  1072009 MSFT   
97)
(XEN) ACPI: HPET 9E82A2B8, 0038 (r1 SUPERM SMCI--MB  1072009 AMI.   
 5)
(XEN) ACPI: SSDT 9E82A688, 57F6 (r2 SaSsdt  SaSsdt  3000 INTL 
20120711)
(XEN) ACPI: ASF! 9E82FE80, 00A5 (r32 INTEL   HCG1 TFSM
F4240)
(XEN) ACPI: DMAR 9E82FF28, 0080 (r1 INTEL  BDW 1 INTL   
 1)
(XEN) System RAM: 32493MB (33273104kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at -00085e00
(XEN) Domain heap initialised
(XEN) vesafb: framebuffer at 0xd100, mapped to 
0x82c000201000, using 1920k, total 1920k
(XEN) vesafb: mode is 800x600x32, linelength=3200, font 8x8
(XEN) vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
(XEN) CPU Vendor: Intel, Family 6 (0x6), Model 60 (0x3c), Stepping 3 
(raw 000306c3)
(XEN) SMBIOS 2.7 present.
(XEN) DMI 2.7 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x1808 (32 bits)
(XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0]
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:1804,1:0], pm1x_evt[1:1800,1:0]
(XEN) ACPI: 32/64X FACS address mismatch in FADT - 
9e848f80/, using 32
(XEN) ACPI: wakeup_vec[9e848f8c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee0
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x08] address[0xfec0] gsi_base[0])
 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  9b71d6a759a6835c7723afa3d79e1e7f10da4396
baseline version:
 xen  a29f19f7476a13cd6d7757b3aa5eb26ffd9e3c54

Last test of basis   146573  2020-01-29 14:00:38 Z0 days
Testing same since   146577  2020-01-29 17:00:44 Z0 days1 attempts


People who touched revisions under test:
  Igor Druzhinin 
  Tamas K Lengyel 

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
   a29f19f747..9b71d6a759  9b71d6a759a6835c7723afa3d79e1e7f10da4396 -> smoke

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

Re: [Xen-devel] [PATCH v4 3/7] x86/hyperv: provide Hyper-V hypercall functions

[Wei Liu]

On Thu, Jan 23, 2020 at 12:28:00PM +0100, Jan Beulich wrote:
> On 22.01.2020 21:23, Wei Liu wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-x86/guest/hyperv-hcall.h
> > @@ -0,0 +1,98 @@
> > +/**
> > + * asm-x86/guest/hyperv-hcall.h
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms and conditions of the GNU General Public
> > + * License, version 2, as published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > + * General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public
> > + * License along with this program; If not, see 
> > .
> > + *
> > + * Copyright (c) 2019 Microsoft.
> > + */
> > +
> > +#ifndef __X86_HYPERV_HCALL_H__
> > +#define __X86_HYPERV_HCALL_H__
> > +
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +static inline uint64_t hv_do_hypercall(uint64_t control, paddr_t 
> > input_addr,
> > +   paddr_t output_addr)
> > +{
> > +uint64_t status;
> > +register unsigned long r8 asm("r8") = output_addr;
> > +
> > +asm volatile ("INDIRECT_CALL %P[hcall_page]"
> > +  : "=a" (status), "+c" (control),
> > +"+d" (input_addr) ASM_CALL_CONSTRAINT
> > +  : "r" (r8),
> > +[hcall_page] "p" (fix_x_to_virt(FIX_X_HYPERV_HCALL))
> > +  : "memory");
> > +
> > +return status;
> > +}
> > +
> > +static inline uint64_t hv_do_fast_hypercall(uint16_t code,
> > +uint64_t input1, uint64_t 
> > input2)
> > +{
> > +uint64_t status;
> > +uint64_t control = code | HV_HYPERCALL_FAST_BIT;
> > +register unsigned long r8 asm("r8") = input2;
> > +
> > +asm volatile ("INDIRECT_CALL %P[hcall_page]"
> > +  : "=a" (status), "+c" (control),
> > +"+d" (input1) ASM_CALL_CONSTRAINT
> > +  : "r" (r8),
> > +[hcall_page] "p" (fix_x_to_virt(FIX_X_HYPERV_HCALL))
> > +  :);
> 
> This comes through as a smiley in my mail viewer, because of the
> missing blanks immediately inside the outermost parentheses.

Fixed.

> 
> > +
> > +return status;
> > +}
> > +
> > +static inline uint64_t hv_do_rep_hypercall(uint16_t code, uint16_t 
> > rep_count,
> > +   uint16_t varhead_size,
> > +   paddr_t input, paddr_t output)
> > +{
> > +uint64_t control = code;
> > +uint64_t status;
> > +uint16_t rep_comp;
> > +
> > +control |= (uint64_t)varhead_size << HV_HYPERCALL_VARHEAD_OFFSET;
> > +control |= (uint64_t)rep_count << HV_HYPERCALL_REP_COMP_OFFSET;
> 
> What about the upper bit(s) spilling into the next field? Perhaps
> better use MASK_INSR() here too?
> 

I didn't do it because we didn't have the two MASKs defined. Plus I
trusted Hyper-V to reject what's abnormal so I wouldn't worry too much
about it.


> Also, this leaves the START field zero, which makes me think you
> mean ...
> 
> > +do {
> > +status = hv_do_hypercall(control, input, output);
> > +if ( (status & HV_HYPERCALL_RESULT_MASK) != HV_STATUS_SUCCESS )
> > +break;
> > +
> > +rep_comp = MASK_EXTR(status, HV_HYPERCALL_REP_COMP_MASK);
> > +
> > +control &= ~HV_HYPERCALL_REP_START_MASK;
> > +control |= MASK_INSR(rep_comp, HV_HYPERCALL_REP_COMP_MASK);
> 
> ... REP_START_MASK here.

Yes, indeed. Fixed.

Wei.

> 
> Jan

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

Re: [Xen-devel] [PATCH v4 3/7] x86/hyperv: provide Hyper-V hypercall functions

[Wei Liu]

On Thu, Jan 23, 2020 at 11:13:10AM +0100, Jan Beulich wrote:
> On 22.01.2020 22:57, Andrew Cooper wrote:
> > On 22/01/2020 20:23, Wei Liu wrote:
> >> These functions will be used later to make hypercalls to Hyper-V.
> >>
> >> Signed-off-by: Wei Liu 
> > 
> > After some experimentation,
> > 
> > diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> > index cbc5701214..3708a60b5c 100644
> > --- a/xen/arch/x86/xen.lds.S
> > +++ b/xen/arch/x86/xen.lds.S
> > @@ -329,6 +329,8 @@ SECTIONS
> >    efi = .;
> >  #endif
> >  
> > +  hv_hcall_page = ABSOLUTE(0x82d0bfffe000);
> > +
> >    /* Sections to be discarded */
> >    /DISCARD/ : {
> >     *(.exit.text)
> > 
> > in the linker script lets direct calls work correctly:
> > 
> > 82d080637935:   b9 01 00 00 40  mov    $0x4001,%ecx
> > 82d08063793a:   0f 30   wrmsr 
> > 82d08063793c:   ba 21 03 00 00  mov    $0x321,%edx
> > 82d080637941:   bf 01 00 00 00  mov    $0x1,%edi
> > 82d080637946:   e8 ac 4f c7 ff  callq  82d0802ac8f7
> > <__set_fixmap_x>
> > 82d08063794b:   41 b8 00 00 00 00   mov    $0x0,%r8d
> > 82d080637951:   b9 ff ff 00 00  mov    $0x,%ecx
> > 82d080637956:   ba 00 00 00 00  mov    $0x0,%edx
> > 82d08063795b:   e8 a0 66 9c 3f  callq  82d0bfffe000
> > 
> > 82d080637960:   66 83 f8 02 cmp    $0x2,%ax
> > 
> > but it does throw:
> > 
> > Difference at .init:00032edf is 0xc000 (expected 0x4000)
> > Difference at .init:00032edf is 0xc000 (expected 0x4000)
> > 
> > as a diagnostic presumably from the final link  (both with a standard
> > Debian 2.28 binutils, and upstream 2.33 build).  I'm not sure what its
> > trying to complain about, as both xen.gz and xen.efi have correctly
> > generated code.
> > 
> > Depending on whether they are benign or not, a linker-friendly
> > fix_to_virt() should be all we need to keep these strictly as direct calls.
> 
> They're benign in the particular case of them actually resulting
> from relative CALLs, which hence require no relocation to be
> recorded in xen.efi's .reloc section. But they should nevertheless
> be silenced. We've been discussing this on irc, iirc. The absolute
> address used wants to move by 1Gb for the $(ALT_BASE) intermediate
> linking step.

FWIW I don't see those messages with my current code.

Wei.

> 
> Jan

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 

Re: [Xen-devel] [ANNOUNCE] Xen 4.14 Development Update

[Andrew Cooper]

On 29/01/2020 12:36, Paul Durrant wrote:
> = Projects =
>
> == Hypervisor == 
>
> === x86 === 
>
> *  Intel Processor Trace virtualization enabling (v1)
>   -  Luwei Kang

Hasn't seen any activity in several releases.  Probably safe to drop. 
Also at least somewhat entangled with CPUID/MSR support.

> *  Fixes to #DB injection
>   -  Andrew Cooper

Parts of this manifested unexpected as XSA-308.  Rest is still work in
progress, with a TODO of how not to break introspection while fixing
it.  Unlikely to see any movement in the short term.

> *  CPUID/MSR Xen/toolstack improvements
>   -  Andrew Cooper

Very much in progress.

https://lore.kernel.org/xen-devel/20200127143444.25538-1-andrew.coop...@citrix.com/
is v2 of the "move data into the migration stream" aspect.

I'm working on "rework boot time CPUID handling" right now, which will
ultimately allow MSRs to be included in what gets configured.

All of this forms a base for "Virtualise MSR_ARCH_CAPS for guests" which
is (now) the logical goal of the work, and might be a better tracking name.

In reality, for now I mean only the various *_NO bits because ...

> *  eIBRS
>   -  Andrew Cooper

... it is unfortunately quite tangled on top.  Because of the overloaded
nature of IBRS, even having Xen try to use eIBRS while only supporting
the legacy IBRS interface for guests turns into a massive headache.

I'm fairly confident that eIBRS support shouldn't be attempted until
general MSR_ARCH_CAPS is in place.

> *  Improvements to domain_crash()
>   -  Andrew Cooper

This is a fairly small piece of work, but I don't have time to progress
it.  I've got a rebased branch if anyone else feels like spending the
day or so it will take to get up to quality.

Another task is AMD hardware mitigations for everything
SpeculativeStoreBypass (i.e. pre-L1TF) and later.  There are crippling
performance problems caused by the lack of MSR_VIRT_SPEC_CTRL.  Since
that series I posted for that, Rome has gained several other hardware
features which need exposing to guests suitably.

~Andrew

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

Re: [Xen-devel] [PATCH] x86: undo part of "refine link time stub area related assertion"

[Andrew Cooper]

On 29/01/2020 17:03, Jan Beulich wrote:
> The original check was not too strict: While we don't use one page of
> memory per CPU, we do use ons page of VA space per CPU. It is the

one.

> latter which matters here.
>
> Undo that part of the change, but leave everything else in place.
>
> Signed-off-by: Jan Beulich 

Ok, but this begs the question why?  If the stubs are tightly packed
together, but the linear space isn't, we end up having loads of aliases
of the stubs.

There is no security benefit for doing so, but there is a real
performance cost from not compacting the linear space.  Most notably,
two threads unable to share a 4k tlb entry for their own stubs, but also
reduced cache locality of reference for the pagetables requires to map
the overly-large linear space.

~Andrew

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

[Xen-devel] [PATCH v7 3/3] x86 / vmx: use a MEMF_no_refcount domheap page for APIC_DEFAULT_PHYS_BASE

[Paul Durrant]

vmx_alloc_vlapic_mapping() currently contains some very odd looking code
that allocates a MEMF_no_owner domheap page and then shares with the guest
as if it were a xenheap page. This then requires vmx_free_vlapic_mapping()
to call a special function in the mm code: free_shared_domheap_page().

By using a MEMF_no_refcount domheap page instead, the odd looking code in
vmx_alloc_vlapic_mapping() can simply use get_page_and_type() to set up a
writable mapping before insertion in the P2M and vmx_free_vlapic_mapping()
can simply release the page using put_page_alloc_ref() followed by
put_page_and_type(). This then allows free_shared_domheap_page() to be
purged.

Signed-off-by: Paul Durrant 
Reviewed-by: Jan Beulich 
---
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: "Roger Pau Monné" 

v4:
 - Use a MEMF_no_refcount page rather than a 'normal' page

v2:
 - Set an initial value for max_pages rather than avoiding the check in
   assign_pages()
 - Make domain_destroy() optional
---
 xen/arch/x86/hvm/vmx/vmx.c | 21 ++---
 xen/arch/x86/mm.c  | 10 --
 xen/include/asm-x86/mm.h   |  2 --
 3 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 606f3dc2eb..7423d2421b 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3028,12 +3028,22 @@ static int vmx_alloc_vlapic_mapping(struct domain *d)
 if ( !cpu_has_vmx_virtualize_apic_accesses )
 return 0;
 
-pg = alloc_domheap_page(d, MEMF_no_owner);
+pg = alloc_domheap_page(d, MEMF_no_refcount);
 if ( !pg )
 return -ENOMEM;
+
+if ( !get_page_and_type(pg, d, PGT_writable_page) )
+{
+/*
+ * The domain can't possibly know about this page yet, so failure
+ * here is a clear indication of something fishy going on.
+ */
+domain_crash(d);
+return -ENODATA;
+}
+
 mfn = page_to_mfn(pg);
 clear_domain_page(mfn);
-share_xen_page_with_guest(pg, d, SHARE_rw);
 d->arch.hvm.vmx.apic_access_mfn = mfn;
 
 return set_mmio_p2m_entry(d, paddr_to_pfn(APIC_DEFAULT_PHYS_BASE), mfn,
@@ -3047,7 +3057,12 @@ static void vmx_free_vlapic_mapping(struct domain *d)
 
 d->arch.hvm.vmx.apic_access_mfn = _mfn(0);
 if ( !mfn_eq(mfn, _mfn(0)) )
-free_shared_domheap_page(mfn_to_page(mfn));
+{
+struct page_info *pg = mfn_to_page(mfn);
+
+put_page_alloc_ref(pg);
+put_page_and_type(pg);
+}
 }
 
 static void vmx_install_vlapic_mapping(struct vcpu *v)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 5b04db8c21..8b290ab3a2 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -496,16 +496,6 @@ void share_xen_page_with_guest(struct page_info *page, 
struct domain *d,
 spin_unlock(>page_alloc_lock);
 }
 
-void free_shared_domheap_page(struct page_info *page)
-{
-put_page_alloc_ref(page);
-if ( !test_and_clear_bit(_PGC_xen_heap, >count_info) )
-ASSERT_UNREACHABLE();
-page->u.inuse.type_info = 0;
-page_set_owner(page, NULL);
-free_domheap_page(page);
-}
-
 void make_cr3(struct vcpu *v, mfn_t mfn)
 {
 struct domain *d = v->domain;
diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h
index 06d64d494d..fafb3af46d 100644
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -320,8 +320,6 @@ struct page_info
 
 #define maddr_get_owner(ma)   (page_get_owner(maddr_to_page((ma
 
-extern void free_shared_domheap_page(struct page_info *page);
-
 #define frame_table ((struct page_info *)FRAMETABLE_VIRT_START)
 extern unsigned long max_page;
 extern unsigned long total_pages;
-- 
2.20.1


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

[Xen-devel] [PATCH v7 2/3] mm: make pages allocated with MEMF_no_refcount safe to assign

[Paul Durrant]

Currently it is unsafe to assign a domheap page allocated with
MEMF_no_refcount to a domain because the domain't 'tot_pages' will not
be incremented, but will be decrement when the page is freed (since
free_domheap_pages() has no way of telling that the increment was skipped).

This patch allocates a new 'count_info' bit for a PGC_extra flag
which is then used to mark pages when alloc_domheap_pages() is called
with MEMF_no_refcount. The MEMF_no_refcount is *not* passed through to
assign_pages() because it still needs to call domain_adjust_tot_pages() to
make sure the domain is appropriately referenced. assign_pages() is
accordingly modified to account pages marked with PGC_extra to an
'extra_pages' counter, which is then subtracted from 'tot_pages' before it
is checked against 'max_pages', thus avoiding over-allocation errors.

NOTE: steal_page() is also modified to decrement extra_pages in the case of
  a PGC_extra page being stolen from a domain.
  Also, whilst adding the extra_pages counter into struct domain, make
  some cosmetic fixes to comments for neighbouring fields.

Signed-off-by: Paul Durrant 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Wei Liu 
Cc: Volodymyr Babchuk 
Cc: "Roger Pau Monné" 

v7:
 - s/PGC_no_refcount/PGC_extra/g
 - Re-work allocation to account for 'extra' pages, also making it
   safe to assign PGC_extra pages post-allocation

v6:
 - Add an extra ASSERT into assign_pages() that PGC_no_refcount is not
   set if MEMF_no_refcount is clear
 - ASSERT that count_info is 0 in alloc_domheap_pages() and set to
   PGC_no_refcount rather than ORing

v5:
 - Make sure PGC_no_refcount is set before assign_pages() is called
 - Don't bother to clear PGC_no_refcount in free_domheap_pages() and
   drop ASSERT in free_heap_pages()
 - Don't latch count_info in free_heap_pages()

v4:
 - New in v4
---
 xen/arch/x86/mm.c|  5 
 xen/common/page_alloc.c  | 49 +---
 xen/include/asm-arm/mm.h |  5 +++-
 xen/include/asm-x86/mm.h |  7 --
 xen/include/xen/sched.h  | 18 ---
 5 files changed, 60 insertions(+), 24 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index f50c065af3..5b04db8c21 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4266,6 +4266,11 @@ int steal_page(
 page_list_del(page, >page_list);
 
 /* Unlink from original owner. */
+if ( page->count_info & PGC_extra )
+{
+ASSERT(d->extra_pages);
+d->extra_pages--;
+}
 if ( !(memflags & MEMF_no_refcount) && !domain_adjust_tot_pages(d, -1) )
 drop_dom_ref = true;
 
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 919a270587..a2d69f222a 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2256,6 +2256,7 @@ int assign_pages(
 {
 int rc = 0;
 unsigned long i;
+unsigned int extra_pages = 0;
 
 spin_lock(>page_alloc_lock);
 
@@ -2267,13 +2268,19 @@ int assign_pages(
 goto out;
 }
 
+for ( i = 0; i < (1 << order); i++ )
+if ( pg[i].count_info & PGC_extra )
+extra_pages++;
+
 if ( !(memflags & MEMF_no_refcount) )
 {
-if ( unlikely((d->tot_pages + (1 << order)) > d->max_pages) )
+unsigned int max_pages = d->max_pages - d->extra_pages - extra_pages;
+
+if ( unlikely((d->tot_pages + (1 << order)) > max_pages) )
 {
 gprintk(XENLOG_INFO, "Over-allocation for domain %u: "
 "%u > %u\n", d->domain_id,
-d->tot_pages + (1 << order), d->max_pages);
+d->tot_pages + (1 << order), max_pages);
 rc = -E2BIG;
 goto out;
 }
@@ -2282,13 +2289,17 @@ int assign_pages(
 get_knownalive_domain(d);
 }
 
+d->extra_pages += extra_pages;
 for ( i = 0; i < (1 << order); i++ )
 {
+unsigned long count_info = pg[i].count_info;
+
 ASSERT(page_get_owner([i]) == NULL);
-ASSERT(!pg[i].count_info);
+ASSERT(!(count_info & ~PGC_extra));
 page_set_owner([i], d);
 smp_wmb(); /* Domain pointer must be visible before updating refcnt. */
-pg[i].count_info = PGC_allocated | 1;
+count_info &= PGC_extra;
+pg[i].count_info = count_info | PGC_allocated | 1;
 page_list_add_tail([i], >page_list);
 }
 
@@ -2314,11 +2325,6 @@ struct page_info *alloc_domheap_pages(
 
 if ( memflags & MEMF_no_owner )
 memflags |= MEMF_no_refcount;
-else if ( (memflags & MEMF_no_refcount) && d )
-{
-ASSERT(!(memflags & MEMF_no_refcount));
-return NULL;
-}
 
 if ( !dma_bitsize )
 memflags &= ~MEMF_no_dma;
@@ -2331,11 +2337,23 @@ struct page_info *alloc_domheap_pages(
   memflags, d)) == NULL)) )
  return NULL;
 
-if ( d && !(memflags & 

[Xen-devel] [PATCH v7 0/3] purge free_shared_domheap_page()

[Paul Durrant]

Drop "mm: modify domain_adjust_tot_pages() to better handle a zero
adjustment".

Paul Durrant (3):
  x86 / vmx: move teardown from domain_destroy()...
  mm: make pages allocated with MEMF_no_refcount safe to assign
  x86 / vmx: use a MEMF_no_refcount domheap page for
APIC_DEFAULT_PHYS_BASE

 xen/arch/x86/hvm/vmx/vmx.c | 25 +++
 xen/arch/x86/mm.c  | 15 
 xen/common/page_alloc.c| 49 --
 xen/include/asm-arm/mm.h   |  5 +++-
 xen/include/asm-x86/mm.h   |  9 +++
 xen/include/xen/sched.h| 18 +++---
 6 files changed, 80 insertions(+), 41 deletions(-)

-- 
2.20.1


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

[Xen-devel] [PATCH v7 1/3] x86 / vmx: move teardown from domain_destroy()...

[Paul Durrant]

... to domain_relinquish_resources().

The teardown code frees the APICv page. This does not need to be done late
so do it in domain_relinquish_resources() rather than domain_destroy().

Signed-off-by: Paul Durrant 
---
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: "Roger Pau Monné" 
Cc: George Dunlap 

v4:
  - New in v4 (disaggregated from v3 patch #3)
---
 xen/arch/x86/hvm/vmx/vmx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index b262d38a7c..606f3dc2eb 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -419,7 +419,7 @@ static int vmx_domain_initialise(struct domain *d)
 return 0;
 }
 
-static void vmx_domain_destroy(struct domain *d)
+static void vmx_domain_relinquish_resources(struct domain *d)
 {
 if ( !has_vlapic(d) )
 return;
@@ -2240,7 +2240,7 @@ static struct hvm_function_table __initdata 
vmx_function_table = {
 .cpu_up_prepare   = vmx_cpu_up_prepare,
 .cpu_dead = vmx_cpu_dead,
 .domain_initialise= vmx_domain_initialise,
-.domain_destroy   = vmx_domain_destroy,
+.domain_relinquish_resources = vmx_domain_relinquish_resources,
 .vcpu_initialise  = vmx_vcpu_initialise,
 .vcpu_destroy = vmx_vcpu_destroy,
 .save_cpu_ctxt= vmx_save_vmcs_ctxt,
-- 
2.20.1


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

[Xen-devel] [PATCH] x86: undo part of "refine link time stub area related assertion"

[Jan Beulich]

The original check was not too strict: While we don't use one page of
memory per CPU, we do use ons page of VA space per CPU. It is the
latter which matters here.

Undo that part of the change, but leave everything else in place.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -2,7 +2,6 @@
 /* Modified for i386/x86-64 Xen by Keir Fraser */
 
 #include 
-#include 
 #include 
 #undef ENTRY
 #undef ALIGN
@@ -353,7 +352,7 @@ SECTIONS
 }
 
 ASSERT(__2M_rwdata_end <= XEN_VIRT_END - XEN_VIRT_START + __XEN_VIRT_START -
-  DIV_ROUND_UP(NR_CPUS, STUBS_PER_PAGE) * PAGE_SIZE,
+  NR_CPUS * PAGE_SIZE,
"Xen image overlaps stubs area")
 
 #ifdef CONFIG_KEXEC

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  a29f19f7476a13cd6d7757b3aa5eb26ffd9e3c54
baseline version:
 xen  f910c3ebc6a178c5cbbc0868134be536fae7f7cf

Last test of basis   146557  2020-01-28 19:00:54 Z0 days
Testing same since   146573  2020-01-29 14:00:38 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Olaf Hering 
  Roger Pau Monné 
  Tamas K Lengyel 
  Wei Liu 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   f910c3ebc6..a29f19f747  a29f19f7476a13cd6d7757b3aa5eb26ffd9e3c54 -> smoke

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

Re: [Xen-devel] [PATCH v2] x86/HVM: relinquish resources also from hvm_domain_destroy()

[Andrew Cooper]

On 29/01/2020 12:59, Jan Beulich wrote:
> Domain creation failure paths don't call domain_relinquish_resources(),
> yet allocations and alike done from hvm_domain_initialize() need to be
> undone nevertheless. Call the function also from hvm_domain_destroy(),
> after making sure all descendants are idempotent.
>
> Note that while viridian_{domain,vcpu}_deinit() were already used in
> ways suggesting they're idempotent, viridian_time_vcpu_deinit() actually
> wasn't: One can't kill a timer that was never initialized.
>
> For hvm_destroy_all_ioreq_servers()'s purposes make
> relocate_portio_handler() return whether the to be relocated port range
> was actually found. This seems cheaper than introducing a flag into
> struct hvm_domain's ioreq_server sub-structure.
>
> In hvm_domain_initialise() additionally
> - use XFREE() also to replace adjacent xfree(),
> - use hvm_domain_relinquish_resources() as being idempotent now.
> There as well as in hvm_domain_destroy() the explicit call to
> rtc_deinit() isn't needed anymore.
>
> In hvm_domain_relinquish_resources() additionally drop a no longer
> relevant if().
>
> Fixes: e7a9b5e72f26 ("viridian: separately allocate domain and vcpu 
> structures")
> Fixes: 26fba3c85571 ("viridian: add implementation of synthetic timers")
> Signed-off-by: Jan Beulich 
> Reviewed-by: Roger Pau Monné 

Acked-by: Andrew Cooper 

Any idempotency improvements in the destroy paths are a good thing. 
We'll be wanting this work complete for the stable toolstack hypercall
work, so we don't have to include a logically broken call into the brand
new API.

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

Re: [Xen-devel] [PATCH v4 1/7] x86: provide executable fixmap facility

[Wei Liu]

On Wed, Jan 29, 2020 at 03:59:32PM +0100, Jan Beulich wrote:
[...]
> >> I seem to recall recommending to export absolute symbols from
> >> assembly code. The question is how easily usable they would
> >> be from C, or how clumsy the resulting code would look.
> > 
> > Even if I use absolute symbol I would still need to define a macro for
> > it. There is no way around it, because enum can't be used in asm or
> > linker script.
> 
> I'm afraid I don't understand. Why a macro? The absolute symbol would
> be there to communicate the relevant (enum-derived) value to the
> linker script. I.e. with
> 
> enum { e0, e1, e2 };
> 
> in some C file
> 
> asm ( ".equ GBL_e2, %c0; .global GBL_e2" :: "i" (e2) );
> 
> which I then hope would allow you to use GBL_e2 in the linker
> script ASSERT().
> 

OK. Let me see if this is possible.

Wei.

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

Re: [Xen-devel] [PATCH 5/5] OvmfPkg/OvmfXen: Set PcdFSBClock

[Laszlo Ersek]

On 01/29/20 13:12, Anthony PERARD wrote:
> Update gEfiMdePkgTokenSpaceGuid.PcdFSBClock so it can have the correct
> value when SecPeiDxeTimerLibCpu start to use it for the APIC timer.
> 
> Currently, nothing appear to use the value in PcdFSBClock before
> XenPlatformPei had a chance to set it even though TimerLib is included
> in modules runned before XenPlatformPei.
> 
> XenPlatformPei doesn't use any of the functions that would use that
> value. No other modules in the PEI phase seems to use the TimerLib
> before PcdFSBClock is set. There are currently two other modules in
> the PEI phase that needs the TimerLib:
> - S3Resume2Pei, but only because LocalApicLib needs it, but nothing is
>   using the value from PcdFSBClock.
> - CpuMpPei, but I believe it only runs after XenPlatformPei
> 
> Before the PEI phase, there's the SEC phase, and SecMain needs
> TimerLib because of LocalApicLib. And it initialise the APIC timers
> for the debug agent. But I don't think any of the DebugLib that
> OvmfXen could use are actually using the *Delay functions in TimerLib,
> and so would not use the value from PcdFSBClock which would be
> uninitialised.
> 
> A simple runtime test showed that TimerLib doesn't use PcdFSBClock
> value before it is set.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
> Signed-off-by: Anthony PERARD 
> ---
>  OvmfPkg/OvmfXen.dsc   | 4 +---
>  OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 1 +
>  OvmfPkg/XenPlatformPei/Xen.c  | 4 
>  3 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
> index 8c11efe9b709..190d7400c148 100644
> --- a/OvmfPkg/OvmfXen.dsc
> +++ b/OvmfPkg/OvmfXen.dsc
> @@ -442,9 +442,6 @@ [PcdsFixedAtBuild]
># Point to the MdeModulePkg/Application/UiApp/UiApp.inf
>gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 
> 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
>  
> -  ## Xen vlapic's frequence is 100 MHz
> -  gEfiMdePkgTokenSpaceGuid.PcdFSBClock|1
> -
>  
> 
>  #
>  # Pcd Dynamic Section - list of all EDK II PCD Entries defined by this 
> Platform
> @@ -468,6 +465,7 @@ [PcdsDynamicDefault]
>gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base|0x0
>gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x8
>  
> +  gEfiMdePkgTokenSpaceGuid.PcdFSBClock

(1) This syntax looks strange; I thought it was mandatory to provide a
default value too.

https://edk2-docs.gitbooks.io/edk-ii-dsc-specification/content/2_dsc_overview/28_pcd_sections.html

-
2.8.3.1 PcdsDynamicDefault

[...]

The format for a boolean or numeric datum type PCD entry in this section is:

PcdTokenSpaceGuidCName.PcdCName|Value
-

I'm not sure if the "build" utility accepts this intentionally, or by
mistake.

Can you simply keep the "|1" part too?

Otherwise, I'm OK with the argument laid out in the commit message.
(Thank you for the detailed commit message!)

With (1) fixed:

Reviewed-by: Laszlo Ersek 

Thanks!
Laszlo


>gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0
>  
># Set video resolution for text setup.
> diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf 
> b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> index 335a442538c2..177200f3b7e5 100644
> --- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> +++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> @@ -83,6 +83,7 @@ [Pcd]
>gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode
>gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable
>gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask
> +  gEfiMdePkgTokenSpaceGuid.PcdFSBClock
>gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy
>gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
>  
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index d6cdc9a8e31c..fc990462dccc 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -504,6 +504,10 @@ CalibrateLapicTimer (
>  / (TscTick2 - TscTick);
>DEBUG ((DEBUG_INFO, "APIC Freq % 8lu Hz\n", Freq));
>  
> +  ASSERT (Freq <= MAX_UINT32);
> +  Status = PcdSet32S (PcdFSBClock, Freq);
> +  ASSERT_RETURN_ERROR (Status);
> +
>UnmapXenPage (SharedInfo);
>  
>  Exit:
> 


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

Re: [Xen-devel] [PATCH 4/5] OvmfPkg/XenPlatformPei: Calibrate APIC timer frequency

[Laszlo Ersek]

On 01/29/20 13:12, Anthony PERARD wrote:
> Calculate the frequency of the APIC timer that Xen provides.
> 
> Even though the frequency is currently hard-coded, it isn't part of
> the public ABI that Xen provides and thus may change at any time. OVMF
> needs to determine the frequency by an other mean.
> 
> Fortunately, Xen provides a way to determines the frequency of the
> TSC, so we can use TSC to calibrate the frequency of the APIC timer.
> That information is found in the shared_info page which we map and
> unmap once done (XenBusDxe is going to map the page somewhere else).
> 
> The calculated frequency is only logged in this patch, it will be used
> in a following patch.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
> Signed-off-by: Anthony PERARD 
> ---
> CC: Roger Pau Monné 
> ---
>  OvmfPkg/XenPlatformPei/XenPlatformPei.inf |   1 +
>  OvmfPkg/XenPlatformPei/Platform.h |   5 +
>  OvmfPkg/XenPlatformPei/Platform.c |   1 +
>  OvmfPkg/XenPlatformPei/Xen.c  | 123 ++
>  4 files changed, 130 insertions(+)

I'll review this superficially; it should be approved by someone from
xen-devel:

> diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf 
> b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> index 0ef77db92c03..335a442538c2 100644
> --- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> +++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> @@ -52,6 +52,7 @@ [LibraryClasses]
>DebugLib
>HobLib
>IoLib
> +  LocalApicLib
>PciLib
>ResourcePublicationLib
>PeiServicesLib
> diff --git a/OvmfPkg/XenPlatformPei/Platform.h 
> b/OvmfPkg/XenPlatformPei/Platform.h
> index 7661f4a8de0a..97e482a065f0 100644
> --- a/OvmfPkg/XenPlatformPei/Platform.h
> +++ b/OvmfPkg/XenPlatformPei/Platform.h
> @@ -127,6 +127,11 @@ XenGetE820Map (
>UINT32 *Count
>);
>  
> +VOID
> +CalibrateLapicTimer (
> +  VOID
> +  );
> +
>  extern EFI_BOOT_MODE mBootMode;
>  
>  extern UINT8 mPhysMemAddressWidth;
> diff --git a/OvmfPkg/XenPlatformPei/Platform.c 
> b/OvmfPkg/XenPlatformPei/Platform.c
> index 717fd0ab1a45..e9511eb40c62 100644
> --- a/OvmfPkg/XenPlatformPei/Platform.c
> +++ b/OvmfPkg/XenPlatformPei/Platform.c
> @@ -448,6 +448,7 @@ InitializeXenPlatform (
>InitializeRamRegions ();
>  
>InitializeXen ();
> +  CalibrateLapicTimer ();
>  
>if (mBootMode != BOOT_ON_S3_RESUME) {
>  ReserveEmuVariableNvStore ();
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index c41fecdc486e..d6cdc9a8e31c 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -19,6 +19,7 @@
>  //
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -386,3 +387,125 @@ InitializeXen (
>  
>return EFI_SUCCESS;
>  }
> +
> +
> +EFI_STATUS
> +MapSharedInfoPage (
> +  IN VOID *PagePtr
> +  )
> +{
> +  xen_add_to_physmap_t  Parameters;
> +  INTN  ReturnCode;
> +
> +  Parameters.domid = DOMID_SELF;
> +  Parameters.space = XENMAPSPACE_shared_info;
> +  Parameters.idx = 0;
> +  Parameters.gpfn = (UINTN) PagePtr >> EFI_PAGE_SHIFT;

(1) Please remove the space character from "(UINTN) PagePtr". Inserting
a space character is a bad and confusing habit in edk2, because it masks
the fact that the cast operator has one of the strongest bindings in the
C language. So I try to keep it out of OvmfPkg and ArmVirtPkg.

> +  ReturnCode = XenHypercallMemoryOp (XENMEM_add_to_physmap, );
> +  if (ReturnCode != 0) {
> +return EFI_NO_MAPPING;
> +  }
> +  return EFI_SUCCESS;
> +}
> +
> +VOID
> +UnmapXenPage (
> +  IN VOID *PagePtr
> +  )
> +{
> +  xen_remove_from_physmap_t Parameters;
> +  INTN  ReturnCode;
> +
> +  Parameters.domid = DOMID_SELF;
> +  Parameters.gpfn = (UINTN) PagePtr >> EFI_PAGE_SHIFT;

(2) Ditto.

> +  ReturnCode = XenHypercallMemoryOp (XENMEM_remove_from_physmap, 
> );
> +  ASSERT (ReturnCode == 0);
> +}
> +
> +
> +STATIC
> +UINT64
> +GetCPUFreq (
> +  IN XEN_VCPU_TIME_INFO *VcpuTime
> +  )
> +{
> +  UINT32 Version;
> +  UINT32 TSCToSystemMultiplier;
> +  INT8   TSCShift;
> +  UINT64 CPUFreq;
> +
> +  do {
> +Version = VcpuTime->Version;
> +MemoryFence ();
> +TSCToSystemMultiplier = VcpuTime->TSCToSystemMultiplier;
> +TSCShift = VcpuTime->TSCShift;
> +MemoryFence ();
> +  } while (((Version & 1) != 0) && (Version != VcpuTime->Version));
> +
> +  CPUFreq = (10ULL << 32) / TSCToSystemMultiplier;

(3) I understand that OvmfXen is X64, and so this code will not be built
for IA32 in practice. Still, for sticking with the coding style, it's
better to use LShiftU64() here, and then DivU64x32().

> +  if (TSCShift >= 0) {
> +  CPUFreq >>= VcpuTime->TSCShift;
> +  } else {
> +  CPUFreq <<= -VcpuTime->TSCShift;
> +  }

(4) Please use LShiftU64() and RShiftU64().

(5) I think there's a typo here: you just fished out "TscShift" from the
shared info page; we should used that cached value, and not access the
shared info page again. 

Re: [Xen-devel] [PATCH v6 5/9] x86/mem_sharing: use default_access in add_to_physmap

[Tamas K Lengyel]

On Wed, Jan 29, 2020 at 9:09 AM Tamas K Lengyel
 wrote:
>
> On Wed, Jan 29, 2020 at 7:56 AM Tamas K Lengyel
>  wrote:
> >
> > On Wed, Jan 29, 2020 at 7:44 AM Jan Beulich  wrote:
> > >
> > > On 29.01.2020 15:05, Tamas K Lengyel wrote:
> > > > On Wed, Jan 29, 2020 at 6:27 AM Jan Beulich  wrote:
> > > >>
> > > >> On 28.01.2020 18:02, Tamas K Lengyel wrote:
> > > >>> On Tue, Jan 28, 2020 at 9:56 AM Jan Beulich  wrote:
> > > 
> > >  On 27.01.2020 19:06, Tamas K Lengyel wrote:
> > > > When plugging a hole in the target physmap don't use the access 
> > > > permission
> > > > returned by __get_gfn_type_access as it can be non-sensical, 
> > > > leading to
> > > > spurious vm_events being sent out for access violations at 
> > > > unexpected
> > > > locations. Make use of p2m->default_access instead.
> > > 
> > >  As before, to me "can be non-sensical" is insufficient as a reason
> > >  here. If it can also be a "good" value, it still remains unclear
> > >  why in that case p2m->default_access is nevertheless the right
> > >  value to use.
> > > >>>
> > > >>> I have already explained in the previous version of the patch why I
> > > >>> said "can be". Forgot to change the commit message from "can be" to
> > > >>> "is".
> > > >>
> > > >> Changing just the commit message would be easy while committing.
> > > >> But even with the change I would ask why this is. Looking at
> > > >> ept_get_entry() (and assuming p2m_pt_get_entry() will work
> > > >> similarly, minus the p2m_access_t which can't come out of the
> > > >> PTE just yet), I see
> > > >>
> > > >> if ( is_epte_valid(ept_entry) )
> > > >> {
> > > >> *t = p2m_recalc_type(recalc || ept_entry->recalc,
> > > >>  ept_entry->sa_p2mt, p2m, gfn);
> > > >> *a = ept_entry->access;
> > > >>
> > > >> near its end. Which means even a hole can have its access field
> > > >> set. So it's still not clear to me from the description why
> > > >> p2m->default_access is uniformly the value to use. Wouldn't you
> > > >> rather want to override the original value only if it's
> > > >> p2m_access_n together with p2m_invalid or p2m_mmio_dm (but not
> > > >> paged-out pages)?
> > > >
> > > > At this point I would just rather state that add_to_physmap only works
> > > > on actual holes, not with paged-out pages. In fact, I would like to
> > > > see mem_paging being dropped from the codebase entirely since it's
> > > > been abandoned for years and noone expressing any interest in keeping
> > > > it. In the interim I would rather not spend unnecessary cycles on
> > > > speculating about potential corner-cases of mem_paging when noone
> > > > actually uses it.
> > > >
> > > >> Of course then the question is whether there
> > > >> wouldn't be an ambiguity with p2m_access_n having got set
> > > >> explicitly on the page. But maybe this is impossible for
> > > >> p2m_invalid / p2m_mmio_dm?
> > > >
> > > > As far as mem_access permissions go, I don't know of any usecase that
> > > > would set mem_access permission on a hole even if by looks of it it is
> > > > technically possible. At this point I would rather just put this
> > > > corner-case's description in a comment.
> > >
> > > I think I would ack a revised patch having this properly explained.
> >
> > That's fine, I'll add some comments to this effect and reword the
> > commit message.
> >
>
> Actually, looking at the implementation of p2m_set_mem_access it's not
> clear to me whether we can even have a hole with a mem_access
> permission set. Can you have a "hole" type with a valid gfn? If not,
> this is a non-issue since p2m_set_mem_access only sets mem_access
> permissions that pass !gfn_eq(gfn, INVALID_GFN).

Never mind, of course gfn can be anything (ie valid) since it's not
tied to whether the entry actually exists or not.

Tamas

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

Re: [Xen-devel] [PATCH 3/5] OvmfPkg/IndustryStandard/Xen: Apply EDK2 coding style to XEN_VCPU_TIME_INFO

[Laszlo Ersek]

On 01/29/20 13:12, Anthony PERARD wrote:
> We are going to use new fields from the Xen headers. Apply the EDK2
> coding style so that the code that is going to use it doesn't look out
> of place.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
> Signed-off-by: Anthony PERARD 
> ---
>  OvmfPkg/Include/IndustryStandard/Xen/xen.h | 17 +
>  1 file changed, 9 insertions(+), 8 deletions(-)

This is highly appreciated. Comments below:

> 
> diff --git a/OvmfPkg/Include/IndustryStandard/Xen/xen.h 
> b/OvmfPkg/Include/IndustryStandard/Xen/xen.h
> index e55d93263285..ac9155089902 100644
> --- a/OvmfPkg/Include/IndustryStandard/Xen/xen.h
> +++ b/OvmfPkg/Include/IndustryStandard/Xen/xen.h
> @@ -183,10 +183,10 @@ struct vcpu_time_info {
>   * The correct way to interact with the version number is similar to
>   * Linux's seqlock: see the implementations of 
> read_seqbegin/read_seqretry.
>   */
> -UINT32 version;
> +UINT32 Version;
>  UINT32 pad0;
> -UINT64 tsc_timestamp;   /* TSC at last update of time vals.  */
> -UINT64 system_time; /* Time, in nanosecs, since boot.*/
> +UINT64 TSCTimestamp;   /* TSC at last update of time vals.  */

(1) Should be "TscTimestamp". Acronyms are de-capitalized when composed
into longer identifiers, to maintain a consistent CamelCase.

> +UINT64 SystemTime; /* Time, in nanosecs, since boot.*/
>  /*
>   * Current system time:
>   *   system_time +
> @@ -194,11 +194,11 @@ struct vcpu_time_info {
>   * CPU frequency (Hz):
>   *   ((10^9 << 32) / tsc_to_system_mul) >> tsc_shift
>   */
> -UINT32 tsc_to_system_mul;
> -INT8   tsc_shift;
> +UINT32 TSCToSystemMultiplier;
> +INT8   TSCShift;

(2) Ditto (both fields).

>  INT8   pad1[3];
>  }; /* 32 bytes */
> -typedef struct vcpu_time_info vcpu_time_info_t;
> +typedef struct vcpu_time_info XEN_VCPU_TIME_INFO;
>  
>  struct vcpu_info {
>  /*
> @@ -234,7 +234,7 @@ struct vcpu_info {
>  #endif /* XEN_HAVE_PV_UPCALL_MASK */
>  xen_ulong_t evtchn_pending_sel;
>  struct arch_vcpu_info arch;
> -struct vcpu_time_info time;
> +struct vcpu_time_info Time;
>  }; /* 64 bytes (x86) */
>  #ifndef __XEN__
>  typedef struct vcpu_info vcpu_info_t;
> @@ -250,7 +250,7 @@ typedef struct vcpu_info vcpu_info_t;
>   * of this structure remaining constant.
>   */
>  struct shared_info {
> -struct vcpu_info vcpu_info[XEN_LEGACY_MAX_VCPUS];
> +struct vcpu_info VcpuInfo[XEN_LEGACY_MAX_VCPUS];

Yes, this is a good example. "Vcpu" and not "VCPU" or "VCpu".

>  
>  /*
>   * A domain can create "event channels" on which it can send and receive
> @@ -299,6 +299,7 @@ struct shared_info {
>  };
>  #ifndef __XEN__
>  typedef struct shared_info shared_info_t;
> +typedef struct shared_info XEN_SHARED_INFO;
>  #endif
>  
>  /* Turn a plain number into a C UINTN constant. */
> 

Assuming the OVMF platforms continue to build at this stage into the
series, and provided that (1) and (2) are fixed:

Reviewed-by: Laszlo Ersek 


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

Re: [Xen-devel] [PATCH 2/5] MdePkg: Allow PcdFSBClock to by Dynamic

[Laszlo Ersek]

On 01/29/20 13:12, Anthony PERARD wrote:
> We are going to want to change the value of PcdFSBClock at run time in
> OvmfXen, so move it to the PcdsDynamic section.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
> Signed-off-by: Anthony PERARD 
> ---
> CC: Bob Feng 
> CC: Liming Gao 
> ---
>  MdePkg/MdePkg.dec | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> index d022cc5e3ef2..8f5a48346e50 100644
> --- a/MdePkg/MdePkg.dec
> +++ b/MdePkg/MdePkg.dec
> @@ -2194,10 +2194,6 @@ [PcdsFixedAtBuild,PcdsPatchableInModule]
># @ValidList  0x8001 | 8, 16, 32
>gEfiMdePkgTokenSpaceGuid.PcdPort80DataWidth|8|UINT8|0x002d
>  
> -  ## This value is used to configure X86 Processor FSB clock.
> -  # @Prompt FSB Clock.
> -  gEfiMdePkgTokenSpaceGuid.PcdFSBClock|2|UINT32|0x000c
> -
>## The maximum printable number of characters. UefLib functions: 
> AsciiPrint(), AsciiErrorPrint(),
>#  PrintXY(), AsciiPrintXY(), Print(), ErrorPrint() base on this PCD value 
> to print characters.
># @Prompt Maximum Printable Number of Characters.
> @@ -2297,5 +2293,9 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, 
> PcdsDynamicEx]
># @Prompt Boot Timeout (s)
>gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0x|UINT16|0x002c
>  
> +  ## This value is used to configure X86 Processor FSB clock.
> +  # @Prompt FSB Clock.
> +  gEfiMdePkgTokenSpaceGuid.PcdFSBClock|2|UINT32|0x000c
> +
>  [UserExtensions.TianoCore."ExtraFiles"]
>MdePkgExtra.uni
> 

Looks good to me:

Reviewed-by: Laszlo Ersek 

Mike or Liming will have to ACK.

Thanks!
Laszlo


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

Re: [Xen-devel] [PATCH v6 5/9] x86/mem_sharing: use default_access in add_to_physmap

[Tamas K Lengyel]

On Wed, Jan 29, 2020 at 7:56 AM Tamas K Lengyel
 wrote:
>
> On Wed, Jan 29, 2020 at 7:44 AM Jan Beulich  wrote:
> >
> > On 29.01.2020 15:05, Tamas K Lengyel wrote:
> > > On Wed, Jan 29, 2020 at 6:27 AM Jan Beulich  wrote:
> > >>
> > >> On 28.01.2020 18:02, Tamas K Lengyel wrote:
> > >>> On Tue, Jan 28, 2020 at 9:56 AM Jan Beulich  wrote:
> > 
> >  On 27.01.2020 19:06, Tamas K Lengyel wrote:
> > > When plugging a hole in the target physmap don't use the access 
> > > permission
> > > returned by __get_gfn_type_access as it can be non-sensical, leading 
> > > to
> > > spurious vm_events being sent out for access violations at unexpected
> > > locations. Make use of p2m->default_access instead.
> > 
> >  As before, to me "can be non-sensical" is insufficient as a reason
> >  here. If it can also be a "good" value, it still remains unclear
> >  why in that case p2m->default_access is nevertheless the right
> >  value to use.
> > >>>
> > >>> I have already explained in the previous version of the patch why I
> > >>> said "can be". Forgot to change the commit message from "can be" to
> > >>> "is".
> > >>
> > >> Changing just the commit message would be easy while committing.
> > >> But even with the change I would ask why this is. Looking at
> > >> ept_get_entry() (and assuming p2m_pt_get_entry() will work
> > >> similarly, minus the p2m_access_t which can't come out of the
> > >> PTE just yet), I see
> > >>
> > >> if ( is_epte_valid(ept_entry) )
> > >> {
> > >> *t = p2m_recalc_type(recalc || ept_entry->recalc,
> > >>  ept_entry->sa_p2mt, p2m, gfn);
> > >> *a = ept_entry->access;
> > >>
> > >> near its end. Which means even a hole can have its access field
> > >> set. So it's still not clear to me from the description why
> > >> p2m->default_access is uniformly the value to use. Wouldn't you
> > >> rather want to override the original value only if it's
> > >> p2m_access_n together with p2m_invalid or p2m_mmio_dm (but not
> > >> paged-out pages)?
> > >
> > > At this point I would just rather state that add_to_physmap only works
> > > on actual holes, not with paged-out pages. In fact, I would like to
> > > see mem_paging being dropped from the codebase entirely since it's
> > > been abandoned for years and noone expressing any interest in keeping
> > > it. In the interim I would rather not spend unnecessary cycles on
> > > speculating about potential corner-cases of mem_paging when noone
> > > actually uses it.
> > >
> > >> Of course then the question is whether there
> > >> wouldn't be an ambiguity with p2m_access_n having got set
> > >> explicitly on the page. But maybe this is impossible for
> > >> p2m_invalid / p2m_mmio_dm?
> > >
> > > As far as mem_access permissions go, I don't know of any usecase that
> > > would set mem_access permission on a hole even if by looks of it it is
> > > technically possible. At this point I would rather just put this
> > > corner-case's description in a comment.
> >
> > I think I would ack a revised patch having this properly explained.
>
> That's fine, I'll add some comments to this effect and reword the
> commit message.
>

Actually, looking at the implementation of p2m_set_mem_access it's not
clear to me whether we can even have a hole with a mem_access
permission set. Can you have a "hole" type with a valid gfn? If not,
this is a non-issue since p2m_set_mem_access only sets mem_access
permissions that pass !gfn_eq(gfn, INVALID_GFN).

Tamas

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

Re: [Xen-devel] [PATCH 1/5] OvmfPkg/XenResetVector: Silent a warning from nasm

[Laszlo Ersek]

On 01/29/20 13:12, Anthony PERARD wrote:
> To avoid nasm generating a warning, replace the macro by the value
> expected to be stored in eax.
>   Ia32/XenPVHMain.asm:76: warning: dword data exceeds bounds
> 
> Reported-by: Laszlo Ersek 
> Signed-off-by: Anthony PERARD 
> ---
>  OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm 
> b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> index 2df0f12e18cb..c761e9d30729 100644
> --- a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> +++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> @@ -73,7 +73,7 @@ xenPVHMain:
>  ;
>  ; parameter for Flat32SearchForBfvBase
>  ;
> -mov eax, ADDR_OF(fourGigabytes)
> +mov eax, 0   ; ADDR_OF(fourGigabytes)
>  add eax, edx ; add delta
>  
>  ;
> 

Reviewed-by: Laszlo Ersek 


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

Re: [Xen-devel] [PATCH] iommu/arm: Don't allow the same micro-TLB to be shared between domains

[Volodymyr Babchuk]

Hi Oleksandr,

Oleksandr Tyshchenko writes:

[...]
> @@ -434,19 +435,45 @@ static void ipmmu_tlb_invalidate(struct 
> ipmmu_vmsa_domain *domain)
>  }
>  
>  /* Enable MMU translation for the micro-TLB. */
> -static void ipmmu_utlb_enable(struct ipmmu_vmsa_domain *domain,
> -  unsigned int utlb)
> +static int ipmmu_utlb_enable(struct ipmmu_vmsa_domain *domain,
> + unsigned int utlb)
>  {
>  struct ipmmu_vmsa_device *mmu = domain->mmu;
> +uint32_t data;
Just nitpicking: I believe, that "imuctr" is better name than "data".

> +
> +/*
> + * We need to prevent the use cases where devices which use the same
> + * micro-TLB are assigned to different Xen domains (micro-TLB cannot be
> + * shared between multiple Xen domains, since it points to the context 
> bank
> + * to use for the page walk).
> + * As each Xen domain uses individual context bank pointed by context_id,
> + * we can potentially recognize that use case by comparing current and 
> new
> + * context_id for already enabled micro-TLB and prevent different context
> + * bank from being set.
> + */
> +data = ipmmu_read(mmu, IMUCTR(utlb));
I can see that this code is not covered by spinlock. So, I believe,
there can be a race comdition, when this register is being read on two
CPUs simultaneously.

> +if ( data & IMUCTR_MMUEN )
> +{
> +unsigned int context_id;
> +
> +context_id = (data & IMUCTR_TTSEL_MASK) >> IMUCTR_TTSEL_SHIFT;
> +if ( domain->context_id != context_id )
> +{
> +dev_err(mmu->dev, "Micro-TLB %u already assigned to IPMMU 
> context %u\n",
> +utlb, context_id);
> +return -EINVAL;
> +}
> +}
>  
>  /*
>   * TODO: Reference-count the micro-TLB as several bus masters can be
> - * connected to the same micro-TLB. Prevent the use cases where
> - * the same micro-TLB could be shared between multiple Xen domains.
> + * connected to the same micro-TLB.
>   */
>  ipmmu_write(mmu, IMUASID(utlb), 0);
> -ipmmu_write(mmu, IMUCTR(utlb), ipmmu_read(mmu, IMUCTR(utlb)) |
> +ipmmu_write(mmu, IMUCTR(utlb), data |
>  IMUCTR_TTSEL_MMU(domain->context_id) | IMUCTR_MMUEN);
> +
> +return 0;
>  }
>  
>  /* Disable MMU translation for the micro-TLB. */
> @@ -671,7 +698,12 @@ static int ipmmu_attach_device(struct ipmmu_vmsa_domain 
> *domain,
>  dev_info(dev, "Reusing IPMMU context %u\n", domain->context_id);
>  
>  for ( i = 0; i < fwspec->num_ids; ++i )
> -ipmmu_utlb_enable(domain, fwspec->ids[i]);
> +{
> +int ret = ipmmu_utlb_enable(domain, fwspec->ids[i]);
> +
> +if ( ret )
> +return ret;
I can't see error path where ipmmu_utlb_disable() would be called for
already enable uTLBs. Is this normal?

> +}
>  
>  return 0;
>  }


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

Re: [Xen-devel] Notes from December 2019 Xen F2F in Cambridge

[Andrew Cooper]

On 29/01/2020 00:36, Daniel Smith wrote:
> ### Discussion
>
> Requested: an in-Xen-tree reference domB implementation
>
> Note: the hypervisor interface supports starting a domain with a
> specified domid. This is not made available by the libxl toolstack.
>
> Xen has logic on permission delegation:
>
> -   in order for a VM to be able to delegate a permission to another, it
> itself must have that permission.
>
> -   **ACTION**: change this to be implemented as a XSM hook, so that
> > policy can choose to override this constraint, while
> > preserving it (ie. the existing behaviour) as the default.

I think it is worth highlighting that Xen's current behaviour appears to
have regressed an older usecase accidentally, and this proposed approach
is close to the original idea for hwdom.

> The domain id to assign to domB: should not be zero.
>
> -   Recommendation is to use a new fixed domain id allocated from the
> reserved range.
>
> -   See DOMID\_IDLE, DOMID\_INVALID, etc in \
>
> The is\_hardware\_domain predicate
>
> -   uses within Xen not necessarily all consistent?

I think the current uses of is_{hardware,control}_domain() should be
ok.  We've been fairly careful since the separate hwdom logic first went in.

> -   convert this to a XSM hook?
>
> -   ***to be determined***: performance impact since hits the avc?

What changes in a "even the XSM dummy policy is actually a flask policy"
world is that there is that the concept of "the hardware/control domain"
blurs.  Its all strictly "can $DOM do $X?".

That said, while "the" control domain can probably disappear, "the"
hardware domain probably can't.  There needs to be some entity
responsible for at least, getting notifications of newly hotplugged
hardware.

>
> Need to not shut down the platform when domB exits
>
> -   ie. distinguish domB from the hardware domain
>
> Since the hypervisor ABI is unstable, specifically the domain building
> hypercalls, will need to use the Xen toolstack:
>
> -   so libxc/libxl is the right interface for initial domB domain logic
> to use
>
> -   otherwise problematic when Xen hypervisor version is changed
>
> -   in the near term, this mandates the use of Linux + toolstack

This aspect is being worked on for plenty of other good reasons.

With any luck, it will be in process by the time domB wants to get
around to using it.

> ### Decision:
>
> use full Linux within domB as starting point
>
> -   unikraft discussed, not selected: is not deployed in production and
> want to use mature, QA\'d and externally maintained components
> -   32MB size for the kernel queried: proposers have no issue with that
> size
>
> Request made for a script interpreter in an example domB, with scripts
> to start dom0 with a given set of permissions
>
> -   aim is to make domB usable for other people\'s use cases and widen
> adoption, help other people with what we build for domB

I think the point was that the first reference domB ought to be
something fairly familiar and easily tweak-able.  In particular, that
reduces the quantity of concurrent work to do while getting the
hypervisor pieces in place.

However, I think it would also be helpful of stating the eventual design
goals, to keep the microkernel plan in mind.

~Andrew

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   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-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 

Re: [Xen-devel] [XEN PATCH v2 05/12] xen/include: remove include of Config.mk

[Jan Beulich]

On 29.01.2020 16:28, Jan Beulich wrote:
> On 17.01.2020 11:53, Anthony PERARD wrote:
>> It isn't necessary to include Config.mk here because this Makefile is
>> only used by xen/Rules.mk which already includes Config.mk.
> 
> And so is xen/test/livepatch/Makefile afaics from its parent dir
> Makefile. With this also adjusted (or it explained why I'm seeing
> things incorrectly) ...
> 
>> Signed-off-by: Anthony PERARD 
> 
> Reviewed-by: Jan Beulich 

And now I've seen that patch 6 does just this. I think such
common theme changes are, unless patches are overly large
already, better put all in on patch. Anyway - the R-b then
is unconditional.

Another question: The cover letter doesn't say anything about
some (or most) patches here being independent of one another,
and hence the option of them going in out of order. The one
here looks to be entirely standalone, for example.

Jan

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

Re: [Xen-devel] [XEN PATCH v2 05/12] xen/include: remove include of Config.mk

[Jan Beulich]

On 17.01.2020 11:53, Anthony PERARD wrote:
> It isn't necessary to include Config.mk here because this Makefile is
> only used by xen/Rules.mk which already includes Config.mk.

And so is xen/test/livepatch/Makefile afaics from its parent dir
Makefile. With this also adjusted (or it explained why I'm seeing
things incorrectly) ...

> Signed-off-by: Anthony PERARD 

Reviewed-by: Jan Beulich 

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

Re: [Xen-devel] [PATCH v6 3/4] mm: make MEMF_no_refcount pages safe to assign

[Durrant, Paul]

> -Original Message-
> From: Jan Beulich 
> Sent: 29 January 2020 15:15
> To: Durrant, Paul 
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; George Dunlap ;
> Ian Jackson ; Julien Grall ;
> Konrad Rzeszutek Wilk ; Stefano Stabellini
> ; Wei Liu ; Volodymyr Babchuk
> ; Roger Pau Monné 
> Subject: Re: [PATCH v6 3/4] mm: make MEMF_no_refcount pages safe to assign
> 
> On 29.01.2020 15:38, Paul Durrant wrote:
> > @@ -2371,6 +2383,8 @@ void free_domheap_pages(struct page_info *pg,
> unsigned int order)
> >
> >  if ( likely(d) && likely(d != dom_cow) )
> >  {
> > +long pages = 0;
> > +
> >  /* NB. May recursively lock from relinquish_memory(). */
> >  spin_lock_recursive(>page_alloc_lock);
> >
> > @@ -2386,9 +2400,11 @@ void free_domheap_pages(struct page_info *pg,
> unsigned int order)
> >  BUG();
> >  }
> >  arch_free_heap_page(d, [i]);
> > +if ( !(pg[i].count_info & PGC_no_refcount) )
> > +pages--;
> >  }
> >
> > -drop_dom_ref = !domain_adjust_tot_pages(d, -(1 << order));
> > +drop_dom_ref = !domain_adjust_tot_pages(d, pages);
> 
> Following from what I've just said on the previous patch, this needs
> further changing then as well. There'll need to be a per-domain
> "non-refcounted-pages" count, which - when transitioning from zero
> to non-zero is accompanied by obtaining a domain ref, and when
> transitioning back to zero causes this domain ref to be dropped.
> Otherwise, once the last ref-counted page was freed, the domain
> may become ready for final destruction, no matter how many non-
> refcounted pages there still are on its page lists. (An alternative
> model might be to include all pages in ->tot_pages, keep using just
> that for the domain ref acquire/release, and subtract the new
> count when e.g. comparing against ->max_pages.)

Yes, I think I'll adjust totpages unconditionally and then subtract the 
secondary count for comparison as it means I can leave the ref counting alone.

  Paul

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

Re: [Xen-devel] [PATCH v6 3/4] mm: make MEMF_no_refcount pages safe to assign

[Jan Beulich]

On 29.01.2020 15:38, Paul Durrant wrote:
> @@ -2371,6 +2383,8 @@ void free_domheap_pages(struct page_info *pg, unsigned 
> int order)
>  
>  if ( likely(d) && likely(d != dom_cow) )
>  {
> +long pages = 0;
> +
>  /* NB. May recursively lock from relinquish_memory(). */
>  spin_lock_recursive(>page_alloc_lock);
>  
> @@ -2386,9 +2400,11 @@ void free_domheap_pages(struct page_info *pg, unsigned 
> int order)
>  BUG();
>  }
>  arch_free_heap_page(d, [i]);
> +if ( !(pg[i].count_info & PGC_no_refcount) )
> +pages--;
>  }
>  
> -drop_dom_ref = !domain_adjust_tot_pages(d, -(1 << order));
> +drop_dom_ref = !domain_adjust_tot_pages(d, pages);

Following from what I've just said on the previous patch, this needs
further changing then as well. There'll need to be a per-domain
"non-refcounted-pages" count, which - when transitioning from zero
to non-zero is accompanied by obtaining a domain ref, and when
transitioning back to zero causes this domain ref to be dropped.
Otherwise, once the last ref-counted page was freed, the domain
may become ready for final destruction, no matter how many non-
refcounted pages there still are on its page lists. (An alternative
model might be to include all pages in ->tot_pages, keep using just
that for the domain ref acquire/release, and subtract the new
count when e.g. comparing against ->max_pages.)

Jan

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

Re: [Xen-devel] [PATCH v6 2/4] mm: modify domain_adjust_tot_pages() to better handle a zero adjustment

[Durrant, Paul]

> -Original Message-
> From: Jan Beulich 
> Sent: 29 January 2020 15:08
> To: Durrant, Paul 
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; George Dunlap ;
> Ian Jackson ; Julien Grall ;
> Konrad Rzeszutek Wilk ; Stefano Stabellini
> ; Wei Liu 
> Subject: Re: [PATCH v6 2/4] mm: modify domain_adjust_tot_pages() to better
> handle a zero adjustment
> 
> On 29.01.2020 15:38, Paul Durrant wrote:
> > --- a/xen/common/memory.c
> > +++ b/xen/common/memory.c
> > @@ -727,8 +727,7 @@ static long
> memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg)
> >   (j * (1UL << exch.out.extent_order)));
> >
> >  spin_lock(>page_alloc_lock);
> > -drop_dom_ref = (dec_count &&
> > -!domain_adjust_tot_pages(d, -
> dec_count));
> > +drop_dom_ref = !domain_adjust_tot_pages(d, -dec_count);
> 
> And it's only now that I see it in this shape that it becomes
> clear to me why the change above shouldn't be done, and why in
> your other patch code should be written similar to the above:
> The abstract model requires that the domain reference be
> dropped only when ->tot_pages _transitions_ to zero. No drop
> should occur if the count was already zero. Granted this may
> be technically impossible in the specific case here, but the
> code would still better reflect this general model, to prevent
> it getting (mis-)cloned into other places.
> 

Ok, I guess I'll drop this and then make sure that free_domheap_pages() avoids 
an erroneous ref drop.

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

Re: [Xen-devel] [PATCH v6 2/4] mm: modify domain_adjust_tot_pages() to better handle a zero adjustment

[Jan Beulich]

On 29.01.2020 15:38, Paul Durrant wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -727,8 +727,7 @@ static long 
> memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg)
>   (j * (1UL << exch.out.extent_order)));
>  
>  spin_lock(>page_alloc_lock);
> -drop_dom_ref = (dec_count &&
> -!domain_adjust_tot_pages(d, -dec_count));
> +drop_dom_ref = !domain_adjust_tot_pages(d, -dec_count);

And it's only now that I see it in this shape that it becomes
clear to me why the change above shouldn't be done, and why in
your other patch code should be written similar to the above:
The abstract model requires that the domain reference be
dropped only when ->tot_pages _transitions_ to zero. No drop
should occur if the count was already zero. Granted this may
be technically impossible in the specific case here, but the
code would still better reflect this general model, to prevent
it getting (mis-)cloned into other places.

Jan

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

Re: [Xen-devel] [PATCH v4 1/7] x86: provide executable fixmap facility

[Jan Beulich]

On 29.01.2020 15:42, Wei Liu wrote:
> On Tue, Jan 28, 2020 at 04:38:42PM +0100, Jan Beulich wrote:
>> On 28.01.2020 16:15, Wei Liu wrote:
>>> On Thu, Jan 23, 2020 at 12:04:00PM +0100, Jan Beulich wrote:
 On 22.01.2020 21:23, Wei Liu wrote:
> This allows us to set aside some address space for executable mapping.
> This fixed map range starts from XEN_VIRT_END so that it is within reach
> of the .text section.
>
> Shift the percpu stub range and livepatch range accordingly.

 Hmm, the livepatch range gets shrunk, not shifted, but yes. Is there
 a particular reason why you move the stubs area down? It looks as if
 the patch would be smaller overall if you didn't. (Possibly down
 the road the stubs area could be made part of the FIXADDR_X range
 anyway.)
>>>
>>> I think having a well-known fixed address is more useful for debugging.
>>>
>>> Going the other way around would mean the hypercall page location
>>> becomes dependent on the number of CPUs configured.
>>
>> Depending on how future insertions are done into
>> enum fixed_addresses_x, the address also won't be "well-known fixed".
> 
> Going back to this, not moving stubs will make the change to
> alloc_stub_page become unnecessary (one line); on the other hand it
> makes FIX_X_ADDR_START become XEN_VIRT_END - NR_CPUS * PAGE_SIZE -
> PAGE_SIZE.
> 
> Are you really concerned about this? I can make the change if you really
> want that, but it is just work with no apparent benefit.

Hmm, indeed, it's just one line. Not sure why I thought there
would be more of an effect. Leave it as is, and sorry for the
noise.

> --- a/xen/include/asm-x86/fixmap.h
> +++ b/xen/include/asm-x86/fixmap.h
> @@ -15,6 +15,9 @@
>  #include 
>  
>  #define FIXADDR_TOP (VMAP_VIRT_END - PAGE_SIZE)
> +#define FIXADDR_X_TOP (XEN_VIRT_END - PAGE_SIZE)
> +/* This constant is derived from enum fixed_addresses_x below */
> +#define MAX_FIXADDR_X_SIZE (2 << PAGE_SHIFT)

 If this can't be properly derived, then a BUILD_BUG_ON() is needed.
 But didn't we discuss on irc already possible approaches of how to
 derive it from the enum? Did none of this work?
>>>
>>> The only option I remember discussing was to define macros instead of
>>> using enum. I said at the time at would make us lose the ability to
>>> dynamically size this area.
>>>
>>> If there are other ways that I missed, let me know.
>>
>> I seem to recall recommending to export absolute symbols from
>> assembly code. The question is how easily usable they would
>> be from C, or how clumsy the resulting code would look.
> 
> Even if I use absolute symbol I would still need to define a macro for
> it. There is no way around it, because enum can't be used in asm or
> linker script.

I'm afraid I don't understand. Why a macro? The absolute symbol would
be there to communicate the relevant (enum-derived) value to the
linker script. I.e. with

enum { e0, e1, e2 };

in some C file

asm ( ".equ GBL_e2, %c0; .global GBL_e2" :: "i" (e2) );

which I then hope would allow you to use GBL_e2 in the linker
script ASSERT().

> I want to keep using enum because that would allow us to size the area
> according to Kconfig.

Of course, I fully agree with this goal.

Jan

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

Re: [Xen-devel] [PATCH v6 5/9] x86/mem_sharing: use default_access in add_to_physmap

[Tamas K Lengyel]

On Wed, Jan 29, 2020 at 7:44 AM Jan Beulich  wrote:
>
> On 29.01.2020 15:05, Tamas K Lengyel wrote:
> > On Wed, Jan 29, 2020 at 6:27 AM Jan Beulich  wrote:
> >>
> >> On 28.01.2020 18:02, Tamas K Lengyel wrote:
> >>> On Tue, Jan 28, 2020 at 9:56 AM Jan Beulich  wrote:
> 
>  On 27.01.2020 19:06, Tamas K Lengyel wrote:
> > When plugging a hole in the target physmap don't use the access 
> > permission
> > returned by __get_gfn_type_access as it can be non-sensical, leading to
> > spurious vm_events being sent out for access violations at unexpected
> > locations. Make use of p2m->default_access instead.
> 
>  As before, to me "can be non-sensical" is insufficient as a reason
>  here. If it can also be a "good" value, it still remains unclear
>  why in that case p2m->default_access is nevertheless the right
>  value to use.
> >>>
> >>> I have already explained in the previous version of the patch why I
> >>> said "can be". Forgot to change the commit message from "can be" to
> >>> "is".
> >>
> >> Changing just the commit message would be easy while committing.
> >> But even with the change I would ask why this is. Looking at
> >> ept_get_entry() (and assuming p2m_pt_get_entry() will work
> >> similarly, minus the p2m_access_t which can't come out of the
> >> PTE just yet), I see
> >>
> >> if ( is_epte_valid(ept_entry) )
> >> {
> >> *t = p2m_recalc_type(recalc || ept_entry->recalc,
> >>  ept_entry->sa_p2mt, p2m, gfn);
> >> *a = ept_entry->access;
> >>
> >> near its end. Which means even a hole can have its access field
> >> set. So it's still not clear to me from the description why
> >> p2m->default_access is uniformly the value to use. Wouldn't you
> >> rather want to override the original value only if it's
> >> p2m_access_n together with p2m_invalid or p2m_mmio_dm (but not
> >> paged-out pages)?
> >
> > At this point I would just rather state that add_to_physmap only works
> > on actual holes, not with paged-out pages. In fact, I would like to
> > see mem_paging being dropped from the codebase entirely since it's
> > been abandoned for years and noone expressing any interest in keeping
> > it. In the interim I would rather not spend unnecessary cycles on
> > speculating about potential corner-cases of mem_paging when noone
> > actually uses it.
> >
> >> Of course then the question is whether there
> >> wouldn't be an ambiguity with p2m_access_n having got set
> >> explicitly on the page. But maybe this is impossible for
> >> p2m_invalid / p2m_mmio_dm?
> >
> > As far as mem_access permissions go, I don't know of any usecase that
> > would set mem_access permission on a hole even if by looks of it it is
> > technically possible. At this point I would rather just put this
> > corner-case's description in a comment.
>
> I think I would ack a revised patch having this properly explained.

That's fine, I'll add some comments to this effect and reword the
commit message.

Tamas

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

[Xen-devel] [PATCH] iommu/arm: Don't allow the same micro-TLB to be shared between domains

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

For the IPMMU-VMSA we need to prevent the use cases where devices
which use the same micro-TLB are assigned to different Xen domains
(micro-TLB cannot be shared between multiple Xen domains, since it
points to the context bank to use for the page walk).

As each Xen domain uses individual context bank pointed by context_id,
we can potentially recognize that use case by comparing current and new
context_id for the already enabled micro-TLB and prevent different
context bank from being set.

Signed-off-by: Oleksandr Tyshchenko 

---

CC: Julien Grall 
CC: Stefano Stabellini 
CC: Volodymyr Babchuk 
CC: Yoshihiro Shimoda 

---
 xen/drivers/passthrough/arm/ipmmu-vmsa.c | 44 +++-
 1 file changed, 38 insertions(+), 6 deletions(-)

diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c 
b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
index 9cfae7e..c21d2d7 100644
--- a/xen/drivers/passthrough/arm/ipmmu-vmsa.c
+++ b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
@@ -257,6 +257,7 @@ static DEFINE_SPINLOCK(ipmmu_devices_lock);
 #define IMUCTR_TTSEL_MMU(n)((n) << 4)
 #define IMUCTR_TTSEL_PMB   (8 << 4)
 #define IMUCTR_TTSEL_MASK  (15 << 4)
+#define IMUCTR_TTSEL_SHIFT 4
 #define IMUCTR_FLUSH   (1 << 1)
 #define IMUCTR_MMUEN   (1 << 0)
 
@@ -434,19 +435,45 @@ static void ipmmu_tlb_invalidate(struct ipmmu_vmsa_domain 
*domain)
 }
 
 /* Enable MMU translation for the micro-TLB. */
-static void ipmmu_utlb_enable(struct ipmmu_vmsa_domain *domain,
-  unsigned int utlb)
+static int ipmmu_utlb_enable(struct ipmmu_vmsa_domain *domain,
+ unsigned int utlb)
 {
 struct ipmmu_vmsa_device *mmu = domain->mmu;
+uint32_t data;
+
+/*
+ * We need to prevent the use cases where devices which use the same
+ * micro-TLB are assigned to different Xen domains (micro-TLB cannot be
+ * shared between multiple Xen domains, since it points to the context bank
+ * to use for the page walk).
+ * As each Xen domain uses individual context bank pointed by context_id,
+ * we can potentially recognize that use case by comparing current and new
+ * context_id for already enabled micro-TLB and prevent different context
+ * bank from being set.
+ */
+data = ipmmu_read(mmu, IMUCTR(utlb));
+if ( data & IMUCTR_MMUEN )
+{
+unsigned int context_id;
+
+context_id = (data & IMUCTR_TTSEL_MASK) >> IMUCTR_TTSEL_SHIFT;
+if ( domain->context_id != context_id )
+{
+dev_err(mmu->dev, "Micro-TLB %u already assigned to IPMMU context 
%u\n",
+utlb, context_id);
+return -EINVAL;
+}
+}
 
 /*
  * TODO: Reference-count the micro-TLB as several bus masters can be
- * connected to the same micro-TLB. Prevent the use cases where
- * the same micro-TLB could be shared between multiple Xen domains.
+ * connected to the same micro-TLB.
  */
 ipmmu_write(mmu, IMUASID(utlb), 0);
-ipmmu_write(mmu, IMUCTR(utlb), ipmmu_read(mmu, IMUCTR(utlb)) |
+ipmmu_write(mmu, IMUCTR(utlb), data |
 IMUCTR_TTSEL_MMU(domain->context_id) | IMUCTR_MMUEN);
+
+return 0;
 }
 
 /* Disable MMU translation for the micro-TLB. */
@@ -671,7 +698,12 @@ static int ipmmu_attach_device(struct ipmmu_vmsa_domain 
*domain,
 dev_info(dev, "Reusing IPMMU context %u\n", domain->context_id);
 
 for ( i = 0; i < fwspec->num_ids; ++i )
-ipmmu_utlb_enable(domain, fwspec->ids[i]);
+{
+int ret = ipmmu_utlb_enable(domain, fwspec->ids[i]);
+
+if ( ret )
+return ret;
+}
 
 return 0;
 }
-- 
2.7.4


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

[Xen-devel] [PATCH v4 0/2] docs: Migration design documents

[Paul Durrant]

Paul Durrant (2):
  docs/designs: Add a design document for non-cooperative live migration
  docs/designs: Add a design document for migration of xenstore data

 docs/designs/non-cooperative-migration.md | 272 ++
 docs/designs/xenstore-migration.md| 121 ++
 2 files changed, 393 insertions(+)
 create mode 100644 docs/designs/non-cooperative-migration.md
 create mode 100644 docs/designs/xenstore-migration.md

-- 
2.20.1


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

[Xen-devel] [PATCH v4 1/2] docs/designs: Add a design document for non-cooperative live migration

[Paul Durrant]

It has become apparent to some large cloud providers that the current
model of cooperative migration of guests under Xen is not usable as it
relies on software running inside the guest, which is likely beyond the
provider's control.
This patch introduces a proposal for non-cooperative live migration,
designed not to rely on any guest-side software.

Signed-off-by: Paul Durrant 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Wei Liu 

v4:
 - Fix issues raised by Wei

v2:
 - Use the term 'non-cooperative' instead of 'transparent'
 - Replace 'trust in' with 'reliance on' when referring to guest-side
   software
---
 docs/designs/non-cooperative-migration.md | 272 ++
 1 file changed, 272 insertions(+)
 create mode 100644 docs/designs/non-cooperative-migration.md

diff --git a/docs/designs/non-cooperative-migration.md 
b/docs/designs/non-cooperative-migration.md
new file mode 100644
index 00..5db3939db5
--- /dev/null
+++ b/docs/designs/non-cooperative-migration.md
@@ -0,0 +1,272 @@
+# Non-Cooperative Migration of Guests on Xen
+
+## Background
+
+The normal model of migration in Xen is driven by the guest because it was
+originally implemented for PV guests, where the guest must be aware it is
+running under Xen and is hence expected to co-operate. This model dates from
+an era when it was assumed that the host administrator had control of at least
+the privileged software running in the guest (i.e. the guest kernel) which may
+still be true in an enterprise deployment but is not generally true in a cloud
+environment. The aim of this design is to provide a model which is purely host
+driven, requiring no co-operation from the software running in the
+guest, and is thus suitable for cloud scenarios.
+
+PV guests are out of scope for this project because, as is outlined above, they
+have a symbiotic relationship with the hypervisor and therefore a certain level
+of co-operation can be assumed.
+
+HVM guests can already be migrated on Xen without guest co-operation but only
+if they don’t have PV drivers installed[1] or are in power state S3. The
+reason for not expecting co-operation if the guest is in S3 is obvious, but the
+reason co-operation is expected if PV drivers are installed is due to the
+nature of PV protocols.
+
+## Xenstore Nodes and Domain ID
+
+The PV driver model consists of a *frontend* and a *backend*. The frontend runs
+inside the guest domain and the backend runs inside a *service domain* which
+may or may not be domain 0. The frontend and backend typically pass data via
+memory pages which are shared between the two domains, but this channel of
+communication is generally established using xenstore (the store protocol
+itself being an exception to this for obvious chicken-and-egg reasons).
+
+Typical protocol establishment is based on use of two separate xenstore
+*areas*. If we consider PV drivers for the *netif* protocol (i.e. class vif)
+and assume the guest has domid X, the service domain has domid Y, and the vif
+has index Z then the frontend area will reside under the parent node:
+
+`/local/domain/Y/device/vif/Z`
+
+All backends, by convention, typically reside under parent node:
+
+`/local/domain/X/backend`
+
+and the normal backend area for vif Z would be:
+
+`/local/domain/X/backend/vif/Y/Z`
+
+but this should not be assumed.
+
+The toolstack will place two nodes in the frontend area to explicitly locate
+the backend:
+
+* `backend`: the fully qualified xenstore path of the backend area
+* `backend-id`: the domid of the service domain
+
+and similarly two nodes in the backend area to locate the frontend area:
+
+* `frontend`: the fully qualified xenstore path of the frontend area
+* `frontend-id`: the domid of the guest domain
+
+
+The guest domain only has write permission to the frontend area and similarly
+the service domain only has write permission to the backend area, but both ends
+have read permission to both areas.
+
+Under both frontend and backend areas is a node called *state*. This is key to
+protocol establishment. Upon PV device creation the toolstack will set the
+value of both state nodes to 1 (XenbusStateInitialising[2]). This should cause
+enumeration of appropriate devices in both the guest and service domains. The
+backend device, once it has written any necessary protocol specific information
+into the xenstore backend area (to be read by the frontend driver) will update
+the backend state node to 2 (XenbusStateInitWait). From this point on PV
+protocols differ slightly; the following illustration is true of the netif
+protocol.
+
+Upon seeing a backend state value of 2, the frontend driver will then read the
+protocol specific information, write details of grant references (for shared
+pages) and event channel ports (for signalling) that it has created, and set
+the state node in the frontend area to 4 

Re: [Xen-devel] [PATCH v3 8/8] RFC: Sketch constructors, DomainCreateNew

[George Dunlap]

On 1/28/20 8:41 PM, Nick Rosbrook wrote:
>> I think marshaling and unmarshalling should be fine, *as long as* the
>> structure being unmarshalled actually went through the
>> libxl__init() function first.
>>
>> In fact, I was kicking around the idea of adding a non-exported field to
>> all the generated structs -- maybe "bool initalized" -- and having the
>> .fromC() methods set this to 'true', and the .toC() methods return an
>> error if it wasn't set.  But then we'd need to write custom JSON
>> marshallers to handle these.
> 
> I *think* to guarantee that libxl__init() has been called when
> unmarshaling, we would need to generate UnmarshalJSON functions to
> implement json.Unmarshaler. E.g.,:
> 
> func (dd *DeviceDisk) UnmarshalJSON(data []byte) error {
> if dd == nil { // Or maybe this is the 'initialized' check you 
> mentioned
> dd, err := NewDeviceDisk()
> if err != nil {
> return err
> }
> }
> 
> return json.Unmarshal(data, dd)
> }
> 
> AFAICT, this would be required for someone to unmarshal a complete
> domain configuration in one go.

So the above will fix an issue like this:

Scenario A
1. Make a structure from version V by calling NewType()
2. Fill in what you want
3. Marshal it into json
4. Marshal it out of json into a structure from version V+1, with new fields

With code as above, the new elements of structure V+1 will be
initialized by the NewType() in the UnmarshalJSON() method.

But the problem I'm worried about is this:

Scenario B
1. Make an empty, uninitialized structure, without calling NewType()
2. Fill in some fields
3. Marshal it into json
4. Marshal it out of json (with the same version)

In the case above, step 3 encodes all the known fields with *golang*'s
zero values, rather than libxl's default values, and so step 4 will
clobber any defaults written by NewType() with golang zero values again.

Of course, something like scenario A might happen without the marshal /
unmarshal, which is why I thought having a private 'initialized' flag
might be helpful.  But then what you'd want to solve B by having the
unmarshaller read the initialized flag and add it to the json / read it
from the json (since the json package itself can't do it).

(Naturally people can directly modify the json to have the 'initialized'
flag set, but if you get to that level of messing around, you get to
keep all the pieces if it breaks.)

>> As far as further steps -- do you have a clear idea what kind of
>> functionality you'd like to see possible by the time of the feature
>> freeze (probably in May)?  Do you have plans to use these bindings
>> yourself, and if so, how?
>>
>> For my part, I want to start and reap guests.  The latter will require
>> adding event callback functionality which will require more thought (and
>> perhaps expose more libxl issues).  But I don't yet have a clear target
>> beyond that.
> 
> Yes, I plan on using these bindings in redctl (our Redfield toolstack)
> [1], to replace our os/exec calls to xl. To fully make that
> transition, we would need domain start/stop, PCI and network
> attach/detach, as well as some utilities (most of which are either
> implemented, or would be easy to do). But, making that transition is
> relatively low on the priority list right now, so I can't commit to a
> timeline unfortunately.

Sure, nor I; but having a goal always helps, even if it's only best-effort.

Looking at redctl, it seems like actually a pretty full-featured
toolstack -- that seems like a nice complete target to aim at. :-)

>> Re function calls -- do we want to just manually duplicate them as
>> needed, or try to get some sort of IDL support?
> 
> I think it will make more sense to manually duplicate them as needed.
> That way, we can be more particular about function signatures etc. to
> ensure they are idiomatic Go. Also, I am of the opinion that a minimal
> API is a better place to start. Which brings me to another question
> and potential work item:
> 
> Do we want to re-evaluate what is currently implemented in the API? Do
> you have plans to use everything that is currently there? If not, it
> might be nice to trim off things we don't need right now.

I think we should make sure that things actually work.  The very
original golang bindings I wrote to be able to control cpupools, so I
think those functions should stay.  But I'm not sure if anyone's ever
used ConsoleGetTty.  Like `xl.cfg` parsing, it's the sort of thing that
*somebody* will probably want eventually; so I'm inclined to say it
would be less cost to just test it and make sure it works than to remove
it and re-add it when someone decides they need it.

Did you have anything in particular in mind?

I was sort of thinking what we might do is leave `xenlight` as mostly
just a plain wrapper around the libxl C functions, as close to what
might be generated as possible; and then have another package that would
do something more 

[Xen-devel] [PATCH v4 2/2] docs/designs: Add a design document for migration of xenstore data

[Paul Durrant]

This patch details proposes extra migration data and xenstore protocol
extensions to support non-cooperative live migration of guests.

Signed-off-by: Paul Durrant 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Wei Liu 

v4:
 - Drop the restrictions on special paths

v3:
 - New in v3
---
 docs/designs/xenstore-migration.md | 121 +
 1 file changed, 121 insertions(+)
 create mode 100644 docs/designs/xenstore-migration.md

diff --git a/docs/designs/xenstore-migration.md 
b/docs/designs/xenstore-migration.md
new file mode 100644
index 00..991236e201
--- /dev/null
+++ b/docs/designs/xenstore-migration.md
@@ -0,0 +1,121 @@
+# Xenstore Migration
+
+## Background
+
+The design for *Non-Cooperative Migration of Guests*[1] explains that extra
+save records are required in the migrations stream to allow a guest running
+PV drivers to be migrated without its co-operation. Moreover the save
+records must include details of registered xenstore watches as well as
+content; information that cannot currently be recovered from `xenstored`,
+and hence some extension to the xenstore protocol[2] will also be required.
+
+The *libxenlight Domain Image Format* specification[3] already defines a
+record type `EMULATOR_XENSTORE_DATA` but this is not suitable for
+transferring xenstore data pertaining to the domain directly as it is
+specified such that keys are relative to the path
+`/local/domain/$dm_domid/device-model/$domid`. Thus it is necessary to
+define at least one new save record type.
+
+## Proposal
+
+### New Save Record
+
+A new mandatory record type should be defined within the libxenlight Domain
+Image Format:
+
+`0x0007: DOMAIN_XENSTORE_DATA`
+
+The format of each of these new records should be as follows:
+
+
+```
+0 1 2 3 4 5 6 7 octet
++++
+| type   | record specific data   |
+++|
+...
++-+
+```
+
+
+| Field | Description |
+|---|---|
+| `type` | 0x: invalid |
+|| 0x0001: node data |
+|| 0x0002: watch data |
+|| 0x0003 - 0x: reserved for future use |
+
+
+where data is always in the form of a NUL separated and terminated tuple
+as follows
+
+
+**node data**
+
+
+`|||`
+
+
+`` is considered relative to the domain path `/local/domain/$domid`
+and hence must not begin with `/`.
+`` and `` should be suitable to formulate a `WRITE` operation
+to the receiving xenstore and `` should be similarly suitable
+to formulate a subsequent `SET_PERMS` operation.
+
+**watch data**
+
+
+`||`
+
+`` again is considered relative and, together with ``, should
+be suitable to formulate an `ADD_DOMAIN_WATCHES` operation (see below).
+
+
+### Protocol Extension
+
+The `WATCH` operation does not allow specification of a ``; it is
+assumed that the watch pertains to the domain that owns the shared ring
+over which the operation is passed. Hence, for the tool-stack to be able
+to register a watch on behalf of a domain a new operation is needed:
+
+```
+ADD_DOMAIN_WATCHES  ||+
+
+Adds watches on behalf of the specified domain.
+
+ is a NUL separated tuple of |. The semantics of this
+operation are identical to the domain issuing WATCH || for
+each .
+```
+
+The watch information for a domain also needs to be extracted from the
+sending xenstored so the following operation is also needed:
+
+```
+GET_DOMAIN_WATCHES  |   ||* 
+
+Gets the list of watches that are currently registered for the domain.
+
+ is a NUL separated tuple of |. The sub-list returned
+will start at  into the the overall list of watches and may be
+truncated such that the returned data fits within XENSTORE_PAYLOAD_MAX.
+If  is beyond the end of the overall list then the returned sub-
+list will be empty. If the value of  changes then it indicates
+that the overall watch list has changed and thus it may be necessary
+to re-issue the operation for previous values of .
+```
+
+It may also be desirable to state in the protocol specification that
+the `INTRODUCE` operation should not clear the `` specified such that
+a `RELEASE` operation followed by an `INTRODUCE` operation form an
+idempotent pair. The current implementation of *C xentored* does this
+(in the `domain_conn_reset()` function) but this could be dropped as this
+behaviour is not currently specified and the page will always be zeroed
+for a newly created domain.
+
+
+* * *
+
+[1] See 
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/designs/non-cooperative-migration.md
+[2] See 
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/xenstore.txt
+[3] See 
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/specs/libxl-migration-stream.pandoc
-- 
2.20.1


___
Xen-devel 

[Xen-devel] [PATCH v2 0/2] nvmx: implement support for MSR bitmaps

[Roger Pau Monne]

Hello,

Current nested VMX code advertises support for the MSR bitmap feature,
yet the implementation isn't done. Previous to this series Xen just maps
the nested guest MSR bitmap (as set by L1) and that's it, the L2 guest
ends up using the L1 MSR bitmap.

This series adds handling of the L2 MSR bitmap and merging with the L1
MSR bitmap and loading it into the nested guest VMCS.

Patch #2 makes sure the x2APIC MSR range is always trapped, or else a
guest with nested virtualization enabled could manage to access some of
the x2APIC MSR registers from the host.

Thanks, Roger.

Roger Pau Monne (2):
  nvmx: implement support for MSR bitmaps
  nvmx: always trap accesses to x2APIC MSRs

 xen/arch/x86/hvm/vmx/vvmx.c| 73 --
 xen/include/asm-x86/hvm/vmx/vvmx.h |  3 +-
 2 files changed, 72 insertions(+), 4 deletions(-)

-- 
2.25.0


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

[Xen-devel] [PATCH v2 1/2] nvmx: implement support for MSR bitmaps

[Roger Pau Monne]

Current implementation of nested VMX has a half baked handling of MSR
bitmaps for the L1 VMM: it maps the L1 VMM provided MSR bitmap, but
doesn't actually load it into the nested vmcs, and thus the nested
guest vmcs ends up using the same MSR bitmap as the L1 VMM.

This is wrong as there's no assurance that the set of features enabled
for the L1 vmcs are the same that L1 itself is going to use in the
nested vmcs, and thus can lead to misconfigurations.

For example L1 vmcs can use x2APIC virtualization and virtual
interrupt delivery, and thus some x2APIC MSRs won't be trapped so that
they can be handled directly by the hardware using virtualization
extensions. On the other hand, the nested vmcs created by L1 VMM might
not use any of such features, so using a MSR bitmap that doesn't trap
accesses to the x2APIC MSRs will be leaking them to the underlying
hardware.

Fix this by crafting a merged MSR bitmap between the one used by L1
and the nested guest.

Signed-off-by: Roger Pau Monné 
---
This seems better than what's done currently, but TBH there's a lot of
work to be done in nvmx in order to make it functional and secure that
I'm not sure whether building on top of the current implementation is
something sane to do, or it would be better to start from scratch and
re-implement nvmx to just support the minimum required set of VTx
features in a sane and safe way.
---
Changes since v1:
 - Split the x2APIC MSR fix into a separate patch.
 - Move setting MSR_BITMAP vmcs field into load_vvmcs_host_state for
   virtual vmexit.
 - Allocate memory with MEMF_no_owner.
 - Use tabs to align comment of the nestedvmx struct field.
---
 xen/arch/x86/hvm/vmx/vvmx.c| 63 --
 xen/include/asm-x86/hvm/vmx/vvmx.h |  3 +-
 2 files changed, 62 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 47eee1e5b9..c35b4bab84 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -128,6 +128,16 @@ int nvmx_vcpu_initialise(struct vcpu *v)
 unmap_domain_page(vw);
 }
 
+if ( cpu_has_vmx_msr_bitmap )
+{
+nvmx->msr_merged = alloc_domheap_page(d, MEMF_no_owner);
+if ( !nvmx->msr_merged )
+{
+gdprintk(XENLOG_ERR, "nest: allocation for MSR bitmap failed\n");
+return -ENOMEM;
+}
+}
+
 nvmx->ept.enabled = 0;
 nvmx->guest_vpid = 0;
 nvmx->vmxon_region_pa = INVALID_PADDR;
@@ -182,6 +192,11 @@ void nvmx_vcpu_destroy(struct vcpu *v)
 free_domheap_page(v->arch.hvm.vmx.vmwrite_bitmap);
 v->arch.hvm.vmx.vmwrite_bitmap = NULL;
 }
+if ( nvmx->msr_merged )
+{
+free_domheap_page(nvmx->msr_merged);
+nvmx->msr_merged = NULL;
+}
 }
  
 void nvmx_domain_relinquish_resources(struct domain *d)
@@ -548,6 +563,37 @@ unsigned long *_shadow_io_bitmap(struct vcpu *v)
 return nestedhvm_vcpu_iomap_get(port80, portED);
 }
 
+static void update_msrbitmap(struct vcpu *v)
+{
+struct nestedvmx *nvmx = _2_nvmx(v);
+struct vmx_msr_bitmap *msr_bitmap;
+unsigned int msr;
+
+ASSERT(__n2_exec_control(v) & CPU_BASED_ACTIVATE_MSR_BITMAP);
+
+if ( !nvmx->msrbitmap )
+return;
+
+msr_bitmap = __map_domain_page(nvmx->msr_merged);
+
+bitmap_or(msr_bitmap->read_low, nvmx->msrbitmap->read_low,
+  v->arch.hvm.vmx.msr_bitmap->read_low,
+  sizeof(msr_bitmap->read_low) * 8);
+bitmap_or(msr_bitmap->read_high, nvmx->msrbitmap->read_high,
+  v->arch.hvm.vmx.msr_bitmap->read_high,
+  sizeof(msr_bitmap->read_high) * 8);
+bitmap_or(msr_bitmap->write_low, nvmx->msrbitmap->write_low,
+  v->arch.hvm.vmx.msr_bitmap->write_low,
+  sizeof(msr_bitmap->write_low) * 8);
+bitmap_or(msr_bitmap->write_high, nvmx->msrbitmap->write_high,
+  v->arch.hvm.vmx.msr_bitmap->write_high,
+  sizeof(msr_bitmap->write_high) * 8);
+
+unmap_domain_page(msr_bitmap);
+
+__vmwrite(MSR_BITMAP, page_to_maddr(nvmx->msr_merged));
+}
+
 void nvmx_update_exec_control(struct vcpu *v, u32 host_cntrl)
 {
 u32 pio_cntrl = (CPU_BASED_ACTIVATE_IO_BITMAP
@@ -558,10 +604,15 @@ void nvmx_update_exec_control(struct vcpu *v, u32 
host_cntrl)
 shadow_cntrl = __n2_exec_control(v);
 pio_cntrl &= shadow_cntrl;
 /* Enforce the removed features */
-shadow_cntrl &= ~(CPU_BASED_ACTIVATE_MSR_BITMAP
-  | CPU_BASED_ACTIVATE_IO_BITMAP
+shadow_cntrl &= ~(CPU_BASED_ACTIVATE_IO_BITMAP
   | CPU_BASED_UNCOND_IO_EXITING);
-shadow_cntrl |= host_cntrl;
+/*
+ * Do NOT enforce the MSR bitmap currently used by L1, as certain hardware
+ * virtualization features require specific MSR bitmap settings, but
+ * without the guest also using these same features the bitmap could be
+ * leaking through unwanted MSR accesses.
+ */
+shadow_cntrl |= (host_cntrl & 

[Xen-devel] [PATCH v2 2/2] nvmx: always trap accesses to x2APIC MSRs

[Roger Pau Monne]

Nested VMX doesn't expose support for
SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE,
SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY or
SECONDARY_EXEC_APIC_REGISTER_VIRT, and hence the x2APIC MSRs should
always be trapped in the nested guest MSR bitmap, or else a nested
guest could access the hardware x2APIC MSRs given certain conditions.

Accessing the hardware MSRs could be achieved by forcing the L0 Xen to
use SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE and
SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY or
SECONDARY_EXEC_APIC_REGISTER_VIRT (if supported), and then creating a
L2 guest with a MSR bitmap that doesn't trap accesses to the x2APIC
MSR range. Then OR'ing both L0 and L1 MSR bitmaps would result in a
bitmap that doesn't trap certain x2APIC MSRs and a VMCS that doesn't
have SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE and
SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY or
SECONDARY_EXEC_APIC_REGISTER_VIRT set either.

Fix this by making sure x2APIC MSRs are always trapped in the nested
MSR bitmap.

Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - New in this version (split from #1 patch).
 - Use non-locked set_bit.
---
 xen/arch/x86/hvm/vmx/vvmx.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index c35b4bab84..69dd4cf6ea 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -589,6 +589,16 @@ static void update_msrbitmap(struct vcpu *v)
   v->arch.hvm.vmx.msr_bitmap->write_high,
   sizeof(msr_bitmap->write_high) * 8);
 
+/*
+ * Nested VMX doesn't support any x2APIC hardware virtualization, so
+ * make sure all the x2APIC MSRs are trapped.
+ */
+for ( msr = MSR_X2APIC_FIRST; msr <= MSR_X2APIC_FIRST + 0xff; msr++ )
+{
+__set_bit(msr, msr_bitmap->read_low);
+__set_bit(msr, msr_bitmap->write_low);
+}
+
 unmap_domain_page(msr_bitmap);
 
 __vmwrite(MSR_BITMAP, page_to_maddr(nvmx->msr_merged));
-- 
2.25.0


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

Re: [Xen-devel] [PATCH v6 5/9] x86/mem_sharing: use default_access in add_to_physmap

[Jan Beulich]

On 29.01.2020 15:05, Tamas K Lengyel wrote:
> On Wed, Jan 29, 2020 at 6:27 AM Jan Beulich  wrote:
>>
>> On 28.01.2020 18:02, Tamas K Lengyel wrote:
>>> On Tue, Jan 28, 2020 at 9:56 AM Jan Beulich  wrote:

 On 27.01.2020 19:06, Tamas K Lengyel wrote:
> When plugging a hole in the target physmap don't use the access permission
> returned by __get_gfn_type_access as it can be non-sensical, leading to
> spurious vm_events being sent out for access violations at unexpected
> locations. Make use of p2m->default_access instead.

 As before, to me "can be non-sensical" is insufficient as a reason
 here. If it can also be a "good" value, it still remains unclear
 why in that case p2m->default_access is nevertheless the right
 value to use.
>>>
>>> I have already explained in the previous version of the patch why I
>>> said "can be". Forgot to change the commit message from "can be" to
>>> "is".
>>
>> Changing just the commit message would be easy while committing.
>> But even with the change I would ask why this is. Looking at
>> ept_get_entry() (and assuming p2m_pt_get_entry() will work
>> similarly, minus the p2m_access_t which can't come out of the
>> PTE just yet), I see
>>
>> if ( is_epte_valid(ept_entry) )
>> {
>> *t = p2m_recalc_type(recalc || ept_entry->recalc,
>>  ept_entry->sa_p2mt, p2m, gfn);
>> *a = ept_entry->access;
>>
>> near its end. Which means even a hole can have its access field
>> set. So it's still not clear to me from the description why
>> p2m->default_access is uniformly the value to use. Wouldn't you
>> rather want to override the original value only if it's
>> p2m_access_n together with p2m_invalid or p2m_mmio_dm (but not
>> paged-out pages)?
> 
> At this point I would just rather state that add_to_physmap only works
> on actual holes, not with paged-out pages. In fact, I would like to
> see mem_paging being dropped from the codebase entirely since it's
> been abandoned for years and noone expressing any interest in keeping
> it. In the interim I would rather not spend unnecessary cycles on
> speculating about potential corner-cases of mem_paging when noone
> actually uses it.
> 
>> Of course then the question is whether there
>> wouldn't be an ambiguity with p2m_access_n having got set
>> explicitly on the page. But maybe this is impossible for
>> p2m_invalid / p2m_mmio_dm?
> 
> As far as mem_access permissions go, I don't know of any usecase that
> would set mem_access permission on a hole even if by looks of it it is
> technically possible. At this point I would rather just put this
> corner-case's description in a comment.

I think I would ack a revised patch having this properly explained.

Jan

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

Re: [Xen-devel] [PATCH v4 1/7] x86: provide executable fixmap facility

[Wei Liu]

On Tue, Jan 28, 2020 at 04:38:42PM +0100, Jan Beulich wrote:
> On 28.01.2020 16:15, Wei Liu wrote:
> > On Thu, Jan 23, 2020 at 12:04:00PM +0100, Jan Beulich wrote:
> >> On 22.01.2020 21:23, Wei Liu wrote:
> >>> This allows us to set aside some address space for executable mapping.
> >>> This fixed map range starts from XEN_VIRT_END so that it is within reach
> >>> of the .text section.
> >>>
> >>> Shift the percpu stub range and livepatch range accordingly.
> >>
> >> Hmm, the livepatch range gets shrunk, not shifted, but yes. Is there
> >> a particular reason why you move the stubs area down? It looks as if
> >> the patch would be smaller overall if you didn't. (Possibly down
> >> the road the stubs area could be made part of the FIXADDR_X range
> >> anyway.)
> > 
> > I think having a well-known fixed address is more useful for debugging.
> > 
> > Going the other way around would mean the hypercall page location
> > becomes dependent on the number of CPUs configured.
> 
> Depending on how future insertions are done into
> enum fixed_addresses_x, the address also won't be "well-known fixed".

Going back to this, not moving stubs will make the change to
alloc_stub_page become unnecessary (one line); on the other hand it
makes FIX_X_ADDR_START become XEN_VIRT_END - NR_CPUS * PAGE_SIZE -
PAGE_SIZE.

Are you really concerned about this? I can make the change if you really
want that, but it is just work with no apparent benefit.

> 
> >>> --- a/xen/include/asm-x86/fixmap.h
> >>> +++ b/xen/include/asm-x86/fixmap.h
> >>> @@ -15,6 +15,9 @@
> >>>  #include 
> >>>  
> >>>  #define FIXADDR_TOP (VMAP_VIRT_END - PAGE_SIZE)
> >>> +#define FIXADDR_X_TOP (XEN_VIRT_END - PAGE_SIZE)
> >>> +/* This constant is derived from enum fixed_addresses_x below */
> >>> +#define MAX_FIXADDR_X_SIZE (2 << PAGE_SHIFT)
> >>
> >> If this can't be properly derived, then a BUILD_BUG_ON() is needed.
> >> But didn't we discuss on irc already possible approaches of how to
> >> derive it from the enum? Did none of this work?
> > 
> > The only option I remember discussing was to define macros instead of
> > using enum. I said at the time at would make us lose the ability to
> > dynamically size this area.
> > 
> > If there are other ways that I missed, let me know.
> 
> I seem to recall recommending to export absolute symbols from
> assembly code. The question is how easily usable they would
> be from C, or how clumsy the resulting code would look.

Even if I use absolute symbol I would still need to define a macro for
it. There is no way around it, because enum can't be used in asm or
linker script.

I want to keep using enum because that would allow us to size the area
according to Kconfig.

Wei.

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

[Xen-devel] [PATCH v6 4/4] x86 / vmx: use a MEMF_no_refcount domheap page for APIC_DEFAULT_PHYS_BASE

[Paul Durrant]

vmx_alloc_vlapic_mapping() currently contains some very odd looking code
that allocates a MEMF_no_owner domheap page and then shares with the guest
as if it were a xenheap page. This then requires vmx_free_vlapic_mapping()
to call a special function in the mm code: free_shared_domheap_page().

By using a MEMF_no_refcount domheap page instead, the odd looking code in
vmx_alloc_vlapic_mapping() can simply use get_page_and_type() to set up a
writable mapping before insertion in the P2M and vmx_free_vlapic_mapping()
can simply release the page using put_page_alloc_ref() followed by
put_page_and_type(). This then allows free_shared_domheap_page() to be
purged.

Signed-off-by: Paul Durrant 
Reviewed-by: Jan Beulich 
---
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: "Roger Pau Monné" 

v4:
 - Use a MEMF_no_refcount page rather than a 'normal' page

v2:
 - Set an initial value for max_pages rather than avoiding the check in
   assign_pages()
 - Make domain_destroy() optional
---
 xen/arch/x86/hvm/vmx/vmx.c | 21 ++---
 xen/arch/x86/mm.c  | 10 --
 xen/include/asm-x86/mm.h   |  2 --
 3 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 606f3dc2eb..7423d2421b 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3028,12 +3028,22 @@ static int vmx_alloc_vlapic_mapping(struct domain *d)
 if ( !cpu_has_vmx_virtualize_apic_accesses )
 return 0;
 
-pg = alloc_domheap_page(d, MEMF_no_owner);
+pg = alloc_domheap_page(d, MEMF_no_refcount);
 if ( !pg )
 return -ENOMEM;
+
+if ( !get_page_and_type(pg, d, PGT_writable_page) )
+{
+/*
+ * The domain can't possibly know about this page yet, so failure
+ * here is a clear indication of something fishy going on.
+ */
+domain_crash(d);
+return -ENODATA;
+}
+
 mfn = page_to_mfn(pg);
 clear_domain_page(mfn);
-share_xen_page_with_guest(pg, d, SHARE_rw);
 d->arch.hvm.vmx.apic_access_mfn = mfn;
 
 return set_mmio_p2m_entry(d, paddr_to_pfn(APIC_DEFAULT_PHYS_BASE), mfn,
@@ -3047,7 +3057,12 @@ static void vmx_free_vlapic_mapping(struct domain *d)
 
 d->arch.hvm.vmx.apic_access_mfn = _mfn(0);
 if ( !mfn_eq(mfn, _mfn(0)) )
-free_shared_domheap_page(mfn_to_page(mfn));
+{
+struct page_info *pg = mfn_to_page(mfn);
+
+put_page_alloc_ref(pg);
+put_page_and_type(pg);
+}
 }
 
 static void vmx_install_vlapic_mapping(struct vcpu *v)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index f50c065af3..67351798c7 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -496,16 +496,6 @@ void share_xen_page_with_guest(struct page_info *page, 
struct domain *d,
 spin_unlock(>page_alloc_lock);
 }
 
-void free_shared_domheap_page(struct page_info *page)
-{
-put_page_alloc_ref(page);
-if ( !test_and_clear_bit(_PGC_xen_heap, >count_info) )
-ASSERT_UNREACHABLE();
-page->u.inuse.type_info = 0;
-page_set_owner(page, NULL);
-free_domheap_page(page);
-}
-
 void make_cr3(struct vcpu *v, mfn_t mfn)
 {
 struct domain *d = v->domain;
diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h
index e75feea15e..036d7ac22f 100644
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -320,8 +320,6 @@ struct page_info
 
 #define maddr_get_owner(ma)   (page_get_owner(maddr_to_page((ma
 
-extern void free_shared_domheap_page(struct page_info *page);
-
 #define frame_table ((struct page_info *)FRAMETABLE_VIRT_START)
 extern unsigned long max_page;
 extern unsigned long total_pages;
-- 
2.20.1


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

[Xen-devel] [PATCH v6 3/4] mm: make MEMF_no_refcount pages safe to assign

[Paul Durrant]

Currently it is unsafe to assign a domheap page allocated with
MEMF_no_refcount to a domain because the domain't 'tot_pages' will not
be incremented, but will be decrement when the page is freed (since
free_domheap_pages() has no way of telling that the increment was skipped).

This patch allocates a new 'count_info' bit for a PGC_no_refcount flag
which is then used to mark domheap pages allocated with MEMF_no_refcount.
This then allows free_domheap_pages() to skip decrementing tot_pages when
appropriate and hence makes the pages safe to assign.

NOTE: The patch sets MEMF_no_refcount directly in alloc_domheap_pages()
  rather than in assign_pages() because the latter is called with
  MEMF_no_refcount by memory_exchange().

Signed-off-by: Paul Durrant 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Wei Liu 
Cc: Volodymyr Babchuk 
Cc: "Roger Pau Monné" 

v6:
 - Add an extra ASSERT into assign_pages() that PGC_no_refcount is not
   set if MEMF_no_refcount is clear
 - ASSERT that count_info is 0 in alloc_domheap_pages() and set to
   PGC_no_refcount rather than ORing

v5:
 - Make sure PGC_no_refcount is set before assign_pages() is called
 - Don't bother to clear PGC_no_refcount in free_domheap_pages() and
   drop ASSERT in free_heap_pages()
 - Don't latch count_info in free_heap_pages()

v4:
 - New in v4
---
 xen/common/page_alloc.c  | 40 
 xen/include/asm-arm/mm.h |  5 -
 xen/include/asm-x86/mm.h |  7 +--
 3 files changed, 37 insertions(+), 15 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 135e15bae0..12b2c5a3d6 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2287,11 +2287,16 @@ int assign_pages(
 
 for ( i = 0; i < (1 << order); i++ )
 {
+unsigned long count_info = pg[i].count_info;
+
 ASSERT(page_get_owner([i]) == NULL);
-ASSERT(!pg[i].count_info);
+ASSERT(!(count_info & ~PGC_no_refcount));
+ASSERT((memflags & MEMF_no_refcount) ||
+   !(count_info & PGC_no_refcount));
 page_set_owner([i], d);
 smp_wmb(); /* Domain pointer must be visible before updating refcnt. */
-pg[i].count_info = PGC_allocated | 1;
+count_info &= PGC_no_refcount;
+pg[i].count_info = count_info | PGC_allocated | 1;
 page_list_add_tail([i], >page_list);
 }
 
@@ -2317,11 +2322,6 @@ struct page_info *alloc_domheap_pages(
 
 if ( memflags & MEMF_no_owner )
 memflags |= MEMF_no_refcount;
-else if ( (memflags & MEMF_no_refcount) && d )
-{
-ASSERT(!(memflags & MEMF_no_refcount));
-return NULL;
-}
 
 if ( !dma_bitsize )
 memflags &= ~MEMF_no_dma;
@@ -2334,11 +2334,23 @@ struct page_info *alloc_domheap_pages(
   memflags, d)) == NULL)) )
  return NULL;
 
-if ( d && !(memflags & MEMF_no_owner) &&
- assign_pages(d, pg, order, memflags) )
+if ( d && !(memflags & MEMF_no_owner) )
 {
-free_heap_pages(pg, order, memflags & MEMF_no_scrub);
-return NULL;
+if ( memflags & MEMF_no_refcount )
+{
+unsigned long i;
+
+for ( i = 0; i < (1ul << order); i++ )
+{
+ASSERT(!pg[i].count_info);
+pg[i].count_info = PGC_no_refcount;
+}
+}
+if ( assign_pages(d, pg, order, memflags) )
+{
+free_heap_pages(pg, order, memflags & MEMF_no_scrub);
+return NULL;
+}
 }
 
 return pg;
@@ -2371,6 +2383,8 @@ void free_domheap_pages(struct page_info *pg, unsigned 
int order)
 
 if ( likely(d) && likely(d != dom_cow) )
 {
+long pages = 0;
+
 /* NB. May recursively lock from relinquish_memory(). */
 spin_lock_recursive(>page_alloc_lock);
 
@@ -2386,9 +2400,11 @@ void free_domheap_pages(struct page_info *pg, unsigned 
int order)
 BUG();
 }
 arch_free_heap_page(d, [i]);
+if ( !(pg[i].count_info & PGC_no_refcount) )
+pages--;
 }
 
-drop_dom_ref = !domain_adjust_tot_pages(d, -(1 << order));
+drop_dom_ref = !domain_adjust_tot_pages(d, pages);
 
 spin_unlock_recursive(>page_alloc_lock);
 
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index 333efd3a60..1076cc9713 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -119,9 +119,12 @@ struct page_info
 #define PGC_state_offlined PG_mask(2, 9)
 #define PGC_state_freePG_mask(3, 9)
 #define page_state_is(pg, st) (((pg)->count_info_state) == PGC_state_##st)
+/* Page is not reference counted */
+#define _PGC_no_refcount  PG_shift(10)
+#define PGC_no_refcount   PG_mask(1, 10)
 
 /* Count of references to this frame. 

[Xen-devel] [PATCH v6 0/4] purge free_shared_domheap_page()

[Paul Durrant]

Paul Durrant (4):
  x86 / vmx: move teardown from domain_destroy()...
  mm: modify domain_adjust_tot_pages() to better handle a zero
adjustment
  mm: make MEMF_no_refcount pages safe to assign
  x86 / vmx: use a MEMF_no_refcount domheap page for
APIC_DEFAULT_PHYS_BASE

 xen/arch/x86/hvm/vmx/vmx.c | 25 +-
 xen/arch/x86/mm.c  | 10 -
 xen/common/memory.c|  3 +--
 xen/common/page_alloc.c| 43 +++---
 xen/include/asm-arm/mm.h   |  5 -
 xen/include/asm-x86/mm.h   |  9 
 6 files changed, 61 insertions(+), 34 deletions(-)

-- 
2.20.1


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

[Xen-devel] [PATCH v6 2/4] mm: modify domain_adjust_tot_pages() to better handle a zero adjustment

[Paul Durrant]

Currently the function will pointlessly acquire and release the global
'heap_lock' in this case.

NOTE: No caller yet calls domain_adjust_tot_pages() with a zero 'pages'
  argument, but a subsequent patch will make this possible.

Signed-off-by: Paul Durrant 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Wei Liu 

v6:
 - Modify memory_exchange()

v5:
 - Split out from the subsequent 'make MEMF_no_refcount pages safe to
   assign' patch as requested by Jan
---
 xen/common/memory.c | 3 +--
 xen/common/page_alloc.c | 3 +++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/common/memory.c b/xen/common/memory.c
index c7d2bac452..a4a5374d26 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -727,8 +727,7 @@ static long 
memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg)
  (j * (1UL << exch.out.extent_order)));
 
 spin_lock(>page_alloc_lock);
-drop_dom_ref = (dec_count &&
-!domain_adjust_tot_pages(d, -dec_count));
+drop_dom_ref = !domain_adjust_tot_pages(d, -dec_count);
 spin_unlock(>page_alloc_lock);
 
 if ( drop_dom_ref )
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 919a270587..135e15bae0 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -460,6 +460,9 @@ unsigned long domain_adjust_tot_pages(struct domain *d, 
long pages)
 {
 long dom_before, dom_after, dom_claimed, sys_before, sys_after;
 
+if ( !pages )
+goto out;
+
 ASSERT(spin_is_locked(>page_alloc_lock));
 d->tot_pages += pages;
 
-- 
2.20.1


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

[Xen-devel] [PATCH v6 1/4] x86 / vmx: move teardown from domain_destroy()...

[Paul Durrant]

... to domain_relinquish_resources().

The teardown code frees the APICv page. This does not need to be done late
so do it in domain_relinquish_resources() rather than domain_destroy().

Signed-off-by: Paul Durrant 
---
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: "Roger Pau Monné" 
Cc: George Dunlap 

v4:
  - New in v4 (disaggregated from v3 patch #3)
---
 xen/arch/x86/hvm/vmx/vmx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index b262d38a7c..606f3dc2eb 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -419,7 +419,7 @@ static int vmx_domain_initialise(struct domain *d)
 return 0;
 }
 
-static void vmx_domain_destroy(struct domain *d)
+static void vmx_domain_relinquish_resources(struct domain *d)
 {
 if ( !has_vlapic(d) )
 return;
@@ -2240,7 +2240,7 @@ static struct hvm_function_table __initdata 
vmx_function_table = {
 .cpu_up_prepare   = vmx_cpu_up_prepare,
 .cpu_dead = vmx_cpu_dead,
 .domain_initialise= vmx_domain_initialise,
-.domain_destroy   = vmx_domain_destroy,
+.domain_relinquish_resources = vmx_domain_relinquish_resources,
 .vcpu_initialise  = vmx_vcpu_initialise,
 .vcpu_destroy = vmx_vcpu_destroy,
 .save_cpu_ctxt= vmx_save_vmcs_ctxt,
-- 
2.20.1


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

Re: [Xen-devel] [XEN PATCH v2 04/12] xen/build: extract clean target from Rules.mk

[Jan Beulich]

On 17.01.2020 11:53, Anthony PERARD wrote:
> From: Anthony PERARD 
> 
> Most of the code executed by Rules.mk isn't necessary for the clean
> target, especially not the CFLAGS. This make running make clean much
> faster.
> 
> This extract the code into a different Makefile. It doesn't want to
> include Config.mk either so variables DEPS_RM and DEPS_INCLUDE are
> extracted from Config.mk as well. DEPS_INCLUDE is put into
> Kbuild.include so it could be use by other Makefiles.

"extracted" makes it sound as if the intention was to move things,
yet ...

> ---
>  xen/Rules.mk   | 13 -
>  xen/scripts/Kbuild.include |  7 ++-
>  xen/scripts/Makefile.clean | 33 +
>  3 files changed, 39 insertions(+), 14 deletions(-)

... ./Config.mk doesn't get touched at all. I guess there are reasons
for this, but I consider it dangerous to leave independent definitions
of the same variables in disconnected places. What if one side gets
updated without noticing the other?

> --- /dev/null
> +++ b/xen/scripts/Makefile.clean
> @@ -0,0 +1,33 @@
> +# SPDX-License-Identifier: GPL-2.0
> +# ==
> +# Cleaning up
> +# ==
> +
> +clean::
> +
> +include $(BASEDIR)/scripts/Kbuild.include
> +
> +include Makefile
> +
> +# Figure out what we need to build from the various variables

s/build/clean/ ?

> +# ==
> +__subdir-y   := $(filter %/, $(obj-y))
> +subdir-y += $(__subdir-y)
> +subdir-n := $(subdir-n) $(subdir-) \
> + $(filter %/, $(obj-n) $(obj-))
> +subdir-all := $(subdir-y) $(subdir-n)

Same remark as for the earlier patch regarding __subdir-y and the
use of tabs. Additionally please use consistent indentation of
:= / += within this block.

Jan

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

Re: [Xen-devel] [PATCH v6 5/9] x86/mem_sharing: use default_access in add_to_physmap

[Tamas K Lengyel]

On Wed, Jan 29, 2020 at 7:05 AM Tamas K Lengyel
 wrote:
>
> On Wed, Jan 29, 2020 at 6:27 AM Jan Beulich  wrote:
> >
> > On 28.01.2020 18:02, Tamas K Lengyel wrote:
> > > On Tue, Jan 28, 2020 at 9:56 AM Jan Beulich  wrote:
> > >>
> > >> On 27.01.2020 19:06, Tamas K Lengyel wrote:
> > >>> When plugging a hole in the target physmap don't use the access 
> > >>> permission
> > >>> returned by __get_gfn_type_access as it can be non-sensical, leading to
> > >>> spurious vm_events being sent out for access violations at unexpected
> > >>> locations. Make use of p2m->default_access instead.
> > >>
> > >> As before, to me "can be non-sensical" is insufficient as a reason
> > >> here. If it can also be a "good" value, it still remains unclear
> > >> why in that case p2m->default_access is nevertheless the right
> > >> value to use.
> > >
> > > I have already explained in the previous version of the patch why I
> > > said "can be". Forgot to change the commit message from "can be" to
> > > "is".
> >
> > Changing just the commit message would be easy while committing.
> > But even with the change I would ask why this is. Looking at
> > ept_get_entry() (and assuming p2m_pt_get_entry() will work
> > similarly, minus the p2m_access_t which can't come out of the
> > PTE just yet), I see
> >
> > if ( is_epte_valid(ept_entry) )
> > {
> > *t = p2m_recalc_type(recalc || ept_entry->recalc,
> >  ept_entry->sa_p2mt, p2m, gfn);
> > *a = ept_entry->access;
> >
> > near its end. Which means even a hole can have its access field
> > set. So it's still not clear to me from the description why
> > p2m->default_access is uniformly the value to use. Wouldn't you
> > rather want to override the original value only if it's
> > p2m_access_n together with p2m_invalid or p2m_mmio_dm (but not
> > paged-out pages)?
>
> At this point I would just rather state that add_to_physmap only works
> on actual holes, not with paged-out pages. In fact, I would like to
> see mem_paging being dropped from the codebase entirely since it's
> been abandoned for years and noone expressing any interest in keeping
> it. In the interim I would rather not spend unnecessary cycles on
> speculating about potential corner-cases of mem_paging when noone
> actually uses it.
>
> > Of course then the question is whether there
> > wouldn't be an ambiguity with p2m_access_n having got set
> > explicitly on the page. But maybe this is impossible for
> > p2m_invalid / p2m_mmio_dm?
>
> As far as mem_access permissions go, I don't know of any usecase that
> would set mem_access permission on a hole even if by looks of it it is
> technically possible. At this point I would rather just put this
> corner-case's description in a comment.

A potential solution for this - if one would need it in the future -
would be to add another VM event type that Xen can use to alert the
toolstack that a pre-existing mem_access permission is being
overwritten by forking. That would allow the toolstack to reset the
permission if it wants to. But honestly, I think it's a lot of code
for a situation that I don't expect anyone will ever run into. Let's
just document it and move on.

Tamas

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

[Xen-devel] [ovmf test] 146571: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
145767

version targeted for testing:
 ovmf c8b8157e126ae2fb6f65842677251d300ceff104
baseline version:
 ovmf 70911f1f4aee0366b6122f2b90d367ec0f066beb

Last test of basis   145767  2020-01-08 00:39:09 Z   21 days
Failing since145774  2020-01-08 02:50:20 Z   21 days   81 attempts
Testing same since   146482  2020-01-24 19:39:39 Z4 days   20 attempts


People who touched revisions under test:
  Aaron Li 
  Albecki, Mateusz 
  Ard Biesheuvel 
  Ashish Singhal 
  Bob Feng 
  Brian R Haug 
  Eric Dong 
  Fan, ZhijuX 
  Hao A Wu 
  Jason Voelz 
  Jian J Wang 
  Krzysztof Koch 
  Laszlo Ersek 
  Leif Lindholm 
  Li, Aaron 
  Liming Gao 
  Mateusz Albecki 
  Michael D Kinney 
  Michael Kubacki 
  Pavana.K 
  Philippe Mathieu-Daud? 
  Philippe Mathieu-Daude 
  Siyuan Fu 
  Siyuan, Fu 
  Sudipto Paul 
  Vitaly Cheptsov 
  Vitaly Cheptsov via Groups.Io 
  Wei6 Xu 
  Xu, Wei6 
  Zhiguang Liu 
  Zhiju.Fan 

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



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [XEN PATCH v2 03/12] xen/build: use $(clean) shorthand for clean targets

[Jan Beulich]

On 17.01.2020 11:53, Anthony PERARD wrote:
> From: Anthony PERARD 
> 
> Collect all the clean targets as we are going to modify it shortly.
> Also, this is inspired by Linux's Kbuild.
> 
> "Kbuild.include" isn't included by "Makefile", but the "_clean" target
> is only used by Rules.mk which include Kbuild.include.
> 
> Signed-off-by: Anthony PERARD 

Reviewed-by: Jan Beulich 

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

Re: [Xen-devel] [XEN PATCH v2 02/12] xen/build: Use obj-y += subdir/ instead of subdir-y

[Jan Beulich]

On 17.01.2020 11:53, Anthony PERARD wrote:
> This is part of upgrading our build system and import more of Linux's
> one.
> 
> In Linux, subdir-y in Makefiles is only used to descend into
> subdirectory when there are no object to build, Xen doesn't have that
> and all subdir have object to be included in the final binary.
> 
> To allow the new syntax, the "obj-y" and "subdir-*" calculation in
> Rules.mk is changed and partially imported from Linux's Kbuild.
> 
> The command used to modify the Makefile was:
> sed -i -r 's#^subdir-(.*)#obj-\1/#;' **/Makefile
> 
> Signed-off-by: Anthony PERARD 

Reviewed-by: Jan Beulich 
with two remarks:

> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -105,17 +105,16 @@ define gendep
>  endef
>  $(foreach o,$(filter-out %/,$(obj-y) $(obj-bin-y) $(extra-y)),$(eval $(call 
> gendep,$(o
>  
> -# Ensure each subdirectory has exactly one trailing slash.
> -subdir-n := $(patsubst %,%/,$(patsubst %/,%,$(subdir-n) $(subdir-)))
> -subdir-y := $(patsubst %,%/,$(patsubst %/,%,$(subdir-y)))
> -
> -# Add explicitly declared subdirectories to the object lists.
> -obj-y += $(patsubst %/,%/built_in.o,$(subdir-y))
> -
> -# Add implicitly declared subdirectories (in the object lists) to the
> -# subdirectory list, and rewrite the object-list entry.
> -subdir-y += $(filter %/,$(obj-y))
> -obj-y:= $(patsubst %/,%/built-in.o,$(obj-y))
> +# Handle objects in subdirs
> +# ---
> +# o if we encounter foo/ in $(obj-y), replace it by foo/built_in.o
> +#   and add the directory to the list of dirs to descend into: $(subdir-y)
> +__subdir-y   := $(filter %/, $(obj-y))
> +subdir-y += $(__subdir-y)

I realize I'll be called guilty of bike-shedding again, and I also
realize this is the way Linux does it, but what use is the
intermediate __subdir-y? Linux has no 2nd use, and hence I also
don't see why we would gain one. I further think according to our
style there should be no use of tabs here.

> +obj-y:= $(patsubst %/, %/built_in.o, $(obj-y))
> +
> +subdir-n := $(subdir-n) $(subdir-) \
> + $(filter %/, $(obj-n) $(obj-))

This will easily fit on one line (and isn't anything cloned from
Linux).

Jan

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

Re: [Xen-devel] [PATCH v3 8/8] RFC: Sketch constructors, DomainCreateNew

[Nick Rosbrook]

> I *think* to guarantee that libxl__init() has been called when
> unmarshaling, we would need to generate UnmarshalJSON functions to
> implement json.Unmarshaler. E.g.,:
>
> func (dd *DeviceDisk) UnmarshalJSON(data []byte) error {
> if dd == nil { // Or maybe this is the 'initialized' check you 
> mentioned

Err, I mean `if dd == (DeviceDisk{})`. We want to check if the value
that dd points to is the DeviceDisk zero value.

-NR

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

Re: [Xen-devel] [ANNOUNCE] Xen 4.14 Development Update

[Tamas K Lengyel]

> === x86 ===

VM forking series is at v6

Tamas

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

Re: [Xen-devel] [PATCH v6 5/9] x86/mem_sharing: use default_access in add_to_physmap

[Tamas K Lengyel]

On Wed, Jan 29, 2020 at 6:27 AM Jan Beulich  wrote:
>
> On 28.01.2020 18:02, Tamas K Lengyel wrote:
> > On Tue, Jan 28, 2020 at 9:56 AM Jan Beulich  wrote:
> >>
> >> On 27.01.2020 19:06, Tamas K Lengyel wrote:
> >>> When plugging a hole in the target physmap don't use the access permission
> >>> returned by __get_gfn_type_access as it can be non-sensical, leading to
> >>> spurious vm_events being sent out for access violations at unexpected
> >>> locations. Make use of p2m->default_access instead.
> >>
> >> As before, to me "can be non-sensical" is insufficient as a reason
> >> here. If it can also be a "good" value, it still remains unclear
> >> why in that case p2m->default_access is nevertheless the right
> >> value to use.
> >
> > I have already explained in the previous version of the patch why I
> > said "can be". Forgot to change the commit message from "can be" to
> > "is".
>
> Changing just the commit message would be easy while committing.
> But even with the change I would ask why this is. Looking at
> ept_get_entry() (and assuming p2m_pt_get_entry() will work
> similarly, minus the p2m_access_t which can't come out of the
> PTE just yet), I see
>
> if ( is_epte_valid(ept_entry) )
> {
> *t = p2m_recalc_type(recalc || ept_entry->recalc,
>  ept_entry->sa_p2mt, p2m, gfn);
> *a = ept_entry->access;
>
> near its end. Which means even a hole can have its access field
> set. So it's still not clear to me from the description why
> p2m->default_access is uniformly the value to use. Wouldn't you
> rather want to override the original value only if it's
> p2m_access_n together with p2m_invalid or p2m_mmio_dm (but not
> paged-out pages)?

At this point I would just rather state that add_to_physmap only works
on actual holes, not with paged-out pages. In fact, I would like to
see mem_paging being dropped from the codebase entirely since it's
been abandoned for years and noone expressing any interest in keeping
it. In the interim I would rather not spend unnecessary cycles on
speculating about potential corner-cases of mem_paging when noone
actually uses it.

> Of course then the question is whether there
> wouldn't be an ambiguity with p2m_access_n having got set
> explicitly on the page. But maybe this is impossible for
> p2m_invalid / p2m_mmio_dm?

As far as mem_access permissions go, I don't know of any usecase that
would set mem_access permission on a hole even if by looks of it it is
technically possible. At this point I would rather just put this
corner-case's description in a comment.

Tamas

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

Re: [Xen-devel] [PATCH v6 7/9] xen/mem_access: Use __get_gfn_type_access in set_mem_access

[Jan Beulich]

On 29.01.2020 14:53, Tamas K Lengyel wrote:
> On Wed, Jan 29, 2020 at 6:10 AM Jan Beulich  wrote:
>>
>> On 27.01.2020 19:06, Tamas K Lengyel wrote:
>>> Use __get_gfn_type_access instead of p2m->get_entry to trigger page-forking
>>> when the mem_access permission is being set on a page that has not yet been
>>> copied over from the parent.
>>
>> You talking of page-forking here, don't you mean ...
>>
>>> --- a/xen/arch/x86/mm/mem_access.c
>>> +++ b/xen/arch/x86/mm/mem_access.c
>>> @@ -303,11 +303,10 @@ static int set_mem_access(struct domain *d, struct 
>>> p2m_domain *p2m,
>>>  ASSERT(!ap2m);
>>>  #endif
>>>  {
>>> -mfn_t mfn;
>>>  p2m_access_t _a;
>>>  p2m_type_t t;
>>> -
>>> -mfn = p2m->get_entry(p2m, gfn, , &_a, 0, NULL, NULL);
>>> +mfn_t mfn = __get_gfn_type_access(p2m, gfn_x(gfn), , &_a,
>>> +  P2M_ALLOC, NULL, false);
>>
>> ... P2M_UNSHARE here?
> 
> No, P2M_UNSHARE is only required if you are doing a memory write.
> Setting memory access permissions is not a memory write, so it's
> sufficient to just allocate the p2m entry. P2M_ALLOCATE also
> encompasses forking the entry if there is a parent VM.

Ah, I see. And hence
Reviewed-by: Jan Beulich 

>> Also shouldn't you have Cc-ed Petre and Alexandru on this patch
>> (for their R: entries) and at least George (perhaps also Andrew
>> and me) to get an ack, seeing that you're the only maintainer
>> of the file?
> 
> I've ran ./add_maintainers.pl on the patches, not sure why noone else got 
> CC-d.

It not picking up R: entries would seem like a bug to me. It not
knowing of nesting of maintainership is entirely expected (or
else it would also need to know that it's - in this case - you
who is invoking it).

Jan

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

Re: [Xen-devel] [PATCH v6 7/9] xen/mem_access: Use __get_gfn_type_access in set_mem_access

[Tamas K Lengyel]

On Wed, Jan 29, 2020 at 6:10 AM Jan Beulich  wrote:
>
> On 27.01.2020 19:06, Tamas K Lengyel wrote:
> > Use __get_gfn_type_access instead of p2m->get_entry to trigger page-forking
> > when the mem_access permission is being set on a page that has not yet been
> > copied over from the parent.
>
> You talking of page-forking here, don't you mean ...
>
> > --- a/xen/arch/x86/mm/mem_access.c
> > +++ b/xen/arch/x86/mm/mem_access.c
> > @@ -303,11 +303,10 @@ static int set_mem_access(struct domain *d, struct 
> > p2m_domain *p2m,
> >  ASSERT(!ap2m);
> >  #endif
> >  {
> > -mfn_t mfn;
> >  p2m_access_t _a;
> >  p2m_type_t t;
> > -
> > -mfn = p2m->get_entry(p2m, gfn, , &_a, 0, NULL, NULL);
> > +mfn_t mfn = __get_gfn_type_access(p2m, gfn_x(gfn), , &_a,
> > +  P2M_ALLOC, NULL, false);
>
> ... P2M_UNSHARE here?

No, P2M_UNSHARE is only required if you are doing a memory write.
Setting memory access permissions is not a memory write, so it's
sufficient to just allocate the p2m entry. P2M_ALLOCATE also
encompasses forking the entry if there is a parent VM.

>
> Also shouldn't you have Cc-ed Petre and Alexandru on this patch
> (for their R: entries) and at least George (perhaps also Andrew
> and me) to get an ack, seeing that you're the only maintainer
> of the file?

I've ran ./add_maintainers.pl on the patches, not sure why noone else got CC-d.

Tamas

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

Re: [Xen-devel] Host freezing after "fixing" recursive fault starting in multicalls.c

[Peter.Kurfer]

> Right, but the bad news is that there are no helpful hypervisor
> messages at all. Sadly this is partly my fault, because I should
> have asked you to do this log collection with a debug hypervisor.
> Most of the possibly interesting messages would appear only there.

> In any event, problems start quite a bit earlier, and typically
> it's the first instance of a problem that is the most helpful to
> analyze, as later ones may be cascade issues. The first sign of
> problems is an overlapping

To be honest, I was already wondering why there were only so few logs but while 
I already found the CMDLINE_XEN options for debug logs I didn't find any 
documentation how to build a debug hypervisor so far and it took me some time 
to work around the fact that I don't have physical access to the server to 
attach an actual serial cable and so on.

I will try to compile Xen with debug enabled and collect more logs afterwards.
Anything to be aware of?


Von: Jan Beulich 
Gesendet: Mittwoch, 29. Januar 2020 09:59
An: Kurfer, Peter
Cc: xen-devel@lists.xenproject.org
Betreff: Re: Host freezing after "fixing" recursive fault starting in 
multicalls.c
    
On 29.01.2020 09:29, peter.kur...@gdata.de wrote:
> As requested I configured one host with:
> 
>> loglvl=all guest_loglvl=all
> 
> and collected one day of logs via serial interface:
> 
>  
> https://drive.google.com/drive/folders/1sQvyNH0Sz28tUeVRZl9mowhB0Htd8ZpO?usp=sharing
> 
> searching for "error" or "multicalls.c" leads to some stacktraces that might 
> be interesting.

Right, but the bad news is that there are no helpful hypervisor
messages at all. Sadly this is partly my fault, because I should
have asked you to do this log collection with a debug hypervisor.
Most of the possibly interesting messages would appear only there.

In any event, problems start quite a bit earlier, and typically
it's the first instance of a problem that is the most helpful to
analyze, as later ones may be cascade issues. The first sign of
problems is an overlapping

[14991.827762] BUG: unable to handle page fault for address: 888ae2eb6bd8

and

[14991.828172] WARNING: CPU: 5 PID: 2585 at arch/x86/xen/multicalls.c:102 
xen_mc_flush+0x194/0x1c0

on CPUs 8 and 5.

> As far as I know the ACPI errors in the context of IPMI can be ignored.

Looks like so, yes, at least for the purposes here. What I wouldn't
put off as a possible reason for problems is the significant amount
of temperature related messages. What I also find at least curious
(but possibly just because I know too little of the respective
aspects of modern kernels) are the recurring __text_poke() instances
on the stack traces. Assuming these are to be expected in the first
place, there might be a race here which is either Xen-specific or
simply has a much better chance of hitting (larger window?) when
running on Xen. But I'm afraid this will need looking into (or at
least commenting on) by a kernel person.

Jan

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

[Xen-devel] [linux-5.4 test] 146567: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
146121
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
146121

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-rtds   16 guest-localmigrate fail in 146559 pass in 146552
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail in 146559 
pass in 146567
 test-amd64-amd64-xl-rtds 15 guest-saverestore  fail pass in 146559
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat  fail pass in 146559

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

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

Re: [Xen-devel] [PATCH RFC] x86/amd: Avoid cpu_has_hypervisor evaluating true on native hardware

[Jan Beulich]

On 29.01.2020 14:08, Andrew Cooper wrote:
> On 29/01/2020 08:17, Jan Beulich wrote:
>> On 28.01.2020 18:14, Andrew Cooper wrote:
>>> On 28/01/2020 13:59, Jan Beulich wrote:
 On 27.01.2020 21:21, Andrew Cooper wrote:
> Without this fix, there is apparently a problem with Roger's "[PATCH v3 
> 7/7]
> x86/tlb: use Xen L0 assisted TLB flush when available" on native AMD 
> hardware.
> I haven't investgiated the issue with that patch specifically, because
> cpu_has_hypervisor being wrong is obviously a bug.
>
> This is one of two possible approaches, and both have their downsides.  
> This
> one takes an extra hit on context switches between PV vcpus and idle/hvm, 
> as
> they will usually differ in HYPERVISOR bit.
 Why would they differ in the HYPERVISOR bit? Maybe for idle (albeit
 off the top of my head I can't recall us special casing idle wrt
 CPUID handling), but why for PV vs HVM? The idle case, if there is
 an issue with this, could be taken care of by actually setting the
 bit there, as no-one should care about what it's set to?
>>> d->arch.pv.cpuidmasks is only allocated for PV domains (and starts by
>>> dup()ing the default).
>> Ah, that's the piece I was missing. My next question then is: Why
>> do we do *_init_levelling() from early_init_*() in the first place?
>> It looks conceptually wrong to me to set up leveling before having
>> obtained CPUID data. Wouldn't there better be a separate hook in
>> struct cpu_dev, to be invoked e.g. from identify_cpu() after
>> generic_identify()?
> 
> cpuid_mask_cpu= literally means "pretend you're this older CPU instead",
> and was implemented in a way which affected Xen.  This is why levelling
> is configured that early.

It's indeed written like this in the cmdline doc, but I vaguely
recall questioning this behavior at least once before.

> Now that this isn't the only way to make heterogeneous migration safe,
> perhaps we don't care so much, but it would still be a behavioural
> change to the cpuid_mask_* parameters.

And indeed we have cpuid= now to control the features Xen is
to use. I don't fancy looking at bug reports where I first need
to sort out the interaction between these two cmdline options.

>>> When context switching levelling MSRs, any non-PV guest uses
>>> cpumask_default.  This captures idle and HVM vcpus.
>>>
>>> This is necessary because, at least at the time it was introduced,
>>> {pv,hvm}_cpuid() issued native CPUID instructions to then feed data back
>>> into guest context.  Its probably less relevant now that guest_cpuid()
>>> doesn't issue native instructions in the general case.
>>>
>>> Either way, HVM gained the default like idle, to cause the lazy
>>> switching logic to switch less often.
>>>
>>> The problem we have after this patch is that default differs from PV in
>>> the HYPERVISOR bit, which basically guarantees that we rewrite the leaf
>>> 1 levelling on each context switch.
>>>
>>> However, having looked at the other features bits which differ for PV,
>>> VME and PSE36 being hidden means we're always switching leaf 1 anyway,
>>> so this change for HYPERVISOR doesn't make the situation any worse.
>>>
> The other approach is to order things more carefully so levelling is
> configured after scanning for cpuid bits, but that has the downside that 
> it is
> very easy to regress.
>
> Thoughts on which is the least-bad approach to take?  Having written this
> patch, I'm now erring on the side of doing it the other way.
 Besides the need for me to understand the aspect above, I'm afraid
 to judge I'd need to have at least a sketch of what the alternative
 would look like, in particular to figure how fragile it really is.
>>> It would be a small bit of careful reordering in cpu/amd.c
>>>
>>> The tipping factor is that, even if we arrange for idle context not to
>>> have HYPERVISOR set (and therefore cpu_has_hypervisor ending up clear
>>> when scanned), a regular CPUID instruction in PV context would see
>>> HYPERVISOR as a property of virtualising things sensibly for guests.
>>>
>>> As we need to cope with HYPERVISOR being visible in some contexts, its
>>> better to consider it uniformly visible and break any kind of notional
>>> link between cpu_has_hypervisor matching what CPUID would see as the bit.
>> After having set up leveling I think we shouldn't use CPUID anymore
>> for leaves which may be leveled. As a result cpu_has_* / cpu_has()
>> would then be the only information source in this regard.
>>
>> Such a general re-arrangement would then also appear to address your
>> "easy to regress" concern.
> 
> I've just had another thought, and it rules out other approaches.
> 
> We use ctxt_switch_levelling(NULL) on the crash path to reset things for
> next kernel, and that needs to hide the HYPERVISOR bit on AMD.
> 
> Therefore, the approach in this patch is the only sensible action (and
> I'm now not concerned about the 

Re: [Xen-devel] [PATCH v6 5/9] x86/mem_sharing: use default_access in add_to_physmap

[Jan Beulich]

On 28.01.2020 18:02, Tamas K Lengyel wrote:
> On Tue, Jan 28, 2020 at 9:56 AM Jan Beulich  wrote:
>>
>> On 27.01.2020 19:06, Tamas K Lengyel wrote:
>>> When plugging a hole in the target physmap don't use the access permission
>>> returned by __get_gfn_type_access as it can be non-sensical, leading to
>>> spurious vm_events being sent out for access violations at unexpected
>>> locations. Make use of p2m->default_access instead.
>>
>> As before, to me "can be non-sensical" is insufficient as a reason
>> here. If it can also be a "good" value, it still remains unclear
>> why in that case p2m->default_access is nevertheless the right
>> value to use.
> 
> I have already explained in the previous version of the patch why I
> said "can be". Forgot to change the commit message from "can be" to
> "is".

Changing just the commit message would be easy while committing.
But even with the change I would ask why this is. Looking at
ept_get_entry() (and assuming p2m_pt_get_entry() will work
similarly, minus the p2m_access_t which can't come out of the
PTE just yet), I see

if ( is_epte_valid(ept_entry) )
{
*t = p2m_recalc_type(recalc || ept_entry->recalc,
 ept_entry->sa_p2mt, p2m, gfn);
*a = ept_entry->access;

near its end. Which means even a hole can have its access field
set. So it's still not clear to me from the description why
p2m->default_access is uniformly the value to use. Wouldn't you
rather want to override the original value only if it's
p2m_access_n together with p2m_invalid or p2m_mmio_dm (but not
paged-out pages)? Of course then the question is whether there
wouldn't be an ambiguity with p2m_access_n having got set
explicitly on the page. But maybe this is impossible for
p2m_invalid / p2m_mmio_dm?

Jan

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 

Re: [Xen-devel] [PATCH v6 7/9] xen/mem_access: Use __get_gfn_type_access in set_mem_access

[Jan Beulich]

On 27.01.2020 19:06, Tamas K Lengyel wrote:
> Use __get_gfn_type_access instead of p2m->get_entry to trigger page-forking
> when the mem_access permission is being set on a page that has not yet been
> copied over from the parent.

You talking of page-forking here, don't you mean ...

> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -303,11 +303,10 @@ static int set_mem_access(struct domain *d, struct 
> p2m_domain *p2m,
>  ASSERT(!ap2m);
>  #endif
>  {
> -mfn_t mfn;
>  p2m_access_t _a;
>  p2m_type_t t;
> -
> -mfn = p2m->get_entry(p2m, gfn, , &_a, 0, NULL, NULL);
> +mfn_t mfn = __get_gfn_type_access(p2m, gfn_x(gfn), , &_a,
> +  P2M_ALLOC, NULL, false);

... P2M_UNSHARE here?

Also shouldn't you have Cc-ed Petre and Alexandru on this patch
(for their R: entries) and at least George (perhaps also Andrew
and me) to get an ack, seeing that you're the only maintainer
of the file?

Jan

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

Re: [Xen-devel] [PATCH RFC] x86/amd: Avoid cpu_has_hypervisor evaluating true on native hardware

[Andrew Cooper]

On 29/01/2020 08:17, Jan Beulich wrote:
> On 28.01.2020 18:14, Andrew Cooper wrote:
>> On 28/01/2020 13:59, Jan Beulich wrote:
>>> On 27.01.2020 21:21, Andrew Cooper wrote:
 Without this fix, there is apparently a problem with Roger's "[PATCH v3 
 7/7]
 x86/tlb: use Xen L0 assisted TLB flush when available" on native AMD 
 hardware.
 I haven't investgiated the issue with that patch specifically, because
 cpu_has_hypervisor being wrong is obviously a bug.

 This is one of two possible approaches, and both have their downsides.  
 This
 one takes an extra hit on context switches between PV vcpus and idle/hvm, 
 as
 they will usually differ in HYPERVISOR bit.
>>> Why would they differ in the HYPERVISOR bit? Maybe for idle (albeit
>>> off the top of my head I can't recall us special casing idle wrt
>>> CPUID handling), but why for PV vs HVM? The idle case, if there is
>>> an issue with this, could be taken care of by actually setting the
>>> bit there, as no-one should care about what it's set to?
>> d->arch.pv.cpuidmasks is only allocated for PV domains (and starts by
>> dup()ing the default).
> Ah, that's the piece I was missing. My next question then is: Why
> do we do *_init_levelling() from early_init_*() in the first place?
> It looks conceptually wrong to me to set up leveling before having
> obtained CPUID data. Wouldn't there better be a separate hook in
> struct cpu_dev, to be invoked e.g. from identify_cpu() after
> generic_identify()?

cpuid_mask_cpu= literally means "pretend you're this older CPU instead",
and was implemented in a way which affected Xen.  This is why levelling
is configured that early.

Now that this isn't the only way to make heterogeneous migration safe,
perhaps we don't care so much, but it would still be a behavioural
change to the cpuid_mask_* parameters.

>> When context switching levelling MSRs, any non-PV guest uses
>> cpumask_default.  This captures idle and HVM vcpus.
>>
>> This is necessary because, at least at the time it was introduced,
>> {pv,hvm}_cpuid() issued native CPUID instructions to then feed data back
>> into guest context.  Its probably less relevant now that guest_cpuid()
>> doesn't issue native instructions in the general case.
>>
>> Either way, HVM gained the default like idle, to cause the lazy
>> switching logic to switch less often.
>>
>> The problem we have after this patch is that default differs from PV in
>> the HYPERVISOR bit, which basically guarantees that we rewrite the leaf
>> 1 levelling on each context switch.
>>
>> However, having looked at the other features bits which differ for PV,
>> VME and PSE36 being hidden means we're always switching leaf 1 anyway,
>> so this change for HYPERVISOR doesn't make the situation any worse.
>>
 The other approach is to order things more carefully so levelling is
 configured after scanning for cpuid bits, but that has the downside that 
 it is
 very easy to regress.

 Thoughts on which is the least-bad approach to take?  Having written this
 patch, I'm now erring on the side of doing it the other way.
>>> Besides the need for me to understand the aspect above, I'm afraid
>>> to judge I'd need to have at least a sketch of what the alternative
>>> would look like, in particular to figure how fragile it really is.
>> It would be a small bit of careful reordering in cpu/amd.c
>>
>> The tipping factor is that, even if we arrange for idle context not to
>> have HYPERVISOR set (and therefore cpu_has_hypervisor ending up clear
>> when scanned), a regular CPUID instruction in PV context would see
>> HYPERVISOR as a property of virtualising things sensibly for guests.
>>
>> As we need to cope with HYPERVISOR being visible in some contexts, its
>> better to consider it uniformly visible and break any kind of notional
>> link between cpu_has_hypervisor matching what CPUID would see as the bit.
> After having set up leveling I think we shouldn't use CPUID anymore
> for leaves which may be leveled. As a result cpu_has_* / cpu_has()
> would then be the only information source in this regard.
>
> Such a general re-arrangement would then also appear to address your
> "easy to regress" concern.

I've just had another thought, and it rules out other approaches.

We use ctxt_switch_levelling(NULL) on the crash path to reset things for
next kernel, and that needs to hide the HYPERVISOR bit on AMD.

Therefore, the approach in this patch is the only sensible action (and
I'm now not concerned about the performance hit, as it won't actually
increase the number of MSR writes we make).

I think I need to rewrite the commit message, but not the code.

~Andrew

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

Re: [Xen-devel] [ANNOUNCE] Xen 4.14 Development Update

[Durrant, Paul]

> -Original Message-
> From: David Woodhouse 
> Sent: 29 January 2020 13:05
> To: xen-devel@lists.xenproject.org; Durrant, Paul 
> Cc: Woodhouse, David ; luwei.k...@intel.com;
> marma...@invisiblethingslab.com; andrew.coop...@citrix.com;
> roger@citrix.com
> Subject: Re: [ANNOUNCE] Xen 4.14 Development Update
> 
> On Wed, 2020-01-29 at 12:36 +, Paul Durrant wrote:
> > This email only tracks big items for xen.git tree. Please reply for
> items
> > you would like to see in 4.14 so that people have an idea what
> > is going on and prioritise accordingly.
> >
> > You're welcome to provide description and use cases of the feature
> you're
> > working on.
> >
> > = Timeline =
> >
> > We now adopt a fixed cut-off date scheme. We will release about every 8
> >  months.
> > The critical dates for Xen 4.14 are as follows:
> >
> > ---> We are here
> > * Last posting date: May 1st, 2020
> > * Hard code freeze: May 22nd, 2020
> > * Release: June 26th, 2020
> >
> > Note that we don't have a freeze exception scheme anymore. All patches
> > that wish to go into 4.14 must be posted initially no later than the
> > last posting date and finally no later than the hard code freeze.
> > All patches posted after that date will be automatically queued into
> next
> > release.
> >
> > RCs will be arranged immediately after freeze.
> >
> > There is also a jira instance to track all the tasks (not only big)
> > for the project. See:
> https://xenproject.atlassian.net/projects/XEN/issues.
> >
> > Some of the tasks tracked by this e-mail also have a corresponding jira
> task
> > referred by XEN-N.
> >
> > There is a version number for patch series associated to each feature.
> > Can each owner send an update giving the latest version number if the
> > series has been re-posted? Also, can the owners of any completed items
> > please respond so that the item can be moved into the 'Completed'
> section.
> >
> > = Projects =
> >
> > == Hypervisor ==
> >
> > *  Live-Updating Xen
> >   -  David Woodhouse
> 
> Latest RFC patchset posted is [RFC v2] at
> https://lists.xenproject.org/archives/html/xen-devel/2020-01/msg01764.html
> 
> The tree at
> https://xenbits.xen.org/gitweb/?p=people/dwmw2/xen.git;a=shortlog;h=refs/h
> eads/lu-master
> as moved on a little since then, and I'll post [RFC v3] shortly.
> 
> So far this is mostly just the basic handover of a stream of migration
> data from one Xen to the next, and allowing the new Xen to vmap and
> process it early enough, and reserve the pages which already contain
> domain data during its "boot".
> 
> In our development tree, we have a PV Dom0 surviving the transition.
> We're working on turning those hacks into something we can show in
> public.
> 
> I have updated the wiki page at https://wiki.xenproject.org/wiki/Live-
> Updating_Xen
> which includes a reference to the handover protocol documentation.
> 
> This also depends on the hypervisor side of non-cooperative live
> migration, mentioned below. But as well as that, parts of the memory
> management are going to intersect with the secret hiding work that you
> *didn't* call out in this email AFAICT.

Yes, I omitted Secret Hiding. Agreed it ought to be tracked.

  Paul

> 
> 
> > *  Non-Cooperative Live Migration
> >   -  Paul Durrant
> >
> > === x86 ===
> >
> > *  Intel Processor Trace virtualization enabling (v1)
> >   -  Luwei Kang
> >
> > *  Linux stub domains (RFC v2)
> >   -  Marek Marczykowski-Górecki
> >
> > *  Fixes to #DB injection
> >   -  Andrew Cooper
> >
> > *  CPUID/MSR Xen/toolstack improvements
> >   -  Andrew Cooper
> >
> > *  Improvements to domain_crash()
> >   -  Andrew Cooper
> >
> > *  EIBRS
> >   -  Andrew Cooper
> >
> > *  Xen ioreq server (v3)
> >   -  Roger Pau Monne
> >
> > === ARM ===
> >
> > == Completed ==
> >
> >
> > Paul Durrant

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

Re: [Xen-devel] [ANNOUNCE] Xen 4.14 Development Update

[David Woodhouse]

On Wed, 2020-01-29 at 12:36 +, Paul Durrant wrote:
> This email only tracks big items for xen.git tree. Please reply for items
> you would like to see in 4.14 so that people have an idea what
> is going on and prioritise accordingly.
> 
> You're welcome to provide description and use cases of the feature you're
> working on.
> 
> = Timeline =
> 
> We now adopt a fixed cut-off date scheme. We will release about every 8
>  months.
> The critical dates for Xen 4.14 are as follows:
> 
> ---> We are here
> * Last posting date: May 1st, 2020
> * Hard code freeze: May 22nd, 2020
> * Release: June 26th, 2020
> 
> Note that we don't have a freeze exception scheme anymore. All patches
> that wish to go into 4.14 must be posted initially no later than the
> last posting date and finally no later than the hard code freeze.
> All patches posted after that date will be automatically queued into next
> release.
> 
> RCs will be arranged immediately after freeze.
> 
> There is also a jira instance to track all the tasks (not only big)
> for the project. See: https://xenproject.atlassian.net/projects/XEN/issues.
> 
> Some of the tasks tracked by this e-mail also have a corresponding jira task
> referred by XEN-N.
> 
> There is a version number for patch series associated to each feature.
> Can each owner send an update giving the latest version number if the
> series has been re-posted? Also, can the owners of any completed items
> please respond so that the item can be moved into the 'Completed' section.
> 
> = Projects =
> 
> == Hypervisor == 
> 
> *  Live-Updating Xen
>   -  David Woodhouse

Latest RFC patchset posted is [RFC v2] at
https://lists.xenproject.org/archives/html/xen-devel/2020-01/msg01764.html

The tree at 
https://xenbits.xen.org/gitweb/?p=people/dwmw2/xen.git;a=shortlog;h=refs/heads/lu-master
as moved on a little since then, and I'll post [RFC v3] shortly.

So far this is mostly just the basic handover of a stream of migration
data from one Xen to the next, and allowing the new Xen to vmap and
process it early enough, and reserve the pages which already contain
domain data during its "boot".

In our development tree, we have a PV Dom0 surviving the transition.
We're working on turning those hacks into something we can show in
public.

I have updated the wiki page at 
https://wiki.xenproject.org/wiki/Live-Updating_Xen
which includes a reference to the handover protocol documentation.

This also depends on the hypervisor side of non-cooperative live
migration, mentioned below. But as well as that, parts of the memory
management are going to intersect with the secret hiding work that you
*didn't* call out in this email AFAICT.


> *  Non-Cooperative Live Migration
>   -  Paul Durrant
> 
> === x86 === 
> 
> *  Intel Processor Trace virtualization enabling (v1)
>   -  Luwei Kang
> 
> *  Linux stub domains (RFC v2)
>   -  Marek Marczykowski-Górecki
> 
> *  Fixes to #DB injection
>   -  Andrew Cooper
> 
> *  CPUID/MSR Xen/toolstack improvements
>   -  Andrew Cooper
> 
> *  Improvements to domain_crash()
>   -  Andrew Cooper
> 
> *  EIBRS
>   -  Andrew Cooper
> 
> *  Xen ioreq server (v3)
>   -  Roger Pau Monne
> 
> === ARM === 
> 
> == Completed == 
> 
> 
> Paul Durrant



smime.p7s
Description: S/MIME cryptographic signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [ANNOUNCE] Xen 4.14 Development Update

[Durrant, Paul]

> -Original Message-
> From: Jan Beulich 
> Sent: 29 January 2020 12:48
> To: Durrant, Paul 
> Cc: xen-devel@lists.xenproject.org
> Subject: Re: [ANNOUNCE] Xen 4.14 Development Update
> 
> On 29.01.2020 13:36, Paul Durrant wrote:
> > === x86 ===
> >
> > *  Intel Processor Trace virtualization enabling (v1)
> >   -  Luwei Kang
> >
> > *  Linux stub domains (RFC v2)
> >   -  Marek Marczykowski-Górecki
> >
> > *  Fixes to #DB injection
> >   -  Andrew Cooper
> >
> > *  CPUID/MSR Xen/toolstack improvements
> >   -  Andrew Cooper
> >
> > *  Improvements to domain_crash()
> >   -  Andrew Cooper
> >
> > *  EIBRS
> >   -  Andrew Cooper
> >
> > *  Xen ioreq server (v3)
> >   -  Roger Pau Monne
> 
> Do you want to add "x86/HVM: implement memory read caching"
> (https://lists.xenproject.org/archives/html/xen-devel/2018-
> 09/msg00976.html)
> here? I think I now have something coming a little closer to
> what Andrew wants. It has its own downsides, so there being a
> v4 (after well over a year) doesn't mean this will get it any
> closer to going in.

It sounds like something that is reasonable to track. I can add it in (starting 
at v3, if v4 has not been posted by that point)

> 
> Do you also want to add the ongoing x86 insn emulator work
> here? Some parts were posted, some parts are still in needed
> of finding time to carry out, and some parts are still pretty
> vague.

Ok. It's on-going work so it may as well be tracked.

  Paul

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

Re: [Xen-devel] [PATCH v5 15/15] drm/xen: Explicitly disable automatic sending of vblank event

[Oleksandr Andrushchenko]

On 1/29/20 2:05 PM, Thomas Zimmermann wrote:
> The atomic helpers automatically send out fake VBLANK events if no
> vblanking has been initialized. This would apply to xen, but xen has
> its own vblank logic. To avoid interfering with the atomic helpers,
> disable automatic vblank events explicitly.
>
> v5:
>   * update comment
> v4:
>   * separate commit from core vblank changes
>
> Signed-off-by: Thomas Zimmermann 
> Acked-by: Gerd Hoffmann 
> Reviewed-by: Daniel Vetter 
Thank you for your work,
Reviewed-by: Oleksandr Andrushchenko 
> ---
>   drivers/gpu/drm/xen/xen_drm_front_kms.c | 19 +++
>   1 file changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c 
> b/drivers/gpu/drm/xen/xen_drm_front_kms.c
> index 4f34c5208180..78096bbcd226 100644
> --- a/drivers/gpu/drm/xen/xen_drm_front_kms.c
> +++ b/drivers/gpu/drm/xen/xen_drm_front_kms.c
> @@ -220,6 +220,24 @@ static bool display_send_page_flip(struct 
> drm_simple_display_pipe *pipe,
>   return false;
>   }
>   
> +static int display_check(struct drm_simple_display_pipe *pipe,
> +  struct drm_plane_state *plane_state,
> +  struct drm_crtc_state *crtc_state)
> +{
> + /*
> +  * Xen doesn't initialize vblanking via drm_vblank_init(), so
> +  * DRM helpers assume that it doesn't handle vblanking and start
> +  * sending out fake VBLANK events automatically.
> +  *
> +  * As xen contains it's own logic for sending out VBLANK events
> +  * in send_pending_event(), disable no_vblank (i.e., the xen
> +  * driver has vblanking support).
> +  */
> + crtc_state->no_vblank = false;
> +
> + return 0;
> +}
> +
>   static void display_update(struct drm_simple_display_pipe *pipe,
>  struct drm_plane_state *old_plane_state)
>   {
> @@ -284,6 +302,7 @@ static const struct drm_simple_display_pipe_funcs 
> display_funcs = {
>   .enable = display_enable,
>   .disable = display_disable,
>   .prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
> + .check = display_check,
>   .update = display_update,
>   };
>   
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel