[Xen-devel] [xen-4.8-testing test] 107184: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops 3 host-install(3)broken REGR. vs. 107019
 test-armhf-armhf-xl-credit2  16 guest-start.2fail REGR. vs. 107019

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 107019
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 107019

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-xtf-amd64-amd64-11 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-21 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-xtf-amd64-amd64-41 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-31 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-xtf-amd64-amd64-51 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-rtds  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
 test-amd64-i386-libvirt  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-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
 build-arm64-pvops 5 kernel-build 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
 

[Xen-devel] [xen-4.7-testing test] 107185: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pair   3 host-install/src_host(3) broken REGR. vs. 107021
 test-armhf-armhf-xl-credit2   3 host-install(3)broken REGR. vs. 107021

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

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
 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-xl-pvh-amd  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-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-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-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
 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-armhf-armhf-libvirt 12 migrate-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-xsm 12 migrate-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-amd64-xl-qemut-win7-amd64 16 guest-stop fail 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
 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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  ada9e109d7539ec93e1b554805721110d2807521
baseline version:
 xen  47ba140217118b2b5153f3529d548bc5bdc98ca5

Last test of basis   107021  2017-03-31 07:12:01 Z4 days
Testing same since   107185  2017-04-04 13:12:45 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Jan Beulich 
  Juergen Gross 

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

Re: [Xen-devel] [PATCH v4] displif: add ABI for para-virtual display

[Oleksandr Andrushchenko]

On 04/04/2017 11:07 PM, Konrad Rzeszutek Wilk wrote:

.snip..

+ *- Protocol version --
+ *
+ * version
+ *  Values: 
+ *
+ *  Protocol version, chosen among the ones supported by the backend.
+ *

..snip..

+#define XENDISPL_FIELD_BE_VERSIONS"versions"
+#define XENDISPL_FIELD_FE_VERSION "version"

I couldn't find in spec what version this actually is. As in I would
assume it is version 1, but that is not enumerated.

We have:
+ * versions
+ *  Values: 
+ *
+ *  List of XENDISPL_LIST_SEPARATOR separated protocol versions 
supported

+ *  by the backend. For example "1,2,3".
which defines the format of the versions enumeration.

Perhaps it may be good to include in the Backend section that the
'versions' will contain the value 1.

I will probably put something like
#define XENDISPL_PROTOCOL_VERSION "1"
on top, which will particularly used by the backend too:
on top, because this value is not only for backend, but
overall protocol identificator

  And that future changes would
update it?

Thus, once we need to change it we are all set



I will release v5 today with the change above and your comments fixed

Thank you,
Oleksandr

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

[Xen-devel] [xen-4.6-testing test] 107186: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-amd64  3 host-install(3) broken REGR. vs. 107151
 test-xtf-amd64-amd64-5   20 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 107151
 test-xtf-amd64-amd64-5 33 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 107151
 test-xtf-amd64-amd64-5   44 xtf/test-hvm64-invlpg~shadow fail REGR. vs. 107151
 test-armhf-armhf-xl-arndale   6 xen-boot fail REGR. vs. 107151

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

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-4   64 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-3   64 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-1   64 xtf/test-pv32pae-xsa-194 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-i386-libvirt  12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-5   64 xtf/test-pv32pae-xsa-194 fail   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
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-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-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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 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-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-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-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-xtf-amd64-amd64-2   64 xtf/test-pv32pae-xsa-194 fail   never pass

version targeted for testing:
 xen  bb92bb77bc98d44cc8e4d8e6d61ae82517455f41
baseline version:
 xen  f96efeb0c6b4f499194571ef6d767534ba851c6a

Last test of basis   107151  2017-04-03 09:51:21 Z1 days
Testing same since   107186  2017-04-04 13:12:45 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Jan Beulich 
  Juergen Gross 

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] [linux-linus test] 107179: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-libvirt 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu 11 guest-start  fail REGR. vs. 59254
 test-amd64-amd64-pair 15 debian-install/dst_host fail in 107169 REGR. vs. 59254

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pair  3 host-install/src_host(3) broken pass in 107169
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken pass in 
107169
 test-amd64-amd64-libvirt  3 host-install(3)  broken pass in 107169
 test-amd64-amd64-pair 4 host-install/dst_host(4) broken pass in 107169
 test-amd64-amd64-xl-pvh-amd   3 host-install(3)  broken pass in 107169
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 107169 
pass in 107179
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 20 leak-check/check fail in 
107169 pass in 107179
 test-amd64-amd64-xl-qemuu-ovmf-amd64 20 leak-check/check fail in 107169 pass 
in 107179

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-amd64-i386-xl-raw   10 guest-start fail baseline untested
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-armhf-armhf-libvirt-raw  9 debian-di-install   fail baseline untested
 build-arm64-xsm   5 xen-build fail in 107169 baseline untested
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 15 
guest-start/debianhvm.repeat fail in 107169 baseline untested
 build-arm64   5 xen-build fail in 107169 baseline untested
 test-amd64-i386-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
 test-amd64-amd64-xl-qemuu-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 in 107169 n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked in 107169 n/a
 build-arm64-libvirt   1 build-check(1)   blocked in 107169 n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1) blocked in 107169 n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked in 107169 n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked in 107169 n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked in 107169 n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)  blocked in 107169 n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked in 107169 n/a
 test-amd64-amd64-libvirt12 migrate-support-check fail in 107169 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-arm64-arm64-libvirt 11 guest-start  fail   never pass
 test-arm64-arm64-xl-xsm  11 guest-start  fail   never pass
 test-arm64-arm64-xl-multivcpu 11 guest-start  fail  never pass
 test-arm64-arm64-xl  11 guest-start  fail   never pass
 test-arm64-arm64-xl-credit2  11 guest-start  fail   never pass
 test-arm64-arm64-xl-rtds 11 guest-start  fail   never pass
 test-arm64-arm64-libvirt-xsm 11 guest-start  fail   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-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-libvirt  12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2  9 debian-di-installfail never pass

version targeted for testing:
 linux08e4e0d0456d0ca8427b2d1ddffa30f1c3e774d7
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis

[Xen-devel] [xen-4.5-testing test] 107183: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 
106872
 test-amd64-amd64-xl-multivcpu  3 host-install(3)   broken REGR. vs. 106872
 test-amd64-i386-qemut-rhel6hvm-amd  3 host-install(3)  broken REGR. vs. 106872
 test-amd64-amd64-migrupgrade 3 host-install/src_host(3) broken REGR. vs. 106872
 test-amd64-amd64-xl-credit2   3 host-install(3)broken REGR. vs. 106872
 test-amd64-i386-freebsd10-amd64  3 host-install(3) broken REGR. vs. 106872
 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 
106872
 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 106872
 test-amd64-i386-qemuu-rhel6hvm-intel 11 guest-start/redhat.repeat fail REGR. 
vs. 106872

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 106840
 test-armhf-armhf-xl-rtds 11 guest-start  fail  like 106840
 test-amd64-amd64-xl-rtds  6 xen-boot fail  like 106872
 test-xtf-amd64-amd64-2   54 leak-check/check fail  like 106872
 test-xtf-amd64-amd64-3   54 leak-check/check fail  like 106872
 test-xtf-amd64-amd64-4   54 leak-check/check fail  like 106872
 test-xtf-amd64-amd64-1   54 leak-check/check fail  like 106872
 test-xtf-amd64-amd64-5   54 leak-check/check fail  like 106872
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 106872
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 106872
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106872
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 106872

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-2   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2 31 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2 37 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2   41 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4 31 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4 37 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1 31 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   41 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1 37 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   41 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-xtf-amd64-amd64-5   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5 31 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5 37 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5   41 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-2   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-3   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-4   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-1   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-5   53 xtf/test-hvm64-xsa-195   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-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 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-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-vhd  10 guest-start  fail   never pass
 

Re: [Xen-devel] [PATCH v10 03/25] x86: refactor psr: implement main data structures.

[Yi Sun]

On 17-04-03 09:50:34, Jan Beulich wrote:
> >>> On 01.04.17 at 15:53,  wrote:
> 
> I was about to ack this, but there are a few more things which bother
> me.
> 
Do you mean ack to this patch 3 or whole patch set? Thanks!

> > ---
> > v10:
> > - remove initialization for 'PSR_SOCKET_L3_CAT'.
> >   (suggested by Jan Beulich)
> > - rename 'feat_ops' to 'feat_props'.
> >   (suggested by Jan Beulich)
> > - move 'cbm_len' to 'feat_props' because it is feature independent so 
> > far.
> >   (suggested by Jan Beulich)
> > - move 'cos_max' to 'feat_props' because it is feature independent.
> >   (suggested by Jan Beulich)
> > - move 'cos_num' to 'feat_props' because it is feature independent.
> >   (suggested by Jan Beulich)
> > - remove union 'info' and struct 'psr_cat_hw_info'.
> > - remove 'get_cos_max' from 'feat_props'.
> >   (suggested by Jan Beulich)
> > - remove 'feat_mask' from 'psr_socket_info' because we can use 
> > 'features[]'
> >   to check if any feature is initialized.
> >   (suggested by Jan Beulich)
> > - move 'ref_lock' above 'cos_ref'.
> >   (suggested by Jan Beulich)
> 
> The movement done is fine for the moment, but it would have been
> even better if you had moved it ahead of the other array too.
> 
Got it.

> > +enum psr_feat_type {
> > +PSR_SOCKET_L3_CAT,
> > +PSR_SOCKET_L3_CDP,
> > +PSR_SOCKET_L2_CAT,
> > +PSR_SOCKET_MAX_FEAT,
> > +};
> 
> It's not really logical to have the first three here - they should have
> been added by their respective patches. Which gets me back to
> the question of the usefulness of a patch like this one: Without the
> following patches, everything being added here is unused. Iirc the
> original version of this patch was quite a bit larger, better justifying
> to break out all of this. The size it has shrunk to by now is a pretty
> good indication that it should have been folded altogether.
> 
Ok, I will add item one by one in related feature's patch. But can I keep
this patch 3? This patch outlines the infrastructure and I demonstrated how
I analyze the data structures in commit message. If I split these data
structures into pieces and implement them into different patches, I am
afraid to lose the completeness.

> Also I think we've had the discussion about the difference between
> "max" and "num" already: The former normally indicates an inclusive
> upper bound, while the latter would usually be an exclusive one.
> Clearly the above naming doesn't match up with this.
> 
Ok, may change it to 'PSR_SOCKET_FEAT_NUM'.

> > +/*
> > + * This structure represents one feature.
> > + * feat_props  - Feature properties, including operation callback functions
> > + and feature common values.
> > + * cos_reg_val - Array to store the values of COS registers. One entry 
> > stores
> > + *   the value of one COS register.
> > + *   For L3 CAT and L2 CAT, one entry corresponds to one 
> > COS_ID.
> > + *   For CDP, two entries correspond to one COS_ID. E.g.
> > + *   COS_ID=0 corresponds to cos_reg_val[0] (Data) and
> > + *   cos_reg_val[1] (Code).
> > + */
> > +struct feat_node {
> > +/*
> > + * This structure defines feature operation callback functions. Every
> > + * feature enabled MUST implement such callback functions and register
> > + * them to props.
> > + *
> > + * Feature specific behaviors will be encapsulated into these callback
> > + * functions. Then, the main flows will not be changed when introducing
> > + * a new feature.
> > + *
> > + * Feature independent HW info and common values are also defined in 
> > it.
> > + */
> > +const struct feat_props {
> > +/*
> > + * cos_num, cos_max and cbm_len are common values for all features
> > + * so far.
> > + * cos_num - COS registers number that feature uses for one COS ID.
> > + *   It is defined in SDM.
> > + * cos_max - The max COS registers number got through CPUID.
> > + * cbm_len - The length of CBM got through CPUID.
> > + */
> > +unsigned int cos_num;
> > +unsigned int cos_max;
> > +unsigned int cbm_len;
> > +} *props;
> 
> Let's think the data arrangement changes done so far a little further:
> Why do we need this pointer per-node (i.e. once per socket)? Now
> that we have a well established order of features used to index
> struct psr_socket_info's features[], why can't the same indexing be
> used to obtain the props pointer from a static (single instance) array
> of props pointers?
> 
Hmm, yes, we can declare a static standalone array of props pointers for all
features and all sockets. It does not belong to 'feat_node' or 'socket_info'.

> Otoh I'm not sure you really meant to move all three data members
> into there, if you still have reason to believe that different 

Re: [Xen-devel] [PATCH v11 5/6] VT-d: introduce update_irte to update irte safely

[Chao Gao]

On Fri, Mar 31, 2017 at 04:01:31AM -0600, Jan Beulich wrote:
 On 29.03.17 at 07:11,  wrote:
>> +static void update_irte(struct iremap_entry *entry,
>> +const struct iremap_entry *new_ire,
>> +bool atomic)
>> +{
>> +if ( cpu_has_cx16 )
>> +{
>> +__uint128_t ret;
>> +struct iremap_entry old_ire;
>> +
>> +old_ire = *entry;
>> +ret = cmpxchg16b(entry, _ire, new_ire);
>> +
>> +/*
>> + * In the above, we use cmpxchg16 to atomically update the 128-bit
>> + * IRTE, and the hardware cannot update the IRTE behind us, so
>> + * the return value of cmpxchg16 should be the same as old_ire.
>> + * This ASSERT validate it.
>> + */
>> +ASSERT(ret == old_ire.val);
>> +}
>> +else
>> +{
>> +/*
>> + * The following code will update irte atomically if possible.
>
>There's nothing atomic below - between the compares and stores
>the value in the table could change. Please don't make false
>promises in comments.

Ok. I agree. Then do you think the parameter 'atomic' of this function is 
proper?

I think this atomic means the caller wants this update to be presented to VT-d 
hardware
as a atomic update. That's to say, no intermediate, invalid IRTE can be seen by 
hardware.

>
>> + * If the caller requests a atomic update but we can't meet it, 
>> + * a bug will be raised.
>> + */
>> +if ( entry->lo == new_ire->lo )
>> +entry->hi = new_ire->hi;
>> +else if ( entry->hi == new_ire->hi )
>> +entry->lo = new_ire->lo;
>
>Best effort would still call for use of write_atomic() instead of both
>of the assignments above.

Will fix. Your concern is compiler would wrongly optimize the assignments?

>
>> @@ -353,7 +409,11 @@ static int ioapic_rte_to_remap_entry(struct iommu 
>> *iommu,
>>  remap_rte->format = 1;/* indicate remap format */
>>  }
>>  
>> -*iremap_entry = new_ire;
>> +if ( init )
>> +update_irte_non_atomic(iremap_entry, _ire);
>> +else
>> +update_irte_atomic(iremap_entry, _ire);
>
>Seems like you'd better call update_irte() here directly, instead of
>having this if/else. Which puts under question the usefulness of the
>two wrappers.

agree. Will remove the two wrappers.

>
>> @@ -639,7 +702,14 @@ static int msi_msg_to_remap_entry(
>>  remap_rte->address_hi = 0;
>>  remap_rte->data = index - i;
>>  
>> -*iremap_entry = new_ire;
>> +if ( msi_desc->remap_entry_initialized )
>> +update_irte_atomic(iremap_entry, _ire);
>> +else
>> +{
>> +update_irte_non_atomic(iremap_entry, _ire);
>> +msi_desc->remap_entry_initialized = true;
>> +}
>
>Same here.
>
>I also wonder whether you really need the new flag: The function
>knows whether it's initializing the IRTE for the first time, as it
>allocates a table index just like ioapic_rte_to_remap_entry() does
>(where you get away without a new flag).

For multi-vector msi case, I don't have a clean solution to get away this flag.
The problem here is that it allocates several table indexes for multi-vector msi
and only initialize the first one. For others, it isn't aware whether the IRTE
is initialized or not.

Thank
Chao

>
>Jan

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

Re: [Xen-devel] Can't read bios file

[Duncan X. Simpson]

Does anybody have advice as to what to do? Am I in the wrong place? Am I
missing something obvious?

On Tue, Apr 4, 2017 at 11:03 AM Duncan X. Simpson 
wrote:

> Update: I still have the same problem when I compile from git master.
>
> On Mon, Apr 3, 2017 at 7:05 PM Duncan X. Simpson 
> wrote:
>
> I apologize, I should probably include this information:
> OS: Arch Linux
> xl info:
> host   : k7dxs-laptop-r500
> release: 4.10.6-1-ARCH
> version: #1 SMP PREEMPT Mon Mar 27 08:28:22 CEST 2017
> machine: x86_64
> nr_cpus: 2
> max_cpu_id : 3
> nr_nodes   : 1
> cores_per_socket   : 2
> threads_per_core   : 1
> cpu_mhz: 2394
> hw_caps:
> b7ebfbff:0408e3fd:20100800:0001::::
> virt_caps  : hvm
> total_memory   : 1944
> free_memory: 517
> sharing_freed_memory   : 0
> sharing_used_memory: 0
> outstanding_claims : 0
> free_cpus  : 0
> xen_major  : 4
> xen_minor  : 8
> xen_extra  : .0
> xen_version: 4.8.0
> xen_caps   : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
> hvm-3.0-x86_32p hvm-3.0-x86_64
> xen_scheduler  : credit
> xen_pagesize   : 4096
> platform_params: virt_start=0x8000
> xen_changeset  :
> xen_commandline: /boot/xen-4.8.0.gz xsave=1
> cc_compiler: gcc (GCC) 6.3.1 20170306
> cc_compile_by  : duncan
> cc_compile_domain  :
> cc_compile_date: Tue Mar 28 15:11:08 MST 2017
> build_id   : 8b7628e151ee56a26b2f83b21160ee1168263b64
> xend_config_format : 4
>
>
> On Mon, Apr 3, 2017 at 6:25 PM Duncan X. Simpson 
> wrote:
>
> I'm trying to set up an HVM CentOS guest, and I've run into a problem. I
> originally tried posting it on Stack Exchange (
> https://superuser.com/questions/1193771/failed-to-read-bios-file-no-such-file-or-directory),
> but it is not documented anywhere on the Internet that Google can see and I
> have gotten no response. I regained interest in it today and used strace to
> determine what bios file it was looking for, and found it was looking for a
> file called 'yes' in the current directory. This is what made me decide it
> was most likely a bug and post it here rather in xen-users. My
> configuration is as listed on the Stack Exchange question and does not
> contain the word yes anywhere in it. What should I do next?
> --
>
> Duncan X. Simpson, K7DXS
>
> --
>
> Duncan X. Simpson, K7DXS
>
> --
>
> Duncan X. Simpson, K7DXS
>
-- 

Duncan X. Simpson, K7DXS
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 04/27] ARM: GICv3 ITS: allocate device and collection table

[Stefano Stabellini]

On Mon, 3 Apr 2017, Andre Przywara wrote:
> Each ITS maps a pair of a DeviceID (for instance derived from a PCI
> b/d/f triplet) and an EventID (the MSI payload or interrupt ID) to a
> pair of LPI number and collection ID, which points to the target CPU.
> This mapping is stored in the device and collection tables, which software
> has to provide for the ITS to use.
> Allocate the required memory and hand it to the ITS.
> The maximum number of devices can be limited to a compile-time variable.
> 
> Signed-off-by: Andre Przywara 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/gic-v3-its.c| 132 
> +++
>  xen/include/asm-arm/gic_v3_its.h |  32 ++
>  2 files changed, 164 insertions(+)
> 
> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> index 58c6ac0..00a1f7b 100644
> --- a/xen/arch/arm/gic-v3-its.c
> +++ b/xen/arch/arm/gic-v3-its.c
> @@ -35,6 +35,105 @@ bool gicv3_its_host_has_its(void)
>  return !list_empty(_its_list);
>  }
>  
> +#define BASER_ATTR_MASK   \
> +((0x3UL << GITS_BASER_SHAREABILITY_SHIFT)   | \
> + (0x7UL << GITS_BASER_OUTER_CACHEABILITY_SHIFT) | \
> + (0x7UL << GITS_BASER_INNER_CACHEABILITY_SHIFT))
> +#define BASER_RO_MASK   (GENMASK_ULL(58, 56) | GENMASK_ULL(52, 48))
> +
> +/* Check that the physical address can be encoded in the PROPBASER register. 
> */
> +static bool check_baser_phys_addr(void *vaddr, unsigned int page_bits)
> +{
> +paddr_t paddr = virt_to_maddr(vaddr);
> +
> +return (!(paddr & ~GENMASK_ULL(page_bits < 16 ? 47 : 51, page_bits)));
> +}
> +
> +static uint64_t encode_baser_phys_addr(paddr_t addr, unsigned int page_bits)
> +{
> +uint64_t ret = addr & GENMASK_ULL(47, page_bits);
> +
> +if ( page_bits < 16 )
> +return ret;
> +
> +/* For 64K pages address bits 51-48 are encoded in bits 15-12. */
> +return ret | ((addr & GENMASK_ULL(51, 48)) >> (48 - 12));
> +}
> +
> +/* The ITS BASE registers work with page sizes of 4K, 16K or 64K. */
> +#define BASER_PAGE_BITS(sz) ((sz) * 2 + 12)
> +
> +static int its_map_baser(void __iomem *basereg, uint64_t regc,
> + unsigned int nr_items)
> +{
> +uint64_t attr, reg;
> +unsigned int entry_size = GITS_BASER_ENTRY_SIZE(regc);
> +unsigned int pagesz = 2;/* try 64K pages first, then go down. */
> +unsigned int table_size;
> +void *buffer;
> +
> +attr  = GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
> +attr |= GIC_BASER_CACHE_SameAsInner << 
> GITS_BASER_OUTER_CACHEABILITY_SHIFT;
> +attr |= GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT;
> +
> +/*
> + * Setup the BASE register with the attributes that we like. Then read
> + * it back and see what sticks (page size, cacheability and shareability
> + * attributes), retrying if necessary.
> + */
> +retry:
> +table_size = ROUNDUP(nr_items * entry_size, 
> BIT(BASER_PAGE_BITS(pagesz)));
> +/* The BASE registers support at most 256 pages. */
> +table_size = min(table_size, 256U << BASER_PAGE_BITS(pagesz));
> +
> +buffer = _xzalloc(table_size, BIT(BASER_PAGE_BITS(pagesz)));
> +if ( !buffer )
> +return -ENOMEM;
> +
> +if ( !check_baser_phys_addr(buffer, BASER_PAGE_BITS(pagesz)) )
> +{
> +xfree(buffer);
> +return -ERANGE;
> +}
> +
> +reg  = attr;
> +reg |= (pagesz << GITS_BASER_PAGE_SIZE_SHIFT);
> +reg |= (table_size >> BASER_PAGE_BITS(pagesz)) - 1;
> +reg |= regc & BASER_RO_MASK;
> +reg |= GITS_VALID_BIT;
> +reg |= encode_baser_phys_addr(virt_to_maddr(buffer),
> +  BASER_PAGE_BITS(pagesz));
> +
> +writeq_relaxed(reg, basereg);
> +regc = readq_relaxed(basereg);
> +
> +/* The host didn't like our attributes, just use what it returned. */
> +if ( (regc & BASER_ATTR_MASK) != attr )
> +{
> +/* If we can't map it shareable, drop cacheability as well. */
> +if ( (regc & GITS_BASER_SHAREABILITY_MASK) == GIC_BASER_NonShareable 
> )
> +{
> +regc &= ~GITS_BASER_INNER_CACHEABILITY_MASK;
> +writeq_relaxed(regc, basereg);
> +}
> +attr = regc & BASER_ATTR_MASK;
> +}
> +if ( (regc & GITS_BASER_INNER_CACHEABILITY_MASK) <= GIC_BASER_CACHE_nC )
> +clean_and_invalidate_dcache_va_range(buffer, table_size);
> +
> +/* If the host accepted our page size, we are done. */
> +if ( ((regc >> GITS_BASER_PAGE_SIZE_SHIFT) & 0x3UL) == pagesz )
> +return 0;
> +
> +xfree(buffer);
> +
> +if ( pagesz-- > 0 )
> +goto retry;
> +
> +/* None of the page sizes was accepted, give up */
> +return -EINVAL;
> +}
> +
>  /* Allow a user to limit the number of devices. */
>  static unsigned int max_its_device_bits = 32;
>  

[Xen-devel] [xen-unstable-smoke test] 107204: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  045d5d10ee5f0066a7e71d1fe18f9c7c27d64703
baseline version:
 xen  c4bdbec00c9063736361124a3492ebceabfaed06

Last test of basis   107194  2017-04-04 16:01:54 Z0 days
Testing same since   107202  2017-04-04 21:17:38 Z0 days2 attempts


People who touched revisions under test:
  Iurii Konovalenko 
  Oleksandr Andrushchenko 
  Oleksandr Dmytryshyn 
  Oleksandr Grytsov 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=045d5d10ee5f0066a7e71d1fe18f9c7c27d64703
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
045d5d10ee5f0066a7e71d1fe18f9c7c27d64703
+ branch=xen-unstable-smoke
+ revision=045d5d10ee5f0066a7e71d1fe18f9c7c27d64703
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' x045d5d10ee5f0066a7e71d1fe18f9c7c27d64703 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : 

Re: [Xen-devel] [PATCH v4 01/27] ARM: GICv3 ITS: parse and store ITS subnodes from hardware DT

[Stefano Stabellini]

On Mon, 3 Apr 2017, Andre Przywara wrote:
> Parse the DT GIC subnodes to find every ITS MSI controller the hardware
> offers. Store that information in a list to both propagate all of them
> later to Dom0, but also to be able to iterate over all ITSes.
> This introduces an ITS Kconfig option.
> 
> Signed-off-by: Andre Przywara 
>
> ---
>  xen/arch/arm/Kconfig |  5 +++
>  xen/arch/arm/Makefile|  1 +
>  xen/arch/arm/gic-v3-its.c| 77 
> 
>  xen/arch/arm/gic-v3.c| 10 +++---
>  xen/include/asm-arm/gic_v3_its.h | 67 ++
>  5 files changed, 156 insertions(+), 4 deletions(-)
>  create mode 100644 xen/arch/arm/gic-v3-its.c
>  create mode 100644 xen/include/asm-arm/gic_v3_its.h
> 
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 43123e6..d46b98c 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -45,6 +45,11 @@ config ACPI
>  config HAS_GICV3
>   bool
>  
> +config HAS_ITS
> +bool
> +prompt "GICv3 ITS MSI controller support" if EXPERT = "y"
> +depends on HAS_GICV3
> +
>  endmenu
>  
>  menu "ARM errata workaround via the alternative framework"
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 0ce94a8..39c0a03 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -18,6 +18,7 @@ obj-$(EARLY_PRINTK) += early_printk.o
>  obj-y += gic.o
>  obj-y += gic-v2.o
>  obj-$(CONFIG_HAS_GICV3) += gic-v3.o
> +obj-$(CONFIG_HAS_ITS) += gic-v3-its.o
>  obj-y += guestcopy.o
>  obj-y += hvm.o
>  obj-y += io.o
> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> new file mode 100644
> index 000..6b02349
> --- /dev/null
> +++ b/xen/arch/arm/gic-v3-its.c
> @@ -0,0 +1,77 @@
> +/*
> + * xen/arch/arm/gic-v3-its.c
> + *
> + * ARM GICv3 Interrupt Translation Service (ITS) support
> + *
> + * Copyright (C) 2016,2017 - ARM 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; under version 2 of the License.
> + *
> + * 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 .
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * No lock here, as this list gets only populated upon boot while scanning
> + * firmware tables for all host ITSes, and only gets iterated afterwards.
> + */
> +LIST_HEAD(host_its_list);
> +
> +bool gicv3_its_host_has_its(void)
> +{
> +return !list_empty(_its_list);
> +}
> +
> +/* Scan the DT for any ITS nodes and create a list of host ITSes out of it. 
> */
> +void gicv3_its_dt_init(const struct dt_device_node *node)
> +{
> +const struct dt_device_node *its = NULL;
> +struct host_its *its_data;
> +
> +/*
> + * Check for ITS MSI subnodes. If any, add the ITS register
> + * frames to the ITS list.
> + */
> +dt_for_each_child_node(node, its)
> +{
> +uint64_t addr, size;
> +
> +if ( !dt_device_is_compatible(its, "arm,gic-v3-its") )
> +continue;
> +
> +if ( dt_device_get_address(its, 0, , ) )
> +panic("GICv3: Cannot find a valid ITS frame address");
> +
> +its_data = xzalloc(struct host_its);
> +if ( !its_data )
> +panic("GICv3: Cannot allocate memory for ITS frame");
> +
> +its_data->addr = addr;
> +its_data->size = size;
> +its_data->dt_node = its;
> +
> +printk("GICv3: Found ITS @0x%lx\n", addr);
> +
> +list_add_tail(_data->entry, _its_list);
> +}
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 695f01f..b626298 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -42,6 +42,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -1227,11 +1228,12 @@ static void __init gicv3_dt_init(void)
>   */
>  res = dt_device_get_address(node, 1 + gicv3.rdist_count,
>  , );
> -if ( res )
> -return;
> +if ( !res )
> +dt_device_get_address(node, 1 + gicv3.rdist_count + 2,
> +  , );
>  
> -dt_device_get_address(node, 1 + gicv3.rdist_count + 2,
> -  , );
> +/* Check for ITS child nodes and build the host ITS list accordingly. */
> +gicv3_its_dt_init(node);
>  }
>  
>  static int 

[Xen-devel] [PATCH v9 4/4] Introduce the pvcalls header

[Stefano Stabellini]

Define the ring and request and response structs according to the
specification. Use the new DEFINE_XEN_FLEX_RING macro.

Add the header to the C99 check.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Konrad Rzeszutek Wilk 
CC: jbeul...@suse.com
CC: konrad.w...@oracle.com
---
 xen/include/Makefile|   3 +-
 xen/include/public/io/pvcalls.h | 153 
 2 files changed, 155 insertions(+), 1 deletion(-)
 create mode 100644 xen/include/public/io/pvcalls.h

diff --git a/xen/include/Makefile b/xen/include/Makefile
index 54adca9..65a732a 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -94,10 +94,11 @@ all: headers.chk headers99.chk headers++.chk
 
 PUBLIC_HEADERS := $(filter-out public/arch-% public/dom0_ops.h, $(wildcard 
public/*.h public/*/*.h) $(public-y))
 
-PUBLIC_C99_HEADERS := public/io/9pfs.h
+PUBLIC_C99_HEADERS := public/io/9pfs.h public/io/pvcalls.h
 PUBLIC_ANSI_HEADERS := $(filter-out public/%ctl.h public/xsm/% 
public/%hvm/save.h $(PUBLIC_C99_HEADERS), $(PUBLIC_HEADERS))
 
 public/io/9pfs.h-prereq := string
+public/io/pvcalls.h-prereq := string
 
 headers.chk: $(PUBLIC_ANSI_HEADERS) Makefile
for i in $(filter %.h,$^); do \
diff --git a/xen/include/public/io/pvcalls.h b/xen/include/public/io/pvcalls.h
new file mode 100644
index 000..cb81712
--- /dev/null
+++ b/xen/include/public/io/pvcalls.h
@@ -0,0 +1,153 @@
+/*
+ * pvcalls.h -- Xen PV Calls Protocol
+ *
+ * Refer to docs/misc/pvcalls.markdown for the specification
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (C) 2017 Stefano Stabellini 
+ */
+
+#ifndef __XEN_PUBLIC_IO_PVCALLS_H__
+#define __XEN_PUBLIC_IO_PVCALLS_H__
+
+#include "../grant_table.h"
+#include "ring.h"
+
+/*
+ * See docs/misc/pvcalls.markdown in xen.git for the full specification:
+ * https://xenbits.xen.org/docs/unstable/misc/pvcalls.html
+ */
+struct pvcalls_data_intf {
+RING_IDX in_cons, in_prod, in_error;
+
+uint8_t pad1[52];
+
+RING_IDX out_cons, out_prod, out_error;
+
+uint8_t pad2[52];
+
+RING_IDX ring_order;
+grant_ref_t ref[];
+};
+DEFINE_XEN_FLEX_RING(pvcalls);
+
+#define PVCALLS_SOCKET 0
+#define PVCALLS_CONNECT1
+#define PVCALLS_RELEASE2
+#define PVCALLS_BIND   3
+#define PVCALLS_LISTEN 4
+#define PVCALLS_ACCEPT 5
+#define PVCALLS_POLL   6
+
+struct xen_pvcalls_request {
+uint32_t req_id; /* private to guest, echoed in response */
+uint32_t cmd;/* command to execute */
+union {
+struct xen_pvcalls_socket {
+uint64_t id;
+uint32_t domain;
+uint32_t type;
+uint32_t protocol;
+} socket;
+struct xen_pvcalls_connect {
+uint64_t id;
+uint8_t addr[28];
+uint32_t len;
+uint32_t flags;
+grant_ref_t ref;
+uint32_t evtchn;
+} connect;
+struct xen_pvcalls_release {
+uint64_t id;
+uint8_t reuse;
+} release;
+struct xen_pvcalls_bind {
+uint64_t id;
+uint8_t addr[28];
+uint32_t len;
+} bind;
+struct xen_pvcalls_listen {
+uint64_t id;
+uint32_t backlog;
+} listen;
+struct xen_pvcalls_accept {
+uint64_t id;
+uint64_t id_new;
+grant_ref_t ref;
+uint32_t evtchn;
+} accept;
+struct xen_pvcalls_poll {
+uint64_t id;
+} poll;
+/* dummy member to force sizeof(struct xen_pvcalls_request)
+ * to match across archs */
+struct xen_pvcalls_dummy {
+uint8_t dummy[56];
+} dummy;
+} u;
+};
+
+struct xen_pvcalls_response {
+uint32_t req_id;
+uint32_t cmd;
+int32_t ret;
+uint32_t pad;
+union 

[Xen-devel] [PATCH v9 0/4] new ring macros, 9pfs and pvcalls headers

[Stefano Stabellini]

Hi all,

this patch series introduces a set of new ring macros to support rings
in the formats specified by the Xen 9pfs transport and PV Calls
protocol. It also introduces the Xen 9pfs and PV Calls protocols
headers.


Changes in v9:
- added reviewed-bys
- code style alignments
- add comment on page granularity
- improve comments

Changes in v8:
- code style fixes in Makefile
- add back lost pvcall header file
- exit 1/ exit $$?
- exit C++ tests if $(CXX) is not available

Changes in v7:
- code style
- remove -include from prereq variable
- use only one prereq variable for both cxx and c99

Changes in v6:
- remove stray semicolons
- code style fix for return statements
- make the last element of DEFINE_XEN_FLEX_RING non a static inline
  function
- improve ring.h prereq comment
- remove mask_order
- use ring_size as parameter instead of ring_order
- fix indentation of parameters in ring.h
- improve order of parameters in ring.h
- introduce per header prereqs in xen/include/Makefile

Changes in v5:
- parenthesize uses of macro parameters in XEN_FLEX_RING_SIZE
- add grant_table.h to the list of prereqs in ring.h and remove the
  #include from ring.h
- #include grant_table.h in 9pfs.h and pvcalls.h
- remove PAGE_SHIFT definition, define XEN_PAGE_SHIFT instead
- code style fixes
- remove struct xen_9pfs_header definition
- don't add extra -include cstring to all c++ tests, only when needed
- add headers99.chk to .gitignore 

Changes in v4:
- include ../grant_table.h in ring.h
- add a comment about required declarations on top of ring.h
- add a patch to introduce a C99 headers check
- add -include string.h to the existing C++ headers check
- add 9pfs and pvcalls to the C99 headers check

Changes in v3:
- fix commit message
- add newlines after read/write_packet functions
- reorder DEFINE_XEN_FLEX_RING_AND_INTF and DEFINE_XEN_FLEX_RING

Changes in v2:
- replace __attribute__((packed)) with #pragma pack
- remove XEN_9PFS_RING_ORDER, the 9pfs ring order should be dynamic
- add editor configuration blocks
- add links to the specs


Stefano Stabellini (4):
  ring.h: introduce macros to handle monodirectional rings with multiple 
req sizes
  xen: introduce a C99 headers check
  Introduce the Xen 9pfs transport header
  Introduce the pvcalls header

 .gitignore  |   3 +-
 xen/include/Makefile|  36 ++---
 xen/include/public/io/9pfs.h|  49 +
 xen/include/public/io/pvcalls.h | 153 ++
 xen/include/public/io/ring.h| 158 
 5 files changed, 385 insertions(+), 14 deletions(-)
 create mode 100644 xen/include/public/io/9pfs.h
 create mode 100644 xen/include/public/io/pvcalls.h

Cheers,

Stefano

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

[Xen-devel] [PATCH v9 3/4] Introduce the Xen 9pfs transport header

[Stefano Stabellini]

Define the ring according to the protocol specification, using the new
DEFINE_XEN_FLEX_RING_AND_INTF macro.

Add the header to the C99 check.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Konrad Rzeszutek Wilk 
CC: jbeul...@suse.com
CC: konrad.w...@oracle.com
---
 xen/include/Makefile |  4 +++-
 xen/include/public/io/9pfs.h | 49 
 2 files changed, 52 insertions(+), 1 deletion(-)
 create mode 100644 xen/include/public/io/9pfs.h

diff --git a/xen/include/Makefile b/xen/include/Makefile
index 495c485..54adca9 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -94,9 +94,11 @@ all: headers.chk headers99.chk headers++.chk
 
 PUBLIC_HEADERS := $(filter-out public/arch-% public/dom0_ops.h, $(wildcard 
public/*.h public/*/*.h) $(public-y))
 
-PUBLIC_C99_HEADERS :=
+PUBLIC_C99_HEADERS := public/io/9pfs.h
 PUBLIC_ANSI_HEADERS := $(filter-out public/%ctl.h public/xsm/% 
public/%hvm/save.h $(PUBLIC_C99_HEADERS), $(PUBLIC_HEADERS))
 
+public/io/9pfs.h-prereq := string
+
 headers.chk: $(PUBLIC_ANSI_HEADERS) Makefile
for i in $(filter %.h,$^); do \
$(CC) -x c -ansi -Wall -Werror -include stdint.h \
diff --git a/xen/include/public/io/9pfs.h b/xen/include/public/io/9pfs.h
new file mode 100644
index 000..4bfd5d4
--- /dev/null
+++ b/xen/include/public/io/9pfs.h
@@ -0,0 +1,49 @@
+/*
+ * 9pfs.h -- Xen 9PFS transport
+ *
+ * Refer to docs/misc/9pfs.markdown for the specification
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (C) 2017 Stefano Stabellini 
+ */
+
+#ifndef __XEN_PUBLIC_IO_9PFS_H__
+#define __XEN_PUBLIC_IO_9PFS_H__
+
+#include "../grant_table.h"
+#include "ring.h"
+
+/*
+ * See docs/misc/9pfs.markdown in xen.git for the full specification:
+ * https://xenbits.xen.org/docs/unstable/misc/9pfs.html
+ */
+DEFINE_XEN_FLEX_RING_AND_INTF(xen_9pfs);
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.9.1


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

[Xen-devel] [PATCH v9 2/4] xen: introduce a C99 headers check

[Stefano Stabellini]

Introduce a C99 headers check, for non-ANSI compliant headers: 9pfs.h
and pvcalls.h.

In addition to the usual -include stdint.h, also add -include string.h
to the C99 check to get the declaration of memcpy and size_t.

For the same reason, also add -include cstring to the C++ check when
necessary.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Jan Beulich 
CC: jbeul...@suse.com
CC: konrad.w...@oracle.com
---
 .gitignore   |  3 +--
 xen/include/Makefile | 33 +
 2 files changed, 22 insertions(+), 14 deletions(-)

diff --git a/.gitignore b/.gitignore
index 443b12a..0265c1e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -273,8 +273,7 @@ xen/arch/*/efi/boot.c
 xen/arch/*/efi/compat.c
 xen/arch/*/efi/efi.h
 xen/arch/*/efi/runtime.c
-xen/include/headers.chk
-xen/include/headers++.chk
+xen/include/headers*.chk
 xen/include/asm
 xen/include/asm-*/asm-offsets.h
 xen/include/asm-x86/cpuid-autogen.h
diff --git a/xen/include/Makefile b/xen/include/Makefile
index aca7f20..495c485 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -90,11 +90,12 @@ compat/xlat.h: $(addprefix compat/.xlat/,$(xlat-y)) Makefile
 
 ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))
 
-all: headers.chk headers++.chk
+all: headers.chk headers99.chk headers++.chk
 
 PUBLIC_HEADERS := $(filter-out public/arch-% public/dom0_ops.h, $(wildcard 
public/*.h public/*/*.h) $(public-y))
 
-PUBLIC_ANSI_HEADERS := $(filter-out public/%ctl.h public/xsm/% 
public/%hvm/save.h, $(PUBLIC_HEADERS))
+PUBLIC_C99_HEADERS :=
+PUBLIC_ANSI_HEADERS := $(filter-out public/%ctl.h public/xsm/% 
public/%hvm/save.h $(PUBLIC_C99_HEADERS), $(PUBLIC_HEADERS))
 
 headers.chk: $(PUBLIC_ANSI_HEADERS) Makefile
for i in $(filter %.h,$^); do \
@@ -104,16 +105,24 @@ headers.chk: $(PUBLIC_ANSI_HEADERS) Makefile
done >$@.new
mv $@.new $@
 
+headers99.chk: $(PUBLIC_C99_HEADERS) Makefile
+   rm -f $@.new
+   $(foreach i, $(filter %.h,$^),\
+   $(CC) -x c -std=c99 -Wall -Werror \
+   -include stdint.h $(foreach j, $($(i)-prereq), -include $(j).h)   \
+   -S -o /dev/null $(i)  \
+   || exit $$?; echo $(i) >> $@.new;)
+   mv $@.new $@
+
 headers++.chk: $(PUBLIC_HEADERS) Makefile
-   if $(CXX) -v >/dev/null 2>&1; then \
-   for i in $(filter %.h,$^); do \
-   echo '#include "'$$i'"' \
-   | $(CXX) -x c++ -std=gnu++98 -Wall -Werror -D__XEN_TOOLS__ \
- -include stdint.h -include public/xen.h -S -o /dev/null - \
-   || exit 1; \
-   echo $$i; \
-   done ; \
-   fi >$@.new
+   rm -f $@.new
+   $(CXX) -v >/dev/null 2>&1 || exit 0;  \
+   $(foreach i, $(filter %.h,$^),\
+   echo "#include "\"$(i)\"  \
+   | $(CXX) -x c++ -std=gnu++98 -Wall -Werror -D__XEN_TOOLS__\
+ -include stdint.h -include public/xen.h \
+ $(foreach j, $($(i)-prereq), -include c$(j)) -S -o /dev/null -  \
+   || exit $$?; echo $(i) >> $@.new;)
mv $@.new $@
 
 endif
@@ -128,5 +137,5 @@ all: $(BASEDIR)/include/asm-x86/cpuid-autogen.h
 endif
 
 clean::
-   rm -rf compat headers.chk headers++.chk
+   rm -rf compat headers*.chk
rm -f $(BASEDIR)/include/asm-x86/cpuid-autogen.h
-- 
1.9.1


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

[Xen-devel] [PATCH v9 1/4] ring.h: introduce macros to handle monodirectional rings with multiple req sizes

[Stefano Stabellini]

This patch introduces macros, structs and functions to handle rings in
the format described by docs/misc/pvcalls.markdown and
docs/misc/9pfs.markdown. The index page (struct __name##_data_intf)
contains the indexes and the grant refs to setup two rings.

   Indexes page
   +--+
   |@0 $NAME_data_intf:   |
   |@76: ring_order = 1   |
   |@80: ref[0]+  |
   |@84: ref[1]+  |
   |   |  |
   |   |  |
   +--+
   |
   v (data ring)
   +---+---+
   |  @0->4095: in |
   |  ref[0]   |
   |---|
   |  @4096->8191: out |
   |  ref[1]   |
   +---+

$NAME_read_packet and $NAME_write_packet are provided to read or write
any data struct from/to the ring. In pvcalls, they are unused. In xen
9pfs, they are used to read or write the 9pfs header. In other protocols
they could be used to read/write the whole request structure. See
docs/misc/9pfs.markdown:Ring Usage to learn how to check how much data
is on the ring, and how to handle notifications.

There is a ring_size parameter to most functions so that protocols using
these macros don't have to have a statically defined ring order at build
time. In pvcalls for example, each new ring could have a different
order.

These macros don't help you share the indexes page or the event channels
needed for notifications. You can do that with other out of band
mechanisms, such as xenstore or another ring.

It is not possible to use a macro to define another macro with a
variable name. For this reason, this patch introduces static inline
functions instead, that are not C89 compliant. Additionally, the macro
defines a struct with a variable sized array, which is also not C89
compliant.

Signed-off-by: Stefano Stabellini 
CC: konrad.w...@oracle.com
CC: jbeul...@suse.com
---
 xen/include/public/io/ring.h | 158 +++
 1 file changed, 158 insertions(+)

diff --git a/xen/include/public/io/ring.h b/xen/include/public/io/ring.h
index 801c0da..30342fc 100644
--- a/xen/include/public/io/ring.h
+++ b/xen/include/public/io/ring.h
@@ -27,6 +27,21 @@
 #ifndef __XEN_PUBLIC_IO_RING_H__
 #define __XEN_PUBLIC_IO_RING_H__
 
+/*
+ * When #include'ing this header, you need to provide the following
+ * declaration upfront:
+ * - standard integers types (uint8_t, uint16_t, etc)
+ * They are provided by stdint.h of the standard headers.
+ *
+ * In addition, if you intend to use the FLEX macros, you also need to
+ * provide the following, before invoking the FLEX macros:
+ * - size_t
+ * - memcpy
+ * - grant_ref_t
+ * These declarations are provided by string.h of the standard headers,
+ * and grant_table.h from the Xen public headers.
+ */
+
 #include "../xen-compat.h"
 
 #if __XEN_INTERFACE_VERSION__ < 0x00030208
@@ -313,6 +328,149 @@ typedef struct __name##_back_ring __name##_back_ring_t
 (_work_to_do) = RING_HAS_UNCONSUMED_RESPONSES(_r);  \
 } while (0)
 
+
+/*
+ * DEFINE_XEN_FLEX_RING_AND_INTF defines two monodirectional rings and
+ * functions to check if there is data on the ring, and to read and
+ * write to them.
+ *
+ * DEFINE_XEN_FLEX_RING is similar to DEFINE_XEN_FLEX_RING_AND_INTF, but
+ * does not define the indexes page. As different protocols can have
+ * extensions to the basic format, this macro allow them to define their
+ * own struct.
+ *
+ * XEN_FLEX_RING_SIZE
+ *   Convenience macro to calculate the size of one of the two rings
+ *   from the overall order.
+ *
+ * $NAME_mask
+ *   Function to apply the size mask to an index, to reduce the index
+ *   within the range [0-size].
+ *
+ * $NAME_read_packet
+ *   Function to read data from the ring. The amount of data to read is
+ *   specified by the "size" argument.
+ *
+ * $NAME_write_packet
+ *   Function to write data to the ring. The amount of data to write is
+ *   specified by the "size" argument.
+ *
+ * $NAME_get_ring_ptr
+ *   Convenience function that returns a pointer to read/write to the
+ *   ring at the right location.
+ *
+ * $NAME_data_intf
+ *   Indexes page, shared between frontend and backend. It also
+ *   contains the array of grant refs.
+ *
+ * $NAME_queued
+ *   Function to calculate how many bytes are currently on the ring,
+ *   ready to be read. It can also be used to calculate how much free
+ *   space is currently on the ring (XEN_FLEX_RING_SIZE() -
+ *   $NAME_queued()).
+ */
+
+#ifndef XEN_PAGE_SHIFT
+/* The PAGE_SIZE for ring protocols and hypercall interfaces is always
+ * 4K, regardless of the architecture, and page granularity chosen by
+ * operating systems.
+ */
+#define XEN_PAGE_SHIFT 12
+#endif
+#define 

Re: [Xen-devel] [PATCH v8 2/4] xen: introduce a C99 headers check

[Stefano Stabellini]

On Mon, 3 Apr 2017, Jan Beulich wrote:
> >>> On 31.03.17 at 21:15,  wrote:
> > Introduce a C99 headers check, for non-ANSI compliant headers: 9pfs.h
> > and pvcalls.h.
> > 
> > In addition to the usual -include stdint.h, also add -include string.h
> > to the C99 check to get the declaration of memcpy and size_t.
> > 
> > For the same reason, also add -include cstring to the C++ check when
> > necessary.
> > 
> > Signed-off-by: Stefano Stabellini 
> > CC: jbeul...@suse.com 
> > CC: konrad.w...@oracle.com 
> > ---
> >  .gitignore   |  3 +--
> >  xen/include/Makefile | 30 ++
> >  2 files changed, 19 insertions(+), 14 deletions(-)
> > 
> > diff --git a/.gitignore b/.gitignore
> > index 443b12a..0265c1e 100644
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -273,8 +273,7 @@ xen/arch/*/efi/boot.c
> >  xen/arch/*/efi/compat.c
> >  xen/arch/*/efi/efi.h
> >  xen/arch/*/efi/runtime.c
> > -xen/include/headers.chk
> > -xen/include/headers++.chk
> > +xen/include/headers*.chk
> >  xen/include/asm
> >  xen/include/asm-*/asm-offsets.h
> >  xen/include/asm-x86/cpuid-autogen.h
> > diff --git a/xen/include/Makefile b/xen/include/Makefile
> > index aca7f20..fd57ce4 100644
> > --- a/xen/include/Makefile
> > +++ b/xen/include/Makefile
> > @@ -90,11 +90,12 @@ compat/xlat.h: $(addprefix compat/.xlat/,$(xlat-y)) 
> > Makefile
> >  
> >  ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))
> >  
> > -all: headers.chk headers++.chk
> > +all: headers.chk headers99.chk headers++.chk
> >  
> >  PUBLIC_HEADERS := $(filter-out public/arch-% public/dom0_ops.h, $(wildcard 
> > public/*.h public/*/*.h) $(public-y))
> >  
> > -PUBLIC_ANSI_HEADERS := $(filter-out public/%ctl.h public/xsm/% 
> > public/%hvm/save.h, $(PUBLIC_HEADERS))
> > +PUBLIC_C99_HEADERS :=
> > +PUBLIC_ANSI_HEADERS := $(filter-out public/%ctl.h public/xsm/% 
> > public/%hvm/save.h $(PUBLIC_C99_HEADERS), $(PUBLIC_HEADERS))
> >  
> >  headers.chk: $(PUBLIC_ANSI_HEADERS) Makefile
> > for i in $(filter %.h,$^); do \
> > @@ -104,16 +105,21 @@ headers.chk: $(PUBLIC_ANSI_HEADERS) Makefile
> > done >$@.new
> > mv $@.new $@
> >  
> > +headers99.chk: $(PUBLIC_C99_HEADERS) Makefile
> > +   rm -f $@.new
> > +   $(foreach i, $(filter %.h,$^), $(CC) -x c -std=c99 -Wall -Werror\
> > +   -include stdint.h $(foreach j, $($(i)-prereq), -include $(j).h) \
> > +   -S -o /dev/null $(i) || exit $$?; echo $(i) >> $@.new;)
> 
> I would have wished that you formatted this along the lines of
> the C++ rule below (|| first on its line, aligned with the beginning
> of the command). But anyway - I can live with it here, but ...
> 
> > +   mv $@.new $@
> > +
> >  headers++.chk: $(PUBLIC_HEADERS) Makefile
> > -   if $(CXX) -v >/dev/null 2>&1; then \
> > -   for i in $(filter %.h,$^); do \
> > -   echo '#include "'$$i'"' \
> > -   | $(CXX) -x c++ -std=gnu++98 -Wall -Werror -D__XEN_TOOLS__ \
> > - -include stdint.h -include public/xen.h -S -o /dev/null - \
> > -   || exit 1; \
> > -   echo $$i; \
> > -   done ; \
> > -   fi >$@.new
> > +   rm -f $@.new
> > +   $(CXX) -v >/dev/null 2>&1 || exit 0;   \
> > +   $(foreach i, $(filter %.h,$^), echo "#include "\"$(i)\"\
> > +   |$(CXX) -x c++ -std=gnu++98 -Wall -Werror -D__XEN_TOOLS__  \
> > +   -include stdint.h -include public/xen.h\
> > +   $(foreach j, $($(i)-prereq), -include c$(j)) -S -o /dev/null - \
> > +   || exit $$?; echo $(i) >> $@.new;)
> 
> ... indentation still doesn't match how it was originally (including,
> as mentioned above as well, aligning the start of the command
> with | and || ) and there's a blank missing after | . Of course I'm
> fine with you fixing this upon commit, if no other need arises for
> a v9, so on that basis with those adjustments
> Reviewed-by: Jan Beulich 

Turns out that I have a small fix to patch #1 to do, so I'll resend the
series once again with your comments and reviewed-by. I hope I
interpreted your alignment asks correctly.

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

Re: [Xen-devel] [PATCH v8 1/4] ring.h: introduce macros to handle monodirectional rings with multiple req sizes

[Stefano Stabellini]

On Tue, 4 Apr 2017, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 31, 2017 at 12:15:16PM -0700, Stefano Stabellini wrote:
> > This patch introduces macros, structs and functions to handle rings in
> > the format described by docs/misc/pvcalls.markdown and
> > docs/misc/9pfs.markdown. The index page (struct __name##_data_intf)
> > contains the indexes and the grant refs to setup two rings.
> > 
> >Indexes page
> >+--+
> >|@0 $NAME_data_intf:   |
> >|@76: ring_order = 1   |
> >|@80: ref[0]+  |
> >|@84: ref[1]+  |
> >|   |  |
> >|   |  |
> >+--+
> >|
> >v (data ring)
> >+---+---+
> >|  @0->4095: in |
> >|  ref[0]   |
> >|---|
> >|  @4096->8191: out |
> >|  ref[1]   |
> >+---+
> > 
> > $NAME_read_packet and $NAME_write_packet are provided to read or write
> > any data struct from/to the ring. In pvcalls, they are unused. In xen
> > 9pfs, they are used to read or write the 9pfs header. In other protocols
> > they could be used to read/write the whole request structure. See
> > docs/misc/9pfs.markdown:Ring Usage to learn how to check how much data
> > is on the ring, and how to handle notifications.
> > 
> > There is a ring_size parameter to most functions so that protocols using
> > these macros don't have to have a statically defined ring order at build
> > time. In pvcalls for example, each new ring could have a different
> > order.
> > 
> > These macros don't help you share the indexes page or the event channels
> > needed for notifications. You can do that with other out of band
> > mechanisms, such as xenstore or another ring.
> > 
> > It is not possible to use a macro to define another macro with a
> > variable name. For this reason, this patch introduces static inline
> > functions instead, that are not C89 compliant. Additionally, the macro
> > defines a struct with a variable sized array, which is also not C89
> > compliant.
> > 
> > Signed-off-by: Stefano Stabellini 
> > CC: konrad.w...@oracle.com
> > CC: jbeul...@suse.com
> > ---
> >  xen/include/public/io/ring.h | 151 
> > +++
> >  1 file changed, 151 insertions(+)
> > 
> > diff --git a/xen/include/public/io/ring.h b/xen/include/public/io/ring.h
> > index 801c0da..7b7794c 100644
> > --- a/xen/include/public/io/ring.h
> > +++ b/xen/include/public/io/ring.h
> > @@ -27,6 +27,21 @@
> >  #ifndef __XEN_PUBLIC_IO_RING_H__
> >  #define __XEN_PUBLIC_IO_RING_H__
> >  
> > +/*
> > + * When #include'ing this header, you need to provide the following
> > + * declaration upfront:
> > + * - standard integers types (uint8_t, uint16_t, etc)
> > + * They are provided by stdint.h of the standard headers.
> > + *
> > + * In addition, if you intend to use the FLEX macros, you also need to
> > + * provide the following, before invoking the FLEX macros:
> > + * - size_t
> > + * - memcpy
> > + * - grant_ref_t
> > + * These declarations are provided by string.h of the standard headers,
> > + * and grant_table.h from the Xen public headers.
> > + */
> > +
> >  #include "../xen-compat.h"
> >  
> >  #if __XEN_INTERFACE_VERSION__ < 0x00030208
> > @@ -313,6 +328,142 @@ typedef struct __name##_back_ring __name##_back_ring_t
> >  (_work_to_do) = RING_HAS_UNCONSUMED_RESPONSES(_r);  \
> >  } while (0)
> >  
> > +
> > +/*
> > + * DEFINE_XEN_FLEX_RING_AND_INTF defines two monodirectional rings and
> > + * functions to check if there is data on the ring, and to read and
> > + * write to them.
> > + *
> > + * DEFINE_XEN_FLEX_RING is similar to DEFINE_XEN_FLEX_RING_AND_INTF, but
> > + * does not define the indexes page. As different protocols can have
> > + * extensions to the basic format, this macro allow them to define their
> > + * own struct.
> > + *
> > + * XEN_FLEX_RING_SIZE
> > + *   Convenience macro to calculate the size of one of the two rings
> > + *   from the overall order.
> > + *
> > + * $NAME_mask
> > + *   Function to apply the size mask to an index, to reduce the index
> > + *   within the range [0-size].
> > + *
> > + * $NAME_read_packet
> > + *   Function to read data from the ring. The amount of data to read is
> > + *   specified by the "size" argument.
> > + *
> > + * $NAME_write_packet
> > + *   Function to write data to the ring. The amount of data to write is
> > + *   specified by the "size" argument.
> > + *
> > + * $NAME_get_ring_ptr
> > + *   Convenience function that returns a pointer to read/write to the
> > + *   ring at the right location.
> > + *
> > + * $NAME_data_intf
> > + *   Indexes 

Re: [Xen-devel] [Qemu-devel] [PATCH v2 2/6] qdict: Add convenience helpers for wrapped puts

[Eric Blake]

On 01/19/2017 08:38 AM, Eric Blake wrote:
> On 01/19/2017 03:25 AM, Markus Armbruster wrote:
>> Eric Blake  writes:
>>
>>> Quite a few users of qdict_put() were manually wrapping a
>>> non-QObject. We can make such call-sites shorter, by providing
>>> common macros to do the tedious work.  Also shorten nearby
>>> qdict_put_obj(,,QOBJECT()) sequences.
>>>
>>> Signed-off-by: Eric Blake 
>>> Reviewed-by: Alberto Garcia 
>>>
>>> ---
>>>
>>> v2: rebase to current master
>>>
>>> I'm okay if you want me to break this patch into smaller pieces.
>>
>> I guess I'm okay with a single piece, but I'd like to know how you did
>> the conversion.  Coccinelle?  Manually?
> 
> Manual, via grepping for put_obj.*QOBJECT. I'll see if I can do the same
> under Coccinelle (at which point, committing the script will make it
> easier to rerun cleanups if later code reintroduces poor usage
> patterns), so maybe I have a v3 coming up.

I've got a Coccinelle patch (mostly) working now - but it has one
shortfall - I found places in tests/check-qdict.c that coccinelle
didn't, and traced it to the fact that our use of g_assert_cmpint(expr,
==, expr) throws off the coccinelle parser so badly that it silently
ignores the entire function body containing the use of that macro.  v3
will be posted soon, with the best of both worlds (coccinelle caught
spots that I missed, not to mention recent code base changes; and my
manual search found the spots in tests/ that coccinelle missed).

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

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

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. 107194

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass

version targeted for testing:
 xen  045d5d10ee5f0066a7e71d1fe18f9c7c27d64703
baseline version:
 xen  c4bdbec00c9063736361124a3492ebceabfaed06

Last test of basis   107194  2017-04-04 16:01:54 Z0 days
Testing same since   107202  2017-04-04 21:17:38 Z0 days1 attempts


People who touched revisions under test:
  Iurii Konovalenko 
  Oleksandr Andrushchenko 
  Oleksandr Dmytryshyn 
  Oleksandr Grytsov 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  fail
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Not pushing.


commit 045d5d10ee5f0066a7e71d1fe18f9c7c27d64703
Author: Oleksandr Andrushchenko 
Date:   Mon Mar 20 09:03:27 2017 +0200

xen/sndif: Add sound-device ABI

Add ABI for the two halves of a para-virtualized
sound driver to communicate with each other.

The ABI allows implementing audio playback and capture as
well as volume control and possibility to mute/unmute
audio sources.

Note: depending on the use-case backend can expose more sound
cards and PCM devices/streams than the underlying HW physically
has by employing SW mixers, configuring virtual sound streams,
channels etc. Thus, allowing fine tunned configurations per
frontend.

Reviewed-by: Konrad Rzeszutek Wilk 
Signed-off-by: Oleksandr Andrushchenko 
Signed-off-by: Oleksandr Grytsov 
Signed-off-by: Oleksandr Dmytryshyn 
Signed-off-by: Iurii Konovalenko 
(qemu changes not included)

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

Re: [Xen-devel] ARM:Booting xen on pine64 board

[Julien Grall]

Hi,

On 04/04/2017 21:45, Stefano Stabellini wrote:
> On Tue, 4 Apr 2017, Andre Przywara wrote:
>> Hi,
>>
>> On 04/04/17 20:02, Stefano Stabellini wrote:
>>> Also CC'ing Andre that I think has a pine64.
>>>
>>> On Tue, 4 Apr 2017, Stefano Stabellini wrote:
 On Sat, 1 Apr 2017, bharat gohil wrote:
> Hello

 Hello Bharat, thanks for your email.


> I am trying to boot xen(debug build) on pine64 ARM64 based board but its 
> hangs at following position,
>
> - UART enabled -
> - CPU  booting -
> - Current EL 0008 -
> - Xen starting at EL2 -
> - Zero BSS -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) Checking for initrd in /chosen
> (XEN) RAM: 4100 - 7fff
> (XEN)
> (XEN) MODULE[0]: 7e20 - 7e202000 Device Tree
> (XEN) MODULE[1]: 7e40 - 7ef46a00 Kernel   
> console=hvc0 ro root=/dev/mmcblk0p2 clk_ignore_unused rootwait
> (XEN)  RESVD[0]: 7e20 - 7e202000
> (XEN)
> (XEN) Command line: dtuart=serial0 earlyprint loglvl=all conswitch=x 
> dom0_mem=128M
> (XEN) Placing Xen at 0x7fc0-0x7fe0
> (XEN) Update BOOTMOD_XEN from 7fe0-7fefad81 => 
> 7fc0-7fcfad81
> (XEN) Booting using Device Tree
> (XEN) Domain heap initialised
> (XEN) Platform: Generic System
> (XEN) Looking for dtuart at "serial0", options ""
>  Xen 4.9-unstable
> (XEN) Xen version 4.9-unstable (bgohil@) (aarch64-linux-gnu-gcc (Linaro 
> GCC 6.2-2016.11) 6.2.1 20161016) debug=n  Tue Mar 28 16:12:32 IST 2017
> (XEN) Latest ChangeSet: Fri Mar 24 14:19:47 2017 +0100 git:5b08f85
> (XEN) Processor: 410fd034: "ARM Limited", variant: 0x0, part 0xd03, rev 
> 0x4
> (XEN) 64-bit Execution:
> (XEN)   Processor Features:  
> (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
> (XEN) Extensions: FloatingPoint AdvancedSIMD
> (XEN)   Debug Features: 10305106 
> (XEN)   Auxiliary Features:  
> (XEN)   Memory Model Features: 1122 
> (XEN)   ISA Features:  00011120 
> (XEN) 32-bit Execution:
> (XEN)   Processor Features: 0131:00011011
> (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
> (XEN) Extensions: GenericTimer Security
> (XEN)   Debug Features: 03010066
> (XEN)   Auxiliary Features: 
> (XEN)   Memory Model Features: 10201105 4000 0126 02102211
> (XEN)  ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121
> (XEN) Using PSCI-0.2 for SMP bringup
> (XEN) SMP: Allowing 4 CPUs
> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 24000 KHz
> (XEN) GICv2 initialization:
> (XEN) gic_dist_addr=01c81000
> (XEN) gic_cpu_addr=01c82000
> (XEN) gic_hyp_addr=01c84000
> (XEN) gic_vcpu_addr=01c86000
> (XEN) gic_maintenance_irq=25
> (XEN) GICv2: 224 lines, 4 cpus, secure (IID 0200143b).
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
>
> but when I boot dtuart= say duart=xyz instead of 
> dtuart=serial0, xen booted successfully but Dom0 crash while probing 
> 'serial0' driver. 
>
> If I remove 'serial0' node from device tree, Dom0 boot successfully but 
> unable to enter input into 'hvc' console. 
>
> what could be wrong here or missing something?

 What is your dom0 command line? Are you passing console=hvc0?

 It looks like pine64 is using an allwinner sun50i-uart, for which we
 don't have a proper driver in Xen yet. That is probably the reason why
 you can see some output from Xen, but you cannot type anything in later
 in Dom0 (which is sent to Xen via the HVC console).  Please send a patch
 to add a simple sun50i-uart driver (see xen/drivers/char/). Given that
 both Xen and Linux are GPLv2, you can import code from Linux if you find
 it appropriate.
>>
>> The UART is exactly the same as in the other Allwinner SoCs, so there is
>> no need for a new UART driver.
>> Another issue inherited from the 32-bit Allwinner chips is that the
>> first four UARTs share a page, so they have to be blacklisted, as Xen
>> can't properly separate them.
>> You might want to look at xen/arch/arm/platforms/sunxi.c. Not sure if
>> this needs to be tied in arm64 somehow.
>  
> No, it doesn't, it should work on arm64 out of the box. But the platform
> compatible string is different: "sun7i-a20" in sunxi.c and "sun50iw1p1"
> on the pine64 dts. If the board is exactly the same, then we only need
> to add "sun50iw1p1" to sunxi_dt_compat.
> 
> What do you do to boot it with Xen?

I played 

Re: [Xen-devel] ARM:Booting xen on pine64 board

[Stefano Stabellini]

On Tue, 4 Apr 2017, Andre Przywara wrote:
> Hi,
> 
> On 04/04/17 20:02, Stefano Stabellini wrote:
> > Also CC'ing Andre that I think has a pine64.
> > 
> > On Tue, 4 Apr 2017, Stefano Stabellini wrote:
> >> On Sat, 1 Apr 2017, bharat gohil wrote:
> >>> Hello
> >>
> >> Hello Bharat, thanks for your email.
> >>
> >>
> >>> I am trying to boot xen(debug build) on pine64 ARM64 based board but its 
> >>> hangs at following position,
> >>>
> >>> - UART enabled -
> >>> - CPU  booting -
> >>> - Current EL 0008 -
> >>> - Xen starting at EL2 -
> >>> - Zero BSS -
> >>> - Setting up control registers -
> >>> - Turning on paging -
> >>> - Ready -
> >>> (XEN) Checking for initrd in /chosen
> >>> (XEN) RAM: 4100 - 7fff
> >>> (XEN)
> >>> (XEN) MODULE[0]: 7e20 - 7e202000 Device Tree
> >>> (XEN) MODULE[1]: 7e40 - 7ef46a00 Kernel   
> >>> console=hvc0 ro root=/dev/mmcblk0p2 clk_ignore_unused rootwait
> >>> (XEN)  RESVD[0]: 7e20 - 7e202000
> >>> (XEN)
> >>> (XEN) Command line: dtuart=serial0 earlyprint loglvl=all conswitch=x 
> >>> dom0_mem=128M
> >>> (XEN) Placing Xen at 0x7fc0-0x7fe0
> >>> (XEN) Update BOOTMOD_XEN from 7fe0-7fefad81 => 
> >>> 7fc0-7fcfad81
> >>> (XEN) Booting using Device Tree
> >>> (XEN) Domain heap initialised
> >>> (XEN) Platform: Generic System
> >>> (XEN) Looking for dtuart at "serial0", options ""
> >>>  Xen 4.9-unstable
> >>> (XEN) Xen version 4.9-unstable (bgohil@) (aarch64-linux-gnu-gcc (Linaro 
> >>> GCC 6.2-2016.11) 6.2.1 20161016) debug=n  Tue Mar 28 16:12:32 IST 2017
> >>> (XEN) Latest ChangeSet: Fri Mar 24 14:19:47 2017 +0100 git:5b08f85
> >>> (XEN) Processor: 410fd034: "ARM Limited", variant: 0x0, part 0xd03, rev 
> >>> 0x4
> >>> (XEN) 64-bit Execution:
> >>> (XEN)   Processor Features:  
> >>> (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
> >>> (XEN) Extensions: FloatingPoint AdvancedSIMD
> >>> (XEN)   Debug Features: 10305106 
> >>> (XEN)   Auxiliary Features:  
> >>> (XEN)   Memory Model Features: 1122 
> >>> (XEN)   ISA Features:  00011120 
> >>> (XEN) 32-bit Execution:
> >>> (XEN)   Processor Features: 0131:00011011
> >>> (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
> >>> (XEN) Extensions: GenericTimer Security
> >>> (XEN)   Debug Features: 03010066
> >>> (XEN)   Auxiliary Features: 
> >>> (XEN)   Memory Model Features: 10201105 4000 0126 02102211
> >>> (XEN)  ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121
> >>> (XEN) Using PSCI-0.2 for SMP bringup
> >>> (XEN) SMP: Allowing 4 CPUs
> >>> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 24000 KHz
> >>> (XEN) GICv2 initialization:
> >>> (XEN) gic_dist_addr=01c81000
> >>> (XEN) gic_cpu_addr=01c82000
> >>> (XEN) gic_hyp_addr=01c84000
> >>> (XEN) gic_vcpu_addr=01c86000
> >>> (XEN) gic_maintenance_irq=25
> >>> (XEN) GICv2: 224 lines, 4 cpus, secure (IID 0200143b).
> >>> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> >>>
> >>> but when I boot dtuart= say duart=xyz instead of 
> >>> dtuart=serial0, xen booted successfully but Dom0 crash while probing 
> >>> 'serial0' driver. 
> >>>
> >>> If I remove 'serial0' node from device tree, Dom0 boot successfully but 
> >>> unable to enter input into 'hvc' console. 
> >>>
> >>> what could be wrong here or missing something?
> >>
> >> What is your dom0 command line? Are you passing console=hvc0?
> >>
> >> It looks like pine64 is using an allwinner sun50i-uart, for which we
> >> don't have a proper driver in Xen yet. That is probably the reason why
> >> you can see some output from Xen, but you cannot type anything in later
> >> in Dom0 (which is sent to Xen via the HVC console).  Please send a patch
> >> to add a simple sun50i-uart driver (see xen/drivers/char/). Given that
> >> both Xen and Linux are GPLv2, you can import code from Linux if you find
> >> it appropriate.
> 
> The UART is exactly the same as in the other Allwinner SoCs, so there is
> no need for a new UART driver.
> Another issue inherited from the 32-bit Allwinner chips is that the
> first four UARTs share a page, so they have to be blacklisted, as Xen
> can't properly separate them.
> You might want to look at xen/arch/arm/platforms/sunxi.c. Not sure if
> this needs to be tied in arm64 somehow.
 
No, it doesn't, it should work on arm64 out of the box. But the platform
compatible string is different: "sun7i-a20" in sunxi.c and "sun50iw1p1"
on the pine64 dts. If the board is exactly the same, then we only need
to add "sun50iw1p1" to sunxi_dt_compat.

What do you do to boot it with Xen?

___
Xen-devel mailing list

Re: [Xen-devel] Wondering about cirris and stdvga

[Konrad Rzeszutek Wilk]

On Mon, Mar 20, 2017 at 02:25:16PM +, Roger Pau Monne wrote:
> On Mon, Mar 20, 2017 at 02:21:50PM +, Paul Durrant wrote:
> > > -Original Message-
> > > From: Roger Pau Monne
> > > Sent: 20 March 2017 14:14
> > > To: Konrad Rzeszutek Wilk 
> > > Cc: Dario Faggioli ; Ian Jackson
> > > ; Pasi Kärkkäinen ; Stefano 
> > > Stabellini
> > > ; Paul Durrant ; Anthony
> > > Perard ; xen-devel  > > de...@lists.xenproject.org>; Roger Pau Monne ;
> > > ajax 
> > > Subject: Re: [Xen-devel] Wondering about cirris and stdvga
> > > 
> > > On Fri, Mar 17, 2017 at 10:19:47AM -0400, Konrad Rzeszutek Wilk wrote:
> > > > On Fri, Nov 25, 2016 at 07:17:31PM +0100, Dario Faggioli wrote:
> > > > > On Mon, 2016-11-21 at 10:04 +0100, Dario Faggioli wrote:
> > > > > > On Sat, 2016-11-19 at 12:56 +0200, Pasi Kärkkäinen wrote:
> > > > > > > 2) It'd good to create an upstream Wayland bugreport and
> > > > > > > investigate
> > > > > > > more about why cirrus is broken with Wayland.
> > > > > > >
> > > > > > Sure, I can do that.
> > > > > >
> > > > > An update.
> > > > >
> > > > > The discussion here has gone on a bit:
> > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1227770
> > > > >
> > > > > The conclusion seems to be that:
> > > > > "cirrus (virtual) hardware is simply to old to run wayland."
> > > > >
> > > > > And so this is (and will very likely remain) a 'WONTFIX' for cirrus, 
> > > > > at
> > > > > least on Fedora.
> > > > >
> > > > > I've also opened a thread on wayland-devel mailing list:
> > > > > https://lists.freedesktop.org/archives/wayland-devel/2016-
> > > November/0318
> > > > > 56.html
> > > > >
> > > > > There, I learned that Wayland is not the component to blame, as 
> > > > > Wayland
> > > > > is the protocol. So, in our case, the 'bug' is most likely in
> > > > > gnome-shell / Mutter.
> > > > >
> > > > > That's not a good thing, though. In fact, just to cite a few sentences
> > > > > from the thread:
> > > > >
> > > > > "Packed 24bpp is going to be pain, not least because I don't know of
> > > > > any clients which render in packed-24"
> > > > >
> > > > > "The 24bpp paths in pretty much everything are also badly untested, so
> > > > > that's asking for trouble."
> > > > >
> > > > > "you will need to test and fix every single Wayland compositor out
> > > > > there."
> > > > >
> > > > > "I really think you'd be far far better off trying to figure out how 
> > > > > to
> > > > > move off the legacy Cirrus emulation as soon as you can."
> > > > >
> > > > > So, we can try seeing if I manage to get some logs out of Mutter to
> > > > > figure out the actual bug more precisely _but_, considering all that
> > > > > people have said both here and in the other forums, I think it would 
> > > > > be
> > > > > better to spend that time figuring out how to switch (and document 
> > > > > this
> > > > > for 4.8 and previous version, of course).
> > > >
> > > >
> > > > Yes. Also as there does not seem to be any supported OS that
> > > > _needs_ the old Cirrus OS to boot and function.
> > > 
> > > Not that I oppose to change to stdvga, but what would happen to Windows
> > > VMs
> > > that suddenly change from cirrus to stdvga, is that going to trigger the
> > > license invalidation stuff? AFAIK this happens when you change hardware,
> > > but
> > > maybe a VGA change doesn't trigger that because it's common for people to
> > > upgrade VGA cards?
> > > 
> > 
> > Changing anything that Windows considers part of the core system will 
> > invalidate a license but, as you say, the graphics device may not be core. 
> > There is another issue (which I just verified myself) which as that at 
> > least some versions of Windows (Server 2008 in my case) won't boot when 
> > using stdvga with qemu trad.
> 
> IMHO, I would leave qemu-trad alone and just change the default gfx card for
> qemu-xen. I don't see much point in touching anything in qemu-trad.

Exactly. The patch I had was only for qemu-xen.

> 
> Roger.

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

Re: [Xen-devel] [PATCH v4] displif: add ABI for para-virtual display

[Konrad Rzeszutek Wilk]

.snip..
> > + *- Protocol version 
> > --
> > + *
> > + * version
> > + *  Values: 
> > + *
> > + *  Protocol version, chosen among the ones supported by the backend.
> > + *
..snip..
> > +#define XENDISPL_FIELD_BE_VERSIONS"versions"
> > +#define XENDISPL_FIELD_FE_VERSION "version"

I couldn't find in spec what version this actually is. As in I would
assume it is version 1, but that is not enumerated.

Perhaps it may be good to include in the Backend section that the
'versions' will contain the value 1. And that future changes would
update it?



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

Re: [Xen-devel] [PATCH v4] displif: add ABI for para-virtual display

[Oleksandr Andrushchenko]

Hi, Konrad!


On 04/04/2017 10:38 PM, Konrad Rzeszutek Wilk wrote:

Hey!

I only had minor comments - and if you are OK with them

comments seem to be reasonable to me

  I can also
put them in the patch when checking them in

Please, do me a favor

  (or if you want you can
repost it right away and I will check in the new version).


---
Changes since v3:
  * add clarification on buffer's size/depth/format and
connector's resolution
  * move be_alloc feature into domain's configuration
to allow more use-cases and freedom (e.g. for 1:1
mapped domains there may be no need to request backend
to allocate buffers, while for the rest it may make more
sense)
  * rename XenStore entries:
  ctrl-ring-ref -> req-ring-ref
  ctrl-channel -> req-event-channel
  event-ring-ref -> evt-ring-ref
  event-channel -> evt-event-channel
  * have 2 separate sections for req/resp and evt transport
parameters
  * fix and extend recovery flow description
  * reserve request codes for future fbif integration if need be
(request codes [0; 15] are reserved)
  * error on attempt to create multiple buffers with same cookie(s)
  * clarification of page directory usage for be_alloc feature
  * add editor's block

Changes since v2:
  * updated XenStore configuration template/pattern
  * added "Recovery flow" to state diagram description
  * renamed gref_directory_start to gref_directory
  * added missing "versions" and "version" string constants

Changes since v1:
  * fixed xendispl_event_page padding size
  * added versioning support
  * explicitly define value types for XenStore fields
  * text decoration re-work
  * added offsets to ASCII box notation

Changes since initial:
  * DRM changed to DISPL, protocol made generic
  * major re-work addressing issues raised for sndif

Signed-off-by: Oleksandr Grytsov 
Signed-off-by: Oleksandr Andrushchenko 
---
  xen/include/public/io/displif.h | 847 
  1 file changed, 847 insertions(+)
  create mode 100644 xen/include/public/io/displif.h

diff --git a/xen/include/public/io/displif.h b/xen/include/public/io/displif.h
new file mode 100644
index ..ac55c4fe8bbe
--- /dev/null
+++ b/xen/include/public/io/displif.h
@@ -0,0 +1,847 @@
+/**
+ * displif.h
+ *
+ * Unified display device I/O interface for Xen guest OSes.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (C) 2016-2017 EPAM Systems Inc.
+ *
+ * Authors: Oleksandr Andrushchenko 
+ *  Oleksandr Grytsov 
+ */
+
+#ifndef __XEN_PUBLIC_IO_DISPLIF_H__
+#define __XEN_PUBLIC_IO_DISPLIF_H__
+
+#include "ring.h"
+#include "../grant_table.h"
+
+/*
+ **
+ *  Main features provided by the protocol
+ **
+ * This protocol aims to provide a unified protocol which fits more
+ * sophisticated use-cases than a framebuffer device can handle. At the
+ * moment basic functionality is supported with the intention to be extended:
+ *  o multiple dynamically allocated/destroyed framebuffers
+ *  o buffers of arbitrary sizes
+ *  o buffer allocation at either back or front end
+ *  o better configuration options including multiple display support
+ *
+ * Note: existing fbif can be used together with displif running at the
+ * same time, e.g. on Linux one provides framebuffer and another DRM/KMS
+ *
+ * Note: display resolution (XenStore's "resolution" property) defines
+ * visible area of the virtual display. At the same time resolution of
+ * the display and frame buffers may differ: buffers can be smaller, equal
+ * or bigger than the visible area. This is to 

Re: [Xen-devel] [PATCH v8 4/4] Introduce the pvcalls header

[Konrad Rzeszutek Wilk]

On Fri, Mar 31, 2017 at 12:15:19PM -0700, Stefano Stabellini wrote:
> Define the ring and request and response structs according to the
> specification. Use the new DEFINE_XEN_FLEX_RING macro.
> 
> Add the header to the C99 check.
> 
> Signed-off-by: Stefano Stabellini 
> CC: jbeul...@suse.com
> CC: konrad.w...@oracle.com

Reviewed-by: Konrad Rzeszutek Wilk 
> ---
>  xen/include/Makefile|   3 +-
>  xen/include/public/io/pvcalls.h | 153 
> 
>  2 files changed, 155 insertions(+), 1 deletion(-)
>  create mode 100644 xen/include/public/io/pvcalls.h
> 
> diff --git a/xen/include/Makefile b/xen/include/Makefile
> index a241444..56b389e 100644
> --- a/xen/include/Makefile
> +++ b/xen/include/Makefile
> @@ -94,10 +94,11 @@ all: headers.chk headers99.chk headers++.chk
>  
>  PUBLIC_HEADERS := $(filter-out public/arch-% public/dom0_ops.h, $(wildcard 
> public/*.h public/*/*.h) $(public-y))
>  
> -PUBLIC_C99_HEADERS := public/io/9pfs.h
> +PUBLIC_C99_HEADERS := public/io/9pfs.h public/io/pvcalls.h
>  PUBLIC_ANSI_HEADERS := $(filter-out public/%ctl.h public/xsm/% 
> public/%hvm/save.h $(PUBLIC_C99_HEADERS), $(PUBLIC_HEADERS))
>  
>  public/io/9pfs.h-prereq := string
> +public/io/pvcalls.h-prereq := string
>  
>  headers.chk: $(PUBLIC_ANSI_HEADERS) Makefile
>   for i in $(filter %.h,$^); do \
> diff --git a/xen/include/public/io/pvcalls.h b/xen/include/public/io/pvcalls.h
> new file mode 100644
> index 000..cb81712
> --- /dev/null
> +++ b/xen/include/public/io/pvcalls.h
> @@ -0,0 +1,153 @@
> +/*
> + * pvcalls.h -- Xen PV Calls Protocol
> + *
> + * Refer to docs/misc/pvcalls.markdown for the specification
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a 
> copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, 
> and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 
> THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + * Copyright (C) 2017 Stefano Stabellini 
> + */
> +
> +#ifndef __XEN_PUBLIC_IO_PVCALLS_H__
> +#define __XEN_PUBLIC_IO_PVCALLS_H__
> +
> +#include "../grant_table.h"
> +#include "ring.h"
> +
> +/*
> + * See docs/misc/pvcalls.markdown in xen.git for the full specification:
> + * https://xenbits.xen.org/docs/unstable/misc/pvcalls.html
> + */
> +struct pvcalls_data_intf {
> +RING_IDX in_cons, in_prod, in_error;
> +
> +uint8_t pad1[52];
> +
> +RING_IDX out_cons, out_prod, out_error;
> +
> +uint8_t pad2[52];
> +
> +RING_IDX ring_order;
> +grant_ref_t ref[];
> +};
> +DEFINE_XEN_FLEX_RING(pvcalls);
> +
> +#define PVCALLS_SOCKET 0
> +#define PVCALLS_CONNECT1
> +#define PVCALLS_RELEASE2
> +#define PVCALLS_BIND   3
> +#define PVCALLS_LISTEN 4
> +#define PVCALLS_ACCEPT 5
> +#define PVCALLS_POLL   6
> +
> +struct xen_pvcalls_request {
> +uint32_t req_id; /* private to guest, echoed in response */
> +uint32_t cmd;/* command to execute */
> +union {
> +struct xen_pvcalls_socket {
> +uint64_t id;
> +uint32_t domain;
> +uint32_t type;
> +uint32_t protocol;
> +} socket;
> +struct xen_pvcalls_connect {
> +uint64_t id;
> +uint8_t addr[28];
> +uint32_t len;
> +uint32_t flags;
> +grant_ref_t ref;
> +uint32_t evtchn;
> +} connect;
> +struct xen_pvcalls_release {
> +uint64_t id;
> +uint8_t reuse;
> +} release;
> +struct xen_pvcalls_bind {
> +uint64_t id;
> +uint8_t addr[28];
> +uint32_t len;
> +} bind;
> +struct xen_pvcalls_listen {
> +uint64_t id;
> +uint32_t backlog;
> +} listen;
> +struct xen_pvcalls_accept {
> +uint64_t id;
> +uint64_t id_new;
> +grant_ref_t ref;
> +uint32_t evtchn;
> +} accept;
> +struct xen_pvcalls_poll {
> +

Re: [Xen-devel] [PATCH v8 3/4] Introduce the Xen 9pfs transport header

[Konrad Rzeszutek Wilk]

On Fri, Mar 31, 2017 at 12:15:18PM -0700, Stefano Stabellini wrote:
> Define the ring according to the protocol specification, using the new
> DEFINE_XEN_FLEX_RING_AND_INTF macro.
> 
> Add the header to the C99 check.
> 
> Signed-off-by: Stefano Stabellini 
> CC: jbeul...@suse.com
> CC: konrad.w...@oracle.com

Reviewed-by: Konrad Rzeszutek Wilk 

> ---
>  xen/include/Makefile |  4 +++-
>  xen/include/public/io/9pfs.h | 49 
> 
>  2 files changed, 52 insertions(+), 1 deletion(-)
>  create mode 100644 xen/include/public/io/9pfs.h
> 
> diff --git a/xen/include/Makefile b/xen/include/Makefile
> index fd57ce4..a241444 100644
> --- a/xen/include/Makefile
> +++ b/xen/include/Makefile
> @@ -94,9 +94,11 @@ all: headers.chk headers99.chk headers++.chk
>  
>  PUBLIC_HEADERS := $(filter-out public/arch-% public/dom0_ops.h, $(wildcard 
> public/*.h public/*/*.h) $(public-y))
>  
> -PUBLIC_C99_HEADERS :=
> +PUBLIC_C99_HEADERS := public/io/9pfs.h
>  PUBLIC_ANSI_HEADERS := $(filter-out public/%ctl.h public/xsm/% 
> public/%hvm/save.h $(PUBLIC_C99_HEADERS), $(PUBLIC_HEADERS))
>  
> +public/io/9pfs.h-prereq := string
> +
>  headers.chk: $(PUBLIC_ANSI_HEADERS) Makefile
>   for i in $(filter %.h,$^); do \
>   $(CC) -x c -ansi -Wall -Werror -include stdint.h \
> diff --git a/xen/include/public/io/9pfs.h b/xen/include/public/io/9pfs.h
> new file mode 100644
> index 000..4bfd5d4
> --- /dev/null
> +++ b/xen/include/public/io/9pfs.h
> @@ -0,0 +1,49 @@
> +/*
> + * 9pfs.h -- Xen 9PFS transport
> + *
> + * Refer to docs/misc/9pfs.markdown for the specification
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a 
> copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, 
> and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 
> THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + * Copyright (C) 2017 Stefano Stabellini 
> + */
> +
> +#ifndef __XEN_PUBLIC_IO_9PFS_H__
> +#define __XEN_PUBLIC_IO_9PFS_H__
> +
> +#include "../grant_table.h"
> +#include "ring.h"
> +
> +/*
> + * See docs/misc/9pfs.markdown in xen.git for the full specification:
> + * https://xenbits.xen.org/docs/unstable/misc/9pfs.html
> + */
> +DEFINE_XEN_FLEX_RING_AND_INTF(xen_9pfs);
> +
> +#endif
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH v8 1/4] ring.h: introduce macros to handle monodirectional rings with multiple req sizes

[Konrad Rzeszutek Wilk]

On Fri, Mar 31, 2017 at 12:15:16PM -0700, Stefano Stabellini wrote:
> This patch introduces macros, structs and functions to handle rings in
> the format described by docs/misc/pvcalls.markdown and
> docs/misc/9pfs.markdown. The index page (struct __name##_data_intf)
> contains the indexes and the grant refs to setup two rings.
> 
>Indexes page
>+--+
>|@0 $NAME_data_intf:   |
>|@76: ring_order = 1   |
>|@80: ref[0]+  |
>|@84: ref[1]+  |
>|   |  |
>|   |  |
>+--+
>|
>v (data ring)
>+---+---+
>|  @0->4095: in |
>|  ref[0]   |
>|---|
>|  @4096->8191: out |
>|  ref[1]   |
>+---+
> 
> $NAME_read_packet and $NAME_write_packet are provided to read or write
> any data struct from/to the ring. In pvcalls, they are unused. In xen
> 9pfs, they are used to read or write the 9pfs header. In other protocols
> they could be used to read/write the whole request structure. See
> docs/misc/9pfs.markdown:Ring Usage to learn how to check how much data
> is on the ring, and how to handle notifications.
> 
> There is a ring_size parameter to most functions so that protocols using
> these macros don't have to have a statically defined ring order at build
> time. In pvcalls for example, each new ring could have a different
> order.
> 
> These macros don't help you share the indexes page or the event channels
> needed for notifications. You can do that with other out of band
> mechanisms, such as xenstore or another ring.
> 
> It is not possible to use a macro to define another macro with a
> variable name. For this reason, this patch introduces static inline
> functions instead, that are not C89 compliant. Additionally, the macro
> defines a struct with a variable sized array, which is also not C89
> compliant.
> 
> Signed-off-by: Stefano Stabellini 
> CC: konrad.w...@oracle.com
> CC: jbeul...@suse.com
> ---
>  xen/include/public/io/ring.h | 151 
> +++
>  1 file changed, 151 insertions(+)
> 
> diff --git a/xen/include/public/io/ring.h b/xen/include/public/io/ring.h
> index 801c0da..7b7794c 100644
> --- a/xen/include/public/io/ring.h
> +++ b/xen/include/public/io/ring.h
> @@ -27,6 +27,21 @@
>  #ifndef __XEN_PUBLIC_IO_RING_H__
>  #define __XEN_PUBLIC_IO_RING_H__
>  
> +/*
> + * When #include'ing this header, you need to provide the following
> + * declaration upfront:
> + * - standard integers types (uint8_t, uint16_t, etc)
> + * They are provided by stdint.h of the standard headers.
> + *
> + * In addition, if you intend to use the FLEX macros, you also need to
> + * provide the following, before invoking the FLEX macros:
> + * - size_t
> + * - memcpy
> + * - grant_ref_t
> + * These declarations are provided by string.h of the standard headers,
> + * and grant_table.h from the Xen public headers.
> + */
> +
>  #include "../xen-compat.h"
>  
>  #if __XEN_INTERFACE_VERSION__ < 0x00030208
> @@ -313,6 +328,142 @@ typedef struct __name##_back_ring __name##_back_ring_t
>  (_work_to_do) = RING_HAS_UNCONSUMED_RESPONSES(_r);  \
>  } while (0)
>  
> +
> +/*
> + * DEFINE_XEN_FLEX_RING_AND_INTF defines two monodirectional rings and
> + * functions to check if there is data on the ring, and to read and
> + * write to them.
> + *
> + * DEFINE_XEN_FLEX_RING is similar to DEFINE_XEN_FLEX_RING_AND_INTF, but
> + * does not define the indexes page. As different protocols can have
> + * extensions to the basic format, this macro allow them to define their
> + * own struct.
> + *
> + * XEN_FLEX_RING_SIZE
> + *   Convenience macro to calculate the size of one of the two rings
> + *   from the overall order.
> + *
> + * $NAME_mask
> + *   Function to apply the size mask to an index, to reduce the index
> + *   within the range [0-size].
> + *
> + * $NAME_read_packet
> + *   Function to read data from the ring. The amount of data to read is
> + *   specified by the "size" argument.
> + *
> + * $NAME_write_packet
> + *   Function to write data to the ring. The amount of data to write is
> + *   specified by the "size" argument.
> + *
> + * $NAME_get_ring_ptr
> + *   Convenience function that returns a pointer to read/write to the
> + *   ring at the right location.
> + *
> + * $NAME_data_intf
> + *   Indexes page, shared between frontend and backend. It also
> + *   contains the array of grant refs.
> + *
> + * $NAME_queued
> + *   Function to calculate how many bytes are currently on the ring,
> + *   ready to be read. It can also be used to calculate how much free
> + *   space is currently 

Re: [Xen-devel] [PATCH v2] xen, kdump: handle pv domain in paddr_vmcoreinfo_note()

[Daniel Kiper]

> On 03/04/17 14:42, Daniel Kiper wrote:
> > On Fri, Mar 31, 2017 at 12:14:38PM +0200, Juergen Gross wrote:
> >> For kdump to work correctly it needs the physical address of
> >> vmcoreinfo_note. When running as dom0 this means the virtual address
> >> has to be translated to the related machine address.
> >>
> >> paddr_vmcoreinfo_note() is meant to do the translation via
> >> __pa_symbol() only, but being attributed "weak" it can be replaced
> >> easily in Xen case.
> >>
> >> Signed-off-by: Juergen Gross 
> >
> > Have you tested this patch with latest crash tool? Do dom0 and Xen
> > hypervisor analysis work without any issue (at least basic commands
> > like dmesg, bt, ps, etc.)? If yes for both you can add:
> >
> > Reviewed-by: Daniel Kiper 
>
> This patch isn't for dump analysis, but for dump creation. Petr has

I know that. However, it may have impact on crash analysis. So,
I would expect that you or anybody else in your behalf will do
at least minimal crash tool tests.

> verified that the dump is in the expected format. Please ask Petr
> for further details, e.g. user side modifications being necessary.

So, if Petr did relevant tests that is nice. However, then, IMO, this
patch begs Petr Tested-by.

Daniel

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

Re: [Xen-devel] [PATCH v4] displif: add ABI for para-virtual display

[Konrad Rzeszutek Wilk]

Hey!

I only had minor comments - and if you are OK with them I can also
put them in the patch when checking them in (or if you want you can
repost it right away and I will check in the new version).

> 
> ---
> Changes since v3:
>  * add clarification on buffer's size/depth/format and
>connector's resolution
>  * move be_alloc feature into domain's configuration
>to allow more use-cases and freedom (e.g. for 1:1
>mapped domains there may be no need to request backend
>to allocate buffers, while for the rest it may make more
>sense)
>  * rename XenStore entries:
>  ctrl-ring-ref -> req-ring-ref
>  ctrl-channel -> req-event-channel
>  event-ring-ref -> evt-ring-ref
>  event-channel -> evt-event-channel
>  * have 2 separate sections for req/resp and evt transport
>parameters
>  * fix and extend recovery flow description
>  * reserve request codes for future fbif integration if need be
>(request codes [0; 15] are reserved)
>  * error on attempt to create multiple buffers with same cookie(s)
>  * clarification of page directory usage for be_alloc feature
>  * add editor's block
> 
> Changes since v2:
>  * updated XenStore configuration template/pattern
>  * added "Recovery flow" to state diagram description
>  * renamed gref_directory_start to gref_directory
>  * added missing "versions" and "version" string constants
> 
> Changes since v1:
>  * fixed xendispl_event_page padding size
>  * added versioning support
>  * explicitly define value types for XenStore fields
>  * text decoration re-work
>  * added offsets to ASCII box notation
> 
> Changes since initial:
>  * DRM changed to DISPL, protocol made generic
>  * major re-work addressing issues raised for sndif
> 
> Signed-off-by: Oleksandr Grytsov 
> Signed-off-by: Oleksandr Andrushchenko 
> ---
>  xen/include/public/io/displif.h | 847 
> 
>  1 file changed, 847 insertions(+)
>  create mode 100644 xen/include/public/io/displif.h
> 
> diff --git a/xen/include/public/io/displif.h b/xen/include/public/io/displif.h
> new file mode 100644
> index ..ac55c4fe8bbe
> --- /dev/null
> +++ b/xen/include/public/io/displif.h
> @@ -0,0 +1,847 @@
> +/**
> + * displif.h
> + *
> + * Unified display device I/O interface for Xen guest OSes.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a 
> copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, 
> and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 
> THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + * Copyright (C) 2016-2017 EPAM Systems Inc.
> + *
> + * Authors: Oleksandr Andrushchenko 
> + *  Oleksandr Grytsov 
> + */
> +
> +#ifndef __XEN_PUBLIC_IO_DISPLIF_H__
> +#define __XEN_PUBLIC_IO_DISPLIF_H__
> +
> +#include "ring.h"
> +#include "../grant_table.h"
> +
> +/*
> + 
> **
> + *  Main features provided by the protocol
> + 
> **
> + * This protocol aims to provide a unified protocol which fits more
> + * sophisticated use-cases than a framebuffer device can handle. At the
> + * moment basic functionality is supported with the intention to be extended:
> + *  o multiple dynamically allocated/destroyed framebuffers
> + *  o buffers of arbitrary sizes
> + *  o buffer allocation at either back or front end
> + *  o better configuration options including multiple display support
> + *
> + * Note: existing fbif can be used together with displif running at the
> + * same time, e.g. on Linux one provides framebuffer and another DRM/KMS
> + *
> + * Note: display resolution (XenStore's "resolution" property) defines
> + * visible area of the virtual display. At the same time resolution of
> + * the display and frame buffers may differ: buffers can be 

Re: [Xen-devel] ARM:Booting xen on pine64 board

[Andre Przywara]

Hi,

On 04/04/17 20:02, Stefano Stabellini wrote:
> Also CC'ing Andre that I think has a pine64.
> 
> On Tue, 4 Apr 2017, Stefano Stabellini wrote:
>> On Sat, 1 Apr 2017, bharat gohil wrote:
>>> Hello
>>
>> Hello Bharat, thanks for your email.
>>
>>
>>> I am trying to boot xen(debug build) on pine64 ARM64 based board but its 
>>> hangs at following position,
>>>
>>> - UART enabled -
>>> - CPU  booting -
>>> - Current EL 0008 -
>>> - Xen starting at EL2 -
>>> - Zero BSS -
>>> - Setting up control registers -
>>> - Turning on paging -
>>> - Ready -
>>> (XEN) Checking for initrd in /chosen
>>> (XEN) RAM: 4100 - 7fff
>>> (XEN)
>>> (XEN) MODULE[0]: 7e20 - 7e202000 Device Tree
>>> (XEN) MODULE[1]: 7e40 - 7ef46a00 Kernel   
>>> console=hvc0 ro root=/dev/mmcblk0p2 clk_ignore_unused rootwait
>>> (XEN)  RESVD[0]: 7e20 - 7e202000
>>> (XEN)
>>> (XEN) Command line: dtuart=serial0 earlyprint loglvl=all conswitch=x 
>>> dom0_mem=128M
>>> (XEN) Placing Xen at 0x7fc0-0x7fe0
>>> (XEN) Update BOOTMOD_XEN from 7fe0-7fefad81 => 
>>> 7fc0-7fcfad81
>>> (XEN) Booting using Device Tree
>>> (XEN) Domain heap initialised
>>> (XEN) Platform: Generic System
>>> (XEN) Looking for dtuart at "serial0", options ""
>>>  Xen 4.9-unstable
>>> (XEN) Xen version 4.9-unstable (bgohil@) (aarch64-linux-gnu-gcc (Linaro GCC 
>>> 6.2-2016.11) 6.2.1 20161016) debug=n  Tue Mar 28 16:12:32 IST 2017
>>> (XEN) Latest ChangeSet: Fri Mar 24 14:19:47 2017 +0100 git:5b08f85
>>> (XEN) Processor: 410fd034: "ARM Limited", variant: 0x0, part 0xd03, rev 0x4
>>> (XEN) 64-bit Execution:
>>> (XEN)   Processor Features:  
>>> (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
>>> (XEN) Extensions: FloatingPoint AdvancedSIMD
>>> (XEN)   Debug Features: 10305106 
>>> (XEN)   Auxiliary Features:  
>>> (XEN)   Memory Model Features: 1122 
>>> (XEN)   ISA Features:  00011120 
>>> (XEN) 32-bit Execution:
>>> (XEN)   Processor Features: 0131:00011011
>>> (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
>>> (XEN) Extensions: GenericTimer Security
>>> (XEN)   Debug Features: 03010066
>>> (XEN)   Auxiliary Features: 
>>> (XEN)   Memory Model Features: 10201105 4000 0126 02102211
>>> (XEN)  ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121
>>> (XEN) Using PSCI-0.2 for SMP bringup
>>> (XEN) SMP: Allowing 4 CPUs
>>> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 24000 KHz
>>> (XEN) GICv2 initialization:
>>> (XEN) gic_dist_addr=01c81000
>>> (XEN) gic_cpu_addr=01c82000
>>> (XEN) gic_hyp_addr=01c84000
>>> (XEN) gic_vcpu_addr=01c86000
>>> (XEN) gic_maintenance_irq=25
>>> (XEN) GICv2: 224 lines, 4 cpus, secure (IID 0200143b).
>>> (XEN) Using scheduler: SMP Credit Scheduler (credit)
>>>
>>> but when I boot dtuart= say duart=xyz instead of 
>>> dtuart=serial0, xen booted successfully but Dom0 crash while probing 
>>> 'serial0' driver. 
>>>
>>> If I remove 'serial0' node from device tree, Dom0 boot successfully but 
>>> unable to enter input into 'hvc' console. 
>>>
>>> what could be wrong here or missing something?
>>
>> What is your dom0 command line? Are you passing console=hvc0?
>>
>> It looks like pine64 is using an allwinner sun50i-uart, for which we
>> don't have a proper driver in Xen yet. That is probably the reason why
>> you can see some output from Xen, but you cannot type anything in later
>> in Dom0 (which is sent to Xen via the HVC console).  Please send a patch
>> to add a simple sun50i-uart driver (see xen/drivers/char/). Given that
>> both Xen and Linux are GPLv2, you can import code from Linux if you find
>> it appropriate.

The UART is exactly the same as in the other Allwinner SoCs, so there is
no need for a new UART driver.
Another issue inherited from the 32-bit Allwinner chips is that the
first four UARTs share a page, so they have to be blacklisted, as Xen
can't properly separate them.
You might want to look at xen/arch/arm/platforms/sunxi.c. Not sure if
this needs to be tied in arm64 somehow.

HTH,
Cheers,
Andre.

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

Re: [Xen-devel] Legacy PCI interrupt {de}assertion count

[Sander Eikelenboom]

On 04/04/17 18:07, Konrad Rzeszutek Wilk wrote:
> On Mon, Apr 03, 2017 at 02:22:36PM +0200, Sander Eikelenboom wrote:
>> On 31/03/17 16:38, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Mar 31, 2017 at 04:46:27AM -0600, Jan Beulich wrote:
>>> On 31.03.17 at 10:07,  wrote:
> On Fri, Mar 31, 2017 at 05:05:44AM +, Tian, Kevin wrote:
>>> From: Jan Beulich [mailto:jbeul...@suse.com]
>>> Sent: Monday, March 27, 2017 4:00 PM
>>>
>> On 24.03.17 at 17:54,  wrote:
 As I understand it, for level triggered legacy PCI interrupts Xen sets
 up a timer in order to perform the EOI if the guest takes too long in
 deasserting the line. This is done in pt_irq_time_out. What I don't
 understand is why this function also does a deassertion of the guest 
 view
>>> of the PCI interrupt, ie:
 why it calls hvm_pci_intx_deassert. This AFAICT will clear the pending
 assert in the guest, and thus the guest will end up loosing one 
 interrupt.
>>>
>>> Especially with the comment next to the respective set_timer() it looks 
>>> to me
>>> as if this was the intended effect: If the guest didn't care to at 
>>> least start
>>> handling the interrupt within PT_IRQ_TIME_OUT, we want it look to be 
>>> lost in
>>> order to not have it block other interrupts inside the guest (i.e. 
>>> there's more
>>> to it than just guarding the host here).
>>>
>>> "Luckily" commit 0f843ba00c ("vt-d: Allow pass-through of shared
>>> interrupts") introducing this has no description at all. Let's see if 
>>> Kevin
>>> remembers any further details ...
>>>
>>
>> Sorry I don't remember more detail other than existing comments.
>> Roger, did you encounter a problem now?
>
> No, I didn't encounter any problems with this so far, any well behaved 
> guest
> will deassert those lines anyway, it just seems to be against the spec.  
> AFAIK
> on bare metal the line will be asserted until the OS deasserts it, so I 
> was
> wondering if this was some kind of workaround?

 "OS deasserts" is a term I don't understand. Aiui it's the origin device
 which would need to de-assert its interrupt, and I think it is not
 uncommon for devices to de-assert interrupts after a certain amount
 of time. If that wasn't the case, spurious interrupts could never occur.
>>>
>>> I recall Sander (CC-ed) here hitting this at some point. There was some 
>>> device
>>> he had (legacy?) that would very much hit this path.
>>>
>>> But I can't recall the details, sorry.
>>>
>>> Sanders, it was in the context of the dpci softirq work I did if that helps.
>>
>> Hi Konrad,
>>
>> You mean these ?
> 
> Yes, but I can't seem to find in those threads the name of the
> device you had - the one that was triggering those legacy
> interrupts.. By any chance you recall what it was?

From your analysis here: 
https://lists.xenproject.org/archives/html/xen-devel/2014-11/msg01550.html
It's the "Multimedia video controller: Conexant Systems, Inc. Device 8210" 
which is a DVR videograbber.

Since it is still in my system, if you need some patches tested with that 
hardware, i could give them a spin!

lspci:

0d:00.0 Multimedia video controller [0400]: Conexant Systems, Inc. Device 
[14f1:8210]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
VC0:Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb:Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
VC1:Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb:Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl:   Enable- ID=1 ArbSelect=Fixed TC/VC=00
Status: NegoPending- InProgress-
Kernel driver in use: pciback


--
Sander

>>
>> The issue leading up to this revert for xen-4.5: 
>> https://lists.xen.org/archives/html/xen-devel/2015-01/msg01025.html
>>
>> Where this seems to be the thread that started the conversation leading up 
>> to that revert: 
>> https://lists.xenproject.org/archives/html/xen-devel/2014-11/msg01330.html
>>
>> Which than for xen-4.6 continued in a thread with the subject "dpci: Put the 
>> dpci back on the list if scheduled from another CPU."
>> which is spread out over several months, (this is somewhere in between 
>> https://lists.xenproject.org/archives/html/xen-devel/2015-03/msg02102.html ).
>>
>> --
>> Sander
>>

 Jan


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

[Xen-devel] [PATCH v2 4/5] tmem: Fix tmem-shared-auth 'auth' values

[Konrad Rzeszutek Wilk]

The hypervisor code (tmemc_shared_pool_auth) since the inception
would consider auth values of:
 0 - to disable authentication!
 1 - to enable authentication for the given UUID.

The docs have it the other way around, so lets fix it.

Acked-by: Wei Liu 
Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Ian Jackson 
Cc: Wei Liu 
--
v2: Added Wei's Ack.
---
 tools/xl/xl_cmdtable.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
index 7d97811..30eb93c 100644
--- a/tools/xl/xl_cmdtable.c
+++ b/tools/xl/xl_cmdtable.c
@@ -416,7 +416,7 @@ struct cmd_spec cmd_table[] = {
   "  -a Authenticate for all tmem pools\n"
   "  -u UUIDSpecify uuid\n"
   " 
(abcdef01-2345-6789-1234-567890abcdef)\n"
-  "  -A AUTH0=auth,1=deauth",
+  "  -A AUTH0=deauth,1=auth",
 },
 { "tmem-freeable",
   _tmem_freeable, 0, 0,
-- 
2.9.3


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

[Xen-devel] [PATCH v2 5/5] tmem: Parse UUIDs correctly.

[Konrad Rzeszutek Wilk]

A simple
xl tmem-shared-auth -u --000A--0001 -A 0 0

resulted in uuid_low = 1 (correct) and uuid_high = 0 (umm?).

The issue was that for hex values above 'A' (or 'a') we forgot
to add 10.

Acked-by: Wei Liu 
Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Ian Jackson 
Cc: Wei Liu 

v2:
 - Added Wei's Ack.
---
 tools/libxc/xc_tmem.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libxc/xc_tmem.c b/tools/libxc/xc_tmem.c
index 5f5e18f..9bf5cc3 100644
--- a/tools/libxc/xc_tmem.c
+++ b/tools/libxc/xc_tmem.c
@@ -138,9 +138,9 @@ static int xc_tmem_uuid_parse(char *uuid_str, uint64_t 
*uuid_lo, uint64_t *uuid_
 else if ( *p >= '0' && *p <= '9' )
 digit = *p - '0';
 else if ( *p >= 'A' && *p <= 'F' )
-digit = *p - 'A';
+digit = *p - 'A' + 10;
 else if ( *p >= 'a' && *p <= 'f' )
-digit = *p - 'a';
+digit = *p - 'a' + 10;
 else
 return -1;
 *x = (*x << 4) | digit;
-- 
2.9.3


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

[Xen-devel] [PATCH v2 1/5] xen/libcx/tmem: Replace TMEM_RESTORE_NEW with XEN_SYSCTL_TMEM_OP_SET_POOLS

[Konrad Rzeszutek Wilk]

This used to be done under TMEM_RESTORE_NEW which was an hypercall
accessible by the guest. However there are couple of reasons
not to do it:
 - No checking of domid on TMEM_RESTORE_NEW which meant that
   any guest could create TMEM pools for other guests.
 - The guest can already create pools using TMEM_NEW_POOL
   (which is limited to guest doing the hypercall)
 - This functionality is only needed during migration - there
   is no need for the guest to have this functionality.

However to move this we also have to allocate the 'struct domain'
->tmem pointer. It is by default set to NULL and would be initialized
via the guest do_tmem() hypercalls. Presumarily that was the
initial reason that TMEM_RESTORE_NEW was in the guest accessible
hypercalls.

Acked-by: Wei Liu  [libxc change] [libxc change] [libxc 
change] [libxc change]
Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Ian Jackson 
Cc: Wei Liu 

v1: First version.

v2: Added Wei's Ack.
  - Used 'switch' in do_tmem_op.
  - Dropped 'idx' in tmemc_set_pools.
  - Update comment in sysctl.h about xen_tmem_pool_info_t structure.
---
 tools/libxc/xc_tmem.c  | 22 +-
 xen/common/tmem.c  | 30 -
 xen/common/tmem_control.c  | 51 ++
 xen/include/public/sysctl.h| 11 ++---
 xen/include/public/tmem.h  |  5 +++--
 xen/include/xen/tmem_control.h |  4 
 xen/include/xen/tmem_xen.h |  1 -
 7 files changed, 93 insertions(+), 31 deletions(-)

diff --git a/tools/libxc/xc_tmem.c b/tools/libxc/xc_tmem.c
index 51d11ef..181de48 100644
--- a/tools/libxc/xc_tmem.c
+++ b/tools/libxc/xc_tmem.c
@@ -385,16 +385,18 @@ static int xc_tmem_restore_new_pool(
 uint64_t uuid_lo,
 uint64_t uuid_hi)
 {
-tmem_op_t op;
-
-op.cmd = TMEM_RESTORE_NEW;
-op.pool_id = pool_id;
-op.u.creat.arg1 = cli_id;
-op.u.creat.flags = flags;
-op.u.creat.uuid[0] = uuid_lo;
-op.u.creat.uuid[1] = uuid_hi;
-
-return do_tmem_op(xch, );
+xen_tmem_pool_info_t pool = {
+.flags.raw = flags,
+.id = pool_id,
+.n_pages = 0,
+.uuid[0] = uuid_lo,
+.uuid[1] = uuid_hi,
+};
+
+return xc_tmem_control(xch, pool_id,
+   XEN_SYSCTL_TMEM_OP_SET_POOLS,
+   cli_id, sizeof(pool),
+   0 /* arg */, );
 }
 
 int xc_tmem_restore(xc_interface *xch, int dom, int io_fd)
diff --git a/xen/common/tmem.c b/xen/common/tmem.c
index 6d5de5b..ee43f13 100644
--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -804,7 +804,7 @@ static void pool_flush(struct tmem_pool *pool, domid_t 
cli_id)
 
 / CLIENT MANIPULATION OPERATIONS **/
 
-static struct client *client_create(domid_t cli_id)
+struct client *client_create(domid_t cli_id)
 {
 struct client *client = xzalloc(struct client);
 int i, shift;
@@ -1435,9 +1435,9 @@ static int do_tmem_destroy_pool(uint32_t pool_id)
 return 1;
 }
 
-static int do_tmem_new_pool(domid_t this_cli_id,
- uint32_t d_poolid, uint32_t flags,
- uint64_t uuid_lo, uint64_t uuid_hi)
+int do_tmem_new_pool(domid_t this_cli_id,
+ uint32_t d_poolid, uint32_t flags,
+ uint64_t uuid_lo, uint64_t uuid_hi)
 {
 struct client *client;
 domid_t cli_id;
@@ -1908,21 +1908,19 @@ long do_tmem_op(tmem_cli_op_t uops)
 /* Acquire write lock for all commands at first. */
 write_lock(_rwlock);
 
-if ( op.cmd == TMEM_CONTROL )
+switch ( op.cmd )
 {
+case TMEM_CONTROL:
+case TMEM_RESTORE_NEW:
 rc = -EOPNOTSUPP;
-}
-else if ( op.cmd == TMEM_AUTH )
-{
+break;
+
+case TMEM_AUTH:
 rc = tmemc_shared_pool_auth(op.u.creat.arg1,op.u.creat.uuid[0],
  op.u.creat.uuid[1],op.u.creat.flags);
-}
-else if ( op.cmd == TMEM_RESTORE_NEW )
-{
-rc = do_tmem_new_pool(op.u.creat.arg1, op.pool_id, op.u.creat.flags,
- op.u.creat.uuid[0], op.u.creat.uuid[1]);
-}
-else {
+break;
+
+default:
 /*
 * For other commands, create per-client tmem structure dynamically on
 * first use by client.
@@ -1999,6 +1997,8 @@ long do_tmem_op(tmem_cli_op_t uops)
 tmem_stats.errored_tmem_ops++;
 return rc;
 }
+break;
+
 }
 out:
 write_unlock(_rwlock);
diff --git a/xen/common/tmem_control.c b/xen/common/tmem_control.c
index ddd9cfe..3e99257 100644
--- a/xen/common/tmem_control.c
+++ b/xen/common/tmem_control.c
@@ -402,6 +402,54 @@ static int tmemc_get_pool(int cli_id,
 return rc ? : idx;
 }
 
+static int tmemc_set_pools(int cli_id,
+   XEN_GUEST_HANDLE(xen_tmem_pool_info_t) 

[Xen-devel] [PATCH v2 2/5] xen/libxc: Move TMEM_AUTH to XEN_SYSCTL_TMEM_OP_SET_AUTH

[Konrad Rzeszutek Wilk]

which surprisingly (or maybe not) looks like
XEN_SYSCTL_TMEM_OP_SET_POOLS.

This hypercall came about, as explained in docs/misc/tmem-internals.html:

When tmem was first proposed to the linux kernel mailing list
(LKML), there was concern expressed about security of shared ephemeral
pools.  The initial tmem implementation only
required a client to provide a 128-bit UUID to identify a shared pool, and the
linux-side tmem implementation obtained this UUID from the superblock of the
shared filesystem (in ocfs2).  It was
pointed out on LKML that the UUID was essentially a security key and any
malicious domain that guessed it would have access to any data from the shared
filesystem that found its way into tmem.
..
As a result, a Xen boot option -- tmem_shared_auth; -- was
added.  The option defaults to disabled,
but when it is enabled, management tools must explicitly authenticate (or may
explicitly deny) shared pool access to any client.
On Xen, this is done with the xm tmem-shared-auth command.
"

However the implementation has some rather large holes:

a) The hypercall was accessed from any guest.

b) If the ->domain id value is 0x then one can toggle the
   tmem_global.shared_auth knob on/off. That with a)
   made it pretty bad.

c) If one toggles the tmem_global.shared_auth off, then the
  'tmem_shared_auth=1' bootup parameter is ignored and
   one can join any shared pool (if UUID is known)!

d) If the 'tmem_shared_auth=1' and tmem_global.shared_auth is
  set to 1, then one can only join an shared pool if the
  UUID has been set by 'xl tmem-shared-auth'. Otherwise
  the joining of a pool fails and a non-shared pool is
  created (without errors to guest). Not exactly sure if
  the shared pool creation at that point should error out
  or not.

e) If a guest is migrated, the policy values (which UUID
  can be shared, whether tmem_global.shared_auth is set, etc)
  are completely ignored.

This patch only fixes a) and only allows the hypercall to
be called by the control domain. Subsequent patches will
fix the remaining issues.

We also have to call client_create as the guest at this
point may not have done any tmem hypercalls - and hence
the '->tmem' from 'struct domain' is still NULL. Us calling
client_create fixes this.

Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Ian Jackson 
Cc: Wei Liu 

v1: First posting
v2: Drop 'idx' in tmemc_auth_pools
Check for 'n_pages' in tmemc_auth_pools.
Update comment for xen_tmem_pool_info_t.
---
 tools/libxc/include/xenctrl.h  |  2 +-
 tools/libxc/xc_tmem.c  | 52 +-
 xen/common/tmem.c  | 10 +++-
 xen/common/tmem_control.c  | 50 
 xen/include/public/sysctl.h| 12 ++
 xen/include/public/tmem.h  |  9 
 xen/include/xen/tmem_control.h |  2 ++
 xen/include/xen/tmem_xen.h |  1 -
 8 files changed, 83 insertions(+), 55 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 2d97d36..e2b4cc1 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1901,7 +1901,7 @@ int xc_tmem_control_oid(xc_interface *xch, int32_t 
pool_id, uint32_t subop,
 int xc_tmem_control(xc_interface *xch,
 int32_t pool_id, uint32_t subop, uint32_t cli_id,
 uint32_t len, uint32_t arg, void *buf);
-int xc_tmem_auth(xc_interface *xch, int cli_id, char *uuid_str, int arg1);
+int xc_tmem_auth(xc_interface *xch, int cli_id, char *uuid_str, int enable);
 int xc_tmem_save(xc_interface *xch, int dom, int live, int fd, int 
field_marker);
 int xc_tmem_save_extra(xc_interface *xch, int dom, int fd, int field_marker);
 void xc_tmem_save_done(xc_interface *xch, int dom);
diff --git a/tools/libxc/xc_tmem.c b/tools/libxc/xc_tmem.c
index 181de48..5f5e18f 100644
--- a/tools/libxc/xc_tmem.c
+++ b/tools/libxc/xc_tmem.c
@@ -22,30 +22,6 @@
 #include 
 #include 
 
-static int do_tmem_op(xc_interface *xch, tmem_op_t *op)
-{
-int ret;
-DECLARE_HYPERCALL_BOUNCE(op, sizeof(*op), XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
-
-if ( xc_hypercall_bounce_pre(xch, op) )
-{
-PERROR("Could not bounce buffer for tmem op hypercall");
-return -EFAULT;
-}
-
-ret = xencall1(xch->xcall, __HYPERVISOR_tmem_op,
-   HYPERCALL_BUFFER_AS_ARG(op));
-if ( ret < 0 )
-{
-if ( errno == EACCES )
-DPRINTF("tmem operation failed -- need to"
-" rebuild the user-space tool set?\n");
-}
-xc_hypercall_bounce_post(xch, op);
-
-return ret;
-}
-
 int xc_tmem_control(xc_interface *xch,
 int32_t pool_id,
 uint32_t cmd,
@@ -69,7 +45,8 @@ int xc_tmem_control(xc_interface *xch,
 sysctl.u.tmem_op.oid.oid[1] = 0;
 sysctl.u.tmem_op.oid.oid[2] = 0;
 
-if ( cmd == XEN_SYSCTL_TMEM_OP_SET_CLIENT_INFO )
+   

[Xen-devel] [PATCH v2] Tmem fixes for v4.9.

[Konrad Rzeszutek Wilk]

Hey!

Since v1:
 - Added Acks
 - Fixed hypervisor patches per Jan's review.

Please see the attached patches. I had hoped that I would have the
initial migrationv2 patches ready but other things preempted me .

This patchset moves two sub-ops (TMEM_RESTORE_NEW, TMEM_AUTH)
from the guest accessible one to the system admin controlled.

It made no sense to have them there in the guest one, and worst
it has some security implications (a hostile guest could join
another shared pool without any authorization) - but since XSA-7
the tmem code is not yet out of "experimental" which means we can
treat these fixes without worrying about security aspects.

Pls see the diff stat, shortlog and also the full diff for easier
review.


 docs/misc/tmem-internals.html   |   6 +--
 docs/misc/xen-command-line.markdown |   3 --
 tools/libxc/include/xenctrl.h   |   2 +-
 tools/libxc/xc_tmem.c   |  78 +++-
 tools/xl/xl_cmdtable.c  |   2 +-
 xen/common/tmem.c   |  38 ++
 xen/common/tmem_control.c   | 101 
 xen/common/tmem_xen.c   |   3 --
 xen/include/public/sysctl.h |  15 --
 xen/include/public/tmem.h   |   8 +--
 xen/include/xen/tmem_control.h  |   6 +++
 xen/include/xen/tmem_xen.h  |   9 
 12 files changed, 173 insertions(+), 98 deletions(-)

Konrad Rzeszutek Wilk (5):
  xen/libcx/tmem: Replace TMEM_RESTORE_NEW with XEN_SYSCTL_TMEM_OP_SET_POOLS
  xen/libxc: Move TMEM_AUTH to XEN_SYSCTL_TMEM_OP_SET_AUTH
  tmem: By default to join an shared pool it must be authorized.
  tmem: Fix tmem-shared-auth 'auth' values
  tmem: Parse UUIDs correctly.


diff --git a/docs/misc/tmem-internals.html b/docs/misc/tmem-internals.html
index 2d8635d..9b7e70e 100644
--- a/docs/misc/tmem-internals.html
+++ b/docs/misc/tmem-internals.html
@@ -715,11 +715,9 @@ Ocfs2 has only very limited security; it is assumed that 
anyone who can
 access the filesystem bits on the shared disk can mount the filesystem and use
 it.  But in a virtualized data center,
 higher isolation requirements may apply.
-As a result, a Xen boot option -- tmem_shared_auth -- was
-added.  The option defaults to disabled,
-but when it is enabled, management tools must explicitly authenticate (or may
+As a result, management tools must explicitly authenticate (or may
 explicitly deny) shared pool access to any client.
-On Xen, this is done with the xm
+On Xen, this is done with the xl
 tmem-shared-auth command.
 
 32-bit implementation.
diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 9eb85d6..9690512 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1539,9 +1539,6 @@ pages) must also be specified via the tbuf\_size 
parameter.
 ### tmem\_compress
 > `= `
 
-### tmem\_shared\_auth
-> `= `
-
 ### tsc
 > `= unstable | skewed | stable:socket`
 
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 2d97d36..e2b4cc1 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1901,7 +1901,7 @@ int xc_tmem_control_oid(xc_interface *xch, int32_t 
pool_id, uint32_t subop,
 int xc_tmem_control(xc_interface *xch,
 int32_t pool_id, uint32_t subop, uint32_t cli_id,
 uint32_t len, uint32_t arg, void *buf);
-int xc_tmem_auth(xc_interface *xch, int cli_id, char *uuid_str, int arg1);
+int xc_tmem_auth(xc_interface *xch, int cli_id, char *uuid_str, int enable);
 int xc_tmem_save(xc_interface *xch, int dom, int live, int fd, int 
field_marker);
 int xc_tmem_save_extra(xc_interface *xch, int dom, int fd, int field_marker);
 void xc_tmem_save_done(xc_interface *xch, int dom);
diff --git a/tools/libxc/xc_tmem.c b/tools/libxc/xc_tmem.c
index 51d11ef..9bf5cc3 100644
--- a/tools/libxc/xc_tmem.c
+++ b/tools/libxc/xc_tmem.c
@@ -22,30 +22,6 @@
 #include 
 #include 
 
-static int do_tmem_op(xc_interface *xch, tmem_op_t *op)
-{
-int ret;
-DECLARE_HYPERCALL_BOUNCE(op, sizeof(*op), XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
-
-if ( xc_hypercall_bounce_pre(xch, op) )
-{
-PERROR("Could not bounce buffer for tmem op hypercall");
-return -EFAULT;
-}
-
-ret = xencall1(xch->xcall, __HYPERVISOR_tmem_op,
-   HYPERCALL_BUFFER_AS_ARG(op));
-if ( ret < 0 )
-{
-if ( errno == EACCES )
-DPRINTF("tmem operation failed -- need to"
-" rebuild the user-space tool set?\n");
-}
-xc_hypercall_bounce_post(xch, op);
-
-return ret;
-}
-
 int xc_tmem_control(xc_interface *xch,
 int32_t pool_id,
 uint32_t cmd,
@@ -69,7 +45,8 @@ int xc_tmem_control(xc_interface *xch,
 sysctl.u.tmem_op.oid.oid[1] = 0;
 sysctl.u.tmem_op.oid.oid[2] = 0;
 
-if ( cmd == XEN_SYSCTL_TMEM_OP_SET_CLIENT_INFO )
+if ( cmd == 

[Xen-devel] [PATCH v2 3/5] tmem: By default to join an shared pool it must be authorized.

[Konrad Rzeszutek Wilk]

Having an off by default option allowing guests to join
_any_ shared pool is not very secure.

Lets eliminate tmem_shared_auth bootup option (which
was disabled by default) and have the code force this by default.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 docs/misc/tmem-internals.html   | 6 ++
 docs/misc/xen-command-line.markdown | 3 ---
 xen/common/tmem.c   | 4 ++--
 xen/common/tmem_xen.c   | 3 ---
 xen/include/xen/tmem_xen.h  | 7 ---
 5 files changed, 4 insertions(+), 19 deletions(-)

diff --git a/docs/misc/tmem-internals.html b/docs/misc/tmem-internals.html
index 2d8635d..9b7e70e 100644
--- a/docs/misc/tmem-internals.html
+++ b/docs/misc/tmem-internals.html
@@ -715,11 +715,9 @@ Ocfs2 has only very limited security; it is assumed that 
anyone who can
 access the filesystem bits on the shared disk can mount the filesystem and use
 it.  But in a virtualized data center,
 higher isolation requirements may apply.
-As a result, a Xen boot option -- tmem_shared_auth -- was
-added.  The option defaults to disabled,
-but when it is enabled, management tools must explicitly authenticate (or may
+As a result, management tools must explicitly authenticate (or may
 explicitly deny) shared pool access to any client.
-On Xen, this is done with the xm
+On Xen, this is done with the xl
 tmem-shared-auth command.
 
 32-bit implementation.
diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 9eb85d6..9690512 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1539,9 +1539,6 @@ pages) must also be specified via the tbuf\_size 
parameter.
 ### tmem\_compress
 > `= `
 
-### tmem\_shared\_auth
-> `= `
-
 ### tsc
 > `= unstable | skewed | stable:socket`
 
diff --git a/xen/common/tmem.c b/xen/common/tmem.c
index 158d660..4f77a8c 100644
--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -846,7 +846,6 @@ struct client *client_create(domid_t cli_id)
 client->info.version = TMEM_SPEC_VERSION;
 client->info.maxpools = MAX_POOLS_PER_DOMAIN;
 client->info.flags.u.compress = tmem_compression_enabled();
-client->shared_auth_required = tmem_shared_auth();
 for ( i = 0; i < MAX_GLOBAL_SHARED_POOLS; i++)
 client->shared_auth_uuid[i][0] =
 client->shared_auth_uuid[i][1] = -1L;
@@ -1530,7 +1529,8 @@ int do_tmem_new_pool(domid_t this_cli_id,
 pool->shared = 0;
 goto out;
 }
-if ( client->shared_auth_required && !tmem_global.shared_auth )
+/* By default only join domains that are authorized by admin. */
+if ( !tmem_global.shared_auth )
 {
 for ( i = 0; i < MAX_GLOBAL_SHARED_POOLS; i++)
 if ( (client->shared_auth_uuid[i][0] == uuid_lo) &&
diff --git a/xen/common/tmem_xen.c b/xen/common/tmem_xen.c
index 7d60b71..06ce3ef 100644
--- a/xen/common/tmem_xen.c
+++ b/xen/common/tmem_xen.c
@@ -20,9 +20,6 @@ boolean_param("tmem", opt_tmem);
 bool_t __read_mostly opt_tmem_compress = 0;
 boolean_param("tmem_compress", opt_tmem_compress);
 
-bool_t __read_mostly opt_tmem_shared_auth = 0;
-boolean_param("tmem_shared_auth", opt_tmem_shared_auth);
-
 atomic_t freeable_page_count = ATOMIC_INIT(0);
 
 /* these are a concurrency bottleneck, could be percpu and dynamically
diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h
index 70cc108..dc5888c 100644
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -41,12 +41,6 @@ static inline bool_t tmem_compression_enabled(void)
 return opt_tmem_compress;
 }
 
-extern bool_t opt_tmem_shared_auth;
-static inline bool_t tmem_shared_auth(void)
-{
-return opt_tmem_shared_auth;
-}
-
 #ifdef CONFIG_TMEM
 extern bool_t opt_tmem;
 static inline bool_t tmem_enabled(void)
@@ -291,7 +285,6 @@ struct client {
 long eph_count, eph_count_max;
 domid_t cli_id;
 xen_tmem_client_t info;
-bool_t shared_auth_required;
 /* For save/restore/migration. */
 bool_t was_frozen;
 struct list_head persistent_invalidated_list;
-- 
2.9.3


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

Re: [Xen-devel] [PATCH 2/2] memory: don't hand MFN info to translated guests

[Andrew Cooper]

On 04/04/17 14:14, Jan Beulich wrote:
> We shouldn't hand MFN info back from increase-reservation for
> translated domains, just like we don't for populate-physmap and
> memory-exchange. For full symmetry also check for a NULL guest handle
> in populate_physmap() (but note this makes no sense in
> memory_exchange(), as there the array is also an input).
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] ARM:Booting xen on pine64 board

[Stefano Stabellini]

Also CC'ing Andre that I think has a pine64.

On Tue, 4 Apr 2017, Stefano Stabellini wrote:
> On Sat, 1 Apr 2017, bharat gohil wrote:
> > Hello
> 
> Hello Bharat, thanks for your email.
> 
> 
> > I am trying to boot xen(debug build) on pine64 ARM64 based board but its 
> > hangs at following position,
> > 
> > - UART enabled -
> > - CPU  booting -
> > - Current EL 0008 -
> > - Xen starting at EL2 -
> > - Zero BSS -
> > - Setting up control registers -
> > - Turning on paging -
> > - Ready -
> > (XEN) Checking for initrd in /chosen
> > (XEN) RAM: 4100 - 7fff
> > (XEN)
> > (XEN) MODULE[0]: 7e20 - 7e202000 Device Tree
> > (XEN) MODULE[1]: 7e40 - 7ef46a00 Kernel   
> > console=hvc0 ro root=/dev/mmcblk0p2 clk_ignore_unused rootwait
> > (XEN)  RESVD[0]: 7e20 - 7e202000
> > (XEN)
> > (XEN) Command line: dtuart=serial0 earlyprint loglvl=all conswitch=x 
> > dom0_mem=128M
> > (XEN) Placing Xen at 0x7fc0-0x7fe0
> > (XEN) Update BOOTMOD_XEN from 7fe0-7fefad81 => 
> > 7fc0-7fcfad81
> > (XEN) Booting using Device Tree
> > (XEN) Domain heap initialised
> > (XEN) Platform: Generic System
> > (XEN) Looking for dtuart at "serial0", options ""
> >  Xen 4.9-unstable
> > (XEN) Xen version 4.9-unstable (bgohil@) (aarch64-linux-gnu-gcc (Linaro GCC 
> > 6.2-2016.11) 6.2.1 20161016) debug=n  Tue Mar 28 16:12:32 IST 2017
> > (XEN) Latest ChangeSet: Fri Mar 24 14:19:47 2017 +0100 git:5b08f85
> > (XEN) Processor: 410fd034: "ARM Limited", variant: 0x0, part 0xd03, rev 0x4
> > (XEN) 64-bit Execution:
> > (XEN)   Processor Features:  
> > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
> > (XEN) Extensions: FloatingPoint AdvancedSIMD
> > (XEN)   Debug Features: 10305106 
> > (XEN)   Auxiliary Features:  
> > (XEN)   Memory Model Features: 1122 
> > (XEN)   ISA Features:  00011120 
> > (XEN) 32-bit Execution:
> > (XEN)   Processor Features: 0131:00011011
> > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
> > (XEN) Extensions: GenericTimer Security
> > (XEN)   Debug Features: 03010066
> > (XEN)   Auxiliary Features: 
> > (XEN)   Memory Model Features: 10201105 4000 0126 02102211
> > (XEN)  ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121
> > (XEN) Using PSCI-0.2 for SMP bringup
> > (XEN) SMP: Allowing 4 CPUs
> > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 24000 KHz
> > (XEN) GICv2 initialization:
> > (XEN) gic_dist_addr=01c81000
> > (XEN) gic_cpu_addr=01c82000
> > (XEN) gic_hyp_addr=01c84000
> > (XEN) gic_vcpu_addr=01c86000
> > (XEN) gic_maintenance_irq=25
> > (XEN) GICv2: 224 lines, 4 cpus, secure (IID 0200143b).
> > (XEN) Using scheduler: SMP Credit Scheduler (credit)
> > 
> > but when I boot dtuart= say duart=xyz instead of 
> > dtuart=serial0, xen booted successfully but Dom0 crash while probing 
> > 'serial0' driver. 
> > 
> > If I remove 'serial0' node from device tree, Dom0 boot successfully but 
> > unable to enter input into 'hvc' console. 
> > 
> > what could be wrong here or missing something?
> 
> What is your dom0 command line? Are you passing console=hvc0?
> 
> It looks like pine64 is using an allwinner sun50i-uart, for which we
> don't have a proper driver in Xen yet. That is probably the reason why
> you can see some output from Xen, but you cannot type anything in later
> in Dom0 (which is sent to Xen via the HVC console).  Please send a patch
> to add a simple sun50i-uart driver (see xen/drivers/char/). Given that
> both Xen and Linux are GPLv2, you can import code from Linux if you find
> it appropriate.
> 
> Cheers,
> 
> Stefano___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] ARM:Booting xen on pine64 board

[Stefano Stabellini]

On Sat, 1 Apr 2017, bharat gohil wrote:
> Hello

Hello Bharat, thanks for your email.


> I am trying to boot xen(debug build) on pine64 ARM64 based board but its 
> hangs at following position,
> 
> - UART enabled -
> - CPU  booting -
> - Current EL 0008 -
> - Xen starting at EL2 -
> - Zero BSS -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) Checking for initrd in /chosen
> (XEN) RAM: 4100 - 7fff
> (XEN)
> (XEN) MODULE[0]: 7e20 - 7e202000 Device Tree
> (XEN) MODULE[1]: 7e40 - 7ef46a00 Kernel   
> console=hvc0 ro root=/dev/mmcblk0p2 clk_ignore_unused rootwait
> (XEN)  RESVD[0]: 7e20 - 7e202000
> (XEN)
> (XEN) Command line: dtuart=serial0 earlyprint loglvl=all conswitch=x 
> dom0_mem=128M
> (XEN) Placing Xen at 0x7fc0-0x7fe0
> (XEN) Update BOOTMOD_XEN from 7fe0-7fefad81 => 
> 7fc0-7fcfad81
> (XEN) Booting using Device Tree
> (XEN) Domain heap initialised
> (XEN) Platform: Generic System
> (XEN) Looking for dtuart at "serial0", options ""
>  Xen 4.9-unstable
> (XEN) Xen version 4.9-unstable (bgohil@) (aarch64-linux-gnu-gcc (Linaro GCC 
> 6.2-2016.11) 6.2.1 20161016) debug=n  Tue Mar 28 16:12:32 IST 2017
> (XEN) Latest ChangeSet: Fri Mar 24 14:19:47 2017 +0100 git:5b08f85
> (XEN) Processor: 410fd034: "ARM Limited", variant: 0x0, part 0xd03, rev 0x4
> (XEN) 64-bit Execution:
> (XEN)   Processor Features:  
> (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
> (XEN) Extensions: FloatingPoint AdvancedSIMD
> (XEN)   Debug Features: 10305106 
> (XEN)   Auxiliary Features:  
> (XEN)   Memory Model Features: 1122 
> (XEN)   ISA Features:  00011120 
> (XEN) 32-bit Execution:
> (XEN)   Processor Features: 0131:00011011
> (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
> (XEN) Extensions: GenericTimer Security
> (XEN)   Debug Features: 03010066
> (XEN)   Auxiliary Features: 
> (XEN)   Memory Model Features: 10201105 4000 0126 02102211
> (XEN)  ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121
> (XEN) Using PSCI-0.2 for SMP bringup
> (XEN) SMP: Allowing 4 CPUs
> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 24000 KHz
> (XEN) GICv2 initialization:
> (XEN) gic_dist_addr=01c81000
> (XEN) gic_cpu_addr=01c82000
> (XEN) gic_hyp_addr=01c84000
> (XEN) gic_vcpu_addr=01c86000
> (XEN) gic_maintenance_irq=25
> (XEN) GICv2: 224 lines, 4 cpus, secure (IID 0200143b).
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> 
> but when I boot dtuart= say duart=xyz instead of 
> dtuart=serial0, xen booted successfully but Dom0 crash while probing 
> 'serial0' driver. 
> 
> If I remove 'serial0' node from device tree, Dom0 boot successfully but 
> unable to enter input into 'hvc' console. 
> 
> what could be wrong here or missing something?

What is your dom0 command line? Are you passing console=hvc0?

It looks like pine64 is using an allwinner sun50i-uart, for which we
don't have a proper driver in Xen yet. That is probably the reason why
you can see some output from Xen, but you cannot type anything in later
in Dom0 (which is sent to Xen via the HVC console).  Please send a patch
to add a simple sun50i-uart driver (see xen/drivers/char/). Given that
both Xen and Linux are GPLv2, you can import code from Linux if you find
it appropriate.

Cheers,

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

Re: [Xen-devel] [RFC XEN PATCH v2 00/15] Add vNVDIMM support to HVM domains

[Dan Williams]

>> I don't think KVM has the same issue, but honestly I don't have the
>> full mental model of how KVM supports mmap. I've at least been able to
>> run a guest where the "pmem" is just dynamic page cache on the host
>> side so the physical memory mapping is changing all the time due to
>> swap. KVM does not have this third-party M2P mapping table to keep up
>> to date so I assume it is just handled by the standard mmap support
>> for establishing a guest physical address range and the standard
>> mapping-invalidate + remap mechanism just works.
>
> Could it be possible to have an Xen driver that would listen on
> these notifications and percolate those changes this driver. Then
> this driver would make the appropiate hypercalls to update the M2P ?
>
> That would solve the 2/ I think?

I think that could work. That sounds like userfaultfd support for DAX
which is something I want to take a look at in the next couple kernel
cycles for other reasons like live migration of guest-VMs with DAX
mappings.

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

Re: [Xen-devel] [PATCH 1/2] memory: exit early from memory_exchange() upon write-back error

[Andrew Cooper]

On 04/04/17 14:13, Jan Beulich wrote:
> There's no point in continuing if in the end we'll return -EFAULT
> anyway. It also seems wrong to report a chunk for which at least one
> write-back failed as successfully exchanged (albeit the indication of
> an error is also not fully correct, as the exchange happened in that
> case at least partially - retrieving the GFN to assign the memory to
> and/or handing back the information on the replacement memory didn't
> work). In any case limiting the amount of damage done to the guest
> can't be all that bad an idea.
>
> Reported-by: Jann Horn 
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

> ---
> I'm additionally surprised we don't require input GFNs to be order
> aligned for both IN- and OUT-chunks (similarly for populate-physmap
> and decrease-reservation).

This sounds like a bug, rather than being intentional.

>
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c

As an observation, I find it amusing that there is a comment just above
this which states

/*
 * Success! Beyond this point we cannot fail for this chunk.
 */

> @@ -639,6 +639,9 @@ static long memory_exchange(XEN_GUEST_HA
>  }
>  }
>  BUG_ON( !(d->is_dying) && (j != (1UL << out_chunk_order)) );
> +
> +if ( rc )
> +goto fail;
>  }
>  
>  exch.nr_exchanged = exch.in.nr_extents;
>
>
>


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

[Xen-devel] [xen-unstable-smoke test] 107194: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  c4bdbec00c9063736361124a3492ebceabfaed06
baseline version:
 xen  938fd2586eb081bcbd694f4c1f09ae6a263b0d90

Last test of basis   107182  2017-04-04 13:02:17 Z0 days
Testing same since   107194  2017-04-04 16:01:54 Z0 days1 attempts


People who touched revisions under test:
  Seraphime Kirkovski 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=c4bdbec00c9063736361124a3492ebceabfaed06
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
c4bdbec00c9063736361124a3492ebceabfaed06
+ branch=xen-unstable-smoke
+ revision=c4bdbec00c9063736361124a3492ebceabfaed06
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' xc4bdbec00c9063736361124a3492ebceabfaed06 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : 

[Xen-devel] [linux-arm-xen baseline-only test] 71148: tolerable trouble: blocked/broken/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 71148 linux-arm-xen real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71148/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   like 68489
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   like 68489

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-pvops 2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-xsm   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-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   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-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-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-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-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

version targeted for testing:
 linux6878b2fa7229c9208a02d45f280c71389cba0617
baseline version:
 linux9550fff2bd1f88405dd61d86e90807046a580d6c

Last test of basis68489  2017-01-26 10:21:44 Z   68 days
Testing same since71148  2017-04-04 10:54:11 Z0 days1 attempts


People who touched revisions under test:
  Stefano Stabellini 

jobs:
 build-arm64-xsm  broken  
 build-armhf-xsm  pass
 build-arm64  broken  
 build-armhf  pass
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  pass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 test-arm64-arm64-xl  blocked 
 test-armhf-armhf-xl  pass
 test-arm64-arm64-libvirt-xsm blocked 
 test-armhf-armhf-libvirt-xsm pass
 test-arm64-arm64-xl-xsm  blocked 
 test-armhf-armhf-xl-xsm  pass
 test-arm64-arm64-xl-credit2  blocked 
 test-armhf-armhf-xl-credit2  pass
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt pass
 test-armhf-armhf-xl-midway   pass
 test-arm64-arm64-xl-multivcpublocked 
 test-armhf-armhf-xl-multivcpu

Re: [Xen-devel] [PATCH v6] altp2m: Introduce external-only and limited use-cases

[Daniel De Graaf]

On 04/04/2017 11:24 AM, Tamas K Lengyel wrote:

Currently setting altp2mhvm=1 in the domain configuration allows access to the
altp2m interface for both in-guest and external privileged tools. This poses
a problem for use-cases where only external access should be allowed, requiring
the user to compile Xen with XSM enabled to be able to appropriately restrict
access.

In this patch we deprecate the altp2mhvm domain configuration option and
introduce the altp2m option, which allows specifying if by default the altp2m
interface should be external-only or limited. The information is stored in
HVM_PARAM_ALTP2M which we now define with specific XEN_ALTP2M_* modes.
If external mode is selected, the XSM check is shifted to use XSM_DM_PRIV
type check, thus restricting access to the interface by the guest itself. Note
that we keep the default XSM policy untouched. Users of XSM who wish to enforce
external mode for altp2m can do so by adjusting their XSM policy directly,
as this domain config option does not override an active XSM policy.

Also, as part of this patch we adjust the hvmop handler to require
HVM_PARAM_ALTP2M to be of a type other then disabled for all ops. This has been
previously only required for get/set altp2m domain state, all other options
were gated on altp2m_enabled. Since altp2m_enabled only gets set during set
altp2m domain state, this change introduces no new requirements to the other
ops but makes it more clear that it is required for all ops.

Signed-off-by: Tamas K Lengyel 
Signed-off-by: Sergej Proskurin 
Acked-by: Wei Liu 


Acked-by: Daniel De Graaf 

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

[Xen-devel] [linux-arm-xen test] 107176: regressions - FAIL

[osstest service owner]

flight 107176 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107176/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail REGR. vs. 62674
 test-armhf-armhf-libvirt 13 saverestore-support-check fail REGR. vs. 62674

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-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 5 kernel-build 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-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-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 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-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-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 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-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-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass

version targeted for testing:
 linux6878b2fa7229c9208a02d45f280c71389cba0617
baseline version:
 linux9550fff2bd1f88405dd61d86e90807046a580d6c

Last test of basis62674  2015-10-05 12:24:43 Z  547 days
Testing same since   107164  2017-04-03 20:34:31 Z0 days3 attempts


People who touched revisions under test:
  Stefano Stabellini 

jobs:
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-arm64  pass
 build-armhf  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-arm64-pvopsfail
 build-armhf-pvopspass
 test-arm64-arm64-xl  blocked 
 test-armhf-armhf-xl  pass
 test-arm64-arm64-libvirt-xsm blocked 
 test-armhf-armhf-libvirt-xsm pass
 test-arm64-arm64-xl-xsm  blocked 
 test-armhf-armhf-xl-xsm  pass
 test-armhf-armhf-xl-arndale  pass
 test-arm64-arm64-xl-credit2  blocked 
 test-armhf-armhf-xl-credit2  pass
 test-armhf-armhf-xl-cubietruck   pass
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt pass
 test-arm64-arm64-xl-multivcpublocked 
 test-armhf-armhf-xl-multivcpupass
 test-arm64-arm64-libvirt-qcow2   blocked 
 test-armhf-armhf-libvirt-raw pass
 test-arm64-arm64-xl-rtds blocked 
 test-armhf-armhf-xl-rtds   

Re: [Xen-devel] [RFC XEN PATCH v2 00/15] Add vNVDIMM support to HVM domains

[Konrad Rzeszutek Wilk]

On Tue, Apr 04, 2017 at 10:59:01AM -0700, Dan Williams wrote:
> On Tue, Apr 4, 2017 at 10:34 AM, Konrad Rzeszutek Wilk
>  wrote:
> > On Tue, Apr 04, 2017 at 10:16:41AM -0700, Dan Williams wrote:
> >> On Tue, Apr 4, 2017 at 10:00 AM, Konrad Rzeszutek Wilk
> >>  wrote:
> >> > On Sat, Apr 01, 2017 at 08:45:45AM -0700, Dan Williams wrote:
> >> >> On Sat, Apr 1, 2017 at 4:54 AM, Konrad Rzeszutek Wilk 
> >> >>  wrote:
> >> >> > ..snip..
> >> >> >> >> Is there a resource I can read more about why the hypervisor 
> >> >> >> >> needs to
> >> >> >> >> have this M2P mapping for nvdimm support?
> >> >> >> >
> >> >> >> > M2P is basically an array of frame numbers. It's indexed by the 
> >> >> >> > host
> >> >> >> > page frame number, or the machine frame number (MFN) in Xen's
> >> >> >> > definition. The n'th entry records the guest page frame number 
> >> >> >> > that is
> >> >> >> > mapped to MFN n. M2P is one of the core data structures used in Xen
> >> >> >> > memory management, and is used to convert MFN to guest PFN. A
> >> >> >> > read-only version of M2P is also exposed as part of ABI to guest. 
> >> >> >> > In
> >> >> >> > the previous design discussion, we decided to put the management of
> >> >> >> > NVDIMM in the existing Xen memory management as much as possible, 
> >> >> >> > so
> >> >> >> > we need to build M2P for NVDIMM as well.
> >> >> >> >
> >> >> >>
> >> >> >> Thanks, but what I don't understand is why this M2P lookup is needed?
> >> >> >
> >> >> > Xen uses it to construct the EPT page tables for the guests.
> >> >> >
> >> >> >> Does Xen establish this metadata for PCI mmio ranges as well? What 
> >> >> >> Xen
> >> >> >
> >> >> > It doesn't have that (M2P) for PCI MMIO ranges. For those it has an
> >> >> > ranges construct (since those are usually contingous and given
> >> >> > in ranges to a guest).
> >> >>
> >> >> So, I'm confused again. This patchset / enabling requires both M2P and
> >> >> contiguous PMEM ranges. If the PMEM is contiguous it seems you don't
> >> >> need M2P and can just reuse the MMIO enabling, or am I missing
> >> >> something?
> >> >
> >> > I think I am confusing you.
> >> >
> >> > The patchset (specifically 04/15] xen/x86: add 
> >> > XEN_SYSCTL_nvdimm_pmem_setup to setup host pmem )
> >> > adds a hypercall to tell Xen where on the NVDIMM it can put
> >> > the M2P array and as well the frametables ('struct page').
> >> >
> >> > There is no range support. The reason is that if break up
> >> > an NVDIMM in various chunks (and then put a filesystem on top of it) - 
> >> > and
> >> > then figure out which of the SPAs belong to the file - and then
> >> > "expose" that file to a guest as NVDIMM - it's SPAs won't
> >> > be contingous. Hence the hypervisor would need to break down
> >> > the 'ranges' structure down in either a bitmap or an M2P
> >> > and also store it. This can get quite tricky so you may
> >> > as well just start with an M2P and 'struct page'.
> >>
> >> Ok... but the problem then becomes that the filesystem is free to
> >> change the file-offset to SPA mapping any time it wants. So the M2P
> >> support is broken if it expects static relationships.
> >
> > Can't you flock an file and that will freeze it? Or mlock it since
> > one is rather mmap-ing it?
> 
> Unfortunately no. This dovetails with the discussion we have been
> having with filesystem folks about the need to call msync() after
> every write. Whenever the filesystem sees a write fault it is free to
> move blocks around in the file, think allocation or copy-on-write
> operations like reflink. The filesystem depends on the application
> calling msync/fsync before it makes the writes from those faults
> durable against crash / powerloss.  Also, actions like online defrag
> can change these offset to physical address relationships without any
> involvement from the application. There's currently no mechanism to
> lock out this behavior because the filesystem assumes that it can just
> invalidate mappings to make the application re-fault.
> 
> >>
> >> > The placement of those datastructures is "
> >> > v2 patch
> >> >series relies on users/admins in Dom0 instead of Dom0 driver to 
> >> > indicate the
> >> >location to store the frametable and M2P of pmem.
> >> > "
> >> >
> >> > Hope this helps?
> >>
> >> It does, but it still seems we're stuck between either 1/ not needing
> >> M2P if we can pass a whole pmem-namespace through to the guest or 2/
> >> M2P being broken by non-static file-offset to physical address
> >> mappings.
> >
> > Aye. So how can 2/ be fixed? I am assuming you would have the same
> > issue with KVM - if the file is 'moving' underneath (and the file-offset
> > to SPA has changed) won't that affect the EPT and other page entries?
> 
> I don't think KVM has the same issue, but honestly I don't have the
> full mental model of how KVM supports mmap. I've at least been able to
> run a guest where the "pmem" is just 

Re: [Xen-devel] Can't read bios file

[Duncan X. Simpson]

Update: I still have the same problem when I compile from git master.

On Mon, Apr 3, 2017 at 7:05 PM Duncan X. Simpson 
wrote:

> I apologize, I should probably include this information:
> OS: Arch Linux
> xl info:
> host   : k7dxs-laptop-r500
> release: 4.10.6-1-ARCH
> version: #1 SMP PREEMPT Mon Mar 27 08:28:22 CEST 2017
> machine: x86_64
> nr_cpus: 2
> max_cpu_id : 3
> nr_nodes   : 1
> cores_per_socket   : 2
> threads_per_core   : 1
> cpu_mhz: 2394
> hw_caps:
> b7ebfbff:0408e3fd:20100800:0001::::
> virt_caps  : hvm
> total_memory   : 1944
> free_memory: 517
> sharing_freed_memory   : 0
> sharing_used_memory: 0
> outstanding_claims : 0
> free_cpus  : 0
> xen_major  : 4
> xen_minor  : 8
> xen_extra  : .0
> xen_version: 4.8.0
> xen_caps   : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
> hvm-3.0-x86_32p hvm-3.0-x86_64
> xen_scheduler  : credit
> xen_pagesize   : 4096
> platform_params: virt_start=0x8000
> xen_changeset  :
> xen_commandline: /boot/xen-4.8.0.gz xsave=1
> cc_compiler: gcc (GCC) 6.3.1 20170306
> cc_compile_by  : duncan
> cc_compile_domain  :
> cc_compile_date: Tue Mar 28 15:11:08 MST 2017
> build_id   : 8b7628e151ee56a26b2f83b21160ee1168263b64
> xend_config_format : 4
>
>
> On Mon, Apr 3, 2017 at 6:25 PM Duncan X. Simpson 
> wrote:
>
> I'm trying to set up an HVM CentOS guest, and I've run into a problem. I
> originally tried posting it on Stack Exchange (
> https://superuser.com/questions/1193771/failed-to-read-bios-file-no-such-file-or-directory),
> but it is not documented anywhere on the Internet that Google can see and I
> have gotten no response. I regained interest in it today and used strace to
> determine what bios file it was looking for, and found it was looking for a
> file called 'yes' in the current directory. This is what made me decide it
> was most likely a bug and post it here rather in xen-users. My
> configuration is as listed on the Stack Exchange question and does not
> contain the word yes anywhere in it. What should I do next?
> --
>
> Duncan X. Simpson, K7DXS
>
> --
>
> Duncan X. Simpson, K7DXS
>
-- 

Duncan X. Simpson, K7DXS
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC XEN PATCH v2 00/15] Add vNVDIMM support to HVM domains

[Dan Williams]

On Tue, Apr 4, 2017 at 10:34 AM, Konrad Rzeszutek Wilk
 wrote:
> On Tue, Apr 04, 2017 at 10:16:41AM -0700, Dan Williams wrote:
>> On Tue, Apr 4, 2017 at 10:00 AM, Konrad Rzeszutek Wilk
>>  wrote:
>> > On Sat, Apr 01, 2017 at 08:45:45AM -0700, Dan Williams wrote:
>> >> On Sat, Apr 1, 2017 at 4:54 AM, Konrad Rzeszutek Wilk  
>> >> wrote:
>> >> > ..snip..
>> >> >> >> Is there a resource I can read more about why the hypervisor needs 
>> >> >> >> to
>> >> >> >> have this M2P mapping for nvdimm support?
>> >> >> >
>> >> >> > M2P is basically an array of frame numbers. It's indexed by the host
>> >> >> > page frame number, or the machine frame number (MFN) in Xen's
>> >> >> > definition. The n'th entry records the guest page frame number that 
>> >> >> > is
>> >> >> > mapped to MFN n. M2P is one of the core data structures used in Xen
>> >> >> > memory management, and is used to convert MFN to guest PFN. A
>> >> >> > read-only version of M2P is also exposed as part of ABI to guest. In
>> >> >> > the previous design discussion, we decided to put the management of
>> >> >> > NVDIMM in the existing Xen memory management as much as possible, so
>> >> >> > we need to build M2P for NVDIMM as well.
>> >> >> >
>> >> >>
>> >> >> Thanks, but what I don't understand is why this M2P lookup is needed?
>> >> >
>> >> > Xen uses it to construct the EPT page tables for the guests.
>> >> >
>> >> >> Does Xen establish this metadata for PCI mmio ranges as well? What Xen
>> >> >
>> >> > It doesn't have that (M2P) for PCI MMIO ranges. For those it has an
>> >> > ranges construct (since those are usually contingous and given
>> >> > in ranges to a guest).
>> >>
>> >> So, I'm confused again. This patchset / enabling requires both M2P and
>> >> contiguous PMEM ranges. If the PMEM is contiguous it seems you don't
>> >> need M2P and can just reuse the MMIO enabling, or am I missing
>> >> something?
>> >
>> > I think I am confusing you.
>> >
>> > The patchset (specifically 04/15] xen/x86: add 
>> > XEN_SYSCTL_nvdimm_pmem_setup to setup host pmem )
>> > adds a hypercall to tell Xen where on the NVDIMM it can put
>> > the M2P array and as well the frametables ('struct page').
>> >
>> > There is no range support. The reason is that if break up
>> > an NVDIMM in various chunks (and then put a filesystem on top of it) - and
>> > then figure out which of the SPAs belong to the file - and then
>> > "expose" that file to a guest as NVDIMM - it's SPAs won't
>> > be contingous. Hence the hypervisor would need to break down
>> > the 'ranges' structure down in either a bitmap or an M2P
>> > and also store it. This can get quite tricky so you may
>> > as well just start with an M2P and 'struct page'.
>>
>> Ok... but the problem then becomes that the filesystem is free to
>> change the file-offset to SPA mapping any time it wants. So the M2P
>> support is broken if it expects static relationships.
>
> Can't you flock an file and that will freeze it? Or mlock it since
> one is rather mmap-ing it?

Unfortunately no. This dovetails with the discussion we have been
having with filesystem folks about the need to call msync() after
every write. Whenever the filesystem sees a write fault it is free to
move blocks around in the file, think allocation or copy-on-write
operations like reflink. The filesystem depends on the application
calling msync/fsync before it makes the writes from those faults
durable against crash / powerloss.  Also, actions like online defrag
can change these offset to physical address relationships without any
involvement from the application. There's currently no mechanism to
lock out this behavior because the filesystem assumes that it can just
invalidate mappings to make the application re-fault.

>>
>> > The placement of those datastructures is "
>> > v2 patch
>> >series relies on users/admins in Dom0 instead of Dom0 driver to 
>> > indicate the
>> >location to store the frametable and M2P of pmem.
>> > "
>> >
>> > Hope this helps?
>>
>> It does, but it still seems we're stuck between either 1/ not needing
>> M2P if we can pass a whole pmem-namespace through to the guest or 2/
>> M2P being broken by non-static file-offset to physical address
>> mappings.
>
> Aye. So how can 2/ be fixed? I am assuming you would have the same
> issue with KVM - if the file is 'moving' underneath (and the file-offset
> to SPA has changed) won't that affect the EPT and other page entries?

I don't think KVM has the same issue, but honestly I don't have the
full mental model of how KVM supports mmap. I've at least been able to
run a guest where the "pmem" is just dynamic page cache on the host
side so the physical memory mapping is changing all the time due to
swap. KVM does not have this third-party M2P mapping table to keep up
to date so I assume it is just handled by the standard mmap support
for establishing a guest physical address range and the standard
mapping-invalidate + 

Re: [Xen-devel] [linux-arm-xen test] 107164: regressions - FAIL

[Stefano Stabellini]

On Tue, 4 Apr 2017, Ian Jackson wrote:
> Julien Grall writes ("Re: [Xen-devel] [linux-arm-xen test] 107164: 
> regressions - FAIL"):
> > On 04/04/2017 04:14 AM, osstest service owner wrote:
> > > flight 107164 linux-arm-xen real [real]
> > > http://logs.test-lab.xenproject.org/osstest/logs/107164/
> ...
> > >  test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail REGR. vs. 
> > > 62674
> > >  test-armhf-armhf-libvirt 13 saverestore-support-check fail REGR. vs. 
> > > 62674
> > 
> > Looking at the result, it fails because of save/restore that has never 
> > been supported on ARM.
> 
> Indeed.  I think the pass in 62674 was spurious.
> 
> Looking at the git logs between the version of osstest used in flight
> 62674, and current production, there were a bunch of fixes to the
> migration support check.  Notably
>   6a9b295891f8e1a952936ce7f7e0ebae56e13797
>   libvirt: Do not attempt save/restore when migration not advertised
> which says "Currently, osstest wrongly thinks that ARM can do
> save/restore, ..."
> 
> The bisector had a go but failed to repro the basis pass, instead
> getting the expected failure:
>   
> http://logs.test-lab.xenproject.org/osstest/logs/107171/test-armhf-armhf-libvirt-xsm/13.ts-saverestore-support-check.log
> The bisector runs with the previous versions of everything except
> osstest itself, so this is consistent.
> 
> Also, I picked a sample job run on an arndale to check that it still
> gets the Xen serial log:
>   
> http://logs.test-lab.xenproject.org/osstest/logs/107164/test-armhf-armhf-libvirt/info.html
>   
> http://logs.test-lab.xenproject.org/osstest/logs/107164/test-armhf-armhf-libvirt/serial-arndale-metrocentre.log
> 
> > Ian, would it be possible to force push linux-arm-xen?
> 
> So, indeed, 
> 
> > > version targeted for testing:
> > >  linux6878b2fa7229c9208a02d45f280c71389cba0617
> 
> I have force pushed that version.
> 
> 
> To summarise our irc conversation about serial host properties on the
> arndale:
> 
> Our plan was:
> 
> 1. Push linux-arm-xen with a change to the Linux DT to support
> "dtuart=serial2".  (Now done.)
> 
> 2. When that passes the push gate (now done) and is being used
> everywhere (not quite yet), we change the XenDTUARTPath setting for
> the arndales to "serial2" from "/serial@12C2".
> 
> 3. After that, use "git merge -s ours" to create a commit on
> linux-arm-xen which is a fast-forward update, but which is actually
> identical to a suitable linux 4.x (probably linux 4.9 for now, because
> that's a stable branch upstream).

I readied a 4.9.y based fast-forwarding linux-arm-xen branch ready to be
pushed. Just let me know when appropriate.


> 4. Any resulting regressions will have to be fixed up, presumably in
> Xen staging/master or the appropriate linux 4.x.y stable upstream
> branch, and then:
> 
> 5. When the 4.x-ish linux-arm-xen (ie, the version which is identical
> to some upstream 4.x but is fast forward from old linux-arm-xen
> revisions) passes the push gate, we will manually rewind both the
> linux-arm-xen input and output push gate branches to the corresponding
> upstream 4.x revision - ie, no code change, but dropping the history
> noise.
> 
> 
> Because the Linux ARM commit to use is frozen at flight start, but
> host properties settings are not, we need to wait for existing flights
> using old linux-arm-xen to finish before changing the host setting.
> 
> Thanks,
> Ian.
> 

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

Re: [Xen-devel] [RFC XEN PATCH v2 00/15] Add vNVDIMM support to HVM domains

[Konrad Rzeszutek Wilk]

On Tue, Apr 04, 2017 at 10:16:41AM -0700, Dan Williams wrote:
> On Tue, Apr 4, 2017 at 10:00 AM, Konrad Rzeszutek Wilk
>  wrote:
> > On Sat, Apr 01, 2017 at 08:45:45AM -0700, Dan Williams wrote:
> >> On Sat, Apr 1, 2017 at 4:54 AM, Konrad Rzeszutek Wilk  
> >> wrote:
> >> > ..snip..
> >> >> >> Is there a resource I can read more about why the hypervisor needs to
> >> >> >> have this M2P mapping for nvdimm support?
> >> >> >
> >> >> > M2P is basically an array of frame numbers. It's indexed by the host
> >> >> > page frame number, or the machine frame number (MFN) in Xen's
> >> >> > definition. The n'th entry records the guest page frame number that is
> >> >> > mapped to MFN n. M2P is one of the core data structures used in Xen
> >> >> > memory management, and is used to convert MFN to guest PFN. A
> >> >> > read-only version of M2P is also exposed as part of ABI to guest. In
> >> >> > the previous design discussion, we decided to put the management of
> >> >> > NVDIMM in the existing Xen memory management as much as possible, so
> >> >> > we need to build M2P for NVDIMM as well.
> >> >> >
> >> >>
> >> >> Thanks, but what I don't understand is why this M2P lookup is needed?
> >> >
> >> > Xen uses it to construct the EPT page tables for the guests.
> >> >
> >> >> Does Xen establish this metadata for PCI mmio ranges as well? What Xen
> >> >
> >> > It doesn't have that (M2P) for PCI MMIO ranges. For those it has an
> >> > ranges construct (since those are usually contingous and given
> >> > in ranges to a guest).
> >>
> >> So, I'm confused again. This patchset / enabling requires both M2P and
> >> contiguous PMEM ranges. If the PMEM is contiguous it seems you don't
> >> need M2P and can just reuse the MMIO enabling, or am I missing
> >> something?
> >
> > I think I am confusing you.
> >
> > The patchset (specifically 04/15] xen/x86: add XEN_SYSCTL_nvdimm_pmem_setup 
> > to setup host pmem )
> > adds a hypercall to tell Xen where on the NVDIMM it can put
> > the M2P array and as well the frametables ('struct page').
> >
> > There is no range support. The reason is that if break up
> > an NVDIMM in various chunks (and then put a filesystem on top of it) - and
> > then figure out which of the SPAs belong to the file - and then
> > "expose" that file to a guest as NVDIMM - it's SPAs won't
> > be contingous. Hence the hypervisor would need to break down
> > the 'ranges' structure down in either a bitmap or an M2P
> > and also store it. This can get quite tricky so you may
> > as well just start with an M2P and 'struct page'.
> 
> Ok... but the problem then becomes that the filesystem is free to
> change the file-offset to SPA mapping any time it wants. So the M2P
> support is broken if it expects static relationships.

Can't you flock an file and that will freeze it? Or mlock it since
one is rather mmap-ing it?
> 
> > The placement of those datastructures is "
> > v2 patch
> >series relies on users/admins in Dom0 instead of Dom0 driver to indicate 
> > the
> >location to store the frametable and M2P of pmem.
> > "
> >
> > Hope this helps?
> 
> It does, but it still seems we're stuck between either 1/ not needing
> M2P if we can pass a whole pmem-namespace through to the guest or 2/
> M2P being broken by non-static file-offset to physical address
> mappings.

Aye. So how can 2/ be fixed? I am assuming you would have the same
issue with KVM - if the file is 'moving' underneath (and the file-offset
to SPA has changed) won't that affect the EPT and other page entries?

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

Re: [Xen-devel] Can't ./configure latest git

[Duncan X. Simpson]

I just realized I misread the error message. I fixed the environment and
got it working.

On Tue, Apr 4, 2017 at 8:30 AM Anthony PERARD 
wrote:

On Tue, Apr 04, 2017 at 03:09:48PM +, Duncan X. Simpson wrote:
> Ah, that makes more sense. Another problem I had when trying to compile
was
> I got a permission denied error on xen-setup, which I fixed by making as
> root (in a chroot of course). Was there a better way to do that?

This sound like an weird issue in your environnement. And I don't see
how been root would affect permission of xen-setup. Is this
tools/qemu-xen-traditional-dir/xen-setup ?

What is the error message?

--
Anthony PERARD

-- 

Duncan X. Simpson, K7DXS
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH] tools:misc:xenlockprof: fix possible format string overflow

[Seraphime Kirkovski]

GCC7 complains about a possible overflow/truncation in xenlockprof.

xenlockprof.c: In function ‘main’:
xenlockprof.c:100:53: error: ‘%s’ directive writing up to 39 bytes into a
 region of size between 17 and 37 
[-Werror=format-overflow=]
 sprintf(name, "unknown type(%d) %d lock %s", data[j].type,
 ^~
xenlockprof.c:100:13: note: ‘sprintf’ output between 24 and 83 bytes
 into a destination of size 60
 sprintf(name, "unknown type(%d) %d lock %s", data[j].type,
 ^~
 data[j].idx, data[j].name);
 ~~

This increases the size of name to 100. Not the most scalable solution,
but certainly the "cheapest", as it doesn't add dependencies for
asprintf.

Signed-off-by: Seraphime Kirkovski 
---
 tools/misc/xenlockprof.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/misc/xenlockprof.c b/tools/misc/xenlockprof.c
index 41fcb792cc..df23c82912 100644
--- a/tools/misc/xenlockprof.c
+++ b/tools/misc/xenlockprof.c
@@ -24,7 +24,7 @@ int main(int argc, char *argv[])
 uint32_t   i, j, n;
 uint64_t   time;
 double l, b, sl, sb;
-char   name[60];
+char   name[100];
 DECLARE_HYPERCALL_BUFFER(xc_lockprof_data_t, data);
 
 if ( (argc > 2) || ((argc == 2) && (strcmp(argv[1], "-r") != 0)) )
-- 
2.11.0


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

Re: [Xen-devel] [GSoc] GSoc Introduction : Xen on ARM: create multiple guests from device tree

[Stefano Stabellini]

One more thing: the deadline for microtasks (the patch submission below
to fix XEN-38) is technically Monday the 10th of April, but in practice
the patch needs to be sent this week to be able to follow up review
comments appropriately. Ideally the patch should be already committed by
Monday the 10th.

On Mon, 3 Apr 2017, Methuku Karthik wrote:
> Hi Stefano,
> 
> I have asked questions in inline. Clarification below questions would really 
> help me in contribution. Please look into the questions. I am highlighting 
> them in this mail.
> 
>  For example, Dom1 should be able to share a page with Dom2 and a
>   different page with Dom3. It needs to be clear which page is shared with
> which VM from the VM config files.
> 
>  
> when we create vms using xl create , for example if i am planning create 
> three VMs,
> 
> Dom1, Dom2 and Dom3, because of the page sharing are we imposing any order of
>   creating VMs.
> 
>   I am asking this question to clarify this point, while creation of Dom1 if 
> its
>   sharing pages with Dom 2 and Dom 3 , should Xen already be aware of Dom2 
> and Dom3?
> 
>   I am referring to following links to understand about mem sharing.
> 
>   
> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/tests/mem-sharing/memshrtoo
>   l.c;h=8e5e22b9e95d91f1441d8eb226b64852eca075d5;hb=HEAD
>   http://xenbits.xen.org/docs/unstable/misc/grant-tables.txt
> 
>   I also want to figure out how domains are created and how xl tool parses 
> the file
>   and passes on the information to domain creation . Let me know if i am 
> thinking in
>   right direction.
> 
>   suggest any resource or work which would help with designing config file 
> options.
> 
> 
>  I will start with Xen-38 that would help me in exploring init code. Correct 
> me if i
>   am wrong.
> 
>   I have a few questions and clarifications before proceeding further. I have 
> checked
>   how config.gz file is generated in linux kernel source.
>   In linux kernel sources, if CONFIG_IKCONFIG_PROC option is set, .conifg 
> file which
>   is generated after choosing options with lets say from make menuconfig  is 
> read into
>   a variable, this way its part of build.
> 
>   during init time proc_create service is used to create this file config.gz.
>   http://lxr.free-electrons.com/source/kernel/configs.c
> 
> 
>   I guess i have to do something similar.
> 
>   Questions :
> 
>   1. When Xen is build using the make command, we effectively set 
> XEN_COMPILE_ARCH,
>   XEN_OS, XEN_TARGET which allow using corresponding .mk file from config 
> folder.
>   These variable in turn decide what are the config options. I wasnt able to 
> find any
>   .config. Please direct me to find the file or if i am missing something. 
> 
>   2. Where and how this config file should be accessible to  User once in 
> Dom0. Is the
>   xen folder created to keep the information about guest domains like proc 
> for process
>   in linux kernel ? Will that be suitable location to have config file.
> 
>   3. if i assume that i will approach similarly, i have to add services to be 
> called
>   during init stage. As am not acquainted with code base, i could just grep 
> with
>   _start or _init or similar strings to find out initialization code. Any
>   input(function name or filename) to look for will be of great help.
> 
> On Mon, Apr 3, 2017 at 3:35 PM, Stefano Stabellini  
> wrote:
>   Thank you! I am looking forward to your contribution on the list! If you
>   encounter any issues, please let us know.
> 
>   The code contribution is more important, but if you find the time in the
>   next few days, it would be nice to add more details to the
>   implementation plan, such as where the memory gets allocated, whether it
>   is taken from a VM, and if so, which one. Also what kind of "token"
>   could be used in the config option and how the toolstack could keep
>   track of the token - memory page references.
> 
>   Thanks,
> 
>   Stefano
> 
>   On Mon, 3 Apr 2017, Methuku Karthik wrote:
>   > Hi Stefano,
>   >
>   > Thanks for Input. I was not able to spend enough time last couple of 
> weeks due to
>   > projects. I have received mail from Lars Kurt explaining submission 
> of draft
>   > proposal and possibility to work on micro tasks.
>   >
>   > I have created a draft proposal from with your inputs and what i 
> learnt about
>   > sharing pages and memory management in Xen, please access it from here
>   >
>   > 
> https://docs.google.com/document/d/1xLmR7x4yfCbRgpuefZQNhZ4lAu-6slW0oXPmjnxcnz0/edi
>   > t#heading=h.1yvc35w6t3fu
>   >
>   > I haven't written anything about maintenance. I have included some 
> links i thought
>   > will be helpful under references and referenced wherever applicable.
>   >
>   > Please suggest comments and inputs.
>   >
>   > On Tue, Mar 28, 2017 at 8:12 PM, Stefano Stabellini 
> 

Re: [Xen-devel] [xen-4.6-testing bisection] complete test-xtf-amd64-amd64-5

[Dario Faggioli]

On Mon, 2017-04-03 at 02:02 -0600, Jan Beulich wrote:
> > > > On 03.04.17 at 00:44,  wrote:
> >   commit 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546
> >   Author: Dario Faggioli 
> >   Date:   Fri Mar 31 09:03:32 2017 +0200
> >   
> >   xen: sched: don't call hooks of the wrong scheduler via
> > VCPU2OP
> 
> I must have completely screwed up on this backport, so I've simply
> reverted it for now. I didn't look closely yet whether this is some
> trivial oversight of mine, or whether perhaps it shouldn't have been
> backported that far back in the first place.
> 
I had a look. The backport looks fine in itself to me.

If I'm not mistaken, this is not in staging-4.6:

 f3d47501db2b7bb8dfd6a3c9710b7aff4b1fc55b
 xen: fix a (latent) cpupool-related race during domain destroy

I can't be positive this is what's missing, but it's my best guess. :-)

I also haven't tried backporting it, but I'm happy to. Let me know if I
should.

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] [RFC XEN PATCH v2 00/15] Add vNVDIMM support to HVM domains

[Dan Williams]

On Tue, Apr 4, 2017 at 10:00 AM, Konrad Rzeszutek Wilk
 wrote:
> On Sat, Apr 01, 2017 at 08:45:45AM -0700, Dan Williams wrote:
>> On Sat, Apr 1, 2017 at 4:54 AM, Konrad Rzeszutek Wilk  
>> wrote:
>> > ..snip..
>> >> >> Is there a resource I can read more about why the hypervisor needs to
>> >> >> have this M2P mapping for nvdimm support?
>> >> >
>> >> > M2P is basically an array of frame numbers. It's indexed by the host
>> >> > page frame number, or the machine frame number (MFN) in Xen's
>> >> > definition. The n'th entry records the guest page frame number that is
>> >> > mapped to MFN n. M2P is one of the core data structures used in Xen
>> >> > memory management, and is used to convert MFN to guest PFN. A
>> >> > read-only version of M2P is also exposed as part of ABI to guest. In
>> >> > the previous design discussion, we decided to put the management of
>> >> > NVDIMM in the existing Xen memory management as much as possible, so
>> >> > we need to build M2P for NVDIMM as well.
>> >> >
>> >>
>> >> Thanks, but what I don't understand is why this M2P lookup is needed?
>> >
>> > Xen uses it to construct the EPT page tables for the guests.
>> >
>> >> Does Xen establish this metadata for PCI mmio ranges as well? What Xen
>> >
>> > It doesn't have that (M2P) for PCI MMIO ranges. For those it has an
>> > ranges construct (since those are usually contingous and given
>> > in ranges to a guest).
>>
>> So, I'm confused again. This patchset / enabling requires both M2P and
>> contiguous PMEM ranges. If the PMEM is contiguous it seems you don't
>> need M2P and can just reuse the MMIO enabling, or am I missing
>> something?
>
> I think I am confusing you.
>
> The patchset (specifically 04/15] xen/x86: add XEN_SYSCTL_nvdimm_pmem_setup 
> to setup host pmem )
> adds a hypercall to tell Xen where on the NVDIMM it can put
> the M2P array and as well the frametables ('struct page').
>
> There is no range support. The reason is that if break up
> an NVDIMM in various chunks (and then put a filesystem on top of it) - and
> then figure out which of the SPAs belong to the file - and then
> "expose" that file to a guest as NVDIMM - it's SPAs won't
> be contingous. Hence the hypervisor would need to break down
> the 'ranges' structure down in either a bitmap or an M2P
> and also store it. This can get quite tricky so you may
> as well just start with an M2P and 'struct page'.

Ok... but the problem then becomes that the filesystem is free to
change the file-offset to SPA mapping any time it wants. So the M2P
support is broken if it expects static relationships.

> The placement of those datastructures is "
> v2 patch
>series relies on users/admins in Dom0 instead of Dom0 driver to indicate 
> the
>location to store the frametable and M2P of pmem.
> "
>
> Hope this helps?

It does, but it still seems we're stuck between either 1/ not needing
M2P if we can pass a whole pmem-namespace through to the guest or 2/
M2P being broken by non-static file-offset to physical address
mappings.

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

Re: [Xen-devel] [PATCH v2] x86/monitor: add support for descriptor access events

[Adrian Pop]

On Tue, Apr 04, 2017 at 04:26:24PM +0100, Andrew Cooper wrote:
> On 04/04/17 10:57, Adrian Pop wrote:
> > diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
> > index f5cd245771..d60e4afd0c 100644
> > --- a/xen/arch/x86/hvm/monitor.c
> > +++ b/xen/arch/x86/hvm/monitor.c
> > @@ -72,6 +72,28 @@ void hvm_monitor_msr(unsigned int msr, uint64_t value)
> >  }
> >  }
> >  
> > +void hvm_monitor_descriptor_access(uint64_t exit_info,
> > +   uint64_t vmx_exit_qualification,
> > +   uint8_t descriptor, bool is_write)
> > +{
> > +struct vcpu *curr = current;
> > +vm_event_request_t req = {
> > +.reason = VM_EVENT_REASON_DESCRIPTOR_ACCESS,
> > +.u.desc_access.descriptor = descriptor,
> > +.u.desc_access.is_write = is_write,
> > +};
> 
> Newline here
 
Ok.

> > +if ( cpu_has_vmx )
> > +{
> > +req.u.desc_access.arch.vmx.instr_info = exit_info;
> > +req.u.desc_access.arch.vmx.exit_qualification = 
> > vmx_exit_qualification;
> > +}
> > +else
> > +{
> > +req.u.desc_access.arch.svm.exitinfo = exit_info;
> > +}
> 
> And here please.

Ok.

> > +monitor_traps(curr, 1, );
> > +}
> > +
> >  static inline unsigned long gfn_of_rip(unsigned long rip)
> >  {
> >  struct vcpu *curr = current;
> > diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h 
> > b/xen/include/asm-x86/hvm/vmx/vmx.h
> > index 2b781ab120..b00ba52443 100644
> > --- a/xen/include/asm-x86/hvm/vmx/vmx.h
> > +++ b/xen/include/asm-x86/hvm/vmx/vmx.h
> > @@ -628,4 +628,46 @@ typedef struct {
> >  u16 eptp_index;
> >  } ve_info_t;
> >  
> > +/* VM-Exit instruction info for LIDT, LGDT, SIDT, SGDT */
> > +typedef union idt_or_gdt_instr_info {
> > +unsigned long raw;
> > +struct {
> > +unsigned long scaling   :2,  /* bits 0:1 - Scaling */
> > +:5,  /* bits 6:2 - Undefined */
> > +addr_size   :3,  /* bits 9:7 - Address size */
> > +:1,  /* bit 10 - Cleared to 0 */
> > +operand_size:1,  /* bit 11 - Operand size */
> > +:3,  /* bits 14:12 - Undefined */
> > +segment_reg :3,  /* bits 17:15 - Segment register */
> > +index_reg   :4,  /* bits 21:18 - Index register */
> > +index_reg_invalid   :1,  /* bit 22 - Index register invalid */
> > +base_reg:4,  /* bits 26:23 - Base register */
> > +base_reg_invalid:1,  /* bit 27 - Base register invalid */
> > +instr_identity  :1,  /* bit 28 - 0:GDT, 1:IDT */
> > +instr_write :1,  /* bit 29 - 0:store, 1:load */
> > +:2;  /* bits 30:31 - Undefined */
> 
> I think you need a :32 /* undefined */ in each of these, to avoid
> breaking the Clang build, which cares that each half of the union have
> the same bit size.

All right.

> All of these can be fixed on commit if there are no other issues. 
> Otherwise, Reviewed-by: Andrew Cooper 

Thanks!

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-i386-pvgrub  3 host-install(3) broken REGR. vs. 71140

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   like 71140
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   like 71140
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   like 71140
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 71140

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   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-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-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   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-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-amd64-amd64-libvirt-xsm 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-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-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   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-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:
 qemuub1a419ec79c2451fd7b6acfb415a02881ad77844
baseline version:
 qemuu95b31d709ba343ad237c3630047ee7438bac4065

Last test of basis71140  2017-04-01 16:17:38 Z3 days
Testing same since71147  2017-04-04 07:50:06 Z0 days1 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  David Gibson 
  Denis V. Lunev 
  Dr. David Alan Gilbert 
  Eric Blake 
  Gerd Hoffmann 
  Javier Celaya 
  Jeff Cody 
  Kashyap Chamarthy 
  Marc-André Lureau 
  Markus Armbruster 
  Max Reitz 

Re: [Xen-devel] [PATCH v3 26/26] ARM: vGIC: advertise LPI support

[Julien Grall]

Hi Andre,

On 31/03/17 19:05, Andre Przywara wrote:

To let a guest know about the availability of virtual LPIs, set the
respective bits in the virtual GIC registers and let a guest control
the LPI enable bit.
Only report the LPI capability if the host has initialized at least
one ITS.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3.c | 74 ++
 1 file changed, 69 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 22a7b1b..47dad6a 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -169,8 +169,10 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 switch ( gicr_reg )
 {
 case VREG32(GICR_CTLR):
-/* We have not implemented LPI's, read zero */
-goto read_as_zero_32;
+if ( dabt.size != DABT_WORD ) goto bad_width;
+*r = vgic_reg32_extract(!!(v->arch.vgic.flags & VGIC_V3_LPIS_ENABLED),


I would be more readable to do:

uint32_t ctlr;

ctlr = !!(v->arch.vgic.flags & VGIC_V3_LPIS_ENABLED);
*r = vgic_reg32_extract(ctlr, info);


+info);
+return 1;

 case VREG32(GICR_IIDR):
 if ( dabt.size != DABT_WORD ) goto bad_width;
@@ -182,16 +184,19 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 uint64_t typer, aff;

 if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
-/* TBD: Update processor id in [23:8] when ITS support is added */
 aff = (MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 3) << 56 |
MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 2) << 48 |
MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 1) << 40 |
MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 0) << 32);
 typer = aff;
+typer |= (v->vcpu_id & 0x) << 8;


Please explain in the commit message why this change. At first glance, 
this should be a separate patch.




 if ( v->arch.vgic.flags & VGIC_V3_RDIST_LAST )
 typer |= GICR_TYPER_LAST;

+if ( v->domain->arch.vgic.has_its )
+typer |= GICR_TYPER_PLPIS;
+
 *r = vgic_reg64_extract(typer, info);

 return 1;
@@ -434,6 +439,35 @@ static uint64_t sanitize_pendbaser(uint64_t reg)
 return reg;
 }

+static void vgic_vcpu_enable_lpis(struct vcpu *v)
+{
+uint64_t reg = v->domain->arch.vgic.rdist_propbase;
+unsigned int nr_lpis = BIT((reg & 0x1f) + 1) - LPI_OFFSET;
+int nr_pages;
+
+/* The first VCPU to enable LPIs maps the property table. */
+if ( !v->domain->arch.vgic.nr_lpis )
+{
+v->domain->arch.vgic.nr_lpis = nr_lpis;
+
+nr_pages = DIV_ROUND_UP(nr_lpis, PAGE_SIZE);
+get_guest_pages(v->domain, reg & GENMASK_ULL(51, 12), nr_pages);
+gprintk(XENLOG_INFO, "VGIC-v3: VCPU%d mapped %d pages for property 
table\n",
+   v->vcpu_id, nr_pages);
+}
+nr_pages = DIV_ROUND_UP(((nr_lpis + LPI_OFFSET) / 8), PAGE_SIZE);
+reg = v->arch.vgic.rdist_pendbase;
+
+get_guest_pages(v->domain, reg & GENMASK_ULL(51, 12), nr_pages);
+
+gprintk(XENLOG_INFO, "VGIC-v3: VCPU%d mapped %d pages for pending table\n",
+v->vcpu_id, nr_pages);
+
+v->arch.vgic.flags |= VGIC_V3_LPIS_ENABLED;
+
+printk("VGICv3: enabled %d LPIs for VCPU%d\n", nr_lpis, v->vcpu_id);
+}
+
 static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu *v, mmio_info_t *info,
   uint32_t gicr_reg,
   register_t r)
@@ -444,8 +478,18 @@ static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu *v, 
mmio_info_t *info,
 switch ( gicr_reg )
 {
 case VREG32(GICR_CTLR):
-/* LPI's not implemented */
-goto write_ignore_32;
+if ( dabt.size != DABT_WORD ) goto bad_width;
+if ( !v->domain->arch.vgic.has_its )
+return 1;
+
+/* LPIs can only be enabled once, but never disabled again. */
+if ( !(r & GICR_CTLR_ENABLE_LPIS) ||
+ (v->arch.vgic.flags & VGIC_V3_LPIS_ENABLED) )


This is fragile. A re-distributor can be updated from any vCPU. So you 
would end up to call vgic_vcpu_enable_lpis twice. You likely want to use 
a lock protecting the GICR_CTLR emulation



+return 1;
+
+vgic_vcpu_enable_lpis(v);
+
+return 1;

 case VREG32(GICR_IIDR):
 /* RO */
@@ -1045,6 +1089,11 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 typer = ((ncpus - 1) << GICD_TYPE_CPUS_SHIFT |
  DIV_ROUND_UP(v->domain->arch.vgic.nr_spis, 32));

+if ( v->domain->arch.vgic.has_its )
+{
+typer |= GICD_TYPE_LPIS;
+irq_bits = 16;


Why 16?


+}
 typer |= (irq_bits - 1) << GICD_TYPE_ID_BITS_SHIFT;

 *r = vgic_reg32_extract(typer, info);
@@ -1666,6 +1715,21 @@ static int vgic_v3_domain_init(struct domain *d)

 

Re: [Xen-devel] [PATCH] Libxc: fix xc_translate_foreign_address()

[Andrew Cooper]

On 04/04/17 17:45, Razvan Cojocaru wrote:
> On 04/04/2017 07:08 PM, Tamas K Lengyel wrote:
>>
>> On Tue, Apr 4, 2017 at 9:58 AM, Andrew Cooper > > wrote:
>>
>> On 04/04/17 16:39, Tamas K Lengyel wrote:
>>>
>>> On Tue, Apr 4, 2017 at 9:11 AM, Andrew Cooper
>>> > wrote:
>>>
>>> On 04/04/17 13:14, Razvan Cojocaru wrote:
>>> > Currently xc_translate_foreign_address only checks for PSE
>>> bit only on
>>> > level 2 entries (that's 2 MB pages on x64 and 32-bit with
>>> PAE, and 4 MB
>>> > pages on 32-bit). But linux kernel sometimes uses 1 GB
>>> pages. This patch
>>> > fixes that, and checks the PSE bit on level 3 entries if the
>>> guest has 4
>>> > translation levels (that means 64-bit guests only).
>>> >
>>> > Signed-off-by: Cristian-Bogdan Sirb >> >
>>>
>>> This function is in a rather tragic state.  Lucky it isn't
>>> used by code
>>> covered by Xen's security statement.
>>>
>>> This patch reintroduces XSA-176, and the existing code doesn't
>>> work for
>>> 4M superpages, or guests using PSE36.  (I might be acutely
>>> aware of
>>> pagetable issues, following c/s
>>> 4c5d78a10dc89).  Furthermore, the map/unmap overhead must be a
>>> large
>>> overhead.
>>>
>>>
>>> Indeed it is, that's why in LibVMI there is actually a cache
>>> implemented for mapped pages so we throw them away only after they
>>> have been idle for a while.
>>>  
>>>
>>>
>>> How often is this used by introspection?  To properly walk the
>>> pagetables, you need access to the CPUID information (as well
>>> as the
>>> control register state), and that isn't yet available to the
>>> toolstack
>>> in Xen.
>>>
>>>
>>> Control register state is certainly available.
>>>  
>>>
>>>
>>> I'm wondering whether it might be better to have a way of
>>> asking Xen to
>>> perform a virtual to linear translation in the context of a
>>> specific
>>> vcpu.  My gut feeling is that it might be quicker than running
>>> this
>>> logic, and is definitely more simple than trying to fix this
>>> code not to
>>> have vulnerabilities in it.
>>>
>>>
>>> I don't think it would be necessary. IMHO doing this in Xen
>>> wouldn't really net us much performance-wise. Furthermore, there
>>> are certain PTE bits that are OS specific and Xen wouldn't
>>> necessary have the required information to do the translation
>>> properly (ie. present bit unset but transition bits used for
>>> Windows guests).
>> Ok.  Xen needs to care only about the behaviour of real pointers in
>> guest context, and whether they raise #PF.
>>
>> It sounds like the best thing to do is to provide userspace with all
>> information it needs to actually perform the walk safely, and let
>> the library apply guest-specific knowledge if it wants.
>>
>> Off the top of my head, the control information needed is:
>>
>> Hap/Shadow, hardwares views towards page1gb and pse36, whether
>> EFER.NX is leaked from Xen, EFER.NX, CR0.{PG,WP},
>> CR4.{PAE,PSE,PCID,SMEP,SMAP,PKE}, and the PDPTRs for the 32bit PAE
>> case, because the translation in use isn't necessary the value you
>> would read by following CR3 in memory.
>>
>>
>> The userspace already has access to these informations and we use them
>> in LibVMI already (see
>> https://github.com/libvmi/libvmi/blob/master/libvmi/memory.c#L37). It's
>> only this libxc function that has not really been touched in a long time
>> because I don't think anyone uses it..
> Should it then be removed altogether, or at least be marked with a
> #warning or a comment?

Removing it entirely will break the gdbsx build.

As its current user is only for debugging, I think this functional fix
as proposed is fine, as long as it also adds a comment at the top
indicating that the use of this function is hazardous for your health in
production scenarios.

~Andrew

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

Re: [Xen-devel] [PATCH v4 25/27] ARM: vITS: create and initialize virtual ITSes for Dom0

[Julien Grall]

Hi Andre,

On 03/04/17 21:28, Andre Przywara wrote:

For each hardware ITS create and initialize a virtual ITS for Dom0.
We use the same memory mapped address to keep the doorbell working.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c   | 32 
 xen/arch/arm/vgic-v3.c   | 17 +
 xen/include/asm-arm/domain.h |  1 +
 xen/include/asm-arm/gic_v3_its.h | 16 
 4 files changed, 66 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 35a0730..dfb6eb3 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -1080,6 +1080,38 @@ static const struct mmio_handler_ops 
vgic_its_mmio_handler = {
 .write = vgic_v3_its_mmio_write,
 };

+int vgic_v3_its_init_virtual(struct domain *d, paddr_t guest_addr,
+ unsigned int devid_bits, unsigned int intid_bits)


*All* initialization functions should have a counterpart in the same 
patch to free the memory.



+{
+struct virt_its *its;
+uint64_t base_attr;
+
+its = xzalloc(struct virt_its);
+if ( ! its )
+return -ENOMEM;
+
+base_attr  = GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
+base_attr |= GIC_BASER_CACHE_SameAsInner << 
GITS_BASER_OUTER_CACHEABILITY_SHIFT;
+base_attr |= GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT;
+
+its->cbaser  = base_attr;
+base_attr |= 0ULL << GITS_BASER_PAGE_SIZE_SHIFT;


Please explain the 0ULL.


+its->baser_dev  = GITS_BASER_TYPE_DEVICE << GITS_BASER_TYPE_SHIFT;
+its->baser_dev |= (7ULL << GITS_BASER_ENTRY_SIZE_SHIFT) | base_attr;


Please explain 7ULL. I suspect you can use a sizeof of the device structure.


+its->baser_coll  = GITS_BASER_TYPE_COLLECTION << GITS_BASER_TYPE_SHIFT;
+its->baser_coll |= (1ULL << GITS_BASER_ENTRY_SIZE_SHIFT) | base_attr;


Please explain 1ULL. I suspect you can use a sizeof of the collection 
structure.



+its->d = d;
+its->doorbell_address = guest_addr + ITS_DOORBELL_OFFSET;
+its->devid_bits = devid_bits;
+its->intid_bits = intid_bits;
+spin_lock_init(>vcmd_lock);
+spin_lock_init(>its_lock);
+
+register_mmio_handler(d, _its_mmio_handler, guest_addr, SZ_64K, its);
+
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index ebcfc16..3fc309e 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1582,6 +1583,7 @@ static int vgic_v3_domain_init(struct domain *d)
  */
 if ( is_hardware_domain(d) )
 {
+struct host_its *hw_its;
 unsigned int first_cpu = 0;

 d->arch.vgic.dbase = vgic_v3_hw.dbase;
@@ -1607,6 +1609,21 @@ static int vgic_v3_domain_init(struct domain *d)

 first_cpu += size / d->arch.vgic.rdist_stride;
 }
+d->arch.vgic.nr_regions = vgic_v3_hw.nr_rdist_regions;


Why did you add that?



+
+list_for_each_entry(hw_its, _its_list, entry)


This could be done in vgic-v3-its.c. Also, I would prefer to see 
something similar to vgic_v3_setup_hw for ITS to make the code agnostic.



+{
+/*


Coding style.


+* For each host ITS create a virtual ITS using the same
+* base and thus doorbell address.
+* Use the same number of device ID bits as the host, and
+* allow 20 bits for the interrupt ID.


Why only 20? This sounds like a made up number that will not fit some 
platform... For the hardware domain you should the same value as used 
for the host ITS.



+*/
+vgic_v3_its_init_virtual(d, hw_its->addr, hw_its->devid_bits, 20);


Please check the return value.


+
+d->arch.vgic.has_its = true;
+}
+
 }
 else
 {
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index f460457..6a60630 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -115,6 +115,7 @@ struct arch_domain
 spinlock_t its_devices_lock;/* Protects the its_devices tree */
 struct radix_tree_root pend_lpi_tree; /* Stores struct pending_irq's */
 rwlock_t pend_lpi_tree_lock;/* Protects the pend_lpi_tree */
+bool has_its;
 #endif
 } vgic;

diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
index 3b5f898..fb05311 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -154,6 +154,14 @@ uint64_t gicv3_get_redist_address(unsigned int cpu, bool 
use_pta);
 int gicv3_its_setup_collection(unsigned int cpu);

 /*
+ * Create and register a virtual ITS at the given guest address.
+ * If a host ITS is specified, a hardware domain can reach out to that host
+ * ITS to deal with devices and LPI mappings and can enable/disable 

Re: [Xen-devel] [PATCH] xenbus: remove transaction holder from list before freeing

[Boris Ostrovsky]

On 04/04/2017 09:42 AM, Juergen Gross wrote:
> On 04/04/17 14:27, Jan Beulich wrote:
>> After allocation the item is being placed on the list right away.
>> Consequently it needs to be taken off the list before freeing in the
>> case xenbus_dev_request_and_reply() failed, as in that case the
>> callback (xenbus_dev_queue_reply()) is not being called (and if it
>> was called, it should do both).
>>
>> Fixes: 5584ea250ae44f929feb4c7bd3877d1c5edbf813
>> Signed-off-by: Jan Beulich 
> Reviewed-by: Juergen Gross 

Applied to for-linus-4.11b.

-boris

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

Re: [Xen-devel] [RFC XEN PATCH v2 00/15] Add vNVDIMM support to HVM domains

[Konrad Rzeszutek Wilk]

On Sat, Apr 01, 2017 at 08:45:45AM -0700, Dan Williams wrote:
> On Sat, Apr 1, 2017 at 4:54 AM, Konrad Rzeszutek Wilk  
> wrote:
> > ..snip..
> >> >> Is there a resource I can read more about why the hypervisor needs to
> >> >> have this M2P mapping for nvdimm support?
> >> >
> >> > M2P is basically an array of frame numbers. It's indexed by the host
> >> > page frame number, or the machine frame number (MFN) in Xen's
> >> > definition. The n'th entry records the guest page frame number that is
> >> > mapped to MFN n. M2P is one of the core data structures used in Xen
> >> > memory management, and is used to convert MFN to guest PFN. A
> >> > read-only version of M2P is also exposed as part of ABI to guest. In
> >> > the previous design discussion, we decided to put the management of
> >> > NVDIMM in the existing Xen memory management as much as possible, so
> >> > we need to build M2P for NVDIMM as well.
> >> >
> >>
> >> Thanks, but what I don't understand is why this M2P lookup is needed?
> >
> > Xen uses it to construct the EPT page tables for the guests.
> >
> >> Does Xen establish this metadata for PCI mmio ranges as well? What Xen
> >
> > It doesn't have that (M2P) for PCI MMIO ranges. For those it has an
> > ranges construct (since those are usually contingous and given
> > in ranges to a guest).
> 
> So, I'm confused again. This patchset / enabling requires both M2P and
> contiguous PMEM ranges. If the PMEM is contiguous it seems you don't
> need M2P and can just reuse the MMIO enabling, or am I missing
> something?

I think I am confusing you.

The patchset (specifically 04/15] xen/x86: add XEN_SYSCTL_nvdimm_pmem_setup to 
setup host pmem )
adds a hypercall to tell Xen where on the NVDIMM it can put 
the M2P array and as well the frametables ('struct page').

There is no range support. The reason is that if break up
an NVDIMM in various chunks (and then put a filesystem on top of it) - and
then figure out which of the SPAs belong to the file - and then
"expose" that file to a guest as NVDIMM - it's SPAs won't
be contingous. Hence the hypervisor would need to break down
the 'ranges' structure down in either a bitmap or an M2P
and also store it. This can get quite tricky so you may
as well just start with an M2P and 'struct page'.

The placement of those datastructures is "
v2 patch
   series relies on users/admins in Dom0 instead of Dom0 driver to indicate the
   location to store the frametable and M2P of pmem.
"

Hope this helps?
> 
> ___
> 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 24/27] ARM: vITS: handle INVALL command

[Julien Grall]

Hi Andre,

On 03/04/17 21:28, Andre Przywara wrote:

The INVALL command instructs an ITS to invalidate the configuration
data for all LPIs associated with a given redistributor (read: VCPU).
This is nasty to emulate exactly with our architecture, so we just scan
the pending table and inject _every_ LPI found there that got enabled.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c | 46 ++
 1 file changed, 46 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 920c437..35a0730 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -425,6 +425,49 @@ static int its_handle_inv(struct virt_its *its, uint64_t 
*cmdptr)
 return 0;
 }

+/*
+ * INVALL updates the per-LPI configuration status for every LPI mapped to
+ * a particular redistributor.
+ * We iterate over all mapped LPIs in our radix tree and update those.
+ */
+static int its_handle_invall(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t collid = its_cmd_get_collection(cmdptr);
+struct vcpu *vcpu;
+struct pending_irq *pirqs[16];
+uint32_t vlpi = 0;
+int nr_lpis, i;


Both nr_lpis and i should be unsigned int.


+
+/* We may want to revisit this implementation for DomUs. */


Please give a bit more details on what needs to be done.


+ASSERT(is_hardware_domain(its->d));
+
+spin_lock(>its_lock);
+vcpu = get_vcpu_from_collection(its, collid);
+spin_unlock(>its_lock);
+
+read_lock(>d->arch.vgic.pend_lpi_tree_lock);
+
+do {


do
{


+nr_lpis = radix_tree_gang_lookup(>d->arch.vgic.pend_lpi_tree,
+ (void **)pirqs, vlpi,
+ARRAY_SIZE(pirqs));


The 2 lines above are using hard tab. Please replace by soft tabs.


+
+for ( i = 0; i < nr_lpis; i++ )
+{
+vlpi = pirqs[i]->irq;
+update_lpi_enabled_status(its, vcpu, vlpi);


Don't you need to only invalidate on the current collection?


+}
+
+/* Protect from overflow when incrementing 0x */
+if ( vlpi == ~0 || ++vlpi < its->d->arch.vgic.nr_lpis )
+break;


Can't we just move vlpi to uint64_t?


+} while ( nr_lpis == ARRAY_SIZE(pirqs));


Coding style while ( ... );

Also this code is not obvious to read. I don't understand why until 
"nr_lpis == ARRAY_SIZE()". Can you explain it?



+
+read_unlock(>d->arch.vgic.pend_lpi_tree_lock);
+
+return 0;
+}
+
 static int its_handle_mapc(struct virt_its *its, uint64_t *cmdptr)
 {
 uint32_t collid = its_cmd_get_collection(cmdptr);
@@ -608,6 +651,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its,
 case GITS_CMD_INV:
 ret = its_handle_inv(its, cmdptr);
break;
+case GITS_CMD_INVALL:
+ret = its_handle_invall(its, cmdptr);
+   break;
 case GITS_CMD_MAPC:
 ret = its_handle_mapc(its, cmdptr);
 break;



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 23/27] ARM: vITS: handle INV command

[Julien Grall]

Hi Andre,

On 03/04/17 21:28, Andre Przywara wrote:

The INV command instructs the ITS to update the configuration data for
a given LPI by re-reading its entry from the property table.
We don't need to care so much about the priority value, but enabling
or disabling an LPI has some effect: We remove or push virtual LPIs
to their VCPUs, also check the virtual pending bit if an LPI gets enabled.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c | 62 ++
 1 file changed, 62 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 2f024b1..920c437 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -366,6 +366,65 @@ static int its_handle_int(struct virt_its *its, uint64_t 
*cmdptr)
 return 0;
 }

+/*
+ * For a given virtual LPI read the enabled bit and priority from the virtual
+ * property table and update the virtual IRQ's state.
+ * This takes care of removing or pushing of virtual LPIs to their VCPUs.
+ */
+static void update_lpi_enabled_status(struct virt_its* its,
+  struct vcpu *vcpu, uint32_t vlpi)
+{
+struct pending_irq *p = lpi_to_pending(its->d, vlpi);
+paddr_t proptable_addr;
+uint8_t *property;
+
+if ( !p )
+return;


Looking at the spec, I don't think it is mandatory to do an INV/INVALL 
after MAPTI. This could be done before, so how the priority will get 
updated?



+
+proptable_addr = its->d->arch.vgic.rdist_propbase & GENMASK_ULL(51, 12);
+property = map_one_guest_page(its->d, proptable_addr + vlpi - LPI_OFFSET);


What if the property table has not been configured correctly? I cannot 
find any code checking the re-distributor has been enabled before 
handling command and therefore no sanitizing.



+
+p->lpi_priority = *property & LPI_PROP_PRIO_MASK;
+
+if ( *property & LPI_PROP_ENABLED )
+{
+unsigned long flags;
+
+set_bit(GIC_IRQ_GUEST_ENABLED, >status);
+spin_lock_irqsave(>arch.vgic.lock, flags);
+if ( !list_empty(>inflight) &&
+ !test_bit(GIC_IRQ_GUEST_VISIBLE, >status) )
+gic_raise_guest_irq(vcpu, vlpi, p->lpi_priority);
+spin_unlock_irqrestore(>arch.vgic.lock, flags);
+
+/* Check whether the LPI has fired while the guest had it disabled. */
+if ( test_and_clear_bit(GIC_IRQ_GUEST_LPI_PENDING, >status) )
+vgic_vcpu_inject_irq(vcpu, vlpi);
+}
+else
+{
+clear_bit(GIC_IRQ_GUEST_ENABLED, >status);
+gic_remove_from_queues(vcpu, vlpi);
+}


This could looks quite similar to vgic_{enable,disable}_irqs. This is a 
call to refactor the code there.



+
+unmap_one_guest_page(property);
+}
+
+static int its_handle_inv(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+struct vcpu *vcpu;
+uint32_t vlpi;
+
+if ( !read_itte(its, devid, eventid, , ) )
+return -1;
+
+update_lpi_enabled_status(its, vcpu, vlpi);
+
+return 0;
+}
+
 static int its_handle_mapc(struct virt_its *its, uint64_t *cmdptr)
 {
 uint32_t collid = its_cmd_get_collection(cmdptr);
@@ -546,6 +605,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its,
 case GITS_CMD_INT:
 ret = its_handle_int(its, cmdptr);
 break;
+case GITS_CMD_INV:
+ret = its_handle_inv(its, cmdptr);
+   break;
 case GITS_CMD_MAPC:
 ret = its_handle_mapc(its, cmdptr);
 break;



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] Libxc: fix xc_translate_foreign_address()

[Razvan Cojocaru]

On 04/04/2017 07:08 PM, Tamas K Lengyel wrote:
> 
> 
> On Tue, Apr 4, 2017 at 9:58 AM, Andrew Cooper  > wrote:
> 
> On 04/04/17 16:39, Tamas K Lengyel wrote:
>>
>>
>> On Tue, Apr 4, 2017 at 9:11 AM, Andrew Cooper
>> > wrote:
>>
>> On 04/04/17 13:14, Razvan Cojocaru wrote:
>> > Currently xc_translate_foreign_address only checks for PSE
>> bit only on
>> > level 2 entries (that's 2 MB pages on x64 and 32-bit with
>> PAE, and 4 MB
>> > pages on 32-bit). But linux kernel sometimes uses 1 GB
>> pages. This patch
>> > fixes that, and checks the PSE bit on level 3 entries if the
>> guest has 4
>> > translation levels (that means 64-bit guests only).
>> >
>> > Signed-off-by: Cristian-Bogdan Sirb > >
>>
>> This function is in a rather tragic state.  Lucky it isn't
>> used by code
>> covered by Xen's security statement.
>>
>> This patch reintroduces XSA-176, and the existing code doesn't
>> work for
>> 4M superpages, or guests using PSE36.  (I might be acutely
>> aware of
>> pagetable issues, following c/s
>> 4c5d78a10dc89).  Furthermore, the map/unmap overhead must be a
>> large
>> overhead.
>>
>>
>> Indeed it is, that's why in LibVMI there is actually a cache
>> implemented for mapped pages so we throw them away only after they
>> have been idle for a while.
>>  
>>
>>
>> How often is this used by introspection?  To properly walk the
>> pagetables, you need access to the CPUID information (as well
>> as the
>> control register state), and that isn't yet available to the
>> toolstack
>> in Xen.
>>
>>
>> Control register state is certainly available.
>>  
>>
>>
>> I'm wondering whether it might be better to have a way of
>> asking Xen to
>> perform a virtual to linear translation in the context of a
>> specific
>> vcpu.  My gut feeling is that it might be quicker than running
>> this
>> logic, and is definitely more simple than trying to fix this
>> code not to
>> have vulnerabilities in it.
>>
>>
>> I don't think it would be necessary. IMHO doing this in Xen
>> wouldn't really net us much performance-wise. Furthermore, there
>> are certain PTE bits that are OS specific and Xen wouldn't
>> necessary have the required information to do the translation
>> properly (ie. present bit unset but transition bits used for
>> Windows guests).
> 
> Ok.  Xen needs to care only about the behaviour of real pointers in
> guest context, and whether they raise #PF.
> 
> It sounds like the best thing to do is to provide userspace with all
> information it needs to actually perform the walk safely, and let
> the library apply guest-specific knowledge if it wants.
> 
> Off the top of my head, the control information needed is:
> 
> Hap/Shadow, hardwares views towards page1gb and pse36, whether
> EFER.NX is leaked from Xen, EFER.NX, CR0.{PG,WP},
> CR4.{PAE,PSE,PCID,SMEP,SMAP,PKE}, and the PDPTRs for the 32bit PAE
> case, because the translation in use isn't necessary the value you
> would read by following CR3 in memory.
> 
> 
> The userspace already has access to these informations and we use them
> in LibVMI already (see
> https://github.com/libvmi/libvmi/blob/master/libvmi/memory.c#L37). It's
> only this libxc function that has not really been touched in a long time
> because I don't think anyone uses it..

Should it then be removed altogether, or at least be marked with a
#warning or a comment?


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH v4 05/14] golang/xenlight: Add tests host related functionality functions

[George Dunlap]

On Mon, Mar 20, 2017 at 6:15 PM, Ian Jackson  wrote:
> George Dunlap writes ("Re: [Xen-devel] [PATCH v4 05/14] golang/xenlight: Add 
> tests host related functionality functions"):
>> I had a chat with Ian Jackson, and we agreed that it would be better
>> to create a file, maybe "test-common.c", that would contain this
>> variable, as well as the three functions below.
>>
>> Then the header ("test-common.h") would contain *declarations* of the
>> variable (i.e., "extern xentoollog_logger_stdiostream *logger;") and
>> function prototypes.
>>
>> The test-common.c file is small now, but it may grow as additional
>> functionality is needed.
>
> Right.
>
>> The other thing you might consider, to further reduce the boilerplate
>> you have in each unit test file, is to also include a libxl_ctx
>> pointer in test-common; and have create_context() simply return an int
>> (0 for success, -1 for failure).
>
> This would be nice.
>
> You might also consider whether create_context would better simply
> exit the program if it fails.  That avoids any possibility of error
> handling bugs.  And maybe it should be called test_common_setup() ?
> (Names are a matter of taste, though.)
>
> Also: in C, main needs to return a value.  I'm surprised your compiler
> isn't complaining.  (Are the compiler warnings properly enabled?)  I
> think I mentioned this one before...

Actually I think in C if you don't call 'return', you end up getting
whatever the last value that was calculated as a return value instead.
At least I once had a colleague show me a program and ask, "Wait, why
does this work?" when he wrote a function that did a bunch of
calculations but never called return. :-)

Better to be explicit though.

 -George

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

Re: [Xen-devel] [PATCH v4 22/27] ARM: vITS: handle DISCARD command

[Julien Grall]

Hi Andre,

On 03/04/17 21:28, Andre Przywara wrote:

The DISCARD command drops the connection between a DeviceID/EventID
and an LPI/collection pair.
We mark the respective structure entries as not allocated and make
sure that any queued IRQs are removed.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index a2758cd..2f024b1 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -473,6 +473,33 @@ static int its_handle_movi(struct virt_its *its, uint64_t 
*cmdptr)
 return 0;
 }

+static int its_handle_discard(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+struct pending_irq *pirq;
+struct vcpu *vcpu;
+uint32_t vlpi;
+
+if ( !read_itte(its, devid, eventid, , ) )
+return -1;
+
+pirq = lpi_to_pending(its->d, vlpi);


Same question as usual about the pending_irq locking.


+if ( pirq )
+{
+clear_bit(GIC_IRQ_GUEST_QUEUED, >status);
+gic_remove_from_queues(vcpu, vlpi);
+}
+
+if ( !write_itte(its, devid, eventid, UNMAPPED_COLLECTION, INVALID_LPI, 
NULL) )
+return -1;
+
+gicv3_assign_guest_event(its->d, its->doorbell_address,
+ devid, eventid, NULL, 0);


Why the return value is not checked?


+
+return 0;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)

 static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
@@ -513,6 +540,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its,
 case GITS_CMD_CLEAR:
 ret = its_handle_clear(its, cmdptr);
 break;
+case GITS_CMD_DISCARD:
+ret = its_handle_discard(its, cmdptr);
+break;
 case GITS_CMD_INT:
 ret = its_handle_int(its, cmdptr);
 break;



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 21/27] ARM: vITS: handle MOVI command

[Julien Grall]

Hi Andre,

On 03/04/17 21:28, Andre Przywara wrote:

The MOVI command moves the interrupt affinity from one redistributor
(read: VCPU) to another.
For now migration of "live" LPIs is not yet implemented, but we store
the changed affinity in the host LPI structure and in our virtual ITTE.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v3-its.c| 24 
 xen/arch/arm/gic-v3-lpi.c| 13 +
 xen/arch/arm/vgic-v3-its.c   | 24 
 xen/include/asm-arm/gic_v3_its.h |  4 
 4 files changed, 65 insertions(+)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 3bc1e58..f611e2f 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -835,6 +835,30 @@ struct pending_irq *gicv3_assign_guest_event(struct domain 
*d,
 return pirq;
 }

+/* Changes the target VCPU for a given host LPI assigned to a domain. */
+int gicv3_lpi_change_vcpu(struct domain *d, paddr_t doorbell,
+  uint32_t vdevid, uint32_t veventid,
+  unsigned int vcpu_id)
+{
+uint32_t host_lpi;
+struct its_devices *dev;
+
+spin_lock(>arch.vgic.its_devices_lock);
+dev = get_its_device(d, doorbell, vdevid);
+if ( dev )
+host_lpi = get_host_lpi(dev, veventid);
+else
+host_lpi = 0;
+spin_unlock(>arch.vgic.its_devices_lock);
+
+if ( !host_lpi )
+return -ENOENT;
+
+gicv3_lpi_update_host_vcpuid(host_lpi, vcpu_id);
+
+return 0;
+}
+
 /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */
 void gicv3_its_dt_init(const struct dt_device_node *node)
 {
diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index 067ccb2..94c3646 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -206,6 +206,19 @@ void gicv3_lpi_update_host_entry(uint32_t host_lpi, int 
domain_id,
 write_u64_atomic(>data, hlpi.data);
 }

+int gicv3_lpi_update_host_vcpuid(uint32_t host_lpi, unsigned int vcpu_id)
+{
+union host_lpi *hlpip;
+
+host_lpi -= LPI_OFFSET;


The same ASSERT would be needed here.


+
+hlpip = _data.host_lpis[host_lpi / HOST_LPIS_PER_PAGE][host_lpi % 
HOST_LPIS_PER_PAGE];
+
+write_u16_atomic(>vcpu_id, vcpu_id);
+
+return 0;
+}
+
 static int gicv3_lpi_allocate_pendtable(uint64_t *reg)
 {
 uint64_t val;
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index e9a309d..a2758cd 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -455,6 +455,24 @@ static int its_handle_mapti(struct virt_its *its, uint64_t 
*cmdptr)
 return 0;
 }

+static int its_handle_movi(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+int collid = its_cmd_get_collection(cmdptr);
+struct vcpu *vcpu;
+
+if ( !write_itte(its, devid, eventid, collid, SKIP_LPI_UPDATE, ) )
+return -1;
+
+/* TODO: lookup currently-in-guest virtual IRQs and migrate them */
+
+gicv3_lpi_change_vcpu(its->d,
+  its->doorbell_address, devid, eventid, 
vcpu->vcpu_id);
+
+return 0;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)

 static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
@@ -508,6 +526,12 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its,
 case GITS_CMD_MAPTI:
 ret = its_handle_mapti(its, cmdptr);
 break;
+case GITS_CMD_MOVALL:
+gdprintk(XENLOG_G_INFO, "ITS: ignoring MOVALL command\n");


Why MOVALL is not implemented?


+break;
+case GITS_CMD_MOVI:
+ret = its_handle_movi(its, cmdptr);
+break;
 case GITS_CMD_SYNC:
 /* We handle ITS commands synchronously, so we ignore SYNC. */
break;
diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
index eeffd58..3b5f898 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -169,8 +169,12 @@ void gicv3_free_host_lpi_block(uint32_t first_lpi);
 struct pending_irq *gicv3_assign_guest_event(struct domain *d, paddr_t 
doorbell,
  uint32_t devid, uint32_t eventid,
  struct vcpu *v, uint32_t 
virt_lpi);
+int gicv3_lpi_change_vcpu(struct domain *d, paddr_t doorbell,
+  uint32_t devid, uint32_t eventid,
+  unsigned int vcpu_id);
 void gicv3_lpi_update_host_entry(uint32_t host_lpi, int domain_id,
  unsigned int vcpu_id, uint32_t virt_lpi);
+int gicv3_lpi_update_host_vcpuid(uint32_t host_lpi, unsigned int vcpu_id);

 #else




Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 20/27] ARM: vITS: handle MAPTI command

[Julien Grall]

Hi Andre,

On 03/04/17 21:28, Andre Przywara wrote:

The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
pair and actually instantiates LPI interrupts.
We connect the already allocated host LPI to this virtual LPI, so that
any triggering IRQ on the host can be quickly forwarded to a guest.
Beside entering the VCPU and the virtual LPI number in the respective
host LPI entry, we also initialize and add the already allocated
struct pending_irq to our radix tree, so that we can now easily find it
by its virtual LPI number.
This exports the vgic_init_pending_irq() function for that purpose.
As write_itte() is now eventually used, we can now add the static tag.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v3-its.c| 70 
 xen/arch/arm/gic-v3-lpi.c| 18 +++
 xen/arch/arm/vgic-v3-its.c   | 36 +++--
 xen/arch/arm/vgic.c  |  2 +-
 xen/include/asm-arm/gic_v3_its.h |  6 
 xen/include/asm-arm/vgic.h   |  1 +
 6 files changed, 130 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 880c7fc..3bc1e58 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -765,6 +765,76 @@ void gicv3_its_unmap_all_devices(struct domain *d)
 spin_unlock(>arch.vgic.its_devices_lock);
 }

+/* Must be called with the its_device_lock held. */


This is a call for adding an ASSERT.


+static struct its_devices *get_its_device(struct domain *d, paddr_t doorbell,
+  uint32_t devid)
+{
+struct rb_node *node = d->arch.vgic.its_devices.rb_node;
+struct its_devices *dev;


[...]



+/*
+ * Connects the event ID for an already assigned device to the given VCPU/vLPI
+ * pair. The corresponding physical LPI is already mapped on the host side
+ * (when assigning the physical device to the guest), so we just connect the
+ * target VCPU/vLPI pair to that interrupt to inject it properly if it fires.
+ */
+struct pending_irq *gicv3_assign_guest_event(struct domain *d,
+ paddr_t doorbell_address,


This is the guest ITS doorbell. Right? So please prefix with v.


+ uint32_t vdevid, uint32_t 
veventid,
+ struct vcpu *v, uint32_t virt_lpi)
+{
+struct its_devices *dev;
+struct pending_irq *pirq = NULL;
+uint32_t host_lpi = 0;
+
+spin_lock(>arch.vgic.its_devices_lock);
+dev = get_its_device(d, doorbell_address, vdevid);
+if ( dev )
+{
+host_lpi = get_host_lpi(dev, veventid);
+pirq = >pend_irqs[veventid];
+}
+spin_unlock(>arch.vgic.its_devices_lock);
+
+if ( !host_lpi || !pirq )
+return NULL;
+
+gicv3_lpi_update_host_entry(host_lpi, d->domain_id,
+v ? v->vcpu_id : -1, virt_lpi);


s/-1/INVALID_VCPU_ID/

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 2/9] mm: Place unscrubbed pages at the end of pagelist

[Boris Ostrovsky]

On 04/04/2017 11:50 AM, Jan Beulich wrote:
 On 04.04.17 at 17:39,  wrote:
>> On 04/04/2017 11:29 AM, Jan Beulich wrote:
>> On 04.04.17 at 17:14,  wrote:
 On 04/04/2017 10:46 AM, Jan Beulich wrote:
>> @@ -933,6 +952,10 @@ static bool_t can_merge(struct page_info *buddy, 
>> unsigned int node,
>>   (phys_to_nid(page_to_maddr(buddy)) != node) )
>>  return false;
>>  
>> +if ( need_scrub !=
>> + !!test_bit(_PGC_need_scrub, >count_info) )
>> +return false;
> I don't think leaving the tree in a state where larger order chunks
> don't become available for allocation right away is going to be
> acceptable. Hence with this issue being dealt with only in patch 7
> as it seems, you should state clearly and visibly that (at least)
> patches 2...7 should only be committed together.
 The dirty pages are available for allocation as result of this patch but
 they might not be merged with higher orders (which is what this check is
 for)
>>> The individual chunks are available for allocation, but not the
>>> combined one (for a suitably high order request). Or am I
>>> missing something?
>>
>> Correct, but this is not changed by any later patch (including patch 7).
>> We only merge with a buddy with the same level of cleanliness (so to
>> speak ;-))
> Hmm, that aspect was one of the main things I had objected to
> back when one of your colleagues had a first take at this.

I thought your objections were over having a period of time when a chunk
is removed from heap for scrubbing and this is not available at all.


>
>> But then we will always have to scan the buddy during allocation to see
>> if any pages are dirty.
> There could be a summary flag to avoid this for entirely clean
> buddies. Plus perhaps some auxiliary indication where the first
> unclean part is, to speed up the scanning.


This should be doable. Let me work on this.

-boris


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

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

[osstest service owner]

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

Failures and problems with tests :-(

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. 107166
 test-amd64-amd64-xl-pvh-amd   3 host-install(3)broken REGR. vs. 107166

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

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
 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-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-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
 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  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-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-amd64-amd64-libvirt 12 migrate-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-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 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 12 migrate-support-checkfail   never pass

version targeted for testing:
 qemuud9123d09f711bf1b855de2b5a907d4c85f46d6c3
baseline version:
 qemuub1a419ec79c2451fd7b6acfb415a02881ad77844

Last test of basis   107166  2017-04-03 21:45:48 Z0 days
Testing same since   107175  2017-04-04 08:57:40 Z0 days1 attempts


People who touched revisions under test:
  Peter Maydell 

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

Re: [Xen-devel] [PATCH v4 08/27] ARM: GICv3 ITS: introduce device mapping

[Julien Grall]

Hi Andre,

On 03/04/17 21:28, Andre Przywara wrote:

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index bd189e8..c7c32b9 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -36,6 +38,26 @@
  */
 LIST_HEAD(host_its_list);

+/*
+ * Describes a device which is using the ITS and is used by a guest.
+ * Since device IDs are per ITS (in contrast to vLPIs, which are per
+ * guest), we have to differentiate between different virtual ITSes.
+ * We use the doorbell address here, since this is a nice architectural
+ * property of MSIs in general and we can easily get to the base address
+ * of the ITS and look that up.
+ */
+struct its_devices {


Just spotted, why its_devices? You only store the information for one 
device.



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 19/27] ARM: vITS: handle MAPD command

[Julien Grall]

Hi Andre,

On 03/04/17 21:28, Andre Przywara wrote:

The MAPD command maps a device by associating a memory region for
storing ITEs with a certain device ID.
We store the given guest physical address in the device table, and, if
this command comes from Dom0, tell the host ITS driver about this new
mapping, so it can issue the corresponing host MAPD command and create


s/corresponing/corresponding/


the required tables.
We don't map the device tables permanently, as their alignment
requirement is only 256 Bytes, thus making mapping of several tables
complicated. Instead we map the device tables on demand when we need
them later.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c | 63 ++
 1 file changed, 63 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 639fbbf..0e636de 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -42,6 +42,7 @@
 #define VIRT_ITS_CMDBUF_VALID   3
 struct virt_its {
 struct domain *d;
+paddr_t doorbell_address;
 spinlock_t vcmd_lock;   /* Protects the virtual command buffer. */
 uint64_t cbaser;
 uint64_t cwriter;
@@ -142,6 +143,27 @@ static struct vcpu *get_vcpu_from_collection(struct 
virt_its *its,
 #define DEV_TABLE_ENTRY(addr, bits) \
 (((addr) & GENMASK_ULL(51, 8)) | (((bits) - 1) & GENMASK_ULL(7, 0)))

+/* Set the address of an ITT for a given device ID. */
+static int its_set_itt_address(struct virt_its *its, uint32_t devid,
+   paddr_t itt_address, uint32_t nr_bits)
+{
+paddr_t addr = get_baser_phys_addr(its->baser_dev);
+uint64_t *itt;
+
+if ( devid >= its->max_devices )
+return -ENOENT;
+
+itt = map_one_guest_page(its->d, addr + devid * sizeof(uint64_t));
+if ( !itt )
+return -EFAULT;
+
+*itt = DEV_TABLE_ENTRY(itt_address, nr_bits);
+
+unmap_one_guest_page(itt);
+
+return 0;
+}
+
 /*
  * Lookup the address of the Interrupt Translation Table associated with
  * a device ID and return the address of the ITTE belonging to the event ID
@@ -367,6 +389,44 @@ static int its_handle_mapc(struct virt_its *its, uint64_t 
*cmdptr)
 return 0;
 }

+static int its_handle_mapd(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+unsigned int size = its_cmd_get_size(cmdptr) + 1;
+bool valid = its_cmd_get_validbit(cmdptr);
+paddr_t itt_addr = its_cmd_mask_field(cmdptr, 2, 0, 52) &
+   GENMASK_ULL(51, 8);
+int ret;


The size should be sanitized against the number of event support by the 
vITS.



+
+/*
+ * There is no easy and clean way for Xen to know the ITS device ID of a
+ * particular (PCI) device, so we have to rely on the guest telling
+ * us about it. For *now* we are just using the device ID *Dom0* uses,
+ * because the driver there has the actual knowledge.
+ * Eventually this will be replaced with a dedicated hypercall to
+ * announce pass-through of devices.
+ */
+if ( is_hardware_domain(its->d) )
+{
+/* Dom0's ITSes are mapped 1:1, so both address are the same. */
+ret = gicv3_its_map_guest_device(its->d, its->doorbell_address, devid,
+ its->doorbell_address, devid,
+ BIT(size), valid);
+if ( ret )
+return ret;
+}
+
+spin_lock(>its_lock);
+if ( valid )
+ret = its_set_itt_address(its, devid, itt_addr, size);
+else
+ret = its_set_itt_address(its, devid, INVALID_PADDR, 1);
+
+spin_unlock(>its_lock);
+
+return ret;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)

 static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
@@ -413,6 +473,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its,
 case GITS_CMD_MAPC:
 ret = its_handle_mapc(its, cmdptr);
 break;
+case GITS_CMD_MAPD:
+ret = its_handle_mapd(its, cmdptr);
+   break;
 case GITS_CMD_SYNC:
 /* We handle ITS commands synchronously, so we ignore SYNC. */
break;



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] Libxc: fix xc_translate_foreign_address()

[Tamas K Lengyel]

On Tue, Apr 4, 2017 at 9:58 AM, Andrew Cooper 
wrote:

> On 04/04/17 16:39, Tamas K Lengyel wrote:
>
>
>
> On Tue, Apr 4, 2017 at 9:11 AM, Andrew Cooper 
> wrote:
>
>> On 04/04/17 13:14, Razvan Cojocaru wrote:
>> > Currently xc_translate_foreign_address only checks for PSE bit only on
>> > level 2 entries (that's 2 MB pages on x64 and 32-bit with PAE, and 4 MB
>> > pages on 32-bit). But linux kernel sometimes uses 1 GB pages. This patch
>> > fixes that, and checks the PSE bit on level 3 entries if the guest has 4
>> > translation levels (that means 64-bit guests only).
>> >
>> > Signed-off-by: Cristian-Bogdan Sirb 
>>
>> This function is in a rather tragic state.  Lucky it isn't used by code
>> covered by Xen's security statement.
>>
>> This patch reintroduces XSA-176, and the existing code doesn't work for
>> 4M superpages, or guests using PSE36.  (I might be acutely aware of
>> pagetable issues, following c/s
>> 4c5d78a10dc89).  Furthermore, the map/unmap overhead must be a large
>> overhead.
>>
>
> Indeed it is, that's why in LibVMI there is actually a cache implemented
> for mapped pages so we throw them away only after they have been idle for a
> while.
>
>
>>
>> How often is this used by introspection?  To properly walk the
>> pagetables, you need access to the CPUID information (as well as the
>> control register state), and that isn't yet available to the toolstack
>> in Xen.
>>
>
> Control register state is certainly available.
>
>
>>
>> I'm wondering whether it might be better to have a way of asking Xen to
>> perform a virtual to linear translation in the context of a specific
>> vcpu.  My gut feeling is that it might be quicker than running this
>> logic, and is definitely more simple than trying to fix this code not to
>> have vulnerabilities in it.
>
>
> I don't think it would be necessary. IMHO doing this in Xen wouldn't
> really net us much performance-wise. Furthermore, there are certain PTE
> bits that are OS specific and Xen wouldn't necessary have the required
> information to do the translation properly (ie. present bit unset but
> transition bits used for Windows guests).
>
>
> Ok.  Xen needs to care only about the behaviour of real pointers in guest
> context, and whether they raise #PF.
>
> It sounds like the best thing to do is to provide userspace with all
> information it needs to actually perform the walk safely, and let the
> library apply guest-specific knowledge if it wants.
>
> Off the top of my head, the control information needed is:
>
> Hap/Shadow, hardwares views towards page1gb and pse36, whether EFER.NX is
> leaked from Xen, EFER.NX, CR0.{PG,WP}, CR4.{PAE,PSE,PCID,SMEP,SMAP,PKE},
> and the PDPTRs for the 32bit PAE case, because the translation in use isn't
> necessary the value you would read by following CR3 in memory.
>

The userspace already has access to these informations and we use them in
LibVMI already (see
https://github.com/libvmi/libvmi/blob/master/libvmi/memory.c#L37). It's
only this libxc function that has not really been touched in a long time
because I don't think anyone uses it..

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

Re: [Xen-devel] linux-next: manual merge of the xen-tip tree with the tip tree

[Juergen Gross]

On 04/04/17 18:04, Vitaly Kuznetsov wrote:
> Juergen Gross  writes:
> 
>> On 29/03/17 12:06, Vitaly Kuznetsov wrote:
>>> Juergen Gross  writes:
 I'll create another branch for-linus-4.12 based on the tip tree next
 week which will be subject to the pull request for Linus. As soon as
 for-linus-4.12 is ready the for-linus-4.12-pre branch shouldn't be used
 any longer.
>>>
>>> Please let me know if/when I need to rebase my series. I'll rebase, test
>>> and re-send.
>>
>> Vitaly, I've created the (new) for-linus-4.12 branch on xen/tip. It is
>> based on the x86-mm-for-xen branch of tip/tip containing the 5-level
>> page table patches. Please rebase your patches to this branch.
> 
> Pushed the rebased series to https://github.com/vittyvk/linux.git
> (xen_pv_hvm_split_v4 branch), this includes your fixup patch. No
> functional changes, all tags preserved.
> 
> I smoke tested the rebased patchset by doing PV-and-HVM, PV-only,
> HVM-only builds and booting different guest types, no issues noticed.
> 
> Please let me know if you prefer me to post patches to the mailing list
> instead. Thanks!
> 

I think the git repo is fine.

Thanks for doing the rebase work,


Juergen

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

Re: [Xen-devel] [PATCH v4 18/27] ARM: vITS: handle MAPC command

[Julien Grall]

Hi Andre,

On 03/04/17 21:28, Andre Przywara wrote:

+static int its_handle_mapc(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t collid = its_cmd_get_collection(cmdptr);
+uint64_t rdbase = its_cmd_mask_field(cmdptr, 2, 16, 44);
+
+if ( collid >= its->max_collections )
+return -1;
+
+if ( rdbase >= its->d->max_vcpus )
+return -1;
+
+spin_lock(>its_lock);


Looking at the lock here, it looks like to me you want to move it down 
to its_set_collection.



+
+if ( its_cmd_get_validbit(cmdptr) )
+its_set_collection(its, collid, rdbase);
+else
+its_set_collection(its, collid, UNMAPPED_COLLECTION);
+
+spin_unlock(>its_lock);
+
+return 0;
+}
+


Cheers,

--
Julien Grall

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

Re: [Xen-devel] Legacy PCI interrupt {de}assertion count

[Konrad Rzeszutek Wilk]

On Mon, Apr 03, 2017 at 02:22:36PM +0200, Sander Eikelenboom wrote:
> On 31/03/17 16:38, Konrad Rzeszutek Wilk wrote:
> > On Fri, Mar 31, 2017 at 04:46:27AM -0600, Jan Beulich wrote:
> > On 31.03.17 at 10:07,  wrote:
> >>> On Fri, Mar 31, 2017 at 05:05:44AM +, Tian, Kevin wrote:
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: Monday, March 27, 2017 4:00 PM
> >
>  On 24.03.17 at 17:54,  wrote:
> >> As I understand it, for level triggered legacy PCI interrupts Xen sets
> >> up a timer in order to perform the EOI if the guest takes too long in
> >> deasserting the line. This is done in pt_irq_time_out. What I don't
> >> understand is why this function also does a deassertion of the guest 
> >> view
> > of the PCI interrupt, ie:
> >> why it calls hvm_pci_intx_deassert. This AFAICT will clear the pending
> >> assert in the guest, and thus the guest will end up loosing one 
> >> interrupt.
> >
> > Especially with the comment next to the respective set_timer() it looks 
> > to me
> > as if this was the intended effect: If the guest didn't care to at 
> > least start
> > handling the interrupt within PT_IRQ_TIME_OUT, we want it look to be 
> > lost in
> > order to not have it block other interrupts inside the guest (i.e. 
> > there's more
> > to it than just guarding the host here).
> >
> > "Luckily" commit 0f843ba00c ("vt-d: Allow pass-through of shared
> > interrupts") introducing this has no description at all. Let's see if 
> > Kevin
> > remembers any further details ...
> >
> 
>  Sorry I don't remember more detail other than existing comments.
>  Roger, did you encounter a problem now?
> >>>
> >>> No, I didn't encounter any problems with this so far, any well behaved 
> >>> guest
> >>> will deassert those lines anyway, it just seems to be against the spec.  
> >>> AFAIK
> >>> on bare metal the line will be asserted until the OS deasserts it, so I 
> >>> was
> >>> wondering if this was some kind of workaround?
> >>
> >> "OS deasserts" is a term I don't understand. Aiui it's the origin device
> >> which would need to de-assert its interrupt, and I think it is not
> >> uncommon for devices to de-assert interrupts after a certain amount
> >> of time. If that wasn't the case, spurious interrupts could never occur.
> > 
> > I recall Sander (CC-ed) here hitting this at some point. There was some 
> > device
> > he had (legacy?) that would very much hit this path.
> > 
> > But I can't recall the details, sorry.
> > 
> > Sanders, it was in the context of the dpci softirq work I did if that helps.
> 
> Hi Konrad,
> 
> You mean these ?

Yes, but I can't seem to find in those threads the name of the
device you had - the one that was triggering those legacy
interrupts.. By any chance you recall what it was?

> 
> The issue leading up to this revert for xen-4.5: 
> https://lists.xen.org/archives/html/xen-devel/2015-01/msg01025.html
> 
> Where this seems to be the thread that started the conversation leading up to 
> that revert: 
> https://lists.xenproject.org/archives/html/xen-devel/2014-11/msg01330.html
> 
> Which than for xen-4.6 continued in a thread with the subject "dpci: Put the 
> dpci back on the list if scheduled from another CPU."
> which is spread out over several months, (this is somewhere in between 
> https://lists.xenproject.org/archives/html/xen-devel/2015-03/msg02102.html ).
> 
> --
> Sander
> 
> >>
> >> Jan
> >>
> >>
> >> ___
> >> 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 17/27] ARM: vITS: handle INT command

[Julien Grall]

Hi Andre,

On 03/04/17 21:28, Andre Przywara wrote:

The INT command sets a given LPI identified by a DeviceID/EventID pair
as pending and thus triggers it to be injected.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index cc1d7a0..dd43eaf 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -297,6 +297,33 @@ static int its_handle_clear(struct virt_its *its, uint64_t 
*cmdptr)
 return 0;
 }

+static int its_handle_int(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+struct pending_irq *p;
+struct vcpu *vcpu;
+uint32_t vlpi;
+
+if ( !read_itte(its, devid, eventid, , ) )
+return -1;
+
+p = lpi_to_pending(its->d, vlpi);


See my question about pending_irq locking earlier on.


+if ( !p )
+return -1;
+
+/*
+ * If the LPI is enabled, inject it.
+ * If not, store the pending state to inject it once it gets enabled later.
+ */
+if ( test_bit(GIC_IRQ_GUEST_ENABLED, >status) )
+vgic_vcpu_inject_irq(vcpu, vlpi);
+else
+set_bit(GIC_IRQ_GUEST_LPI_PENDING, >status);
+
+return 0;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)

 static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
@@ -337,6 +364,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its,
 case GITS_CMD_CLEAR:
 ret = its_handle_clear(its, cmdptr);
 break;
+case GITS_CMD_INT:
+ret = its_handle_int(its, cmdptr);
+break;
 case GITS_CMD_SYNC:
 /* We handle ITS commands synchronously, so we ignore SYNC. */
break;



Cheers,

--
Julien Grall

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

Re: [Xen-devel] linux-next: manual merge of the xen-tip tree with the tip tree

[Vitaly Kuznetsov]

Juergen Gross  writes:

> On 29/03/17 12:06, Vitaly Kuznetsov wrote:
>> Juergen Gross  writes:
>>> I'll create another branch for-linus-4.12 based on the tip tree next
>>> week which will be subject to the pull request for Linus. As soon as
>>> for-linus-4.12 is ready the for-linus-4.12-pre branch shouldn't be used
>>> any longer.
>> 
>> Please let me know if/when I need to rebase my series. I'll rebase, test
>> and re-send.
>
> Vitaly, I've created the (new) for-linus-4.12 branch on xen/tip. It is
> based on the x86-mm-for-xen branch of tip/tip containing the 5-level
> page table patches. Please rebase your patches to this branch.

Pushed the rebased series to https://github.com/vittyvk/linux.git
(xen_pv_hvm_split_v4 branch), this includes your fixup patch. No
functional changes, all tags preserved.

I smoke tested the rebased patchset by doing PV-and-HVM, PV-only,
HVM-only builds and booting different guest types, no issues noticed.

Please let me know if you prefer me to post patches to the mailing list
instead. Thanks!

-- 
  Vitaly

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

Re: [Xen-devel] [PATCH v4 16/27] ARM: vITS: handle CLEAR command

[Julien Grall]

Hi Andre,

On 03/04/17 21:28, Andre Przywara wrote:

This introduces the ITS command handler for the CLEAR command, which
clears the pending state of an LPI.
This removes a not-yet injected, but already queued IRQ from a VCPU.
As read_itte() is now eventually used, we add the static keyword.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index fcfea3b..cc1d7a0 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -186,8 +186,8 @@ static void put_itte(struct virt_its *its, struct vits_itte 
*itte)
  * This function takes care of the locking by taking the its_lock itself, so
  * a caller shall not hold this. Upon returning, the lock is dropped again.
  */
-bool read_itte(struct virt_its *its, uint32_t devid, uint32_t evid,
-   struct vcpu **vcpu, uint32_t *vlpi)
+static bool read_itte(struct virt_its *its, uint32_t devid, uint32_t evid,
+  struct vcpu **vcpu, uint32_t *vlpi)
 {
 struct vits_itte *itte;
 uint16_t collid;
@@ -273,6 +273,30 @@ static uint64_t its_cmd_mask_field(uint64_t *its_cmd, 
unsigned int word,
 #define its_cmd_get_target_addr(cmd)its_cmd_mask_field(cmd, 2, 16, 32)
 #define its_cmd_get_validbit(cmd)   its_cmd_mask_field(cmd, 2, 63,  1)

+static int its_handle_clear(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+struct pending_irq *p;
+struct vcpu *vcpu;
+uint32_t vlpi;
+
+if ( !read_itte(its, devid, eventid, , ) )
+return -1;
+
+p = lpi_to_pending(its->d, vlpi);
+if ( !p )
+return -1;
+
+clear_bit(GIC_IRQ_GUEST_LPI_PENDING, >status);
+
+/* Remove a pending, but not yet injected guest IRQ. */


Copying Stefano's comment from last year:

"We need to check that the vlpi hasn't already been added to an LR
register. We can do that with GIC_IRQ_GUEST_VISIBLE.

In case GIC_IRQ_GUEST_VISIBLE is set, we need to clear the lr
(clear_lr). If we don't handle this case, we should at least print a
warning."

I will let Stefano comments more here.


+clear_bit(GIC_IRQ_GUEST_QUEUED, >status);
+gic_remove_from_queues(vcpu, vlpi);
+
+return 0;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)

 static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
@@ -310,6 +334,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its,

 switch ( its_cmd_get_command(cmdptr) )
 {
+case GITS_CMD_CLEAR:
+ret = its_handle_clear(its, cmdptr);
+break;
 case GITS_CMD_SYNC:
 /* We handle ITS commands synchronously, so we ignore SYNC. */
break;



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 15/27] ARM: vITS: introduce translation table walks

[Julien Grall]

Hi Andre,

On 03/04/17 21:28, Andre Przywara wrote:

The ITS stores the target (v)CPU and the (virtual) LPI number in tables.
Introduce functions to walk those tables and translate an device ID -
event ID pair into a pair of virtual LPI and vCPU.
We map those tables on demand - which is cheap on arm64. Also we take
care of the locking on the way, since we can't easily protect those ITTs
from being altered by the guest.

To allow compiling without warnings, we declare two functions as
non-static for the moment, which two later patches will fix.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c | 183 +
 1 file changed, 183 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index fd3b9a1..fcfea3b 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -71,6 +71,189 @@ static bool its_is_enabled(struct virt_its *its)
 return test_bit(VIRT_ITS_ENABLED, >flags);
 }

+#define UNMAPPED_COLLECTION  ((uint16_t)~0)
+
+/*
+ * The physical address is encoded slightly differently depending on
+ * the used page size: the highest four bits are stored in the lowest
+ * four bits of the field for 64K pages.
+ */
+static paddr_t get_baser_phys_addr(uint64_t reg)
+{
+if ( reg & BIT(9) )
+return (reg & GENMASK_ULL(47, 16)) |
+((reg & GENMASK_ULL(15, 12)) << 36);
+else
+return reg & GENMASK_ULL(47, 12);
+}
+
+/* Must be called with the ITS lock held. */


Again, this is a call for an ASSERT(...).


+static struct vcpu *get_vcpu_from_collection(struct virt_its *its,
+ uint16_t collid)
+{
+paddr_t addr = get_baser_phys_addr(its->baser_coll);
+uint16_t *coll_table;
+uint16_t vcpu_id;
+
+if ( collid >= its->max_collections )
+return NULL;
+
+coll_table = map_one_guest_page(its->d, addr + collid * sizeof(uint16_t));
+if ( !coll_table )
+return NULL;
+
+vcpu_id = *coll_table;
+
+unmap_one_guest_page(coll_table);
+
+if ( vcpu_id == UNMAPPED_COLLECTION || vcpu_id >= its->d->max_vcpus )
+return NULL;
+
+return its->d->vcpu[vcpu_id];
+}
+
+/*
+ * Our device table encodings:
+ * Contains the guest physical address of the Interrupt Translation Table in
+ * bits [51:8], and the size of it encoded in the lowest 8 bits.


The size is in term of bits, correct? If so, can you clarify in it in 
the comment?



+ */
+#define DEV_TABLE_ITT_ADDR(x) ((x) & GENMASK_ULL(51, 8))
+#define DEV_TABLE_ITT_SIZE(x) (BIT(((x) & GENMASK_ULL(7, 0)) + 1))
+#define DEV_TABLE_ENTRY(addr, bits) \
+(((addr) & GENMASK_ULL(51, 8)) | (((bits) - 1) & GENMASK_ULL(7, 0)))
+
+/*
+ * Lookup the address of the Interrupt Translation Table associated with
+ * a device ID and return the address of the ITTE belonging to the event ID
+ * (which is an index into that table).
+ */
+static paddr_t its_get_itte_address(struct virt_its *its,
+uint32_t devid, uint32_t evid)
+{
+paddr_t ret, addr = get_baser_phys_addr(its->baser_dev);
+uint64_t *itt_ptr;
+uint64_t itt;


What is the plan for two-level page support for vITS?


+
+if ( devid >= its->max_devices )
+return INVALID_PADDR;
+
+itt_ptr = map_one_guest_page(its->d, addr + devid * sizeof(uint64_t));
+if ( !itt_ptr )
+return INVALID_PADDR;
+
+itt = read_u64_atomic(itt_ptr);
+
+if ( evid < DEV_TABLE_ITT_SIZE(itt) &&
+ DEV_TABLE_ITT_ADDR(itt) != INVALID_PADDR )
+ret = DEV_TABLE_ITT_ADDR(itt) + evid * sizeof(struct vits_itte);
+else
+ret = INVALID_PADDR;
+
+unmap_one_guest_page(itt_ptr);
+
+return ret;
+}
+
+/*
+ * Looks up a given deviceID/eventID pair on an ITS and returns a pointer to
+ * the corresponding ITTE. This maps the respective guest page into Xen.
+ * Once finished with handling the ITTE, call put_itte() to unmap
+ * the page again.
+ * Must be called with the ITS lock held.


This is a call for adding an ASSERT.


+ */
+static struct vits_itte *get_itte(struct virt_its *its,
+  uint32_t devid, uint32_t evid)
+{
+paddr_t addr = its_get_itte_address(its, devid, evid);
+
+if ( addr == INVALID_PADDR )
+return NULL;
+
+return map_one_guest_page(its->d, addr);
+}
+
+/* Must be called with the ITS lock held. */


Ditto.


+static void put_itte(struct virt_its *its, struct vits_itte *itte)
+{
+unmap_one_guest_page(itte);
+}
+
+/*
+ * Queries the collection and device tables to get the vCPU and virtual
+ * LPI number for a given guest event. This takes care of mapping the
+ * respective tables and validating the values, since we can't efficiently
+ * protect the ITTs with their less-than-page-size granularity.
+ * This function takes care of the locking by taking the its_lock itself, so
+ * a caller shall not hold this. Upon returning, the 

Re: [Xen-devel] [PATCH] kexec: clear kexec_image slot when unloading kexec image

[Bhavesh Davda]

> That's not how we do things normally. You could have looked at a
> couple of patches sent by others...
> 
> Jan

Well, naturally I tried doing that first, but due to the follies of statistical 
sampling, unfortunately the several patches I looked at on xen-devel didn’t 
have the more verbose description that’s not part of the commit log, or had a 
separate cover letter e-mail as [PATCH 00] of a series with the more verbose 
descriptions.

Like I said though, mea culpa, and I’ll be more careful next time :)

Thanks

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

Re: [Xen-devel] [PATCH v2 15/27] ARM: vITS: introduce translation table walks

[Julien Grall]

Hi Andre,

On 03/04/17 19:25, Andre Przywara wrote:

On 24/03/17 13:00, Julien Grall wrote:

On 03/16/2017 11:20 AM, Andre Przywara wrote:

+ */
+bool read_itte(struct virt_its *its, uint32_t devid, uint32_t evid,
+   struct vcpu **vcpu, uint32_t *vlpi)
+{
+struct vits_itte *itte;
+int collid;
+uint32_t _vlpi;
+struct vcpu *_vcpu;
+
+spin_lock(>its_lock);


Do we expect multiple vCPU calling read_itte at the same time? This
needs to be clarify in the comments because this current function is not
scalable.


We need this lock here because this protects our data structures.
A guest locks accesses to the ITS command queue anyway (otherwrite
multiple VCPUs would race for CWRITER and CREADR), so I don't see a real
problem. And this lock is pre ITS, not per guest.


Fair point, please ignore my request then.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] Libxc: fix xc_translate_foreign_address()

[Andrew Cooper]

On 04/04/17 16:39, Tamas K Lengyel wrote:
>
>
> On Tue, Apr 4, 2017 at 9:11 AM, Andrew Cooper
> > wrote:
>
> On 04/04/17 13:14, Razvan Cojocaru wrote:
> > Currently xc_translate_foreign_address only checks for PSE bit
> only on
> > level 2 entries (that's 2 MB pages on x64 and 32-bit with PAE,
> and 4 MB
> > pages on 32-bit). But linux kernel sometimes uses 1 GB pages.
> This patch
> > fixes that, and checks the PSE bit on level 3 entries if the
> guest has 4
> > translation levels (that means 64-bit guests only).
> >
> > Signed-off-by: Cristian-Bogdan Sirb  >
>
> This function is in a rather tragic state.  Lucky it isn't used by
> code
> covered by Xen's security statement.
>
> This patch reintroduces XSA-176, and the existing code doesn't
> work for
> 4M superpages, or guests using PSE36.  (I might be acutely aware of
> pagetable issues, following c/s
> 4c5d78a10dc89).  Furthermore, the map/unmap overhead must be a large
> overhead.
>
>
> Indeed it is, that's why in LibVMI there is actually a cache
> implemented for mapped pages so we throw them away only after they
> have been idle for a while.
>  
>
>
> How often is this used by introspection?  To properly walk the
> pagetables, you need access to the CPUID information (as well as the
> control register state), and that isn't yet available to the toolstack
> in Xen.
>
>
> Control register state is certainly available.
>  
>
>
> I'm wondering whether it might be better to have a way of asking
> Xen to
> perform a virtual to linear translation in the context of a specific
> vcpu.  My gut feeling is that it might be quicker than running this
> logic, and is definitely more simple than trying to fix this code
> not to
> have vulnerabilities in it.
>
>
> I don't think it would be necessary. IMHO doing this in Xen wouldn't
> really net us much performance-wise. Furthermore, there are certain
> PTE bits that are OS specific and Xen wouldn't necessary have the
> required information to do the translation properly (ie. present bit
> unset but transition bits used for Windows guests).

Ok.  Xen needs to care only about the behaviour of real pointers in
guest context, and whether they raise #PF.

It sounds like the best thing to do is to provide userspace with all
information it needs to actually perform the walk safely, and let the
library apply guest-specific knowledge if it wants.

Off the top of my head, the control information needed is:

Hap/Shadow, hardwares views towards page1gb and pse36, whether EFER.NX
is leaked from Xen, EFER.NX, CR0.{PG,WP},
CR4.{PAE,PSE,PCID,SMEP,SMAP,PKE}, and the PDPTRs for the 32bit PAE case,
because the translation in use isn't necessary the value you would read
by following CR3 in memory.

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

Re: [Xen-devel] [PATCH v2 2/9] mm: Place unscrubbed pages at the end of pagelist

[Jan Beulich]

>>> On 04.04.17 at 17:39,  wrote:
> On 04/04/2017 11:29 AM, Jan Beulich wrote:
> On 04.04.17 at 17:14,  wrote:
>>> On 04/04/2017 10:46 AM, Jan Beulich wrote:
> @@ -933,6 +952,10 @@ static bool_t can_merge(struct page_info *buddy, 
> unsigned int node,
>   (phys_to_nid(page_to_maddr(buddy)) != node) )
>  return false;
>  
> +if ( need_scrub !=
> + !!test_bit(_PGC_need_scrub, >count_info) )
> +return false;
 I don't think leaving the tree in a state where larger order chunks
 don't become available for allocation right away is going to be
 acceptable. Hence with this issue being dealt with only in patch 7
 as it seems, you should state clearly and visibly that (at least)
 patches 2...7 should only be committed together.
>>> The dirty pages are available for allocation as result of this patch but
>>> they might not be merged with higher orders (which is what this check is
>>> for)
>> The individual chunks are available for allocation, but not the
>> combined one (for a suitably high order request). Or am I
>> missing something?
> 
> 
> Correct, but this is not changed by any later patch (including patch 7).
> We only merge with a buddy with the same level of cleanliness (so to
> speak ;-))

Hmm, that aspect was one of the main things I had objected to
back when one of your colleagues had a first take at this.

> @@ -952,9 +977,10 @@ static struct page_info *merge_chunks(struct 
> page_info *pg, unsigned int node,
>  {
>  /* Merge with predecessor block? */
>  buddy = pg - mask;
> -if ( !can_merge(buddy, node, order) )
> +if ( !can_merge(buddy, node, order, need_scrub) )
>  break;
>  
> +pg->count_info &= ~PGC_need_scrub;
>  pg = buddy;
>  page_list_del(pg, (node, zone, order));
>  }
> @@ -962,9 +988,10 @@ static struct page_info *merge_chunks(struct 
> page_info *pg, unsigned int node,
>  {
>  /* Merge with successor block? */
>  buddy = pg + mask;
> -if ( !can_merge(buddy, node, order) )
> +if ( !can_merge(buddy, node, order, need_scrub) )
>  break;
>  
> +buddy->count_info &= ~PGC_need_scrub;
>  page_list_del(buddy, (node, zone, order));
>  }
 For both of these, how come you can / want to clear the need-scrub
 flag? Wouldn't it be better for each individual page to retain it, so
 when encountering a higher-order one you know which pages need
 scrubbing and which don't? Couldn't that also be used to avoid
 suppressing their merging here right away?
>>> I am trying to avoid having to keep dirty bit for each page since a
>>> buddy is either fully clean or fully dirty. That way we shouldn't need
>>> to walk the list and clear the bit. (I, in fact, suspect that there may
>>> be other state bits/fields that we might be able to keep at a buddy only)
>> But as said - at the expense of not being able to merge early. I
>> consider this a serious limitation.
> 
> What do you mean by "early"? At freeing time?

Right.

> But then we will always have to scan the buddy during allocation to see
> if any pages are dirty.

There could be a summary flag to avoid this for entirely clean
buddies. Plus perhaps some auxiliary indication where the first
unclean part is, to speed up the scanning.

Jan


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

Re: [Xen-devel] [PATCH] Libxc: fix xc_translate_foreign_address()

[Tamas K Lengyel]

On Tue, Apr 4, 2017 at 9:11 AM, Andrew Cooper 
wrote:

> On 04/04/17 13:14, Razvan Cojocaru wrote:
> > Currently xc_translate_foreign_address only checks for PSE bit only on
> > level 2 entries (that's 2 MB pages on x64 and 32-bit with PAE, and 4 MB
> > pages on 32-bit). But linux kernel sometimes uses 1 GB pages. This patch
> > fixes that, and checks the PSE bit on level 3 entries if the guest has 4
> > translation levels (that means 64-bit guests only).
> >
> > Signed-off-by: Cristian-Bogdan Sirb 
>
> This function is in a rather tragic state.  Lucky it isn't used by code
> covered by Xen's security statement.
>
> This patch reintroduces XSA-176, and the existing code doesn't work for
> 4M superpages, or guests using PSE36.  (I might be acutely aware of
> pagetable issues, following c/s
> 4c5d78a10dc89).  Furthermore, the map/unmap overhead must be a large
> overhead.
>

Indeed it is, that's why in LibVMI there is actually a cache implemented
for mapped pages so we throw them away only after they have been idle for a
while.


>
> How often is this used by introspection?  To properly walk the
> pagetables, you need access to the CPUID information (as well as the
> control register state), and that isn't yet available to the toolstack
> in Xen.
>

Control register state is certainly available.


>
> I'm wondering whether it might be better to have a way of asking Xen to
> perform a virtual to linear translation in the context of a specific
> vcpu.  My gut feeling is that it might be quicker than running this
> logic, and is definitely more simple than trying to fix this code not to
> have vulnerabilities in it.


I don't think it would be necessary. IMHO doing this in Xen wouldn't really
net us much performance-wise. Furthermore, there are certain PTE bits that
are OS specific and Xen wouldn't necessary have the required information to
do the translation properly (ie. present bit unset but transition bits used
for Windows guests).

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

Re: [Xen-devel] [PATCH v2 2/9] mm: Place unscrubbed pages at the end of pagelist

[Boris Ostrovsky]

On 04/04/2017 11:29 AM, Jan Beulich wrote:
 On 04.04.17 at 17:14,  wrote:
>> On 04/04/2017 10:46 AM, Jan Beulich wrote:
 @@ -933,6 +952,10 @@ static bool_t can_merge(struct page_info *buddy, 
 unsigned int node,
   (phys_to_nid(page_to_maddr(buddy)) != node) )
  return false;
  
 +if ( need_scrub !=
 + !!test_bit(_PGC_need_scrub, >count_info) )
 +return false;
>>> I don't think leaving the tree in a state where larger order chunks
>>> don't become available for allocation right away is going to be
>>> acceptable. Hence with this issue being dealt with only in patch 7
>>> as it seems, you should state clearly and visibly that (at least)
>>> patches 2...7 should only be committed together.
>> The dirty pages are available for allocation as result of this patch but
>> they might not be merged with higher orders (which is what this check is
>> for)
> The individual chunks are available for allocation, but not the
> combined one (for a suitably high order request). Or am I
> missing something?


Correct, but this is not changed by any later patch (including patch 7).
We only merge with a buddy with the same level of cleanliness (so to
speak ;-))


>
 @@ -952,9 +977,10 @@ static struct page_info *merge_chunks(struct 
 page_info *pg, unsigned int node,
  {
  /* Merge with predecessor block? */
  buddy = pg - mask;
 -if ( !can_merge(buddy, node, order) )
 +if ( !can_merge(buddy, node, order, need_scrub) )
  break;
  
 +pg->count_info &= ~PGC_need_scrub;
  pg = buddy;
  page_list_del(pg, (node, zone, order));
  }
 @@ -962,9 +988,10 @@ static struct page_info *merge_chunks(struct 
 page_info *pg, unsigned int node,
  {
  /* Merge with successor block? */
  buddy = pg + mask;
 -if ( !can_merge(buddy, node, order) )
 +if ( !can_merge(buddy, node, order, need_scrub) )
  break;
  
 +buddy->count_info &= ~PGC_need_scrub;
  page_list_del(buddy, (node, zone, order));
  }
>>> For both of these, how come you can / want to clear the need-scrub
>>> flag? Wouldn't it be better for each individual page to retain it, so
>>> when encountering a higher-order one you know which pages need
>>> scrubbing and which don't? Couldn't that also be used to avoid
>>> suppressing their merging here right away?
>> I am trying to avoid having to keep dirty bit for each page since a
>> buddy is either fully clean or fully dirty. That way we shouldn't need
>> to walk the list and clear the bit. (I, in fact, suspect that there may
>> be other state bits/fields that we might be able to keep at a buddy only)
> But as said - at the expense of not being able to merge early. I
> consider this a serious limitation.

What do you mean by "early"? At freeing time?

But then we will always have to scan the buddy during allocation to see
if any pages are dirty.


>
 --- a/xen/include/asm-x86/mm.h
 +++ b/xen/include/asm-x86/mm.h
 @@ -233,6 +233,10 @@ struct page_info
  #define PGC_count_width   PG_shift(9)
  #define PGC_count_mask((1UL<>> So why not a new PGC_state_dirty instead of this independent
>>> flag? Pages other than PGC_state_free should never make it
>>> to the scrubber, so the flag is meaningless for all other
>>> PGC_state_*.
>> Wouldn't doing this require possibly making two checks ---
>> page_state_is(pg, free) || page_state_is(pg, dirty)?
> Well, your goal would normally be to first look for pages not
> needing scrubbing anyway, so quite likely you'd do two
> passes anyway. But of course much depends on whether to
> merge early or late.

Again, I need to understand what you consider "early" and "late".

-boris


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

Re: [Xen-devel] [PATCH] kexec: clear kexec_image slot when unloading kexec image

[Jan Beulich]

>>> On 04.04.17 at 17:30,  wrote:
>>  Looks like you've mixed up commit message (everything up from this
>> marker) and …
>> 
> 
> Sorry about that! Since it’s been a while since I posted a git patch to a 
> mailing list, I had to figure out what the canonical format for an e-mail 
> with a patch was, such that I could have a more verbose description of the 
> problem followed by the usual git commit message. In the Documentation 
> directory of the mainline Linux kernel tree I thought this is what they were 
> recommending:
> 
> 
> You can put a longer, more verbose description of the problem and the patch 
> here. This section is not picked up by the tools committers use to extract 
> the patch out of the e-mail.
> 
> - - -
> Original git commit message, more concise, which will be used as the commit 
> message in git
> Signed-off-by: 
> Reviewed-by:
> - - -
> diffstat
> 
> diff
> - -
> git version
> 
> 
> Is that not correct?

That's not how we do things normally. You could have looked at a
couple of patches sent by others...

Jan

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

Re: [Xen-devel] [PATCH v4 10/27] ARM: GICv3: forward pending LPIs to guests

[Julien Grall]

Hi Andre,

On 03/04/17 21:28, Andre Przywara wrote:

diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index d3ee141..ad89863 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -125,6 +125,48 @@ uint64_t gicv3_get_redist_address(unsigned int cpu, bool 
use_pta)
 return per_cpu(lpi_redist, cpu).redist_id << 16;
 }

+/*
+ * Handle incoming LPIs, which are a bit special, because they are potentially
+ * numerous and also only get injected into guests. Treat them specially here,
+ * by just looking up their target vCPU and virtual LPI number and hand it
+ * over to the injection function.
+ */
+void do_LPI(unsigned int lpi)
+{
+struct domain *d;
+union host_lpi *hlpip, hlpi;
+struct vcpu *vcpu;


I forgot to mention, you will need irq_enter here and irq_exit in the 
return path.



+WRITE_SYSREG32(lpi, ICC_EOIR1_EL1);
+
+hlpip = gic_get_host_lpi(lpi);
+if ( !hlpip )
+return;
+
+hlpi.data = read_u64_atomic(>data);
+
+/* Unmapped events are marked with an invalid LPI ID. */
+if ( hlpi.virt_lpi == INVALID_LPI )
+return;
+
+d = rcu_lock_domain_by_id(hlpi.dom_id);
+if ( !d )
+return;
+
+/* Make sure we don't step beyond the vcpu array. */
+if ( hlpi.vcpu_id >= d->max_vcpus )
+{
+rcu_unlock_domain(d);
+return;
+}
+
+vcpu = d->vcpu[hlpi.vcpu_id];
+
+vgic_vcpu_inject_irq(vcpu, hlpi.virt_lpi);
+
+rcu_unlock_domain(d);
+}
+
 static int gicv3_lpi_allocate_pendtable(uint64_t *reg)
 {
 uint64_t val;
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 3ed6f81..a6037d4 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -709,7 +709,13 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
 do_IRQ(regs, irq, is_fiq);
 local_irq_disable();
 }
-else if (unlikely(irq < 16))
+#ifdef CONFIG_HAS_ITS
+else if ( is_lpi(irq) )
+{


You probably want to enable IRQs here...


+do_LPI(irq);


... and disable here as we do the SPIs/PPIs.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] Can't ./configure latest git

[Anthony PERARD]

On Tue, Apr 04, 2017 at 03:09:48PM +, Duncan X. Simpson wrote:
> Ah, that makes more sense. Another problem I had when trying to compile was
> I got a permission denied error on xen-setup, which I fixed by making as
> root (in a chroot of course). Was there a better way to do that?

This sound like an weird issue in your environnement. And I don't see
how been root would affect permission of xen-setup. Is this
tools/qemu-xen-traditional-dir/xen-setup ?

What is the error message?

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH] kexec: clear kexec_image slot when unloading kexec image

[Bhavesh Davda]

> Looks like you've mixed up commit message (everything up from this
> marker) and …
> 

Sorry about that! Since it’s been a while since I posted a git patch to a 
mailing list, I had to figure out what the canonical format for an e-mail with 
a patch was, such that I could have a more verbose description of the problem 
followed by the usual git commit message. In the Documentation directory of the 
mainline Linux kernel tree I thought this is what they were recommending:


You can put a longer, more verbose description of the problem and the patch 
here. This section is not picked up by the tools committers use to extract the 
patch out of the e-mail.

- - -
Original git commit message, more concise, which will be used as the commit 
message in git
Signed-off-by: 
Reviewed-by:
- - -
diffstat

diff
- -
git version


Is that not correct?

Also couldn’t find the right command line options for any of the git helpers 
like format-patch or send-email to let it do the canonical formatting with the 
verbose description, so I edited the “git format-patch” generated file to 
conform with the above format.

Thanks for fixing it up!

- Bhavesh




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

Re: [Xen-devel] [PATCH v2 2/9] mm: Place unscrubbed pages at the end of pagelist

[Jan Beulich]

>>> On 04.04.17 at 17:14,  wrote:
> On 04/04/2017 10:46 AM, Jan Beulich wrote:
>>> @@ -933,6 +952,10 @@ static bool_t can_merge(struct page_info *buddy, 
>>> unsigned int node,
>>>   (phys_to_nid(page_to_maddr(buddy)) != node) )
>>>  return false;
>>>  
>>> +if ( need_scrub !=
>>> + !!test_bit(_PGC_need_scrub, >count_info) )
>>> +return false;
>> I don't think leaving the tree in a state where larger order chunks
>> don't become available for allocation right away is going to be
>> acceptable. Hence with this issue being dealt with only in patch 7
>> as it seems, you should state clearly and visibly that (at least)
>> patches 2...7 should only be committed together.
> 
> The dirty pages are available for allocation as result of this patch but
> they might not be merged with higher orders (which is what this check is
> for)

The individual chunks are available for allocation, but not the
combined one (for a suitably high order request). Or am I
missing something?

>>> @@ -952,9 +977,10 @@ static struct page_info *merge_chunks(struct page_info 
>>> *pg, unsigned int node,
>>>  {
>>>  /* Merge with predecessor block? */
>>>  buddy = pg - mask;
>>> -if ( !can_merge(buddy, node, order) )
>>> +if ( !can_merge(buddy, node, order, need_scrub) )
>>>  break;
>>>  
>>> +pg->count_info &= ~PGC_need_scrub;
>>>  pg = buddy;
>>>  page_list_del(pg, (node, zone, order));
>>>  }
>>> @@ -962,9 +988,10 @@ static struct page_info *merge_chunks(struct page_info 
>>> *pg, unsigned int node,
>>>  {
>>>  /* Merge with successor block? */
>>>  buddy = pg + mask;
>>> -if ( !can_merge(buddy, node, order) )
>>> +if ( !can_merge(buddy, node, order, need_scrub) )
>>>  break;
>>>  
>>> +buddy->count_info &= ~PGC_need_scrub;
>>>  page_list_del(buddy, (node, zone, order));
>>>  }
>> For both of these, how come you can / want to clear the need-scrub
>> flag? Wouldn't it be better for each individual page to retain it, so
>> when encountering a higher-order one you know which pages need
>> scrubbing and which don't? Couldn't that also be used to avoid
>> suppressing their merging here right away?
> 
> I am trying to avoid having to keep dirty bit for each page since a
> buddy is either fully clean or fully dirty. That way we shouldn't need
> to walk the list and clear the bit. (I, in fact, suspect that there may
> be other state bits/fields that we might be able to keep at a buddy only)

But as said - at the expense of not being able to merge early. I
consider this a serious limitation.

>>> +static void scrub_free_pages(unsigned int node)
>>> +{
>>> +struct page_info *pg;
>>> +unsigned int i, zone;
>>> +int order;
>> There are no negative orders.
> 
> It actually becomes negative in the loop below and this is loop exit
> condition.

Only because of the way you've coded the loop. It becoming
negative can be easily avoided.

>>> +ASSERT(spin_is_locked(_lock));
>>> +
>>> +if ( !node_need_scrub[node] )
>>> +return;
>>> +
>>> +for ( zone = 0; zone < NR_ZONES; zone++ )
>>> +{
>>> +for ( order = MAX_ORDER; order >= 0; order-- )
>>> +{
>>> +while ( !page_list_empty((node, zone, order)) )
>>> +{
>>> +/* Unscrubbed pages are always at the end of the list. */
>>> +pg = page_list_last((node, zone, order));
>>> +if ( !test_bit(_PGC_need_scrub, >count_info) )
>>> +break;
>>> +
>>> +for ( i = 0; i < (1UL << order); i++)
>> Types of loop variable and upper bound do not match.
>>
>>> +scrub_one_page([i]);
>>> +
>>> +pg->count_info &= ~PGC_need_scrub;
>>> +
>>> +page_list_del(pg, (node, zone, order));
>>> +(void)merge_chunks(pg, node, zone, order);
>> Pointless cast.
> 
> Didn't coverity complain about those types of things? That was the
> reason I have the cast here. If not I'll drop it.

I don't know why Coverity would complain about an unused
return value. We've got plenty of such cases throughout the
code base. If this was a macro, the story might be different.

>>> --- a/xen/include/asm-x86/mm.h
>>> +++ b/xen/include/asm-x86/mm.h
>>> @@ -233,6 +233,10 @@ struct page_info
>>>  #define PGC_count_width   PG_shift(9)
>>>  #define PGC_count_mask((1UL<>>  
>>> +/* Page needs to be scrubbed */
>>> +#define _PGC_need_scrub   PG_shift(10)
>>> +#define PGC_need_scrubPG_mask(1, 10)
>> So why not a new PGC_state_dirty instead of this independent
>> flag? Pages other than PGC_state_free should never make it
>> to the scrubber, so the flag is meaningless for all other
>> PGC_state_*.
> 
> Wouldn't doing this require possibly making 

Re: [Xen-devel] [PATCH v2] x86/monitor: add support for descriptor access events

[Andrew Cooper]

On 04/04/17 10:57, Adrian Pop wrote:
> diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
> index f5cd245771..d60e4afd0c 100644
> --- a/xen/arch/x86/hvm/monitor.c
> +++ b/xen/arch/x86/hvm/monitor.c
> @@ -72,6 +72,28 @@ void hvm_monitor_msr(unsigned int msr, uint64_t value)
>  }
>  }
>  
> +void hvm_monitor_descriptor_access(uint64_t exit_info,
> +   uint64_t vmx_exit_qualification,
> +   uint8_t descriptor, bool is_write)
> +{
> +struct vcpu *curr = current;
> +vm_event_request_t req = {
> +.reason = VM_EVENT_REASON_DESCRIPTOR_ACCESS,
> +.u.desc_access.descriptor = descriptor,
> +.u.desc_access.is_write = is_write,
> +};

Newline here

> +if ( cpu_has_vmx )
> +{
> +req.u.desc_access.arch.vmx.instr_info = exit_info;
> +req.u.desc_access.arch.vmx.exit_qualification = 
> vmx_exit_qualification;
> +}
> +else
> +{
> +req.u.desc_access.arch.svm.exitinfo = exit_info;
> +}

And here please.

> +monitor_traps(curr, 1, );
> +}
> +
>  static inline unsigned long gfn_of_rip(unsigned long rip)
>  {
>  struct vcpu *curr = current;
> diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h 
> b/xen/include/asm-x86/hvm/vmx/vmx.h
> index 2b781ab120..b00ba52443 100644
> --- a/xen/include/asm-x86/hvm/vmx/vmx.h
> +++ b/xen/include/asm-x86/hvm/vmx/vmx.h
> @@ -628,4 +628,46 @@ typedef struct {
>  u16 eptp_index;
>  } ve_info_t;
>  
> +/* VM-Exit instruction info for LIDT, LGDT, SIDT, SGDT */
> +typedef union idt_or_gdt_instr_info {
> +unsigned long raw;
> +struct {
> +unsigned long scaling   :2,  /* bits 0:1 - Scaling */
> +:5,  /* bits 6:2 - Undefined */
> +addr_size   :3,  /* bits 9:7 - Address size */
> +:1,  /* bit 10 - Cleared to 0 */
> +operand_size:1,  /* bit 11 - Operand size */
> +:3,  /* bits 14:12 - Undefined */
> +segment_reg :3,  /* bits 17:15 - Segment register */
> +index_reg   :4,  /* bits 21:18 - Index register */
> +index_reg_invalid   :1,  /* bit 22 - Index register invalid */
> +base_reg:4,  /* bits 26:23 - Base register */
> +base_reg_invalid:1,  /* bit 27 - Base register invalid */
> +instr_identity  :1,  /* bit 28 - 0:GDT, 1:IDT */
> +instr_write :1,  /* bit 29 - 0:store, 1:load */
> +:2;  /* bits 30:31 - Undefined */

I think you need a :32 /* undefined */ in each of these, to avoid
breaking the Clang build, which cares that each half of the union have
the same bit size.

All of these can be fixed on commit if there are no other issues. 
Otherwise, Reviewed-by: Andrew Cooper 

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

[Xen-devel] [PATCH v6] altp2m: Introduce external-only and limited use-cases

[Tamas K Lengyel]

Currently setting altp2mhvm=1 in the domain configuration allows access to the
altp2m interface for both in-guest and external privileged tools. This poses
a problem for use-cases where only external access should be allowed, requiring
the user to compile Xen with XSM enabled to be able to appropriately restrict
access.

In this patch we deprecate the altp2mhvm domain configuration option and
introduce the altp2m option, which allows specifying if by default the altp2m
interface should be external-only or limited. The information is stored in
HVM_PARAM_ALTP2M which we now define with specific XEN_ALTP2M_* modes.
If external mode is selected, the XSM check is shifted to use XSM_DM_PRIV
type check, thus restricting access to the interface by the guest itself. Note
that we keep the default XSM policy untouched. Users of XSM who wish to enforce
external mode for altp2m can do so by adjusting their XSM policy directly,
as this domain config option does not override an active XSM policy.

Also, as part of this patch we adjust the hvmop handler to require
HVM_PARAM_ALTP2M to be of a type other then disabled for all ops. This has been
previously only required for get/set altp2m domain state, all other options
were gated on altp2m_enabled. Since altp2m_enabled only gets set during set
altp2m domain state, this change introduces no new requirements to the other
ops but makes it more clear that it is required for all ops.

Signed-off-by: Tamas K Lengyel 
Signed-off-by: Sergej Proskurin 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Andrew Cooper 
Cc: Jan Beulich 
Cc: Daniel De Graaf 

v5: Add "limited" mode where the guest only has access to enable/disable
VMFUNC and #VE features.

v6: Check mode when XSM is enabled so that both the mode and the XSM policy
has to allow the altp2m operation to succeed. Makes limited mode available
even when XSM is enabled.
---
 docs/man/xl.cfg.pod.5.in| 41 -
 tools/libxl/libxl_create.c  |  6 --
 tools/libxl/libxl_dom.c | 18 --
 tools/libxl/libxl_types.idl | 14 ++
 tools/xl/xl_parse.c | 20 +++-
 xen/arch/x86/hvm/hvm.c  | 22 --
 xen/include/public/hvm/params.h | 12 +++-
 xen/include/xsm/dummy.h | 23 ---
 xen/include/xsm/xsm.h   |  6 +++---
 xen/xsm/flask/hooks.c   | 21 -
 10 files changed, 159 insertions(+), 24 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 206d33eb3f..616dc093b0 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -1319,6 +1319,41 @@ enabled by default and you should usually omit it. It 
may be necessary
 to disable the HPET in order to improve compatibility with guest
 Operating Systems (X86 only)
 
+=item 

Re: [Xen-devel] [PATCH v2 0/9] Memory scrubbing from idle loop

[George Dunlap]

On 03/04/17 17:50, Boris Ostrovsky wrote:
> When a domain is destroyed the hypervisor must scrub domain's pages before
> giving them to another guest in order to prevent leaking the deceased
> guest's data. Currently this is done during guest's destruction, possibly
> causing very lengthy cleanup process.
> 
> This series adds support for scrubbing released pages from idle loop,
> making guest destruction significantly faster. For example, destroying a
> 1TB guest can now be completed in 40+ seconds as opposed to about 9 minutes
> using existing scrubbing algorithm.
> 
> The downside of this series is that we sometimes fail to allocate high-order
> sets of pages since dirty pages may not yet be merged into higher-order sets
> while they are waiting to be scrubbed.
> 
> Briefly, the new algorithm places dirty pages at the end of heap's page list
> for each node/zone/order to avoid having to scan full list while searching
> for dirty pages. One processor form each node checks whether the node has any
> dirty pages and, if such pages are found, scrubs them. Scrubbing itself
> happens without holding heap lock so other users may access heap in the
> meantime. If while idle loop is scrubbing a particular chunk of pages this
> chunk is requested by the heap allocator, scrubbing is immediately stopped.
> 
> On the allocation side, alloc_heap_pages() first tries to satisfy allocation
> request using only clean pages. If this is not possible, the search is
> repeated and dirty pages are scrubbed by the allocator.
> 
> This series is somewhat based on earlier work by Bob Liu.
> 
> V1:
> * Only set PGC_need_scrub bit for the buddy head, thus making it unnecessary
>   to scan whole buddy
> * Fix spin_lock_cb()
> * Scrub CPU-less nodes
> * ARM support. Note that I have not been able to test this, only built the
>   binary
> * Added scrub test patch (last one). Not sure whether it should be considered
>   for committing but I have been running with it.
> 
> V2:
> * merge_chunks() returns new buddy head
> * scrub_free_pages() returns softirq pending status in addition to (factored 
> out)
>   status of unscrubbed memory
> * spin_lock uses inlined spin_lock_cb()
> * scrub debugging code checks whole page, not just the first word.
> 
> Deferred:
> * Per-node heap locks. In addition to (presumably) improving performance in
>   general, once they are available we can parallelize scrubbing further by
>   allowing more than one core per node to do idle loop scrubbing.
> * AVX-based scrubbing
> * Use idle loop scrubbing during boot.
> 
> 
> Boris Ostrovsky (9):
>   mm: Separate free page chunk merging into its own routine
>   mm: Place unscrubbed pages at the end of pagelist
>   mm: Scrub pages in alloc_heap_pages() if needed
>   mm: Scrub memory from idle loop
>   mm: Do not discard already-scrubbed pages softirqs are pending
>   spinlock: Introduce spin_lock_cb()
>   mm: Keep pages available for allocation while scrubbing
>   mm: Print number of unscrubbed pages in 'H' debug handler
>   mm: Make sure pages are scrubbed
> 
>  xen/Kconfig.debug  |7 +
>  xen/arch/arm/domain.c  |   13 +-
>  xen/arch/x86/domain.c  |3 +-
>  xen/common/page_alloc.c|  475 
> +---
>  xen/common/spinlock.c  |9 +-
>  xen/include/asm-arm/mm.h   |8 +
>  xen/include/asm-x86/mm.h   |8 +
>  xen/include/xen/mm.h   |1 +
>  xen/include/xen/spinlock.h |3 +

FAOD, even though this series has 'mm' in the title of almost every
patch, none of it comes under my explicit maintainership (which is
arch/x86/mm), so I don't think it needs any Acks specifically from me to
get in.

On the whole the series looks like it's going in the right direction, so
I won't give a detailed review unless someone specifically asks for it.

 -George

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

Re: [Xen-devel] [PATCH] Libxc: fix xc_translate_foreign_address()

[Razvan Cojocaru]

On 04/04/2017 06:11 PM, Andrew Cooper wrote:
> On 04/04/17 13:14, Razvan Cojocaru wrote:
>> Currently xc_translate_foreign_address only checks for PSE bit only on
>> level 2 entries (that's 2 MB pages on x64 and 32-bit with PAE, and 4 MB
>> pages on 32-bit). But linux kernel sometimes uses 1 GB pages. This patch
>> fixes that, and checks the PSE bit on level 3 entries if the guest has 4
>> translation levels (that means 64-bit guests only).
>>
>> Signed-off-by: Cristian-Bogdan Sirb 
> 
> This function is in a rather tragic state.  Lucky it isn't used by code
> covered by Xen's security statement.
> 
> This patch reintroduces XSA-176, and the existing code doesn't work for
> 4M superpages, or guests using PSE36.  (I might be acutely aware of
> pagetable issues, following c/s
> 4c5d78a10dc89).  Furthermore, the map/unmap overhead must be a large
> overhead.
> 
> How often is this used by introspection?  To properly walk the
> pagetables, you need access to the CPUID information (as well as the
> control register state), and that isn't yet available to the toolstack
> in Xen.
> 
> I'm wondering whether it might be better to have a way of asking Xen to
> perform a virtual to linear translation in the context of a specific
> vcpu.  My gut feeling is that it might be quicker than running this
> logic, and is definitely more simple than trying to fix this code not to
> have vulnerabilities in it.

We have a workaround looking directly into the guest but have felt that
the proper thing to do was to contribute the fix back to Xen.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH] Libxc: fix xc_translate_foreign_address()

[Andrew Cooper]

On 04/04/17 13:14, Razvan Cojocaru wrote:
> Currently xc_translate_foreign_address only checks for PSE bit only on
> level 2 entries (that's 2 MB pages on x64 and 32-bit with PAE, and 4 MB
> pages on 32-bit). But linux kernel sometimes uses 1 GB pages. This patch
> fixes that, and checks the PSE bit on level 3 entries if the guest has 4
> translation levels (that means 64-bit guests only).
>
> Signed-off-by: Cristian-Bogdan Sirb 

This function is in a rather tragic state.  Lucky it isn't used by code
covered by Xen's security statement.

This patch reintroduces XSA-176, and the existing code doesn't work for
4M superpages, or guests using PSE36.  (I might be acutely aware of
pagetable issues, following c/s
4c5d78a10dc89).  Furthermore, the map/unmap overhead must be a large
overhead.

How often is this used by introspection?  To properly walk the
pagetables, you need access to the CPUID information (as well as the
control register state), and that isn't yet available to the toolstack
in Xen.

I'm wondering whether it might be better to have a way of asking Xen to
perform a virtual to linear translation in the context of a specific
vcpu.  My gut feeling is that it might be quicker than running this
logic, and is definitely more simple than trying to fix this code not to
have vulnerabilities in it.

~Andrew

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