[Xen-devel] [linux-4.9 test] 133242: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken
 build-arm64  broken
 build-arm64-pvopsbroken
 test-armhf-armhf-xl-multivcpu  6 xen-install fail REGR. vs. 132748
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR. 
vs. 132748

Regressions which are regarded as allowable (not blocking):
 build-arm64   2 hosts-allocate broken REGR. vs. 132748
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 132748
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 132748

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 build-arm64-pvops 3 capture-logs  broken blocked in 132748
 build-arm64   3 capture-logs  broken blocked in 132748
 build-arm64-xsm   3 capture-logs  broken blocked in 132748
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 132748
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 132748
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 132748
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 132748
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 132748
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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  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-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
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-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-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-a

[Xen-devel] [linux-3.18 test] 133239: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvopsbroken
 build-arm64  broken
 build-arm64-xsm  broken
 build-arm64-pvops 3 capture-logs   broken REGR. vs. 128858
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 128858
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 128858
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 128858
 test-amd64-amd64-xl-multivcpu  7 xen-bootfail REGR. vs. 128858
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  7 xen-bootfail REGR. vs. 128858
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. 
vs. 128858
 test-amd64-amd64-libvirt  7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 128858
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 
128858
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 128858
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 128858
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 128858
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 128858
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 128858
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 128858
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 128858
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 128858
 test-amd64-amd64-xl-credit2   7 xen-boot fail REGR. vs. 128858
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 128858
 test-amd64-amd64-xl   7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-rumprun-amd64  7 xen-boot   fail REGR. vs. 128858
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 128858
 test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 128858
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 128858
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 128858
 test-amd64-amd64-xl-pvshim7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 128858
 test-amd64-amd64-xl-xsm   7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-libvirt-xsm  7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 128858

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt  6 xen-install  fail in 133191 pass in 133239
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail in 133191 
pass in 133239
 test-armhf-armhf-xl-cubietruck  6 xen-install  fail pass in 133191
 test-armhf-armhf-xl-vhd   8 host-ping-check-xenfail pass in 133191

Regressions which are regarded as allowable (not blocking):
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 128858
 build-arm64   2 hosts-allocate broken REGR. vs. 128858
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 128858
 test-amd64-amd64-xl-rtds  7 xen-boot fail REGR. vs. 128858

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl   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-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 build-arm64   3 capture-logs  broken blocked in 128858
 build-arm64-xsm   3 capture-logs  broken blocked in 128858
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail in 133191 never 
pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail in 133191 
never pass
 test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 133191 never pass
 test-armhf-armhf-xl-vhd 13 saverestore-support

[Xen-devel] [linux-4.19 test] 133240: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-pvopsbroken
 build-arm64-xsm  broken
 build-amd64   6 xen-buildfail REGR. vs. 129313

Regressions which are regarded as allowable (not blocking):
 build-arm64   2 hosts-allocate broken REGR. vs. 129313
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 129313
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 129313

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf fb0b35e05f772bd415fe264267bbbcde2e0accda
baseline version:
 ovmf 1a35dd723bbf9333a11f6397dac77f1a5dadd3c5

Last test of basis   133203  2019-02-12 18:45:18 Z3 days
Testing same since   133243  2019-02-14 04:57:55 Z1 days1 attempts


People who touched revisions under test:
  Antoine Coeur 
  Ard Biesheuvel 
  Chen A Chen 
  Coeur 
  Hao Wu 
  Laszlo Ersek 
  Sean Brogan 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   1a35dd723b..fb0b35e05f  fb0b35e05f772bd415fe264267bbbcde2e0accda -> 
xen-tested-master

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

[Xen-devel] [libvirt test] 133238: trouble: blocked/broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

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

Regressions which are regarded as allowable (not blocking):
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 132941
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 132941

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-arm64-pvops 3 capture-logs  broken blocked in 132941
 build-arm64-xsm   3 capture-logs  broken blocked in 132941
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 132941
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 132941
 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-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  174309a1f8499b928fa62b8c5b2326485bd66496
baseline version:
 libvirt  620d9dd598fde388f56ac37bcd3b31168c2f9fc6

Last test of basis   132941  2019-02-05 14:57:44 Z   10 days
Failing since132978  2019-02-06 20:25:32 Z9 days7 attempts
Testing same since   133238  2019-02-14 00:02:59 Z1 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Cole Robinson 
  Eric Blake 
  Erik Skultety 
  Jie Wang 
  Jiri Denemark 
  John Ferlan 
  Ján Tomko 
  Laine Stump 
  Michal Privoznik 
  Nikolay Shirokovskiy 
  Peter Krempa 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  broken  
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   blocked 
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



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

Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Stefano Stabellini]

On Fri, 15 Feb 2019, Wei Liu wrote:
> On Thu, Feb 14, 2019 at 09:03:24PM +, Lars Kurth wrote:
> > 
> > 
> > > On 14 Feb 2019, at 18:32, Stefano Stabellini  
> > > wrote:
> > > 
> > > On Thu, 14 Feb 2019, Jan Beulich wrote:
> > > On 13.02.19 at 20:11,  wrote:
> > >>> On Wed, 13 Feb 2019, Wei Liu wrote:
> >  On Tue, Feb 12, 2019 at 09:34:25PM -0500, Daniel P. Smith wrote:
> > > Greetings,
> > > 
> > > On the 11/14/18 Xen x86 community call a discussion was initiated 
> > > about
> > > using Kconfig to build minimized versions of Xen for security, safety
> > > and other certification requirements. After some offline discussions
> > > with Xen contributors I realized that a variety of efforts each with
> > > their own respective goals are underway,
> > > 
> > > - nested virtualization
> > > - mixed criticality architectures
> > > - reducing trusted componentary
> > > - combining hardware protection of virtualization with performance and
> > > ease-of-use of containers
> > > 
> > > These efforts use hypervisors in different roles, all which Xen is
> > > capable of meeting. Today Xen's utility comes at the expense of 
> > > carrying
> > > features necessary for one role to be present in another role where it
> > > is not required, e.g. PV interfaces that may not be essential in an 
> > > ARM
> > > mixed criticality deployment.
> > > 
> > > The initial focus will be to explore and document the range of 
> > > possible
> > > use cases that are of interest to the Xen community. This will be the
> > > input to a design document that is crafted in conjunction with the Xen
> > > maintainers, to identify possible approaches to extend the existing
> > > Kconfig infrastructure to produce tailored instances of Xen.
> > > 
> > > If you are interested in participating in this effort, please reply to
> > > this thread to outline possible use cases, design constraints and 
> > > other
> > > considerations for improving Xen's Kconfig infrastructure to support
> > > tailoring for specific use cases.
> > > 
> >  
> >  My impression from the community call is that you want to provide
> >  smallish configurations for different use cases.
> >  
> >  The Kconfig infrastructure is already able to do what you want as far 
> >  as
> >  I can tell.  You can easily feed it a base config file -- see files
> >  under automation/configs/x86/.  What sort of extension is needed in 
> >  your
> >  opinion?
> >  
> >  As use case goes, it would be a good start if you just submit something
> >  you care about.
> > >>> 
> > >>> I mentioned on the call that a good first start could be a kconfig that
> > >>> allows to build an hypervisor binary with only support for PVH and only
> > >>> support for recent Intel machines, with the goal of minimizing the code
> > >>> base to less than 100K LOC.
> > >> 
> > >> "With only support for PVH" (which really means HVM) we already have.
> > >> "With only support for recent Intel machines" would require adding new
> > >> Kconfig options first, to control Intel, AMD, etc separately, and to then
> > >> further somehow separate "old" from "new" (which may turn out not
> > >> very easy to do without a lot of #ifdef-ary or other code churn). I'm
> > >> not aware of something like this existing on Linux either - all I'm aware
> > >> of there is a means to control what -m option might be passed
> > >> to the compiler, but without disabling any source code from getting
> > >> compiled.
> > > 
> > > I was thinking along the lines of having options to disable drivers for
> > > older timers and older interrupt controllers that are not needed on
> > > recent machines.
> > > 
> > > 
> > >> And then "with only support for recent Intel machines" could also imply
> > >> HAP-only; disabling shadow code (which also is already possible) will
> > >> alone save almost 10k LOC (counting .c files only).
> > > 
> > > I have just run `make cloc' on x86 with the smallest possible
> > > configuration (HVM only):
> > > 
> > > 
> > > http://cloc.sourceforge.net  v 1.60  T=0.87 
> > > s (370.3 files/s, 255808.4 lines/s)
> > > ---
> > > Language files  blankcomment  
> > >  code
> > > ---
> > > C  309  33238  29432 
> > > 157001
> > > Assembly14466531  
> > >  2435
> > > ---
> > > SUM:   323  33704  29963 
> > > 159436
> > > ---

Re: [Xen-devel] MCE/EDAC Status/Updating?

[Andrew Cooper]

On 15/02/2019 18:20, Elliott Mitchell wrote:
> On Fri, Feb 15, 2019 at 03:58:49AM -0700, Jan Beulich wrote:
> On 15.02.19 at 05:23,  wrote:
>>> The MCE/EDAC support code appears to be in rather poor shape.
>>>
>>> The AMD code mentions Family 10h, which might have been available 10
>>> years ago.  They've likely been findable used with difficulty more
>>> recently, but no hardware made in the past 5 years matches this profile.
>> Well, Fam10 is mentioned explicitly, but as per the use of e.g.
>> mcheck_amd_famXX newer ones are supported by this code
>> as well.
> In that case sometime between Xen 4.1 and Xen 4.4, the AMD MCE/EDAC code
> was completely broken and hasn't been fixed.

I take it you've got a usecase which now doesn't work?

>>> Given the recent trends in Xen's development I'd tend to suggest going a
>>> different direction from the existing code.  The existing code was
>>> attempting to handle MCE/EDAC errors by emulating them and passing them
>>> to the effected domain.  Instead of this approach, let Domain 0 handle
>>> talking to MCE/EDAC hardware and merely have Xen decode addresses.
>>>
>>> If errors/warnings are occuring, you need those reports centralized,
>>> which points to handling them in Domain 0.  If an uncorrectable error
>>> occurs, Domain 0 should choose whether to kill a given VM or panic the
>>> entire machine.  Either way, Domain 0 really needs to be alerted that
>>> hardware is misbehaving and may need to be replaced.
>> But the point of the virtualization is to allow guests to more or less
>> gracefully recover (at least as far as the theory of it goes), e.g. by
>> killing just a process, rather than getting blindly killed.
>>
>> As to panic-ing the entire machine - if that's necessary, Dom0 is
>> unlikely to be in the right position. There's way too high a chance for
>> further things to go wrong until the event has even just arrived in
>> Dom0, let alone it having taken a decision.
> I'll agree it does make sense to try sending a corrupted memory alert to
> the effected domain, rather than nuking the entire VM.  Alerting the
> owner of the hardware though should be higher priority as they will then
> know they need to schedule a downtime and replace the module.
>
>
>>> The other part is alerting Domain 0 is *far* more likely to get the
>>> correct type of attention.  A business owning a Domain U on a random
>>> machine, may run a kernel without MCE/EDAC support or could miss the
>>> entries in their system log, nor would they necessarily know the correct
>>> personel to contact about hardware failing.
>> Alerting Dom0 alongside the affected DomU may indeed be desirable,
>> but mainly for the purpose of logging, only as a last resort for the
>> purpose of killing a guest.
> I think alerting Dom0 should be rather higher priority than alerting
> DomUs.  A given DomU may see one correctable memory error per month,
> which might seem harmless until you find there are a hundred DomUs on
> that hardware and every one of them is seeing one error per month.
>
> The only real useful place to report correctable errors like that is to
> Dom0.  Meanwhile uncorrectable errors are likely better to send a PV
> message to the DomU.  Let QEMU turn it into something which looks like
> real hardware if needed.  Meanwhile Dom0 may have a more up to date
> driver for the hardware than Xen.

I don't think anyone can defend the current state of MCE
handling/reporting in Xen, and I would certainly like to see it improved.

However, its not a simple as "let dom0 handle everything".  Dom0 is just
a VM, like all other domains.  It cant access the MCE MSR banks, and
even if it could, it would have a pcpu vs vcpu problem when trying to
interpret the data.

Xen is the entity which needs to handle the #MC, and do first-pass
processing.  If we want to give it to dom0 for further processing, it
either has to be virtualised in an architectural manner, or passed via a
paravirt channel so dom0 definitely knows it is dealing with data in
different enumeration spaces.

I expect there are also some non-trivial ACPI interactions here, which
are also made complicated by the Xen/dom0
interface-turned-undoucmented-mess.

Another issue we should look into is if we are going to make
improvements here, how do we go about ensuring that we don't regress
behaviour again.  I have no experience in this area (other than
bugfixing the #MC handler until it appears to behave as it did before),
but surely there are some ways of testing?

~Andrew

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

[Xen-devel] [PATCH RFC] drm: add func to better detect wether swiotlb is needed

[Michael D Labriola]

This commit fixes DRM failures on Xen PV systems that were introduced in
v4.17 by the following commits:

82626363 drm: add func to get max iomem address v2
fd5fd480 drm/amdgpu: only enable swiotlb alloc when need v2
1bc3d3cc drm/radeon: only enable swiotlb path when need v2

The introduction of ->need_swiotlb to the ttm_dma_populate() conditionals
in the radeon and amdgpu device drivers causes Gnome to immediately crash
on Xen PV systems, returning the user to the login screen.  The following
kernel errors get logged:

[   28.554259] radeon_dp_aux_transfer_native: 200 callbacks suppressed
[   31.219821] radeon :01:00.0: swiotlb buffer is full (sz: 2097152 bytes)
[   31.220030] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to 
allocate GEM object (16384000, 2, 4096, -14)
[   31.226109] radeon :01:00.0: swiotlb buffer is full (sz: 2097152 bytes)
[   31.226300] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to 
allocate GEM object (16384000, 2, 4096, -14)
[   31.300734] gnome-shell[1935]: segfault at 88 ip 7f39151cd904 sp 
7ffc97611ad8 error 4 in libmutter-cogl.so[7f3915178000+aa000]
[   31.300745] Code: 5f c3 0f 1f 40 00 48 8b 47 78 48 8b 40 40 ff e0 66 0f 1f 
44 00 00 48 8b 47 78 48 8b 40 48 ff e0 66 0f 1f 44 00 00 48 8b 47 78 <48> 8b 80 
88 00 00 00 ff e0 0f 1f 00 48 8b 47 78 48 8b 40 68 ff e0
[   38.193302] radeon_dp_aux_transfer_native: 116 callbacks suppressed
[   40.009317] radeon :01:00.0: swiotlb buffer is full (sz: 2097152 bytes)
[   40.009488] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to 
allocate GEM object (16384000, 2, 4096, -14)
[   40.015114] radeon :01:00.0: swiotlb buffer is full (sz: 2097152 bytes)
[   40.015297] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to 
allocate GEM object (16384000, 2, 4096, -14)
[   40.028302] gnome-shell[2431]: segfault at 2dadf40 ip 02dadf40 sp 
7ffcd24ea5f8 error 15
[   40.028306] Code: 20 6e 31 00 00 00 00 00 00 00 00 37 e3 3d 2d 7f 00 00 80 
f4 e6 3d 2d 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 
00 00 00 00 00 c1 00 00 00 00 00 00 00 80 e1 d2 03 00 00

This commit renames drm_get_max_iomem() to drm_need_swiotlb(), adds a
xen_pv_domain() check to it, and moves the bit shifting comparison that
always follows its usage into the function (simplifying the drm driver
code).
---
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c  |  2 +-
 drivers/gpu/drm/drm_memory.c   | 19 ---
 drivers/gpu/drm/radeon/radeon_device.c |  2 +-
 include/drm/drm_cache.h|  2 +-
 6 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index 910c4ce..6bc0266 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -1029,7 +1029,7 @@ static int gmc_v7_0_sw_init(void *handle)
pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
pr_warn("amdgpu: No coherent DMA available\n");
}
-   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
+   adev->need_swiotlb = drm_need_swiotlb(dma_bits);
 
r = gmc_v7_0_init_microcode(adev);
if (r) {
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index 747c068..8638adf 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -1155,7 +1155,7 @@ static int gmc_v8_0_sw_init(void *handle)
pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
pr_warn("amdgpu: No coherent DMA available\n");
}
-   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
+   adev->need_swiotlb = drm_need_swiotlb(dma_bits);
 
r = gmc_v8_0_init_microcode(adev);
if (r) {
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index f35d7a5..4f67093 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -989,7 +989,7 @@ static int gmc_v9_0_sw_init(void *handle)
pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
printk(KERN_WARNING "amdgpu: No coherent DMA available.\n");
}
-   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
+   adev->need_swiotlb = drm_need_swiotlb(dma_bits);
 
if (adev->asic_type == CHIP_VEGA20) {
r = gfxhub_v1_1_get_xgmi_info(adev);
diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c
index d69e4fc..6af59a6 100644
--- a/drivers/gpu/drm/drm_memory.c
+++ b/drivers/gpu/drm/drm_memory.c
@@ -35,6 +35,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include "drm_legacy.h"
 
@@ -150,15 +151,27 @@ void drm_legacy_ioremapfree(struct drm_local_map *map, 
struct drm_device *dev)
 }
 EXPORT_SYMBOL(d

Re: [Xen-devel] [Qemu-devel] [PATCH 1/3] dataplane/xen-block: remove dead code

[Philippe Mathieu-Daudé]

On 2/15/19 5:25 PM, Paul Durrant wrote:
> The if() statement is clearly bogus (dead code which should have been
> cleaned up when grant mapping was removed).

"... was removed in 06454c24ad)."

> 
> Spotted by Coverity: CID 1398635
> 
> While in the neighbourhood, add a missing 'fall through' annotation.
> 
> Reported-by: Peter Maydell 
> Signed-off-by: Paul Durrant 
> ---
> Cc: Stefan Hajnoczi 
> Cc: Stefano Stabellini 
> Cc: Anthony Perard 
> Cc: Kevin Wolf 
> Cc: Max Reitz 
> ---
>  hw/block/dataplane/xen-block.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-block.c
> index c6a15da024..f1523c5b45 100644
> --- a/hw/block/dataplane/xen-block.c
> +++ b/hw/block/dataplane/xen-block.c
> @@ -281,10 +281,6 @@ static void xen_block_complete_aio(void *opaque, int ret)
>  break;
>  case BLKIF_OP_WRITE:
>  case BLKIF_OP_FLUSH_DISKCACHE:
> -if (!request->req.nr_segments) {
> -break;
> -}
> -break;
>  default:
>  break;
>  }
> @@ -298,6 +294,7 @@ static void xen_block_complete_aio(void *opaque, int ret)
>  if (!request->req.nr_segments) {
>  break;
>  }
> +/* fall through */
>  case BLKIF_OP_READ:
>  if (request->status == BLKIF_RSP_OKAY) {
>  block_acct_done(blk_get_stats(dataplane->blk), &request->acct);
> 

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

Re: [Xen-devel] XEN on R-CAR H3

[Oleksandr]

On 15.02.19 16:17, Amit Tomer wrote:

Hi,


Hi





disk = [ 'phy:/dev/mmcblk1p1,xvda1' ]

Thanks , this worked for us and we can now boot Linux guest in domU.


Sounds great




But now, while booting Android as domU guest , we don't get console
login for domU and it stuck
here:

[   10.597394] usbcore: registered new interface driver cdc_acm
[   10.597436] cdc_acm: USB Abstract Control Model driver for USB
modems and ISDN adapters
[   10.599829] file system registered
[   10.611942] kauditd_printk_skb: 6 callbacks suppressed
[   10.611947] audit: type=1400 audit(1550239280.843:17): avc:  denied
  { entrypoint } for  pid=864 comm="init" path="/system/bin/adbd"
dev="xvda1" ino=889 scontext=u:r:adbd:s0
tcontext=u:object_r:unlabeled:s0 tclass=file permissive=1
[   10.616842] audit: type=1400 audit(1550239280.847:18): avc:  denied
  { map } for  pid=864 comm="adbd" path="/system/bin/adbd" dev="xvda1"
ino=889 scontext=u:r:adbd:s0 tcontext=u:object_r:unlabeled:s0
tclass=file permissive=1
[   10.617012] audit: type=1400 audit(1550239280.851:19): avc:  denied
  { read execute } for  pid=864 comm="adbd" path="/system/bin/adbd"
dev="xvda1" ino=889 scontext=u:r:adbd:s0
tcontext=u:object_r:unlabeled:s0 tclass=file permissive=1
[   10.747628] random: adbd: uninitialized urandom read (40 bytes read)

Is there a special way to give hvc console login in Android , the way
we do it in Ubuntu is to create hvc0.conf file?


I am wondering what Android version you are using. What is your use-case?

I am not familiar with Android internals, but AFAIK we don't perform any 
special actions to make Android happy using hvc, except the following:

1. Add "console=hvc0" to kernel command line
2. Set CONFIG_HVC_XEN=y, CONFIG_HVC_XEN_FRONTEND=y in kernel defconfig

This is our development product
https://github.com/xen-troops/meta-xt-prod-devel
which in addition to Linux guest contains Android P guest.

Here you can see how we implemented.




Thanks
- Amit


--
Regards,

Oleksandr Tyshchenko


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

Re: [Xen-devel] Organising a workshop to solve safety certification related questions (March 25/26, Cambridge, UK, Citrix)

[Lars Kurth]

Hi all,

apologies this took a while. 5 weeks to go to the event!
I created 
https://wiki.xenproject.org/wiki/Developer_Meeting/March2019_-_Safety_Certification
 

 which contains information about the venue, hotels and travel

I also added a registration form: please fill this out if you want to attend 
(even if just remotely): see 
https://wiki.xenproject.org/wiki/Developer_Meeting/March2019_-_Safety_Certification#Registration_.28both_in_person_and_for_remote_participation.29
 


I started to put in some thoughts with regards to the agenda: I will be looking 
for volunteers to help with some of the content. I am working with EPAM on some 
of these, but others are welcome to join.
A scratchpad of ideas which will eventually become an agenda are here: 
https://docs.google.com/document/d/1aKjxDLkEnPZ_0gHgAv4xy9iPv6hVBkIC_wiA0rZzRms/edit
 

 

If you need a visa invitation letter, there is a 3 working day turnaround. 
Please contact me via my Citrix email address as outlined in the Wiki page if 
you need an invitation letter

Best Regards
Lars


> On 4 Feb 2019, at 20:25, Lars Kurth  wrote:
> 
> Hi all,
> 
> from my perspective we have enough momentum to move forward, albeit some 
> prospective attendees are still confirming their travel plans. I can 
> accommodate a maximum if 15, but possibly, a few more. With this in Mind, 
> please start booking flights.
> 
> Location:
> The Citrix office in Milton, just outside of Cambridge
> Citrix Systems:
> 101 Cambridge Science Park Rd, Milton
> Cambridge CB4 0FY
> UK
> 
> Timing
> The event will be held on Monday March 25, and ends on the 26th. I expect 
> days to go from 9:00 to 17:00 and some beverages and food will be provided
> EPAM will host an evening event on the 25th
> 
> Agenda
> With regards the agenda, I will work selected community members on it.
> The agenda is yours, so please prepare and be specific about the technical, 
> community, process and maybe financial problems we have to solve.
> 
> Remote Participation
> I will still need to test this and provide more feedback
> 
> Registration
> I will set up an ad-hoc google doc
> 
> Getting To Cambridge/Accommodation
> London Stansted is the easiest airport to fly to: there is a direct train 
> that goes frequently and take 30-40 minutes
> You may have to use London Heathrow you come from the US, China or Japan. In 
> that case, you can take a fixed rate taxi: see 
> http://www.expressairporttransport.co.uk/Taxi-Cambridge-To-Heathrow-Airport 
> 
> 
> The key question you will have to decide upon is whether you stay in the town 
> centre, which is stunning, but it may take 30 mins to the Citrix office, or 
> whether you stay close tp the office. I will provide more info in due time
> 
> Regards
> Lars 
> 
>> On 23 Jan 2019, at 10:16, Lars Kurth > > wrote:
>> 
>> Hi all,
>> 
>> it looks as if March 25/26 in Frankfurt or Cambridge is the best option. For 
>> Matt, this would mean that he can only attend the first day, but I believe 
>> this would be OK. Maybe Robin can attend the second day, instead of Matt. 
>> Before we finalise the dates, I will need to secure the meeting space. I 
>> will be able to do this in the next few days and will send an update as soon 
>> as this is done.
>> 
>> Note that we had a few people on this list which have replied to me 
>> privately. Please let me know privately or publicly whether March 25/26 
>> would be suitable for you. We can in parallel work on the agenda.
>>  
>> Best Regards
>> Lars
>> 
>>> On 16 Jan 2019, at 13:09, Lars Kurth >> > wrote:
>>> 
>>> 
>>> 
 On 16 Jan 2019, at 12:16, George Dunlap >>> > wrote:
 
 On 1/8/19 5:59 PM, Lars Kurth wrote:
> What I need is 
> - Raise your hands if you are interested 
> - Let me know of date / location restrictions
> - We could try and so some of this via video conference: would you be 
> able to attend if we did open the meeting up to some remote participation
 
 I'm interested.  All the dates mentioned should work for me.
 
 -George
>>> 
>>> Hi all,
>>> 
>>> to summarise!
>>> 
>>> We have a good number of people and organisations interested from pretty 
>>> one everyone on the list, but it seems the dates won't work for most 
>>> people. 
>>> Location wise: Germany (Frankfurt) and/or UK (Cambridge) work for most, 
>>> except for representatives from Dornerworks and Starlab, who would dial in 
>>> for some of the meetings 
>>> There seems to be a slight bias for Cambridge, as we have most

Re: [Xen-devel] RT Xen on ARM - R-Car series

[Julien Grall]

Sorry for the formatting.

On Fri, 15 Feb 2019, 18:30 Andrii Anisov,  wrote:

> Hello Julien,
>
> On 15.02.19 18:31, Julien Grall wrote:
> > Why? Is it because you want to be cache-aligned?  If so, requiring the
> > structure to be 64-bytes is not enough.
>
> I did not mean caches.
>

What is the reason then?

> You also want the address to
> > be 64-bytes aligned.
>
> I would keep it as a hint for static/dynamic allocations in VMs, hoping
> the address would be normally 64 bytes aligned.
> I hope it might be stronger than, only commenting it should not cross a
> page boundary. E.g. like `struct vcpu_register_vcpu_info` is commented.
>
> I've got this idea after looking at runstate definition as per-cpu in
> Linux [1]
>

It is not obvious why it would be 64-bytes alignment from the definition.
Can you please explain the rationale to impose that alignment?

I really appreciate you suggest ideas/patches but  it would be helpful if
you provide rationale at the same time. This would avoid a round of e-mails
just for asking the reasons and delay the interesting bits.


> > If an OS cares about it, then it can aligned itself here.
> I suppose we can hint the OS by structure alignment in the interface
> header, and require it from OS verifying it on hypercall handling

.


> [1]
> https://elixir.bootlin.com/linux/v5.0-rc6/source/drivers/xen/time.c#L22
>
> --
> Sincerely,
> Andrii Anisov.
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH V2 0/7] Add FOLL_LONGTERM to GUP fast and use it

[Ira Weiny]

> NOTE: This series depends on my clean up patch to remove the write parameter
> from gup_fast_permitted()[1]
> 
> HFI1, qib, and mthca, use get_user_pages_fast() due to it performance
> advantages.  These pages can be held for a significant time.  But
> get_user_pages_fast() does not protect against mapping of FS DAX pages.
> 
> Introduce FOLL_LONGTERM and use this flag in get_user_pages_fast() which
> retains the performance while also adding the FS DAX checks.  XDP has also
> shown interest in using this functionality.[2]
> 
> In addition we change get_user_pages() to use the new FOLL_LONGTERM flag and
> remove the specialized get_user_pages_longterm call.
> 
> [1] https://lkml.org/lkml/2019/2/11/237
> [2] https://lkml.org/lkml/2019/2/11/1789

Any comments on this series?  I've touched a lot of subsystems which I think
require review.

Thanks,
Ira

> 
> Ira Weiny (7):
>   mm/gup: Replace get_user_pages_longterm() with FOLL_LONGTERM
>   mm/gup: Change write parameter to flags in fast walk
>   mm/gup: Change GUP fast to use flags rather than a write 'bool'
>   mm/gup: Add FOLL_LONGTERM capability to GUP fast
>   IB/hfi1: Use the new FOLL_LONGTERM flag to get_user_pages_fast()
>   IB/qib: Use the new FOLL_LONGTERM flag to get_user_pages_fast()
>   IB/mthca: Use the new FOLL_LONGTERM flag to get_user_pages_fast()
> 
>  arch/mips/mm/gup.c  |  11 +-
>  arch/powerpc/kvm/book3s_64_mmu_hv.c |   4 +-
>  arch/powerpc/kvm/e500_mmu.c |   2 +-
>  arch/powerpc/mm/mmu_context_iommu.c |   4 +-
>  arch/s390/kvm/interrupt.c   |   2 +-
>  arch/s390/mm/gup.c  |  12 +-
>  arch/sh/mm/gup.c|  11 +-
>  arch/sparc/mm/gup.c |   9 +-
>  arch/x86/kvm/paging_tmpl.h  |   2 +-
>  arch/x86/kvm/svm.c  |   2 +-
>  drivers/fpga/dfl-afu-dma-region.c   |   2 +-
>  drivers/gpu/drm/via/via_dmablit.c   |   3 +-
>  drivers/infiniband/core/umem.c  |   5 +-
>  drivers/infiniband/hw/hfi1/user_pages.c |   5 +-
>  drivers/infiniband/hw/mthca/mthca_memfree.c |   3 +-
>  drivers/infiniband/hw/qib/qib_user_pages.c  |   8 +-
>  drivers/infiniband/hw/qib/qib_user_sdma.c   |   2 +-
>  drivers/infiniband/hw/usnic/usnic_uiom.c|   9 +-
>  drivers/media/v4l2-core/videobuf-dma-sg.c   |   6 +-
>  drivers/misc/genwqe/card_utils.c|   2 +-
>  drivers/misc/vmw_vmci/vmci_host.c   |   2 +-
>  drivers/misc/vmw_vmci/vmci_queue_pair.c |   6 +-
>  drivers/platform/goldfish/goldfish_pipe.c   |   3 +-
>  drivers/rapidio/devices/rio_mport_cdev.c|   4 +-
>  drivers/sbus/char/oradax.c  |   2 +-
>  drivers/scsi/st.c   |   3 +-
>  drivers/staging/gasket/gasket_page_table.c  |   4 +-
>  drivers/tee/tee_shm.c   |   2 +-
>  drivers/vfio/vfio_iommu_spapr_tce.c |   3 +-
>  drivers/vfio/vfio_iommu_type1.c |   3 +-
>  drivers/vhost/vhost.c   |   2 +-
>  drivers/video/fbdev/pvr2fb.c|   2 +-
>  drivers/virt/fsl_hypervisor.c   |   2 +-
>  drivers/xen/gntdev.c|   2 +-
>  fs/orangefs/orangefs-bufmap.c   |   2 +-
>  include/linux/mm.h  |  17 +-
>  kernel/futex.c  |   2 +-
>  lib/iov_iter.c  |   7 +-
>  mm/gup.c| 220 
>  mm/gup_benchmark.c  |   5 +-
>  mm/util.c   |   8 +-
>  net/ceph/pagevec.c  |   2 +-
>  net/rds/info.c  |   2 +-
>  net/rds/rdma.c  |   3 +-
>  44 files changed, 232 insertions(+), 180 deletions(-)
> 
> -- 
> 2.20.1
> 

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

Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Stefano Stabellini]

On Fri, 15 Feb 2019, George Dunlap wrote:
> > On Feb 15, 2019, at 5:36 PM, Stefano Stabellini  
> > wrote:
> > 
> > On Fri, 15 Feb 2019, George Dunlap wrote:
> >>> On Feb 13, 2019, at 7:11 PM, Stefano Stabellini  
> >>> wrote:
> >>> 
> >>> On Wed, 13 Feb 2019, Wei Liu wrote:
>  On Tue, Feb 12, 2019 at 09:34:25PM -0500, Daniel P. Smith wrote:
> > Greetings,
> > 
> > On the 11/14/18 Xen x86 community call a discussion was initiated about
> > using Kconfig to build minimized versions of Xen for security, safety
> > and other certification requirements. After some offline discussions
> > with Xen contributors I realized that a variety of efforts each with
> > their own respective goals are underway,
> > 
> > - nested virtualization
> > - mixed criticality architectures
> > - reducing trusted componentary
> > - combining hardware protection of virtualization with performance and
> > ease-of-use of containers
> > 
> > These efforts use hypervisors in different roles, all which Xen is
> > capable of meeting. Today Xen's utility comes at the expense of carrying
> > features necessary for one role to be present in another role where it
> > is not required, e.g. PV interfaces that may not be essential in an ARM
> > mixed criticality deployment.
> > 
> > The initial focus will be to explore and document the range of possible
> > use cases that are of interest to the Xen community. This will be the
> > input to a design document that is crafted in conjunction with the Xen
> > maintainers, to identify possible approaches to extend the existing
> > Kconfig infrastructure to produce tailored instances of Xen.
> > 
> > If you are interested in participating in this effort, please reply to
> > this thread to outline possible use cases, design constraints and other
> > considerations for improving Xen's Kconfig infrastructure to support
> > tailoring for specific use cases.
> > 
>  
>  My impression from the community call is that you want to provide
>  smallish configurations for different use cases.
>  
>  The Kconfig infrastructure is already able to do what you want as far as
>  I can tell.  You can easily feed it a base config file -- see files
>  under automation/configs/x86/.  What sort of extension is needed in your
>  opinion?
>  
>  As use case goes, it would be a good start if you just submit something
>  you care about.
> >>> 
> >>> I mentioned on the call that a good first start could be a kconfig that
> >>> allows to build an hypervisor binary with only support for PVH and only
> >>> support for recent Intel machines, with the goal of minimizing the code
> >>> base to less than 100K LOC.
> >> 
> >> I think one thing that might be helpful is a sort of “feature document” 
> >> for each defconfig we’re looking at creating.  This would include:
> >> 
> >> * What the “target use case” for each defconfig would be
> >> * The end goal in terms of functionality / LoC / whatever
> >> * The current state, work items yet to do
> >> * What potential variations there are (i.e., how to enable shadow if you 
> >> want, or switch from Intel-only to AMD-only)
> >> 
> >> I’ve sort of been using docs/design/qemu-deprivilege.md in this way: 
> >> Saying where we want to go, and moving things from “to do” to “done” as 
> >> they get implemented.  That would make it easier to have in-progress 
> >> things in the tree, make it easier for people to collaborate / enhance 
> >> defconfigs, and also be a starting point for talking about testing and 
> >> support status.
> > 
> > +1
> > 
> > Just to set the expectations right on this thread: I am just trying to
> > provide feedback from the field, things I know are important to the Xen
> > on x86 embedded user community. I am not going to take this on as a work
> > item.  But somebody else might? Daniel Smith, I am looking at you :-)
> 
> I tried to make this clear on the call, but just in case, let me try to 
> repeat / expand on what I said:
> 
> When creating a brand-new thing like this, the best thing is for each 
> person/org to make exactly the thing that they want.  Daniel shouldn’t be 
> trying to make a defconfig for embedded x86 hypervisors unless that’s 
> specifically what he wants to use: he should be making a defconfig for his 
> specific use case.
> 
> When someone else comes along and wants the second instance of whatever this 
> thing is, we can then refactor our system based on two people’s real actual 
> requirements.
> 
> The only time to try to sit and plan a General Purpose Thing are:
> 1. When you already have loads of instances, so you have a clear idea what a 
> General Purpose Thing of this type looks like
> 2. When you need to worry about backwards compatibility.
> 
> I don’t think #1 or #2 are true in this case; so the most efficient thing 
> will be for Daniel to make exactly the thing that 

Re: [Xen-devel] MCE/EDAC Status/Updating?

[Elliott Mitchell]

On Fri, Feb 15, 2019 at 03:58:49AM -0700, Jan Beulich wrote:
> >>> On 15.02.19 at 05:23,  wrote:
> > The MCE/EDAC support code appears to be in rather poor shape.
> > 
> > The AMD code mentions Family 10h, which might have been available 10
> > years ago.  They've likely been findable used with difficulty more
> > recently, but no hardware made in the past 5 years matches this profile.
> 
> Well, Fam10 is mentioned explicitly, but as per the use of e.g.
> mcheck_amd_famXX newer ones are supported by this code
> as well.

In that case sometime between Xen 4.1 and Xen 4.4, the AMD MCE/EDAC code
was completely broken and hasn't been fixed.



> > Given the recent trends in Xen's development I'd tend to suggest going a
> > different direction from the existing code.  The existing code was
> > attempting to handle MCE/EDAC errors by emulating them and passing them
> > to the effected domain.  Instead of this approach, let Domain 0 handle
> > talking to MCE/EDAC hardware and merely have Xen decode addresses.
> > 
> > If errors/warnings are occuring, you need those reports centralized,
> > which points to handling them in Domain 0.  If an uncorrectable error
> > occurs, Domain 0 should choose whether to kill a given VM or panic the
> > entire machine.  Either way, Domain 0 really needs to be alerted that
> > hardware is misbehaving and may need to be replaced.
> 
> But the point of the virtualization is to allow guests to more or less
> gracefully recover (at least as far as the theory of it goes), e.g. by
> killing just a process, rather than getting blindly killed.
> 
> As to panic-ing the entire machine - if that's necessary, Dom0 is
> unlikely to be in the right position. There's way too high a chance for
> further things to go wrong until the event has even just arrived in
> Dom0, let alone it having taken a decision.

I'll agree it does make sense to try sending a corrupted memory alert to
the effected domain, rather than nuking the entire VM.  Alerting the
owner of the hardware though should be higher priority as they will then
know they need to schedule a downtime and replace the module.


> > The other part is alerting Domain 0 is *far* more likely to get the
> > correct type of attention.  A business owning a Domain U on a random
> > machine, may run a kernel without MCE/EDAC support or could miss the
> > entries in their system log, nor would they necessarily know the correct
> > personel to contact about hardware failing.
> 
> Alerting Dom0 alongside the affected DomU may indeed be desirable,
> but mainly for the purpose of logging, only as a last resort for the
> purpose of killing a guest.

I think alerting Dom0 should be rather higher priority than alerting
DomUs.  A given DomU may see one correctable memory error per month,
which might seem harmless until you find there are a hundred DomUs on
that hardware and every one of them is seeing one error per month.

The only real useful place to report correctable errors like that is to
Dom0.  Meanwhile uncorrectable errors are likely better to send a PV
message to the DomU.  Let QEMU turn it into something which looks like
real hardware if needed.  Meanwhile Dom0 may have a more up to date
driver for the hardware than Xen.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445



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

Re: [Xen-devel] [PATCH v3 7/8] x86/mm: handle foreign mappings in p2m_entry_modify

[George Dunlap]

> On Feb 15, 2019, at 2:18 PM, Roger Pau Monne  wrote:
> 
> So that the specific handling can be removed from
> atomic_write_ept_entry and be shared with npt and shadow code.
> 
> This commit also removes the check that prevent non-ept PVH dom0 from
> mapping foreign pages.
> 
> Signed-off-by: Roger Pau Monné 

Mostly looks good; just a few comments...
> 
> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
> index f4ec2becbd..1687b31571 100644
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -932,11 +932,14 @@ int p2m_set_ioreq_server(struct domain *d, unsigned int 
> flags,
> struct hvm_ioreq_server *p2m_get_ioreq_server(struct domain *d,
>   unsigned int *flags);
> 
> -static inline void p2m_entry_modify(struct p2m_domain *p2m, p2m_type_t nt,
> -p2m_type_t ot, unsigned int level)
> +static inline int p2m_entry_modify(struct p2m_domain *p2m, p2m_type_t nt,
> +   p2m_type_t ot, mfn_t nfn, mfn_t ofn,
> +   unsigned int level)
> {
> -if ( level != 1 || nt == ot )
> -return;
> +BUG_ON(level > 1 && (nt == p2m_ioreq_server || nt == p2m_map_foreign));
> +
> +if ( level != 1 || (nt == ot && mfn_eq(nfn, ofn)) )
> +return 0;
> 
> switch ( nt )
> {
> @@ -948,6 +951,14 @@ static inline void p2m_entry_modify(struct p2m_domain 
> *p2m, p2m_type_t nt,
> p2m->ioreq.entry_count++;
> break;
> 
> +case p2m_map_foreign:
> +BUG_ON(!mfn_valid(nfn));

Since we’re going to be returning errors anyway, why not retain the original 
functionality of returning -EINVAL in this case, rather than BUG_ON?

> +
> +if ( !page_get_owner_and_reference(mfn_to_page(nfn)) )
> +return -EBUSY;
> +
> +break;
> +
> default:
> break;
> }
> @@ -959,9 +970,16 @@ static inline void p2m_entry_modify(struct p2m_domain 
> *p2m, p2m_type_t nt,
> p2m->ioreq.entry_count--;
> break;
> 
> +case p2m_map_foreign:
> +BUG_ON(!mfn_valid(ofn));

If somehow this happened, then the bug isn’t here but somewhere else; 
continuing on won’t make things any worse than they would be if this page 
weren’t removed.  I think this should probably be an ASSERT() (to help narrow 
down where a bug may have come from), followed by a simple return.  Likely the 
worst that would happen here is an un-killable domain; no need to crash 
production servers in this case.

Thanks,
 -George

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

Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions

[George Dunlap]

> On Feb 15, 2019, at 5:36 PM, Stefano Stabellini  
> wrote:
> 
> On Fri, 15 Feb 2019, George Dunlap wrote:
>>> On Feb 13, 2019, at 7:11 PM, Stefano Stabellini  
>>> wrote:
>>> 
>>> On Wed, 13 Feb 2019, Wei Liu wrote:
 On Tue, Feb 12, 2019 at 09:34:25PM -0500, Daniel P. Smith wrote:
> Greetings,
> 
> On the 11/14/18 Xen x86 community call a discussion was initiated about
> using Kconfig to build minimized versions of Xen for security, safety
> and other certification requirements. After some offline discussions
> with Xen contributors I realized that a variety of efforts each with
> their own respective goals are underway,
> 
> - nested virtualization
> - mixed criticality architectures
> - reducing trusted componentary
> - combining hardware protection of virtualization with performance and
> ease-of-use of containers
> 
> These efforts use hypervisors in different roles, all which Xen is
> capable of meeting. Today Xen's utility comes at the expense of carrying
> features necessary for one role to be present in another role where it
> is not required, e.g. PV interfaces that may not be essential in an ARM
> mixed criticality deployment.
> 
> The initial focus will be to explore and document the range of possible
> use cases that are of interest to the Xen community. This will be the
> input to a design document that is crafted in conjunction with the Xen
> maintainers, to identify possible approaches to extend the existing
> Kconfig infrastructure to produce tailored instances of Xen.
> 
> If you are interested in participating in this effort, please reply to
> this thread to outline possible use cases, design constraints and other
> considerations for improving Xen's Kconfig infrastructure to support
> tailoring for specific use cases.
> 
 
 My impression from the community call is that you want to provide
 smallish configurations for different use cases.
 
 The Kconfig infrastructure is already able to do what you want as far as
 I can tell.  You can easily feed it a base config file -- see files
 under automation/configs/x86/.  What sort of extension is needed in your
 opinion?
 
 As use case goes, it would be a good start if you just submit something
 you care about.
>>> 
>>> I mentioned on the call that a good first start could be a kconfig that
>>> allows to build an hypervisor binary with only support for PVH and only
>>> support for recent Intel machines, with the goal of minimizing the code
>>> base to less than 100K LOC.
>> 
>> I think one thing that might be helpful is a sort of “feature document” for 
>> each defconfig we’re looking at creating.  This would include:
>> 
>> * What the “target use case” for each defconfig would be
>> * The end goal in terms of functionality / LoC / whatever
>> * The current state, work items yet to do
>> * What potential variations there are (i.e., how to enable shadow if you 
>> want, or switch from Intel-only to AMD-only)
>> 
>> I’ve sort of been using docs/design/qemu-deprivilege.md in this way: Saying 
>> where we want to go, and moving things from “to do” to “done” as they get 
>> implemented.  That would make it easier to have in-progress things in the 
>> tree, make it easier for people to collaborate / enhance defconfigs, and 
>> also be a starting point for talking about testing and support status.
> 
> +1
> 
> Just to set the expectations right on this thread: I am just trying to
> provide feedback from the field, things I know are important to the Xen
> on x86 embedded user community. I am not going to take this on as a work
> item.  But somebody else might? Daniel Smith, I am looking at you :-)

I tried to make this clear on the call, but just in case, let me try to repeat 
/ expand on what I said:

When creating a brand-new thing like this, the best thing is for each 
person/org to make exactly the thing that they want.  Daniel shouldn’t be 
trying to make a defconfig for embedded x86 hypervisors unless that’s 
specifically what he wants to use: he should be making a defconfig for his 
specific use case.

When someone else comes along and wants the second instance of whatever this 
thing is, we can then refactor our system based on two people’s real actual 
requirements.

The only time to try to sit and plan a General Purpose Thing are:
1. When you already have loads of instances, so you have a clear idea what a 
General Purpose Thing of this type looks like
2. When you need to worry about backwards compatibility.

I don’t think #1 or #2 are true in this case; so the most efficient thing will 
be for Daniel to make exactly the thing that he himself wants, spending very 
little time on attempting to make it a General Purpose Thing that someone else 
might want.

 -George

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

Re: [Xen-devel] [PATCH v3 6/8] p2m: change write_p2m_entry to return an error code

[George Dunlap]

> On Feb 15, 2019, at 2:18 PM, Roger Pau Monne  wrote:
> 
> This is in preparation for also changing p2m_entry_modify to return an
> error code.
> 
> No functional change intended.

I think you need to explain wheny/why you’re using BUG_ON() rather than 
ASSERT() or passing the caller up the stack.


Just in general:

* Passing things up the stack should be used when the caller is already 
expecting to handle errors, and the state when the error was discovered isn’t 
broken, or too hard to fix.

* BUG_ON() should be used when you can’t pass things up the stack, and 
continuing would certainly cause a vulnerability.

* ASSERT() should be used when continuing might work, or might have an effect 
later whose badness is equal or less than that of a host crash; OR whose truth 
can be clearly observed from the code directly surrounding it.

For instance...

> diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
> index 04e9d81cf6..44abd65999 100644
> --- a/xen/arch/x86/mm/p2m-pt.c
> +++ b/xen/arch/x86/mm/p2m-pt.c
> @@ -202,7 +202,7 @@ p2m_next_level(struct p2m_domain *p2m, void **table,
> new_entry = l1e_from_mfn(mfn, P2M_BASE_FLAGS | _PAGE_RW);
> 
> p2m_add_iommu_flags(&new_entry, level, 
> IOMMUF_readable|IOMMUF_writable);
> -p2m->write_p2m_entry(p2m, gfn, p2m_entry, new_entry, level + 1);
> +BUG_ON(p2m->write_p2m_entry(p2m, gfn, p2m_entry, new_entry, level + 
> 1));

In this case, a few lines above we have `return -ENOMEM`; so:
1. The caller is expecting to handle error values, and
2. There’s no unusual state to try to clean up.

It seems like the `rc = … / if ( rc ) return rc` pattern would be better here.

> }
> else if ( flags & _PAGE_PSE )
> {
> @@ -250,14 +250,14 @@ p2m_next_level(struct p2m_domain *p2m, void **table,
> {
> new_entry = l1e_from_pfn(pfn | (i << ((level - 1) * 
> PAGETABLE_ORDER)),
>  flags);
> -p2m->write_p2m_entry(p2m, gfn, l1_entry + i, new_entry, level);
> +BUG_ON(p2m->write_p2m_entry(p2m, gfn, l1_entry + i, new_entry, 
> level));
> }

Here, we can’t return an error value, because we’re halfway through an 
operation and don’t want to have to bother to clean up.  Ignoring the error and 
leaving it half-done would certainly be worse than a host crash.

On the other hand… we know that the previous write_entry succeeded; is it 
really possible for this one to fail?

p2m_entry_modify() doesn’t do anything for entries > 4k, and (by the end of 
this series) will BUG_ON() if its "

I’m tempted to say that what we should do is use ASSERT() here (and many other 
places) put a comment in p2m_entry_modify() to say that when changing it, we 
need to revisit all the direct callers to make sure that ASSERT() is still 
suitable.

> 
> unmap_domain_page(l1_entry);
> 
> new_entry = l1e_from_mfn(mfn, P2M_BASE_FLAGS | _PAGE_RW);
> p2m_add_iommu_flags(&new_entry, level, 
> IOMMUF_readable|IOMMUF_writable);
> -p2m->write_p2m_entry(p2m, gfn, p2m_entry, new_entry, level + 1);
> +BUG_ON(p2m->write_p2m_entry(p2m, gfn, p2m_entry, new_entry, level + 
> 1));

In this case, we can see from the context that what’s been written is a 
mid-level entry that has just been allocated; there’s no code change that 
should be able to cause this to fail.  I’m inclined to say this should only be 
an ASSERT().

> }
> else
> ASSERT(flags & _PAGE_PRESENT);
> @@ -321,7 +321,7 @@ static int p2m_pt_set_recalc_range(struct p2m_domain *p2m,
> if ( (l1e_get_flags(e) & _PAGE_PRESENT) && !needs_recalc(l1, e) )
> {
> set_recalc(l1, e);
> -p2m->write_p2m_entry(p2m, first_gfn, pent, e, level);
> +BUG_ON(p2m->write_p2m_entry(p2m, first_gfn, pent, e, level));
> }

Again here; theoretically, the only change has been that RECALC_FLAGS have been 
added.

And so on.

Thoughts?  (Looking for input from Jan here as well.)

If not, it seems like we should also be modifying the places in p2m-ept.c to do 
BUG_ON() rather than ASSERT()’ing that the page write succeeded.

 -George

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

Re: [Xen-devel] RT Xen on ARM - R-Car series

[Andrii Anisov]

On 15.02.19 19:13, Julien Grall wrote:

Not really... This is an implementation details that does not matter
on the OS side.

And on hypervisor side?


If you want accurate number, then the NOW() macro is not sufficient
enough. Read to CNTPCTL_EL0 can occur speculatively and out of order
relative to other instructions executed on the same PE. So the PE can
potentially execute CNTPCTL_EL0 before update_runstate_area(...).

You would want to add an isb() at least before NOW() and potentially
after (unless you have register dependency).
I have a patch for adding an isb()  in the NOW() macro. I will send it later 
on.Good hint.





   update_runstate_area(current);

+if (current->domain->domain_id == 1)
+printk("cp = %"PRI_stime"\n", NOW()-t);


That's only one number.  Did you do an average over multiple context
switch (say 1000) ?

No, just got them on the console to see the numbers. They seems to not change 
significantly during a minute run.
That's why I did not answer about context switches number.

I can do it in a bit more complicated way. But I do not expect I would 
encounter differences.

--
Sincerely,
Andrii Anisov.

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

Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Stefano Stabellini]

On Fri, 15 Feb 2019, George Dunlap wrote:
> > On Feb 13, 2019, at 7:11 PM, Stefano Stabellini  
> > wrote:
> > 
> > On Wed, 13 Feb 2019, Wei Liu wrote:
> >> On Tue, Feb 12, 2019 at 09:34:25PM -0500, Daniel P. Smith wrote:
> >>> Greetings,
> >>> 
> >>> On the 11/14/18 Xen x86 community call a discussion was initiated about
> >>> using Kconfig to build minimized versions of Xen for security, safety
> >>> and other certification requirements. After some offline discussions
> >>> with Xen contributors I realized that a variety of efforts each with
> >>> their own respective goals are underway,
> >>> 
> >>> - nested virtualization
> >>> - mixed criticality architectures
> >>> - reducing trusted componentary
> >>> - combining hardware protection of virtualization with performance and
> >>> ease-of-use of containers
> >>> 
> >>> These efforts use hypervisors in different roles, all which Xen is
> >>> capable of meeting. Today Xen's utility comes at the expense of carrying
> >>> features necessary for one role to be present in another role where it
> >>> is not required, e.g. PV interfaces that may not be essential in an ARM
> >>> mixed criticality deployment.
> >>> 
> >>> The initial focus will be to explore and document the range of possible
> >>> use cases that are of interest to the Xen community. This will be the
> >>> input to a design document that is crafted in conjunction with the Xen
> >>> maintainers, to identify possible approaches to extend the existing
> >>> Kconfig infrastructure to produce tailored instances of Xen.
> >>> 
> >>> If you are interested in participating in this effort, please reply to
> >>> this thread to outline possible use cases, design constraints and other
> >>> considerations for improving Xen's Kconfig infrastructure to support
> >>> tailoring for specific use cases.
> >>> 
> >> 
> >> My impression from the community call is that you want to provide
> >> smallish configurations for different use cases.
> >> 
> >> The Kconfig infrastructure is already able to do what you want as far as
> >> I can tell.  You can easily feed it a base config file -- see files
> >> under automation/configs/x86/.  What sort of extension is needed in your
> >> opinion?
> >> 
> >> As use case goes, it would be a good start if you just submit something
> >> you care about.
> > 
> > I mentioned on the call that a good first start could be a kconfig that
> > allows to build an hypervisor binary with only support for PVH and only
> > support for recent Intel machines, with the goal of minimizing the code
> > base to less than 100K LOC.
> 
> I think one thing that might be helpful is a sort of “feature document” for 
> each defconfig we’re looking at creating.  This would include:
> 
> * What the “target use case” for each defconfig would be
> * The end goal in terms of functionality / LoC / whatever
> * The current state, work items yet to do
> * What potential variations there are (i.e., how to enable shadow if you 
> want, or switch from Intel-only to AMD-only)
> 
> I’ve sort of been using docs/design/qemu-deprivilege.md in this way: Saying 
> where we want to go, and moving things from “to do” to “done” as they get 
> implemented.  That would make it easier to have in-progress things in the 
> tree, make it easier for people to collaborate / enhance defconfigs, and also 
> be a starting point for talking about testing and support status.

+1

Just to set the expectations right on this thread: I am just trying to
provide feedback from the field, things I know are important to the Xen
on x86 embedded user community. I am not going to take this on as a work
item.  But somebody else might? Daniel Smith, I am looking at you :-)___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Fwd: xen: credit2: credit2 can’t reach the throughput as expected

[Dario Faggioli]

[Hey, these email are still in HTML. Please check your mail program]

On Fri, 2019-02-15 at 06:15 +, zheng chuan wrote:
> Hi, Dario,
>
Hi,

> Here is the xentrace in credit2 with ratelimiting 1 ms and 30ms by
> observing 1 seconds both.
> 
Ok, thanks a lot for doing this! I'm doing my own experiments, but
slower than I wanted to, as I am also a little busy with other
things... so I really appreciate your efforts. :-)

> Roughly, we can see the frequency of the context switch.
> The context switch decreases significantly when the ratelimiting
> changes from 1ms to 30ms
> linux-EBkjWt:/home # cat credit2_r_1000.log | grep __enter_scheduler
> | wc -l
> 2407
> linux-EBkjWt:/home # cat credit2_r_3.log | grep __enter_scheduler
> | wc -l
> 714
> 
Well, sure, that's expected. It is, indeed, the intended effect of
having ratelimiting in the first place.

Now, can I ask you a favour? Can you rerun with:

 sched_credit2_migrate_resist=0

added to Xen's boot command line?

Not that I expect "miracles" (things might even get worse!), but
looking at the traces, I got curios of what kind of effect that could
have.

Also, for both the Credit1 and Credit2 cases, are you touching power
management(like with `xenpm`)?

> Since we also complement credit for sleeper vcpus to guarantee the
> fairness (also sched_latency of sleeper vcpus) once we trigger the
> reset_credit.
> it does not look like suitable for some workload such like the case
> in this issue, 
> Is that possible we try to do some punishment for the sleepers or
> complement credit in other policy to avoid too much preemption?
> 
You keep mentioning "sleepers" or "sleeping vcpus", but I don't
understand this part. A sleeping vcpu, even if it has the highest
credits, due to a reset, won't preempt any running vcpus.

It will (likely) preempt one when it wakes up, but that also happens on
Credit1  due to boosting (well, in theory... unless everyone is always
boosted, at which point things are hard to predict).

> We sacrifice throughput for the sched_latency by theory, However,
> what's interesting is that, as I said before, if I don't complement
> credit for sleepers
> or enlarge the ratelimiting, the sched_latency may not get worse
> If the vcpus runs staggeredly which spread into pCPUs when they are
> in idle at most of time due to the stable running pattern in my demo.
> 
But can we actually try to measure latency as well? Because it looks to
me that we're discussing while having only half of the picture
available.

Also, since you said you tried, can you show me (in code, I mean) what
you mean with "if I don't complement credit for sleepers", in order for
me to better understand what you mean with that?

Thanks again for you work and Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/


signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] RT Xen on ARM - R-Car series

[Andrii Anisov]

Hello Julien,

On 15.02.19 18:31, Julien Grall wrote:

Why? Is it because you want to be cache-aligned?  If so, requiring the
structure to be 64-bytes is not enough.


I did not mean caches.


You also want the address to
be 64-bytes aligned.


I would keep it as a hint for static/dynamic allocations in VMs, hoping the 
address would be normally 64 bytes aligned.
I hope it might be stronger than, only commenting it should not cross a page 
boundary. E.g. like `struct vcpu_register_vcpu_info` is commented.

I've got this idea after looking at runstate definition as per-cpu in Linux [1]


If an OS cares about it, then it can aligned itself here.

I suppose we can hint the OS by structure alignment in the interface header, 
and require it from OS verifying it on hypercall handling.

[1] https://elixir.bootlin.com/linux/v5.0-rc6/source/drivers/xen/time.c#L22

--
Sincerely,
Andrii Anisov.

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

Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Stefano Stabellini]

On Fri, 15 Feb 2019, Jan Beulich wrote:
> >>> On 14.02.19 at 19:32,  wrote:
> > Do you have any other suggestions about things that could be removed to
> > reach down to 100K LOC, in addition to what you have already written
> > above (Intel/AMD, shadow)?
> 
> If you mean ones we already have Kconfig options for, then you
> could drop TBOOT, which in turn drops CRYPTO, which together
> is about 3k LOC. Turning off XENOPROF would yield another 2k.
> I assume you've already restricted yourself to just the null
> scheduler? But that's about it, I think, without actual code (or at
> least Kconfig) changes.

I meant suggestions for things that could be disabled in the build, but
we don't have a kconfig option for it yet. Such as some of the
decompression algorithms (as Wei pointed out).

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 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 13 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

version targeted for testing:
 xen  365aabb6e5023cee476adf81106729efd49c644f
baseline version:
 xen  f178a00c30173c0b268d99160e19ad299b1823a2

Last test of basis   133263  2019-02-15 10:00:51 Z0 days
Testing same since   133264  2019-02-15 14:00:44 Z0 days1 attempts


People who touched revisions under test:
  Paul Durrant 
  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-i386 pass
 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
   f178a00c30..365aabb6e5  365aabb6e5023cee476adf81106729efd49c644f -> smoke

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

Re: [Xen-devel] RT Xen on ARM - R-Car series

[Julien Grall]

On Fri, Feb 15, 2019 at 12:30 PM Andrii Anisov  wrote:
>
> Hello Julien,

Hi,

> On 14.02.19 19:29, Julien Grall wrote:
> > I am not sure why you are speaking about the current implementation
> > when my point was about the new implementation.
> >
> > I guess your point stick even if we decide to use guest physical
> > address.
> For sure. The type of guest address used by hypervisor to reach runstate area 
> and having that area mapped are quite orthogonal questions. But, IMHO, 
> tightly coupled and might be solved together.

Not really... This is an implementation details that does not matter
on the OS side.

>
> > Although, I am still unconvinced of the benefits to keep it
> > mapped.
> My point was reducing context switch time, but those controversial numbers 
> left me confused.

You missed my point.  I don't say performance is not important but you
have to take into account the drawbacks.
I am not entirely happy to keep the runstate always mapped if it uses
more memory in Xen (vmap is quite limited)
and does not make significant improvement in the context switch time.

>
> >> I've measured the raw `update_runstate_area()` execution time. With 
> >> runstate mapped - its execution time is less than my timer tick (120ns), 
> >> with runstate not mapped - I've seen
> > its execution time as 4 to 8 ticks (480-960ns).
> >
> > Please provide the code you use to measure it. How often do you call it?
> The code to see that is as simple as following:
>
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 0a2e997..d673d00 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -314,8 +314,16 @@ static void schedule_tail(struct vcpu *prev)
>   context_saved(prev);
>
>   if ( prev != current )
> +{
> +s_time_t t = 0;
> +if (current->domain->domain_id == 1)
> +t = NOW();

If you want accurate number, then the NOW() macro is not sufficient
enough. Read to CNTPCTL_EL0 can occur speculatively and out of order
relative to other instructions executed on the same PE. So the PE can
potentially execute CNTPCTL_EL0 before update_runstate_area(...).

You would want to add an isb() at least before NOW() and potentially
after (unless you have register dependency).
I have a patch for adding an isb()  in the NOW() macro. I will send it later on.

Note that I have no idea whether the isb()s matter on the processors
you use. But it would be best to have it to make sure the numbers are
accurate.

>   update_runstate_area(current);
>
> +if (current->domain->domain_id == 1)
> +printk("cp = %"PRI_stime"\n", NOW()-t);

That's only one number.  Did you do an average over multiple context
switch (say 1000) ?

> +}
> +
>   /* Ensure that the vcpu has an up-to-date time base. */
>   update_vcpu_system_time(current);
>   }
>
> >> But using TBM, I encountered that making runstate mapped with Roger's 
> >> patch increases the IRQ latency from ~7000ns to ~7900ns. It is opposite to 
> >> my expectations and to the raw decrease of `runstate_update_area()` 
> >> execution time.
> >
> > Raw benchmarks should be taken with a grain of salt. The more if you
> > only benchmark a single function as the context switch may introduce
> > latency/cache eviction.
> >
> > Although, I would have expected the numbers to be the same. What is
> > your configuration here? Do you have others guests running? How many
> > context switch do you have?
>
> The configuration is the same as here [1].

Well, your e-mail contains multiple configuration. From my
understanding, TTBM will run exclusively on one CPU, so you will look
at context switch between idle vCPU and TTBM.
Do you trap wfi/wfe?

Also, you didn't answer to my last question regarding the number of
context switch. How long do you leave the test run?

Cheers,

-- 
Julien Grall

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

[Xen-devel] [linux-4.4 test] 133230: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-xsm  broken
 build-arm64-pvopsbroken

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot   fail pass in 133160
 test-amd64-i386-rumprun-i386 17 rumprun-demo-xenstorels/xenstorels.repeat fail 
pass in 133160
 test-amd64-i386-xl-qemuu-ovmf-amd64 16 guest-localmigrate/x10 fail pass in 
133160

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocatebroken baseline untested
 build-arm64-xsm   2 hosts-allocatebroken baseline untested
 build-arm64   2 hosts-allocatebroken baseline untested
 build-arm64   3 capture-logs  broken baseline untested
 build-arm64-pvops 3 capture-logs  broken baseline untested
 build-arm64-xsm   3 capture-logs  broken baseline untested
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail 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-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-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-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-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail 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 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail 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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-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  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop 

Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]

[Ian Jackson]

Lars Kurth writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 more 
messages]"):
> This is fine by me

Thanks, pushed now.

Ian.

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

Re: [Xen-devel] [PATCH] xen/pciback: Don't disable PCI_COMMAND on PCI device reset.

[Konrad Rzeszutek Wilk]

On Wed, Feb 13, 2019 at 06:21:31PM -0500, Prarit Bhargava wrote:
> From: Konrad Rzeszutek Wilk 
> 

+LKML
> This was submitted in 2015 here
> 
> https://marc.info/?l=linux-kernel&m=142807132515973&w=2
> 
> and has been included in Fedora builds ever since.  No issues have been
> reported with the patch.
> 
> P.
> 
> 8<
> 
> There is no need for this at all. Worst it means that if
> the guest tries to write to BARs it could lead (on certain
> platforms) to PCI SERR errors.
> 
> Please note that with af6fc858a35b90e89ea7a7ee58e66628c55c776b
> "xen-pciback: limit guest control of command register"
> a guest is still allowed to enable those control bits (safely), but
> is not allowed to disable them and that therefore a well behaved
> frontend which enables things before using them will still
> function correctly.
> 
> This is done via an write to the configuration register 0x4 which
> triggers on the backend side:
> command_write
>   \- pci_enable_device
>  \- pci_enable_device_flags
> \- do_pci_enable_device
>\- pcibios_enable_device
>   \-pci_enable_resourcess
> [which enables the PCI_COMMAND_MEMORY|PCI_COMMAND_IO]
> 
> However guests (and drivers) which don't do this could cause
> problems, including the security issues which XSA-120 sought
> to address.
> 
> Reported-by: Jan Beulich 
> Signed-off-by: Konrad Rzeszutek Wilk 
> Reviewed-by: Prarit Bhargava 
> Cc: Juergen Gross 
> ---
>  drivers/xen/xen-pciback/pciback_ops.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/xen/xen-pciback/pciback_ops.c 
> b/drivers/xen/xen-pciback/pciback_ops.c
> index ea4a08b83fa0..787966f44589 100644
> --- a/drivers/xen/xen-pciback/pciback_ops.c
> +++ b/drivers/xen/xen-pciback/pciback_ops.c
> @@ -127,8 +127,6 @@ void xen_pcibk_reset_device(struct pci_dev *dev)
>   if (pci_is_enabled(dev))
>   pci_disable_device(dev);
>  
> - pci_write_config_word(dev, PCI_COMMAND, 0);
> -
>   dev->is_busmaster = 0;
>   } else {
>   pci_read_config_word(dev, PCI_COMMAND, &cmd);
> -- 
> 2.18.1
> 

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

Re: [Xen-devel] Upstream Dom0 DRM problems regarding swiotlb

[Christoph Hellwig]

On Fri, Feb 15, 2019 at 11:07:22AM -0500, Michael Labriola wrote:
> > > But the latter text seems to agree with that.  So what is the actual
> > > problem that started this discussion?
> > >
> >
> > See https://lists.xen.org/archives/html/xen-devel/2019-02/threads.html#00818
> 
> I believe the actual problem is either:
> 
> 1) The radeon/amdgpu drivers are calling ttm_populate_and_map_pages()
> which *should* work on a Xen PV host, but doesn't and needs to be
> fixed.
> 
> or
> 
> 2) The radeon/amdgpu drivers are calling ttm_populate_and_map_pages()
> which *cannot* work in Xen, and they should go back to calling
> ttm_dma_populate() in that case.
> 
> I'm having a hard time figuring out which of those is correct.

I think the answer is neither 1 or 2 (or a bit of both).

ttm_populate_and_map_pages uses dma_map_page to map GPU memory,
and from what I can tell from your report potentially lots of it.

So this does "properly" use the DMA API for some amount of "properly".
The problem here is that ttm_populate_and_map_pages first allocates
memory and then maps it in a way where it bounce buffers a lot,
leading to a swiotlb buffer exaustion, as seen in your report.

ttm_dma_populate also sort of "properly" uses the DMA API in that it
uses the dma_alloc_coherent allocator.  The benefit of that allocator is
that is always returns addressable memory without exhausing the swiotlb
buffer.  The dowside of ttm_dma_populate / dma_alloc_coherent is that
on architectures where PCIe is not cache coherent it pointlessly
up other resources, as coherent DMA memory can be a very finite resource
there.

So for a short term fix forcing the dma_alloc_coherent route on
Xen/x86 is the right thing.  On Xen/arm and Xen/arm64 is might already
be problemeatic due to the explanation above unfortunately.

The real fix is to finally get broadly available non-coherent device
memory allocator into mainlaine and with ttm_populate_and_map_pages
to use it.  Note that for non-coherent devices it seems like
ttm_populate_and_map_pages also seems to miss proper ownership
management but that is another issue.

My proposal for such an allocator here:

   https://lwn.net/Articles/774429/

unfortunately doesn't seem to go anywhere as the DRM folks generally
seem to prefer bolting band-aid ontop of band-aid instead of actually
fixing such problems.

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

Re: [Xen-devel] RT Xen on ARM - R-Car series

[Julien Grall]

Hi,

On Fri, Feb 15, 2019 at 4:23 PM Andrii Anisov  wrote:
> On 14.02.19 18:29, Roger Pau Monné wrote:
> > In order to simplify stuff the new interface could require runstate
> > areas to be page aligned, but I think the check can be relaxed to
> > simply require runstate areas to not cross a page boundary.
>
> My idea so far is to keep the same `struct vcpu_runstate_info` but harden it 
> with `__attribute__((aligned(64)))` right in the interface file vcpu.h. Also 
> add some guard asserts verifying that its actual size is less than 64 bytes.

Why? Is it because you want to be cache-aligned?  If so, requiring the
structure to be 64-bytes is not enough. You also want the address to
be 64-bytes aligned.
However, I am not sure why we should bother with that in the
interface The cacheline varies between architectures and even SoC.
If an OS cares about it, then it can aligned itself here.

Cheers,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH 1/2] xen/gntdev: Do not destroy context while dma-bufs are in use

[Juergen Gross]

On 15/02/2019 16:35, Oleksandr Andrushchenko wrote:
> On 2/15/19 5:28 PM, Boris Ostrovsky wrote:
>> On 2/15/19 10:07 AM, Oleksandr Andrushchenko wrote:
>>> On 2/15/19 5:03 PM, Boris Ostrovsky wrote:
 On 2/14/19 9:23 AM, Oleksandr Andrushchenko wrote:
>      /* DMA buffer export support. */
> @@ -311,6 +317,7 @@ static void dmabuf_exp_release(struct kref *kref)
>      dmabuf_exp_wait_obj_signal(gntdev_dmabuf->priv,
> gntdev_dmabuf);
>    list_del(&gntdev_dmabuf->next);
> +    fput(gntdev_dmabuf->priv->filp);
>    kfree(gntdev_dmabuf);
>    }
>    @@ -423,6 +430,7 @@ static int dmabuf_exp_from_pages(struct
> gntdev_dmabuf_export_args *args)
>    mutex_lock(&args->dmabuf_priv->lock);
>    list_add(&gntdev_dmabuf->next, &args->dmabuf_priv->exp_list);
>    mutex_unlock(&args->dmabuf_priv->lock);
> +    get_file(gntdev_dmabuf->priv->filp);
 Not fget()?
>>> fget wants file descriptor [1] and returns struct file *,
>>> but we already have struct file*, so I use get_file [2]
>>> which does what I need - increments the reference counter
>>> on the file
>>
>> Reviewed-by: Boris Ostrovsky 
> Thank you,
> any chance we can get this for 5.1?
> 

Yes.


Juergen

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

Re: [Xen-devel] Upstream Dom0 DRM problems regarding swiotlb

[Konrad Rzeszutek Wilk]

On Fri, Feb 15, 2019 at 11:07:22AM -0500, Michael Labriola wrote:
> On Fri, Feb 15, 2019 at 12:57 AM Juergen Gross  wrote:
> >
> > On 14/02/2019 18:57, Christoph Hellwig wrote:
> > > On Thu, Feb 14, 2019 at 07:03:38AM +0100, Juergen Gross wrote:
> > >>> The thing which is different between Xen PV guests and most others (all
> > >>> others(?), now that Lguest and UML have been dropped) is that what Linux
> > >>> thinks of as PFN $N isn't necessarily adjacent to PFN $N+1 in system
> > >>> physical address space.
> > >>>
> > >>> Therefore, code which has a buffer spanning a page boundary can't just
> > >>> convert a pointer to the buffer into a physical address, and hand that
> > >>> address to a device.  You generally end up with either memory corruption
> > >>> (DMA hitting the wrong page allocated to the guest), or an IOMMU fault
> > >>> (DMA hitting a pages which isn't allocated to the guest).
> > >
> > > The Linux DMA API allows for dma_map_page / dma_map_single calls to
> > > spawn 4k boundaries.  If Xen doesn't support that it will have to bounce
> > > buffer for that case (and get horrible performance).
> > >
> > > But the latter text seems to agree with that.  So what is the actual
> > > problem that started this discussion?
> > >
> >
> > See https://lists.xen.org/archives/html/xen-devel/2019-02/threads.html#00818
> 
> I believe the actual problem is either:
> 
> 1) The radeon/amdgpu drivers are calling ttm_populate_and_map_pages()
> which *should* work on a Xen PV host, but doesn't and needs to be
> fixed.
> 
> or
> 
> 2) The radeon/amdgpu drivers are calling ttm_populate_and_map_pages()
> which *cannot* work in Xen, and they should go back to calling
> ttm_dma_populate() in that case.

The Nvidia one has this (correct):

1583 #if IS_ENABLED(CONFIG_SWIOTLB) && IS_ENABLED(CONFIG_X86)   
 
1584 if (swiotlb_nr_tbl()) {
 
1585 return ttm_dma_populate((void *)ttm, dev, ctx);
 
1586 }  
 
1587 #endif  

The Radeon has this - where now it adds 'need_swiotlb':

695 #ifdef CONFIG_SWIOTLB   

 696 if (rdev->need_swiotlb && swiotlb_nr_tbl()) {  
 
 697 return ttm_dma_populate(>t->ttm, rdev->dev, ctx);
 
 698 }  
 
 699 #endif   

The problem is fairly simple - the platform _requires_ to use
DMA API.

But the driver's have their own 'need_swiotlb' which ignores the platform
and sets it based on the device's DMA width:

  rdev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);

There should be an extra check to see if the platform requires
to use DMA API.

> 
> I'm having a hard time figuring out which of those is correct.
> 
> -- 
> Michael D Labriola
> 21 Rip Van Winkle Cir
> Warwick, RI 02886
> 401-316-9844 (cell)
> 401-848-8871 (work)
> 401-234-1306 (home)

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

[Xen-devel] [PATCH 2/3] xen-block: remove redundant assignment

[Paul Durrant]

The assignment to 'p' is unnecessary as the code will either goto 'invalid'
or p will get overwritten.

Spotted by Coverity: CID 1398638

Reported-by: Peter Maydell 
Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: Kevin Wolf 
Cc: Max Reitz 
---
 hw/block/xen-block.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
index 5012af9cb6..29afe2703a 100644
--- a/hw/block/xen-block.c
+++ b/hw/block/xen-block.c
@@ -413,8 +413,7 @@ static void xen_block_set_vdev(Object *obj, Visitor *v, 
const char *name,
 }
 
 if (*end == 'p') {
-p = (char *) ++end;
-if (*end == '\0') {
+if (*(++end) == '\0') {
 goto invalid;
 }
 }
-- 
2.20.1.2.gb21ebb6


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

[Xen-devel] [PATCH 0/3] Coverity fixes

[Paul Durrant]

Paul Durrant (3):
  dataplane/xen-block: remove dead code
  xen-block: remove redundant assignment
  xen-block: report error condition from vbd_name_to_disk()

 hw/block/dataplane/xen-block.c |  5 +
 hw/block/xen-block.c   | 24 
 2 files changed, 17 insertions(+), 12 deletions(-)
---
Cc: Anthony Perard 
Cc: Kevin Wolf 
Cc: Max Reitz 
Cc: Stefan Hajnoczi 
Cc: Stefano Stabellini 
-- 
2.20.1.2.gb21ebb6


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

[Xen-devel] [PATCH 1/3] dataplane/xen-block: remove dead code

[Paul Durrant]

The if() statement is clearly bogus (dead code which should have been
cleaned up when grant mapping was removed).

Spotted by Coverity: CID 1398635

While in the neighbourhood, add a missing 'fall through' annotation.

Reported-by: Peter Maydell 
Signed-off-by: Paul Durrant 
---
Cc: Stefan Hajnoczi 
Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: Kevin Wolf 
Cc: Max Reitz 
---
 hw/block/dataplane/xen-block.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-block.c
index c6a15da024..f1523c5b45 100644
--- a/hw/block/dataplane/xen-block.c
+++ b/hw/block/dataplane/xen-block.c
@@ -281,10 +281,6 @@ static void xen_block_complete_aio(void *opaque, int ret)
 break;
 case BLKIF_OP_WRITE:
 case BLKIF_OP_FLUSH_DISKCACHE:
-if (!request->req.nr_segments) {
-break;
-}
-break;
 default:
 break;
 }
@@ -298,6 +294,7 @@ static void xen_block_complete_aio(void *opaque, int ret)
 if (!request->req.nr_segments) {
 break;
 }
+/* fall through */
 case BLKIF_OP_READ:
 if (request->status == BLKIF_RSP_OKAY) {
 block_acct_done(blk_get_stats(dataplane->blk), &request->acct);
-- 
2.20.1.2.gb21ebb6


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

[Xen-devel] [PATCH 3/3] xen-block: report error condition from vbd_name_to_disk()

[Paul Durrant]

The function needs to make sure it is passed a valid disk name. This is
easily done by making sure that the parsing loop results in a non-zero
value.

Spotted by Coverity: CID 1398640

Reported-by: Peter Maydell 
Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: Kevin Wolf 
Cc: Max Reitz 
---
 hw/block/xen-block.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
index 29afe2703a..37a456c207 100644
--- a/hw/block/xen-block.c
+++ b/hw/block/xen-block.c
@@ -351,21 +351,28 @@ static void xen_block_get_vdev(Object *obj, Visitor *v, 
const char *name,
 g_free(str);
 }
 
-static unsigned int vbd_name_to_disk(const char *name, const char **endp)
+static int vbd_name_to_disk(const char *name, const char **endp,
+unsigned long *disk)
 {
-unsigned int disk = 0;
+unsigned int n = 0;
 
 while (*name != '\0') {
 if (!g_ascii_isalpha(*name) || !g_ascii_islower(*name)) {
 break;
 }
 
-disk *= 26;
-disk += *name++ - 'a' + 1;
+n *= 26;
+n += *name++ - 'a' + 1;
 }
 *endp = name;
 
-return disk - 1;
+if (!n) {
+return -1;
+}
+
+*disk = n - 1;
+
+return 0;
 }
 
 static void xen_block_set_vdev(Object *obj, Visitor *v, const char *name,
@@ -418,7 +425,9 @@ static void xen_block_set_vdev(Object *obj, Visitor *v, 
const char *name,
 }
 }
 } else {
-vdev->disk = vbd_name_to_disk(p, &end);
+if (vbd_name_to_disk(p, &end, &vdev->disk)) {
+goto invalid;
+}
 }
 
 if (*end != '\0') {
-- 
2.20.1.2.gb21ebb6


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

Re: [Xen-devel] Upstream Dom0 DRM problems regarding swiotlb

[Michael Labriola]

On Fri, Feb 15, 2019 at 12:57 AM Juergen Gross  wrote:
>
> On 14/02/2019 18:57, Christoph Hellwig wrote:
> > On Thu, Feb 14, 2019 at 07:03:38AM +0100, Juergen Gross wrote:
> >>> The thing which is different between Xen PV guests and most others (all
> >>> others(?), now that Lguest and UML have been dropped) is that what Linux
> >>> thinks of as PFN $N isn't necessarily adjacent to PFN $N+1 in system
> >>> physical address space.
> >>>
> >>> Therefore, code which has a buffer spanning a page boundary can't just
> >>> convert a pointer to the buffer into a physical address, and hand that
> >>> address to a device.  You generally end up with either memory corruption
> >>> (DMA hitting the wrong page allocated to the guest), or an IOMMU fault
> >>> (DMA hitting a pages which isn't allocated to the guest).
> >
> > The Linux DMA API allows for dma_map_page / dma_map_single calls to
> > spawn 4k boundaries.  If Xen doesn't support that it will have to bounce
> > buffer for that case (and get horrible performance).
> >
> > But the latter text seems to agree with that.  So what is the actual
> > problem that started this discussion?
> >
>
> See https://lists.xen.org/archives/html/xen-devel/2019-02/threads.html#00818

I believe the actual problem is either:

1) The radeon/amdgpu drivers are calling ttm_populate_and_map_pages()
which *should* work on a Xen PV host, but doesn't and needs to be
fixed.

or

2) The radeon/amdgpu drivers are calling ttm_populate_and_map_pages()
which *cannot* work in Xen, and they should go back to calling
ttm_dma_populate() in that case.

I'm having a hard time figuring out which of those is correct.

-- 
Michael D Labriola
21 Rip Van Winkle Cir
Warwick, RI 02886
401-316-9844 (cell)
401-848-8871 (work)
401-234-1306 (home)

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

Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]

[Lars Kurth]

On 15/02/2019, 15:40, "Ian Jackson"  wrote:

Lars Kurth writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 
more messages]"):
> as mentioned earlier, I think we need a legal/admin item for hardware and 
donations. See proposed addition below.
...
> LEGAL
> =

I would prefer not to bake the Linux Foundation address into this
document, nor to have it be the primary repository for legal details,
if that's OK.

How about this:

  LEGAL - XEN PROJECT
  ===

  The Xen Project Test Lab runs public tests, and provides access to its
  hardware to Xen community members so that they can debug the code.
  Accordingly there must not be any restrictions on publication of
  information such as test results, nor any restrictions on access to
  the hardware.  Ie, the Xen Project is not able to agree to any
  nondisclosure agreement (NDA).

  The Xen Project Test Lab does not accept hardware on loan.  We
  purchase it, or, following prior consultation and approval, can accept
  donations.  For donations, the Linux Foundation requires a letter
  confirming some legal details.  The Community Manager will provide
  a list of specific requirements for that `donation form' letter.

This is fine by me
Lars

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

[Xen-devel] [qemu-mainline test] 133228: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvopsbroken
 build-arm64-xsm  broken
 build-arm64  broken
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10 fail 
REGR. vs. 132847

Regressions which are regarded as allowable (not blocking):
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 132847
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 132847
 build-arm64   2 hosts-allocate broken REGR. vs. 132847

Tests which did not succeed, but are not blocking:
 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-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64   3 capture-logs  broken blocked in 132847
 build-arm64-xsm   3 capture-logs  broken blocked in 132847
 build-arm64-pvops 3 capture-logs  broken blocked in 132847
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 132847
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 132847
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 132847
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 132847
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 132847
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-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  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-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-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuu0b5e750bea635b167eb03d86c3d9a09bbd43bc06
baseline version:
 qemuua61faa3d02159d24d4fa984733dbc0c905508752

Last test of basis   132847  2019-02-04 13:19:31 Z   11 days
Failing since132945  2019-02-05 16:32:07 Z9 days5 attempts
Testing same since   133228  2019-02-13 11:13:26 Z2 days1 attempts


People who touched revisions under test:
  Alex Bennée 
  Andrey Shinkevich 
  Anthony PERARD 
  Brendan Shanks 
  Catherine Ho 
  Changpeng Liu 
  Chen Zhang 
  Cleber Rosa 
  Cornelia Huck 
  Daniel P. Berran

Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]

[Ian Jackson]

Lars Kurth writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 more 
messages]"):
> as mentioned earlier, I think we need a legal/admin item for hardware and 
> donations. See proposed addition below.
...
> LEGAL
> =

I would prefer not to bake the Linux Foundation address into this
document, nor to have it be the primary repository for legal details,
if that's OK.

How about this:

  LEGAL - XEN PROJECT
  ===

  The Xen Project Test Lab runs public tests, and provides access to its
  hardware to Xen community members so that they can debug the code.
  Accordingly there must not be any restrictions on publication of
  information such as test results, nor any restrictions on access to
  the hardware.  Ie, the Xen Project is not able to agree to any
  nondisclosure agreement (NDA).

  The Xen Project Test Lab does not accept hardware on loan.  We
  purchase it, or, following prior consultation and approval, can accept
  donations.  For donations, the Linux Foundation requires a letter
  confirming some legal details.  The Community Manager will provide
  a list of specific requirements for that `donation form' letter.

Ian.

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

[Xen-devel] [PATCH for-4.12 V5 1/2] altp2m: Prevent deadlocks when a domain performs altp2m operations on itself

[Razvan Cojocaru]

domain_pause_except_self() was introduced to allow a domain to pause
itself while doing altp2m operations.  However, as written, it has a
risk fo deadlock if two vcpus enter the loop at the same time.

Luckily, there's already a solution for this: Attempt to call domain's
hypercall_deadlock_mutex, and restart the entire hypercall if you
fail.

Make domain_pause_except_self() attempt to grab this mutex when
pausing itself, returning -ERESTART if it fails.  Have the callers
check for errors and pass the value up.  In both cases, the top-level
do_hvm_op() should DTRT when -ERESTART is returned.

The (necessary) reuse of the hypercall deadlock mutex poses the risk
of getting called from a context where the lock was already acquired
(e.g. someone may (say) call domctl_lock(), then afterwards call
domain_pause_except_self()). However, in the interest of not
overcomplicating things, no changes are made here to the mutex.
Attempted nesting of this lock isn't a security issue, because all
that will happen is that the vcpu will livelock taking continuations.

Signed-off-by: George Dunlap 
Tested-by: Razvan Cojocaru 
---
Release exception justification:
- Fixes a bug in the current code
- Lays the foundation of another fix
- Only affects altp2m, which isn't a supported feature

NB two possible further improvements to put on the list for 4.13:
 - Replace send-interrupt-and-wait-for-each-one loop with
   hvmop_flush_tlb_all()'s more efficient
   send-all-the-interrupts-then-wait loop.
 - Modify hvmop_flush_tlb_all() to use domain_pause_except_self() to
   avoid code duplication
---
CC: George Dunlap 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Wei Liu 
CC: "Roger Pau Monné" 
CC: George Dunlap 
CC: Ian Jackson 
CC: Julien Grall 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
---
 xen/arch/x86/mm/p2m.c   | 10 --
 xen/common/domain.c |  8 +++-
 xen/include/xen/sched.h |  2 +-
 3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index d14ce57..7232dbf 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2530,8 +2530,11 @@ int p2m_destroy_altp2m_by_id(struct domain *d, unsigned 
int idx)
 if ( !idx || idx >= MAX_ALTP2M )
 return rc;
 
-domain_pause_except_self(d);
+rc = domain_pause_except_self(d);
+if ( rc )
+return rc;
 
+rc = -EBUSY;
 altp2m_list_lock(d);
 
 if ( d->arch.altp2m_eptp[idx] != mfn_x(INVALID_MFN) )
@@ -2561,8 +2564,11 @@ int p2m_switch_domain_altp2m_by_id(struct domain *d, 
unsigned int idx)
 if ( idx >= MAX_ALTP2M )
 return rc;
 
-domain_pause_except_self(d);
+rc = domain_pause_except_self(d);
+if ( rc )
+return rc;
 
+rc = -EINVAL;
 altp2m_list_lock(d);
 
 if ( d->arch.altp2m_eptp[idx] != mfn_x(INVALID_MFN) )
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 7470cd9..32bca8d 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1134,18 +1134,24 @@ int domain_unpause_by_systemcontroller(struct domain *d)
 return 0;
 }
 
-void domain_pause_except_self(struct domain *d)
+int domain_pause_except_self(struct domain *d)
 {
 struct vcpu *v, *curr = current;
 
 if ( curr->domain == d )
 {
+/* Avoid racing with other vcpus which may want to be pausing us */
+if ( !spin_trylock(&d->hypercall_deadlock_mutex) )
+return -ERESTART;
 for_each_vcpu( d, v )
 if ( likely(v != curr) )
 vcpu_pause(v);
+spin_unlock(&d->hypercall_deadlock_mutex);
 }
 else
 domain_pause(d);
+
+return 0;
 }
 
 void domain_unpause_except_self(struct domain *d)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index d633e1d..edee52d 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -839,7 +839,7 @@ static inline int 
domain_pause_by_systemcontroller_nosync(struct domain *d)
 }
 
 /* domain_pause() but safe against trying to pause current. */
-void domain_pause_except_self(struct domain *d);
+int __must_check domain_pause_except_self(struct domain *d);
 void domain_unpause_except_self(struct domain *d);
 
 /*
-- 
2.7.4


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

[Xen-devel] [PATCH for-4.12 V5 2/2] x86/altp2m: fix HVMOP_altp2m_set_domain_state race

[Razvan Cojocaru]

HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
on purpose (as it was originally supposed to cater to a in-guest
agent, and a domain pausing itself is not a good idea).

This can lead to domain crashes in the vmx_vmexit_handler() code
that checks if the guest has the ability to switch EPTP without an
exit. That code can __vmread() the host p2m's EPT_POINTER
(before HVMOP_altp2m_set_domain_state "for_each_vcpu()" has a
chance to run altp2m_vcpu_initialise(), but after
d->arch.altp2m_active is set).

Signed-off-by: Razvan Cojocaru 

---
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Wei Liu 
CC: "Roger Pau Monné" 
---
 xen/arch/x86/hvm/hvm.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 410623d..79c7d81 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4538,6 +4538,10 @@ static int do_altp2m_op(
 break;
 }
 
+rc = domain_pause_except_self(d);
+if ( rc )
+break;
+
 ostate = d->arch.altp2m_active;
 d->arch.altp2m_active = !!a.u.domain_state.state;
 
@@ -4556,6 +4560,8 @@ static int do_altp2m_op(
 if ( ostate )
 p2m_flush_altp2m(d);
 }
+
+domain_unpause_except_self(d);
 break;
 }
 
-- 
2.7.4


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

Re: [Xen-devel] [PATCH 1/2] xen/gntdev: Do not destroy context while dma-bufs are in use

[Oleksandr Andrushchenko]

On 2/15/19 5:28 PM, Boris Ostrovsky wrote:

On 2/15/19 10:07 AM, Oleksandr Andrushchenko wrote:

On 2/15/19 5:03 PM, Boris Ostrovsky wrote:

On 2/14/19 9:23 AM, Oleksandr Andrushchenko wrote:

     /* DMA buffer export support. */
@@ -311,6 +317,7 @@ static void dmabuf_exp_release(struct kref *kref)
     dmabuf_exp_wait_obj_signal(gntdev_dmabuf->priv, gntdev_dmabuf);
   list_del(&gntdev_dmabuf->next);
+    fput(gntdev_dmabuf->priv->filp);
   kfree(gntdev_dmabuf);
   }
   @@ -423,6 +430,7 @@ static int dmabuf_exp_from_pages(struct
gntdev_dmabuf_export_args *args)
   mutex_lock(&args->dmabuf_priv->lock);
   list_add(&gntdev_dmabuf->next, &args->dmabuf_priv->exp_list);
   mutex_unlock(&args->dmabuf_priv->lock);
+    get_file(gntdev_dmabuf->priv->filp);

Not fget()?

fget wants file descriptor [1] and returns struct file *,
but we already have struct file*, so I use get_file [2]
which does what I need - increments the reference counter
on the file


Reviewed-by: Boris Ostrovsky 

Thank you,
any chance we can get this for 5.1?

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

Re: [Xen-devel] [PATCH 1/2] xen/gntdev: Do not destroy context while dma-bufs are in use

[Boris Ostrovsky]

On 2/15/19 10:07 AM, Oleksandr Andrushchenko wrote:
> On 2/15/19 5:03 PM, Boris Ostrovsky wrote:
>> On 2/14/19 9:23 AM, Oleksandr Andrushchenko wrote:
>>>     /* DMA buffer export support. */
>>> @@ -311,6 +317,7 @@ static void dmabuf_exp_release(struct kref *kref)
>>>     dmabuf_exp_wait_obj_signal(gntdev_dmabuf->priv, gntdev_dmabuf);
>>>   list_del(&gntdev_dmabuf->next);
>>> +    fput(gntdev_dmabuf->priv->filp);
>>>   kfree(gntdev_dmabuf);
>>>   }
>>>   @@ -423,6 +430,7 @@ static int dmabuf_exp_from_pages(struct
>>> gntdev_dmabuf_export_args *args)
>>>   mutex_lock(&args->dmabuf_priv->lock);
>>>   list_add(&gntdev_dmabuf->next, &args->dmabuf_priv->exp_list);
>>>   mutex_unlock(&args->dmabuf_priv->lock);
>>> +    get_file(gntdev_dmabuf->priv->filp);
>> Not fget()?
> fget wants file descriptor [1] and returns struct file *,
> but we already have struct file*, so I use get_file [2]
> which does what I need - increments the reference counter
> on the file


Reviewed-by: Boris Ostrovsky 

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

Re: [Xen-devel] [PATCH for-4.12 v3 3/8] amd/npt/shadow: replace assert that prevents creating 2M/1G MMIO entries

[Juergen Gross]

On 15/02/2019 15:18, Roger Pau Monne wrote:
> The assert was originally added to make sure that higher order
> regions (> PAGE_ORDER_4K) could not be used to bypass the
> mmio_ro_ranges check performed by p2m_type_to_flags.
> 
> This however is already checked in set_mmio_p2m_entry, which makes
> sure that higher order mappings don't overlap with mmio_ro_ranges,
> thus allowing the creation of high order MMIO mappings safely.
> 
> Replace the assert to allow 2M/1G entries to be created for MMIO
> regions and add some extra asserts as a replacement to make sure
> there's no overlapping with MMIO read-only ranges.
> 
> Note that 1G MMIO entries will not be created unless mmio_order is
> changed to allow it.
> 
> Signed-off-by: Roger Pau Monné 

Release-acked-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH for-4.12 v3 3/8] amd/npt/shadow: replace assert that prevents creating 2M/1G MMIO entries

[George Dunlap]

> On Feb 15, 2019, at 2:18 PM, Roger Pau Monne  wrote:
> 
> The assert was originally added to make sure that higher order
> regions (> PAGE_ORDER_4K) could not be used to bypass the
> mmio_ro_ranges check performed by p2m_type_to_flags.
> 
> This however is already checked in set_mmio_p2m_entry, which makes
> sure that higher order mappings don't overlap with mmio_ro_ranges,
> thus allowing the creation of high order MMIO mappings safely.
> 
> Replace the assert to allow 2M/1G entries to be created for MMIO
> regions and add some extra asserts as a replacement to make sure
> there's no overlapping with MMIO read-only ranges.
> 
> Note that 1G MMIO entries will not be created unless mmio_order is
> changed to allow it.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: George Dunlap 

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

Re: [Xen-devel] [PATCH 1/2] xen/gntdev: Do not destroy context while dma-bufs are in use

[Oleksandr Andrushchenko]

On 2/15/19 5:03 PM, Boris Ostrovsky wrote:

On 2/14/19 9:23 AM, Oleksandr Andrushchenko wrote:
  
  /* DMA buffer export support. */

@@ -311,6 +317,7 @@ static void dmabuf_exp_release(struct kref *kref)
  
  	dmabuf_exp_wait_obj_signal(gntdev_dmabuf->priv, gntdev_dmabuf);

list_del(&gntdev_dmabuf->next);
+   fput(gntdev_dmabuf->priv->filp);
kfree(gntdev_dmabuf);
  }
  
@@ -423,6 +430,7 @@ static int dmabuf_exp_from_pages(struct gntdev_dmabuf_export_args *args)

mutex_lock(&args->dmabuf_priv->lock);
list_add(&gntdev_dmabuf->next, &args->dmabuf_priv->exp_list);
mutex_unlock(&args->dmabuf_priv->lock);
+   get_file(gntdev_dmabuf->priv->filp);

Not fget()?

fget wants file descriptor [1] and returns struct file *,
but we already have struct file*, so I use get_file [2]
which does what I need - increments the reference counter
on the file


-boris


[1] 
https://elixir.bootlin.com/linux/v5.0-rc6/source/include/linux/file.h#L46

[2] https://elixir.bootlin.com/linux/v5.0-rc6/source/include/linux/fs.h#L949

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

Re: [Xen-devel] RT Xen on ARM - R-Car series

[Andrii Anisov]

Hello Roger,

On 14.02.19 18:29, Roger Pau Monné wrote:

I meant that with the current interface a user could change the
backing memory behind the virtual address passed in the runstate
register hypercall and expect Xen to write to the new physical memory
area without having to do anything else.

Attempting to do that with my proposed patch can result in hard to
debug guest memory corruption.


It's true.


OSes use atomic operations to update a PTE, so I'm not sure how that
could be problematic. Xen will either get the new or the old address
from the PTE, but never a half-written value.


I did mean using the old address, which I suppose might result in the same 
issues as you mentioned above.


In order to simplify stuff the new interface could require runstate
areas to be page aligned, but I think the check can be relaxed to
simply require runstate areas to not cross a page boundary.


My idea so far is to keep the same `struct vcpu_runstate_info` but harden it 
with `__attribute__((aligned(64)))` right in the interface file vcpu.h. Also 
add some guard asserts verifying that its actual size is less than 64 bytes.
Then, on the new initcall verify if it crosses the page boundary.

--
Sincerely,
Andrii Anisov.

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

Re: [Xen-devel] [PATCH 2/2] xen/gntdev: Check and release imported dma-bufs on close

[Boris Ostrovsky]

On 2/14/19 9:23 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
>
> Check if there are any imported dma-bufs left not released by
> user-space when grant device's release callback is called and
> free those if this is the case. This can happen if user-space
> leaks the buffers because of a bug or application has been
> terminated for any reason.
>
> Signed-off-by: Oleksandr Andrushchenko 

Reviewed-by: Boris ostrov...@oracle.com>



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

Re: [Xen-devel] [PATCH 1/2] xen/gntdev: Do not destroy context while dma-bufs are in use

[Boris Ostrovsky]

On 2/14/19 9:23 AM, Oleksandr Andrushchenko wrote:
>  
>  /* DMA buffer export support. */
> @@ -311,6 +317,7 @@ static void dmabuf_exp_release(struct kref *kref)
>  
>   dmabuf_exp_wait_obj_signal(gntdev_dmabuf->priv, gntdev_dmabuf);
>   list_del(&gntdev_dmabuf->next);
> + fput(gntdev_dmabuf->priv->filp);
>   kfree(gntdev_dmabuf);
>  }
>  
> @@ -423,6 +430,7 @@ static int dmabuf_exp_from_pages(struct 
> gntdev_dmabuf_export_args *args)
>   mutex_lock(&args->dmabuf_priv->lock);
>   list_add(&gntdev_dmabuf->next, &args->dmabuf_priv->exp_list);
>   mutex_unlock(&args->dmabuf_priv->lock);
> + get_file(gntdev_dmabuf->priv->filp);

Not fget()?

-boris



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

[Xen-devel] [PATCH for-4.12 v3 1/8] dom0/pvh: align allocation and mapping order to start address

[Roger Pau Monne]

The p2m and iommu mapping code always had the requirement that
addresses and orders must be aligned when populating the p2m or the
iommu page tables.

PVH dom0 builder didn't take this requirement into account, and can
call into the p2m/iommu mapping helpers with addresses and orders that
are not aligned.

Fix this by making sure the orders passed to the physmap population
helpers are always aligned to the guest address to be populated.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Wei Liu 
Reviewed-by: Jan Beulich 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
---
Without this patch trying to create a PVH dom0 will trigger an assert
on certain hardware depending on the memory map.
---
Changes since v1:
 - Reword commit message.
---
 xen/arch/x86/hvm/dom0_build.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 51cf490811..a571d15c13 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -152,6 +152,8 @@ static int __init pvh_populate_memory_range(struct domain 
*d,
 
 order = get_order_from_pages(end - start + 1);
 order = min(order ? order - 1 : 0, max_order);
+/* The order allocated and populated must be aligned to the address. */
+order = min(order, start ? find_first_set_bit(start) : MAX_ORDER);
 page = alloc_domheap_pages(d, order, dom0_memflags | MEMF_no_scrub);
 if ( page == NULL )
 {
-- 
2.17.2 (Apple Git-113)


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

[Xen-devel] [PATCH for-4.12 v3 2/8] x86/pvh: reorder PVH dom0 iommu initialization

[Roger Pau Monne]

So that the iommu is initialized before populating the p2m, and
entries added get the corresponding iommu page table entries if
required. This requires splitting the current pvh_setup_p2m into two
different functions. One that crafts dom0 physmap and sets the paging
allocation, and another one that actually populates the p2m with RAM
regions.

Note that this allows to remove the special casing done for the low
1MB in hwdom_iommu_map.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Jan Beulich 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
---
Changes since v1:
 - New in this version.
---
The previous flow, where the iommu was enabled after having populated
the p2m was used to workaround an issue on an old pre-Haswell Intel
box. I no longer have that box, and when I tested PVH dom0 on it was
before the iommu map-reserved fixes.

If hardware needing the iommu page tables to contain RAM regions is
found I'm happy to work on other solutions, like performing the setup
of the iommu at the start of dom0_construct_pvh but only enabling it
when dom0 p2m is fully populated.
---
 xen/arch/x86/hvm/dom0_build.c   | 35 +++--
 xen/drivers/passthrough/x86/iommu.c |  7 +-
 2 files changed, 24 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index a571d15c13..aa599f09ef 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -409,14 +409,10 @@ static __init void pvh_setup_e820(struct domain *d, 
unsigned long nr_pages)
 ASSERT(cur_pages == nr_pages);
 }
 
-static int __init pvh_setup_p2m(struct domain *d)
+static void __init pvh_init_p2m(struct domain *d)
 {
-struct vcpu *v = d->vcpu[0];
 unsigned long nr_pages = dom0_compute_nr_pages(d, NULL, 0);
-unsigned int i;
-int rc;
 bool preempted;
-#define MB1_PAGES PFN_DOWN(MB(1))
 
 pvh_setup_e820(d, nr_pages);
 do {
@@ -425,6 +421,14 @@ static int __init pvh_setup_p2m(struct domain *d)
   &preempted);
 process_pending_softirqs();
 } while ( preempted );
+}
+
+static int __init pvh_populate_p2m(struct domain *d)
+{
+struct vcpu *v = d->vcpu[0];
+unsigned int i;
+int rc;
+#define MB1_PAGES PFN_DOWN(MB(1))
 
 /*
  * Memory below 1MB is identity mapped initially. RAM regions are
@@ -1134,13 +1138,6 @@ int __init dom0_construct_pvh(struct domain *d, const 
module_t *image,
 
 printk(XENLOG_INFO "*** Building a PVH Dom%d ***\n", d->domain_id);
 
-rc = pvh_setup_p2m(d);
-if ( rc )
-{
-printk("Failed to setup Dom0 physical memory map\n");
-return rc;
-}
-
 /*
  * NB: MMCFG initialization needs to be performed before iommu
  * initialization so the iommu code can fetch the MMCFG regions used by the
@@ -1148,8 +1145,22 @@ int __init dom0_construct_pvh(struct domain *d, const 
module_t *image,
  */
 pvh_setup_mmcfg(d);
 
+/*
+ * Craft dom0 physical memory map and set the paging allocation. This must
+ * be done before the iommu initializion, since iommu initialization code
+ * will likely add mappings required by devices to the p2m (ie: RMRRs).
+ */
+pvh_init_p2m(d);
+
 iommu_hwdom_init(d);
 
+rc = pvh_populate_p2m(d);
+if ( rc )
+{
+printk("Failed to setup Dom0 physical memory map\n");
+return rc;
+}
+
 rc = pvh_load_kernel(d, image, image_headroom, initrd, 
bootstrap_map(image),
  cmdline, &entry, &start_info);
 if ( rc )
diff --git a/xen/drivers/passthrough/x86/iommu.c 
b/xen/drivers/passthrough/x86/iommu.c
index a88ef9b189..42b1a1bbc3 100644
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -151,12 +151,7 @@ static bool __hwdom_init hwdom_iommu_map(const struct 
domain *d,
  * inclusive mapping additionally maps in every pfn up to 4GB except those
  * that fall in unusable ranges for PV Dom0.
  */
-if ( (pfn > max_pfn && !mfn_valid(mfn)) || xen_in_range(pfn) ||
- /*
-  * Ignore any address below 1MB, that's already identity mapped by the
-  * Dom0 builder for HVM.
-  */
- (!d->domain_id && is_hvm_domain(d) && pfn < PFN_DOWN(MB(1))) )
+if ( (pfn > max_pfn && !mfn_valid(mfn)) || xen_in_range(pfn) )
 return false;
 
 switch ( type = page_get_ram_type(mfn) )
-- 
2.17.2 (Apple Git-113)


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

Re: [Xen-devel] [PATCH for-4.12 v3 3/8] amd/npt/shadow: replace assert that prevents creating 2M/1G MMIO entries

[Jan Beulich]

>>> On 15.02.19 at 15:18,  wrote:
> The assert was originally added to make sure that higher order
> regions (> PAGE_ORDER_4K) could not be used to bypass the
> mmio_ro_ranges check performed by p2m_type_to_flags.
> 
> This however is already checked in set_mmio_p2m_entry, which makes
> sure that higher order mappings don't overlap with mmio_ro_ranges,
> thus allowing the creation of high order MMIO mappings safely.
> 
> Replace the assert to allow 2M/1G entries to be created for MMIO
> regions and add some extra asserts as a replacement to make sure
> there's no overlapping with MMIO read-only ranges.
> 
> Note that 1G MMIO entries will not be created unless mmio_order is
> changed to allow it.
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH for-4.12 v3 2/8] x86/pvh: reorder PVH dom0 iommu initialization

[Juergen Gross]

On 15/02/2019 15:18, Roger Pau Monne wrote:
> So that the iommu is initialized before populating the p2m, and
> entries added get the corresponding iommu page table entries if
> required. This requires splitting the current pvh_setup_p2m into two
> different functions. One that crafts dom0 physmap and sets the paging
> allocation, and another one that actually populates the p2m with RAM
> regions.
> 
> Note that this allows to remove the special casing done for the low
> 1MB in hwdom_iommu_map.
> 
> Signed-off-by: Roger Pau Monné 
> Reviewed-by: Jan Beulich 

Release-acked-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH for-4.12 v3 1/8] dom0/pvh: align allocation and mapping order to start address

[Juergen Gross]

On 15/02/2019 15:18, Roger Pau Monne wrote:
> The p2m and iommu mapping code always had the requirement that
> addresses and orders must be aligned when populating the p2m or the
> iommu page tables.
> 
> PVH dom0 builder didn't take this requirement into account, and can
> call into the p2m/iommu mapping helpers with addresses and orders that
> are not aligned.
> 
> Fix this by making sure the orders passed to the physmap population
> helpers are always aligned to the guest address to be populated.
> 
> Signed-off-by: Roger Pau Monné 
> Reviewed-by: Wei Liu 
> Reviewed-by: Jan Beulich 

Release-acked-by: Juergen Gross 


Juergen

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

[Xen-devel] [PATCH v3 7/8] x86/mm: handle foreign mappings in p2m_entry_modify

[Roger Pau Monne]

So that the specific handling can be removed from
atomic_write_ept_entry and be shared with npt and shadow code.

This commit also removes the check that prevent non-ept PVH dom0 from
mapping foreign pages.

Signed-off-by: Roger Pau Monné 
---
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: Tim Deegan 
---
Changes since v2:
 - Return an error code from p2m_entry_modify and propagate it to the
   callers.

Changes since v1:
 - Simply code since mfn_to_page cannot return NULL.
 - Check if the mfn is valid before getting/dropping the page reference.
 - Use BUG_ON instead of ASSERTs, since getting the reference counting
   wrong is more dangerous than a DoS.
---
 xen/arch/x86/mm/hap/hap.c   | 12 +--
 xen/arch/x86/mm/p2m-ept.c   | 56 +++--
 xen/arch/x86/mm/p2m-pt.c|  7 -
 xen/arch/x86/mm/shadow/common.c |  3 +-
 xen/include/asm-x86/p2m.h   | 26 ---
 5 files changed, 39 insertions(+), 65 deletions(-)

diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 5b507376bc..2daf8424f6 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -714,6 +714,7 @@ hap_write_p2m_entry(struct domain *d, unsigned long gfn, 
l1_pgentry_t *p,
 {
 uint32_t old_flags;
 bool_t flush_nestedp2m = 0;
+int rc;
 
 /* We know always use the host p2m here, regardless if the vcpu
  * is in host or guest mode. The vcpu can be in guest mode by
@@ -734,8 +735,15 @@ hap_write_p2m_entry(struct domain *d, unsigned long gfn, 
l1_pgentry_t *p,
 && perms_strictly_increased(old_flags, l1e_get_flags(new)) );
 }
 
-p2m_entry_modify(p2m_get_hostp2m(d), p2m_flags_to_type(l1e_get_flags(new)),
- p2m_flags_to_type(old_flags), level);
+rc = p2m_entry_modify(p2m_get_hostp2m(d),
+  p2m_flags_to_type(l1e_get_flags(new)),
+  p2m_flags_to_type(old_flags), l1e_get_mfn(new),
+  l1e_get_mfn(*p), level);
+if ( rc )
+{
+paging_unlock(d);
+return rc;
+}
 
 safe_write_pte(p, new);
 if ( old_flags & _PAGE_PRESENT )
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 0ece6608cb..83bd602fc4 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -45,65 +45,19 @@ static inline bool_t is_epte_valid(ept_entry_t *e)
 return ((e->epte & ~(1ul << 63)) != 0 && e->sa_p2mt != p2m_invalid);
 }
 
-/* returns : 0 for success, -errno otherwise */
 static int atomic_write_ept_entry(struct p2m_domain *p2m,
   ept_entry_t *entryptr, ept_entry_t new,
   int level)
 {
-int rc;
-unsigned long oldmfn = mfn_x(INVALID_MFN);
-bool_t check_foreign = (new.mfn != entryptr->mfn ||
-new.sa_p2mt != entryptr->sa_p2mt);
-
-if ( level )
-{
-ASSERT(!is_epte_superpage(&new) || !p2m_is_foreign(new.sa_p2mt));
-write_atomic(&entryptr->epte, new.epte);
-return 0;
-}
-
-if ( unlikely(p2m_is_foreign(new.sa_p2mt)) )
-{
-rc = -EINVAL;
-if ( !is_epte_present(&new) )
-goto out;
-
-if ( check_foreign )
-{
-struct domain *fdom;
-
-if ( !mfn_valid(_mfn(new.mfn)) )
-goto out;
-
-rc = -ESRCH;
-fdom = page_get_owner(mfn_to_page(_mfn(new.mfn)));
-if ( fdom == NULL )
-goto out;
+int rc = p2m_entry_modify(p2m, new.sa_p2mt, entryptr->sa_p2mt,
+  _mfn(new.mfn), _mfn(entryptr->mfn), level);
 
-/* get refcount on the page */
-rc = -EBUSY;
-if ( !get_page(mfn_to_page(_mfn(new.mfn)), fdom) )
-goto out;
-}
-}
-
-if ( unlikely(p2m_is_foreign(entryptr->sa_p2mt)) && check_foreign )
-oldmfn = entryptr->mfn;
-
-p2m_entry_modify(p2m, new.sa_p2mt, entryptr->sa_p2mt, level);
+if ( rc )
+return rc;
 
 write_atomic(&entryptr->epte, new.epte);
 
-if ( unlikely(oldmfn != mfn_x(INVALID_MFN)) )
-put_page(mfn_to_page(_mfn(oldmfn)));
-
-rc = 0;
-
- out:
-if ( rc )
-gdprintk(XENLOG_ERR, "epte o:%"PRIx64" n:%"PRIx64" rc:%d\n",
- entryptr->epte, new.epte, rc);
-return rc;
+return 0;
 }
 
 static void ept_p2m_type_to_flags(struct p2m_domain *p2m, ept_entry_t *entry,
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index 44abd65999..8902c4c9ab 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -540,13 +540,6 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, mfn_t 
mfn,
 __trace_var(TRC_MEM_SET_P2M_ENTRY, 0, sizeof(t), &t);
 }
 
-if ( unlikely(p2m_is_foreign(p2mt)) )
-{
-/* hvm fixme: foreign types are only supported on ept at present */
-gdprintk(X

[Xen-devel] [PATCH for-4.12 v3 4/8] pvh/dom0: warn when dom0_mem is not set

[Roger Pau Monne]

There have been several reports of the dom0 builder running out of
memory when building a PVH dom0 without having specified a dom0_mem
value. Print a warning message if dom0_mem is not set when booting in
PVH mode.

This is a temporary workaround until accounting for internal memory
required by Xen (ie: paging structures) is improved.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: Juergen Gross 
---
Without this patch creating a PVH dom0 without a dom0_mem parameter
can result in the dom0 builder running out of memory thus leading to a
Xen crash. The added message gives a hit to the user about a possible
fix.
---
Changes since v2:
 - Print message only once.

Changes since v1:
 - Rewrite the warning message.
 - Check nr_pages in order to figure out if the amount of dom0 memory
   has been set.
---
 xen/arch/x86/dom0_build.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 2b4d9e9ea6..6ebe36766b 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -378,8 +378,18 @@ unsigned long __init dom0_compute_nr_pages(
  * maximum of 128MB.
  */
 if ( !nr_pages )
+{
 nr_pages = avail - (pv_shim ? pv_shim_mem(avail)
  : min(avail / 16, 128UL << (20 - 
PAGE_SHIFT)));
+if ( is_hvm_domain(d) && !need_paging )
+/*
+ * Temporary workaround message until internal (paging) memory
+ * accounting required to build a pvh dom0 is improved.
+ */
+printk("WARNING: PVH dom0 without dom0_mem set is still 
unstable. "
+   "If you get crashes during boot, try adding a dom0_mem 
parameter\n");
+}
+
 
 /* Clamp according to min/max limits and available memory. */
 nr_pages = max(nr_pages, min_pages);
-- 
2.17.2 (Apple Git-113)


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

[Xen-devel] [PATCH for-4.12 v3 0/8] pvh/dom0/shadow/amd fixes

[Roger Pau Monne]

Hello,

The following series contains fixes that should be considered for 4.12.

I'm not sure whether patches 5, 6, 7 and 8 should be aimed at 4.12, they
contain changes to the p2m code that could affect HVM guests. Note that
without those changes a PVH dom0 running on AMD hardware will be unable
to create guests. Overall the patches are a nice cleanup to the handling
of p2m_ioreq_server and p2m_map_foreign types IMO.

The series can also be found at:

git://xenbits.xen.org/people/royger/xen.git fixes-4.12-v3

Roger Pau Monne (8):
  dom0/pvh: align allocation and mapping order to start address
  x86/pvh: reorder PVH dom0 iommu initialization
  amd/npt/shadow: replace assert that prevents creating 2M/1G MMIO
entries
  pvh/dom0: warn when dom0_mem is not set
  x86/mm: split p2m ioreq server pages special handling into helper
  p2m: change write_p2m_entry to return an error code
  x86/mm: handle foreign mappings in p2m_entry_modify
  npt/shadow: allow getting foreign page table entries

 xen/arch/x86/dom0_build.c   |  10 +++
 xen/arch/x86/hvm/dom0_build.c   |  37 ++
 xen/arch/x86/mm/hap/hap.c   |  15 +++-
 xen/arch/x86/mm/hap/nested_hap.c|   4 +-
 xen/arch/x86/mm/p2m-ept.c   | 107 ++--
 xen/arch/x86/mm/p2m-pt.c|  88 ++-
 xen/arch/x86/mm/paging.c|  12 ++--
 xen/arch/x86/mm/shadow/common.c |   8 ++-
 xen/arch/x86/mm/shadow/none.c   |   7 +-
 xen/arch/x86/mm/shadow/private.h|   6 +-
 xen/drivers/passthrough/x86/iommu.c |   7 +-
 xen/include/asm-x86/p2m.h   |  54 +-
 xen/include/asm-x86/paging.h|   8 +--
 13 files changed, 191 insertions(+), 172 deletions(-)

-- 
2.17.2 (Apple Git-113)


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

Re: [Xen-devel] [PATCH for-4.12 v3 4/8] pvh/dom0: warn when dom0_mem is not set

[Jan Beulich]

>>> On 15.02.19 at 15:18,  wrote:
> There have been several reports of the dom0 builder running out of
> memory when building a PVH dom0 without having specified a dom0_mem
> value. Print a warning message if dom0_mem is not set when booting in
> PVH mode.
> 
> This is a temporary workaround until accounting for internal memory
> required by Xen (ie: paging structures) is improved.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Jan Beulich 

Btw, it looks as if you did Cc Jürgen here and on patch 3, but not
on the first two.

Jan


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

Re: [Xen-devel] XEN on R-CAR H3

[Amit Tomer]

Hi,

> disk = [ 'phy:/dev/mmcblk1p1,xvda1' ]

Thanks , this worked for us and we can now boot Linux guest in domU.

But now, while booting Android as domU guest , we don't get console
login for domU and it stuck
here:

[   10.597394] usbcore: registered new interface driver cdc_acm
[   10.597436] cdc_acm: USB Abstract Control Model driver for USB
modems and ISDN adapters
[   10.599829] file system registered
[   10.611942] kauditd_printk_skb: 6 callbacks suppressed
[   10.611947] audit: type=1400 audit(1550239280.843:17): avc:  denied
 { entrypoint } for  pid=864 comm="init" path="/system/bin/adbd"
dev="xvda1" ino=889 scontext=u:r:adbd:s0
tcontext=u:object_r:unlabeled:s0 tclass=file permissive=1
[   10.616842] audit: type=1400 audit(1550239280.847:18): avc:  denied
 { map } for  pid=864 comm="adbd" path="/system/bin/adbd" dev="xvda1"
ino=889 scontext=u:r:adbd:s0 tcontext=u:object_r:unlabeled:s0
tclass=file permissive=1
[   10.617012] audit: type=1400 audit(1550239280.851:19): avc:  denied
 { read execute } for  pid=864 comm="adbd" path="/system/bin/adbd"
dev="xvda1" ino=889 scontext=u:r:adbd:s0
tcontext=u:object_r:unlabeled:s0 tclass=file permissive=1
[   10.747628] random: adbd: uninitialized urandom read (40 bytes read)

Is there a special way to give hvc console login in Android , the way
we do it in Ubuntu is to create hvc0.conf file?

Thanks
- Amit

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

[Xen-devel] [PATCH for-4.12 v3 3/8] amd/npt/shadow: replace assert that prevents creating 2M/1G MMIO entries

[Roger Pau Monne]

The assert was originally added to make sure that higher order
regions (> PAGE_ORDER_4K) could not be used to bypass the
mmio_ro_ranges check performed by p2m_type_to_flags.

This however is already checked in set_mmio_p2m_entry, which makes
sure that higher order mappings don't overlap with mmio_ro_ranges,
thus allowing the creation of high order MMIO mappings safely.

Replace the assert to allow 2M/1G entries to be created for MMIO
regions and add some extra asserts as a replacement to make sure
there's no overlapping with MMIO read-only ranges.

Note that 1G MMIO entries will not be created unless mmio_order is
changed to allow it.

Signed-off-by: Roger Pau Monné 
---
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: Juergen Gross 
---
Without this patch trying to create a PVH dom0 will trigger an assert
on certain hardware depending on the memory map.
---
Changes since v2:
 - Unify checks into a helper function.

Changes since v1:
 - Fix subject.
 - Replace the assert with a suitable one.
---
 xen/arch/x86/mm/p2m-pt.c | 23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index 12f92cf1f0..52eaa24b18 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -479,6 +479,23 @@ int p2m_pt_handle_deferred_changes(uint64_t gpa)
 return rc;
 }
 
+/* Checks only applicable to entries with order > PAGE_ORDER_4K */
+static void check_entry(mfn_t mfn, p2m_type_t new, p2m_type_t old,
+unsigned int order)
+{
+ASSERT(order > PAGE_ORDER_4K);
+ASSERT(old != p2m_ioreq_server);
+if ( new == p2m_mmio_direct )
+ASSERT(!mfn_eq(mfn, INVALID_MFN) &&
+   !rangeset_overlaps_range(mmio_ro_ranges, mfn_x(mfn),
+mfn_x(mfn) + (1ul << order)));
+else if ( p2m_allows_invalid_mfn(new) || new == p2m_invalid ||
+  new == p2m_mmio_dm )
+ASSERT(mfn_valid(mfn) || mfn_eq(mfn, INVALID_MFN));
+else
+ASSERT(mfn_valid(mfn));
+}
+
 /* Returns: 0 for success, -errno for failure */
 static int
 p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, mfn_t mfn,
@@ -575,8 +592,7 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, mfn_t 
mfn,
 }
 }
 
-ASSERT(p2m_flags_to_type(flags) != p2m_ioreq_server);
-ASSERT(!mfn_valid(mfn) || p2mt != p2m_mmio_direct);
+check_entry(mfn, p2mt, p2m_flags_to_type(flags), page_order);
 l3e_content = mfn_valid(mfn) || p2m_allows_invalid_mfn(p2mt)
 ? p2m_l3e_from_pfn(mfn_x(mfn),
p2m_type_to_flags(p2m, p2mt, mfn, 2))
@@ -667,8 +683,7 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, mfn_t 
mfn,
 }
 }
 
-ASSERT(p2m_flags_to_type(flags) != p2m_ioreq_server);
-ASSERT(!mfn_valid(mfn) || p2mt != p2m_mmio_direct);
+check_entry(mfn, p2mt, p2m_flags_to_type(flags), page_order);
 l2e_content = mfn_valid(mfn) || p2m_allows_invalid_mfn(p2mt)
 ? p2m_l2e_from_pfn(mfn_x(mfn),
p2m_type_to_flags(p2m, p2mt, mfn, 1))
-- 
2.17.2 (Apple Git-113)


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

[Xen-devel] [PATCH v3 8/8] npt/shadow: allow getting foreign page table entries

[Roger Pau Monne]

Current npt and shadow code to get an entry will always return
INVALID_MFN for foreign entries. Allow to return the entry mfn for
foreign entries, like it's done for grant table entries.

Signed-off-by: Roger Pau Monné 
---
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
---
Changes since v2:
 - Use p2m_is_any_ram.
---
 xen/arch/x86/mm/p2m-pt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index 8902c4c9ab..e194b6854b 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -869,8 +869,8 @@ pod_retry_l1:
 *t = p2m_recalc_type(recalc || _needs_recalc(flags), l1t, p2m, gfn);
 unmap_domain_page(l1e);
 
-ASSERT(mfn_valid(mfn) || !p2m_is_ram(*t) || p2m_is_paging(*t));
-return (p2m_is_valid(*t) || p2m_is_grant(*t)) ? mfn : INVALID_MFN;
+ASSERT(mfn_valid(mfn) || !p2m_is_any_ram(*t) || p2m_is_paging(*t));
+return (p2m_is_valid(*t) || p2m_is_any_ram(*t)) ? mfn : INVALID_MFN;
 }
 
 static void p2m_pt_change_entry_type_global(struct p2m_domain *p2m,
-- 
2.17.2 (Apple Git-113)


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

[Xen-devel] [PATCH v3 5/8] x86/mm: split p2m ioreq server pages special handling into helper

[Roger Pau Monne]

So that it can be shared by both ept, npt and shadow code, instead of
duplicating it.

No change in functionality intended.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Paul Durrant 
---
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: Paul Durrant 
---
Changes since v1:
 - Remove unused p2mt_old from p2m_pt_set_entry.
---
 xen/arch/x86/mm/hap/hap.c   |  3 ++
 xen/arch/x86/mm/p2m-ept.c   | 55 +++--
 xen/arch/x86/mm/p2m-pt.c| 24 --
 xen/arch/x86/mm/shadow/common.c |  3 ++
 xen/include/asm-x86/p2m.h   | 32 +++
 5 files changed, 56 insertions(+), 61 deletions(-)

diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 3d651b94c3..dc46d5e14f 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -734,6 +734,9 @@ hap_write_p2m_entry(struct domain *d, unsigned long gfn, 
l1_pgentry_t *p,
 && perms_strictly_increased(old_flags, l1e_get_flags(new)) );
 }
 
+p2m_entry_modify(p2m_get_hostp2m(d), p2m_flags_to_type(l1e_get_flags(new)),
+ p2m_flags_to_type(old_flags), level);
+
 safe_write_pte(p, new);
 if ( old_flags & _PAGE_PRESENT )
 flush_tlb_mask(d->dirty_cpumask);
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index bb562607f7..0ece6608cb 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -46,7 +46,8 @@ static inline bool_t is_epte_valid(ept_entry_t *e)
 }
 
 /* returns : 0 for success, -errno otherwise */
-static int atomic_write_ept_entry(ept_entry_t *entryptr, ept_entry_t new,
+static int atomic_write_ept_entry(struct p2m_domain *p2m,
+  ept_entry_t *entryptr, ept_entry_t new,
   int level)
 {
 int rc;
@@ -89,6 +90,8 @@ static int atomic_write_ept_entry(ept_entry_t *entryptr, 
ept_entry_t new,
 if ( unlikely(p2m_is_foreign(entryptr->sa_p2mt)) && check_foreign )
 oldmfn = entryptr->mfn;
 
+p2m_entry_modify(p2m, new.sa_p2mt, entryptr->sa_p2mt, level);
+
 write_atomic(&entryptr->epte, new.epte);
 
 if ( unlikely(oldmfn != mfn_x(INVALID_MFN)) )
@@ -390,7 +393,8 @@ static int ept_next_level(struct p2m_domain *p2m, bool_t 
read_only,
  * present entries in the given page table, optionally marking the entries
  * also for their subtrees needing P2M type re-calculation.
  */
-static bool_t ept_invalidate_emt(mfn_t mfn, bool_t recalc, int level)
+static bool_t ept_invalidate_emt(struct p2m_domain *p2m, mfn_t mfn,
+ bool_t recalc, int level)
 {
 int rc;
 ept_entry_t *epte = map_domain_page(mfn);
@@ -408,7 +412,7 @@ static bool_t ept_invalidate_emt(mfn_t mfn, bool_t recalc, 
int level)
 e.emt = MTRR_NUM_TYPES;
 if ( recalc )
 e.recalc = 1;
-rc = atomic_write_ept_entry(&epte[i], e, level);
+rc = atomic_write_ept_entry(p2m, &epte[i], e, level);
 ASSERT(rc == 0);
 changed = 1;
 }
@@ -459,7 +463,7 @@ static int ept_invalidate_emt_range(struct p2m_domain *p2m,
 rc = -ENOMEM;
 goto out;
 }
-wrc = atomic_write_ept_entry(&table[index], split_ept_entry, i);
+wrc = atomic_write_ept_entry(p2m, &table[index], split_ept_entry, i);
 ASSERT(wrc == 0);
 
 for ( ; i > target; --i )
@@ -479,7 +483,7 @@ static int ept_invalidate_emt_range(struct p2m_domain *p2m,
 {
 e.emt = MTRR_NUM_TYPES;
 e.recalc = 1;
-wrc = atomic_write_ept_entry(&table[index], e, target);
+wrc = atomic_write_ept_entry(p2m, &table[index], e, target);
 ASSERT(wrc == 0);
 rc = 1;
 }
@@ -549,17 +553,11 @@ static int resolve_misconfig(struct p2m_domain *p2m, 
unsigned long gfn)
 nt = p2m_recalc_type(e.recalc, e.sa_p2mt, p2m, gfn + i);
 if ( nt != e.sa_p2mt )
 {
-if ( e.sa_p2mt == p2m_ioreq_server )
-{
-ASSERT(p2m->ioreq.entry_count > 0);
-p2m->ioreq.entry_count--;
-}
-
 e.sa_p2mt = nt;
 ept_p2m_type_to_flags(p2m, &e, e.sa_p2mt, e.access);
 }
 e.recalc = 0;
-wrc = atomic_write_ept_entry(&epte[i], e, level);
+wrc = atomic_write_ept_entry(p2m, &epte[i], e, level);
 ASSERT(wrc == 0);
 }
 }
@@ -595,7 +593,7 @@ static int resolve_misconfig(struct p2m_domain *p2m, 
unsigned long gfn)
 {
 if ( ept_split_super_page(p2m, &e, level, level - 1) )
 {
-wrc = atomic_write_ept_entry(&epte[i], e, level);
+wrc = atomic_write_e

[Xen-devel] [PATCH v3 6/8] p2m: change write_p2m_entry to return an error code

[Roger Pau Monne]

This is in preparation for also changing p2m_entry_modify to return an
error code.

No functional change intended.

Signed-off-by: Roger Pau Monné 
---
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: Tim Deegan 
---
Changes since v2:
 - New in this version.
---
 xen/arch/x86/mm/hap/hap.c|  4 +++-
 xen/arch/x86/mm/hap/nested_hap.c |  4 +++-
 xen/arch/x86/mm/p2m-pt.c | 30 ++
 xen/arch/x86/mm/paging.c | 12 
 xen/arch/x86/mm/shadow/common.c  |  4 +++-
 xen/arch/x86/mm/shadow/none.c|  7 ---
 xen/arch/x86/mm/shadow/private.h |  6 +++---
 xen/include/asm-x86/p2m.h|  4 ++--
 xen/include/asm-x86/paging.h |  8 
 9 files changed, 48 insertions(+), 31 deletions(-)

diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index dc46d5e14f..5b507376bc 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -708,7 +708,7 @@ static void hap_update_paging_modes(struct vcpu *v)
 put_gfn(d, cr3_gfn);
 }
 
-static void
+static int
 hap_write_p2m_entry(struct domain *d, unsigned long gfn, l1_pgentry_t *p,
 l1_pgentry_t new, unsigned int level)
 {
@@ -745,6 +745,8 @@ hap_write_p2m_entry(struct domain *d, unsigned long gfn, 
l1_pgentry_t *p,
 
 if ( flush_nestedp2m )
 p2m_flush_nestedp2m(d);
+
+return 0;
 }
 
 static unsigned long hap_gva_to_gfn_real_mode(
diff --git a/xen/arch/x86/mm/hap/nested_hap.c b/xen/arch/x86/mm/hap/nested_hap.c
index d2a07a5c79..abe5958a52 100644
--- a/xen/arch/x86/mm/hap/nested_hap.c
+++ b/xen/arch/x86/mm/hap/nested_hap.c
@@ -71,7 +71,7 @@
 /*NESTED VIRT P2M FUNCTIONS */
 //
 
-void
+int
 nestedp2m_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn,
 l1_pgentry_t *p, l1_pgentry_t new, unsigned int level)
 {
@@ -87,6 +87,8 @@ nestedp2m_write_p2m_entry(struct p2m_domain *p2m, unsigned 
long gfn,
 flush_tlb_mask(p2m->dirty_cpumask);
 
 paging_unlock(d);
+
+return 0;
 }
 
 //
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index 04e9d81cf6..44abd65999 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -202,7 +202,7 @@ p2m_next_level(struct p2m_domain *p2m, void **table,
 new_entry = l1e_from_mfn(mfn, P2M_BASE_FLAGS | _PAGE_RW);
 
 p2m_add_iommu_flags(&new_entry, level, 
IOMMUF_readable|IOMMUF_writable);
-p2m->write_p2m_entry(p2m, gfn, p2m_entry, new_entry, level + 1);
+BUG_ON(p2m->write_p2m_entry(p2m, gfn, p2m_entry, new_entry, level + 
1));
 }
 else if ( flags & _PAGE_PSE )
 {
@@ -250,14 +250,14 @@ p2m_next_level(struct p2m_domain *p2m, void **table,
 {
 new_entry = l1e_from_pfn(pfn | (i << ((level - 1) * 
PAGETABLE_ORDER)),
  flags);
-p2m->write_p2m_entry(p2m, gfn, l1_entry + i, new_entry, level);
+BUG_ON(p2m->write_p2m_entry(p2m, gfn, l1_entry + i, new_entry, 
level));
 }
 
 unmap_domain_page(l1_entry);
 
 new_entry = l1e_from_mfn(mfn, P2M_BASE_FLAGS | _PAGE_RW);
 p2m_add_iommu_flags(&new_entry, level, 
IOMMUF_readable|IOMMUF_writable);
-p2m->write_p2m_entry(p2m, gfn, p2m_entry, new_entry, level + 1);
+BUG_ON(p2m->write_p2m_entry(p2m, gfn, p2m_entry, new_entry, level + 
1));
 }
 else
 ASSERT(flags & _PAGE_PRESENT);
@@ -321,7 +321,7 @@ static int p2m_pt_set_recalc_range(struct p2m_domain *p2m,
 if ( (l1e_get_flags(e) & _PAGE_PRESENT) && !needs_recalc(l1, e) )
 {
 set_recalc(l1, e);
-p2m->write_p2m_entry(p2m, first_gfn, pent, e, level);
+BUG_ON(p2m->write_p2m_entry(p2m, first_gfn, pent, e, level));
 }
 first_gfn += 1UL << (i * PAGETABLE_ORDER);
 }
@@ -392,14 +392,14 @@ static int do_recalc(struct p2m_domain *p2m, unsigned 
long gfn)
  !needs_recalc(l1, ent) )
 {
 set_recalc(l1, ent);
-p2m->write_p2m_entry(p2m, gfn - remainder, &ptab[i],
- ent, level);
+BUG_ON(p2m->write_p2m_entry(p2m, gfn - remainder, &ptab[i],
+ent, level));
 }
 remainder -= 1UL << ((level - 1) * PAGETABLE_ORDER);
 }
 smp_wmb();
 clear_recalc(l1, e);
-p2m->write_p2m_entry(p2m, gfn, pent, e, level + 1);
+BUG_ON(p2m->write_p2m_entry(p2m, gfn, pent, e, level + 1));
 }
 unmap_domain_page((void *)((unsigned long)pent & PAGE_MASK));
 }
@@ -444,7 +444,7 @@ static int do_recalc(struct p2m_domain *p2m, unsigned long 
gfn)
 }
 else
 clear_recalc(l1, e);
-p2m->write_p2m_entry(p2m, gfn, pent,

[Xen-devel] [linux-next test] 133224: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvopsbroken
 build-arm64-xsm  broken
 build-arm64  broken
 test-armhf-armhf-xl-credit1  12 guest-start  fail REGR. vs. 133145
 test-armhf-armhf-libvirt 12 guest-start  fail REGR. vs. 133145
 test-armhf-armhf-xl  12 guest-start  fail REGR. vs. 133145
 test-armhf-armhf-xl-cubietruck 12 guest-startfail REGR. vs. 133145
 test-armhf-armhf-xl-credit2  12 guest-start  fail REGR. vs. 133145
 test-armhf-armhf-xl-multivcpu 12 guest-start fail REGR. vs. 133145
 test-armhf-armhf-xl-arndale  12 guest-start  fail REGR. vs. 133145
 test-armhf-armhf-xl-vhd  10 debian-di-installfail REGR. vs. 133145
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 133145

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 12 guest-start  fail REGR. vs. 133145

Tests which did not succeed, but are not blocking:
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate  broken like 133145
 build-arm64-pvops 2 hosts-allocate  broken like 133145
 build-arm64-xsm   2 hosts-allocate  broken like 133145
 build-arm64-xsm   3 capture-logsbroken like 133145
 build-arm64-pvops 3 capture-logsbroken like 133145
 build-arm64   3 capture-logsbroken like 133145
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail like 133145
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail like 
133145
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133145
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 133145
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 133145
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 133145
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 133145
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail like 
133145
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 133145
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 133145
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 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-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linuxc4f3ef3eb53fd7e8cbfe200d5ff6dba2b08526b5
baseline version:
 linuxd13937116f1e82bf508a6325111b322c30c85eb9

Last test of basis  (not found) 
Failing since   (not found) 
Testing same since   133224  2019-02-13 09:19:06 Z2 days1 attempts

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  broken  
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  broken  
 build-ar

Re: [Xen-devel] [PATCH for-4.12 V4] x86/altp2m: fix HVMOP_altp2m_set_domain_state race

[George Dunlap]

> On Feb 15, 2019, at 2:02 PM, Jan Beulich  wrote:
> 
 On 15.02.19 at 14:51,  wrote:
> 
>> 
>>> On Feb 15, 2019, at 1:47 PM, Andrew Cooper  
>>> wrote:
>>> 
>>> On 15/02/2019 13:37, George Dunlap wrote:
 
>> The one issue is that domain_pause_except_self() currently is actually a 
>> deadlock risk if two different vcpus start it at the same time.  I think 
>> the 
>> 
>> attached patch (compile-tested only) should fix this issue; after this 
>> patch 
>> 
>> you should be able to use domain_pause_except_self() in 
>> altp2m_set_domain_state instead.
> There's one thing I don't really like here, which is a result of the
> (necessary) re-use of the hypercall deadlock mutex: This
> certainly poses the risk of getting called from a context where
> the lock was already acquired. Therefore I'd like to suggest to
> use this lock in a recursive way (here and elsewhere).
>>> 
>>> I can't think of a usecase were we would want to tolerate recursion on
>>> the hypercall deadlock spinlock.
>> 
>> It sounds like Jan is specifically thinking that someone may (say) call 
>> domctl_lock(), then afterwards call domain_pause_except_self().
>> 
>> Of course, that would deadlock immediately, so would probably get caught 
>> before the patch even got to `git send-email`.
> 
> Indeed. The situation I'm worried about is if this was put on some
> error path, which might never be hit in testing.

Hmm, or other unusual paths.  I’m leaning more towards saying we should use 
spin_lock_recursive(); it’s not *that* much more complication, is it, Andy?

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

Re: [Xen-devel] [PATCH for-4.12 V4] x86/altp2m: fix HVMOP_altp2m_set_domain_state race

[Jan Beulich]

>>> On 15.02.19 at 14:51,  wrote:

> 
>> On Feb 15, 2019, at 1:47 PM, Andrew Cooper  wrote:
>> 
>> On 15/02/2019 13:37, George Dunlap wrote:
>>> 
> The one issue is that domain_pause_except_self() currently is actually a 
> deadlock risk if two different vcpus start it at the same time.  I think 
> the 
> 
> attached patch (compile-tested only) should fix this issue; after this 
> patch 
> 
> you should be able to use domain_pause_except_self() in 
> altp2m_set_domain_state instead.
 There's one thing I don't really like here, which is a result of the
 (necessary) re-use of the hypercall deadlock mutex: This
 certainly poses the risk of getting called from a context where
 the lock was already acquired. Therefore I'd like to suggest to
 use this lock in a recursive way (here and elsewhere).
>> 
>> I can't think of a usecase were we would want to tolerate recursion on
>> the hypercall deadlock spinlock.
> 
> It sounds like Jan is specifically thinking that someone may (say) call 
> domctl_lock(), then afterwards call domain_pause_except_self().
> 
> Of course, that would deadlock immediately, so would probably get caught 
> before the patch even got to `git send-email`.

Indeed. The situation I'm worried about is if this was put on some
error path, which might never be hit in testing.

>  But it seems like a 
> reasonable thing someone might want to do.
> 
> OTOH, I’m fine leaving making it recursive until someone discovers that it 
> needs to be.

Considering Andrew's remark towards this "just" being a live lock
of a domain, I won't insist on the recursiveness, but I still think
it would be better as less error prone down the road. If left as is,
it would perhaps be a good idea to at least leave a remark in the
description, so that someone running into the problem and finding
this commit won't have to guess why it is the way it is.

Jan


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

Re: [Xen-devel] [PATCH for-4.12 V4] x86/altp2m: fix HVMOP_altp2m_set_domain_state race

[Razvan Cojocaru]

On 2/15/19 3:37 PM, George Dunlap wrote:




On Feb 15, 2019, at 1:24 PM, Jan Beulich  wrote:


On 15.02.19 at 13:52,  wrote:

On Feb 12, 2019, at 11:42 AM, Razvan Cojocaru  wrote:

HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
on purpose (as it was originally supposed to cater to a in-guest
agent, and a domain pausing itself is not a good idea).


Sorry to come in here on v4 and suggest changing everything, but I don’t
really like the solution you have here.  Not setting altp2m to ‘active’ until
after the vcpus are set up makes sense; but passing this true/false value in
seems ugly, and still seems a bit racy (i.e., what if p2m_active() is
disabled between the check in HVMOP_altp2m_switch_p2m and the time we
actually call altp2m_vcpu_update_p2m()?)

I certainly don’t think domain_pause() should be our go-to solution for race
avoidance, but in this case it really seems like switching the global p2m for
every vcpu at once makes the most sense; and trying to safely change this on
an unpaused domain is not only overly complicated, but probably not what we
wanted anyway.

p2m_altp2m_destroy_by_id() and p2m_switch_domain_altp2m_by_id() already use
domain_pause_except_self(); so it seems like not using it for
altp2m_set_domain_state was probably more of an oversight than an intentional
decision.  Using that here seems like a more robust solution.


Ah, I didn't even recall there was such a function. As this now
also allows covering a domain requesting the operation for itself,
I don't mind the pausing approach anymore.


Yeah, I forgot too until I was grepping for “domain_pause” to figure out what 
everyone else was doing. :-)


The one issue is that domain_pause_except_self() currently is actually a
deadlock risk if two different vcpus start it at the same time.  I think the
attached patch (compile-tested only) should fix this issue; after this patch
you should be able to use domain_pause_except_self() in
altp2m_set_domain_state instead.


There's one thing I don't really like here, which is a result of the
(necessary) re-use of the hypercall deadlock mutex: This
certainly poses the risk of getting called from a context where
the lock was already acquired. Therefore I'd like to suggest to
use this lock in a recursive way (here and elsewhere).




And two cosmetic remarks - there's no need to re-specify
__must_check on the function definition, as the function
declaration ought to be in scope anyway. And there's a stray
blank inside the likely() you add.


I don’t see that I added a ‘likely’; there’s one in context, but I don’t see 
any stray blanks there.

The other two points make sense — Razvan, would you be willing to make those 
changes (and test the result, as I haven’t done more than compile-test it)?


Of course, happy to. Just to make sure I understand where we stand: I'll 
try to leave the mutex alone for now and only switch to a recursive one 
if anything blows up.



Thanks,
Razvan

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

Re: [Xen-devel] [PATCH for-4.12 V4] x86/altp2m: fix HVMOP_altp2m_set_domain_state race

[George Dunlap]

> On Feb 15, 2019, at 1:47 PM, Andrew Cooper  wrote:
> 
> On 15/02/2019 13:37, George Dunlap wrote:
>> 
 The one issue is that domain_pause_except_self() currently is actually a 
 deadlock risk if two different vcpus start it at the same time.  I think 
 the 
 attached patch (compile-tested only) should fix this issue; after this 
 patch 
 you should be able to use domain_pause_except_self() in 
 altp2m_set_domain_state instead.
>>> There's one thing I don't really like here, which is a result of the
>>> (necessary) re-use of the hypercall deadlock mutex: This
>>> certainly poses the risk of getting called from a context where
>>> the lock was already acquired. Therefore I'd like to suggest to
>>> use this lock in a recursive way (here and elsewhere).
> 
> I can't think of a usecase were we would want to tolerate recursion on
> the hypercall deadlock spinlock.

It sounds like Jan is specifically thinking that someone may (say) call 
domctl_lock(), then afterwards call domain_pause_except_self().

Of course, that would deadlock immediately, so would probably get caught before 
the patch even got to `git send-email`.  But it seems like a reasonable thing 
someone might want to do.

OTOH, I’m fine leaving making it recursive until someone discovers that it 
needs to be.

 -George

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

Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]

[Lars Kurth]

Ian,

as mentioned earlier, I think we need a legal/admin item for hardware and 
donations. See proposed addition below.

On 15/02/2019, 11:57, "Ian Jackson"  wrote:

Ian Jackson writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 
more messages]"):
> So overall, for the reasons I explain, I'm going to commit this
> document (subject to the other comments etc.) *with* the requirement
> that hardware must be supported by Debian (at least, in -backports).

This didn't happen.  THere was considerable further discussion.  The
fact that various kinds of uncertainty meant this document didn't get
committed is now blocking us giving the go-ahead for some new hardware
acquisition:

...

From fae48bd584a0b58934a2df97b6db1d06eacf1724 Mon Sep 17 00:00:00 2001
From: Ian Jackson 
Date: Tue, 30 Oct 2018 16:12:27 +
Subject: [OSSTEST PATCH] README.hardware-acquisition

New document-cum-checklist, for helping with hardware procurement.

Signed-off-by: Ian Jackson 
CC: in...@xenproject.org
CC: George Dunlap 
CC: Stefano Stabellini 
CC: Julien Grall https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.12 V4] x86/altp2m: fix HVMOP_altp2m_set_domain_state race

[Andrew Cooper]

On 15/02/2019 13:37, George Dunlap wrote:
>
>>> The one issue is that domain_pause_except_self() currently is actually a 
>>> deadlock risk if two different vcpus start it at the same time.  I think 
>>> the 
>>> attached patch (compile-tested only) should fix this issue; after this 
>>> patch 
>>> you should be able to use domain_pause_except_self() in 
>>> altp2m_set_domain_state instead.
>> There's one thing I don't really like here, which is a result of the
>> (necessary) re-use of the hypercall deadlock mutex: This
>> certainly poses the risk of getting called from a context where
>> the lock was already acquired. Therefore I'd like to suggest to
>> use this lock in a recursive way (here and elsewhere).

I can't think of a usecase were we would want to tolerate recursion on
the hypercall deadlock spinlock.

I'd assert/domain_crash() that its not locked by the current cpu, rather
than complicating everything for a theoretical case of questionable utility.

Attempted nesting of this lock isn't a security issue, because all that
will happen is that the vcpu will livelock taking continuations.

~Andrew

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

Re: [Xen-devel] [PATCH for-4.12 V4] x86/altp2m: fix HVMOP_altp2m_set_domain_state race

[Jan Beulich]

>>> On 15.02.19 at 14:37,  wrote:
>> On Feb 15, 2019, at 1:24 PM, Jan Beulich  wrote:
>> And two cosmetic remarks - there's no need to re-specify
>> __must_check on the function definition, as the function
>> declaration ought to be in scope anyway. And there's a stray
>> blank inside the likely() you add.
> 
> I don’t see that I added a ‘likely’; there’s one in context, but I don’t see 
> any stray blanks there.

Oh, I'm sorry - an artifact from the strange font my mail client
uses when viewing attachments. It looks like there is a space,
but there really isn't.

Jan


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

Re: [Xen-devel] [PATCH V2 0/3] Renesas Stout board support (R-Car Gen2)

[Oleksandr]

On 15.02.19 15:30, Julien Grall wrote:

Hi, Julien




On Fri, 15 Feb 2019, 14:25 Oleksandr, > wrote:



On 01.02.19 14:37, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko mailto:oleksandr_tyshche...@epam.com>>
>
> Hi, all.


Hi, all

gentle reminder...


This is in my queue of patches to review. Also, as we are in freeze, I 
tend to prioritize patches for 4.12.


I will try to have a look next week.



I understand. Thank you.




Cheers,



>
> The purpose of this patch series is to add required support to
be able to run
> Xen on Renesas Stout board [1] which uses SCIFA compatible UART
as a console
> interface.
>
> Actually Xen already has support for SCIF compatible UARTs which
are used on
> Renesas Lager (R-Car Gen2), Salvator-X, H3ULCB/M3ULCB (R-Car
Gen3) and other
> development boards. So this patch series extends existing
support to be able
> to handle both interfaces.
>
> --
>
> Current patch series is based on the following commit
3389a8dc8c5753a3c84744923cd0193395e3f2a9
> and tested on Stout (ARM32) and H3ULCB (ARM64) boards.
>
> You can find current patch series here:
> repo: https://github.com/otyshchenko1/xen.git branch: stout_upstream
>
> You can find previous discussion here:
>
https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg21058.html
>
> Please note, that current patch series doesn’t have the
following patches:
> - xen/arm: drivers: scif: Remove unused #define-s (already
upstreamed)
> - xen/arm: Reuse R-Car Gen2 platform code for Stout board (was
dropped)
> but has new one:
> - xen/arm: Clarify usage of earlyprintk for Lager board
>
> --
>
> In order to run Xen on Stout board you need "PSCI-enabled"
U-Boot (not upsteamed yet).
> You can find corresponding patches for U-Boot here:
>

http://u-boot.10912.n7.nabble.com/PATCH-0-3-PSCI-support-for-r8a7790-SoC-Lager-Stout-boards-td357352.html
>
> Have a plan to update Xen Wiki regarding this board.
>
> [1] https://elinux.org/R-Car/Boards/Stout
>
> --
>
> Oleksandr Tyshchenko (3):
>    xen/arm: drivers: scif: Add support for SCIFA compatible UARTs
>    xen/arm: Clarify usage of earlyprintk for Lager board
>    xen/arm: Add SCIFA UART support for early printk
>
>   docs/misc/arm/early-printk.txt     |   2 +-
>   xen/arch/arm/arm32/debug-scifa.inc |  51 ++
>   xen/drivers/char/scif-uart.c       | 139
+++--
>   xen/include/asm-arm/scif-uart.h    |  44 ++--
>   4 files changed, 194 insertions(+), 42 deletions(-)
>   create mode 100644 xen/arch/arm/arm32/debug-scifa.inc
>
-- 
Regards,


Oleksandr Tyshchenko


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


--
Regards,

Oleksandr Tyshchenko

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

Re: [Xen-devel] [PATCH for-4.12 V4] x86/altp2m: fix HVMOP_altp2m_set_domain_state race

[George Dunlap]

> On Feb 15, 2019, at 1:24 PM, Jan Beulich  wrote:
> 
 On 15.02.19 at 13:52,  wrote:
>>> On Feb 12, 2019, at 11:42 AM, Razvan Cojocaru  
>>> wrote:
>>> 
>>> HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
>>> on purpose (as it was originally supposed to cater to a in-guest
>>> agent, and a domain pausing itself is not a good idea).
>> 
>> Sorry to come in here on v4 and suggest changing everything, but I don’t 
>> really like the solution you have here.  Not setting altp2m to ‘active’ 
>> until 
>> after the vcpus are set up makes sense; but passing this true/false value in 
>> seems ugly, and still seems a bit racy (i.e., what if p2m_active() is 
>> disabled between the check in HVMOP_altp2m_switch_p2m and the time we 
>> actually call altp2m_vcpu_update_p2m()?)
>> 
>> I certainly don’t think domain_pause() should be our go-to solution for race 
>> avoidance, but in this case it really seems like switching the global p2m 
>> for 
>> every vcpu at once makes the most sense; and trying to safely change this on 
>> an unpaused domain is not only overly complicated, but probably not what we 
>> wanted anyway.
>> 
>> p2m_altp2m_destroy_by_id() and p2m_switch_domain_altp2m_by_id() already use 
>> domain_pause_except_self(); so it seems like not using it for 
>> altp2m_set_domain_state was probably more of an oversight than an 
>> intentional 
>> decision.  Using that here seems like a more robust solution.
> 
> Ah, I didn't even recall there was such a function. As this now
> also allows covering a domain requesting the operation for itself,
> I don't mind the pausing approach anymore.

Yeah, I forgot too until I was grepping for “domain_pause” to figure out what 
everyone else was doing. :-)

>> The one issue is that domain_pause_except_self() currently is actually a 
>> deadlock risk if two different vcpus start it at the same time.  I think the 
>> attached patch (compile-tested only) should fix this issue; after this patch 
>> you should be able to use domain_pause_except_self() in 
>> altp2m_set_domain_state instead.
> 
> There's one thing I don't really like here, which is a result of the
> (necessary) re-use of the hypercall deadlock mutex: This
> certainly poses the risk of getting called from a context where
> the lock was already acquired. Therefore I'd like to suggest to
> use this lock in a recursive way (here and elsewhere).

> 
> And two cosmetic remarks - there's no need to re-specify
> __must_check on the function definition, as the function
> declaration ought to be in scope anyway. And there's a stray
> blank inside the likely() you add.

I don’t see that I added a ‘likely’; there’s one in context, but I don’t see 
any stray blanks there.

The other two points make sense — Razvan, would you be willing to make those 
changes (and test the result, as I haven’t done more than compile-test it)?

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

Re: [Xen-devel] [PATCH for-4.12 V4] x86/altp2m: fix HVMOP_altp2m_set_domain_state race

[Razvan Cojocaru]

On Feb 12, 2019, at 11:42 AM, Razvan Cojocaru  wrote:

HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
on purpose (as it was originally supposed to cater to a in-guest
agent, and a domain pausing itself is not a good idea).


Sorry to come in here on v4 and suggest changing everything, but I don’t really 
like the solution you have here.  Not setting altp2m to ‘active’ until after 
the vcpus are set up makes sense; but passing this true/false value in seems 
ugly, and still seems a bit racy (i.e., what if p2m_active() is disabled 
between the check in HVMOP_altp2m_switch_p2m and the time we actually call 
altp2m_vcpu_update_p2m()?)

I certainly don’t think domain_pause() should be our go-to solution for race 
avoidance, but in this case it really seems like switching the global p2m for 
every vcpu at once makes the most sense; and trying to safely change this on an 
unpaused domain is not only overly complicated, but probably not what we wanted 
anyway.

p2m_altp2m_destroy_by_id() and p2m_switch_domain_altp2m_by_id() already use 
domain_pause_except_self(); so it seems like not using it for 
altp2m_set_domain_state was probably more of an oversight than an intentional 
decision.  Using that here seems like a more robust solution.

The one issue is that domain_pause_except_self() currently is actually a 
deadlock risk if two different vcpus start it at the same time.  I think the 
attached patch (compile-tested only) should fix this issue; after this patch 
you should be able to use domain_pause_except_self() in altp2m_set_domain_state 
instead.

Does that sound reasonable?


Not only does that sound reasonable, I personally prefer this approach. 
I'll apply this patch and give it a spin.



Thanks,
Razvan

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

Re: [Xen-devel] [PATCH V2 0/3] Renesas Stout board support (R-Car Gen2)

[Julien Grall]

On Fri, 15 Feb 2019, 14:25 Oleksandr,  wrote:

>
> On 01.02.19 14:37, Oleksandr Tyshchenko wrote:
> > From: Oleksandr Tyshchenko 
> >
> > Hi, all.
>
>
> Hi, all
>
> gentle reminder...
>

This is in my queue of patches to review. Also, as we are in freeze, I tend
to prioritize patches for 4.12.

I will try to have a look next week.

Cheers,


>
> >
> > The purpose of this patch series is to add required support to be able
> to run
> > Xen on Renesas Stout board [1] which uses SCIFA compatible UART as a
> console
> > interface.
> >
> > Actually Xen already has support for SCIF compatible UARTs which are
> used on
> > Renesas Lager (R-Car Gen2), Salvator-X, H3ULCB/M3ULCB (R-Car Gen3) and
> other
> > development boards. So this patch series extends existing support to be
> able
> > to handle both interfaces.
> >
> > --
> >
> > Current patch series is based on the following commit
> 3389a8dc8c5753a3c84744923cd0193395e3f2a9
> > and tested on Stout (ARM32) and H3ULCB (ARM64) boards.
> >
> > You can find current patch series here:
> > repo: https://github.com/otyshchenko1/xen.git branch: stout_upstream
> >
> > You can find previous discussion here:
> >
> https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg21058.html
> >
> > Please note, that current patch series doesn’t have the following
> patches:
> > - xen/arm: drivers: scif: Remove unused #define-s (already upstreamed)
> > - xen/arm: Reuse R-Car Gen2 platform code for Stout board (was dropped)
> > but has new one:
> > - xen/arm: Clarify usage of earlyprintk for Lager board
> >
> > --
> >
> > In order to run Xen on Stout board you need "PSCI-enabled" U-Boot (not
> upsteamed yet).
> > You can find corresponding patches for U-Boot here:
> >
> http://u-boot.10912.n7.nabble.com/PATCH-0-3-PSCI-support-for-r8a7790-SoC-Lager-Stout-boards-td357352.html
> >
> > Have a plan to update Xen Wiki regarding this board.
> >
> > [1] https://elinux.org/R-Car/Boards/Stout
> >
> > --
> >
> > Oleksandr Tyshchenko (3):
> >xen/arm: drivers: scif: Add support for SCIFA compatible UARTs
> >xen/arm: Clarify usage of earlyprintk for Lager board
> >xen/arm: Add SCIFA UART support for early printk
> >
> >   docs/misc/arm/early-printk.txt |   2 +-
> >   xen/arch/arm/arm32/debug-scifa.inc |  51 ++
> >   xen/drivers/char/scif-uart.c   | 139
> +++--
> >   xen/include/asm-arm/scif-uart.h|  44 ++--
> >   4 files changed, 194 insertions(+), 42 deletions(-)
> >   create mode 100644 xen/arch/arm/arm32/debug-scifa.inc
> >
> --
> Regards,
>
> Oleksandr Tyshchenko
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.12 V4] x86/altp2m: fix HVMOP_altp2m_set_domain_state race

[Jan Beulich]

>>> On 15.02.19 at 13:52,  wrote:
>> On Feb 12, 2019, at 11:42 AM, Razvan Cojocaru  
>> wrote:
>> 
>> HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
>> on purpose (as it was originally supposed to cater to a in-guest
>> agent, and a domain pausing itself is not a good idea).
> 
> Sorry to come in here on v4 and suggest changing everything, but I don’t 
> really like the solution you have here.  Not setting altp2m to ‘active’ until 
> after the vcpus are set up makes sense; but passing this true/false value in 
> seems ugly, and still seems a bit racy (i.e., what if p2m_active() is 
> disabled between the check in HVMOP_altp2m_switch_p2m and the time we 
> actually call altp2m_vcpu_update_p2m()?)
> 
> I certainly don’t think domain_pause() should be our go-to solution for race 
> avoidance, but in this case it really seems like switching the global p2m for 
> every vcpu at once makes the most sense; and trying to safely change this on 
> an unpaused domain is not only overly complicated, but probably not what we 
> wanted anyway.
> 
> p2m_altp2m_destroy_by_id() and p2m_switch_domain_altp2m_by_id() already use 
> domain_pause_except_self(); so it seems like not using it for 
> altp2m_set_domain_state was probably more of an oversight than an intentional 
> decision.  Using that here seems like a more robust solution.

Ah, I didn't even recall there was such a function. As this now
also allows covering a domain requesting the operation for itself,
I don't mind the pausing approach anymore.

> The one issue is that domain_pause_except_self() currently is actually a 
> deadlock risk if two different vcpus start it at the same time.  I think the 
> attached patch (compile-tested only) should fix this issue; after this patch 
> you should be able to use domain_pause_except_self() in 
> altp2m_set_domain_state instead.

There's one thing I don't really like here, which is a result of the
(necessary) re-use of the hypercall deadlock mutex: This
certainly poses the risk of getting called from a context where
the lock was already acquired. Therefore I'd like to suggest to
use this lock in a recursive way (here and elsewhere).

And two cosmetic remarks - there's no need to re-specify
__must_check on the function definition, as the function
declaration ought to be in scope anyway. And there's a stray
blank inside the likely() you add.

Jan


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

Re: [Xen-devel] [PATCH V2 0/3] Renesas Stout board support (R-Car Gen2)

[Oleksandr]

On 01.02.19 14:37, Oleksandr Tyshchenko wrote:

From: Oleksandr Tyshchenko 

Hi, all.



Hi, all

gentle reminder...




The purpose of this patch series is to add required support to be able to run
Xen on Renesas Stout board [1] which uses SCIFA compatible UART as a console
interface.

Actually Xen already has support for SCIF compatible UARTs which are used on
Renesas Lager (R-Car Gen2), Salvator-X, H3ULCB/M3ULCB (R-Car Gen3) and other
development boards. So this patch series extends existing support to be able
to handle both interfaces.

--

Current patch series is based on the following commit 
3389a8dc8c5753a3c84744923cd0193395e3f2a9
and tested on Stout (ARM32) and H3ULCB (ARM64) boards.

You can find current patch series here:
repo: https://github.com/otyshchenko1/xen.git branch: stout_upstream

You can find previous discussion here:
https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg21058.html

Please note, that current patch series doesn’t have the following patches:
- xen/arm: drivers: scif: Remove unused #define-s (already upstreamed)
- xen/arm: Reuse R-Car Gen2 platform code for Stout board (was dropped)
but has new one:
- xen/arm: Clarify usage of earlyprintk for Lager board

--

In order to run Xen on Stout board you need "PSCI-enabled" U-Boot (not 
upsteamed yet).
You can find corresponding patches for U-Boot here:
http://u-boot.10912.n7.nabble.com/PATCH-0-3-PSCI-support-for-r8a7790-SoC-Lager-Stout-boards-td357352.html

Have a plan to update Xen Wiki regarding this board.

[1] https://elinux.org/R-Car/Boards/Stout

--

Oleksandr Tyshchenko (3):
   xen/arm: drivers: scif: Add support for SCIFA compatible UARTs
   xen/arm: Clarify usage of earlyprintk for Lager board
   xen/arm: Add SCIFA UART support for early printk

  docs/misc/arm/early-printk.txt |   2 +-
  xen/arch/arm/arm32/debug-scifa.inc |  51 ++
  xen/drivers/char/scif-uart.c   | 139 +++--
  xen/include/asm-arm/scif-uart.h|  44 ++--
  4 files changed, 194 insertions(+), 42 deletions(-)
  create mode 100644 xen/arch/arm/arm32/debug-scifa.inc


--
Regards,

Oleksandr Tyshchenko


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

Re: [Xen-devel] [PATCH for-4.12 V4] x86/altp2m: fix HVMOP_altp2m_set_domain_state race

[George Dunlap]

> On Feb 12, 2019, at 11:42 AM, Razvan Cojocaru  
> wrote:
> 
> HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
> on purpose (as it was originally supposed to cater to a in-guest
> agent, and a domain pausing itself is not a good idea).

Sorry to come in here on v4 and suggest changing everything, but I don’t really 
like the solution you have here.  Not setting altp2m to ‘active’ until after 
the vcpus are set up makes sense; but passing this true/false value in seems 
ugly, and still seems a bit racy (i.e., what if p2m_active() is disabled 
between the check in HVMOP_altp2m_switch_p2m and the time we actually call 
altp2m_vcpu_update_p2m()?)

I certainly don’t think domain_pause() should be our go-to solution for race 
avoidance, but in this case it really seems like switching the global p2m for 
every vcpu at once makes the most sense; and trying to safely change this on an 
unpaused domain is not only overly complicated, but probably not what we wanted 
anyway.

p2m_altp2m_destroy_by_id() and p2m_switch_domain_altp2m_by_id() already use 
domain_pause_except_self(); so it seems like not using it for 
altp2m_set_domain_state was probably more of an oversight than an intentional 
decision.  Using that here seems like a more robust solution.

The one issue is that domain_pause_except_self() currently is actually a 
deadlock risk if two different vcpus start it at the same time.  I think the 
attached patch (compile-tested only) should fix this issue; after this patch 
you should be able to use domain_pause_except_self() in altp2m_set_domain_state 
instead.

Does that sound reasonable?

 -George


0001-altp2m-Prevent-deadlocks-when-a-domain-performs-altp.patch
Description: 0001-altp2m-Prevent-deadlocks-when-a-domain-performs-altp.patch
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 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 13 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

version targeted for testing:
 xen  f178a00c30173c0b268d99160e19ad299b1823a2
baseline version:
 xen  455301716e1ff358cb79367213003fba771dd466

Last test of basis   133005  2019-02-07 14:00:32 Z7 days
Failing since133011  2019-02-07 18:00:36 Z7 days   47 attempts
Testing same since   133200  2019-02-12 16:00:56 Z2 days   24 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Kevin Tian 
  Michael Tautschnig 
  Norbert Manthey 
  Norbert Manthey 
  Stefano Stabellini 
  Stefano Stabellini 
  Tim Deegan 
  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-i386 pass
 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
   455301716e..f178a00c30  f178a00c30173c0b268d99160e19ad299b1823a2 -> smoke

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

Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]

[Juergen Gross]

On 15/02/2019 12:56, Ian Jackson wrote:
> Ian Jackson writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 
> more messages]"):
>> So overall, for the reasons I explain, I'm going to commit this
>> document (subject to the other comments etc.) *with* the requirement
>> that hardware must be supported by Debian (at least, in -backports).
> 
> This didn't happen.  THere was considerable further discussion.  The
> fact that various kinds of uncertainty meant this document didn't get
> committed is now blocking us giving the go-ahead for some new hardware
> acquisition:
> 
> Ie, I can't answer the question "should we accept hardware XYZ"
> without reference to at least an implied a checklist like this.
> Having written it down I ought to use the one I've written down,
> because to do otherwise is simply to pointlessly invite mistakes.  And
> if I'm to use a written-down checklist it should be one which is
> actually official.
> 
> Accordingly, I intend to commit this to osstest now.  Juergen, this is
> just a document: can I have your release ack for it ?

Yes, sure:

Release-acked-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH] tools/libxendevicemodel: add xendevicemodel_modified_memory_bulk to map

[Juergen Gross]

On 15/02/2019 11:31, Paul Durrant wrote:
> Cc-ing Juergen, in case this can make 4.12...
> 
>> -Original Message-
>> From: Paul Durrant [mailto:paul.durr...@citrix.com]
>> Sent: 15 February 2019 10:02
>> To: xen-devel@lists.xenproject.org
>> Cc: Paul Durrant ; Ian Jackson
>> ; Wei Liu 
>> Subject: [PATCH] tools/libxendevicemodel: add
>> xendevicemodel_modified_memory_bulk to map
>>
>> Commit e3b93b3c595 "dmop: add xendevicemodel_modified_memory_bulk()" added
>> the implementation to the library almost 2 years ago, but the function
>> was not included in the map file, essentially making it useless. This
>> patch rectifies the situation.
>>
>> Signed-off-by: Paul Durrant 

Release-acked-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]

[Ian Jackson]

Ian Jackson writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 
more messages]"):
> So overall, for the reasons I explain, I'm going to commit this
> document (subject to the other comments etc.) *with* the requirement
> that hardware must be supported by Debian (at least, in -backports).

This didn't happen.  THere was considerable further discussion.  The
fact that various kinds of uncertainty meant this document didn't get
committed is now blocking us giving the go-ahead for some new hardware
acquisition:

Ie, I can't answer the question "should we accept hardware XYZ"
without reference to at least an implied a checklist like this.
Having written it down I ought to use the one I've written down,
because to do otherwise is simply to pointlessly invite mistakes.  And
if I'm to use a written-down checklist it should be one which is
actually official.

Accordingly, I intend to commit this to osstest now.  Juergen, this is
just a document: can I have your release ack for it ?

I will then reply separately about the specific new hardware, using
the checklist as a guide.  Obviously a checklist is always a
guidelines document: if we find that a point is best answered a
different way than the checklist expects, or that the checklist ought
to be changed, then changes to the checklist are a reasonable part of
the outcome of such a process; that would be in the form of further
patches to this document in osstest.

Ian.

From fae48bd584a0b58934a2df97b6db1d06eacf1724 Mon Sep 17 00:00:00 2001
From: Ian Jackson 
Date: Tue, 30 Oct 2018 16:12:27 +
Subject: [OSSTEST PATCH] README.hardware-acquisition

New document-cum-checklist, for helping with hardware procurement.

Signed-off-by: Ian Jackson 
CC: in...@xenproject.org
CC: George Dunlap 
CC: Stefano Stabellini 
CC: Julien Grall https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH SpectreV1+L1TF v6 3/9] x86/hvm: block speculative out-of-bound accesses

[Jan Beulich]

>>> On 15.02.19 at 11:50,  wrote:
> On 2/15/19 09:55, Jan Beulich wrote:
> On 15.02.19 at 09:05,  wrote:
>>> On 2/12/19 15:14, Jan Beulich wrote:
>>> On 12.02.19 at 15:05,  wrote:
> On 2/12/19 14:25, Jan Beulich wrote:
> On 08.02.19 at 14:44,  wrote:
>>> @@ -4104,6 +4108,12 @@ static int hvmop_set_param(
>>>  if ( a.index >= HVM_NR_PARAMS )
>>>  return -EINVAL;
>>>  
>>> +/*
>>> + * Make sure the guest controlled value a.index is bounded even 
>>> during
>>> + * speculative execution.
>>> + */
>>> +a.index = array_index_nospec(a.index, HVM_NR_PARAMS);
>>> +
>>>  d = rcu_lock_domain_by_any_id(a.domid);
>>>  if ( d == NULL )
>>>  return -ESRCH;
>>> @@ -4370,6 +4380,12 @@ static int hvmop_get_param(
>>>  if ( a.index >= HVM_NR_PARAMS )
>>>  return -EINVAL;
>>>  
>>> +/*
>>> + * Make sure the guest controlled value a.index is bounded even 
>>> during
>>> + * speculative execution.
>>> + */
>>> +a.index = array_index_nospec(a.index, HVM_NR_PARAMS);
>> ... the usefulness of these two. To make forward progress it may
>> be worthwhile to split off these two changes into a separate patch.
>> If you're fine with this, I could strip these two before committing,
>> in which case the remaining change is
>> Reviewed-by: Jan Beulich 
> Taking apart the commit is fine with me. I will submit a follow up
> change that does not update the values but fixes the reads.
 As pointed out during the v5 discussion, I'm unconvinced that if
 you do so the compiler can't re-introduce the issue via CSE. I'd
 really like a reliable solution to be determined first.
>>> I cannot give a guarantee what future compilers might do. Furthermore, I
>>> do not want to wait until all/most compilers ship with such a
>>> controllable guarantee.
>> Guarantee? Future compilers are (hopefully) going to get better at
>> optimizing, and hence are (again hopefully) going to find more
>> opportunities for CSE. So the problem is going to get worse rather
>> than better, and the changes you're proposing to re-instate are
>> therefore more like false promises.
> 
> I do not want to dive into compilers future here. I would like to fix
> the issue for todays compilers now and not wait until compilers evolved
> one way or another. For this patch, the relevant information is whether
> it should go in like this, or whether you want me to protect all the
> reads instead. Is there more data I shall provide to help make this
> decision?

I understand that you're not happy with what I've said, and you're
unlikely to become any happier with what I'll add. But please
understand that _if_ we make any changes to address issues with
speculation, the goal has to be that we don't have to come back
an re-investigate after every new compiler release.

Even beyond that - if, as you say, we'd limit ourselves to current
compilers, did you check that all of them at any optimization level
or with any other flags passed which may affect code generation
produce non-vulnerable code? And in particular considering the
case here never recognize CSE potential where we would like them
not to?

A code change is, imo, not even worthwhile considering to be put
in if it is solely based on the observations made with a limited set
of compilers and/or options. This might indeed help you, if you
care only about one specific environment. But by putting this in
(and perhaps even backporting it) we're sort of stating that the
issue is under control (to the best of our abilities, and for the given
area of code). For everyone.

So, to answer your question: From what we know, we simply
can't take a decision, at least not between the two proposed
variants of how to change the code. If there was a variant that
firmly worked, then there would not even be a need for any
discussion. And again from what we know, there is one
requirement that need to be fulfilled for a change to be
considered "firmly working": The index needs to be in a register.
There must not be a way for the compiler to undermine this,
be it by CSE or any other means.

Considering changes done elsewhere, of course this may be
taken with a grain of salt. In other places we also expect the
compiler to not emit unreasonable code (e.g. needlessly
spilling registers to memory just to then reload them). But
while that's (imo) a fine expectation to have when an array
index is used just once, it is unavoidably more complicated in
the case here as well as in the grant table one.

Jan


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

Re: [Xen-devel] [PATCH] tools/libxendevicemodel: add xendevicemodel_modified_memory_bulk to map

[Ian Jackson]

Paul Durrant writes ("RE: [PATCH] tools/libxendevicemodel: add 
xendevicemodel_modified_memory_bulk to map"):
> Perhaps it would be possible to build some sort of cross-check that all 
> functions listed in the public header of a library are actually *somewhere* 
> in the map file, so this doesn't happen in future.

I wouldn't stand in the way of that, but presumably functions are
usually added because someone wants to call them so it would often be
spotted anyway, and the consequences of a mistake here are fairly
minor.

Ian.

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

Re: [Xen-devel] RT Xen on ARM - R-Car series

[Andrii Anisov]

Hello Julien,

On 14.02.19 19:29, Julien Grall wrote:

I am not sure why you are speaking about the current implementation
when my point was about the new implementation.

I guess your point stick even if we decide to use guest physical
address.

For sure. The type of guest address used by hypervisor to reach runstate area 
and having that area mapped are quite orthogonal questions. But, IMHO, tightly 
coupled and might be solved together.


Although, I am still unconvinced of the benefits to keep it
mapped.

My point was reducing context switch time, but those controversial numbers left 
me confused.


I've measured the raw `update_runstate_area()` execution time. With runstate 
mapped - its execution time is less than my timer tick (120ns), with runstate 
not mapped - I've seen

its execution time as 4 to 8 ticks (480-960ns).

Please provide the code you use to measure it. How often do you call it?

The code to see that is as simple as following:

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 0a2e997..d673d00 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -314,8 +314,16 @@ static void schedule_tail(struct vcpu *prev)
 context_saved(prev);
 
 if ( prev != current )

+{
+s_time_t t = 0;
+if (current->domain->domain_id == 1)
+t = NOW();
 update_runstate_area(current);
 
+if (current->domain->domain_id == 1)

+printk("cp = %"PRI_stime"\n", NOW()-t);
+}
+
 /* Ensure that the vcpu has an up-to-date time base. */
 update_vcpu_system_time(current);
 }


But using TBM, I encountered that making runstate mapped with Roger's patch 
increases the IRQ latency from ~7000ns to ~7900ns. It is opposite to my 
expectations and to the raw decrease of `runstate_update_area()` execution time.


Raw benchmarks should be taken with a grain of salt. The more if you
only benchmark a single function as the context switch may introduce
latency/cache eviction.

Although, I would have expected the numbers to be the same. What is
your configuration here? Do you have others guests running? How many
context switch do you have?


The configuration is the same as here [1].



Also, what are the modifications you made in TBM to use runstate?


I've just registered the runstate area with following [2].

[1] https://lists.xenproject.org/archives/html/xen-devel/2018-12/msg00881.html
[2] 
https://github.com/aanisov/tbm/commit/806e8a7e6e6c72aef10f1c8a579424252aca2635


--
Sincerely,
Andrii Anisov.

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

Re: [Xen-devel] [PATCH] tools/libxendevicemodel: add xendevicemodel_modified_memory_bulk to map

[Paul Durrant]

> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@citrix.com]
> Sent: 15 February 2019 11:27
> To: Paul Durrant 
> Cc: xen-devel@lists.xenproject.org; Wei Liu ;
> jgr...@suse.com
> Subject: RE: [PATCH] tools/libxendevicemodel: add
> xendevicemodel_modified_memory_bulk to map
> 
> Paul Durrant writes ("RE: [PATCH] tools/libxendevicemodel: add
> xendevicemodel_modified_memory_bulk to map"):
> > Cc-ing Juergen, in case this can make 4.12...
> 
> I think this should go into 4.12.  It is very low risk.
> 
> In another case there would possibly be questions about whether we
> wanted to add an additional ABI/API stability promise, but in this
> case this is not an issue.

No, indeed.

Perhaps it would be possible to build some sort of cross-check that all 
functions listed in the public header of a library are actually *somewhere* in 
the map file, so this doesn't happen in future.

  Paul

> 
> Ian.

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

Re: [Xen-devel] [PATCH] tools/libxendevicemodel: add xendevicemodel_modified_memory_bulk to map

[Ian Jackson]

Paul Durrant writes ("RE: [PATCH] tools/libxendevicemodel: add 
xendevicemodel_modified_memory_bulk to map"):
> Cc-ing Juergen, in case this can make 4.12...

I think this should go into 4.12.  It is very low risk.

In another case there would possibly be questions about whether we
wanted to add an additional ABI/API stability promise, but in this
case this is not an issue.

Ian.

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

Re: [Xen-devel] [OSSTEST PATCH 5/4] backports snapshot: Disable apt timestamp checking in right place

[Ian Jackson]

Juergen Gross writes ("Re: [Xen-devel] [OSSTEST PATCH 5/4] backports snapshot: 
Disable apt timestamp checking in right place"):
> Release-acked-by: Juergen Gross 
> 
> in case my implicit ack from yesterday expired as well ;-)

Thanks :-).  I pushed it without waiting.  It is now in production (as
of 07mumble UTC this morning).  I think we will get a push of
xen-unstable-smoke shortly.

Ian.

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

Re: [Xen-devel] [PATCH] tools/libxendevicemodel: add xendevicemodel_modified_memory_bulk to map

[Wei Liu]

On Fri, Feb 15, 2019 at 10:02:00AM +, Paul Durrant wrote:
> Commit e3b93b3c595 "dmop: add xendevicemodel_modified_memory_bulk()" added
> the implementation to the library almost 2 years ago, but the function
> was not included in the map file, essentially making it useless. This
> patch rectifies the situation.
> 
> Signed-off-by: Paul Durrant 

Acked-by: Wei Liu 

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

Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Lars Kurth]

> On 15 Feb 2019, at 09:35, George Dunlap  wrote:
> 
>>> 
>>> As use case goes, it would be a good start if you just submit something
>>> you care about.
>> 
>> I mentioned on the call that a good first start could be a kconfig that
>> allows to build an hypervisor binary with only support for PVH and only
>> support for recent Intel machines, with the goal of minimizing the code
>> base to less than 100K LOC.
> 
> I think one thing that might be helpful is a sort of “feature document” for 
> each defconfig we’re looking at creating.  This would include:
> 
> * What the “target use case” for each defconfig would be
> * The end goal in terms of functionality / LoC / whatever
> * The current state, work items yet to do
> * What potential variations there are (i.e., how to enable shadow if you 
> want, or switch from Intel-only to AMD-only)
> 
> I’ve sort of been using docs/design/qemu-deprivilege.md in this way: Saying 
> where we want to go, and moving things from “to do” to “done” as they get 
> implemented.  That would make it easier to have in-progress things in the 
> tree, make it easier for people to collaborate / enhance defconfigs, and also 
> be a starting point for talking about testing and support status.

I think this is a great idea
Regards
Lars


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

Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Wei Liu]

On Thu, Feb 14, 2019 at 09:03:24PM +, Lars Kurth wrote:
> 
> 
> > On 14 Feb 2019, at 18:32, Stefano Stabellini  wrote:
> > 
> > On Thu, 14 Feb 2019, Jan Beulich wrote:
> > On 13.02.19 at 20:11,  wrote:
> >>> On Wed, 13 Feb 2019, Wei Liu wrote:
>  On Tue, Feb 12, 2019 at 09:34:25PM -0500, Daniel P. Smith wrote:
> > Greetings,
> > 
> > On the 11/14/18 Xen x86 community call a discussion was initiated about
> > using Kconfig to build minimized versions of Xen for security, safety
> > and other certification requirements. After some offline discussions
> > with Xen contributors I realized that a variety of efforts each with
> > their own respective goals are underway,
> > 
> > - nested virtualization
> > - mixed criticality architectures
> > - reducing trusted componentary
> > - combining hardware protection of virtualization with performance and
> > ease-of-use of containers
> > 
> > These efforts use hypervisors in different roles, all which Xen is
> > capable of meeting. Today Xen's utility comes at the expense of carrying
> > features necessary for one role to be present in another role where it
> > is not required, e.g. PV interfaces that may not be essential in an ARM
> > mixed criticality deployment.
> > 
> > The initial focus will be to explore and document the range of possible
> > use cases that are of interest to the Xen community. This will be the
> > input to a design document that is crafted in conjunction with the Xen
> > maintainers, to identify possible approaches to extend the existing
> > Kconfig infrastructure to produce tailored instances of Xen.
> > 
> > If you are interested in participating in this effort, please reply to
> > this thread to outline possible use cases, design constraints and other
> > considerations for improving Xen's Kconfig infrastructure to support
> > tailoring for specific use cases.
> > 
>  
>  My impression from the community call is that you want to provide
>  smallish configurations for different use cases.
>  
>  The Kconfig infrastructure is already able to do what you want as far as
>  I can tell.  You can easily feed it a base config file -- see files
>  under automation/configs/x86/.  What sort of extension is needed in your
>  opinion?
>  
>  As use case goes, it would be a good start if you just submit something
>  you care about.
> >>> 
> >>> I mentioned on the call that a good first start could be a kconfig that
> >>> allows to build an hypervisor binary with only support for PVH and only
> >>> support for recent Intel machines, with the goal of minimizing the code
> >>> base to less than 100K LOC.
> >> 
> >> "With only support for PVH" (which really means HVM) we already have.
> >> "With only support for recent Intel machines" would require adding new
> >> Kconfig options first, to control Intel, AMD, etc separately, and to then
> >> further somehow separate "old" from "new" (which may turn out not
> >> very easy to do without a lot of #ifdef-ary or other code churn). I'm
> >> not aware of something like this existing on Linux either - all I'm aware
> >> of there is a means to control what -m option might be passed
> >> to the compiler, but without disabling any source code from getting
> >> compiled.
> > 
> > I was thinking along the lines of having options to disable drivers for
> > older timers and older interrupt controllers that are not needed on
> > recent machines.
> > 
> > 
> >> And then "with only support for recent Intel machines" could also imply
> >> HAP-only; disabling shadow code (which also is already possible) will
> >> alone save almost 10k LOC (counting .c files only).
> > 
> > I have just run `make cloc' on x86 with the smallest possible
> > configuration (HVM only):
> > 
> > 
> > http://cloc.sourceforge.net  v 1.60  T=0.87 s 
> > (370.3 files/s, 255808.4 lines/s)
> > ---
> > Language files  blankcomment   
> > code
> > ---
> > C  309  33238  29432 
> > 157001
> > Assembly14466531   
> > 2435
> > ---
> > SUM:   323  33704  29963 
> > 159436
> > ---
> > 
> > This is great! The last time I did the count it was above 220K LOC.  We
> > should make more noise about this -- it is a major.
> 
> @Wei: the binary size data is not that impressive. Would it be possible to do 
> the make cloc on HVM, PV and mixed?
> I can include this into the 

Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Wei Liu]

On Thu, Feb 14, 2019 at 10:32:31AM -0800, Stefano Stabellini wrote:
> 
> Do you have any other suggestions about things that could be removed to
> reach down to 100K LOC, in addition to what you have already written
> above (Intel/AMD, shadow)?

Turning off some of the decompression algorithms can probably save you
somewhere between 1K to 4K LOC.

This requires some code changes though.

Wei.

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

Re: [Xen-devel] MCE/EDAC Status/Updating?

[Jan Beulich]

>>> On 15.02.19 at 05:23,  wrote:
> The MCE/EDAC support code appears to be in rather poor shape.
> 
> The AMD code mentions Family 10h, which might have been available 10
> years ago.  They've likely been findable used with difficulty more
> recently, but no hardware made in the past 5 years matches this profile.

Well, Fam10 is mentioned explicitly, but as per the use of e.g.
mcheck_amd_famXX newer ones are supported by this code
as well.

> The Intel code has had some more recent minor updates.  Intel may have
> managed to keep their hardware supporting the interface used by Xen, and
> so the driver /may/ function on current Intel hardware.
> 
> Looks like both drivers originated with employees of the respective
> companies (I'm suspecting both were paid for by the corporations).
> 
> 
> Given the recent trends in Xen's development I'd tend to suggest going a
> different direction from the existing code.  The existing code was
> attempting to handle MCE/EDAC errors by emulating them and passing them
> to the effected domain.  Instead of this approach, let Domain 0 handle
> talking to MCE/EDAC hardware and merely have Xen decode addresses.
> 
> If errors/warnings are occuring, you need those reports centralized,
> which points to handling them in Domain 0.  If an uncorrectable error
> occurs, Domain 0 should choose whether to kill a given VM or panic the
> entire machine.  Either way, Domain 0 really needs to be alerted that
> hardware is misbehaving and may need to be replaced.

But the point of the virtualization is to allow guests to more or less
gracefully recover (at least as far as the theory of it goes), e.g. by
killing just a process, rather than getting blindly killed.

As to panic-ing the entire machine - if that's necessary, Dom0 is
unlikely to be in the right position. There's way too high a chance for
further things to go wrong until the event has even just arrived in
Dom0, let alone it having taken a decision.

> The other part is alerting Domain 0 is *far* more likely to get the
> correct type of attention.  A business owning a Domain U on a random
> machine, may run a kernel without MCE/EDAC support or could miss the
> entries in their system log, nor would they necessarily know the correct
> personel to contact about hardware failing.

Alerting Dom0 alongside the affected DomU may indeed be desirable,
but mainly for the purpose of logging, only as a last resort for the
purpose of killing a guest.

Jan



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

Re: [Xen-devel] [PATCH SpectreV1+L1TF v6 3/9] x86/hvm: block speculative out-of-bound accesses

[Norbert Manthey]

On 2/15/19 09:55, Jan Beulich wrote:
 On 15.02.19 at 09:05,  wrote:
>> On 2/12/19 15:14, Jan Beulich wrote:
>> On 12.02.19 at 15:05,  wrote:
 On 2/12/19 14:25, Jan Beulich wrote:
 On 08.02.19 at 14:44,  wrote:
>> @@ -4104,6 +4108,12 @@ static int hvmop_set_param(
>>  if ( a.index >= HVM_NR_PARAMS )
>>  return -EINVAL;
>>  
>> +/*
>> + * Make sure the guest controlled value a.index is bounded even 
>> during
>> + * speculative execution.
>> + */
>> +a.index = array_index_nospec(a.index, HVM_NR_PARAMS);
>> +
>>  d = rcu_lock_domain_by_any_id(a.domid);
>>  if ( d == NULL )
>>  return -ESRCH;
>> @@ -4370,6 +4380,12 @@ static int hvmop_get_param(
>>  if ( a.index >= HVM_NR_PARAMS )
>>  return -EINVAL;
>>  
>> +/*
>> + * Make sure the guest controlled value a.index is bounded even 
>> during
>> + * speculative execution.
>> + */
>> +a.index = array_index_nospec(a.index, HVM_NR_PARAMS);
> ... the usefulness of these two. To make forward progress it may
> be worthwhile to split off these two changes into a separate patch.
> If you're fine with this, I could strip these two before committing,
> in which case the remaining change is
> Reviewed-by: Jan Beulich 
 Taking apart the commit is fine with me. I will submit a follow up
 change that does not update the values but fixes the reads.
>>> As pointed out during the v5 discussion, I'm unconvinced that if
>>> you do so the compiler can't re-introduce the issue via CSE. I'd
>>> really like a reliable solution to be determined first.
>> I cannot give a guarantee what future compilers might do. Furthermore, I
>> do not want to wait until all/most compilers ship with such a
>> controllable guarantee.
> Guarantee? Future compilers are (hopefully) going to get better at
> optimizing, and hence are (again hopefully) going to find more
> opportunities for CSE. So the problem is going to get worse rather
> than better, and the changes you're proposing to re-instate are
> therefore more like false promises.

I do not want to dive into compilers future here. I would like to fix
the issue for todays compilers now and not wait until compilers evolved
one way or another. For this patch, the relevant information is whether
it should go in like this, or whether you want me to protect all the
reads instead. Is there more data I shall provide to help make this
decision?

Best,
Norbert

>
> Jan
>
>




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich
Ust-ID: DE 289 237 879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

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

Re: [Xen-devel] [PATCH] tools/libxendevicemodel: add xendevicemodel_modified_memory_bulk to map

[Paul Durrant]

Cc-ing Juergen, in case this can make 4.12...

> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 15 February 2019 10:02
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Ian Jackson
> ; Wei Liu 
> Subject: [PATCH] tools/libxendevicemodel: add
> xendevicemodel_modified_memory_bulk to map
> 
> Commit e3b93b3c595 "dmop: add xendevicemodel_modified_memory_bulk()" added
> the implementation to the library almost 2 years ago, but the function
> was not included in the map file, essentially making it useless. This
> patch rectifies the situation.
> 
> Signed-off-by: Paul Durrant 
> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/libs/devicemodel/Makefile  | 2 +-
>  tools/libs/devicemodel/libxendevicemodel.map | 5 +
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libs/devicemodel/Makefile
> b/tools/libs/devicemodel/Makefile
> index 5b2df7a18e..73cff6dbc4 100644
> --- a/tools/libs/devicemodel/Makefile
> +++ b/tools/libs/devicemodel/Makefile
> @@ -2,7 +2,7 @@ XEN_ROOT = $(CURDIR)/../../..
>  include $(XEN_ROOT)/tools/Rules.mk
> 
>  MAJOR= 1
> -MINOR= 2
> +MINOR= 3
>  SHLIB_LDFLAGS += -Wl,--version-script=libxendevicemodel.map
> 
>  CFLAGS   += -Werror -Wmissing-prototypes
> diff --git a/tools/libs/devicemodel/libxendevicemodel.map
> b/tools/libs/devicemodel/libxendevicemodel.map
> index 04797b239d..561c62deb4 100644
> --- a/tools/libs/devicemodel/libxendevicemodel.map
> +++ b/tools/libs/devicemodel/libxendevicemodel.map
> @@ -33,3 +33,8 @@ VERS_1.2 {
>   xendevicemodel_relocate_memory;
>   xendevicemodel_pin_memory_cacheattr;
>  } VERS_1.1;
> +
> +VERS_1.3 {
> + global:
> + xendevicemodel_modified_memory_bulk;
> +} VERS_1.2;
> --
> 2.20.1.2.gb21ebb671


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

Re: [Xen-devel] [PATCH SpectreV1+L1TF v6 8/9] common/grant_table: block speculative out-of-bound accesses

[Jan Beulich]

>>> On 15.02.19 at 10:55,  wrote:
> On 2/13/19 12:50, Jan Beulich wrote:
> On 08.02.19 at 14:44,  wrote:
>>> Guests can issue grant table operations and provide guest controlled
>>> data to them. This data is also used for memory loads. To avoid
>>> speculative out-of-bound accesses, we use the array_index_nospec macro
>>> where applicable. However, there are also memory accesses that cannot
>>> be protected by a single array protection, or multiple accesses in a
>>> row. To protect these, a nospec barrier is placed between the actual
>>> range check and the access via the block_speculation macro.
>>>
>>> As different versions of grant tables use structures of different size,
>>> and the status is encoded in an array for version 2, speculative
>>> execution might touch zero-initialized structures of version 2 while
>>> the table is actually using version 1.
>> Why zero-initialized? Did I still not succeed demonstrating to you
>> that speculation along a v2 path can actually overrun v1 arrays,
>> not just access parts with may still be zero-initialized?
> I believe a speculative v2 access can touch data that has been written
> by valid v1 accesses before, zero initialized data, or touch the NULL
> page. Given the macros for the access I do not believe that a v2 access
> can touch a page that is located behind a page holding valid v1 data.

I've given examples before of how I see this to be possible. Would
you mind going back to one of the instances, and explaining to me
how you do _not_ see any room for an overrun there? Having
given examples, I simply don't know how else I can explain this to
you without knowing at what specific part of the explanation we
diverge. (And no, I'm not excluding that I'm making up an issue
where there is none.)

>>> @@ -963,9 +965,13 @@ map_grant_ref(
>>>  PIN_FAIL(unlock_out, GNTST_bad_gntref, "Bad ref %#x for d%d\n",
>>>   op->ref, rgt->domain->domain_id);
>>>  
>>> +/* Make sure the above check is not bypassed speculatively */
>>> +block_speculation();
>>> +
>>>  act = active_entry_acquire(rgt, op->ref);
>>>  shah = shared_entry_header(rgt, op->ref);
>>> -status = rgt->gt_version == 1 ? &shah->flags : &status_entry(rgt, 
>>> op->ref);
>>> +status = evaluate_nospec(rgt->gt_version == 1) ? &shah->flags
>>> + : &status_entry(rgt, 
>>> op->ref);
>> Did you consider folding the two pairs of fences you emit into
>> one? Moving up the assignment to status ought to achieve this,
>> as then the block_speculation() could be dropped afaict.
>>
>> Then again you don't alter shared_entry_header(). If there's
>> a reason for you not having done so, then a second fence
>> here is needed in any event.
> Instead of the block_speculation() macro, I can also protect the op->ref
> usage before evaluate_nospec via the array_index_nospec function.

That's an option (as before), but doesn't help with shared_entry_header()'s
evaluation of gt_version.

>> What about the version check in nr_grant_entries()? It appears
>> to me as if at least its use in grant_map_exists() (which simply is
>> the first one I've found) is problematic without an adjustment.
>> Even worse, ...
>>
>>> @@ -1321,7 +1327,8 @@ unmap_common(
>>>  goto unlock_out;
>>>  }
>>>  
>>> -act = active_entry_acquire(rgt, op->ref);
>>> +act = active_entry_acquire(rgt, array_index_nospec(op->ref,
>>> +   
> nr_grant_entries(rgt)));
>> ... you add a use e.g. here to _guard_ against speculation.
> The adjustment you propose is to exchange the switch statement in
> nr_grant_entries with a if( evaluate_nospec( gt->gt_version == 1 ), so
> that the returned values are not speculated?

At this point I'm not proposing a particular solution. I'm just
putting on the table an issue left un-addressed. I certainly
wouldn't welcome converting the switch() to an if(), even if
right now there's no v3 on the horizon. (It's actually quite
the inverse: If someone came and submitted a patch to change
the various if()-s on gt_version to switch()-es, I'd welcome this.)

> Already before this
> modification the function is called and not inlined.

How does this matter when considering speculation?

> Do you want me to
> cache the value in functions that call this method regularly to avoid
> the penalty of the introduced lfence for each call?

That would go back to the question of what good it does to
latch value into a local variable when you don't know whether
the compiler will put that variable in a register or in memory.
IOW I'm afraid that to be on the safe side there's no way
around the repeated LFENCEs.

>> And what about _set_status(), unmap_common_complete(),
>> gnttab_grow_table(), gnttab_setup_table(),
>> release_grant_for_copy(), the 2nd one in acquire_grant_for_copy(),
>> several ones in gnttab_set_version(), gnttab_release_mappings(),
>> the 3rd one in mem_sharing_gref_to_gfn(), 

[Xen-devel] [PATCH] tools/libxendevicemodel: add xendevicemodel_modified_memory_bulk to map

[Paul Durrant]

Commit e3b93b3c595 "dmop: add xendevicemodel_modified_memory_bulk()" added
the implementation to the library almost 2 years ago, but the function
was not included in the map file, essentially making it useless. This
patch rectifies the situation.

Signed-off-by: Paul Durrant 
---
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/libs/devicemodel/Makefile  | 2 +-
 tools/libs/devicemodel/libxendevicemodel.map | 5 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/libs/devicemodel/Makefile b/tools/libs/devicemodel/Makefile
index 5b2df7a18e..73cff6dbc4 100644
--- a/tools/libs/devicemodel/Makefile
+++ b/tools/libs/devicemodel/Makefile
@@ -2,7 +2,7 @@ XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 MAJOR= 1
-MINOR= 2
+MINOR= 3
 SHLIB_LDFLAGS += -Wl,--version-script=libxendevicemodel.map
 
 CFLAGS   += -Werror -Wmissing-prototypes
diff --git a/tools/libs/devicemodel/libxendevicemodel.map 
b/tools/libs/devicemodel/libxendevicemodel.map
index 04797b239d..561c62deb4 100644
--- a/tools/libs/devicemodel/libxendevicemodel.map
+++ b/tools/libs/devicemodel/libxendevicemodel.map
@@ -33,3 +33,8 @@ VERS_1.2 {
xendevicemodel_relocate_memory;
xendevicemodel_pin_memory_cacheattr;
 } VERS_1.1;
+
+VERS_1.3 {
+   global:
+   xendevicemodel_modified_memory_bulk;
+} VERS_1.2;
-- 
2.20.1.2.gb21ebb671


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

Re: [Xen-devel] [PATCH SpectreV1+L1TF v6 8/9] common/grant_table: block speculative out-of-bound accesses

[Norbert Manthey]

On 2/13/19 12:50, Jan Beulich wrote:
 On 08.02.19 at 14:44,  wrote:
>> Guests can issue grant table operations and provide guest controlled
>> data to them. This data is also used for memory loads. To avoid
>> speculative out-of-bound accesses, we use the array_index_nospec macro
>> where applicable. However, there are also memory accesses that cannot
>> be protected by a single array protection, or multiple accesses in a
>> row. To protect these, a nospec barrier is placed between the actual
>> range check and the access via the block_speculation macro.
>>
>> As different versions of grant tables use structures of different size,
>> and the status is encoded in an array for version 2, speculative
>> execution might touch zero-initialized structures of version 2 while
>> the table is actually using version 1.
> Why zero-initialized? Did I still not succeed demonstrating to you
> that speculation along a v2 path can actually overrun v1 arrays,
> not just access parts with may still be zero-initialized?
I believe a speculative v2 access can touch data that has been written
by valid v1 accesses before, zero initialized data, or touch the NULL
page. Given the macros for the access I do not believe that a v2 access
can touch a page that is located behind a page holding valid v1 data.
>
>> @@ -203,8 +204,9 @@ static inline unsigned int nr_status_frames(const struct 
>> grant_table *gt)
>>  }
>>  
>>  #define MAPTRACK_PER_PAGE (PAGE_SIZE / sizeof(struct grant_mapping))
>> -#define maptrack_entry(t, e) \
>> -((t)->maptrack[(e)/MAPTRACK_PER_PAGE][(e)%MAPTRACK_PER_PAGE])
>> +#define maptrack_entry(t, e)
>>\
>> +((t)->maptrack[array_index_nospec(e, (t)->maptrack_limit)   
>>\
>> + 
>> /MAPTRACK_PER_PAGE][(e)%MAPTRACK_PER_PAGE])
> I would have hoped that the pointing out of similar formatting
> issues elsewhere would have had an impact here as well, but
> I see the / is still wrongly at the beginning of a line, and is still
> not followed by a blank (would be "preceded" if it was well
> placed). And while I realize it's only code movement, adding
> the missing blanks around % would be appreciated too at this
> occasion.
I will move the "/" to the upper line, and add the space around the "%".
>
>> @@ -963,9 +965,13 @@ map_grant_ref(
>>  PIN_FAIL(unlock_out, GNTST_bad_gntref, "Bad ref %#x for d%d\n",
>>   op->ref, rgt->domain->domain_id);
>>  
>> +/* Make sure the above check is not bypassed speculatively */
>> +block_speculation();
>> +
>>  act = active_entry_acquire(rgt, op->ref);
>>  shah = shared_entry_header(rgt, op->ref);
>> -status = rgt->gt_version == 1 ? &shah->flags : &status_entry(rgt, 
>> op->ref);
>> +status = evaluate_nospec(rgt->gt_version == 1) ? &shah->flags
>> + : &status_entry(rgt, 
>> op->ref);
> Did you consider folding the two pairs of fences you emit into
> one? Moving up the assignment to status ought to achieve this,
> as then the block_speculation() could be dropped afaict.
>
> Then again you don't alter shared_entry_header(). If there's
> a reason for you not having done so, then a second fence
> here is needed in any event.
Instead of the block_speculation() macro, I can also protect the op->ref
usage before evaluate_nospec via the array_index_nospec function.
>
> What about the version check in nr_grant_entries()? It appears
> to me as if at least its use in grant_map_exists() (which simply is
> the first one I've found) is problematic without an adjustment.
> Even worse, ...
>
>> @@ -1321,7 +1327,8 @@ unmap_common(
>>  goto unlock_out;
>>  }
>>  
>> -act = active_entry_acquire(rgt, op->ref);
>> +act = active_entry_acquire(rgt, array_index_nospec(op->ref,
>> +   
>> nr_grant_entries(rgt)));
> ... you add a use e.g. here to _guard_ against speculation.
The adjustment you propose is to exchange the switch statement in
nr_grant_entries with a if( evaluate_nospec( gt->gt_version == 1 ), so
that the returned values are not speculated? Already before this
modification the function is called and not inlined. Do you want me to
cache the value in functions that call this method regularly to avoid
the penalty of the introduced lfence for each call?
>
> And what about _set_status(), unmap_common_complete(),
> gnttab_grow_table(), gnttab_setup_table(),
> release_grant_for_copy(), the 2nd one in acquire_grant_for_copy(),
> several ones in gnttab_set_version(), gnttab_release_mappings(),
> the 3rd one in mem_sharing_gref_to_gfn(), gnttab_map_frame(),
> and gnttab_get_status_frame()?

Protecting the function itself should allow to not modify the
speculation guards in these functions. I would have to check each of
them, whether the guest actually has control, and whether it makes sense
to introduce a _nospec variant of the nr_gr

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

[osstest service owner]

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

Failures and problems with tests :-(

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 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

version targeted for testing:
 xen  f178a00c30173c0b268d99160e19ad299b1823a2
baseline version:
 xen  455301716e1ff358cb79367213003fba771dd466

Last test of basis   133005  2019-02-07 14:00:32 Z7 days
Failing since133011  2019-02-07 18:00:36 Z7 days   46 attempts
Testing same since   133200  2019-02-12 16:00:56 Z2 days   23 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Kevin Tian 
  Michael Tautschnig 
  Norbert Manthey 
  Norbert Manthey 
  Stefano Stabellini 
  Stefano Stabellini 
  Tim Deegan 
  Wei Liu 

jobs:
 build-arm64-xsm  broken  
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 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

broken-job build-arm64-xsm broken
broken-step build-arm64-xsm host-install(4)

Not pushing.


commit f178a00c30173c0b268d99160e19ad299b1823a2
Author: Norbert Manthey 
Date:   Tue Feb 12 15:20:15 2019 +0100

x86/hvm: block speculative out-of-bound accesses

There are multiple arrays in the HVM interface that are accessed
with indices that are provided by the guest. To avoid speculative
out-of-bound accesses, we use the array_index_nospec macro.

When blocking speculative out-of-bound accesses, we can classify arrays
into dynamic arrays and static arrays. Where the former are allocated
during run time, the size of the latter is known during compile time.
On static arrays, compiler might be able to block speculative accesses
in the future.

This is part of the speculative hardening effort.

Reported-by: Pawel Wieczorkiewicz 
Signed-off-by: Norbert Manthey 
Reviewed-by: Jan Beulich 
Release-acked-by: Juergen Gross 

commit 56d8d0119d270f846c6c4943712b8a21fbe5d4d0
Author: Jan Beulich 
Date:   Tue Feb 12 11:54:57 2019 +0100

VMX: don't ignore P2M setup error

set_mmio_p2m_entry() may fail, in particular with -ENOMEM. Don't ignore
such an error, but instead cause domain creation to fail in such a case.

Signed-off-by: Jan Beulich 
Acked-by: Andrew Cooper 
Acked-by: Kevin Tian 
Release-acked-by: Juergen Gross 

commit 88b92c3820cffed4b4abeb139edc2cbd8286cb12
Author: Juergen Gross 
Date:   Tue Feb 12 11:54:07 2019 +0100

iommu: fix iommu_ops initialization

Commit 32a5ea00ec75ef53e ("IOMMU/x86: remove indirection from certain
IOMMU hook accesses") introduced iommu_ops initialized at boot time
with data declared as __initconstrel.

On Intel systems there is another path where iommu_ops is initialized
and this path is relevant on resume after returning from system suspend.
As the initialization data is no longer accessible in this case that
second initialization must be dropped in case the system isn't just
booting.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 
Acked-by: Kevin Tian 
Release-acked-by: Juergen Gross 

commit 09fc4de4a8ebb389641b8b8a632efcb7ca880e08
Author: Norbert Manthey 
Date:   Wed Feb 6 15:09:33 2019 +0100

asm: h