[Xen-devel] [qemu-upstream-4.6-testing baseline-only test] 68473: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68473 qemu-upstream-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68473/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-armhf-armhf-libvirt   13 saverestore-support-check fail baseline untested
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail baseline 
untested
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail baseline 
untested
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop   fail baseline untested
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail baseline 
untested
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeatfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 qemuuba9175c5bde6796851d3b9d888ee488fd0257d05

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-xl-xsm  pass
 test-armhf-armhf-xl-xsm  pass
 test-amd64-i386-xl-xsm   pass
 test-amd64-amd64-qemuu-nested-amdfail
 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3  3 host-install(3)  broken REGR. vs. 104662
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)  broken REGR. vs. 104662
 test-amd64-amd64-pygrub   3 host-install(3)broken REGR. vs. 104662
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken 
REGR. vs. 104662
 test-armhf-armhf-xl-arndale   9 debian-install   fail REGR. vs. 104662
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 104662

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 104662
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 104662
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104662
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 104662
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 104662
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 104662

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  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-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu3aca12f841fcd6f3a7477076dad0d564360500de
baseline version:
 qemuuc7f1cf01b8245762ca5864e835d84f6677ae8b1f

Last test of basis   104662  2017-01-25 20:13:58 Z2 days
Failing since104761  2017-01-27 12:15:22 Z0 days2 attempts
Testing same since   104788  2017-01-27 23:46:07 Z0 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Cornelia Huck 
  Cédric Le Goater 
  Daniel P. Berrange 
  David Engraf 
  Fam 

[Xen-devel] [xen-unstable baseline-only test] 68470: tolerable trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68470 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68470/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-arm64-arm64-libvirt-xsm  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-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_host  fail baseline untested
 test-armhf-armhf-libvirt-xsm 11 guest-start fail baseline untested
 test-armhf-armhf-libvirt   13 saverestore-support-check fail baseline untested
 test-amd64-amd64-migrupgrade 11 host-ping-check-xen/src_host fail baseline 
untested
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail baseline 
untested
 test-armhf-armhf-libvirt   15 guest-start/debian.repeat fail baseline untested
 test-amd64-i386-qemuu-rhel6hvm-amd 14 leak-check/check  fail baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop   fail baseline untested
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 9 windows-install fail baseline 
untested
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  e225a1c7c06037e4f938efa43d4407e7abb088c1

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  broken  
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken REGR. vs. 
104681
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
104681
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 104681
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 104681
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 104681
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 104681
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 104681
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 104681
 test-amd64-i386-qemuu-rhel6hvm-intel  9 redhat-install   fail REGR. vs. 104681
 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
104681
 test-amd64-i386-qemut-rhel6hvm-intel  9 redhat-install   fail REGR. vs. 104681
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 104681
 test-amd64-i386-qemut-rhel6hvm-amd  9 redhat-install fail REGR. vs. 104681
 test-amd64-i386-qemuu-rhel6hvm-amd  9 redhat-install fail REGR. vs. 104681
 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 104681
 test-armhf-armhf-xl-vhd  10 guest-start  fail REGR. vs. 104681
 test-amd64-i386-xl-qemut-winxpsp3  9 windows-install fail REGR. vs. 104681
 test-amd64-i386-xl-qemuu-winxpsp3  9 windows-install fail REGR. vs. 104681
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 
104681
 test-amd64-i386-xl-qemuu-win7-amd64  9 windows-install   fail REGR. vs. 104681
 test-amd64-i386-xl-qemut-win7-amd64  9 windows-install   fail REGR. vs. 104681

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 104681
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 104681
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 104681
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 104681
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 104681
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 104681

Tests which did not succeed, but are not blocking:
 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  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 

[Xen-devel] [qemu-upstream-unstable baseline-only test] 68472: tolerable trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68472 qemu-upstream-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68472/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-arm64-arm64-libvirt-xsm  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-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-armhf-armhf-libvirt   13 saverestore-support-check fail baseline untested
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail baseline 
untested
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail baseline 
untested
 test-amd64-amd64-xl-qcow221 leak-check/checkfail baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop   fail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop  fail baseline untested
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail baseline 
untested
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 qemuu5cd2e1739763915e6b4c247eef71f948dc808bd5

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  broken  
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  blocked 
 

[Xen-devel] [qemu-mainline baseline-only test] 68471: tolerable trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68471 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68471/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-arm64-arm64-libvirt-xsm  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-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  3 host-install(3)   broken baseline untested
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-boot   fail baseline untested
 test-armhf-armhf-libvirt   13 saverestore-support-check fail baseline untested
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail baseline 
untested
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail baseline 
untested
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail baseline 
untested
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeatfail   never pass
 test-armhf-armhf-libvirt 15 guest-start/debian.repeatfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 qemuu3879284d6517dc22529395bdb259f4183b589127

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

[Xen-devel] [linux-linus test] 104767: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail REGR. 
vs. 59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-winxpsp3 3 host-install(3) broken in 104741 pass in 
104767
 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken pass in 
104741
 test-amd64-amd64-xl-credit2   3 host-install(3)  broken pass in 104741
 test-amd64-i386-libvirt   3 host-install(3)  broken pass in 104741
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken 
pass in 104741
 test-amd64-amd64-xl-qemut-debianhvm-amd64 13 guest-localmigrate fail in 104741 
pass in 104767
 test-amd64-amd64-xl-qemut-winxpsp3 15 guest-localmigrate/x10 fail in 104741 
pass in 104767
 test-armhf-armhf-xl-multivcpu  6 xen-boot  fail pass in 104741
 test-armhf-armhf-xl-rtds  6 xen-boot   fail pass in 104741
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail pass 
in 104741
 test-amd64-i386-xl-qemuu-win7-amd64 12 guest-saverestore   fail pass in 104741

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken 
baseline untested
 test-amd64-amd64-pygrub   3 host-install(3)   broken baseline untested
 test-amd64-i386-libvirt-pair 3 host-install/src_host(3) broken baseline 
untested
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-armhf-armhf-libvirt-raw  6 xen-bootfail baseline untested
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 test-amd64-i386-rumprun-i386 16 rumprun-demo-xenstorels/xenstorels.repeat fail 
in 104741 baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail in 104741 like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  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-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt 12 migrate-support-check fail in 104741 never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 104741 never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail in 104741 never 
pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail in 104741 
never pass
 test-armhf-armhf-xl-rtds12 migrate-support-check fail in 104741 never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 104741 never pass
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass

version targeted for 

[Xen-devel] [xen-4.6-testing baseline-only test] 68469: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68469 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68469/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-xtf-amd64-amd64-2  20 xtf/test-hvm32-invlpg~shadow fail baseline untested
 test-xtf-amd64-amd64-2 32 xtf/test-hvm32pae-invlpg~shadow fail baseline 
untested
 test-xtf-amd64-amd64-5  20 xtf/test-hvm32-invlpg~shadow fail baseline untested
 test-xtf-amd64-amd64-2  43 xtf/test-hvm64-invlpg~shadow fail baseline untested
 test-xtf-amd64-amd64-5 32 xtf/test-hvm32pae-invlpg~shadow fail baseline 
untested
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail baseline 
untested
 test-armhf-armhf-libvirt   13 saverestore-support-check fail baseline untested
 test-xtf-amd64-amd64-5  43 xtf/test-hvm64-invlpg~shadow fail baseline untested
 test-xtf-amd64-amd64-1  20 xtf/test-hvm32-invlpg~shadow fail baseline untested
 test-xtf-amd64-amd64-1 32 xtf/test-hvm32pae-invlpg~shadow fail baseline 
untested
 test-xtf-amd64-amd64-1  43 xtf/test-hvm64-invlpg~shadow fail baseline untested
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail baseline 
untested
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop  fail baseline untested
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop   fail baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop   fail baseline untested
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail baseline 
untested
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install   fail baseline untested
 test-xtf-amd64-amd64-4   62 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-3   62 xtf/test-pv32pae-xsa-194 fail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-2   62 xtf/test-pv32pae-xsa-194 fail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-xtf-amd64-amd64-5   62 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-1   62 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  09f521a077024d5955d766eef7a040d2af928ec2

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt 

[Xen-devel] [PATCH] xen: credit2: non Credit2 pCPUs are ok during shutdown/suspend.

[Dario Faggioli]

Commit 7478ebe1602e6 ("xen: credit2: fix shutdown/suspend
when playing with cpupools"), while doing the right thing
for actual code, forgot to update the ASSERT()s accordingly,
in csched2_vcpu_migrate().

In fact, as stated there already, during shutdown/suspend,
we must allow a Credit2 vCPU to temporarily migrate to a
non Credit2 BSP, without any ASSERT() triggering.

Move them down, after the check for whether or not we are
shutting down, where the assumption that the pCPU must be
valid Credit2 ones, is valid.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Anshul Makkar 
Cc: Jan Beulich 
---
If 7478ebe1602e is backported, this one should be as well.

Sorry for this. I'm sure I tested, so I don't know how it could happened... I
must have forgotten debug=n when testing this case. :-(
---
 xen/common/sched_credit2.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index b2f2b17..85f36bc 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -1953,10 +1953,6 @@ csched2_vcpu_migrate(
 struct csched2_runqueue_data *trqd;
 s_time_t now = NOW();
 
-/* Check if new_cpu is valid */
-ASSERT(cpumask_test_cpu(new_cpu, _PRIV(ops)->initialized));
-ASSERT(cpumask_test_cpu(new_cpu, vc->cpu_hard_affinity));
-
 /*
  * Being passed a target pCPU which is outside of our cpupool is only
  * valid if we are shutting down (or doing ACPI suspend), and we are
@@ -1985,6 +1981,10 @@ csched2_vcpu_migrate(
 return;
 }
 
+/* If here, new_cpu must be a valid Credit2 pCPU, and in our affinity. */
+ASSERT(cpumask_test_cpu(new_cpu, _PRIV(ops)->initialized));
+ASSERT(cpumask_test_cpu(new_cpu, vc->cpu_hard_affinity));
+
 trqd = RQD(ops, new_cpu);
 
 /*


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

[Xen-devel] [xen-4.5-testing baseline-only test] 68468: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68468 xen-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68468/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-xtf-amd64-amd64-2  20 xtf/test-hvm32-invlpg~shadow fail baseline untested
 test-xtf-amd64-amd64-2 32 xtf/test-hvm32pae-invlpg~shadow fail baseline 
untested
 test-xtf-amd64-amd64-2  43 xtf/test-hvm64-invlpg~shadow fail baseline untested
 test-xtf-amd64-amd64-5  20 xtf/test-hvm32-invlpg~shadow fail baseline untested
 test-xtf-amd64-amd64-5 32 xtf/test-hvm32pae-invlpg~shadow fail baseline 
untested
 test-xtf-amd64-amd64-3  20 xtf/test-hvm32-invlpg~shadow fail baseline untested
 test-xtf-amd64-amd64-5  43 xtf/test-hvm64-invlpg~shadow fail baseline untested
 test-xtf-amd64-amd64-3 32 xtf/test-hvm32pae-invlpg~shadow fail baseline 
untested
 test-armhf-armhf-libvirt   13 saverestore-support-check fail baseline untested
 test-xtf-amd64-amd64-3  43 xtf/test-hvm64-invlpg~shadow fail baseline untested
 test-xtf-amd64-amd64-4   53 leak-check/checkfail baseline untested
 test-amd64-amd64-xl-rtds  6 xen-bootfail baseline untested
 test-xtf-amd64-amd64-2   53 leak-check/checkfail baseline untested
 test-xtf-amd64-amd64-1   53 leak-check/checkfail baseline untested
 test-xtf-amd64-amd64-5   53 leak-check/checkfail baseline untested
 test-xtf-amd64-amd64-3   53 leak-check/checkfail baseline untested
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail 
baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop  fail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail baseline 
untested
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install   fail baseline untested
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-xtf-amd64-amd64-2   52 xtf/test-hvm64-xsa-195   fail   never pass
 test-armhf-armhf-libvirt-raw 10 guest-start  fail   never pass
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-3   52 xtf/test-hvm64-xsa-195   fail   never pass
 test-armhf-armhf-xl-vhd  10 guest-start  fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 xen  2b17bf45470bf742d78a22116e3b7ec1a3213c45

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  pass
 

Re: [Xen-devel] [PATCH v4] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

[Stefano Stabellini]

On Fri, 27 Jan 2017, Julien Grall wrote:
> Hi Stefano,
> 
> On 27/01/2017 20:41, Stefano Stabellini wrote:
> > On Fri, 27 Jan 2017, Tamas K Lengyel wrote:
> > > When the toolstack modifies memory of a running ARM VM it may happen
> > > that the underlying memory of a current vCPU PC is changed. Without
> > > flushing the icache the vCPU may continue executing stale instructions.
> > > 
> > > Also expose the xc_domain_cacheflush through xenctrl.h.
> > > 
> > > Signed-off-by: Tamas K Lengyel 
> > > Acked-by: Wei Liu 
> > > ---
> > > Cc: Ian Jackson 
> > > Cc: Stefano Stabellini 
> > > Cc: Julien Grall 
> > > 
> > > Note: patch has been verified to solve stale icache issues on the
> > >   HiKey platform.
> > 
> > Sorry to come in the discussion late, but there has been a lot of
> > traffic on this in the last two days. The patch is clear and well
> > written, thanks for that. However, I am concerned about the performance
> > impact of the icache flush.
> > 
> > What stale icache issues is it trying to solve?
> 
> The icache issue for Tamas is when the monitor application is writing into the
> guest memory.
> 
> Even if we put aside this problem, the instruction cache is not able to snoop
> into the data cache. So if we don't invalidate the instruction cache, the
> guest may see stale instruction when booting or may requesting memory and then
> use it (e.g ballooning).

I understand. We probably need to add an icache flush on certain
ballooning operations.


> > This patch introduces the icache flush in flush_page_to_ram, which is
> > called in two instances:
> > 
> > 1) arch_do_domctl(XEN_DOMCTL_cacheflush) -> p2m_cache_flush ->
> > flush_page_to_ram
> > 
> > 2) alloc_xenheap_pages
> > 
> > It looks like we don't need the icache flush in 2). We should probably
> > avoid icache flushes for that. Julien, do you agree?
> 
> I disagree, in both case the full icache flush is necessary. As Tamas wrote in
> the comment, it is not possible to invalidate by VA because it does not ensure
> that all aliases will be removed in non-PIPT cache.
> 
> For the first instance, we could avoid the icache flush in each DOMCTL by
> flushing the instruction cache before the domain is running for the first
> time.

This seems like a good way forward.


> For the second instance, we have no other choice.

Most alloc_heap_pages (alloc_xenheap_pages and alloc_domheap_pages) are
done at domain initialization, so they would also be taken care by
flushing the instruction cache before the domain is running. There are
only very few exceptions to that, the main one being ballooning, and we
need another icache flush in that case. But I think we should avoid
doing global icache flushes every time alloc_heap_pages is called.


> > I am also wondering about all the libxc/libxl callers, many of whom
> > don't need an icache flush. Ideally we would have an argument in
> > XEN_DOMCTL_cacheflush to specify the type of cache flush we need,
> > similar to GNTTABOP_cache_flush.
> 
> Unless the instruction cache will be flushed before the guest is booting, all
> the callers of DOMCTL_cacheflush will require the invalidation.

DOMCTL_cacheflush is called several time during the domain build, it is
certainly better to do the icache flush once, rather than many times.

If we decide to perform one icache flush at domain creation in Xen at
the right time, we still need XEN_DOMCTL_cacheflush in its current form
to flush the dcache.

Also we still need a way to flush the icache to solve Tamas' problem
with mem_access at run time.

As a consequence, even after introducing one icache flush in Xen at
domain creation, I think we still need a new "icache flush" flag in
XEN_DOMCTL_cacheflush: all the current callers would not use it, but
mem_access userspace components will be able to use it.


> Looking at GNTTABOP_cache_flush, I think we will also need to invalidate the
> instruction cache (or at least partially).

GNTTABOP_cache_flush is used for DMA coherency with devices. Maybe there
are cases where an icache flush might be needed, but Linux doesn't use
it that way. In fact, if Linux needed a icache flush, it would need it
on native as well, but it does not.

For completeness, we could add a flag to the hypercall to request an
icache flush, but today it would be left unused.

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

Re: [Xen-devel] [PATCH v3 2/3] xen-platform: add support for unplugging NVMe disks...

[Stefano Stabellini]

On Thu, 26 Jan 2017, Paul Durrant wrote:
> ...not just IDE and SCSI.
> 
> This patch allows the Xen tool-stack to fully support of NVMe as an
> emulated disk type. See [1] for the relevant tool-stack patch discussion.
> 
> [1] https://lists.xen.org/archives/html/xen-devel/2017-01/msg01225.html
> 
> Signed-off-by: Paul Durrant 

Reviewed-by: Stefano Stabellini 

I queued the whole series. FYI I am waiting for another patch to fix a
regression before sending a pull request.


> Cc: Stefano Stabellini 
> Cc: Anthony Perard 
> Cc: "Michael S. Tsirkin" 
> Cc: Paolo Bonzini 
> Cc: Richard Henderson 
> Cc: Eduardo Habkost 
> 
> v3:
> - Add reference to xen-devel patch discussion in commit message as
>   requested by Stefano.
> ---
>  hw/i386/xen/xen_platform.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c
> index f50915f..7d41ebb 100644
> --- a/hw/i386/xen/xen_platform.c
> +++ b/hw/i386/xen/xen_platform.c
> @@ -120,6 +120,7 @@ static void unplug_disks(PCIBus *b, PCIDevice *d, void *o)
>  break;
>  
>  case PCI_CLASS_STORAGE_SCSI:
> +case PCI_CLASS_STORAGE_EXPRESS:
>  object_unparent(OBJECT(d));
>  break;
>  
> -- 
> 2.1.4
> 

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

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

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)  broken REGR. vs. 104662
 test-amd64-amd64-pygrub   3 host-install(3)broken REGR. vs. 104662
 test-amd64-amd64-xl-qemuu-winxpsp3  3 host-install(3)  broken REGR. vs. 104662
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken 
REGR. vs. 104662

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 104662
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 104662
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104662
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 104662
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 104662
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 104662

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  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-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuub944b2ec46702651ac89a166840ddaff2a11fb5a
baseline version:
 qemuuc7f1cf01b8245762ca5864e835d84f6677ae8b1f

Last test of basis   104662  2017-01-25 20:13:58 Z2 days
Testing same since   104761  2017-01-27 12:15:22 Z0 days1 attempts


People who touched revisions under test:
  Fam Zheng 
  Max Reitz 
  Peter Maydell 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  fail
 

Re: [Xen-devel] [PATCH] MAINTAINERS: Update xen-devel mailing list address

[Stefano Stabellini]

On Wed, 25 Jan 2017, Anthony PERARD wrote:
> On Mon, Nov 28, 2016 at 10:14:00AM -0800, Stefano Stabellini wrote:
> > On Fri, 25 Nov 2016, Anthony PERARD wrote:
> > > Signed-off-by: Anthony PERARD 
> > 
> > Acked-by: Stefano Stabellini 
> 
> Hi,
> 
> This patch has never been applied.

Sorry, it's on my queue now.

> 
> > >  MAINTAINERS | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 4a60579..1379317 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -309,7 +309,7 @@ Guest CPU Cores (Xen):
> > >  X86
> > >  M: Stefano Stabellini 
> > >  M: Anthony Perard 
> > > -L: xen-de...@lists.xensource.com
> > > +L: xen-de...@lists.xenproject.org
> > >  S: Supported
> > >  F: xen-*
> > >  F: */xen*
> > > -- 
> > > Anthony PERARD
> > > 
> 
> -- 
> Anthony PERARD
> 

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

Re: [Xen-devel] [DOC v3] Xen transport for 9pfs

[Stefano Stabellini]

On Wed, 25 Jan 2017, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 05, 2017 at 04:54:37PM -0800, Stefano Stabellini wrote:
> > Changes in v3:
> > - clarify a few statements
> > - rename port- to event-channel-
> > - use grant_ref_t ref[1] instead of ref[]
> > 
> > Changes in v2:
> > - fix copy/paste error
> > - rename ring-ref- to ring-ref
> > - fix memory barriers
> > - add "verify prod/cons against local copy"
> > - add a paragraph on high level design
> > - add a note on the maximum possible max-ring-page-order value
> > - add mechanisms to avoid unnecessary evtchn notifications
> > 
> > ---
> > 
> > # Xen transport for 9pfs version 1 
> > 
> > ## Background
> > 
> > 9pfs is a network filesystem protocol developed for Plan 9. 9pfs is very
> > simple and describes a series of commands and responses. It is
> > completely independent from the communication channels, in fact many
> > clients and servers support multiple channels, usually called
> > "transports". For example the Linux client supports tcp and unix
> > sockets, fds, virtio and rdma.
> > 
> > 
> > ### 9pfs protocol
> > 
> > This document won't cover the full 9pfs specification. Please refer to
> > this [paper] and this [website] for a detailed description of it.
> > However it is useful to know that each 9pfs request and response has the
> > following header:
> > 
> > struct header {
> > uint32_t size;
> > uint8_t id;
> > uint16_t tag;
> > } __attribute__((packed));
> > 
> > 0 4  57
> > +-+--++
> > |  size   |id|tag |
> > +-+--++
> > 
> > - *size*
> > The size of the request or response.
> > 
> > - *id*
> > The 9pfs request or response operation.
> > 
> > - *tag*
> > Unique id that identifies a specific request/response pair. It is used
> > to multiplex operations on a single channel.
> > 
> > It is possible to have multiple requests in-flight at any given time.
> > 
> > 
> > ## Rationale
> > 
> > This document describes a Xen based transport for 9pfs, in the
> > traditional PV frontend and backend format. The PV frontend is used by
> > the client to send commands to the server. The PV backend is used by the
> > 9pfs server to receive commands from clients and send back responses.
> > 
> > The transport protocol supports multiple rings up to the maximum
> > supported by the backend. The size of every ring is also configurable
> > and can span multiple pages, up to the maximum supported by the backend
> > (although it cannot be more than 2MB). The design is to exploit
> > parallelism at the vCPU level and support multiple outstanding requests
> > simultaneously.
> > 
> > This document does not cover the 9pfs client/server design or
> > implementation, only the transport for it.
> 
> What about the Paul's binary protocol..
> 
> https://patchwork.kernel.org/patch/7968201/ ?
> 
> He was using it as a side-channel for hash functions for the network
> stack (Windows -> Linux)? Could that be used?

I haven't read it in details but:

   * The control ring uses a fixed request/response message size and is
   * balanced (i.e. one request to one response)

This protocol needs to be able to handle messages of different sizes.


> Or I suppose vice-versa - could Paul use your work here
> instead of this network specific netif_ctrl?

Yes, this protocol can be used to carry any data. But specific messages
need to be defined for each implementation. In this case, the messages
are defined by 9p.


> > ## Xenstore
> > 
> > The frontend and the backend connect via xenstore to exchange
> > information. The toolstack creates front and back nodes with state
> > [XenbusStateInitialising]. The protocol node name is **9pfs**.
> 
> Since this an opaque protocol to just push data back and forth
> could it be more generic?
> 
> [edit: I see now the 9pfs specific entries so nevermind]

Actually, I think it could be made generic and it is in my todo list.
In all honesty, it is not your fault, but given the speed of review of
new Xen PV protocols, I am wary of adding another one to the queue.


> > Multiple rings are supported for each frontend and backend connection.
> > 
> > The following are mandatory xenstore nodes for this protocol.
> > 
> > 
> > ### Frontend XenBus Nodes
> 
> Could I convience you to have Backend XenBus Nodes first?

Sure


> > 
> > num-rings
> >  Values: 
> > 
> >  Number of rings. It needs to be lower or equal to max-rings.
> > 
> > event-channel- (event-channel-0, event-channel-1, etc)
> >  Values: 
> > 
> >  The identifier of the Xen event channel used to signal activity
> >  in the ring buffer. One for each ring.
> > 
> > ring-ref (ring-ref0, ring-ref1, etc)
> >  Values: 
> > 
> >  The Xen grant reference granting permission for the backend to
> >  map a page with information to setup a share ring. One for each
> >  ring.
> > 
> 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-credit2  17 guest-localmigrate/x10   fail REGR. vs. 104616
 test-amd64-amd64-xl  17 guest-localmigrate/x10   fail REGR. vs. 104616
 test-amd64-i386-xl-xsm   17 guest-localmigrate/x10   fail REGR. vs. 104616
 test-amd64-i386-xl   17 guest-localmigrate/x10 fail in 104640 REGR. vs. 104616

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken 
pass in 104640
 test-amd64-amd64-xl-qemut-debianhvm-amd64 3 host-install(3) broken pass in 
104640
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3)  broken pass in 104640
 test-amd64-i386-freebsd10-amd64  3 host-install(3)   broken pass in 104640
 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken pass in 
104640
 test-amd64-i386-qemut-rhel6hvm-amd  3 host-install(3)broken pass in 104640
 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate fail in 104640 pass in 
104752
 test-amd64-amd64-xl-credit2 15 guest-localmigrate fail in 104640 pass in 104752
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail in 104640 
pass in 104752
 test-amd64-i386-xl   15 guest-localmigrate fail pass in 104640
 test-amd64-i386-libvirt  14 guest-saverestore  fail pass in 104640

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 14 guest-saverestore   fail blocked in 104616
 test-armhf-armhf-libvirt   13 saverestore-support-check fail blocked in 104616
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail blocked in 
104616
 test-armhf-armhf-xl-rtds   15 guest-start/debian.repeat fail blocked in 104616
 test-armhf-armhf-libvirt-raw  9 debian-di-install   fail blocked in 104616
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail in 104640 
blocked in 104616
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 104616
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104616

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  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-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw 11 migrate-support-check fail in 104640 never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 

Re: [Xen-devel] [RFC XEN PATCH 16/16] tools/libxl: initiate pmem mapping via qmp callback

[Konrad Rzeszutek Wilk]

On Mon, Oct 10, 2016 at 08:32:35AM +0800, Haozhong Zhang wrote:
> QMP command 'query-nvdimms' is used by libxl to get the backend, the
> guest SPA and size of each vNVDIMM device, and then libxl starts mapping
> backend to guest for each vNVDIMM device.
> 
> Signed-off-by: Haozhong Zhang 
> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/libxl/libxl_qmp.c | 64 
> +
>  1 file changed, 64 insertions(+)
> 
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index f8addf9..02edd09 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -26,6 +26,7 @@
>  
>  #include "_libxl_list.h"
>  #include "libxl_internal.h"
> +#include "libxl_nvdimm.h"
>  
>  /* #define DEBUG_RECEIVED */
>  
> @@ -1146,6 +1147,66 @@ out:
>  return rc;
>  }
>  
> +static int qmp_register_nvdimm_callback(libxl__qmp_handler *qmp,
> +const libxl__json_object *o,
> +void *unused)
> +{
> +GC_INIT(qmp->ctx);
> +const libxl__json_object *obj = NULL;
> +const libxl__json_object *sub_obj = NULL;
> +int i = 0;

unsigned int.
> +const char *mem_path;
> +uint64_t slot, spa, length;
> +int ret = 0;
> +
> +for (i = 0; (obj = libxl__json_array_get(o, i)); i++) {
> +if (!libxl__json_object_is_map(obj))
> +continue;
> +
> +sub_obj = libxl__json_map_get("slot", obj, JSON_INTEGER);
> +slot = libxl__json_object_get_integer(sub_obj);
> +
> +sub_obj = libxl__json_map_get("mem-path", obj, JSON_STRING);
> +mem_path = libxl__json_object_get_string(sub_obj);
> +if (!mem_path) {
> +LOG(ERROR, "No mem-path is specified for NVDIMM #%" PRId64, 
> slot);
> +ret = -EINVAL;
> +goto out;
> +}
> +
> +sub_obj = libxl__json_map_get("spa", obj, JSON_INTEGER);
> +spa = libxl__json_object_get_integer(sub_obj);
> +
> +sub_obj = libxl__json_map_get("length", obj, JSON_INTEGER);
> +length = libxl__json_object_get_integer(sub_obj);
> +
> +LOG(DEBUG,
> +"vNVDIMM #%" PRId64 ": %s, spa 0x%" PRIx64 ", length 0x%" PRIx64,
> +slot, mem_path, spa, length);
> +
> +ret = libxl_nvdimm_add_device(gc, qmp->domid, mem_path, spa, length);
> +if (ret) {
> +LOG(ERROR,
> +"Failed to add NVDIMM #%" PRId64
> +"(mem_path %s, spa 0x%" PRIx64 ", length 0x%" PRIx64 ") "
> +"to domain %d (err = %d)",
> +slot, mem_path, spa, length, qmp->domid, ret);
> +goto out;
> +}
> +}
> +
> + out:
> +GC_FREE;
> +return ret;
> +}
> +
> +static int libxl__qmp_query_nvdimms(libxl__qmp_handler *qmp)
> +{
> +return qmp_synchronous_send(qmp, "query-nvdimms", NULL,
> +qmp_register_nvdimm_callback,
> +NULL, qmp->timeout);
> +}
> +
>  int libxl__qmp_hmp(libxl__gc *gc, int domid, const char *command_line,
> char **output)
>  {
> @@ -1187,6 +1248,9 @@ int libxl__qmp_initializations(libxl__gc *gc, uint32_t 
> domid,
>  if (!ret) {
>  ret = qmp_query_vnc(qmp);
>  }
> +if (!ret && guest_config->num_vnvdimms) {
> +ret = libxl__qmp_query_nvdimms(qmp);
> +}
>  libxl__qmp_close(qmp);
>  return ret;
>  }
> -- 
> 2.10.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [RFC XEN PATCH 15/16] tools/libxl: handle return code of libxl__qmp_initializations()

[Konrad Rzeszutek Wilk]

On Mon, Oct 10, 2016 at 08:32:34AM +0800, Haozhong Zhang wrote:
> If any error code is returned when creating a domain, stop the domain
> creation.

This looks like it is a bug-fix that can be spun off from this
patchset?

> 
> Signed-off-by: Haozhong Zhang 
> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/libxl/libxl_create.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index d986cd2..24e8368 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -1499,7 +1499,9 @@ static void domcreate_devmodel_started(libxl__egc *egc,
>  if (dcs->sdss.dm.guest_domid) {
>  if (d_config->b_info.device_model_version
>  == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
> -libxl__qmp_initializations(gc, domid, d_config);
> +ret = libxl__qmp_initializations(gc, domid, d_config);
> +if (ret)
> +goto error_out;
>  }
>  }
>  
> -- 
> 2.10.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [RFC XEN PATCH 14/16] tools/libxl: add support to map files on pmem devices to guests

[Konrad Rzeszutek Wilk]

On Mon, Oct 10, 2016 at 08:32:33AM +0800, Haozhong Zhang wrote:
> We can map host pmem devices or files on pmem devices to guests. This
> patch adds support to map files on pmem devices. The implementation
> relies on the Linux pmem driver and kernel APIs, so it currently

May want to mention which CONFIG_ options are needed.
> functions only when libxl is compiled for Linux.
> 
> Signed-off-by: Haozhong Zhang 
> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/libxl/libxl_nvdimm.c | 73 
> +-
>  1 file changed, 72 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl_nvdimm.c b/tools/libxl/libxl_nvdimm.c
> index 7bcbaaf..b3ba19a 100644
> --- a/tools/libxl/libxl_nvdimm.c
> +++ b/tools/libxl/libxl_nvdimm.c
> @@ -25,6 +25,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  
>  #include "libxl_internal.h"
>  #include "libxl_arch.h"
> @@ -97,10 +100,78 @@ static int add_pages(libxl__gc *gc, uint32_t domid,
>  return ret;
>  }
>  
> +static uint64_t
> +get_file_extents(libxl__gc *gc, int fd, unsigned long length,
> + struct fiemap_extent **extents_r)
> +{
> +struct fiemap *fiemap;
> +uint64_t nr_extents = 0, extents_size;
> +
> +fiemap = libxl__zalloc(gc, sizeof(*fiemap));
> +if ( !fiemap )
> +goto out;
> +
> +fiemap->fm_length = length;
> +if ( ioctl(fd, FS_IOC_FIEMAP, fiemap) < 0 )
> +goto out;
> +
> +nr_extents = fiemap->fm_mapped_extents;
> +extents_size = sizeof(struct fiemap_extent) * nr_extents;
> +fiemap = libxl__realloc(gc, fiemap, sizeof(*fiemap) + extents_size);
> +if ( !fiemap )
> +goto out;
> +
> +memset(fiemap->fm_extents, 0, extents_size);
> +fiemap->fm_extent_count = nr_extents;
> +fiemap->fm_mapped_extents = 0;
> +
> +if ( ioctl(fd, FS_IOC_FIEMAP, fiemap) < 0 )
> +goto out;
> +
> +*extents_r = fiemap->fm_extents;
> +
> + out:
> +return nr_extents;
> +}
> +
>  static int add_file(libxl__gc *gc, uint32_t domid, int fd,
>  xen_pfn_t mfn, xen_pfn_t gpfn, unsigned long nr_mfns)
>  {
> -return -EINVAL;
> +struct fiemap_extent *extents;
> +uint64_t nr_extents, i;
> +int ret = 0;
> +
> +nr_extents = get_file_extents(gc, fd, nr_mfns << XC_PAGE_SHIFT, 
> );
> +if ( !nr_extents )
> +return -EIO;
> +
> +for ( i = 0; i < nr_extents; i++ )
> +{
> +uint64_t p_offset = extents[i].fe_physical;
> +uint64_t l_offset = extents[i].fe_logical;
> +uint64_t length = extents[i].fe_length;
> +
> +if ( extents[i].fe_flags & ~FIEMAP_EXTENT_LAST )
> +{
> +ret = -EINVAL;
> +break;
> +}
> +
> +if ( (p_offset | l_offset | length) & ~XC_PAGE_MASK )
> +{
> +ret = -EINVAL;
> +break;
> +}
> +
> +ret = add_pages(gc, domid,
> +mfn + (p_offset >> XC_PAGE_SHIFT),
> +gpfn + (l_offset >> XC_PAGE_SHIFT),
> +length >> XC_PAGE_SHIFT);
> +if ( ret )
> +break;
> +}
> +
> +return ret;
>  }
>  
>  int libxl_nvdimm_add_device(libxl__gc *gc,
> -- 
> 2.10.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [RFC XEN PATCH 13/16] tools/libxl: add support to map host pmem device to guests

[Konrad Rzeszutek Wilk]

..snip..
> > +mfn = host_spa >> XC_PAGE_SHIFT;
> > +gpfn = guest_spa >> XC_PAGE_SHIFT;
> > +nr_gpfns = guest_size >> XC_PAGE_SHIFT;
> > +
> > +switch ( st.st_mode & S_IFMT )
> > +{
> > +case S_IFBLK:
> > +ret = add_pages(gc, domid, mfn, gpfn, nr_gpfns);
> 
> You will need to change the return value.
> > +break;
> > +
> > +case S_IFREG:
> > +ret = add_file(gc, domid, fd, mfn, gpfn, nr_gpfns);
> 
> Ditto here.

Also should we close the fd descriptor if there are any errors?

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

Re: [Xen-devel] [RFC XEN PATCH 13/16] tools/libxl: add support to map host pmem device to guests

[Konrad Rzeszutek Wilk]

On Mon, Oct 10, 2016 at 08:32:32AM +0800, Haozhong Zhang wrote:
> We can map host pmem devices or files on pmem devices to guests. This
> patch adds support to map pmem devices. The implementation relies on the
> Linux pmem driver, so it currently functions only when libxl is compiled

Perhaps say when the pmem driver was introduced and also what CONFIG
option to use to enable it?
> for Linux.
> 
> Signed-off-by: Haozhong Zhang 
> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/libxl/Makefile   |   2 +-
>  tools/libxl/libxl_nvdimm.c | 210 
> +
>  tools/libxl/libxl_nvdimm.h |  45 ++
>  3 files changed, 256 insertions(+), 1 deletion(-)
>  create mode 100644 tools/libxl/libxl_nvdimm.c
>  create mode 100644 tools/libxl/libxl_nvdimm.h
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index a904927..ecc9ae1 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -106,7 +106,7 @@ ifeq ($(CONFIG_NetBSD),y)
>  LIBXL_OBJS-y += libxl_netbsd.o
>  else
>  ifeq ($(CONFIG_Linux),y)
> -LIBXL_OBJS-y += libxl_linux.o
> +LIBXL_OBJS-y += libxl_linux.o libxl_nvdimm.o
>  else
>  ifeq ($(CONFIG_FreeBSD),y)
>  LIBXL_OBJS-y += libxl_freebsd.o
> diff --git a/tools/libxl/libxl_nvdimm.c b/tools/libxl/libxl_nvdimm.c
> new file mode 100644
> index 000..7bcbaaf
> --- /dev/null
> +++ b/tools/libxl/libxl_nvdimm.c
> @@ -0,0 +1,210 @@
> +/*
> + * tools/libxl/libxl_nvdimm.c
> + *
> + * Copyright (c) 2016, Intel Corporation.

2017 now.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or

LGPL please. libxl uses that license.

> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; If not, see .
> + *
> + * Author: Haozhong Zhang 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "libxl_internal.h"
> +#include "libxl_arch.h"
> +#include "libxl_nvdimm.h"
> +
> +#include 
> +
> +#define BLK_DEVICE_ROOT "/sys/dev/block"
> +
> +static int nvdimm_sysfs_read(libxl__gc *gc,
> + unsigned int major, unsigned int minor,
> + const char *name, void **data_r)
> +{
> +char *path = libxl__sprintf(gc, BLK_DEVICE_ROOT"/%u:%u/device/%s",
> +major, minor, name);
> +return libxl__read_sysfs_file_contents(gc, path, data_r, NULL);
> +}
> +
> +static int nvdimm_get_spa(libxl__gc *gc, unsigned int major, unsigned int 
> minor,
> +  uint64_t *spa_r)
> +{
> +void *data;
> +int ret = nvdimm_sysfs_read(gc, major, minor, "resource", );
> +
> +if ( ret )
> +return ret;
> +
> +*spa_r = strtoll(data, NULL, 0);
> +return 0;
> +}
> +
> +static int nvdimm_get_size(libxl__gc *gc, unsigned int major, unsigned int 
> minor,
> +   uint64_t *size_r)
> +{
> +void *data;
> +int ret = nvdimm_sysfs_read(gc, major, minor, "size", );
> +
> +if ( ret )
> +return ret;
> +
> +*size_r = strtoll(data, NULL, 0);
> +
> +return 0;
> +}
> +
> +static int add_pages(libxl__gc *gc, uint32_t domid,
> + xen_pfn_t mfn, xen_pfn_t gpfn, unsigned long nr_mfns)
> +{
> +unsigned int nr;
> +int ret = 0;
> +
> +while ( nr_mfns )
> +{
> +nr = min(nr_mfns, (unsigned long) UINT_MAX);
No need for space   ^- here.
> +
> +ret = xc_domain_populate_pmemmap(CTX->xch, domid, mfn, gpfn, nr);
> +if ( ret )
> +{
> +LOG(ERROR, "failed to map pmem pages, "
> +"mfn 0x%" PRIx64", gpfn 0x%" PRIx64 ", nr_mfns %u, err %d",
> +mfn, gpfn, nr, ret);
> +break;
> +}
> +
> +nr_mfns -= nr;
> +mfn += nr;
> +gpfn += nr;
> +}
> +
> +return ret;
> +}
> +
> +static int add_file(libxl__gc *gc, uint32_t domid, int fd,
> +xen_pfn_t mfn, xen_pfn_t gpfn, unsigned long nr_mfns)
> +{
> +return -EINVAL;

Hehehehe..
> +}
> +
> +int libxl_nvdimm_add_device(libxl__gc *gc,
> +uint32_t domid, const char *path,
> +uint64_t guest_spa, uint64_t guest_size)
> +{
> +int fd;
> +struct stat st;
> +unsigned int major, minor;
> +uint64_t host_spa, host_size;
> +xen_pfn_t mfn, gpfn;
> +  

Re: [Xen-devel] [RFC XEN PATCH 12/16] tools/libxl: build qemu options from xl vNVDIMM configs

[Konrad Rzeszutek Wilk]

On Mon, Oct 10, 2016 at 08:32:31AM +0800, Haozhong Zhang wrote:
> For xl vNVDIMM configs
>   vnvdimms = [ '/path/to/pmem0', '/path/to/pmem1', ... ]
> 
> the following qemu options are built
>   -machine ,nvdimm
>   -m ,slots=$NR_SLOTS,maxmem=$MEM_SIZE
>   -object memory-backend-xen,id=mem1,size=$PMEM0_SIZE,mem-path=/path/to/pmem0
>   -device nvdimm,id=nvdimm1,memdev=mem1
>   -object memory-backend-xen,id=mem2,size=$PMEM1_SIZE,mem-path=/path/to/pmem1
>   -device nvdimm,id=nvdimm2,memdev=mem2
>   ...

Also you may want to say which patch (just the title) adds support
for these parameters?

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

Re: [Xen-devel] [RFC XEN PATCH 12/16] tools/libxl: build qemu options from xl vNVDIMM configs

[Konrad Rzeszutek Wilk]

On Mon, Oct 10, 2016 at 08:32:31AM +0800, Haozhong Zhang wrote:
> For xl vNVDIMM configs
>   vnvdimms = [ '/path/to/pmem0', '/path/to/pmem1', ... ]
> 
> the following qemu options are built
>   -machine ,nvdimm
>   -m ,slots=$NR_SLOTS,maxmem=$MEM_SIZE
>   -object memory-backend-xen,id=mem1,size=$PMEM0_SIZE,mem-path=/path/to/pmem0
>   -device nvdimm,id=nvdimm1,memdev=mem1
>   -object memory-backend-xen,id=mem2,size=$PMEM1_SIZE,mem-path=/path/to/pmem1
>   -device nvdimm,id=nvdimm2,memdev=mem2
>   ...
> where
> * NR_SLOTS is the number of entries in vnvdimms + 1,
> * MEM_SIZE is the total size of all RAM and NVDIMM devices,
> * PMEM#_SIZE is the size of the host pmem device/file '/path/to/pmem#'.
> 
> Signed-off-by: Haozhong Zhang 
> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/libxl/libxl_dm.c  | 113 
> +++-
>  tools/libxl/libxl_types.idl |   8 
>  tools/libxl/xl_cmdimpl.c|  16 +++

You probably also want this new parameter in the xl manpage.

>  3 files changed, 135 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index ad366a8..6b8c019 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -24,6 +24,10 @@
>  #include 
>  #include 
>  
> +#if defined(__linux__)
> +#include 
> +#endif
> +
>  static const char *libxl_tapif_script(libxl__gc *gc)
>  {
>  #if defined(__linux__) || defined(__FreeBSD__)
> @@ -905,6 +909,86 @@ static char *qemu_disk_ide_drive_string(libxl__gc *gc, 
> const char *target_path,
>  return drive;
>  }
>  
> +#if defined(__linux__)
> +
> +static uint64_t libxl__build_dm_vnvdimm_args(libxl__gc *gc, flexarray_t 
> *dm_args,
> + struct libxl_device_vnvdimm 
> *dev,
> + int dev_no)
> +{
> +int fd, rc;
> +struct stat st;
> +uint64_t size = 0;
> +char *arg;
> +
> +fd = open(dev->file, O_RDONLY);
> +if (fd < 0) {
> +LOG(ERROR, "failed to open file %s: %s",
> +dev->file, strerror(errno));
> +goto out;
> +}
> +
> +if (stat(dev->file, )) {
> +LOG(ERROR, "failed to get status of file %s: %s",
> +dev->file, strerror(errno));
> +goto out_fclose;
> +}
> +
> +switch (st.st_mode & S_IFMT) {
> +case S_IFBLK:
> +rc = ioctl(fd, BLKGETSIZE64, );
> +if (rc == -1) {
> +LOG(ERROR, "failed to get size of block device %s: %s",
> +dev->file, strerror(errno));
> +size = 0;
> +}
> +break;
> +
> +case S_IFREG:
> +size = st.st_size;
> +break;
> +
> +default:
> +LOG(ERROR, "%s is not a block device or regular file", dev->file);
> +break;
> +}
> +
> +if (!size)
> +goto out_fclose;
> +
> +flexarray_append(dm_args, "-object");
> +arg = GCSPRINTF("memory-backend-xen,id=mem%d,size=%"PRIu64",mem-path=%s",
> +dev_no + 1, size, dev->file);
> +flexarray_append(dm_args, arg);
> +
> +flexarray_append(dm_args, "-device");
> +arg = GCSPRINTF("nvdimm,id=nvdimm%d,memdev=mem%d", dev_no + 1, dev_no + 
> 1);
> +flexarray_append(dm_args, arg);
> +
> + out_fclose:
> +close(fd);
> + out:
> +return size;
> +}
> +
> +static uint64_t libxl__build_dm_vnvdimms_args(
> +libxl__gc *gc, flexarray_t *dm_args,
> +struct libxl_device_vnvdimm *vnvdimms, int num_vnvdimms)
> +{
> +uint64_t total_size = 0, size;
> +int i;

unsigned int
> +

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

Re: [Xen-devel] [RFC XEN PATCH 11/16] tools/libacpi: load ACPI built by the device model

[Konrad Rzeszutek Wilk]

On Mon, Oct 10, 2016 at 08:32:30AM +0800, Haozhong Zhang wrote:
> ACPI tables built by the device model, whose signatures do not
> conflict with tables built by Xen (except SSDT), are loaded after ACPI
> tables built by Xen.
> 
> ACPI namespace devices built by the device model, whose names do not
> conflict with devices built by Xen, are assembled and placed in SSDTs
> after ACPI tables built by Xen.
> 
> Signed-off-by: Haozhong Zhang 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/firmware/hvmloader/util.c |  12 +++
>  tools/libacpi/acpi2_0.h |   2 +
>  tools/libacpi/build.c   | 216 
> 
>  tools/libacpi/libacpi.h |   5 +
>  4 files changed, 235 insertions(+)
> 
> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
> index dba954a..e6530cd 100644
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -998,6 +998,18 @@ void hvmloader_acpi_build_tables(struct acpi_config 
> *config,
>  if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1)  )
>  config->table_flags |= ACPI_HAS_SSDT_S4;
>  
> +s = xenstore_read(HVM_XS_DM_ACPI_ADDRESS, NULL);
> +if ( s )
> +{
> +config->dm.addr = strtoll(s, NULL, 0);
> +
> +s = xenstore_read(HVM_XS_DM_ACPI_LENGTH, NULL);
> +if ( s )
> +config->dm.length = strtoll(s, NULL, 0);
> +else
> +config->dm.addr = 0;
> +}
> +
>  config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC | ACPI_HAS_WAET);
>  
>  config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
> diff --git a/tools/libacpi/acpi2_0.h b/tools/libacpi/acpi2_0.h
> index 775eb7a..7414470 100644
> --- a/tools/libacpi/acpi2_0.h
> +++ b/tools/libacpi/acpi2_0.h
> @@ -430,6 +430,7 @@ struct acpi_20_slit {
>  #define ACPI_2_0_WAET_SIGNATURE ASCII32('W','A','E','T')
>  #define ACPI_2_0_SRAT_SIGNATURE ASCII32('S','R','A','T')
>  #define ACPI_2_0_SLIT_SIGNATURE ASCII32('S','L','I','T')
> +#define ACPI_2_0_SSDT_SIGNATURE ASCII32('S','S','D','T')
>  
>  /*
>   * Table revision numbers.
> @@ -445,6 +446,7 @@ struct acpi_20_slit {
>  #define ACPI_1_0_FADT_REVISION 0x01
>  #define ACPI_2_0_SRAT_REVISION 0x01
>  #define ACPI_2_0_SLIT_REVISION 0x01
> +#define ACPI_2_0_SSDT_REVISION 0x02
>  
>  #pragma pack ()
>  
> diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
> index 47dae01..829a365 100644
> --- a/tools/libacpi/build.c
> +++ b/tools/libacpi/build.c
> @@ -20,6 +20,7 @@
>  #include "ssdt_s4.h"
>  #include "ssdt_tpm.h"
>  #include "ssdt_pm.h"
> +#include "aml_build.h"
>  #include 
>  #include 
>  #include 
> @@ -55,6 +56,34 @@ struct acpi_info {
>  uint64_t pci_hi_min, pci_hi_len; /* 24, 32 - PCI I/O hole boundaries */
>  };
>  
> +#define DM_ACPI_BLOB_TYPE_TABLE 0 /* ACPI table */
> +#define DM_ACPI_BLOB_TYPE_NSDEV 1 /* AML definition of an ACPI namespace 
> device */
> +
> +/* ACPI tables of following signatures should not appear in DM ACPI */

It would be good to have some form of build check to check against
this list..
> +static const uint64_t dm_acpi_signature_blacklist[] = {
> +ACPI_2_0_RSDP_SIGNATURE,
> +ACPI_2_0_FACS_SIGNATURE,
> +ACPI_2_0_FADT_SIGNATURE,
> +ACPI_2_0_MADT_SIGNATURE,
> +ACPI_2_0_RSDT_SIGNATURE,
> +ACPI_2_0_XSDT_SIGNATURE,
> +ACPI_2_0_TCPA_SIGNATURE,
> +ACPI_2_0_HPET_SIGNATURE,
> +ACPI_2_0_WAET_SIGNATURE,
> +ACPI_2_0_SRAT_SIGNATURE,
> +ACPI_2_0_SLIT_SIGNATURE,
> +};
> +
> +/* ACPI namespace devices of following names should not appear in DM ACPI */
> +static const char *dm_acpi_devname_blacklist[] = {
> +"MEM0",
> +"PCI0",
> +"AC",
> +"BAT0",
> +"BAT1",
> +"TPM",

.. and this one.

But I am not even sure how one would do that?

Perhaps add a big warning:

"Make sure to add your table name if you this code (libacpi) is
constructing it. "?

Or maybe have some 'register_acpi_table' function which will expand
this blacklist?

> +};
> +
>  static void set_checksum(
>  void *table, uint32_t checksum_offset, uint32_t length)
>  {
> @@ -339,6 +368,190 @@ static int construct_passthrough_tables(struct 
> acpi_ctxt *ctxt,
>  return nr_added;
>  }
>  
> +#define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))

That may want to go libacpi.h ?
> +
> +static int check_signature_collision(uint64_t sig)

bool
> +{
> +int i;

unsigned int

> +for ( i = 0; i < ARRAY_SIZE(dm_acpi_signature_blacklist); i++ )
> +{
> +if ( sig == dm_acpi_signature_blacklist[i] )
> +return 1;

return true

> +}
> +return 0;
> +}
> +
> +static int check_devname_collision(const char *name)

bool
> +{
> +int i;

unsigned int

> +for ( i = 0; i < ARRAY_SIZE(dm_acpi_devname_blacklist); i++ )
> +{
> +if ( !strncmp(name, 

Re: [Xen-devel] [PATCH v4] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

[Julien Grall]

Hi,

On 27/01/2017 20:54, Tamas K Lengyel wrote:

On Fri, Jan 27, 2017 at 1:41 PM, Stefano Stabellini
 wrote:

On Fri, 27 Jan 2017, Tamas K Lengyel wrote:

When the toolstack modifies memory of a running ARM VM it may happen
that the underlying memory of a current vCPU PC is changed. Without
flushing the icache the vCPU may continue executing stale instructions.

Also expose the xc_domain_cacheflush through xenctrl.h.

Signed-off-by: Tamas K Lengyel 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Julien Grall 

Note: patch has been verified to solve stale icache issues on the
  HiKey platform.


Sorry to come in the discussion late, but there has been a lot of
traffic on this in the last two days. The patch is clear and well
written, thanks for that. However, I am concerned about the performance
impact of the icache flush.

What stale icache issues is it trying to solve?


The case where it is very easy to trigger a stale icache is during an
SMC trap on multi-core boards (like the HiKey). If the monitor
application removes the SMC from memory in the callback (through
xc_map_foreign_range), the SMC instruction will still happen
repeatedly afterwards until the CPU gives up and fetches the actual
contents of the memory. The same icache issue could get triggered any
time the user is modifying instructions in the memory of an active VM.
But flushing the dcache would also be required any time memory is
modified anywhere, so exposing the libxc function would be necessary
without the icache issue anyway.

Speaking of which, after reading
https://events.linuxfoundation.org/sites/events/files/slides/slides_17.pdf,
shouldn't the cache flush happen both before and after memory is
modified (as shown on slide 33)?


I have CCed Mark Rutland who wrote the slides to confirm. The example 
was about doing non-coherent DMA, the device rely on the OS to do the 
cache maintenance for the DMA operation.


In our case, the tools are mapping the region cacheable, so no need to 
do the cache flush before the modifying the memory.


Although, an issue I could see is if a guest vCPU is running with cache 
disabled (other than during early boot). In that case, we have the same 
memory region mapped with different cacheability attribute. But I think 
it will be a real mess and not really helpful as PV protocol would not work.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC XEN PATCH 10/16] tools/libacpi: add a simple AML builder

[Konrad Rzeszutek Wilk]

On Mon, Oct 10, 2016 at 08:32:29AM +0800, Haozhong Zhang wrote:
> It is used by libacpi to generate SSDTs from ACPI namespace devices
> built by the device model.

Would it make sense to include a link to document outlining the
the AML code? Or perhaps even just include an simple example
of ASL and what the resulting AML code should look like?

And maybe what subset of the AML code this implements?
(with some simple ASL examples?)

Also adding Ross who wrote an AML builder as well.

> 
> Signed-off-by: Haozhong Zhang 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/firmware/hvmloader/Makefile |   3 +-
>  tools/libacpi/aml_build.c | 254 
> ++
>  tools/libacpi/aml_build.h |  83 +
>  tools/libxl/Makefile  |   3 +-
>  4 files changed, 341 insertions(+), 2 deletions(-)
>  create mode 100644 tools/libacpi/aml_build.c
>  create mode 100644 tools/libacpi/aml_build.h
> 
> diff --git a/tools/firmware/hvmloader/Makefile 
> b/tools/firmware/hvmloader/Makefile
> index 77d7551..cf0dac3 100644
> --- a/tools/firmware/hvmloader/Makefile
> +++ b/tools/firmware/hvmloader/Makefile
> @@ -79,11 +79,12 @@ smbios.o: CFLAGS += 
> -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
>  
>  ACPI_PATH = ../../libacpi
>  ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
> -ACPI_OBJS = $(patsubst %.c,%.o,$(ACPI_FILES)) build.o static_tables.o
> +ACPI_OBJS = $(patsubst %.c,%.o,$(ACPI_FILES)) build.o static_tables.o 
> aml_build.o
>  $(ACPI_OBJS): CFLAGS += -I. -DLIBACPI_STDUTILS=\"$(CURDIR)/util.h\"
>  CFLAGS += -I$(ACPI_PATH)
>  vpath build.c $(ACPI_PATH)
>  vpath static_tables.c $(ACPI_PATH)
> +vpath aml_build.c $(ACPI_PATH)
>  OBJS += $(ACPI_OBJS)
>  
>  hvmloader: $(OBJS)
> diff --git a/tools/libacpi/aml_build.c b/tools/libacpi/aml_build.c
> new file mode 100644
> index 000..b6f23f4
> --- /dev/null
> +++ b/tools/libacpi/aml_build.c
> @@ -0,0 +1,254 @@
> +/*
> + * tools/libacpi/aml_build.c
> + *
> + * Copyright (c) 2016, Intel Corporation.

.. now 2017
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by

The libacpi is LGPL.

Could this be licensed as LGPL please?

> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; If not, see .
> + *
> + * Author: Haozhong Zhang 
> + */
> +
> +#include LIBACPI_STDUTILS
> +#include "libacpi.h"
> +#include "aml_build.h"
> +
> +#define AML_OP_SCOPE 0x10
> +#define AML_OP_EXT   0x5B
> +#define AML_OP_DEVICE0x82
> +
> +#define ACPI_NAMESEG_LEN 4
> +
> +struct aml_build_alloctor {
> +struct acpi_ctxt *ctxt;
> +uint8_t *buf;
> +uint32_t capacity;
> +uint32_t used;
> +};
> +static struct aml_build_alloctor alloc;
> +
> +enum { ALLOC_OVERFLOW, ALLOC_NOT_NEEDED, ALLOC_NEEDED };

Why not make this a named enum?
> +
> +static int alloc_needed(uint32_t size)
> +{
> +uint32_t len = alloc.used + size;
> +
> +if ( len < alloc.used )
> +return ALLOC_OVERFLOW;
> +else if ( len <= alloc.capacity )
> +return ALLOC_NOT_NEEDED;
> +else
> +return ALLOC_NEEDED;
> +}
> +
> +static uint8_t *aml_buf_alloc(uint32_t size)
> +{
> +int needed = alloc_needed(size);

And then this can be an enum? Or alternatively make this unsigned int.

> +uint8_t *buf = NULL;
> +struct acpi_ctxt *ctxt = alloc.ctxt;
> +uint32_t alloc_size, alloc_align = ctxt->min_alloc_align;
> +
> +switch ( needed )
> +{
> +case ALLOC_OVERFLOW:
> +break;
> +
> +case ALLOC_NEEDED:
> +alloc_size = (size + alloc_align) & ~(alloc_align - 1);

Perhaps multiply times two so we have more wiggle room?

> +buf = ctxt->mem_ops.alloc(ctxt, alloc_size, alloc_align);
> +if ( !buf )
> +break;
> +if ( alloc.buf + alloc.capacity != buf )
> +{
> +buf = NULL;
> +break;
> +}
> +alloc.capacity += alloc_size;
> +alloc.used += size;
> +break;
> +
> +case ALLOC_NOT_NEEDED:
> +buf = alloc.buf + alloc.used;
> +alloc.used += size;
> +break;
> +
> +default:
> +break;
> +}
> +
> +return buf;
> +}
> +
> +static uint32_t get_package_length(uint8_t *pkg)
> +{
> +uint32_t len;
> +
> +len = pkg - 

Re: [Xen-devel] [RFC XEN PATCH 09/16] tools/libacpi: add callbacks to access XenStore

[Konrad Rzeszutek Wilk]

On Mon, Oct 10, 2016 at 08:32:28AM +0800, Haozhong Zhang wrote:
> libacpi needs to access information placed in XenStore in order to load
> ACPI built by the device model.
> 
> Signed-off-by: Haozhong Zhang 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/firmware/hvmloader/util.c   | 50 
> +++
>  tools/firmware/hvmloader/util.h   |  2 ++
>  tools/firmware/hvmloader/xenbus.c | 20 
>  tools/libacpi/libacpi.h   | 10 
>  tools/libxl/libxl_x86_acpi.c  | 24 +++
>  5 files changed, 106 insertions(+)
> 
> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
> index 504ae6a..dba954a 100644
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -888,6 +888,51 @@ static void acpi_mem_free(struct acpi_ctxt *ctxt,
>  /* ACPI builder currently doesn't free memory so this is just a stub */
>  }
>  
> +static const char *acpi_xs_read(struct acpi_ctxt *ctxt, const char *path)
> +{
> +return xenstore_read(path, NULL);
> +}
> +
> +static int acpi_xs_write(struct acpi_ctxt *ctxt,
> + const char *path, const char *value)
> +{
> +return xenstore_write(path, value);
> +}
> +
> +static unsigned int count_strings(const char *strings, unsigned int len)
> +{
> +const char *p;
> +unsigned int n;
> +
> +for ( p = strings, n = 0; p < strings + len; p++ )
> +if ( *p == '\0' )
> +n++;
> +
> +return n;
> +}
> +
> +static char **acpi_xs_directory(struct acpi_ctxt *ctxt,
> +const char *path, unsigned int *num)
> +{
> +const char *strings;
> +char *s, *p, **ret;
> +unsigned int len, n;
> +
> +strings = xenstore_directory(path, , NULL);
> +if ( !strings )
> +return NULL;
> +
> +n = count_strings(strings, len);
> +ret = ctxt->mem_ops.alloc(ctxt, n * sizeof(char *) + len, 0);

sizeof(*s)

But you may also check ret against NULL before you memcpy data in there.


> +memcpy([n], strings, len);
> +
> +s = (char *)[n];
> +for ( p = s, *num = 0; p < s + len; p+= strlen(p) + 1 )

Perhaps add an space before += ?
> +ret[(*num)++] = p;
> +
> +return ret;
> +}
> +
>  static uint8_t acpi_lapic_id(unsigned cpu)
>  {
>  return LAPIC_ID(cpu);
> @@ -975,6 +1020,11 @@ void hvmloader_acpi_build_tables(struct acpi_config 
> *config,
>  ctxt.min_alloc_unit = PAGE_SIZE;
>  ctxt.min_alloc_align = 16;
>  
> +ctxt.xs_ops.read = acpi_xs_read;
> +ctxt.xs_ops.write = acpi_xs_write;
> +ctxt.xs_ops.directory = acpi_xs_directory;
> +ctxt.xs_opaque = NULL;
> +
>  acpi_build_tables(, config);
>  
>  hvm_param_set(HVM_PARAM_VM_GENERATION_ID_ADDR, config->vm_gid_addr);
> diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
> index 6a50dae..9443673 100644
> --- a/tools/firmware/hvmloader/util.h
> +++ b/tools/firmware/hvmloader/util.h
> @@ -225,6 +225,8 @@ const char *xenstore_read(const char *path, const char 
> *default_resp);
>   */
>  int xenstore_write(const char *path, const char *value);
>  
> +const char *xenstore_directory(const char *path, uint32_t *len,
> +   const char *default_resp);
>  
>  /* Get a HVM param.
>   */
> diff --git a/tools/firmware/hvmloader/xenbus.c 
> b/tools/firmware/hvmloader/xenbus.c
> index 448157d..70bdadd 100644
> --- a/tools/firmware/hvmloader/xenbus.c
> +++ b/tools/firmware/hvmloader/xenbus.c
> @@ -296,6 +296,26 @@ int xenstore_write(const char *path, const char *value)
>  return ret;
>  }
>  
> +const char *xenstore_directory(const char *path, uint32_t *len,
> +   const char *default_resp)
> +{
> +uint32_t type = 0;
> +const char *answer = NULL;
> +
> +xenbus_send(XS_DIRECTORY,
> +path, strlen(path),
> +"", 1, /* nul separator */
> +NULL, 0);
> +
> +if ( xenbus_recv(len, , ) || (type != XS_DIRECTORY) )
> +answer = NULL;
> +
> +if ( (default_resp != NULL) && ((answer == NULL) || (*answer == '\0')) )
> +answer = default_resp;
> +
> +return answer;

This function looks very similar to xenstore_read. Could xenstore_read
become __xenstore_read with an extra argument (type) and then the
new xenstore_read along with xenstore_dir would call in it?
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/tools/libacpi/libacpi.h b/tools/libacpi/libacpi.h
> index 0fb16e7..12cafd8 100644
> --- a/tools/libacpi/libacpi.h
> +++ b/tools/libacpi/libacpi.h
> @@ -50,6 +50,16 @@ struct acpi_ctxt {
>  
>  uint32_t min_alloc_unit;
>  uint32_t min_alloc_align;
> +
> +struct acpi_xs_ops {
> +const char *(*read)(struct acpi_ctxt *ctxt, const char *path);
> +

Re: [Xen-devel] [PATCH v4] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

[Julien Grall]

Hi Stefano,

On 27/01/2017 20:41, Stefano Stabellini wrote:

On Fri, 27 Jan 2017, Tamas K Lengyel wrote:

When the toolstack modifies memory of a running ARM VM it may happen
that the underlying memory of a current vCPU PC is changed. Without
flushing the icache the vCPU may continue executing stale instructions.

Also expose the xc_domain_cacheflush through xenctrl.h.

Signed-off-by: Tamas K Lengyel 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Julien Grall 

Note: patch has been verified to solve stale icache issues on the
  HiKey platform.


Sorry to come in the discussion late, but there has been a lot of
traffic on this in the last two days. The patch is clear and well
written, thanks for that. However, I am concerned about the performance
impact of the icache flush.

What stale icache issues is it trying to solve?


The icache issue for Tamas is when the monitor application is writing 
into the guest memory.


Even if we put aside this problem, the instruction cache is not able to 
snoop into the data cache. So if we don't invalidate the instruction 
cache, the guest may see stale instruction when booting or may 
requesting memory and then use it (e.g ballooning).




This patch introduces the icache flush in flush_page_to_ram, which is
called in two instances:

1) arch_do_domctl(XEN_DOMCTL_cacheflush) -> p2m_cache_flush -> flush_page_to_ram

2) alloc_xenheap_pages

It looks like we don't need the icache flush in 2). We should probably
avoid icache flushes for that. Julien, do you agree?


I disagree, in both case the full icache flush is necessary. As Tamas 
wrote in the comment, it is not possible to invalidate by VA because it 
does not ensure that all aliases will be removed in non-PIPT cache.


For the first instance, we could avoid the icache flush in each DOMCTL 
by flushing the instruction cache before the domain is running for the 
first time.


For the second instance, we have no other choice.



I am also wondering about all the libxc/libxl callers, many of whom
don't need an icache flush. Ideally we would have an argument in
XEN_DOMCTL_cacheflush to specify the type of cache flush we need,
similar to GNTTABOP_cache_flush.


Unless the instruction cache will be flushed before the guest is 
booting, all the callers of DOMCTL_cacheflush will require the invalidation.


Looking at GNTTABOP_cache_flush, I think we will also need to invalidate 
the instruction cache (or at least partially).


Regards,

--
Julien Grall

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

Re: [Xen-devel] [RFC XEN PATCH 08/16] tools/libacpi: expose details of memory allocation callback

[Konrad Rzeszutek Wilk]

On Mon, Oct 10, 2016 at 08:32:27AM +0800, Haozhong Zhang wrote:
> Expose the minimal allocation unit and the minimal alignment used by the
> memory allocator, so that certain ACPI code (e.g. the AML builder added
> later) can get contiguous memory allocated by multiple calls to

s/later/in patch titled: "XYZ"/

> acpi_ctxt.mem_ops.alloc().

This contingous memory is virtual or physical? You may want to be
specific.

And you may want to say that acpi_build_tables uses that by default
which is why you have the value of sixteen.
> 
> Signed-off-by: Haozhong Zhang 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/firmware/hvmloader/util.c | 2 ++
>  tools/libacpi/libacpi.h | 3 +++
>  tools/libxl/libxl_x86_acpi.c| 2 ++
>  3 files changed, 7 insertions(+)
> 
> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
> index 1fe8dcc..504ae6a 100644
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -972,6 +972,8 @@ void hvmloader_acpi_build_tables(struct acpi_config 
> *config,
>  ctxt.mem_ops.free = acpi_mem_free;
>  ctxt.mem_ops.v2p = acpi_v2p;
>  ctxt.mem_ops.p2v = acpi_p2v;
> +ctxt.min_alloc_unit = PAGE_SIZE;

?? Really? That seems excessive as the acpi_build_tables calls
ctxt->mem_ops.alloc :
$ grep "ctxt->mem_ops.alloc" * | wc -l
20

That would imply 20 pages ?

> +ctxt.min_alloc_align = 16;

Does that mean it is sixteen pages aligment? Or 16 bytes aligment?

If the bytes perhaps you want to change the name to
'min_alloc_byte_align' ?

>  
>  acpi_build_tables(, config);
>  
> diff --git a/tools/libacpi/libacpi.h b/tools/libacpi/libacpi.h
> index 62e90ab..0fb16e7 100644
> --- a/tools/libacpi/libacpi.h
> +++ b/tools/libacpi/libacpi.h
> @@ -47,6 +47,9 @@ struct acpi_ctxt {
>  unsigned long (*v2p)(struct acpi_ctxt *ctxt, void *v);
>  void *(*p2v)(struct acpi_ctxt *ctxt, unsigned long p);
>  } mem_ops;
> +
> +uint32_t min_alloc_unit;
> +uint32_t min_alloc_align;
>  };
>  
>  struct acpi_config {
> diff --git a/tools/libxl/libxl_x86_acpi.c b/tools/libxl/libxl_x86_acpi.c
> index aa5b83d..baf60ac 100644
> --- a/tools/libxl/libxl_x86_acpi.c
> +++ b/tools/libxl/libxl_x86_acpi.c
> @@ -187,6 +187,8 @@ int libxl__dom_load_acpi(libxl__gc *gc,
>  libxl_ctxt.c.mem_ops.v2p = virt_to_phys;
>  libxl_ctxt.c.mem_ops.p2v = phys_to_virt;
>  libxl_ctxt.c.mem_ops.free = acpi_mem_free;
> +libxl_ctxt.c.min_alloc_unit = libxl_ctxt.page_size;
> +libxl_ctxt.c.min_alloc_align = 16;
>  
>  rc = init_acpi_config(gc, dom, b_info, );
>  if (rc) {
> -- 
> 2.10.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH v4] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

[Tamas K Lengyel]

On Fri, Jan 27, 2017 at 1:41 PM, Stefano Stabellini
 wrote:
> On Fri, 27 Jan 2017, Tamas K Lengyel wrote:
>> When the toolstack modifies memory of a running ARM VM it may happen
>> that the underlying memory of a current vCPU PC is changed. Without
>> flushing the icache the vCPU may continue executing stale instructions.
>>
>> Also expose the xc_domain_cacheflush through xenctrl.h.
>>
>> Signed-off-by: Tamas K Lengyel 
>> Acked-by: Wei Liu 
>> ---
>> Cc: Ian Jackson 
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>>
>> Note: patch has been verified to solve stale icache issues on the
>>   HiKey platform.
>
> Sorry to come in the discussion late, but there has been a lot of
> traffic on this in the last two days. The patch is clear and well
> written, thanks for that. However, I am concerned about the performance
> impact of the icache flush.
>
> What stale icache issues is it trying to solve?

The case where it is very easy to trigger a stale icache is during an
SMC trap on multi-core boards (like the HiKey). If the monitor
application removes the SMC from memory in the callback (through
xc_map_foreign_range), the SMC instruction will still happen
repeatedly afterwards until the CPU gives up and fetches the actual
contents of the memory. The same icache issue could get triggered any
time the user is modifying instructions in the memory of an active VM.
But flushing the dcache would also be required any time memory is
modified anywhere, so exposing the libxc function would be necessary
without the icache issue anyway.

Speaking of which, after reading
https://events.linuxfoundation.org/sites/events/files/slides/slides_17.pdf,
shouldn't the cache flush happen both before and after memory is
modified (as shown on slide 33)?

>
> This patch introduces the icache flush in flush_page_to_ram, which is
> called in two instances:
>
> 1) arch_do_domctl(XEN_DOMCTL_cacheflush) -> p2m_cache_flush -> 
> flush_page_to_ram
>
> 2) alloc_xenheap_pages
>
> It looks like we don't need the icache flush in 2). We should probably
> avoid icache flushes for that. Julien, do you agree?
>
> I am also wondering about all the libxc/libxl callers, many of whom
> don't need an icache flush. Ideally we would have an argument in
> XEN_DOMCTL_cacheflush to specify the type of cache flush we need,
> similar to GNTTABOP_cache_flush.
>

I'm OK with that, though that would probably require a bump in
XEN_DOMCTL_INTERFACE_VERSION.

Tamas

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

Re: [Xen-devel] [RFC XEN PATCH 07/16] tools/libacpi: add callback acpi_ctxt.p2v to get a pointer from physical address

[Konrad Rzeszutek Wilk]

On Mon, Oct 10, 2016 at 08:32:26AM +0800, Haozhong Zhang wrote:
> This callback is used when libacpi needs to in-place access ACPI built
> by the device model, whose address is specified in the physical address.

May I recommend you write:

This callback is used when libacpi needs to access ACPI blobs
built by the device-model. The address is provided as an physical
address on XenBus (see patch titled: XYZ).

?

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

Re: [Xen-devel] [RFC XEN PATCH 06/16] tools: reserve guest memory for ACPI from device model

[Konrad Rzeszutek Wilk]

On Mon, Oct 10, 2016 at 08:32:25AM +0800, Haozhong Zhang wrote:
> One guest page is reserved for the device model to place guest ACPI. The

guest ACPI what? ACPI SSDT? MADT?

Also why one page? What if there is a need for more than one page?

You add  HVM_XS_DM_ACPI_LENGTH which makes me think this is accounted
for?

> base address and size of the reserved area are passed to the device
> model via XenStore keys hvmloader/dm-acpi/{address, length}.
> 
> Signed-off-by: Haozhong Zhang 
> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/libxc/include/xc_dom.h|  1 +
>  tools/libxc/xc_dom_x86.c|  7 +++
>  tools/libxl/libxl_dom.c | 25 +
>  xen/include/public/hvm/hvm_xs_strings.h | 11 +++
>  4 files changed, 44 insertions(+)
> 
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index 608cbc2..19d65cd 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -98,6 +98,7 @@ struct xc_dom_image {
>  xen_pfn_t xenstore_pfn;
>  xen_pfn_t shared_info_pfn;
>  xen_pfn_t bootstack_pfn;
> +xen_pfn_t dm_acpi_pfn;

Perhaps an pointer to an variable size array?

 xen_pfn_t *dm_acpi_pfns;
 unsigned int dm_apci_nr;

?
>  xen_pfn_t pfn_alloc_end;
>  xen_vaddr_t virt_alloc_end;
>  xen_vaddr_t bsd_symtab_start;
> diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
> index 0eab8a7..47f14a1 100644
> --- a/tools/libxc/xc_dom_x86.c
> +++ b/tools/libxc/xc_dom_x86.c
> @@ -674,6 +674,13 @@ static int alloc_magic_pages_hvm(struct xc_dom_image 
> *dom)
>   ioreq_server_pfn(0));
>  xc_hvm_param_set(xch, domid, HVM_PARAM_NR_IOREQ_SERVER_PAGES,
>   NR_IOREQ_SERVER_PAGES);
> +
> +dom->dm_acpi_pfn = xc_dom_alloc_page(dom, "DM ACPI");
> +if ( dom->dm_acpi_pfn == INVALID_PFN )
> +{
> +DOMPRINTF("Could not allocate page for device model ACPI.");
> +goto error_out;
> +}
>  }
>  
>  rc = xc_dom_alloc_segment(dom, >start_info_seg,
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index d519c8d..f0a1d97 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -865,6 +865,31 @@ static int hvm_build_set_xs_values(libxl__gc *gc,
>  goto err;
>  }
>  
> +if (dom->dm_acpi_pfn) {
> +uint64_t guest_addr_out = dom->dm_acpi_pfn * XC_DOM_PAGE_SIZE(dom);
> +
> +if (guest_addr_out >= 0x1ULL) {
> +LOG(ERROR,
> +"Guest address of DM ACPI is 0x%"PRIx64", but expected below 
> 4G",
> +guest_addr_out);
> +goto err;
> +}
> +
> +path = GCSPRINTF("/local/domain/%d/"HVM_XS_DM_ACPI_ADDRESS, domid);
> +
> +ret = libxl__xs_printf(gc, XBT_NULL, path, "0x%"PRIx64,
> +   guest_addr_out);
> +if (ret)
> +goto err;
> +
> +path = GCSPRINTF("/local/domain/%d/"HVM_XS_DM_ACPI_LENGTH, domid);
> +
> +ret = libxl__xs_printf(gc, XBT_NULL, path, "0x%"PRIx64,
> +   (uint64_t) XC_DOM_PAGE_SIZE(dom));
I don't think you need the space here:  ^
> +if (ret)
> +goto err;
> +}
> +
>  return 0;
>  
>  err:
> diff --git a/xen/include/public/hvm/hvm_xs_strings.h 
> b/xen/include/public/hvm/hvm_xs_strings.h
> index 146b0b0..f44f71f 100644
> --- a/xen/include/public/hvm/hvm_xs_strings.h
> +++ b/xen/include/public/hvm/hvm_xs_strings.h
> @@ -79,4 +79,15 @@
>   */
>  #define HVM_XS_OEM_STRINGS "bios-strings/oem-%d"
>  
> +/* Follows are XenStore keys for DM ACPI (ACPI built by device model,
> + * e.g. QEMU).
> + *
> + * A reserved area of guest physical memory is used to pass DM
> + * ACPI. Values of following two keys specify the base address and
> + * length (in bytes) of the reserved area.
> + */
> +#define HVM_XS_DM_ACPI_ROOT  "hvmloader/dm-acpi"
> +#define HVM_XS_DM_ACPI_ADDRESS   HVM_XS_DM_ACPI_ROOT"/address"
> +#define HVM_XS_DM_ACPI_LENGTHHVM_XS_DM_ACPI_ROOT"/length"
> +
>  #endif /* __XEN_PUBLIC_HVM_HVM_XS_STRINGS_H__ */
> -- 
> 2.10.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH] arm/monitor: flush the icache during SMC traps

[Julien Grall]

Hi Stefano,

On 27/01/2017 19:27, Stefano Stabellini wrote:

On Thu, 26 Jan 2017, Tamas K Lengyel wrote:

On Thu, Jan 26, 2017 at 10:54 AM, Tamas K Lengyel
 wrote:

On Thu, Jan 26, 2017 at 4:30 AM, Julien Grall  wrote:

So according to the manual (C5.3.9-10) IALLU and IALLUIS are not
available from EL0. IVAU can be enabled to execute in EL0; however on
my 4.1 kernel it generates a permission fault. I'm also not sure if
IVAU would actually be a solution.


I think there is a Linux syscall available for this kind of things,
called cacheflush. See arch/arm/kernel/traps.c:arm_syscall.


The cacheflush system is only implement on ARM32. And even thought, we 
have a domctl cacheflush for this purpose.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

[Stefano Stabellini]

On Fri, 27 Jan 2017, Tamas K Lengyel wrote:
> When the toolstack modifies memory of a running ARM VM it may happen
> that the underlying memory of a current vCPU PC is changed. Without
> flushing the icache the vCPU may continue executing stale instructions.
> 
> Also expose the xc_domain_cacheflush through xenctrl.h.
> 
> Signed-off-by: Tamas K Lengyel 
> Acked-by: Wei Liu 
> ---
> Cc: Ian Jackson 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> 
> Note: patch has been verified to solve stale icache issues on the
>   HiKey platform.

Sorry to come in the discussion late, but there has been a lot of
traffic on this in the last two days. The patch is clear and well
written, thanks for that. However, I am concerned about the performance
impact of the icache flush.

What stale icache issues is it trying to solve?

This patch introduces the icache flush in flush_page_to_ram, which is
called in two instances:

1) arch_do_domctl(XEN_DOMCTL_cacheflush) -> p2m_cache_flush -> flush_page_to_ram

2) alloc_xenheap_pages

It looks like we don't need the icache flush in 2). We should probably
avoid icache flushes for that. Julien, do you agree?

I am also wondering about all the libxc/libxl callers, many of whom
don't need an icache flush. Ideally we would have an argument in
XEN_DOMCTL_cacheflush to specify the type of cache flush we need,
similar to GNTTABOP_cache_flush.


> v4: Fix commit message
> v3: Flush the entire icache instead of flush by VA
> v2: Return 0 on x86 and clarify comment in xenctrl.h
> ---
>  tools/libxc/include/xenctrl.h |  8 
>  tools/libxc/xc_domain.c   |  6 +++---
>  tools/libxc/xc_private.h  |  3 ---
>  xen/arch/arm/mm.c | 10 ++
>  4 files changed, 21 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 63c616ff6a..a2f23fcd5a 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -2720,6 +2720,14 @@ int xc_livepatch_revert(xc_interface *xch, char *name, 
> uint32_t timeout);
>  int xc_livepatch_unload(xc_interface *xch, char *name, uint32_t timeout);
>  int xc_livepatch_replace(xc_interface *xch, char *name, uint32_t timeout);
>  
> +/*
> + * Ensure cache coherency after memory modifications. A call to this function
> + * is only required on ARM as the x86 architecture provides cache coherency
> + * guarantees. Calling this function on x86 is allowed but has no effect.
> + */
> +int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
> + xen_pfn_t start_pfn, xen_pfn_t nr_pfns);
> +
>  /* Compat shims */
>  #include "xenctrl_compat.h"
>  
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> index 296b8523b5..98ab6ba3fd 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -74,10 +74,10 @@ int xc_domain_cacheflush(xc_interface *xch, uint32_t 
> domid,
>  /*
>   * The x86 architecture provides cache coherency guarantees which prevent
>   * the need for this hypercall.  Avoid the overhead of making a hypercall
> - * just for Xen to return -ENOSYS.
> + * just for Xen to return -ENOSYS.  It is safe to ignore this call on x86
> + * so we just return 0.
>   */
> -errno = ENOSYS;
> -return -1;
> +return 0;
>  #else
>  DECLARE_DOMCTL;
>  domctl.cmd = XEN_DOMCTL_cacheflush;
> diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
> index 97445ae1fe..fddebdc917 100644
> --- a/tools/libxc/xc_private.h
> +++ b/tools/libxc/xc_private.h
> @@ -366,9 +366,6 @@ void bitmap_byte_to_64(uint64_t *lp, const uint8_t *bp, 
> int nbits);
>  /* Optionally flush file to disk and discard page cache */
>  void discard_file_cache(xc_interface *xch, int fd, int flush);
>  
> -int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
> -  xen_pfn_t start_pfn, xen_pfn_t nr_pfns);
> -
>  #define MAX_MMU_UPDATES 1024
>  struct xc_mmu {
>  mmu_update_t updates[MAX_MMU_UPDATES];
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 99588a330d..596283fc99 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -390,6 +390,16 @@ void flush_page_to_ram(unsigned long mfn)
>  
>  clean_and_invalidate_dcache_va_range(v, PAGE_SIZE);
>  unmap_domain_page(v);
> +
> +/*
> + * For some of the instruction cache (such as VIPT), the entire I-Cache
> + * needs to be flushed to guarantee that all the aliases of a given
> + * physical address will be removed from the cache.
> + * Invalidating the I-Cache by VA highly depends on the behavior of the
> + * I-Cache (See D4.9.2 in ARM DDI 0487A.k_iss10775). Instead of using 
> flush
> + * by VA on select platforms, we just flush the entire cache here.
> + */
> +invalidate_icache();
>  }
>  
>  void __init arch_init_memory(void)
> -- 
> 2.11.0

Re: [Xen-devel] [DOC v3] Xen transport for 9pfs

[Stefano Stabellini]

On Fri, 27 Jan 2017, Konrad Rzeszutek Wilk wrote:
> > > 
> > > ## Ring Setup
> > > 
> > > The shared page has the following layout:
> > > 
> > > typedef uint32_t XEN_9PFS_RING_IDX;
> > > 
> > > struct xen_9pfs_intf {
> > >   XEN_9PFS_RING_IDX in_cons, in_prod, in_event;
> > >   XEN_9PFS_RING_IDX out_cons, out_prod, out_event;
> > > 
> > >   uint32_t ring_order;
> > > /* this is an array of (1 << ring_order) elements */
> > >   grant_ref_t ref[1];
> > > };
> > 
> > Could you explain why DEFINE_RING_TYPES would not work?

They cannot work because they require fixed length messages.


> > Could you explain more what '[in|out]_event' ?

I'll write more about them in reply to your other email, but they are
just an optimization to remove unnecessary event notifications. In fact
the first version I sent didn't have them
(http://marc.info/?l=xen-devel=148046256107032).


> > Also would it be possible to re-organize this structure
> > so there are no cache bounces?

I'll separate in and out indexes.


> This, along with a similar layout in the PV Calls got me thinking.
> 
> Why aren't you using the standard old fashioned DEFINE_RING_TYPES.

They only work with fixed length messages.


> And if there is something wrong with it - why not use something
> that has been tried and true. Like the VirtIO available and used
> ring? That has the idea of 'avail_even't as an index.
> 
> And also it provides two nice pages where one is written by
> the frontend while the other by the backend. Which nicely 
> takes into account cache bounces.

This is something that has been tried and true: it is based on the Xen
console ring with only few modifications. See
xen/include/public/io/console.h. The [in|out]_event things are optional
optimizations.

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

Re: [Xen-devel] [DOC v3] Xen transport for 9pfs

[Konrad Rzeszutek Wilk]

> > 
> > ## Ring Setup
> > 
> > The shared page has the following layout:
> > 
> > typedef uint32_t XEN_9PFS_RING_IDX;
> > 
> > struct xen_9pfs_intf {
> > XEN_9PFS_RING_IDX in_cons, in_prod, in_event;
> > XEN_9PFS_RING_IDX out_cons, out_prod, out_event;
> > 
> > uint32_t ring_order;
> > /* this is an array of (1 << ring_order) elements */
> > grant_ref_t ref[1];
> > };
> 
> Could you explain why DEFINE_RING_TYPES would not work?
> 
> Could you explain more what '[in|out]_event' ?
> 
> Also would it be possible to re-organize this structure
> so there are no cache bounces?

This, along with a similar layout in the PV Calls got me thinking.

Why aren't you using the standard old fashioned DEFINE_RING_TYPES.

And if there is something wrong with it - why not use something
that has been tried and true. Like the VirtIO available and used
ring? That has the idea of 'avail_even't as an index.

And also it provides two nice pages where one is written by
the frontend while the other by the backend. Which nicely 
takes into account cache bounces.


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

Re: [Xen-devel] [PATCH v5 4/9] xen/x86: populate PVHv2 Dom0 physical memory map

[Tim Deegan]

At 09:40 -0700 on 27 Jan (1485510008), Jan Beulich wrote:
> >>> On 27.01.17 at 14:20,  wrote:
> > At 12:51 + on 27 Jan (1485521470), Andrew Cooper wrote:
> >> On 27/01/17 11:14, Tim Deegan wrote:
> >> > But looking at it now, I'm not convinced of exactly how.  The magic
> >> > bitmap in the TSS is at [I/O Map Base Address] - 32, and the I/O map
> >> > base address itself lives at offset 100.  A zero'd TSS should mean an
> >> > I/O map at 0, and an interrupt redirection bitmap at -32, which would
> >> > plausibly work if the TSS were 256 bytes (matching the limit set in
> >> > Xen).  Perhaps it's only working because the 128 bytes following the
> >> > TSS in hvmloader happen to be zeros too?
> >> 
> >> With an IO_base_map of 0, the software interrupt bitmap will end up
> >> being ahead of the TSS, not after it.
> > 
> > I should have thought that the segmented address calculation would
> > wrap and leave us at TSS + 224.
> 
> I don't think wrapping takes the limit value into account.

Quite right, I'm talking nonsense.

> - vmx_set_segment_register() will need to set a correct limit

Yep.

> - vmx_set_segment_register() should initialize the TSS every
>   time (including setting the I/O bitmap address to no lower
>   than 32)

Probably to no lower than 136, to avoid having the bits of that field
itself appearing in either the IO or interrupt bitmap.

> - hvmloader's init_vm86_tss() will need to allocate 160 bytes
>   rather than 128 (and we should expose this number, so that
>   Roger can also use it)
> 
> Perhaps we should even introduce a hypercall for hvmloader
> to query the needed value, rather than exposing a hardcoded
> number?

I think Andrew's suggestion of just using a whole page is a good
one.  The TSS is a 32-bit one, after all, and doesn't need to live in
BIOS space.

Cheers,

Tim.

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

Re: [Xen-devel] [PATCH v5 4/9] xen/x86: populate PVHv2 Dom0 physical memory map

[Tim Deegan]

> Despite being owned by the guest, this TSS is actually managed by
Xen.
> It should be initialised to defaults each time Xen needs to use it
on
> behalf of the guest.

At 14:35 + on 27 Jan (1485527708), Andrew Cooper wrote:
> On 27/01/17 14:01, Tim Deegan wrote:
> > Hi,
> >
> > At 13:46 + on 27 Jan (1485524765), Andrew Cooper wrote:
> >> The actual behaviour can be determined by putting the TSS on a page
> >> boundary, making the previous frame non-readable via EPT, and seeing
> >> whether an EPT violation occurs.
> > Indeed.  Or likewise with normal pagetables. 
> >
> >>> Yes, I wonder about the I/O bitmap too.  We don't provide one, or even
> >>> enough space for a full one, but the current SDM is pretty clear that
> >>> the CPU will try to check it in virtual 8086 mode.
> >>>
> >>> It may be that all the ports actually used happen to fall in the 128
> >>> bytes of zeros that we provide.
> >> With an offset of 0, we actually provide 256 bytes of zeros in the
> >> bitmap within the TSS limit.
> > Sure, or at least 128 bytes of zeros and another 128 bytes of something.
> 
> That is a good point.  Nothing prevents a guest exiting vm86 mode, and
> using a task switch to move to a new tss, which will cause Xen to write
> state back into the vm86_tss, making it no longer a zeroed block of memory.
> 
> Despite being owned by the guest, this TSS is actually managed by Xen. 
> It should be initialised to defaults each time Xen needs to use it on
> behalf of the guest.

But it's already in an E820 reserved block - if the guest overwrites
it (with a task switch or otherwise) it will break real-mode support,
but this is no worse than nobbling any other part of the BIOS state.

If we're making it non-zero, I can see an argument for having Xen init
the contents once (maybe when the HVM param is written?) so that it
matches what Xen expects of it.  But resetting it every time we use it
would be overkill.

> >> We set IOPL to 3 as well as when entering vm86 to fake up real mode. 
> >> This bypasses all I/O bitmap checks (a properly common to ring 3
> >> protected tasks as well - See specifically 20.2.7 "Sensitive
> >> Instructions"), which means the IN/OUT instructions end up directly at
> >> the relevant vmexit case.
> > 20.2.8.1 makes it clear that this is not the case -- in virtual 8086
> > mode all IN/OUT ops check the bitmap event with IOPL == CPL.
> 
> Hmm.  Right you area, which explains why the TSS limit is greater than
> 0x67. 
> 
> If the emulation code were working correctly, the emulator should come
> to the same conclusion as hardware and inject a #GP fault.

I don't think so -- the emulator is emulating actual real-mode, not
virtual 8086 mode, so it shouldn't fault on any IO port accesses.

Cheers,

Tim.

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

Re: [Xen-devel] [xen-4.8-testing test] 104736: regressions - FAIL

[Stefano Stabellini]

On Fri, 27 Jan 2017, Jan Beulich wrote:
> >>> On 27.01.17 at 09:59,  wrote:
> > version targeted for testing:
> >  xen  b29aed8b0355fe9f7d49faa9aef12b2f8f983c2c
> > baseline version:
> >  xen  e1cefedd80f9972854769bfc6e32e23b56cd0712
> > 
> > Last test of basis   104358  2017-01-20 18:08:51 Z6 days
> > Testing same since   104736  2017-01-27 01:59:12 Z0 days1 attempts
> > 
> > 
> > People who touched revisions under test:
> >   Julien Grall 
> >   Tamas K Lengyel 
> 
> Stefano,
> 
> of course I can't tell how urgent this fix was, but considering that
> 4.8 has done fine so far without, may I ask that backports in the
> common case get applied to stable trees only once their master
> originals have passed all push gates on master? Security fixes are
> the most prominent exception to this rule, but quite likely those
> are also the only such exceptions.

Yes, you are right. I did it that way in the past, but this time I
thought that the commit was simple enough that an immidiate backport
wouldn't be a problem. Next time, I'll wait for the push gate in any
case (except for security fixes).

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

Re: [Xen-devel] [PATCH RFC 1/8] golang/xenlight: Create stub package

[George Dunlap]

On 23/01/17 16:43, Ronald Rojas wrote:
> Create a basic Makefile to build and install libxenlight Golang
> bindings. Also add a stub package which only opens libxl context.
> 
> Include a global xenlight.Ctx variable which can be used as the
> default context by the entire program if desired.
> 
> For now, return simple errors. Proper error handling will be
> added in next patch.
> 
> Signed-off-by: Ronald Rojas 

Actually, I've done a pretty big re-work of how the makefiles work, to
make sure that we can always be using stuff that is only in-tree, and
not anything that is in our outside environment.

Attached is the result.  Once we have this, then in your test makefiles
can look like this:

dominfo-go: dominfo.go
GOPATH=$(XEN_GOPATH) $(GO) build -o $@ $<

And that will use the current in-tree version of the xenlight package.

You can probably tell I've got some comments on your testing patch as
well, but that will have to wait until Monday. :-)

Let me know what you think.

Peace,
 -George

> ---
>  tools/Makefile| 17 
>  tools/golang/xenlight/Makefile| 31 ++
>  tools/golang/xenlight/xenlight.go | 86 
> +++
>  3 files changed, 134 insertions(+)
>  create mode 100644 tools/golang/xenlight/Makefile
>  create mode 100644 tools/golang/xenlight/xenlight.go
> 
> diff --git a/tools/Makefile b/tools/Makefile
> index 77e0723..c1e975f 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -11,6 +11,8 @@ SUBDIRS-y += xenstore
>  SUBDIRS-y += misc
>  SUBDIRS-y += examples
>  SUBDIRS-y += hotplug
> +#Uncomment line to build Golang libxl
> +#SUBDIRS-y += golang/xenlight
>  SUBDIRS-y += xentrace
>  SUBDIRS-$(CONFIG_XCUTILS) += xcutils
>  SUBDIRS-$(CONFIG_X86) += firmware
> @@ -303,6 +305,21 @@ subdir-clean-qemu-xen-dir:
>   $(MAKE) -C qemu-xen-dir clean; \
>   fi
>  
> +subdir-clean-golang/xenlight: .phony
> + $(MAKE) -C golang/xenlight clean
> +
> +subdir-distclean-golang/xenlight: .phony
> + $(MAKE) -C golang/xenlight distclean
> +
> +subdir-install-golang/xenlight: .phony
> + $(MAKE) -C golang/xenlight install
> +
> +subdir-all-golang/xenlight: .phony
> + $(MAKE) -C golang/xenlight all
> +
> +subdir-distclean-firmware: .phony
> + $(MAKE) -C firmware distclean
> +
>  subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony
>   $(MAKE) -C debugger/gdbsx clean
>  
> diff --git a/tools/golang/xenlight/Makefile b/tools/golang/xenlight/Makefile
> new file mode 100644
> index 000..1c2a2b7
> --- /dev/null
> +++ b/tools/golang/xenlight/Makefile
> @@ -0,0 +1,31 @@
> +XEN_ROOT=$(CURDIR)/../../..
> +GOLANG_SRC=$(GOPATH)/src/xenproject.org/xenlight
> +CGO_CFLAGS = -I$(DESTDIR)$(includedir)
> +CGO_LDFLAGS = -L$(DESTDIR)$(libdir) -Wl,-rpath-link=$(DESTDIR)$(libdir)
> +include $(XEN_ROOT)/tools/Rules.mk
> +
> +BINARY = xenlight.a
> +GO ?= go
> +
> +.PHONY: all
> +all: build
> +
> +.PHONY: build
> +build: xenlight.a
> +
> +.PHONY: install
> +install: build
> + $(INSTALL_DIR) $(DESTDIR)$(GOLANG_SRC)
> + $(INSTALL_DATA) xenlight.go $(DESTDIR)$(GOLANG_SRC)
> +
> +.PHONY: clean
> +clean:
> + $(RM) $(BINARY)
> +
> +.PHONY: distclean
> +distclean: clean
> +
> +xenlight.a: xenlight.go
> + CGO_CFLAGS="$(CGO_CFLAGS)" CGO_LDFLAGS="$(CGO_LDFLAGS)" $(GO) build -o 
> $@ $<
> +
> +-include $(DEPS)
> diff --git a/tools/golang/xenlight/xenlight.go 
> b/tools/golang/xenlight/xenlight.go
> new file mode 100644
> index 000..f82e14e
> --- /dev/null
> +++ b/tools/golang/xenlight/xenlight.go
> @@ -0,0 +1,86 @@
> +/*
> + * Copyright (C) 2016 George W. Dunlap, Citrix Systems UK Ltd
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; version 2 of the
> + * License only.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> + * 02110-1301, USA.
> + */
> +package xenlight
> +
> +/*
> +#cgo LDFLAGS: -lxenlight -lyajl
> +#include 
> +#include 
> +*/
> +import "C"
> +
> +/*
> + * Other flags that may be needed at some point:
> + *  -lnl-route-3 -lnl-3
> + *
> + * To get back to static linking:
> + * #cgo LDFLAGS: -lxenlight -lyajl_s -lxengnttab -lxenstore -lxenguest 
> -lxentoollog -lxenevtchn -lxenctrl -lblktapctl -lxenforeignmemory -lxencall 
> -lz -luuid -lutil
> +*/
> +
> +import (
> + "fmt"
> + "unsafe"
> +)
> +
> +
> +/*
> + * Types: Builtins
> + */
> +type Context struct {
> + ctx *C.libxl_ctx
> +}
> +
> 

Re: [Xen-devel] [PATCH] xen: sched: improve debug dump output.

[Meng Xu]

On Thu, Jan 26, 2017 at 11:52 AM, Dario Faggioli
 wrote:
> Scheduling information debug dump for Credit2 is hard
> to read as it contains the same information repeated
> multiple time in different ways.
>
> In fact, in Credit2, CPUs are grouped in runqueus.
> Here's the current debug output:
>
>  CPU[00]  sibling=,0003, core=,00ff
> run: [32767.0] flags=0 cpu=0 credit=-1073741824 [w=0] load=0 (~0%)
>   1: [0.3] flags=0 cpu=2 credit=3273410 [w=256] load=262144 (~100%)
>   2: [0.4] flags=0 cpu=2 credit=2974954 [w=256] load=262144 (~100%)
>  CPU[01]  sibling=,0003, core=,00ff
> run: [32767.1] flags=0 cpu=1 credit=-1073741824 [w=0] load=0 (~0%)
>   1: [0.3] flags=0 cpu=2 credit=3273410 [w=256] load=262144 (~100%)
>   2: [0.4] flags=0 cpu=2 credit=2974954 [w=256] load=262144 (~100%)
>  CPU[02]  sibling=,000c, core=,00ff
> run: [0.2] flags=2 cpu=2 credit=3556909 [w=256] load=262144 (~100%)
>   1: [0.3] flags=0 cpu=2 credit=3273410 [w=256] load=262144 (~100%)
>   2: [0.4] flags=0 cpu=2 credit=2974954 [w=256] load=262144 (~100%)
>
> Here, CPUs 0, 1 and 2, are all part of runqueue 0,
> the content of which (which, BTW, is d0v3 and d0v4)
> is printed 3 times! It is also not very useful to
> see the details of the idle vcpus, as they're always
> the same (except for the vCPU ids).
>
> With this change, we print:
>  - pCPUs details and, for non idle ones, what vCPU
>they're running;
>  - the runqueue content, once and for all.
>
>  Runqueue 0:
>  CPU[00] runq=0, sibling=,0003, core=,00ff
> run: [0.15] flags=2 cpu=0 credit=5804742 [w=256] load=3655 (~1%)
>  CPU[01] runq=0, sibling=,0003, core=,00ff
>  CPU[02] runq=0, sibling=,000c, core=,00ff
> run: [0.3] flags=2 cpu=2 credit=6674856 [w=256] load=262144 (~100%)
>  CPU[03] runq=0, sibling=,000c, core=,00ff
>  RUNQ:
>   0: [0.1] flags=0 cpu=2 credit=6561215 [w=256] load=262144 (~100%)
>   1: [0.2] flags=0 cpu=2 credit=5812356 [w=256] load=262144 (~100%)
>
> Stop printing details of idle vCPUs also in Credit1
> and RTDS (they're pretty useless in there too).
>
> Signed-off-by: Dario Faggioli 
> ---
> Cc: George Dunlap 
> Cc: Anshul Makkar 
> Cc: Meng Xu 
> ---
>  xen/common/sched_credit.c  |6 ++--
>  xen/common/sched_credit2.c |   72 
> +---
>  xen/common/sched_rt.c  |9 +-
>  xen/common/schedule.c  |7 ++--
>  4 files changed, 49 insertions(+), 45 deletions(-)

As to the sched_rt.c,
Acked-by Meng Xu 

Thanks,

Meng

---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [PATCH] arm/monitor: flush the icache during SMC traps

[Stefano Stabellini]

On Thu, 26 Jan 2017, Tamas K Lengyel wrote:
> On Thu, Jan 26, 2017 at 10:54 AM, Tamas K Lengyel
>  wrote:
> > On Thu, Jan 26, 2017 at 4:30 AM, Julien Grall  wrote:
> >> (CC xen-devel, Ravzan, and Stefao)
> >>
> >> Hi Tamas,
> >>
> >> Not sure why you only CC me on the answer. I have CCed again xen-devel as I
> >> don't see any sensible discussion in it.
> >>
> >> On 26/01/2017 00:11, Tamas K Lengyel wrote:
> >>>
> >>> On Wed, Jan 25, 2017 at 3:41 PM, Julien Grall 
> >>> wrote:
> 
>  Hi Tamas,
> 
>  On 25/01/2017 20:02, Tamas K Lengyel wrote:
> >
> >
> > During an SMC trap it is possible that the user may change the memory
> 
> 
> 
>  By user, do you mean the monitor application?
> >>>
> >>>
> >>> Yes.
> >>
> >>
> >> It would be worth clarifying in the commit message.
> >>
> >>
> >>>
> 
> > from where the SMC was fetched. However, without flushing the icache
> > the SMC may still trigger if the pCPU was idle during the trap. Flush
> > the icache to ensure consistency.
> 
> 
> 
>  invalidate_icache will invalidate the cache to PoU on all the pCPUs. But
>  here you only mention a problem on the current pCPU. So which behavior do
>  you want to achieve?
> >>>
> >>>
> >>> It would be sufficient to flush the icache on the specific pCPU that
> >>> trapped with the SMC. Didn't see anything defined in Xen to achieve
> >>> that.
> >>>
> 
> >
> > Signed-off-by: Tamas K Lengyel 
> > ---
> > Cc: Razvan Cojocaru 
> > Cc: Stefano Stabellini 
> > Cc: Julien Grall 
> > ---
> >  xen/arch/arm/monitor.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/xen/arch/arm/monitor.c b/xen/arch/arm/monitor.c
> > index 59ce8f635f..ae1b97993f 100644
> > --- a/xen/arch/arm/monitor.c
> > +++ b/xen/arch/arm/monitor.c
> > @@ -63,6 +63,9 @@ int monitor_smc(void)
> >  .reason = VM_EVENT_REASON_PRIVILEGED_CALL
> >  };
> >
> > +/* Nuke the icache as the memory may get changed underneath us. */
> > +invalidate_icache();
> > +
> 
> 
> 
>  Can you explain why you put this call before the monitor trap and not
>  after?
>  From my understanding the monitoring application may change the memory.
>  But
>  by the time you modify the instruction, the instruction cache may have
>  prefetched the previous instruction. So the problem is still there.
> >>>
> >>>
> >>> Not sure how would that happen exactly? The vCPU gets paused until the
> >>> user responds to the vm_event request, so where would it perform the
> >>> prefetch again? Also, with this change I've verified that the repeated
> >>> SMC issue no longer presents itself (it has been triggered quite
> >>> regularly on the hikey before).
> >>
> >>
> >> The ARM ARM provides a set of expected behavior and where to call the cache
> >> maintenance instruction. If it is not done correctly, it may not affect 
> >> your
> >> platform but at some point in the future (or even already today) it will
> >> break a platform. I wish you good luck to debug that when it happens. It is
> >> a really nightmare :).
> >>
> >> So what I care the most is what is the correct behavior based on the ARM
> >> ARM. A good overview can be found in a talk made by Mark Rutland [1].
> >>
> >> What I was concerned about is the instruction cache been shared between
> >> multiple processors (for instance L2 cache or higher). A vCPU could also 
> >> get
> >> rescheduled to another processor afterwards. Leading to accessing an out of
> >> date instruction cache.
> >
> >  I see, yea, in that case the instruction may still trigger regardless. 
> > Sigh.
> >
> >>
> >>>
> >>> Also, for multi-vCPU guest another vCPU fetching the SMC before the
> >>> memory modification happen (ie. just after this flush) is not a
> >>> problem and is expected behavior. Providing a non-racy setup for
> >>> trapping on multi-vCPU guests requires other work (like altp2m).
> >>
> >>
> >> I am not that concerned about the SMC itself, but the fact that you may
> >> modify the guest memory whilst it is running. So another vCPU may end up to
> >> execute a mix between new and old instructions depending of the state of 
> >> its
> >> instruction cache. That would result to a potential undefined behavior.
> >>
> >> Also, you want to make sure that if you write another SMC in memory, it is
> >> effectively affecting all the vCPUs now and not a moment after.
> >
> > Yeap.
> >
> >>
> >> So I still think the invalidate_icache should be done afterwards. IHMO
> >> modifying guest instructions while other vCPU are running is very fragile 
> >> as
> >> other thread may execute the instructions your are running.
> >
> > I see your point, just got confused because the 

Re: [Xen-devel] [PATCH] xen: sched: improve debug dump output.

[Meng Xu]

>
> > > TBH, what I don't especially like in the output above is, within
> > > the
> > > vCPU info being printed:
> > >  - the spaces inside '[' ']';
> > >  - the big numbers;
> > >  - the fact that last_start is rather useless (it's more tracing
> > > info
> > >than debug dump info, IMO);
> >
> > I feel the last_start is useful, at least to identify the previous
> > subtle bug in budget accounting. It tells us when the running VCPU
> > was
> > scheduled and indicates how the budget will be burned later.
> > When I saw the last_start is in the previous period and the
> > burn_budget() still use the old last_start to burn budget for the
> > current period, I figured out the bug.
> >
> That's ok, we're all different... That's what makes the World so
> beautiful. :-)
>
> > >  - the fact that the various queues info and CPUs info are not
> > >displaed closer, and they even have "Domain info:" in between
> > > them
> > >(which is because of schedule.c, not sched_rt.c, I know);
> > >  - the word "info" after "Global RunQueue", "Global DepletedQueue",
> > >"Global Replenishment Events";
> > >  - the word "Global", in the names above;
> > >  - the onQ and runnable flags being printed, which I don't is
> > > really
> > >necessary or useful;
> > >  - the lack of scheduler wide information (e.g., the tickled mask,
> > > the
> > >next timeout of the replenishment timer, etc);
> > >
> > > But this is material for another patch. :-)
> >
> > I agree with all of the above output improvements, except for killing
> > the last_start info. :-)
> >
> Ok. I'm not yet working on a patch that does remove it. If/when I will
> and send it, you're more than entitled, and have the necessary power,
> to Nack it. ;-P


OK. Once this serials of patch gets in, I can send one patch to fix this output.
>
>
> > > Going back to printing "idle" or not, also remember that this is
> > > debug
> > > output, meant at being mostly useful for developers, or with help
> > > from
> > > developers. And developers can easily check in the code what having
> > > just the CPU ID printed means (in case it's not obvious, which I
> > > think
> > > it is, or they don't remember).
> > >
> > > That being said, it's not that I can't live with the added "idle"
> > > indication. But I like it less and would prefer not to add it.
> >
> > Sure! I was thinking if we should even avoid printing out the idle
> > CPU
> > number to make the output more concise on an idle systems.
> >
> Yeah, that was also my first doing. But, then, looking at the output, I
> found it a little bit too obfuscated the info about what pCPUs are
> actually in use within the scheduler (think of the case where it's not
> default, and is in a cpupool).
>
> So I ended up deciding to leave it there, all of them, idle or not.
>
> > After seeing the complete output, I think the current output is fine.
> >
> Great! So, you'll send your Acked-by soon?


Yep. I'm replying to your original email.

Meng
---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest

[Stefano Stabellini]

On Fri, 27 Jan 2017, Bhupinder Thakur wrote:
> Hi,
> 
> I have done the changes for emulating pl011 in Xen. Currently, I have
> verified the emulation code by manually reading/writing data to
> /dev/ttyAMA0 which is the device file for pl011 device. The data is
> flowing fine between xenconsoled and the guest domain.

Good progress!


> As a next step, I wanted to use /dev/ttyAMA0 as a console.

Do you see, among the kernel boot messages, something about ttyAMA0
being available? Is there a getty -L ttyAMA0 in your inittab?


> For that I tried adding console=ttyAMA0 instead of console=hvc0 in the
> "extra" directive in the domU configuration file. However, I do not
> see the output on the console once I attached the console using "xl
> console ". I tried using "xl console -t serial
> " also but that shows the tty1 console and not the
> ttyAMA0 one.
> 
> Note that currently for testing, I have patched the code in the
> xenconsoled to read/write pl011 ring buffers and write them to the
> same pty terminal as used by hvc0. Finally, once I have verified, I
> will create a separate pty for pl011 and add a new console type
> "pl011".

If you modified xenconsoled to use the same pty as hvc0, then you should
just do "xl console ", the -t serial option is useless, as
there is only one console from xl console point of view.

You might want to disable the PV console for these tests. I suggest to
add a return at the beginning of drivers/tty/hvc/hvc_xen.c:xen_hvc_init
and drivers/tty/hvc/hvc_xen.c:xen_cons_init.



> Regards,
> Bhupinder
> 
> 
> On 18 January 2017 at 00:57, Stefano Stabellini  
> wrote:
> > On Tue, 17 Jan 2017, Julien Grall wrote:
> >> Hi,
> >>
> >> Sorry for the late answer, I am just back from holidays and still 
> >> catching-up
> >> with my e-mails.
> >>
> >> On 03/01/17 20:08, Stefano Stabellini wrote:
> >> > On Thu, 29 Dec 2016, Bhupinder Thakur wrote:
> >> > > On 28 December 2016 at 23:19, Julien Grall  
> >> > > wrote:
> >> > > > On 21/12/16 22:12, Stefano Stabellini wrote:
> >> > > > >
> >> > > > > On Wed, 21 Dec 2016, Julien Grall wrote:
> >> > > > > >
> >> > > > > > On 20/12/2016 20:53, Stefano Stabellini wrote:
> >> > > > > > >
> >> > > > > > > On Tue, 20 Dec 2016, Julien Grall wrote:
> >> > > > > > > >
> >> > > > > > > > On 19/12/2016 21:24, Stefano Stabellini wrote:
> >> > > > > > > > >
> >> > > > > > > > > On Mon, 19 Dec 2016, Christoffer Dall wrote:
> >> > > > > > > > > >
> >> > > > > > > > > > On Fri, Dec 16, 2016 at 05:03:13PM +, Julien Grall
> >> > > > > > > > > > wrote:
> >> > > > > > > > >
> >> > > > > > > > > If we use hvm_params for this, we need two new hvm_params 
> >> > > > > > > > > and
> >> > > > > > > > > Xen
> >> > > > > > > > > needs
> >> > > > > > > > > to unmap the pfn from the guest immediately, because we 
> >> > > > > > > > > don't
> >> > > > > > > > > want the
> >> > > > > > > > > guest to have access to it.
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > > If you unmap the pfn, the PV backend will not be able to 
> >> > > > > > > > request
> >> > > > > > > > the
> >> > > > > > > > page
> >> > > > > > > > because there will be no translation available.
> >> > > > > > > >
> >> > > > > > > > So what you want to do is preventing the guest to at least 
> >> > > > > > > > write
> >> > > > > > > > into
> >> > > > > > > > region
> >> > > > > > > > (not sure if it is worth to restrict read)
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > That's a good idea.
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > > and unmap the page via the hypercall
> >> > > > > > > > XENMEM_decrease_reservation.
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > That would be issued by the guest itself, right? To save 
> >> > > > > > > address
> >> > > > > > > space?
> >> > > > > >
> >> > > > > >
> >> > > > > > Correct. The main use case today is ballooning, but guest could 
> >> > > > > > call
> >> > > > > > it
> >> > > > > > on any
> >> > > > > > other RAM baked page.
> >> > > > > >
> >> > > > > > I was thinking about more about the protection needed. 
> >> > > > > > Technically
> >> > > > > > the
> >> > > > > > data in
> >> > > > > > the ring are not trusted. So if the guest is messing up with it, 
> >> > > > > > it
> >> > > > > > would
> >> > > > > > not
> >> > > > > > be a big issue. Or did I miss anything here?
> >> > > > >
> >> > > > >
> >> > > > > I understand that a guest would be smart to call
> >> > > > > XENMEM_decrease_reservation on the PV console page for pl011, but 
> >> > > > > it
> >> > > > > cannot be a security measure, because, in fact, it needs to be 
> >> > > > > called
> >> > > > > by
> >> > > > > the guest.  Of course, a malicious guest can simply not call
> >> > > > > XENMEM_decrease_reservation for it.
> >> > > >
> >> > > >
> >> > > > Sorry I was not clear. I was not suggested the guest to call
> >> > > > XENMEM_decrease_reservation on ring for security but a malicious 
> >> > > > guest
> >> > > > issuing 

Re: [Xen-devel] altp2m: unexpected behavior

[Tamas K Lengyel]

On Fri, Jan 27, 2017 at 11:30 AM, Andrew Cooper
 wrote:
> On 27/01/17 18:22, Tamas K Lengyel wrote:
>> On Fri, Jan 27, 2017 at 8:44 AM, Matt Leinhos  wrote:
>>> Hello,
>>>
>>> In developing against the altp2m API, I've encountered something I
>>> wasn't expecting.
>>>
>>> Here's the scenario:
>>>
>>> 1. Create a new altp2m memory view. Assume we get view ID 1.
>>> 2. Change some MFN permissions in view 1.
>>> 3. Destroy view 1.
>>> 4. Create another altp2m view. Get view ID 1 again.
>>>
>>>
>>> Now, I was expecting that by destroying the view in step 3, all the MFNs
>>> in that view would revert back to XENMEM_access_default. However, after
>>> completing step 4, I still encounter #VEs based on the permissions I set
>>> in step 2.
>>>
>>> Is this a deliberate design decision?
>>>
>>> Thanks,
>>> Matt
>> Hi Matt,
>> I'm not sure whether that is deliberate design decision but I've also
>> encountered the issue you are seeing. Destroying the view doesn't
>> actually seem to free/clean the tables, so you should do a manual
>> reset to the default permission of all GFNs you modified before you
>> destroy it. That will ensure that the next time you create a table
>> with that ID that it will be clean.
>
> I'd argue that this is a bug.  Destroying a view should clean everything up.
>

Yeap, but there is a workaround at least.

Tamas

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

Re: [Xen-devel] [PATCH v15] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other.

[Konrad Rzeszutek Wilk]

On Fri, Jan 27, 2017 at 08:38:29PM +0200, Oleksandr Andrushchenko wrote:
> 
> 
> On 01/27/2017 08:13 PM, Konrad Rzeszutek Wilk wrote:
> > .snip..
> > > I am looking at this from FAE's or integrator's POV, when one would need
> > FAE?
> > 
> Field Applications Engineer
> > > to touch different parts of the system. "/0/0/0" makes me feel
> > > sad just because either you have to keep all those numbers in mind (like 
> > > you
> > > do)
> > > or have documentation available (and know where it is, e.g. sources
> > > of Xen or kernel).
> > > I have a strong feeling that if you can change configuration without
> > > knowing what index stands for it is always better and fail-safer then
> > > just having numbers...
> > Not sure I follow that.
> > 
> > How would you change configuration without knowing the index?
> > 
> > ..snip..
> if one looks at
> .../pcm-dev-0/stream-1/...
> most probably he/she will understand this w/o any documentation,
> because it is human readable
> 
> if one looks at
> .../0/1/...
> well, I believe you can almost do nothing w/o looking at the documentation

I can see the beaty of it.

I can also see the beaty of the old implied mechanism
from a maintaince perspective.

I am maintainer so I am leaning towards the second one
as having less "special" cases.

Sorry, I feel like I am mutilating your baby with this
old boring view of "maintaince" and "conform to the old
standard" :-(


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

Re: [Xen-devel] [GIT PULL] (xen-blkfront) stable/for-jens-4.10 for your 'linux-next' branch.

[Jens Axboe]

On 01/27/2017 11:47 AM, Konrad Rzeszutek Wilk wrote:
> Hey Jens,
> 
> Please pull in your 'for-linus' branch two little fixes for Xen
> block front:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git 
> stable/for-jens-4.10
> 
> One fix is for handling the XEN_PAGE_SIZE != PAGE_SIZE (4KB vs 64KB
> on ARM for example) mishandling while the other is fixing
> the accounting for the configuration changes.

Pulled, thanks.

-- 
Jens Axboe


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

[Xen-devel] [GIT PULL] (xen-blkfront) stable/for-jens-4.10 for your 'linux-next' branch.

[Konrad Rzeszutek Wilk]

Hey Jens,

Please pull in your 'for-linus' branch two little fixes for Xen
block front:

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git 
stable/for-jens-4.10

One fix is for handling the XEN_PAGE_SIZE != PAGE_SIZE (4KB vs 64KB
on ARM for example) mishandling while the other is fixing
the accounting for the configuration changes.

Thank you!

drivers/block/xen-blkfront.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

Jan Beulich (2):
  xen-blkfront: feature flags handling adjustments
  xen-blkfront: correct maximum segment accounting

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

Re: [Xen-devel] [DOC v8] PV Calls protocol design

[Stefano Stabellini]

On Fri, 27 Jan 2017, Oleksandr Andrushchenko wrote:
> Hi, Stefano!
> >  Error numbers
> > 
> > The numbers corresponding to the error names specified by POSIX are:
> > 
> >  [EPERM] -1
> >  [ENOENT]-2
> > 
> Don't you want to use Xen's errno.h here as described in [1]?
> So we have error codes consistent for all PV protocols?
> 
> Thanks,
> Oleksandr
> 
> [1] https://marc.info/?l=xen-devel=148545604312317=2
> 

Hi Oleksandr,

PVCalls is a bit different, because the protocol is meant to send POSIX
calls to the backend, therefore, I have to use POSIX error names in the
protocol.

I could assign any numbers to the names though. It makes sense to use
the Xen/Linux error numbers for simplicity. Whether I declare them
directly as numbers as I have done here, or indirectly as XEN_ERRNO, I
don't think it matters much. But I think that using numbers is clearer,
that's why I did it that way.

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

Re: [Xen-devel] [PATCH v15] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other.

[Oleksandr Andrushchenko]

On 01/27/2017 08:13 PM, Konrad Rzeszutek Wilk wrote:

.snip..

I am looking at this from FAE's or integrator's POV, when one would need

FAE?


Field Applications Engineer

to touch different parts of the system. "/0/0/0" makes me feel
sad just because either you have to keep all those numbers in mind (like you
do)
or have documentation available (and know where it is, e.g. sources
of Xen or kernel).
I have a strong feeling that if you can change configuration without
knowing what index stands for it is always better and fail-safer then
just having numbers...

Not sure I follow that.

How would you change configuration without knowing the index?

..snip..

if one looks at
.../pcm-dev-0/stream-1/...
most probably he/she will understand this w/o any documentation,
because it is human readable

if one looks at
.../0/1/...
well, I believe you can almost do nothing w/o looking at the documentation

ok, then

struct xensnd_rw_req {
 uint32_t offset;
 uint32_t len;
};
covers all the requests, but open/close
Do you want me to keep the same structure name (xensnd_rw_req)
or rename it to something like xensnd_io_req?

The name is fine.

Thank you,
Oleksandr



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

Re: [Xen-devel] [PATCH] xen: sched: improve debug dump output.

[Dario Faggioli]

On Fri, 2017-01-27 at 12:05 -0500, Meng Xu wrote:
> On Thu, Jan 26, 2017 at 5:08 PM, Dario Faggioli
>  wrote:
> > "Runqueue 0" tells that what follow is information about the pCPUs
> > and
> > the vCPUs of that runqueue (it's the same label used above for,
> > showing
> > more general runqueue information.
> > 
> > "RUNQ:" tells that what follows is the content of the runqueue,
> > i.e.,
> > the vCPUs which are runnable but not running (the one that were
> > running
> > have been printed already, next to the pCPU they're running on),
> > asn
> > are waiting for their turn in this runqueue.
> > 
> > Any better?
> 
> I see the relation between RUNQ and Runqueue now.
> In RTDS, we did not keep the running VCPUs in the runqueue.
>
Credit2 does remove the running vCPU from the runqueue too.

That's the only (sane?) thing you can do if your runqueue is shared
among multiple pCPUs (which is the case for both Credit2 and RTDS).

Well, actually, that's indeed the case even in Credit1 (although, there
you may leave it in the runq, if you want).

> So I feel it may be better to add a short explanation for RUNQ and
> Runqueue in the output to make it clearer.
> 
> Maybe, something like this:
> "Runqueue 0" change to "Runqueue 0 (Running):"
> "RUNQ" change to "Runqueue 0 (Ready)"
> 
> What do you think?
> 
I'll think about it, but I don't terribly feel the need to be this
verbose in this kind of output.

> > TBH, what I don't especially like in the output above is, within
> > the
> > vCPU info being printed:
> >  - the spaces inside '[' ']';
> >  - the big numbers;
> >  - the fact that last_start is rather useless (it's more tracing
> > info
> >    than debug dump info, IMO);
> 
> I feel the last_start is useful, at least to identify the previous
> subtle bug in budget accounting. It tells us when the running VCPU
> was
> scheduled and indicates how the budget will be burned later.
> When I saw the last_start is in the previous period and the
> burn_budget() still use the old last_start to burn budget for the
> current period, I figured out the bug.
> 
That's ok, we're all different... That's what makes the World so
beautiful. :-)

> >  - the fact that the various queues info and CPUs info are not
> >    displaed closer, and they even have "Domain info:" in between
> > them
> >    (which is because of schedule.c, not sched_rt.c, I know);
> >  - the word "info" after "Global RunQueue", "Global DepletedQueue",
> >    "Global Replenishment Events";
> >  - the word "Global", in the names above;
> >  - the onQ and runnable flags being printed, which I don't is
> > really
> >    necessary or useful;
> >  - the lack of scheduler wide information (e.g., the tickled mask,
> > the
> >    next timeout of the replenishment timer, etc);
> > 
> > But this is material for another patch. :-)
> 
> I agree with all of the above output improvements, except for killing
> the last_start info. :-)
> 
Ok. I'm not yet working on a patch that does remove it. If/when I will
and send it, you're more than entitled, and have the necessary power,
to Nack it. ;-P

> > Going back to printing "idle" or not, also remember that this is
> > debug
> > output, meant at being mostly useful for developers, or with help
> > from
> > developers. And developers can easily check in the code what having
> > just the CPU ID printed means (in case it's not obvious, which I
> > think
> > it is, or they don't remember).
> > 
> > That being said, it's not that I can't live with the added "idle"
> > indication. But I like it less and would prefer not to add it.
> 
> Sure! I was thinking if we should even avoid printing out the idle
> CPU
> number to make the output more concise on an idle systems.
>
Yeah, that was also my first doing. But, then, looking at the output, I
found it a little bit too obfuscated the info about what pCPUs are
actually in use within the scheduler (think of the case where it's not
default, and is in a cpupool).

So I ended up deciding to leave it there, all of them, idle or not.

> After seeing the complete output, I think the current output is fine.
> 
Great! So, you'll send your Acked-by soon?

Thanks and Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

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

Re: [Xen-devel] altp2m: unexpected behavior

[Andrew Cooper]

On 27/01/17 18:22, Tamas K Lengyel wrote:
> On Fri, Jan 27, 2017 at 8:44 AM, Matt Leinhos  wrote:
>> Hello,
>>
>> In developing against the altp2m API, I've encountered something I
>> wasn't expecting.
>>
>> Here's the scenario:
>>
>> 1. Create a new altp2m memory view. Assume we get view ID 1.
>> 2. Change some MFN permissions in view 1.
>> 3. Destroy view 1.
>> 4. Create another altp2m view. Get view ID 1 again.
>>
>>
>> Now, I was expecting that by destroying the view in step 3, all the MFNs
>> in that view would revert back to XENMEM_access_default. However, after
>> completing step 4, I still encounter #VEs based on the permissions I set
>> in step 2.
>>
>> Is this a deliberate design decision?
>>
>> Thanks,
>> Matt
> Hi Matt,
> I'm not sure whether that is deliberate design decision but I've also
> encountered the issue you are seeing. Destroying the view doesn't
> actually seem to free/clean the tables, so you should do a manual
> reset to the default permission of all GFNs you modified before you
> destroy it. That will ensure that the next time you create a table
> with that ID that it will be clean.

I'd argue that this is a bug.  Destroying a view should clean everything up.

~Andrew

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

[Xen-devel] [PATCH v4] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

[Tamas K Lengyel]

When the toolstack modifies memory of a running ARM VM it may happen
that the underlying memory of a current vCPU PC is changed. Without
flushing the icache the vCPU may continue executing stale instructions.

Also expose the xc_domain_cacheflush through xenctrl.h.

Signed-off-by: Tamas K Lengyel 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Julien Grall 

Note: patch has been verified to solve stale icache issues on the
  HiKey platform.

v4: Fix commit message
v3: Flush the entire icache instead of flush by VA
v2: Return 0 on x86 and clarify comment in xenctrl.h
---
 tools/libxc/include/xenctrl.h |  8 
 tools/libxc/xc_domain.c   |  6 +++---
 tools/libxc/xc_private.h  |  3 ---
 xen/arch/arm/mm.c | 10 ++
 4 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 63c616ff6a..a2f23fcd5a 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2720,6 +2720,14 @@ int xc_livepatch_revert(xc_interface *xch, char *name, 
uint32_t timeout);
 int xc_livepatch_unload(xc_interface *xch, char *name, uint32_t timeout);
 int xc_livepatch_replace(xc_interface *xch, char *name, uint32_t timeout);
 
+/*
+ * Ensure cache coherency after memory modifications. A call to this function
+ * is only required on ARM as the x86 architecture provides cache coherency
+ * guarantees. Calling this function on x86 is allowed but has no effect.
+ */
+int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
+ xen_pfn_t start_pfn, xen_pfn_t nr_pfns);
+
 /* Compat shims */
 #include "xenctrl_compat.h"
 
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 296b8523b5..98ab6ba3fd 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -74,10 +74,10 @@ int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
 /*
  * The x86 architecture provides cache coherency guarantees which prevent
  * the need for this hypercall.  Avoid the overhead of making a hypercall
- * just for Xen to return -ENOSYS.
+ * just for Xen to return -ENOSYS.  It is safe to ignore this call on x86
+ * so we just return 0.
  */
-errno = ENOSYS;
-return -1;
+return 0;
 #else
 DECLARE_DOMCTL;
 domctl.cmd = XEN_DOMCTL_cacheflush;
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index 97445ae1fe..fddebdc917 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -366,9 +366,6 @@ void bitmap_byte_to_64(uint64_t *lp, const uint8_t *bp, int 
nbits);
 /* Optionally flush file to disk and discard page cache */
 void discard_file_cache(xc_interface *xch, int fd, int flush);
 
-int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
-xen_pfn_t start_pfn, xen_pfn_t nr_pfns);
-
 #define MAX_MMU_UPDATES 1024
 struct xc_mmu {
 mmu_update_t updates[MAX_MMU_UPDATES];
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 99588a330d..596283fc99 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -390,6 +390,16 @@ void flush_page_to_ram(unsigned long mfn)
 
 clean_and_invalidate_dcache_va_range(v, PAGE_SIZE);
 unmap_domain_page(v);
+
+/*
+ * For some of the instruction cache (such as VIPT), the entire I-Cache
+ * needs to be flushed to guarantee that all the aliases of a given
+ * physical address will be removed from the cache.
+ * Invalidating the I-Cache by VA highly depends on the behavior of the
+ * I-Cache (See D4.9.2 in ARM DDI 0487A.k_iss10775). Instead of using flush
+ * by VA on select platforms, we just flush the entire cache here.
+ */
+invalidate_icache();
 }
 
 void __init arch_init_memory(void)
-- 
2.11.0


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

Re: [Xen-devel] [PATCH v3] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

[Tamas K Lengyel]

On Fri, Jan 27, 2017 at 11:20 AM, Julien Grall  wrote:
> Hi Tamas,
>
> On 27/01/17 18:17, Tamas K Lengyel wrote:
>>
>> When the toolstack modifies memory of a running ARM VM it may happen
>> that the underlying memory of a current vCPU PC is changed. Without
>> flushing the icache the vCPU may continue executing stale instructions.
>>
>> In this patch we introduce VA-based icache flushing macros.
>
>
> I think you forgot to update the commit message.
>
> The code looks good to me.
>

Doh =) One sec..

Tamas

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

Re: [Xen-devel] altp2m: unexpected behavior

[Tamas K Lengyel]

On Fri, Jan 27, 2017 at 8:44 AM, Matt Leinhos  wrote:
> Hello,
>
> In developing against the altp2m API, I've encountered something I
> wasn't expecting.
>
> Here's the scenario:
>
> 1. Create a new altp2m memory view. Assume we get view ID 1.
> 2. Change some MFN permissions in view 1.
> 3. Destroy view 1.
> 4. Create another altp2m view. Get view ID 1 again.
>
>
> Now, I was expecting that by destroying the view in step 3, all the MFNs
> in that view would revert back to XENMEM_access_default. However, after
> completing step 4, I still encounter #VEs based on the permissions I set
> in step 2.
>
> Is this a deliberate design decision?
>
> Thanks,
> Matt

Hi Matt,
I'm not sure whether that is deliberate design decision but I've also
encountered the issue you are seeing. Destroying the view doesn't
actually seem to free/clean the tables, so you should do a manual
reset to the default permission of all GFNs you modified before you
destroy it. That will ensure that the next time you create a table
with that ID that it will be clean.

Cheers,
Tamas

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

Re: [Xen-devel] [PATCH v3] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

[Julien Grall]

Hi Tamas,

On 27/01/17 18:17, Tamas K Lengyel wrote:

When the toolstack modifies memory of a running ARM VM it may happen
that the underlying memory of a current vCPU PC is changed. Without
flushing the icache the vCPU may continue executing stale instructions.

In this patch we introduce VA-based icache flushing macros.


I think you forgot to update the commit message.

The code looks good to me.

Cheers,


Also expose
the xc_domain_cacheflush through xenctrl.h.

Signed-off-by: Tamas K Lengyel 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Julien Grall 

Note: patch has been verified to solve stale icache issues on the
  HiKey platform.

v3: Flush the entire icache instead of flush by VA
v2: Return 0 on x86 and clarify comment in xenctrl.h
---
 tools/libxc/include/xenctrl.h |  8 
 tools/libxc/xc_domain.c   |  6 +++---
 tools/libxc/xc_private.h  |  3 ---
 xen/arch/arm/mm.c | 10 ++
 4 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 63c616ff6a..a2f23fcd5a 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2720,6 +2720,14 @@ int xc_livepatch_revert(xc_interface *xch, char *name, 
uint32_t timeout);
 int xc_livepatch_unload(xc_interface *xch, char *name, uint32_t timeout);
 int xc_livepatch_replace(xc_interface *xch, char *name, uint32_t timeout);

+/*
+ * Ensure cache coherency after memory modifications. A call to this function
+ * is only required on ARM as the x86 architecture provides cache coherency
+ * guarantees. Calling this function on x86 is allowed but has no effect.
+ */
+int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
+ xen_pfn_t start_pfn, xen_pfn_t nr_pfns);
+
 /* Compat shims */
 #include "xenctrl_compat.h"

diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 296b8523b5..98ab6ba3fd 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -74,10 +74,10 @@ int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
 /*
  * The x86 architecture provides cache coherency guarantees which prevent
  * the need for this hypercall.  Avoid the overhead of making a hypercall
- * just for Xen to return -ENOSYS.
+ * just for Xen to return -ENOSYS.  It is safe to ignore this call on x86
+ * so we just return 0.
  */
-errno = ENOSYS;
-return -1;
+return 0;
 #else
 DECLARE_DOMCTL;
 domctl.cmd = XEN_DOMCTL_cacheflush;
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index 97445ae1fe..fddebdc917 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -366,9 +366,6 @@ void bitmap_byte_to_64(uint64_t *lp, const uint8_t *bp, int 
nbits);
 /* Optionally flush file to disk and discard page cache */
 void discard_file_cache(xc_interface *xch, int fd, int flush);

-int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
-xen_pfn_t start_pfn, xen_pfn_t nr_pfns);
-
 #define MAX_MMU_UPDATES 1024
 struct xc_mmu {
 mmu_update_t updates[MAX_MMU_UPDATES];
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 99588a330d..596283fc99 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -390,6 +390,16 @@ void flush_page_to_ram(unsigned long mfn)

 clean_and_invalidate_dcache_va_range(v, PAGE_SIZE);
 unmap_domain_page(v);
+
+/*
+ * For some of the instruction cache (such as VIPT), the entire I-Cache
+ * needs to be flushed to guarantee that all the aliases of a given
+ * physical address will be removed from the cache.
+ * Invalidating the I-Cache by VA highly depends on the behavior of the
+ * I-Cache (See D4.9.2 in ARM DDI 0487A.k_iss10775). Instead of using flush
+ * by VA on select platforms, we just flush the entire cache here.
+ */
+invalidate_icache();
 }

 void __init arch_init_memory(void)



--
Julien Grall

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

[Xen-devel] [PATCH v3] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

[Tamas K Lengyel]

When the toolstack modifies memory of a running ARM VM it may happen
that the underlying memory of a current vCPU PC is changed. Without
flushing the icache the vCPU may continue executing stale instructions.

In this patch we introduce VA-based icache flushing macros. Also expose
the xc_domain_cacheflush through xenctrl.h.

Signed-off-by: Tamas K Lengyel 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Julien Grall 

Note: patch has been verified to solve stale icache issues on the
  HiKey platform.

v3: Flush the entire icache instead of flush by VA
v2: Return 0 on x86 and clarify comment in xenctrl.h
---
 tools/libxc/include/xenctrl.h |  8 
 tools/libxc/xc_domain.c   |  6 +++---
 tools/libxc/xc_private.h  |  3 ---
 xen/arch/arm/mm.c | 10 ++
 4 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 63c616ff6a..a2f23fcd5a 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2720,6 +2720,14 @@ int xc_livepatch_revert(xc_interface *xch, char *name, 
uint32_t timeout);
 int xc_livepatch_unload(xc_interface *xch, char *name, uint32_t timeout);
 int xc_livepatch_replace(xc_interface *xch, char *name, uint32_t timeout);
 
+/*
+ * Ensure cache coherency after memory modifications. A call to this function
+ * is only required on ARM as the x86 architecture provides cache coherency
+ * guarantees. Calling this function on x86 is allowed but has no effect.
+ */
+int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
+ xen_pfn_t start_pfn, xen_pfn_t nr_pfns);
+
 /* Compat shims */
 #include "xenctrl_compat.h"
 
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 296b8523b5..98ab6ba3fd 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -74,10 +74,10 @@ int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
 /*
  * The x86 architecture provides cache coherency guarantees which prevent
  * the need for this hypercall.  Avoid the overhead of making a hypercall
- * just for Xen to return -ENOSYS.
+ * just for Xen to return -ENOSYS.  It is safe to ignore this call on x86
+ * so we just return 0.
  */
-errno = ENOSYS;
-return -1;
+return 0;
 #else
 DECLARE_DOMCTL;
 domctl.cmd = XEN_DOMCTL_cacheflush;
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index 97445ae1fe..fddebdc917 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -366,9 +366,6 @@ void bitmap_byte_to_64(uint64_t *lp, const uint8_t *bp, int 
nbits);
 /* Optionally flush file to disk and discard page cache */
 void discard_file_cache(xc_interface *xch, int fd, int flush);
 
-int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
-xen_pfn_t start_pfn, xen_pfn_t nr_pfns);
-
 #define MAX_MMU_UPDATES 1024
 struct xc_mmu {
 mmu_update_t updates[MAX_MMU_UPDATES];
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 99588a330d..596283fc99 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -390,6 +390,16 @@ void flush_page_to_ram(unsigned long mfn)
 
 clean_and_invalidate_dcache_va_range(v, PAGE_SIZE);
 unmap_domain_page(v);
+
+/*
+ * For some of the instruction cache (such as VIPT), the entire I-Cache
+ * needs to be flushed to guarantee that all the aliases of a given
+ * physical address will be removed from the cache.
+ * Invalidating the I-Cache by VA highly depends on the behavior of the
+ * I-Cache (See D4.9.2 in ARM DDI 0487A.k_iss10775). Instead of using flush
+ * by VA on select platforms, we just flush the entire cache here.
+ */
+invalidate_icache();
 }
 
 void __init arch_init_memory(void)
-- 
2.11.0


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

Re: [Xen-devel] [PATCH v15] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other.

[Konrad Rzeszutek Wilk]

.snip..
> I am looking at this from FAE's or integrator's POV, when one would need

FAE?

> to touch different parts of the system. "/0/0/0" makes me feel
> sad just because either you have to keep all those numbers in mind (like you
> do)
> or have documentation available (and know where it is, e.g. sources
> of Xen or kernel).
> I have a strong feeling that if you can change configuration without
> knowing what index stands for it is always better and fail-safer then
> just having numbers...

Not sure I follow that.

How would you change configuration without knowing the index?

..snip..
> ok, then
> 
> struct xensnd_rw_req {
> uint32_t offset;
> uint32_t len;
> };
> covers all the requests, but open/close
> Do you want me to keep the same structure name (xensnd_rw_req)
> or rename it to something like xensnd_io_req?

The name is fine.
> 
> Thank you,
> Oleksandr

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

Re: [Xen-devel] [PATCH v3] xen/arm: fix rank/vgic lock inversion bug

[Julien Grall]

(CC Artem as ARM coverity admin)

Hi Stefano,

On 03/01/17 23:29, Stefano Stabellini wrote:

Always set the new physical irq affinity at the beginning of
vgic_migrate_irq, in all cases.

No need to set physical irq affinity in gic_update_one_lr anymore,
solving the lock inversion problem.

After migrating an interrupt from vcpu/pcpu 0 to vcpu/pcpu 1, it is
possible to receive a physical interrupt on pcpu 1, which Xen is
supposed to inject into vcpu 1, before the LR on pcpu 0 has been
cleared. In this case the irq is still marked as
GIC_IRQ_GUEST_MIGRATING, and struct pending_irq is still "inflight" on
vcpu 0. As the irq cannot be "inflight" on vcpu 0 and vcpu 1
simultaneously, drop the interrupt.


I am not sure to understand how this is related to the fix of the 
rank/vgic lock inversion bug. Am I right to think that this bug was 
already present?




Coverity-ID: 1381855
Coverity-ID: 1381853


I am bit confused... somehow those numbers disappeared from the main 
Coverity page. Which means Coverity think they have been fixed. However 
this patch is not yet upstreamed. Artem, are you testing Xen upstream?




Signed-off-by: Stefano Stabellini 
---
 xen/arch/arm/gic.c  |  6 +-
 xen/arch/arm/vgic.c | 19 +++
 2 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index a5348f2..767fc9e 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -504,11 +504,7 @@ static void gic_update_one_lr(struct vcpu *v, int i)
 gic_raise_guest_irq(v, irq, p->priority);
 else {
 list_del_init(>inflight);
-if ( test_and_clear_bit(GIC_IRQ_GUEST_MIGRATING, >status) )
-{
-struct vcpu *v_target = vgic_get_target_vcpu(v, irq);
-irq_set_affinity(p->desc, cpumask_of(v_target->processor));
-}
+clear_bit(GIC_IRQ_GUEST_MIGRATING, >status);
 }
 }
 }
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 364d5f0..11ffb9b 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -264,20 +264,17 @@ void vgic_migrate_irq(struct vcpu *old, struct vcpu *new, 
unsigned int irq)
 if ( p->desc == NULL )
 return;

+irq_set_affinity(p->desc, cpumask_of(new->processor));
+
 /* migration already in progress, no need to do anything */
 if ( test_bit(GIC_IRQ_GUEST_MIGRATING, >status) )
 return;
+if ( list_empty(>inflight) )
+return;

 perfc_incr(vgic_irq_migrates);

 spin_lock_irqsave(>arch.vgic.lock, flags);
-
-if ( list_empty(>inflight) )
-{
-irq_set_affinity(p->desc, cpumask_of(new->processor));
-spin_unlock_irqrestore(>arch.vgic.lock, flags);
-return;
-}
 /* If the IRQ is still lr_pending, re-inject it to the new vcpu */
 if ( !list_empty(>lr_queue) )
 {
@@ -286,7 +283,6 @@ void vgic_migrate_irq(struct vcpu *old, struct vcpu *new, 
unsigned int irq)
 list_del_init(>inflight);
 irq_set_affinity(p->desc, cpumask_of(new->processor));


This call is not necessary anymore.


 spin_unlock_irqrestore(>arch.vgic.lock, flags);


Now all the paths finish by spin_unlock; return; Can you send a patch do 
the cleanup?



-vgic_vcpu_inject_irq(new, irq);


The comment on top of the if says: "If the IRQ is still lr_pending, 
re-inject it to the new vCPU". However, you remove interrupt from the 
list but never re-inject it.


Looking at the context, I think we should keep the call to 
vgic_vcpu_inject_irq otherwise we lost the interrupt for ever.



 return;
 }
 /* if the IRQ is in a GICH_LR register, set GIC_IRQ_GUEST_MIGRATING
@@ -495,6 +491,13 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int 
virq)
 return;
 }

+if ( test_bit(GIC_IRQ_GUEST_MIGRATING, >status) )
+{
+/* Drop the interrupt, because it is still inflight on another vcpu */
+spin_unlock_irqrestore(>arch.vgic.lock, flags);


If I understand correctly, the problem arise because LRs are cleared 
lazily and the other vCPU is still running. It is a short window and I 
don't think should happen often.


I would suggest to kick the other vCPU with an SGI to get the LRs 
cleared. Any opinions?



+return;
+}
+
 set_bit(GIC_IRQ_GUEST_QUEUED, >status);

 if ( !list_empty(>inflight) )



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 4/9] xen/x86: populate PVHv2 Dom0 physical memory map

[Andrew Cooper]

On 27/01/17 16:40, Jan Beulich wrote:
 On 27.01.17 at 14:20,  wrote:
>> At 12:51 + on 27 Jan (1485521470), Andrew Cooper wrote:
>>> On 27/01/17 11:14, Tim Deegan wrote:
 But looking at it now, I'm not convinced of exactly how.  The magic
 bitmap in the TSS is at [I/O Map Base Address] - 32, and the I/O map
 base address itself lives at offset 100.  A zero'd TSS should mean an
 I/O map at 0, and an interrupt redirection bitmap at -32, which would
 plausibly work if the TSS were 256 bytes (matching the limit set in
 Xen).  Perhaps it's only working because the 128 bytes following the
 TSS in hvmloader happen to be zeros too?
>>> With an IO_base_map of 0, the software interrupt bitmap will end up
>>> being ahead of the TSS, not after it.
>> I should have thought that the segmented address calculation would
>> wrap and leave us at TSS + 224.
> I don't think wrapping takes the limit value into account. It's all
> linear address calculations, and as Andrew says the assumption
> in microcode likely is that things will be set up properly by any
> OS interested in using the interrupt bitmap.
>
 I also don't remember why the TSS is 128 rather than 104 bytes.  The
 SDM claims that the TSS must be larger than 104 bytes "when accessing
 the I/O permission bit map or interrupt redirection bit map."
 (7.2.2. "TSS Descriptor") but I suspect that just means that the
 generated address of the bitmap must lie inside the limit.
>>> The documented way of expressing "no IO bitmap" is to set the map base
>>> to a value which exceeds the TSS limit.  All this means (I think) is
>>> that you must make a larger than default TSS if you want to use a IO or
>>> software interrupt bitmap.
>> Yes, I wonder about the I/O bitmap too.  We don't provide one, or even
>> enough space for a full one, but the current SDM is pretty clear that
>> the CPU will try to check it in virtual 8086 mode.
>>
>> It may be that all the ports actually used happen to fall in the 128
>> bytes of zeros that we provide.
> I suppose so: This is precisely enough for the ISA port range.
>
> So what we'll need to do then, as I understand it from the
> discussion so far:
>
> - vmx_set_segment_register() will need to set a correct limit
> - vmx_set_segment_register() should initialize the TSS every
>   time (including setting the I/O bitmap address to no lower
>   than 32)
> - hvmloader's init_vm86_tss() will need to allocate 160 bytes
>   rather than 128 (and we should expose this number, so that
>   Roger can also use it)
>
> Perhaps we should even introduce a hypercall for hvmloader
> to query the needed value, rather than exposing a hardcoded
> number?

I suggest we remove all responsibility of managing this from hvmloader. 
The only thing hvmloader does is allocate space for it, and reserve it
in the E820.

It is conceptually related to IDENT_PT, although the IDENT_PT must be
allocated and filled in by the domain builder for the HVM guest to
function.  It would be cleaner for the domain builder to also allocate
an adjacent page for the VM86_TSS when it constructs the IDENT_PT.

All HVMLoader needs to do is read the two hvmparams and adjust the E820
table suitably.

Finally, the IO bitmap needs to be a fraction larger than 160 bytes.

From tools/firmware/rombios/rombios.h:

#define PANIC_PORT  0x400
#define PANIC_PORT2 0x401
#define INFO_PORT   0x402
#define DEBUG_PORT  0x403

which are just above the ISA range.  I'd also just allocate a full page
for it; no OS is going to bother trying to use fractions of a page
around an E820 reserved region.

~Andrew

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

Re: [Xen-devel] [PATCH v2] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

[Tamas K Lengyel]

On Fri, Jan 27, 2017 at 10:25 AM, Julien Grall  wrote:
> Hello Tamas,
>
> Please give a bit more time to people for reviewing before sending a new
> version. Patches adding cache instruction are never easy to review.
>
> On 27/01/17 16:45, Tamas K Lengyel wrote:
>>
>> When the toolstack modifies memory of a running ARM VM it may happen
>> that the underlying memory of a current vCPU PC is changed. Without
>> flushing the icache the vCPU may continue executing stale instructions.
>> In this patch we introduce VA-based icache flushing macros. Also expose
>> the xc_domain_cacheflush through xenctrl.h.
>>
>> Signed-off-by: Tamas K Lengyel 
>> ---
>> Cc: Ian Jackson 
>> Cc: Wei Liu 
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>>
>> Note: patch has been verified to solve stale icache issues on the
>>   HiKey platform.
>
>
> In the future, please include a reference to the ARM ARM to corroborate your
> testing. This would speed-up the review.

Ack.

>
>
>>
>> v2: Return 0 on x86 and clarify comment in xenctrl.h
>> ---
>>  tools/libxc/include/xenctrl.h|  8 
>>  tools/libxc/xc_domain.c  |  6 +++---
>>  tools/libxc/xc_private.h |  3 ---
>>  xen/arch/arm/mm.c|  1 +
>>  xen/include/asm-arm/arm32/page.h |  3 +++
>>  xen/include/asm-arm/arm64/page.h |  3 +++
>>  xen/include/asm-arm/page.h   | 31 +++
>>  7 files changed, 49 insertions(+), 6 deletions(-)
>>
>> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
>> index 63c616ff6a..a2f23fcd5a 100644
>> --- a/tools/libxc/include/xenctrl.h
>> +++ b/tools/libxc/include/xenctrl.h
>> @@ -2720,6 +2720,14 @@ int xc_livepatch_revert(xc_interface *xch, char
>> *name, uint32_t timeout);
>>  int xc_livepatch_unload(xc_interface *xch, char *name, uint32_t timeout);
>>  int xc_livepatch_replace(xc_interface *xch, char *name, uint32_t
>> timeout);
>>
>> +/*
>> + * Ensure cache coherency after memory modifications. A call to this
>> function
>> + * is only required on ARM as the x86 architecture provides cache
>> coherency
>> + * guarantees. Calling this function on x86 is allowed but has no effect.
>> + */
>> +int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
>> + xen_pfn_t start_pfn, xen_pfn_t nr_pfns);
>> +
>>  /* Compat shims */
>>  #include "xenctrl_compat.h"
>>
>> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
>> index 296b8523b5..98ab6ba3fd 100644
>> --- a/tools/libxc/xc_domain.c
>> +++ b/tools/libxc/xc_domain.c
>> @@ -74,10 +74,10 @@ int xc_domain_cacheflush(xc_interface *xch, uint32_t
>> domid,
>>  /*
>>   * The x86 architecture provides cache coherency guarantees which
>> prevent
>>   * the need for this hypercall.  Avoid the overhead of making a
>> hypercall
>> - * just for Xen to return -ENOSYS.
>> + * just for Xen to return -ENOSYS.  It is safe to ignore this call on
>> x86
>> + * so we just return 0.
>>   */
>> -errno = ENOSYS;
>> -return -1;
>> +return 0;
>>  #else
>>  DECLARE_DOMCTL;
>>  domctl.cmd = XEN_DOMCTL_cacheflush;
>> diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
>> index 97445ae1fe..fddebdc917 100644
>> --- a/tools/libxc/xc_private.h
>> +++ b/tools/libxc/xc_private.h
>> @@ -366,9 +366,6 @@ void bitmap_byte_to_64(uint64_t *lp, const uint8_t
>> *bp, int nbits);
>>  /* Optionally flush file to disk and discard page cache */
>>  void discard_file_cache(xc_interface *xch, int fd, int flush);
>>
>> -int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
>> -xen_pfn_t start_pfn, xen_pfn_t nr_pfns);
>> -
>>  #define MAX_MMU_UPDATES 1024
>>  struct xc_mmu {
>
>
>>  mmu_update_t updates[MAX_MMU_UPDATES];
>> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
>> index 99588a330d..43e5b3d9e2 100644
>> --- a/xen/arch/arm/mm.c
>> +++ b/xen/arch/arm/mm.c
>> @@ -389,6 +389,7 @@ void flush_page_to_ram(unsigned long mfn)
>>  void *v = map_domain_page(_mfn(mfn));
>>
>>  clean_and_invalidate_dcache_va_range(v, PAGE_SIZE);
>> +invalidate_icache_va_range(v, PAGE_SIZE);
>
>
> I was about to say that the instruction cache flush would not be necessary
> for the current use case. But in fact, even if the domain is not yet running
> or we are allocating a page, we need to flush the I-Cache.
>
> However, I am afraid that invalidating the I-Cache by VA range will not work
> as you expect on all platforms. This will highly depend on the behavior of
> the I-Cache (See D4.9.2 in ARM DDI 0487A.k_iss10775).
>
> For some of the instruction cache (such as VIPT), you would need to flush
> the entire I-Cache to guarantee that all the aliases of a given physical
> address will be removed from the cache.
>
> There are 2 options to fix the issue:
> 1) Always flush the entire cache
>

Re: [Xen-devel] [PATCH v5 6/9] xen/x86: parse Dom0 kernel for PVHv2

[Roger Pau Monne]

On Fri, Jan 27, 2017 at 05:22:03PM +, Roger Pau Monne wrote:
> On Thu, Jan 26, 2017 at 06:37:00AM -0700, Jan Beulich wrote:
> > >>> On 19.01.17 at 18:29,  wrote:
> > > @@ -1959,12 +1960,146 @@ static int __init pvh_setup_p2m(struct domain *d)
> > >  #undef MB1_PAGES
> > >  }
> > >  
> > > +static int __init pvh_load_kernel(struct domain *d, const module_t 
> > > *image,
> > > +  unsigned long image_headroom,
> > > +  module_t *initrd, char *image_base,
> > > +  char *cmdline, paddr_t *entry,
> > > +  paddr_t *start_info_addr)
> > > +{
> > > +char *image_start = image_base + image_headroom;
> > 
> > While for cmdline plain char is certainly fine, I think we should stop
> > abusing this type for image and image_base, even if this means
> > some further adjustments elsewhere. This really ought to be u8 or
> > unsigned char.
> 
> Done.

I've used void * because that's also used by the toolstack and involves less
changes.

Roger.

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

[Xen-devel] [xen-4.8-testing test] 104751: tolerable trouble: blocked/broken/fail/pass - PUSHED

[osstest service owner]

flight 104751 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104751/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken pass in 
104736
 test-amd64-i386-xl-raw3 host-install(3)  broken pass in 104736
 test-amd64-amd64-rumprun-amd64 16 rumprun-demo-xenstorels/xenstorels.repeat 
fail in 104736 pass in 104751
 test-amd64-i386-xl-qemut-win7-amd64 9 windows-install fail in 104736 pass in 
104751
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 12 guest-saverestore fail pass in 
104736

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104358
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 104358
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 104358
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 104358
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 104358

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  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-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 xen  b29aed8b0355fe9f7d49faa9aef12b2f8f983c2c
baseline version:
 xen  e1cefedd80f9972854769bfc6e32e23b56cd0712

Last test of basis   104358  2017-01-20 18:08:51 Z6 days
Testing same since   104736  2017-01-27 01:59:12 Z0 days2 attempts

Re: [Xen-devel] [PATCH v5 6/9] xen/x86: parse Dom0 kernel for PVHv2

[Roger Pau Monne]

On Fri, Jan 27, 2017 at 05:22:03PM +, Roger Pau Monne wrote:
> On Thu, Jan 26, 2017 at 06:37:00AM -0700, Jan Beulich wrote:
> > >>> On 19.01.17 at 18:29,  wrote:
> > > +if ( cmdline != NULL )
> > > +{
> > > +rc = hvm_copy_to_guest_phys_vcpu(last_addr, cmdline,
> > > + strlen(cmdline) + 1, v);
> > > +if ( rc )
> > > +{
> > > +printk("Unable to copy guest command line\n");
> > > +return rc;
> > > +}
> > > +start_info.cmdline_paddr = last_addr;
> > > +last_addr += ROUNDUP(strlen(cmdline) + 1, 8);
> > 
> > Where is this 8 coming from?
> 
> So that the next struct is aligned to the cache line size? It's also done in
> xc_dom_x86.c.

Sorry, not to the cache, this is just so it's aligned:

https://lists.xen.org/archives/html/xen-devel/2015-08/msg01883.html

Roger.


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

Re: [Xen-devel] [PATCH v2] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

[Julien Grall]

Hello Tamas,

Please give a bit more time to people for reviewing before sending a new 
version. Patches adding cache instruction are never easy to review.


On 27/01/17 16:45, Tamas K Lengyel wrote:

When the toolstack modifies memory of a running ARM VM it may happen
that the underlying memory of a current vCPU PC is changed. Without
flushing the icache the vCPU may continue executing stale instructions.
In this patch we introduce VA-based icache flushing macros. Also expose
the xc_domain_cacheflush through xenctrl.h.

Signed-off-by: Tamas K Lengyel 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Stefano Stabellini 
Cc: Julien Grall 

Note: patch has been verified to solve stale icache issues on the
  HiKey platform.


In the future, please include a reference to the ARM ARM to corroborate 
your testing. This would speed-up the review.




v2: Return 0 on x86 and clarify comment in xenctrl.h
---
 tools/libxc/include/xenctrl.h|  8 
 tools/libxc/xc_domain.c  |  6 +++---
 tools/libxc/xc_private.h |  3 ---
 xen/arch/arm/mm.c|  1 +
 xen/include/asm-arm/arm32/page.h |  3 +++
 xen/include/asm-arm/arm64/page.h |  3 +++
 xen/include/asm-arm/page.h   | 31 +++
 7 files changed, 49 insertions(+), 6 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 63c616ff6a..a2f23fcd5a 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2720,6 +2720,14 @@ int xc_livepatch_revert(xc_interface *xch, char *name, 
uint32_t timeout);
 int xc_livepatch_unload(xc_interface *xch, char *name, uint32_t timeout);
 int xc_livepatch_replace(xc_interface *xch, char *name, uint32_t timeout);

+/*
+ * Ensure cache coherency after memory modifications. A call to this function
+ * is only required on ARM as the x86 architecture provides cache coherency
+ * guarantees. Calling this function on x86 is allowed but has no effect.
+ */
+int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
+ xen_pfn_t start_pfn, xen_pfn_t nr_pfns);
+
 /* Compat shims */
 #include "xenctrl_compat.h"

diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 296b8523b5..98ab6ba3fd 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -74,10 +74,10 @@ int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
 /*
  * The x86 architecture provides cache coherency guarantees which prevent
  * the need for this hypercall.  Avoid the overhead of making a hypercall
- * just for Xen to return -ENOSYS.
+ * just for Xen to return -ENOSYS.  It is safe to ignore this call on x86
+ * so we just return 0.
  */
-errno = ENOSYS;
-return -1;
+return 0;
 #else
 DECLARE_DOMCTL;
 domctl.cmd = XEN_DOMCTL_cacheflush;
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index 97445ae1fe..fddebdc917 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -366,9 +366,6 @@ void bitmap_byte_to_64(uint64_t *lp, const uint8_t *bp, int 
nbits);
 /* Optionally flush file to disk and discard page cache */
 void discard_file_cache(xc_interface *xch, int fd, int flush);

-int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
-xen_pfn_t start_pfn, xen_pfn_t nr_pfns);
-
 #define MAX_MMU_UPDATES 1024
 struct xc_mmu {



 mmu_update_t updates[MAX_MMU_UPDATES];
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 99588a330d..43e5b3d9e2 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -389,6 +389,7 @@ void flush_page_to_ram(unsigned long mfn)
 void *v = map_domain_page(_mfn(mfn));

 clean_and_invalidate_dcache_va_range(v, PAGE_SIZE);
+invalidate_icache_va_range(v, PAGE_SIZE);


I was about to say that the instruction cache flush would not be 
necessary for the current use case. But in fact, even if the domain is 
not yet running or we are allocating a page, we need to flush the I-Cache.


However, I am afraid that invalidating the I-Cache by VA range will not 
work as you expect on all platforms. This will highly depend on the 
behavior of the I-Cache (See D4.9.2 in ARM DDI 0487A.k_iss10775).


For some of the instruction cache (such as VIPT), you would need to 
flush the entire I-Cache to guarantee that all the aliases of a given 
physical address will be removed from the cache.


There are 2 options to fix the issue:
1) Always flush the entire cache
	2) Either flush by VA or the entire cache depending of the I-cache 
implementation


I don't mind if you implement option 1 for now.


 unmap_domain_page(v);
 }

diff --git a/xen/include/asm-arm/arm32/page.h b/xen/include/asm-arm/arm32/page.h
index ea4b312c70..10e5288d0f 100644
--- a/xen/include/asm-arm/arm32/page.h
+++ b/xen/include/asm-arm/arm32/page.h
@@ -19,6 +19,9 @@ static inline void 

Re: [Xen-devel] [PATCH v5 6/9] xen/x86: parse Dom0 kernel for PVHv2

[Roger Pau Monne]

On Thu, Jan 26, 2017 at 06:37:00AM -0700, Jan Beulich wrote:
> >>> On 19.01.17 at 18:29,  wrote:
> > @@ -1959,12 +1960,146 @@ static int __init pvh_setup_p2m(struct domain *d)
> >  #undef MB1_PAGES
> >  }
> >  
> > +static int __init pvh_load_kernel(struct domain *d, const module_t *image,
> > +  unsigned long image_headroom,
> > +  module_t *initrd, char *image_base,
> > +  char *cmdline, paddr_t *entry,
> > +  paddr_t *start_info_addr)
> > +{
> > +char *image_start = image_base + image_headroom;
> 
> While for cmdline plain char is certainly fine, I think we should stop
> abusing this type for image and image_base, even if this means
> some further adjustments elsewhere. This really ought to be u8 or
> unsigned char.

Done.

> > +unsigned long image_len = image->mod_end;
> > +struct elf_binary elf;
> > +struct elf_dom_parms parms;
> > +paddr_t last_addr;
> > +struct hvm_start_info start_info;
> > +struct hvm_modlist_entry mod = { 0 };
> > +struct vcpu *saved_current, *v = d->vcpu[0];
> > +int rc;
> > +
> > +if ( (rc = bzimage_parse(image_base, _start, _len)) != 0 )
> > +{
> > +printk("Error trying to detect bz compressed kernel\n");
> > +return rc;
> > +}
> > +
> > +if ( (rc = elf_init(, image_start, image_len)) != 0 )
> > +{
> > +printk("Unable to init ELF\n");
> > +return rc;
> > +}
> > +#ifdef VERBOSE
> > +elf_set_verbose();
> > +#endif
> > +elf_parse_binary();
> > +if ( (rc = elf_xen_parse(, )) != 0 )
> > +{
> > +printk("Unable to parse kernel for ELFNOTES\n");
> > +return rc;
> > +}
> > +
> > +if ( parms.phys_entry == UNSET_ADDR32 ) {
> 
> Please move the brace to its own line.

Done.

> > +printk("Unable to find XEN_ELFNOTE_PHYS32_ENTRY address\n");
> > +return -EINVAL;
> > +}
> > +
> > +printk("OS: %s version: %s loader: %s bitness: %s\n", parms.guest_os,
> > +   parms.guest_ver, parms.loader,
> > +   elf_64bit() ? "64-bit" : "32-bit");
> > +
> > +/* Copy the OS image and free temporary buffer. */
> > +elf.dest_base = (void *)(parms.virt_kstart - parms.virt_base);
> > +elf.dest_size = parms.virt_kend - parms.virt_kstart;
> > +
> > +/*
> > + * NB: we need to set vCPU 0 of Dom0 as the current vCPU (instead of 
> > the
> > + * idle one) because elf_load_binary calls raw_{copy_to/clear}_guest, 
> > and
> > + * the target domain is not passed anywhere. This is very similar to 
> > what
> > + * is done during classic PV Dom0 creation, where Xen switches to the 
> > Dom0
> > + * page tables. We also cannot pass a struct domain or vcpu to
> > + * elf_load_binary, since the interface is shared with the toolstack, 
> > and
> > + * it doesn't have any notion of a domain or vcpu struct.
> > + */
> > +saved_current = current;
> > +set_current(v);
> > +rc = elf_load_binary();
> > +set_current(saved_current);
> 
> While with the comment it's not as bad anymore, I'm still not happy
> with this code. The tool stack portion of the explanation in particular
> does not really hold: We would add an opaque void * parameter to
> the functions involved, which the tool stack could pass NULL for, and
> you'd use it to convey the vcpu.

As spoken on IRC, I will add a new field to elf_binary only visible to the
hypervisor and that will be used to pass the destination vcpu down to
elf_load_image.

> > +if ( rc < 0 )
> > +{
> > +printk("Failed to load kernel: %d\n", rc);
> > +printk("Xen dom0 kernel broken ELF: %s\n", elf_check_broken());
> > +return rc;
> > +}
> > +
> > +last_addr = ROUNDUP(parms.virt_kend - parms.virt_base, PAGE_SIZE);
> > +
> > +if ( initrd != NULL )
> > +{
> > +rc = hvm_copy_to_guest_phys_vcpu(last_addr,
> > + mfn_to_virt(initrd->mod_start),
> > + initrd->mod_end, v);
> > +if ( rc )
> > +{
> > +printk("Unable to copy initrd to guest\n");
> > +return rc;
> > +}
> > +
> > +mod.paddr = last_addr;
> > +mod.size = initrd->mod_end;
> > +last_addr += ROUNDUP(initrd->mod_end, PAGE_SIZE);
> > +}
> > +
> > +/* Free temporary buffers. */
> > +discard_initial_images();
> > +
> > +memset(_info, 0, sizeof(start_info));
> 
> You clear "mod" with an initializer (which btw could be just the two
> braces), but you memset() start_info - please be consistent.

Done, I've added an initializer to it also.

> > +if ( cmdline != NULL )
> > +{
> > +rc = hvm_copy_to_guest_phys_vcpu(last_addr, cmdline,
> > + strlen(cmdline) + 1, v);
> > +if ( rc )
> > +{
> > +

Re: [Xen-devel] [PATCH v15] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other.

[Oleksandr Andrushchenko]

On 01/27/2017 06:36 PM, Konrad Rzeszutek Wilk wrote:

On Fri, Jan 27, 2017 at 05:50:36PM +0200, Oleksandr Andrushchenko wrote:

thank you for comments, please find answers below

Can we please switch to v16 discussion as v15 vs v16 is
a big change?



This channel seemed appropiate to hash this out.

sorry about that

  I will
look at v16 next week (out of time for reviews for today).

thank you for your time

See below.

On 01/27/2017 05:14 PM, Konrad Rzeszutek Wilk wrote:

On Thu, Jan 26, 2017 at 12:02:49PM +0200, Oleksandr Andrushchenko wrote:

Hi, Konrad!

First of all thank you very much for the valuable comments

and your time!

The number of changes (mostly in description) is going to

be huge, so do you think I can publish something like

"RFC v16" so we can discuss the updated patch?

RFC sadly means folks are going to mostly ignore it.
I would prefer you did not use RFC at this stage but just
did v16.
..snip..

sure

+ * Example for the frontend running in domain 5, instance of the driver
+ * in the front is 0 (single or first PV driver), device id 2,
+ * first stream (0):
+ * /local/domain//device/vsnd//
+ * device//stream//type = "p"
+ * /local/domain/5/device/vsnd/0/device/2/stream/0/type = "p"

Why do you need 'device' ?

just for clarity: the hierarchy of the sound driver would
be that a device may have multiple different streams.

And it just occured to me that you could also imply that
each device has an stream without the 'stream' in it.

So

/local/domain/5/device/vsnd/0/2/0/type = "p"

And the format is:
/local/domain//device/vsnd///

ok, so we'll end up with something like:

- Backend
---

/local/domain/0/backend/vsnd/1/0/frontend-id = "1"
/local/domain/0/backend/vsnd/1/0/frontend = "/local/domain/1/device/vsnd/0"
/local/domain/0/backend/vsnd/1/0/state = "4"
/local/domain/0/backend/vsnd/1/0/versions = "1,2"




- Card 

/local/domain/1/device/vsnd/0/version = "1"
/local/domain/1/device/vsnd/0/short-name = "Card short name"
/local/domain/1/device/vsnd/0/long-name = "Card long name"
/local/domain/1/device/vsnd/0/sample-rates = "8000,32000,44100,48000,96000"
/local/domain/1/device/vsnd/0/sample-formats = "s8,u8,s16_le,s16_be"
/local/domain/1/device/vsnd/0/buffer-size = "262144"



- PCM device 0 

/local/domain/1/device/vsnd/0/0/name = "General analog"
/local/domain/1/device/vsnd/0/0/channels-max = "5"



- Stream 0, playback


/local/domain/1/device/vsnd/0/0/0/type = "p"
/local/domain/1/device/vsnd/0/0/0/sample-formats = "s8,u8"
/local/domain/1/device/vsnd/0/0/0/unique-id = "0"
/local/domain/1/device/vsnd/0/0/0/ring-ref = "386"
/local/domain/1/device/vsnd/0/0/0/event-channel = "15"



--- PCM device 3


/local/domain/1/device/vsnd/0/3/name = "HDMI-0"
/local/domain/1/device/vsnd/0/3/sample-rates = "8000,32000,44100"



-- Stream 0, capture


/local/domain/1/device/vsnd/0/3/0/type = "c"
/local/domain/1/device/vsnd/0/3/0/unique-id = "2"
/local/domain/1/device/vsnd/0/3/0/ring-ref = "387"
/local/domain/1/device/vsnd/0/3/0/event-channel = "151"

Is this what you would like to see?

Yes.
ok, then I will use 
"/local/domain/1/device/vsnd"

as the pattern, no "device", "stream" or whatever

IMO, all these values do not help understanding what it is, e.g.
this is equal to me if we have

/local/domain/1/device/vbd/51712/queue-0/ring-ref = "8"
/local/domain/1/device/vbd/51712/queue-0/event-channel = "3"
/local/domain/1/device/vbd/51712/queue-1 = ""
/local/domain/1/device/vbd/51712/queue-1/ring-ref = "9"

and then decided to go with

/local/domain/1/device/vbd/51712/0/ring-ref = "8"
/local/domain/1/device/vbd/51712/0/event-channel = "3"
/local/domain/1/device/vbd/51712/1/ring-ref = "9"

Can one easily tell what 0 or 1 after "51712/" is?

I do. But maybe my brain has been swimming in this too much?

I am looking at this from FAE's or integrator's POV, when one would need
to touch different parts of the system. "/0/0/0" makes me feel
sad just because either you have to keep all those numbers in mind (like 
you do)

or have documentation available (and know where it is, e.g. sources
of Xen or kernel).
I have a strong feeling that if you can change configuration without
knowing what index stands for it is always better and fail-safer then
just having numbers...

So, what is the final decision then?

Though I have a little of trouble with the 'instance of the
driver'. Are you suggesting you would have multiple
PV drivers of 'vsnd'? Can't the multiple device ids fulfill this?

it is possible, but the main use-case will have a single
PV driver with multiple PCM devices/streams

OK, so no need for this then.
.. snip..

+ * operation - 

Re: [Xen-devel] [PATCH RFC 4/6] COLO-Proxy: Add primary userspace colo proxy start args

[Wei Liu]

On Thu, Jan 26, 2017 at 02:36:07PM +0800, Zhang Chen wrote:
> Qemu need this args to start userspace colo-proxy.
> 
> Signed-off-by: Zhang Chen 

Since we have:

   # Note that the COLO configuration settings should be considered unstable.
   # They may change incompatibly in future versions of Xen.

I have no major objection with this patch.

But I do wonder if you can reduce the repetition somehow.

See below.

> ---
>  tools/libxl/libxl_dm.c  | 104 
>  tools/libxl/libxl_nic.c | 232 
> 
>  tools/libxl/libxl_types.idl |  31 +-
>  tools/libxl/xl_cmdimpl.c|  58 +++
>  4 files changed, 424 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 281058d..b3484df 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
>  }
> diff --git a/tools/libxl/libxl_nic.c b/tools/libxl/libxl_nic.c
> index 61b55ca..b7a3596 100644
> --- a/tools/libxl/libxl_nic.c
> +++ b/tools/libxl/libxl_nic.c
> @@ -196,6 +196,123 @@ static void libxl__device_nic_add(libxl__egc *egc, 
> uint32_t domid,
>  flexarray_append(back, nic->coloft_forwarddev);
>  }
>  
> +if (nic->sock_mirror_id) {
> +flexarray_append(back, "sock_mirror_id");
> +flexarray_append(back, nic->sock_mirror_id);
> +}
> +if (nic->sock_mirror_ip) {
> +flexarray_append(back, "sock_mirror_ip");
> +flexarray_append(back, nic->sock_mirror_ip);
> +}

Here, please use a macro:

#define MAYBE_ADD_COLO_ARGS(arg) ...

 MAYBE_ADD_COLO_ARGS(sock_mirror_id);
 MAYBE_ADD_COLO_ARGS(sock_mirror_ip);
 ...
#undef MAYBE_ADD_COLO_ARGS
> +
>  flexarray_append(back, "mac");
>  flexarray_append(back,GCSPRINTF(LIBXL_MAC_FMT, 
> LIBXL_MAC_BYTES(nic->mac)));
>  if (nic->ip) {
> @@ -348,6 +465,121 @@ static int libxl__device_nic_from_xenstore(libxl__gc 
> *gc,
>  GCSPRINTF("%s/forwarddev", libxl_path),
>  (const char **)(>coloft_forwarddev));
>  if (rc) goto out;
> +rc = libxl__xs_read_checked(NOGC, XBT_NULL,
> +GCSPRINTF("%s/sock_mirror_id", libxl_path),
> +(const char **)(>sock_mirror_id));
> +if (rc) goto out;

And another macro for this hunk.

> +rc = libxl__xs_read_checked(NOGC, XBT_NULL,
> +GCSPRINTF("%s/sock_mirror_ip", libxl_path),
> +(const char **)(>sock_mirror_ip));
> +if (rc) goto out;
> +rc = libxl__xs_read_checked(NOGC, XBT_NULL,
> +GCSPRINTF("%s/sock_mirror_port", libxl_path),
> +(const char **)(>sock_mirror_port));
> +if (rc) goto out;
> +rc = libxl__xs_read_checked(NOGC, XBT_NULL,
[...]
>  
>  /* vif_ioemu nics use the same xenstore entries as vif interfaces */
>  rc = libxl__xs_read_checked(gc, XBT_NULL,
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 89c2c9d..1deb11b 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -629,7 +629,36 @@ libxl_device_nic = Struct("device_nic", [
>  ("gatewaydev", string),
>  # Note that the COLO configuration settings should be considered 
> unstable.
>  # They may change incompatibly in future versions of Xen.
> -("coloft_forwarddev", string)
> +("coloft_forwarddev", string),
> +("sock_mirror_id", string),
> +("sock_mirror_ip", string),
> +("sock_mirror_port", string),
> +("sock_compare_pri_in_id", string),
> +("sock_compare_pri_in_ip", string),
> +("sock_compare_pri_in_port", string),
> +("sock_compare_sec_in_id", string),
> +("sock_compare_sec_in_ip", string),
> +("sock_compare_sec_in_port", string),
> +("sock_redirector0_id", string),
> +("sock_redirector0_ip", string),
> +("sock_redirector0_port", string),
> +("sock_redirector1_id", string),
> +("sock_redirector1_ip", string),
> +("sock_redirector1_port", string),
> +("sock_redirector2_id", string),
> +("sock_redirector2_ip", string),
> +("sock_redirector2_port", string),
> +("filter_mirror_queue", string),
> +("filter_mirror_outdev", string),
> +("filter_redirector0_queue", string),
> +("filter_redirector0_indev", string),
> +("filter_redirector0_outdev", string),
> +("filter_redirector1_queue", string),
> +("filter_redirector1_indev", string),
> +("filter_redirector1_outdev", string),

I suggest you prefix all these fields with colo_.

Wei.

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

Re: [Xen-devel] [PATCH] xen: sched: improve debug dump output.

[Meng Xu]

On Thu, Jan 26, 2017 at 5:08 PM, Dario Faggioli
 wrote:
> On Thu, 2017-01-26 at 13:59 -0500, Meng Xu wrote:
>> Hi Dario,
>>
> Hi,
>
>> On Thu, Jan 26, 2017 at 11:52 AM, Dario Faggioli
>>  wrote:
>> >
>> >  Runqueue 0:
>> >  CPU[00] runq=0, sibling=,0003, core=,00ff
>> > run: [0.15] flags=2 cpu=0 credit=5804742 [w=256] load=3655
>> > (~1%)
>> >  CPU[01] runq=0, sibling=,0003, core=,00ff
>> >  CPU[02] runq=0, sibling=,000c, core=,00ff
>> > run: [0.3] flags=2 cpu=2 credit=6674856 [w=256] load=262144
>> > (~100%)
>> >  CPU[03] runq=0, sibling=,000c, core=,00ff
>> >  RUNQ:
>>
>> What is the difference between RUNQ and Runqueue 0 in the message?
>>
> Right. So, this is more comprehensive output:
>
> (XEN) [ 2797.156864] Cpupool 0:
> (XEN) [ 2797.156866] Cpus: 0-5,10-15
> (XEN) [ 2797.156868] Scheduler: SMP Credit Scheduler rev2 (credit2)
> (XEN) [ 2797.156871] Active queues: 2
> (XEN) [ 2797.156873]default-weight = 256
> (XEN) [ 2797.156876] Runqueue 0:
> (XEN) [ 2797.156878]ncpus  = 6
> (XEN) [ 2797.156879]cpus   = 0-5
> (XEN) [ 2797.156881]max_weight = 256
> (XEN) [ 2797.156882]instload   = 5
> (XEN) [ 2797.156884]aveload= 1052984 (~401%)
> (XEN) [ 2797.156887]idlers: ,002a
> (XEN) [ 2797.156889]tickled: ,
> (XEN) [ 2797.156891]fully idle cores: ,
> (XEN) [ 2797.156894] Runqueue 1:
> (XEN) [ 2797.156896]ncpus  = 6
> (XEN) [ 2797.156897]cpus   = 10-15
> (XEN) [ 2797.156899]max_weight = 256
> (XEN) [ 2797.156900]instload   = 4
> (XEN) [ 2797.156902]aveload= 1061305 (~404%)
> (XEN) [ 2797.156904]idlers: ,e800
> (XEN) [ 2797.156906]tickled: ,
> (XEN) [ 2797.156908]fully idle cores: ,c000
> (XEN) [ 2797.156910] Domain info:
> (XEN) [ 2797.156912]Domain: 0 w 256 v 16
> (XEN) [ 2797.156914]  1: [0.0] flags=2 cpu=4 credit=-476120314 [w=256] 
> load=85800 (~32%)
> (XEN) [ 2797.156919]  2: [0.1] flags=0 cpu=2 credit=5630728 [w=256] 
> load=262144 (~100%)
> (XEN) [ 2797.156923]  3: [0.2] flags=0 cpu=2 credit=4719251 [w=256] 
> load=262144 (~100%)
> (XEN) [ 2797.156928]  4: [0.3] flags=2 cpu=2 credit=5648202 [w=256] 
> load=262144 (~100%)
> (XEN) [ 2797.156933]  5: [0.4] flags=2 cpu=12 credit=2735243 [w=256] 
> load=262144 (~100%)
> (XEN) [ 2797.156939]  6: [0.5] flags=2 cpu=12 credit=2721770 [w=256] 
> load=262144 (~100%)
> (XEN) [ 2797.156945]  7: [0.6] flags=0 cpu=12 credit=2150753 [w=256] 
> load=262144 (~100%)
> (XEN) [ 2797.156950]  8: [0.7] flags=0 cpu=14 credit=10424341 [w=256] 
> load=2836 (~1%)
> (XEN) [ 2797.156986]  9: [0.8] flags=0 cpu=4 credit=1050 [w=256] 
> load=14 (~0%)
> (XEN) [ 2797.156991] 10: [0.9] flags=0 cpu=14 credit=1050 [w=256] 
> load=12 (~0%)
> (XEN) [ 2797.156995] 11: [0.10] flags=0 cpu=5 credit=9204778 [w=256] 
> load=7692 (~2%)
> (XEN) [ 2797.156999] 12: [0.11] flags=0 cpu=1 credit=10501097 [w=256] 
> load=2791 (~1%)
> (XEN) [ 2797.157004] 13: [0.12] flags=0 cpu=4 credit=1050 [w=256] 
> load=28 (~0%)
> (XEN) [ 2797.157008] 14: [0.13] flags=0 cpu=11 credit=1050 [w=256] 
> load=19 (~0%)
> (XEN) [ 2797.157013] 15: [0.14] flags=0 cpu=14 credit=1050 [w=256] 
> load=388 (~0%)
> (XEN) [ 2797.157017] 16: [0.15] flags=0 cpu=3 credit=9832716 [w=256] 
> load=7326 (~2%)
> (XEN) [ 2797.157022]Domain: 1 w 256 v 2
> (XEN) [ 2797.157024] 17: [1.0] flags=2 cpu=10 credit=-1085114190 [w=256] 
> load=261922 (~99%)
> (XEN) [ 2797.157029] 18: [1.1] flags=0 cpu=14 credit=1050 [w=256] 
> load=0 (~0%)
> (XEN) [ 2797.157033]Domain: 2 w 256 v 2
> (XEN) [ 2797.157035] 19: [2.0] flags=2 cpu=0 credit=-593239186 [w=256] 
> load=47389 (~18%)
> (XEN) [ 2797.157040] 20: [2.1] flags=0 cpu=11 credit=1050 [w=256] 
> load=0 (~0%)
> (XEN) [ 2797.157044] Runqueue 0:
> (XEN) [ 2797.157047] CPU[00] runq=0, sibling=,0003, 
> core=,00ff
> (XEN) [ 2797.157050]run: [2.0] flags=2 cpu=0 credit=-593239186 [w=256] 
> load=47389 (~18%)
> (XEN) [ 2797.157055] CPU[01] runq=0, sibling=,0003, 
> core=,00ff
> (XEN) [ 2797.157058] CPU[02] runq=0, sibling=,000c, 
> core=,00ff
> (XEN) [ 2797.157061]run: [0.3] flags=2 cpu=2 credit=5648202 [w=256] 
> load=262144 (~100%)
> (XEN) [ 2797.157066] CPU[03] runq=0, sibling=,000c, 
> core=,00ff
> (XEN) [ 2797.157069] CPU[04] runq=0, sibling=,0030, 
> core=,00ff
> (XEN) [ 2797.157072]run: [0.0] flags=2 cpu=4 credit=-476120314 [w=256] 
> load=85800 (~32%)
> (XEN) [ 2797.157077] CPU[05] runq=0, sibling=,0030, 
> core=,00ff
> (XEN) 

Re: [Xen-devel] [PATCH RFC 3/6] COLO-Proxy: Setup userspace colo-proxy on secondary side

[Wei Liu]

On Thu, Jan 26, 2017 at 02:36:06PM +0800, Zhang Chen wrote:
> In this patch we add a function to close
> kernel COLO-Proxy on secondary side.
> 
> Signed-off-by: Zhang Chen 
> ---
>  tools/libxl/libxl_colo_restore.c |  9 +++--
>  tools/libxl/libxl_create.c   |  9 +++--
>  tools/libxl/libxl_types.idl  |  1 +
>  tools/libxl/xl_cmdimpl.c | 18 +++---
>  4 files changed, 30 insertions(+), 7 deletions(-)
> 
> diff --git a/tools/libxl/libxl_colo_restore.c 
> b/tools/libxl/libxl_colo_restore.c
> index 6a96328..1d42539 100644
> --- a/tools/libxl/libxl_colo_restore.c
> +++ b/tools/libxl/libxl_colo_restore.c
> @@ -774,8 +774,13 @@ static void colo_setup_checkpoint_devices(libxl__egc 
> *egc,
>  
>  STATE_AO_GC(crs->ao);
>  
> -cds->device_kind_flags = (1 << LIBXL__DEVICE_KIND_VIF) |
> - (1 << LIBXL__DEVICE_KIND_VBD);
> +if (crs->cps.is_userspace_proxy) {
> +cds->device_kind_flags = (1 << LIBXL__DEVICE_KIND_VBD);
> +} else {
> +cds->device_kind_flags = (1 << LIBXL__DEVICE_KIND_VIF) |
> + (1 << LIBXL__DEVICE_KIND_VBD);
> +}
> +

Style issue.

>  cds->callback = colo_restore_setup_cds_done;
>  cds->ao = ao;
>  cds->domid = crs->domid;
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index e3bc257..d230ecd 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -1609,6 +1609,7 @@ static int do_domain_create(libxl_ctx *ctx, 
> libxl_domain_config *d_config,
>  uint32_t *domid, int restore_fd, int 
> send_back_fd,
>  const libxl_domain_restore_params *params,
>  const char *colo_proxy_script,
> +const bool userspace_colo_proxy,
>  const libxl_asyncop_how *ao_how,
>  const libxl_asyncprogress_how *aop_console_how)
>  {
> @@ -1633,6 +1634,7 @@ static int do_domain_create(libxl_ctx *ctx, 
> libxl_domain_config *d_config,
>  cdcs->dcs.callback = domain_create_cb;
>  cdcs->dcs.domid_soft_reset = INVALID_DOMID;
>  cdcs->dcs.colo_proxy_script = colo_proxy_script;
> +cdcs->dcs.crs.cps.is_userspace_proxy = userspace_colo_proxy;
>  libxl__ao_progress_gethow(>dcs.aop_console_how, aop_console_how);
>  cdcs->domid_out = domid;
>  
> @@ -1821,7 +1823,7 @@ int libxl_domain_create_new(libxl_ctx *ctx, 
> libxl_domain_config *d_config,
>  {
>  unset_disk_colo_restore(d_config);
>  return do_domain_create(ctx, d_config, domid, -1, -1, NULL, NULL,
> -ao_how, aop_console_how);
> +false, ao_how, aop_console_how);
>  }
>  
>  int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config 
> *d_config,
> @@ -1832,16 +1834,19 @@ int libxl_domain_create_restore(libxl_ctx *ctx, 
> libxl_domain_config *d_config,
>  const libxl_asyncprogress_how 
> *aop_console_how)
>  {
>  char *colo_proxy_script = NULL;
> +bool userspace_colo_proxy = false;
>  
>  if (params->checkpointed_stream == LIBXL_CHECKPOINTED_STREAM_COLO) {
>  colo_proxy_script = params->colo_proxy_script;
> +userspace_colo_proxy = 
> libxl_defbool_val(params->userspace_colo_proxy);

I think I'm going to ask for a bit of cleanup here.

You don't  actually need the values of colo_proxy_script and
userspace_colo_proxy here.

So instead of having both values here. I suggest:

1. provide a patch to refactor existing code so that do_domain_create
   doesn't take colo_proxy_script anymore. It should be able to do
   cdcs->dcs.colo_proxy_script = params->colo_proxy_script.
2. rework this patch on top of that patch.

Does this make sense? Let me know if this is not feasible due to I miss
something obvious.

>  set_disk_colo_restore(d_config);
>  } else {
>  unset_disk_colo_restore(d_config);
>  }
>  
>  return do_domain_create(ctx, d_config, domid, restore_fd, send_back_fd,
> -params, colo_proxy_script, ao_how, 
> aop_console_how);
> +params, colo_proxy_script, userspace_colo_proxy,
> +ao_how, aop_console_how);
>  }
>  
>  int libxl_domain_soft_reset(libxl_ctx *ctx,
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 1bd2057..89c2c9d 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -390,6 +390,7 @@ libxl_domain_restore_params = 
> Struct("domain_restore_params", [
>  ("checkpointed_stream", integer),
>  ("stream_version", uint32, {'init_val': '1'}),
>  ("colo_proxy_script", string),
> +("userspace_colo_proxy", libxl_defbool),

I suppose you can use LIBXL_HAVE_COLO_USERSPACE_PROXY for this whole
series.

Since this series touches a lot of common code, I would like you to

Re: [Xen-devel] [PATCH RFC 5/6] COLO-Proxy: Add secondary userspace colo-proxy start args

[Wei Liu]

On Thu, Jan 26, 2017 at 02:36:08PM +0800, Zhang Chen wrote:
> Qemu need this args to start userspace colo-proxy.
> 
> Signed-off-by: Zhang Chen 

See previous patch. Same comments apply here.

Wei.

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

Re: [Xen-devel] [PATCH v2] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

[Wei Liu]

On Fri, Jan 27, 2017 at 09:45:45AM -0700, Tamas K Lengyel wrote:
> When the toolstack modifies memory of a running ARM VM it may happen
> that the underlying memory of a current vCPU PC is changed. Without
> flushing the icache the vCPU may continue executing stale instructions.
> 
> In this patch we introduce VA-based icache flushing macros. Also expose
> the xc_domain_cacheflush through xenctrl.h.
> 
> Signed-off-by: Tamas K Lengyel 
> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> 
> Note: patch has been verified to solve stale icache issues on the
>   HiKey platform.
> 
> v2: Return 0 on x86 and clarify comment in xenctrl.h
> ---
>  tools/libxc/include/xenctrl.h|  8 
>  tools/libxc/xc_domain.c  |  6 +++---
>  tools/libxc/xc_private.h |  3 ---

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH RFC 0/6] COLO-Proxy: Make Xen COLO use userspace colo-proxy

[Wei Liu]

On Thu, Jan 26, 2017 at 02:36:03PM +0800, Zhang Chen wrote:
> Hi~ All~ Happy Chinese New Year~~

Happy Chinese New Year to you, too!

I skimmed through this series and made some comments based on my
preliminary assessment. If you have any questions, feel free to ask.

I suppose we would need to have a few more rounds to hash out all the
details.

Wei.

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

Re: [Xen-devel] [PATCH RFC 2/6] COLO-Proxy: Setup userspace colo-proxy on primary side

[Wei Liu]

On Thu, Jan 26, 2017 at 02:36:05PM +0800, Zhang Chen wrote:
> In this patch we close kernel COLO-Proxy on primary side.
> 
> Signed-off-by: Zhang Chen 

Acked-by: Wei Liu 

I don't claim I know much about COLO though, nor have I ever run it, so
it would be better to have a second eye on this patch.

There are some style nits below.

> ---
>  tools/libxl/libxl_colo_proxy.c | 30 ++
>  tools/libxl/libxl_colo_save.c  |  9 +++--
>  2 files changed, 37 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl_colo_proxy.c b/tools/libxl/libxl_colo_proxy.c
> index 0983f42..348484d 100644
> --- a/tools/libxl/libxl_colo_proxy.c
> +++ b/tools/libxl/libxl_colo_proxy.c
> @@ -152,6 +152,11 @@ int colo_proxy_setup(libxl__colo_proxy_state *cps)
>  
>  STATE_AO_GC(cps->ao);
>  
> +if (cps->is_userspace_proxy) {
> +/* If enable userspace proxy mode, we don't need setup kernel proxy 
> */
> +return 0;
> +}
> +

There is only one statement so no need to have {}.

You can move the comment before "if" and remove {}.

Same rule applies to all the patches.

Wei.

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

Re: [Xen-devel] [PATCH RFC 6/6] COLO-Proxy: Use socket to get checkpoint event.

[Wei Liu]

On Thu, Jan 26, 2017 at 02:36:09PM +0800, Zhang Chen wrote:
> We use old kernel colo proxy way to get the checkpoint event from qemu.
> This patch have some TODO job.
> Qemu compare need add a API to support this(I will add this in qemu).
> 
> Signed-off-by: Zhang Chen 

No major objection but this patch probably needs reworking if you change
your previous patches.

Wei.

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

Re: [Xen-devel] [PATCH RFC 1/6] COLO-Proxy: Add remus command to open userspace proxy

[Wei Liu]

On Thu, Jan 26, 2017 at 02:36:04PM +0800, Zhang Chen wrote:
> Add remus '-p' to enable userspace colo proxy(in qemu).
> 
> Signed-off-by: Zhang Chen 
> ---
>  docs/man/xl.pod.1.in  |  4 
>  tools/libxl/libxl_colo.h  |  5 +
>  tools/libxl/libxl_colo_save.c |  2 ++
>  tools/libxl/libxl_types.idl   | 17 +
>  tools/libxl/xl_cmdimpl.c  | 13 -
>  tools/libxl/xl_cmdtable.c |  3 ++-
>  6 files changed, 34 insertions(+), 10 deletions(-)
> 
> diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.pod.1.in
> index 09c1faa..b5fb7c1 100644
> --- a/docs/man/xl.pod.1.in
> +++ b/docs/man/xl.pod.1.in
> @@ -553,6 +553,10 @@ Disable disk replication. Requires enabling unsafe mode.
>  Enable COLO HA. This conflicts with B<-i> and B<-b>, and memory
>  checkpoint compression must be disabled.
>  
> +=item B<-p>
> +
> +Enable userspace COLO Proxy. Must open with B<-c>.
> +

Use userspace COLO Proxy. This option must be used in conjunction with B<-c>.

>  =back
>  
>  =item B I
> diff --git a/tools/libxl/libxl_colo.h b/tools/libxl/libxl_colo.h
> index 682275c..4746d8c 100644
> --- a/tools/libxl/libxl_colo.h
> +++ b/tools/libxl/libxl_colo.h
> @@ -64,6 +64,11 @@ struct libxl__colo_proxy_state {
>  
>  int sock_fd;
>  int index;
> +/*
> + * Private, True means use userspace colo proxy
> + *  False means use kernel colo proxy.
> + */
> +bool is_userspace_proxy;
>  };
>  
>  struct libxl__colo_save_state {
> diff --git a/tools/libxl/libxl_colo_save.c b/tools/libxl/libxl_colo_save.c
> index 620..eb8336c 100644
> --- a/tools/libxl/libxl_colo_save.c
> +++ b/tools/libxl/libxl_colo_save.c
> @@ -101,6 +101,8 @@ void libxl__colo_save_setup(libxl__egc *egc, 
> libxl__colo_save_state *css)
>  css->qdisk_setuped = false;
>  css->qdisk_used = false;
>  libxl__ev_child_init(>child);
> +css->cps.is_userspace_proxy =
> +libxl_defbool_val(dss->remus->userspace_colo_proxy);
>  
>  if (dss->remus->netbufscript)
>  css->colo_proxy_script = libxl__strdup(gc, dss->remus->netbufscript);
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index a612d1f..1bd2057 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -844,14 +844,15 @@ libxl_sched_credit2_params = 
> Struct("sched_credit2_params", [
>  ], dispose_fn=None)
>  
>  libxl_domain_remus_info = Struct("domain_remus_info",[
> -("interval", integer),
> -("allow_unsafe", libxl_defbool),
> -("blackhole",libxl_defbool),
> -("compression",  libxl_defbool),
> -("netbuf",   libxl_defbool),
> -("netbufscript", string),
> -("diskbuf",  libxl_defbool),
> -("colo", libxl_defbool)
> +("interval", integer),
> +("allow_unsafe", libxl_defbool),
> +("blackhole",libxl_defbool),
> +("compression",  libxl_defbool),
> +("netbuf",   libxl_defbool),
> +("netbufscript", string),
> +("diskbuf",  libxl_defbool),
> +("colo", libxl_defbool),
> +("userspace_colo_proxy", libxl_defbool)

Please add a LIBXL_HAVE macro in libxl.h.

>  ])
>  
>  libxl_event_type = Enumeration("event_type", [
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 7e8a8ae..905c5f6 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -8893,7 +8893,7 @@ int main_remus(int argc, char **argv)
>  
>  memset(_info, 0, sizeof(libxl_domain_remus_info));
>  
> -SWITCH_FOREACH_OPT(opt, "Fbundi:s:N:ec", NULL, "remus", 2) {
> +SWITCH_FOREACH_OPT(opt, "Fbundi:s:N:ecp", NULL, "remus", 2) {
>  case 'i':
>  r_info.interval = atoi(optarg);
>  break;
> @@ -8923,6 +8923,9 @@ int main_remus(int argc, char **argv)
>  break;
>  case 'c':
>  libxl_defbool_set(_info.colo, true);
> +break;
> +case 'p':
> +libxl_defbool_set(_info.userspace_colo_proxy, true);
>  }
>  
>  domid = find_domain(argv[optind]);
> @@ -8931,9 +8934,17 @@ int main_remus(int argc, char **argv)
>  /* Defaults */
>  libxl_defbool_setdefault(_info.blackhole, false);
>  libxl_defbool_setdefault(_info.colo, false);
> +libxl_defbool_setdefault(_info.userspace_colo_proxy, false);
> +

Hmm... I think setting defaults should be pushed into libxl.

But I think this is issue is orthogonal to this patch, and we can
revisit this later.

>  if (!libxl_defbool_val(r_info.colo) && !r_info.interval)
>  r_info.interval = 200;
>  
> +if (libxl_defbool_val(r_info.userspace_colo_proxy) &&
> +!libxl_defbool_val(r_info.colo)) {
> +perror("option -p must open with -c");

"Option -p must be used in conjunction with -c".

And please use fprintf(stderr,...) here because libxl_defbool_val
doesn't touch errno.


> +exit(-1);
> +}
> +
>  if 

[Xen-devel] [PATCH v2] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

[Tamas K Lengyel]

When the toolstack modifies memory of a running ARM VM it may happen
that the underlying memory of a current vCPU PC is changed. Without
flushing the icache the vCPU may continue executing stale instructions.

In this patch we introduce VA-based icache flushing macros. Also expose
the xc_domain_cacheflush through xenctrl.h.

Signed-off-by: Tamas K Lengyel 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Stefano Stabellini 
Cc: Julien Grall 

Note: patch has been verified to solve stale icache issues on the
  HiKey platform.

v2: Return 0 on x86 and clarify comment in xenctrl.h
---
 tools/libxc/include/xenctrl.h|  8 
 tools/libxc/xc_domain.c  |  6 +++---
 tools/libxc/xc_private.h |  3 ---
 xen/arch/arm/mm.c|  1 +
 xen/include/asm-arm/arm32/page.h |  3 +++
 xen/include/asm-arm/arm64/page.h |  3 +++
 xen/include/asm-arm/page.h   | 31 +++
 7 files changed, 49 insertions(+), 6 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 63c616ff6a..a2f23fcd5a 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2720,6 +2720,14 @@ int xc_livepatch_revert(xc_interface *xch, char *name, 
uint32_t timeout);
 int xc_livepatch_unload(xc_interface *xch, char *name, uint32_t timeout);
 int xc_livepatch_replace(xc_interface *xch, char *name, uint32_t timeout);
 
+/*
+ * Ensure cache coherency after memory modifications. A call to this function
+ * is only required on ARM as the x86 architecture provides cache coherency
+ * guarantees. Calling this function on x86 is allowed but has no effect.
+ */
+int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
+ xen_pfn_t start_pfn, xen_pfn_t nr_pfns);
+
 /* Compat shims */
 #include "xenctrl_compat.h"
 
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 296b8523b5..98ab6ba3fd 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -74,10 +74,10 @@ int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
 /*
  * The x86 architecture provides cache coherency guarantees which prevent
  * the need for this hypercall.  Avoid the overhead of making a hypercall
- * just for Xen to return -ENOSYS.
+ * just for Xen to return -ENOSYS.  It is safe to ignore this call on x86
+ * so we just return 0.
  */
-errno = ENOSYS;
-return -1;
+return 0;
 #else
 DECLARE_DOMCTL;
 domctl.cmd = XEN_DOMCTL_cacheflush;
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index 97445ae1fe..fddebdc917 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -366,9 +366,6 @@ void bitmap_byte_to_64(uint64_t *lp, const uint8_t *bp, int 
nbits);
 /* Optionally flush file to disk and discard page cache */
 void discard_file_cache(xc_interface *xch, int fd, int flush);
 
-int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
-xen_pfn_t start_pfn, xen_pfn_t nr_pfns);
-
 #define MAX_MMU_UPDATES 1024
 struct xc_mmu {
 mmu_update_t updates[MAX_MMU_UPDATES];
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 99588a330d..43e5b3d9e2 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -389,6 +389,7 @@ void flush_page_to_ram(unsigned long mfn)
 void *v = map_domain_page(_mfn(mfn));
 
 clean_and_invalidate_dcache_va_range(v, PAGE_SIZE);
+invalidate_icache_va_range(v, PAGE_SIZE);
 unmap_domain_page(v);
 }
 
diff --git a/xen/include/asm-arm/arm32/page.h b/xen/include/asm-arm/arm32/page.h
index ea4b312c70..10e5288d0f 100644
--- a/xen/include/asm-arm/arm32/page.h
+++ b/xen/include/asm-arm/arm32/page.h
@@ -19,6 +19,9 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
 : : "r" (pte.bits), "r" (p) : "memory");
 }
 
+/* Inline ASM to invalidate icache on register R (may be an inline asm 
operand) */
+#define __invalidate_icache_one(R) STORE_CP32(R, ICIMVAU)
+
 /* Inline ASM to invalidate dcache on register R (may be an inline asm 
operand) */
 #define __invalidate_dcache_one(R) STORE_CP32(R, DCIMVAC)
 
diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
index 23d778154d..0f380b95b4 100644
--- a/xen/include/asm-arm/arm64/page.h
+++ b/xen/include/asm-arm/arm64/page.h
@@ -16,6 +16,9 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
 : : "r" (pte.bits), "r" (p) : "memory");
 }
 
+/* Inline ASM to invalidate icache on register R (may be an inline asm 
operand) */
+#define __invalidate_icache_one(R) "ic ivau, %" #R ";"
+
 /* Inline ASM to invalidate dcache on register R (may be an inline asm 
operand) */
 #define __invalidate_dcache_one(R) "dc ivac, %" #R ";"
 
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index c492d6df50..a618d0e556 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ 

Re: [Xen-devel] [PATCH v5 4/9] xen/x86: populate PVHv2 Dom0 physical memory map

[Jan Beulich]

>>> On 27.01.17 at 14:20,  wrote:
> At 12:51 + on 27 Jan (1485521470), Andrew Cooper wrote:
>> On 27/01/17 11:14, Tim Deegan wrote:
>> > But looking at it now, I'm not convinced of exactly how.  The magic
>> > bitmap in the TSS is at [I/O Map Base Address] - 32, and the I/O map
>> > base address itself lives at offset 100.  A zero'd TSS should mean an
>> > I/O map at 0, and an interrupt redirection bitmap at -32, which would
>> > plausibly work if the TSS were 256 bytes (matching the limit set in
>> > Xen).  Perhaps it's only working because the 128 bytes following the
>> > TSS in hvmloader happen to be zeros too?
>> 
>> With an IO_base_map of 0, the software interrupt bitmap will end up
>> being ahead of the TSS, not after it.
> 
> I should have thought that the segmented address calculation would
> wrap and leave us at TSS + 224.

I don't think wrapping takes the limit value into account. It's all
linear address calculations, and as Andrew says the assumption
in microcode likely is that things will be set up properly by any
OS interested in using the interrupt bitmap.

>> > I also don't remember why the TSS is 128 rather than 104 bytes.  The
>> > SDM claims that the TSS must be larger than 104 bytes "when accessing
>> > the I/O permission bit map or interrupt redirection bit map."
>> > (7.2.2. "TSS Descriptor") but I suspect that just means that the
>> > generated address of the bitmap must lie inside the limit.
>> 
>> The documented way of expressing "no IO bitmap" is to set the map base
>> to a value which exceeds the TSS limit.  All this means (I think) is
>> that you must make a larger than default TSS if you want to use a IO or
>> software interrupt bitmap.
> 
> Yes, I wonder about the I/O bitmap too.  We don't provide one, or even
> enough space for a full one, but the current SDM is pretty clear that
> the CPU will try to check it in virtual 8086 mode.
> 
> It may be that all the ports actually used happen to fall in the 128
> bytes of zeros that we provide.

I suppose so: This is precisely enough for the ISA port range.

So what we'll need to do then, as I understand it from the
discussion so far:

- vmx_set_segment_register() will need to set a correct limit
- vmx_set_segment_register() should initialize the TSS every
  time (including setting the I/O bitmap address to no lower
  than 32)
- hvmloader's init_vm86_tss() will need to allocate 160 bytes
  rather than 128 (and we should expose this number, so that
  Roger can also use it)

Perhaps we should even introduce a hypercall for hvmloader
to query the needed value, rather than exposing a hardcoded
number?

Jan


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

Re: [Xen-devel] [PATCH v15] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other.

[Konrad Rzeszutek Wilk]

On Fri, Jan 27, 2017 at 05:50:36PM +0200, Oleksandr Andrushchenko wrote:
> thank you for comments, please find answers below
> 
> Can we please switch to v16 discussion as v15 vs v16 is
> a big change?



This channel seemed appropiate to hash this out. I will
look at v16 next week (out of time for reviews for today).

See below.
> 
> On 01/27/2017 05:14 PM, Konrad Rzeszutek Wilk wrote:
> > On Thu, Jan 26, 2017 at 12:02:49PM +0200, Oleksandr Andrushchenko wrote:
> > > Hi, Konrad!
> > > 
> > > First of all thank you very much for the valuable comments
> > > 
> > > and your time!
> > > 
> > > The number of changes (mostly in description) is going to
> > > 
> > > be huge, so do you think I can publish something like
> > > 
> > > "RFC v16" so we can discuss the updated patch?
> > RFC sadly means folks are going to mostly ignore it.
> > I would prefer you did not use RFC at this stage but just
> > did v16.
> > ..snip..
> sure
> > > > > + * Example for the frontend running in domain 5, instance of the 
> > > > > driver
> > > > > + * in the front is 0 (single or first PV driver), device id 2,
> > > > > + * first stream (0):
> > > > > + * /local/domain//device/vsnd//
> > > > > + * device//stream//type = "p"
> > > > > + * /local/domain/5/device/vsnd/0/device/2/stream/0/type = "p"
> > > > Why do you need 'device' ?
> > > just for clarity: the hierarchy of the sound driver would
> > > be that a device may have multiple different streams.
> > And it just occured to me that you could also imply that
> > each device has an stream without the 'stream' in it.
> > 
> > So
> > 
> > /local/domain/5/device/vsnd/0/2/0/type = "p"
> > 
> > And the format is:
> > /local/domain//device/vsnd/ > driver>//
> ok, so we'll end up with something like:
> 
> - Backend
> ---
> 
> /local/domain/0/backend/vsnd/1/0/frontend-id = "1"
> /local/domain/0/backend/vsnd/1/0/frontend = "/local/domain/1/device/vsnd/0"
> /local/domain/0/backend/vsnd/1/0/state = "4"
> /local/domain/0/backend/vsnd/1/0/versions = "1,2"



> 
> - Card 
> 
> /local/domain/1/device/vsnd/0/version = "1"
> /local/domain/1/device/vsnd/0/short-name = "Card short name"
> /local/domain/1/device/vsnd/0/long-name = "Card long name"
> /local/domain/1/device/vsnd/0/sample-rates = "8000,32000,44100,48000,96000"
> /local/domain/1/device/vsnd/0/sample-formats = "s8,u8,s16_le,s16_be"
> /local/domain/1/device/vsnd/0/buffer-size = "262144"


> 
> - PCM device 0 
> 
> /local/domain/1/device/vsnd/0/0/name = "General analog"
> /local/domain/1/device/vsnd/0/0/channels-max = "5"


> 
> - Stream 0, playback
> 
> 
> /local/domain/1/device/vsnd/0/0/0/type = "p"
> /local/domain/1/device/vsnd/0/0/0/sample-formats = "s8,u8"
> /local/domain/1/device/vsnd/0/0/0/unique-id = "0"
> /local/domain/1/device/vsnd/0/0/0/ring-ref = "386"
> /local/domain/1/device/vsnd/0/0/0/event-channel = "15"


> 
> --- PCM device 3
> 
> 
> /local/domain/1/device/vsnd/0/3/name = "HDMI-0"
> /local/domain/1/device/vsnd/0/3/sample-rates = "8000,32000,44100"


> 
> -- Stream 0, capture
> 
> 
> /local/domain/1/device/vsnd/0/3/0/type = "c"
> /local/domain/1/device/vsnd/0/3/0/unique-id = "2"
> /local/domain/1/device/vsnd/0/3/0/ring-ref = "387"
> /local/domain/1/device/vsnd/0/3/0/event-channel = "151"
> 
> Is this what you would like to see?

Yes.
> IMO, all these values do not help understanding what it is, e.g.
> this is equal to me if we have
> 
> /local/domain/1/device/vbd/51712/queue-0/ring-ref = "8"
> /local/domain/1/device/vbd/51712/queue-0/event-channel = "3"
> /local/domain/1/device/vbd/51712/queue-1 = ""
> /local/domain/1/device/vbd/51712/queue-1/ring-ref = "9"
> 
> and then decided to go with
> 
> /local/domain/1/device/vbd/51712/0/ring-ref = "8"
> /local/domain/1/device/vbd/51712/0/event-channel = "3"
> /local/domain/1/device/vbd/51712/1/ring-ref = "9"
> 
> Can one easily tell what 0 or 1 after "51712/" is?

I do. But maybe my brain has been swimming in this too much?

> 
> So, what is the final decision then?

> 
> > Though I have a little of trouble with the 'instance of the
> > driver'. Are you suggesting you would have multiple
> > PV drivers of 'vsnd'? Can't the multiple device ids fulfill this?
> it is possible, but the main use-case will have a single
> PV driver with multiple PCM devices/streams

OK, so no need for this then.
.. snip..
> > > > > + * operation - XENSND_OP_SET_VOLUME for volume set
> > > > > + *   or XENSND_OP_GET_VOLUME for volume get
> > > > > + * Buffer passed with XENSND_OP_OPEN is used to exchange volume
> > > > > + * values:
> > > > Oh. That means you these operation are in effect 'barrier' ones.
> > > > 
> > > > As the buffer must be flushed 

Re: [Xen-devel] [PATCH] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

[Wei Liu]

On Fri, Jan 27, 2017 at 09:32:25AM -0700, Tamas K Lengyel wrote:
> On Fri, Jan 27, 2017 at 9:29 AM, Julien Grall  wrote:
> > Hi Tamas,
> >
> > On 27/01/17 16:23, Tamas K Lengyel wrote:
> >>
> >> On Fri, Jan 27, 2017 at 9:15 AM, Julien Grall 
> >> wrote:
> >>>
> >>> Hello,
> >>>
> >>> On 27/01/17 15:52, Tamas K Lengyel wrote:
> 
> 
>  Well, yes, only ARM could _should_ call this function. The comment I
>  think is important to tell the user don't expect it to do anything on
>  x86.  Doesn't mean they can't call it though - if that was the case it
>  would be wrapped in an ifdef like all the other architecture specific
>  bits in the header. I would think that's pretty straight forward. No
>  objection to clarifing the comment though if it helps.
> >>>
> >>>
> >>>
> >>> If you looked at the commit log, the #ifdef was added to avoid calling
> >>> the
> >>> hypervisor for nothing and therefore saving few hundred cycles bit of
> >>> time.
> >>> Technically speaking, this helper abstracts the architectural behavior of
> >>> the cache. So it makes sense to call it on x86 even if it is a nop.
> >>
> >>
> >> Except that on x86 the user should be aware that it returns an error,
> >> which is normal and can be ignored.
> >
> >
> > It looks like the current callers does not check the return. However, it
> > would more make sense to return 0 if we expect nothing to be done rather
> > than -ENOSYS.
> >
> 
> That would be fine by me. Wei, what do you think?
> 

No objection from me.

> Tamas

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

Re: [Xen-devel] [PATCH] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

[Tamas K Lengyel]

On Fri, Jan 27, 2017 at 9:29 AM, Julien Grall  wrote:
> Hi Tamas,
>
> On 27/01/17 16:23, Tamas K Lengyel wrote:
>>
>> On Fri, Jan 27, 2017 at 9:15 AM, Julien Grall 
>> wrote:
>>>
>>> Hello,
>>>
>>> On 27/01/17 15:52, Tamas K Lengyel wrote:


 Well, yes, only ARM could _should_ call this function. The comment I
 think is important to tell the user don't expect it to do anything on
 x86.  Doesn't mean they can't call it though - if that was the case it
 would be wrapped in an ifdef like all the other architecture specific
 bits in the header. I would think that's pretty straight forward. No
 objection to clarifing the comment though if it helps.
>>>
>>>
>>>
>>> If you looked at the commit log, the #ifdef was added to avoid calling
>>> the
>>> hypervisor for nothing and therefore saving few hundred cycles bit of
>>> time.
>>> Technically speaking, this helper abstracts the architectural behavior of
>>> the cache. So it makes sense to call it on x86 even if it is a nop.
>>
>>
>> Except that on x86 the user should be aware that it returns an error,
>> which is normal and can be ignored.
>
>
> It looks like the current callers does not check the return. However, it
> would more make sense to return 0 if we expect nothing to be done rather
> than -ENOSYS.
>

That would be fine by me. Wei, what do you think?

Tamas

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

Re: [Xen-devel] [PATCH v5 4/9] xen/x86: populate PVHv2 Dom0 physical memory map

[Jan Beulich]

>>> On 27.01.17 at 17:04,  wrote:
> On Fri, Jan 27, 2017 at 08:11:56AM -0700, Jan Beulich wrote:
>> >>> On 27.01.17 at 13:23,  wrote:
>> > On Thu, Jan 26, 2017 at 05:41:58AM -0700, Jan Beulich wrote:
>> >> >>> On 19.01.17 at 18:29,  wrote:
>> >> > @@ -43,6 +44,9 @@ static long __initdata dom0_nrpages;
>> >> >  static long __initdata dom0_min_nrpages;
>> >> >  static long __initdata dom0_max_nrpages = LONG_MAX;
>> >> >  
>> >> > +/* Size of the VM86 TSS for virtual 8086 mode to use. */
>> >> > +#define HVM_VM86_TSS_SIZE   128
>> >> 
>> >> I continue to be puzzled by this value. Why 128? I think this really
>> >> needs to be clarified in the comment.
>> > 
>> > Given the recent comments by Tim, and that this is starting to look like a 
>> > can
>> > of worms, I would like to leave this as-is for the moment, on the grounds 
>> > that
>> > it's what hvmloader does (I'm not saying it's right), and that this issue
>> > should be treated independently from this patch series.
>> 
>> Well, for the purpose of this patch it would be sufficient if the
>> comment referred to hvmloader. But then I think I saw you set the
>> TSS limit to 0x67, which is neither in line with the value above nor
> 
> Hm, no, I'm not setting the limit anywhere here, this is done in
> vmx_set_segment_register,

Well, you do, in patch 8 (in pvh_setup_cpus()). But that's a different
TSS, so the limits are independent. It's just what I had in mind here.

> and it's indeed set to 0xff which is wrong for
> hvmloader too according to the conversation that's going on related to this
> HVM_VM86_TSS_SIZE param.

Right.

>> - according to what Tim said (but I didn't check myself yet) - the
>> 255 used in hvmloader. I.e. if you clone hvmloader code, all
>> aspects of it should match.
>> 
>> > Alternatively, I can just remove setting HVM_PARAM_VM86_TSS for a PVHv2 
>> > Dom0.
>> > IIRC I've tried that before (without unrestricted mode support) and it was
>> > working fine.
>> 
>> Now if that's the case, then why bother with the TSS?
> 
> It seems like it working was just luck, but I don't know all the details. 
> Maybe
> the emulator is somehow fixing this up when the TSS is corrupted/incorrect?

I don't think so. Btw, why is the kernel dropping back into real mode
anyway? It's being started in protected mode after all.

>> > Given the change that you requested in pvh_steal_ram, now the start of the
>> > memory area returned by it it's not going to be page-aligned, so I will 
>> > have to
>> > perform the TSS setup first, and then the identity page tables.
>> 
>> Or simply pass the required alignment.
> 
> Passing an alignment here would mean that pvh_steal_ram would have to return 2
> pages in order to meet this alignment, and we would end up wasting memory.
> Also, this is the only caller of pvh_steal_ram that requires alignment. This 
> is
> what I have after changing pvh_steal_ram to remove RAM from the end of the
> region:
> 
> static int __init pvh_setup_vmx_realmode_helpers(struct domain *d)
> {
> p2m_type_t p2mt;
> uint32_t rc, *ident_pt;
> uint8_t *tss;
> mfn_t mfn;
> paddr_t gaddr;
> 
> /*
>  * Steal some space from the last found RAM region. One page will be
>  * used for the identity page tables, and the remaining space for the
>  * VM86 TSS. Note that after this not all e820 regions will be aligned
>  * to PAGE_SIZE.
>  */
> if ( pvh_steal_ram(d, PAGE_SIZE + HVM_VM86_TSS_SIZE, GB(4), ) )
> {
> printk("Unable to find memory to stash the identity map and TSS\n");
> return -ENOMEM;
> }
> 
> tss = map_domain_gfn(p2m_get_hostp2m(d), _gfn(PFN_DOWN(gaddr)),
>  , , 0, );
> if ( tss )
> {
> memset(tss, 0, HVM_VM86_TSS_SIZE);
> unmap_domain_page(tss);
> put_page(mfn_to_page(mfn_x(mfn)));
> d->arch.hvm_domain.params[HVM_PARAM_VM86_TSS] = gaddr;
> }
> else
> printk("Unable to map VM86 TSS area\n");
> 
> gaddr += HVM_VM86_TSS_SIZE;
> ASSERT(IS_ALIGNED(gaddr, PAGE_SIZE));

And this assert holds merely because, prior to this function running,
all E820 entries are page aligned? That's rather fragile then.
Considering that getting into here is going to be increasingly unlikely
going forward, I don't think we should be afraid of wasting a little
bit of memory here.

Jan

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

Re: [Xen-devel] [PATCH] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

[Julien Grall]

Hi Tamas,

On 27/01/17 16:23, Tamas K Lengyel wrote:

On Fri, Jan 27, 2017 at 9:15 AM, Julien Grall  wrote:

Hello,

On 27/01/17 15:52, Tamas K Lengyel wrote:


Well, yes, only ARM could _should_ call this function. The comment I
think is important to tell the user don't expect it to do anything on
x86.  Doesn't mean they can't call it though - if that was the case it
would be wrapped in an ifdef like all the other architecture specific
bits in the header. I would think that's pretty straight forward. No
objection to clarifing the comment though if it helps.



If you looked at the commit log, the #ifdef was added to avoid calling the
hypervisor for nothing and therefore saving few hundred cycles bit of time.
Technically speaking, this helper abstracts the architectural behavior of
the cache. So it makes sense to call it on x86 even if it is a nop.


Except that on x86 the user should be aware that it returns an error,
which is normal and can be ignored.


It looks like the current callers does not check the return. However, it 
would more make sense to return 0 if we expect nothing to be done rather 
than -ENOSYS.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

[Tamas K Lengyel]

On Fri, Jan 27, 2017 at 9:15 AM, Julien Grall  wrote:
> Hello,
>
> On 27/01/17 15:52, Tamas K Lengyel wrote:
>>
>> Well, yes, only ARM could _should_ call this function. The comment I
>> think is important to tell the user don't expect it to do anything on
>> x86.  Doesn't mean they can't call it though - if that was the case it
>> would be wrapped in an ifdef like all the other architecture specific
>> bits in the header. I would think that's pretty straight forward. No
>> objection to clarifing the comment though if it helps.
>
>
> If you looked at the commit log, the #ifdef was added to avoid calling the
> hypervisor for nothing and therefore saving few hundred cycles bit of time.
> Technically speaking, this helper abstracts the architectural behavior of
> the cache. So it makes sense to call it on x86 even if it is a nop.

Except that on x86 the user should be aware that it returns an error,
which is normal and can be ignored.

>
> Now, if you are saying that on x86 it might be necessary to also clean the
> guest memory range. Then it would be worth to consider implementing the
> hypercall.
>

I'm not aware of this being needed on x86.

Tamas

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

Re: [Xen-devel] [PATCH] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

[Julien Grall]

Hello,

On 27/01/17 15:52, Tamas K Lengyel wrote:

Well, yes, only ARM could _should_ call this function. The comment I
think is important to tell the user don't expect it to do anything on
x86.  Doesn't mean they can't call it though - if that was the case it
would be wrapped in an ifdef like all the other architecture specific
bits in the header. I would think that's pretty straight forward. No
objection to clarifing the comment though if it helps.


If you looked at the commit log, the #ifdef was added to avoid calling 
the hypervisor for nothing and therefore saving few hundred cycles bit 
of time. Technically speaking, this helper abstracts the architectural 
behavior of the cache. So it makes sense to call it on x86 even if it is 
a nop.


Now, if you are saying that on x86 it might be necessary to also clean 
the guest memory range. Then it would be worth to consider implementing 
the hypercall.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2] xen, input: try to read screen resolution for xen-kbdfront

[Dmitry Torokhov]

On January 27, 2017 12:31:19 AM PST, Juergen Gross  wrote:
>On 27/01/17 09:26, Oleksandr Andrushchenko wrote:
>> On 01/27/2017 10:14 AM, Juergen Gross wrote:
>>> On 27/01/17 08:53, Oleksandr Andrushchenko wrote:
 On 01/27/2017 09:46 AM, Juergen Gross wrote:
> On 27/01/17 08:21, Oleksandr Andrushchenko wrote:
>> On 01/27/2017 09:12 AM, Juergen Gross wrote:
>>> Instead of using the default resolution of 800*600 for the
>pointing
>>> device of xen-kbdfront try to read the resolution of the
>(virtual)
>>> framebuffer device. Use the default as fallback only.
>>>
>>> Signed-off-by: Juergen Gross 
>>> ---
>>> V2: get framebuffer resolution only if CONFIG_FB (Dmitry
>Torokhov)
>>> ---
>>> drivers/input/misc/xen-kbdfront.c | 15 ---
>>> 1 file changed, 12 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/input/misc/xen-kbdfront.c
>>> b/drivers/input/misc/xen-kbdfront.c
>>> index 3900875..3aae9b4 100644
>>> --- a/drivers/input/misc/xen-kbdfront.c
>>> +++ b/drivers/input/misc/xen-kbdfront.c
>>> @@ -16,6 +16,7 @@
>>> #include 
>>> #include 
>>> #include 
>>> +#include 
>>> #include 
>>> #include 
>>> @@ -108,7 +109,7 @@ static irqreturn_t input_handler(int rq,
>void
>>> *dev_id)
>>> static int xenkbd_probe(struct xenbus_device *dev,
>>>   const struct xenbus_device_id *id)
>>> {
>>> -int ret, i;
>>> +int ret, i, width, height;
>>> unsigned int abs;
>>> struct xenkbd_info *info;
>>> struct input_dev *kbd, *ptr;
>>> @@ -173,9 +174,17 @@ static int xenkbd_probe(struct
>xenbus_device
>>> *dev,
>>> ptr->id.product = 0xfffe;
>>>   if (abs) {
>>> +width = XENFB_WIDTH;
>>> +height = XENFB_HEIGHT;
>>> +#ifdef CONFIG_FB
>>> +if (registered_fb[0]) {
>> This still will not help if FB gets registered after kbd+ptr
> Hmm, so you think I should add a call to fb_register_client() to
>get
> events for new registered framebuffer devices?
 yes, but also pay attention to CONFIG_FB_NOTIFY: you may still
 end up w/o notification.
>>> Okay, that's not worse than today.
>> agree
> This would probably work. I'll have a try.
>
>
> Thanks,
>
> Juergen
 My bigger concern here is that we try to tie keyboard and pointer
>device
 to the framebuffer. IMO, these are independent parts of the system
>and
 the relation
 depends on the use-case. One can have graphics enabled w/o
>framebuffer
 at all, e.g.
 DRM/KMS + OpenGLES + Weston + kbd + ptr...
>>> Again: that's a use case which will work as today. The current
>defaults
>>> are being used.
>>>
>>> The question is whether we should add a module parameter switching
>off
>>> the automatic adaption of the resolution as there might be use cases
>>> where we don't want this feature.
>> I think for those who doesn't want this resolution there is
>> still a possibility to change it on backend's XenbusStateConnected
>> So, no need for module parameter, IMO
>
>Fine.
>
>I'll send V3 soon.

How about you do the axis adjustment from userspace (udev rule), and leave 
kernel as is?


Thanks.

-- 
Dmitry

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

Re: [Xen-devel] [PATCH] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

[Wei Liu]

On Fri, Jan 27, 2017 at 08:52:50AM -0700, Tamas K Lengyel wrote:
> On Jan 27, 2017 08:43, "Wei Liu"  wrote:
> 
> On Fri, Jan 27, 2017 at 08:37:33AM -0700, Tamas K Lengyel wrote:
> > On Fri, Jan 27, 2017 at 7:49 AM, Wei Liu  wrote:
> > > On Thu, Jan 26, 2017 at 03:16:22PM -0700, Tamas K Lengyel wrote:
> > >> When the toolstack modifies memory of a running ARM VM it may happen
> > >> that the underlying memory of a current vCPU PC is changed. Without
> > >> flushing the icache the vCPU may continue executing stale instructions.
> > >>
> > >
> > > Why is this not an issue for x86? Is this because ARM handles coherency
> > > differently from x86?
> > >
> > >> In this patch we introduce VA-based icache flushing macros. Also expose
> > >> the xc_domain_cacheflush through xenctrl.h.
> > >>
> > >> Signed-off-by: Tamas K Lengyel 
> > >> ---
> > >> Cc: Ian Jackson 
> > >> Cc: Wei Liu 
> > >> Cc: Stefano Stabellini 
> > >> Cc: Julien Grall 
> > >>
> > >> Note: patch has been verified to solve stale icache issues on the
> > >>   HiKey platform.
> > >> ---
> > >>  tools/libxc/include/xenctrl.h|  6 ++
> > >>  tools/libxc/xc_private.h |  3 ---
> > >>  xen/arch/arm/mm.c|  1 +
> > >>  xen/include/asm-arm/arm32/page.h |  3 +++
> > >>  xen/include/asm-arm/arm64/page.h |  3 +++
> > >>  xen/include/asm-arm/page.h   | 31 +++
> > >>  6 files changed, 44 insertions(+), 3 deletions(-)
> > >>
> > >> diff --git a/tools/libxc/include/xenctrl.h
> b/tools/libxc/include/xenctrl.h
> > >> index 63c616ff6a..cb80a2b07c 100644
> > >> --- a/tools/libxc/include/xenctrl.h
> > >> +++ b/tools/libxc/include/xenctrl.h
> > >> @@ -2720,6 +2720,12 @@ int xc_livepatch_revert(xc_interface *xch, char
> *name, uint32_t timeout);
> > >>  int xc_livepatch_unload(xc_interface *xch, char *name, uint32_t
> timeout);
> > >>  int xc_livepatch_replace(xc_interface *xch, char *name, uint32_t
> timeout);
> > >>
> > >> +/*
> > >> + * ARM only. Ensure cache coherency after memory modifications.
> > >> + */
> > >
> > > The existing code doesn't suggest this is ARM only. This function is
> > > used in xc_dom_unmap_one etc. This comment looks wrong.
> > >
> > > I don't object to making this function externally visible though.
> > >
> > > Wei.
> >
> > Hi Wei,
> > the comment is correct, this domctl is for ARM only. If you check the
> > code in xc_domain.c for the function, you will find this:
> >
> > #if defined (__i386__) || defined (__x86_64__)
> > /*
> >  * The x86 architecture provides cache coherency guarantees which
> prevent
> >  * the need for this hypercall.  Avoid the overhead of making a
> hypercall
> >  * just for Xen to return -ENOSYS.
> >  */
> > errno = ENOSYS;
> > return -1;
> > #else
> >
> > I guess I could move this comment to xenctrl.h to avoid confusions like
> this.
> >
> 
> Maybe it is just me: I read this comment differently. It suggests only
> ARM code can call this function. In reality x86 can call it too, but it
> has no effect.
> 
> I would suggest either just drop the comment or make clear it only has
> effect on ARM.
> 
> 
> Well, yes, only ARM could _should_ call this function. The comment I think
> is important to tell the user don't expect it to do anything on x86.
> Doesn't mean they can't call it though - if that was the case it would be
> wrapped in an ifdef like all the other architecture specific bits in the
> header. I would think that's pretty straight forward. No objection to
> clarifing the comment though if it helps.
> 

Clarifying would be good enough for me.

> Tamas

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

Re: [Xen-devel] [PATCH v5 4/9] xen/x86: populate PVHv2 Dom0 physical memory map

[Roger Pau Monne]

On Fri, Jan 27, 2017 at 08:11:56AM -0700, Jan Beulich wrote:
> >>> On 27.01.17 at 13:23,  wrote:
> > On Thu, Jan 26, 2017 at 05:41:58AM -0700, Jan Beulich wrote:
> >> >>> On 19.01.17 at 18:29,  wrote:
> >> > @@ -43,6 +44,9 @@ static long __initdata dom0_nrpages;
> >> >  static long __initdata dom0_min_nrpages;
> >> >  static long __initdata dom0_max_nrpages = LONG_MAX;
> >> >  
> >> > +/* Size of the VM86 TSS for virtual 8086 mode to use. */
> >> > +#define HVM_VM86_TSS_SIZE   128
> >> 
> >> I continue to be puzzled by this value. Why 128? I think this really
> >> needs to be clarified in the comment.
> > 
> > Given the recent comments by Tim, and that this is starting to look like a 
> > can
> > of worms, I would like to leave this as-is for the moment, on the grounds 
> > that
> > it's what hvmloader does (I'm not saying it's right), and that this issue
> > should be treated independently from this patch series.
> 
> Well, for the purpose of this patch it would be sufficient if the
> comment referred to hvmloader. But then I think I saw you set the
> TSS limit to 0x67, which is neither in line with the value above nor

Hm, no, I'm not setting the limit anywhere here, this is done in
vmx_set_segment_register, and it's indeed set to 0xff which is wrong for
hvmloader too according to the conversation that's going on related to this
HVM_VM86_TSS_SIZE param.

> - according to what Tim said (but I didn't check myself yet) - the
> 255 used in hvmloader. I.e. if you clone hvmloader code, all
> aspects of it should match.
> 
> > Alternatively, I can just remove setting HVM_PARAM_VM86_TSS for a PVHv2 
> > Dom0.
> > IIRC I've tried that before (without unrestricted mode support) and it was
> > working fine.
> 
> Now if that's the case, then why bother with the TSS?

It seems like it working was just luck, but I don't know all the details. Maybe
the emulator is somehow fixing this up when the TSS is corrupted/incorrect?

> >> > @@ -333,7 +338,9 @@ static unsigned long __init compute_dom0_nr_pages(
> >> >  avail -= max_pdx >> s;
> >> >  }
> >> >  
> >> > -need_paging = opt_dom0_shadow || (is_pvh_domain(d) && 
> >> > !iommu_hap_pt_share);
> >> > +need_paging = opt_dom0_shadow ||
> >> > +  (has_hvm_container_domain(d) && (!iommu_hap_pt_share 
> >> > ||
> >> > +   
> >> > !paging_mode_hap(d)));
> >> 
> >> What is the !paging_mode_hap() part good for? It's being taken care
> >> of by checking opt_dom0_shadow already, isn't it? Alternatively, to
> >> make the distinction more obvious, I'd suggest
> >> 
> >> need_paging = has_hvm_container_domain(d)
> >>   ? !iommu_hap_pt_share || !paging_mode_hap(d)
> >>   : opt_dom0_shadow;
> > 
> > AFAICT it *might* be possible to run a PVHv2 Dom0 on a box with no EPT, but
> > with an IOMMU? Does that exist? In that case opt_dom0_shadow won't be set, 
> > but
> > paging_mode_hap would be false. Maybe that's just an impossible combination 
> > in
> > any case...
> 
> At least when running Xen itself virtualized, I wouldn't dare to assume
> this is an impossible combination. However, I can't see how that case
> would be handled any different by the original or the suggested
> replacement expressions: need_paging would get set either way afaict.

Oh yes, sorry, my reply was to the "What is the !paging_mode_hap() part good
for?" question. I've changed setting need_paging as you suggested.

> > Given the change that you requested in pvh_steal_ram, now the start of the
> > memory area returned by it it's not going to be page-aligned, so I will 
> > have to
> > perform the TSS setup first, and then the identity page tables.
> 
> Or simply pass the required alignment.

Passing an alignment here would mean that pvh_steal_ram would have to return 2
pages in order to meet this alignment, and we would end up wasting memory.
Also, this is the only caller of pvh_steal_ram that requires alignment. This is
what I have after changing pvh_steal_ram to remove RAM from the end of the
region:

static int __init pvh_setup_vmx_realmode_helpers(struct domain *d)
{
p2m_type_t p2mt;
uint32_t rc, *ident_pt;
uint8_t *tss;
mfn_t mfn;
paddr_t gaddr;

/*
 * Steal some space from the last found RAM region. One page will be
 * used for the identity page tables, and the remaining space for the
 * VM86 TSS. Note that after this not all e820 regions will be aligned
 * to PAGE_SIZE.
 */
if ( pvh_steal_ram(d, PAGE_SIZE + HVM_VM86_TSS_SIZE, GB(4), ) )
{
printk("Unable to find memory to stash the identity map and TSS\n");
return -ENOMEM;
}

tss = map_domain_gfn(p2m_get_hostp2m(d), _gfn(PFN_DOWN(gaddr)),
 , , 0, );
if ( tss )
{
memset(tss, 0, HVM_VM86_TSS_SIZE);
unmap_domain_page(tss);
put_page(mfn_to_page(mfn_x(mfn)));

Re: [Xen-devel] [PATCH] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

[Tamas K Lengyel]

On Jan 27, 2017 08:43, "Wei Liu"  wrote:

On Fri, Jan 27, 2017 at 08:37:33AM -0700, Tamas K Lengyel wrote:
> On Fri, Jan 27, 2017 at 7:49 AM, Wei Liu  wrote:
> > On Thu, Jan 26, 2017 at 03:16:22PM -0700, Tamas K Lengyel wrote:
> >> When the toolstack modifies memory of a running ARM VM it may happen
> >> that the underlying memory of a current vCPU PC is changed. Without
> >> flushing the icache the vCPU may continue executing stale instructions.
> >>
> >
> > Why is this not an issue for x86? Is this because ARM handles coherency
> > differently from x86?
> >
> >> In this patch we introduce VA-based icache flushing macros. Also expose
> >> the xc_domain_cacheflush through xenctrl.h.
> >>
> >> Signed-off-by: Tamas K Lengyel 
> >> ---
> >> Cc: Ian Jackson 
> >> Cc: Wei Liu 
> >> Cc: Stefano Stabellini 
> >> Cc: Julien Grall 
> >>
> >> Note: patch has been verified to solve stale icache issues on the
> >>   HiKey platform.
> >> ---
> >>  tools/libxc/include/xenctrl.h|  6 ++
> >>  tools/libxc/xc_private.h |  3 ---
> >>  xen/arch/arm/mm.c|  1 +
> >>  xen/include/asm-arm/arm32/page.h |  3 +++
> >>  xen/include/asm-arm/arm64/page.h |  3 +++
> >>  xen/include/asm-arm/page.h   | 31 +++
> >>  6 files changed, 44 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/tools/libxc/include/xenctrl.h
b/tools/libxc/include/xenctrl.h
> >> index 63c616ff6a..cb80a2b07c 100644
> >> --- a/tools/libxc/include/xenctrl.h
> >> +++ b/tools/libxc/include/xenctrl.h
> >> @@ -2720,6 +2720,12 @@ int xc_livepatch_revert(xc_interface *xch, char
*name, uint32_t timeout);
> >>  int xc_livepatch_unload(xc_interface *xch, char *name, uint32_t
timeout);
> >>  int xc_livepatch_replace(xc_interface *xch, char *name, uint32_t
timeout);
> >>
> >> +/*
> >> + * ARM only. Ensure cache coherency after memory modifications.
> >> + */
> >
> > The existing code doesn't suggest this is ARM only. This function is
> > used in xc_dom_unmap_one etc. This comment looks wrong.
> >
> > I don't object to making this function externally visible though.
> >
> > Wei.
>
> Hi Wei,
> the comment is correct, this domctl is for ARM only. If you check the
> code in xc_domain.c for the function, you will find this:
>
> #if defined (__i386__) || defined (__x86_64__)
> /*
>  * The x86 architecture provides cache coherency guarantees which
prevent
>  * the need for this hypercall.  Avoid the overhead of making a
hypercall
>  * just for Xen to return -ENOSYS.
>  */
> errno = ENOSYS;
> return -1;
> #else
>
> I guess I could move this comment to xenctrl.h to avoid confusions like
this.
>

Maybe it is just me: I read this comment differently. It suggests only
ARM code can call this function. In reality x86 can call it too, but it
has no effect.

I would suggest either just drop the comment or make clear it only has
effect on ARM.


Well, yes, only ARM could _should_ call this function. The comment I think
is important to tell the user don't expect it to do anything on x86.
Doesn't mean they can't call it though - if that was the case it would be
wrapped in an ifdef like all the other architecture specific bits in the
header. I would think that's pretty straight forward. No objection to
clarifing the comment though if it helps.

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

Re: [Xen-devel] [PATCH v15] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other.

[Oleksandr Andrushchenko]

thank you for comments, please find answers below

Can we please switch to v16 discussion as v15 vs v16 is
a big change?

On 01/27/2017 05:14 PM, Konrad Rzeszutek Wilk wrote:

On Thu, Jan 26, 2017 at 12:02:49PM +0200, Oleksandr Andrushchenko wrote:

Hi, Konrad!

First of all thank you very much for the valuable comments

and your time!

The number of changes (mostly in description) is going to

be huge, so do you think I can publish something like

"RFC v16" so we can discuss the updated patch?

RFC sadly means folks are going to mostly ignore it.
I would prefer you did not use RFC at this stage but just
did v16.
..snip..

sure

+ * Example for the frontend running in domain 5, instance of the driver
+ * in the front is 0 (single or first PV driver), device id 2,
+ * first stream (0):
+ * /local/domain//device/vsnd//
+ * device//stream//type = "p"
+ * /local/domain/5/device/vsnd/0/device/2/stream/0/type = "p"

Why do you need 'device' ?

just for clarity: the hierarchy of the sound driver would
be that a device may have multiple different streams.

And it just occured to me that you could also imply that
each device has an stream without the 'stream' in it.

So

/local/domain/5/device/vsnd/0/2/0/type = "p"

And the format is:
/local/domain//device/vsnd///

ok, so we'll end up with something like:

- Backend 
---


/local/domain/0/backend/vsnd/1/0/frontend-id = "1"
/local/domain/0/backend/vsnd/1/0/frontend = "/local/domain/1/device/vsnd/0"
/local/domain/0/backend/vsnd/1/0/state = "4"
/local/domain/0/backend/vsnd/1/0/versions = "1,2"

- Card 

/local/domain/1/device/vsnd/0/version = "1"
/local/domain/1/device/vsnd/0/short-name = "Card short name"
/local/domain/1/device/vsnd/0/long-name = "Card long name"
/local/domain/1/device/vsnd/0/sample-rates = "8000,32000,44100,48000,96000"
/local/domain/1/device/vsnd/0/sample-formats = "s8,u8,s16_le,s16_be"
/local/domain/1/device/vsnd/0/buffer-size = "262144"

- PCM device 0 

/local/domain/1/device/vsnd/0/0/name = "General analog"
/local/domain/1/device/vsnd/0/0/channels-max = "5"

- Stream 0, playback 



/local/domain/1/device/vsnd/0/0/0/type = "p"
/local/domain/1/device/vsnd/0/0/0/sample-formats = "s8,u8"
/local/domain/1/device/vsnd/0/0/0/unique-id = "0"
/local/domain/1/device/vsnd/0/0/0/ring-ref = "386"
/local/domain/1/device/vsnd/0/0/0/event-channel = "15"

--- PCM device 3 



/local/domain/1/device/vsnd/0/3/name = "HDMI-0"
/local/domain/1/device/vsnd/0/3/sample-rates = "8000,32000,44100"

-- Stream 0, capture 



/local/domain/1/device/vsnd/0/3/0/type = "c"
/local/domain/1/device/vsnd/0/3/0/unique-id = "2"
/local/domain/1/device/vsnd/0/3/0/ring-ref = "387"
/local/domain/1/device/vsnd/0/3/0/event-channel = "151"

Is this what you would like to see?
IMO, all these values do not help understanding what it is, e.g.
this is equal to me if we have

/local/domain/1/device/vbd/51712/queue-0/ring-ref = "8"
/local/domain/1/device/vbd/51712/queue-0/event-channel = "3"
/local/domain/1/device/vbd/51712/queue-1 = ""
/local/domain/1/device/vbd/51712/queue-1/ring-ref = "9"

and then decided to go with

/local/domain/1/device/vbd/51712/0/ring-ref = "8"
/local/domain/1/device/vbd/51712/0/event-channel = "3"
/local/domain/1/device/vbd/51712/1/ring-ref = "9"

Can one easily tell what 0 or 1 after "51712/" is?

So, what is the final decision then?


Though I have a little of trouble with the 'instance of the
driver'. Are you suggesting you would have multiple
PV drivers of 'vsnd'? Can't the multiple device ids fulfill this?

it is possible, but the main use-case will have a single
PV driver with multiple PCM devices/streams



So, from readability POV I would still have "device" in place
 From xenstore documentation: "Data should generally be
human-readable for ease of management and debugging "
I assume this also applies to the structure as well

Could not this be:

/local/domain/5/device/vsnd/0/2/stream/0/type = "p" ?

then one has to know that "2" stands for device.
see above, I would keep "device" here



+ *
+ *--- PCM settings 
+ *
+ * Every virtualized sound frontend has set of devices and streams, each

frontend or backend?

I would think backend since this is still the backend section?

you are right, moved to frontend's section

+ * is individually configured. Part of the PCM configuration can be defined at
+ * higher level and be fully or partially re-used by the underlying layers.
+ * These configuration values are:
+ *  o number of channels (min/max)
+ *  o supported sample rates
+ *  o supported sample formats.
+ * E.g. one can define these values for the 

[Xen-devel] altp2m: unexpected behavior

[Matt Leinhos]

Hello,

In developing against the altp2m API, I've encountered something I
wasn't expecting.

Here's the scenario:

1. Create a new altp2m memory view. Assume we get view ID 1.
2. Change some MFN permissions in view 1.
3. Destroy view 1.
4. Create another altp2m view. Get view ID 1 again.


Now, I was expecting that by destroying the view in step 3, all the MFNs
in that view would revert back to XENMEM_access_default. However, after
completing step 4, I still encounter #VEs based on the permissions I set
in step 2.

Is this a deliberate design decision?

Thanks,
Matt

-- 
Matt Leinhos
Star Lab
https://starlab.io/

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

Re: [Xen-devel] [PATCH] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

[Wei Liu]

On Fri, Jan 27, 2017 at 08:37:33AM -0700, Tamas K Lengyel wrote:
> On Fri, Jan 27, 2017 at 7:49 AM, Wei Liu  wrote:
> > On Thu, Jan 26, 2017 at 03:16:22PM -0700, Tamas K Lengyel wrote:
> >> When the toolstack modifies memory of a running ARM VM it may happen
> >> that the underlying memory of a current vCPU PC is changed. Without
> >> flushing the icache the vCPU may continue executing stale instructions.
> >>
> >
> > Why is this not an issue for x86? Is this because ARM handles coherency
> > differently from x86?
> >
> >> In this patch we introduce VA-based icache flushing macros. Also expose
> >> the xc_domain_cacheflush through xenctrl.h.
> >>
> >> Signed-off-by: Tamas K Lengyel 
> >> ---
> >> Cc: Ian Jackson 
> >> Cc: Wei Liu 
> >> Cc: Stefano Stabellini 
> >> Cc: Julien Grall 
> >>
> >> Note: patch has been verified to solve stale icache issues on the
> >>   HiKey platform.
> >> ---
> >>  tools/libxc/include/xenctrl.h|  6 ++
> >>  tools/libxc/xc_private.h |  3 ---
> >>  xen/arch/arm/mm.c|  1 +
> >>  xen/include/asm-arm/arm32/page.h |  3 +++
> >>  xen/include/asm-arm/arm64/page.h |  3 +++
> >>  xen/include/asm-arm/page.h   | 31 +++
> >>  6 files changed, 44 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> >> index 63c616ff6a..cb80a2b07c 100644
> >> --- a/tools/libxc/include/xenctrl.h
> >> +++ b/tools/libxc/include/xenctrl.h
> >> @@ -2720,6 +2720,12 @@ int xc_livepatch_revert(xc_interface *xch, char 
> >> *name, uint32_t timeout);
> >>  int xc_livepatch_unload(xc_interface *xch, char *name, uint32_t timeout);
> >>  int xc_livepatch_replace(xc_interface *xch, char *name, uint32_t timeout);
> >>
> >> +/*
> >> + * ARM only. Ensure cache coherency after memory modifications.
> >> + */
> >
> > The existing code doesn't suggest this is ARM only. This function is
> > used in xc_dom_unmap_one etc. This comment looks wrong.
> >
> > I don't object to making this function externally visible though.
> >
> > Wei.
> 
> Hi Wei,
> the comment is correct, this domctl is for ARM only. If you check the
> code in xc_domain.c for the function, you will find this:
> 
> #if defined (__i386__) || defined (__x86_64__)
> /*
>  * The x86 architecture provides cache coherency guarantees which prevent
>  * the need for this hypercall.  Avoid the overhead of making a hypercall
>  * just for Xen to return -ENOSYS.
>  */
> errno = ENOSYS;
> return -1;
> #else
> 
> I guess I could move this comment to xenctrl.h to avoid confusions like this.
> 

Maybe it is just me: I read this comment differently. It suggests only
ARM code can call this function. In reality x86 can call it too, but it
has no effect.

I would suggest either just drop the comment or make clear it only has
effect on ARM.

Wei.

> Cheers,
> Tamas

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

Re: [Xen-devel] [PATCH v2 6/9] xen/pvh: Initialize grant table for PVH guests

[Juergen Gross]

On 26/01/17 20:41, Boris Ostrovsky wrote:
> Like PV guests, PVH does not have PCI devices and therefore cannot
> use MMIO space to store grants. Instead it balloons out memory and
> keeps grants there.
> 
> Signed-off-by: Boris Ostrovsky 

Reviewed-by: Juergen Gross 


Juergen


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

Re: [Xen-devel] [PATCH v2 9/9] xen/pvh: Use Xen's emergency_restart op for PVH guests

[Juergen Gross]

On 26/01/17 20:41, Boris Ostrovsky wrote:
> Using native_machine_emergency_restart (called during reboot) will
> lead PVH guests to machine_real_restart()  where we try to use
> real_mode_header which is not initialized.
> 
> Signed-off-by: Boris Ostrovsky 

Reviewed-by: Juergen Gross 


Juergen


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

Re: [Xen-devel] [PATCH] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

[Tamas K Lengyel]

On Fri, Jan 27, 2017 at 7:49 AM, Wei Liu  wrote:
> On Thu, Jan 26, 2017 at 03:16:22PM -0700, Tamas K Lengyel wrote:
>> When the toolstack modifies memory of a running ARM VM it may happen
>> that the underlying memory of a current vCPU PC is changed. Without
>> flushing the icache the vCPU may continue executing stale instructions.
>>
>
> Why is this not an issue for x86? Is this because ARM handles coherency
> differently from x86?
>
>> In this patch we introduce VA-based icache flushing macros. Also expose
>> the xc_domain_cacheflush through xenctrl.h.
>>
>> Signed-off-by: Tamas K Lengyel 
>> ---
>> Cc: Ian Jackson 
>> Cc: Wei Liu 
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>>
>> Note: patch has been verified to solve stale icache issues on the
>>   HiKey platform.
>> ---
>>  tools/libxc/include/xenctrl.h|  6 ++
>>  tools/libxc/xc_private.h |  3 ---
>>  xen/arch/arm/mm.c|  1 +
>>  xen/include/asm-arm/arm32/page.h |  3 +++
>>  xen/include/asm-arm/arm64/page.h |  3 +++
>>  xen/include/asm-arm/page.h   | 31 +++
>>  6 files changed, 44 insertions(+), 3 deletions(-)
>>
>> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
>> index 63c616ff6a..cb80a2b07c 100644
>> --- a/tools/libxc/include/xenctrl.h
>> +++ b/tools/libxc/include/xenctrl.h
>> @@ -2720,6 +2720,12 @@ int xc_livepatch_revert(xc_interface *xch, char 
>> *name, uint32_t timeout);
>>  int xc_livepatch_unload(xc_interface *xch, char *name, uint32_t timeout);
>>  int xc_livepatch_replace(xc_interface *xch, char *name, uint32_t timeout);
>>
>> +/*
>> + * ARM only. Ensure cache coherency after memory modifications.
>> + */
>
> The existing code doesn't suggest this is ARM only. This function is
> used in xc_dom_unmap_one etc. This comment looks wrong.
>
> I don't object to making this function externally visible though.
>
> Wei.

Hi Wei,
the comment is correct, this domctl is for ARM only. If you check the
code in xc_domain.c for the function, you will find this:

#if defined (__i386__) || defined (__x86_64__)
/*
 * The x86 architecture provides cache coherency guarantees which prevent
 * the need for this hypercall.  Avoid the overhead of making a hypercall
 * just for Xen to return -ENOSYS.
 */
errno = ENOSYS;
return -1;
#else

I guess I could move this comment to xenctrl.h to avoid confusions like this.

Cheers,
Tamas

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

Re: [Xen-devel] [PATCH v3] x86/ept: Allow write-combining on !mfn_valid() MMIO mappings again

[Konrad Rzeszutek Wilk]

. snip ..
> > Signed-off-by: David Woodhouse 
> 
> Reviewed-by: Jan Beulich 
> 
> But before committing I'd prefer to have a VMX maintainer ack
> too.

Who is gone until Feb yth (Spring festival in China).

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

Re: [Xen-devel] [PATCH v2 8/9] xen/pvh: Enable CPU hotplug

[Juergen Gross]

On 26/01/17 20:41, Boris Ostrovsky wrote:
> PVH guests don't (yet) receive ACPI hotplug interrupts and therefore
> need to monitor xenstore for CPU hotplug event.
> 
> Signed-off-by: Boris Ostrovsky 

Reviewed-by: Juergen Gross 


Juergen

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 104681
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
104681
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 104681
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 104681
 test-amd64-i386-qemuu-rhel6hvm-intel  9 redhat-install   fail REGR. vs. 104681
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 104681
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 104681
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 104681
 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
104681
 test-amd64-i386-qemut-rhel6hvm-intel  9 redhat-install   fail REGR. vs. 104681
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 104681
 test-amd64-i386-qemut-rhel6hvm-amd  9 redhat-install fail REGR. vs. 104681
 test-amd64-i386-qemuu-rhel6hvm-amd  9 redhat-install fail REGR. vs. 104681
 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 104681
 test-amd64-i386-xl-qemut-winxpsp3  9 windows-install fail REGR. vs. 104681
 test-amd64-i386-xl-qemuu-winxpsp3  9 windows-install fail REGR. vs. 104681
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 
104681
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 
104681
 test-amd64-i386-xl-qemuu-win7-amd64  9 windows-install   fail REGR. vs. 104681
 test-amd64-i386-xl-qemut-win7-amd64  9 windows-install   fail REGR. vs. 104681

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 104681
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 104681
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 104681
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 104681
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 104681
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 104681

Tests which did not succeed, but are not blocking:
 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  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-check 

Re: [Xen-devel] [PATCH RESEND v5 21/24] tools: L2 CAT: support get HW info for L2 CAT.

[Wei Liu]

On Thu, Jan 19, 2017 at 02:01:23PM +0800, Yi Sun wrote:
> This patch implements xl/xc changes to support get HW info
> for L2 CAT.
> 
> 'xl psr-hwinfo' is updated to show both L3 CAT and L2 CAT
> info.
> 
> Example(on machine which only supports L2 CAT):
> Cache Monitoring Technology (CMT):
> Enabled : 0
> Cache Allocation Technology (CAT): L2
> Socket ID   : 0
> Maximum COS : 3
> CBM length  : 8
> Default CBM : 0xff
> 
> Signed-off-by: He Chen 
> Signed-off-by: Yi Sun 

Acked-by: Wei Liu 

Only one nit below.
[...]
> -int xc_psr_cat_get_l3_info(xc_interface *xch, uint32_t socket,
> -   uint32_t *cos_max, uint32_t *cbm_len,
> -   bool *cdp_enabled)
> +int xc_psr_cat_get_info(xc_interface *xch, uint32_t socket, unsigned int lvl,
> +uint32_t *cos_max, uint32_t *cbm_len, bool 
> *cdp_enabled)
>  {
> -int rc;
> +int rc = -1;
>  DECLARE_SYSCTL;
>  
>  sysctl.cmd = XEN_SYSCTL_psr_cat_op;
> -sysctl.u.psr_cat_op.cmd = XEN_SYSCTL_PSR_CAT_get_l3_info;
>  sysctl.u.psr_cat_op.target = socket;
>  
> -rc = xc_sysctl(xch, );
> -if ( !rc )
> -{
> -*cos_max = sysctl.u.psr_cat_op.u.l3_info.cos_max;
> -*cbm_len = sysctl.u.psr_cat_op.u.l3_info.cbm_len;
> -*cdp_enabled = sysctl.u.psr_cat_op.u.l3_info.flags &
> -   XEN_SYSCTL_PSR_CAT_L3_CDP;
> +switch ( lvl ) {

Please put '{' on a new line.

Wei.

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

Re: [Xen-devel] [PATCH RESEND v5 24/24] docs: add L2 CAT description in docs.

[Wei Liu]

On Thu, Jan 19, 2017 at 02:01:26PM +0800, Yi Sun wrote:
> This patch adds L2 CAT description in related documents.
> 
> Signed-off-by: He Chen 
> Signed-off-by: Yi Sun 

Acked-by: Wei Liu 

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