[Xen-devel] [libvirt test] 105075: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-xsm  5 xen-install  fail REGR. vs. 104989

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  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
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  ae01530cb431a4a4915524f323c9c000ea591d8e
baseline version:
 libvirt  b42524552036cadb99d32c5dd0d6d598721518ff

Last test of basis   104989  2017-01-30 04:20:29 Z1 days
Testing same since   105075  2017-01-31 04:22:06 Z0 days1 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  Fabian Freyer 
  Jiri Denemark 
  Ján Tomko 
  Michal Privoznik 
  Nikolay Shirokovskiy 
  Roman Bogorodskiy 

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



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

Logs, config files, etc. are available at

[Xen-devel] [linux-linus test] 105038: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-armhf-armhf-libvirt-raw  6 xen-bootfail baseline untested
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail baseline 
untested
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254

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

version targeted for testing:
 linux751321b3dd5040dc5be19bd23f985e80c914621a
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  572 days
Failing since 59348  2015-07-10 04:24:05 Z  571 days  236 attempts
Testing same since   105038  2017-01-30 22:17:32 Z0 days1 attempts


7543 people touched revisions under test,
not listing them all

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl7 host-ping-check-xen fail in 104981 pass in 105018
 test-armhf-armhf-xl-arndale   5 xen-installfail pass in 104981

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

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   like 68495
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   like 68495
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   like 68495
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 68495
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 68495

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-xsm   2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  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 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-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:
 qemuua0def594286d9110a6035e02eef558cf3cf5d847
baseline version:
 qemuu3aca12f841fcd6f3a7477076dad0d564360500de

Last test of basis68495  2017-01-29 04:14:29 Z2 days
Testing same since68500  2017-01-30 22:44:25 Z0 days1 attempts


People who touched revisions under test:
  Eric Farman 
  Ladi Prosek 
  Laszlo Ersek 
  Marc-André Lureau 
  Paolo Bonzini 
  Pavel Dovgalyuk 
  Peter Lieven 
  Peter Maydell 
  Peter Xu 
  Phil Dennis-Jordan 

[Xen-devel] [ovmf baseline-only test] 68501: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68501 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68501/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 7fcb735412998d536cb348049c4ea60897fa6886
baseline version:
 ovmf 465663e9f128428323e6c6e4431dd15ac287a24c

Last test of basis68496  2017-01-29 04:17:31 Z2 days
Testing same since68501  2017-01-31 01:48:43 Z0 days1 attempts


People who touched revisions under test:
  Laszlo Ersek 

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



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.


commit 7fcb735412998d536cb348049c4ea60897fa6886
Author: Laszlo Ersek 
Date:   Fri Jan 27 08:10:15 2017 +0100

ArmVirtPkg/QemuFwCfgLib: implement QemuFwCfgSkipBytes() API

We are now sufficiently equipped to implement the new QemuFwCfgSkipBytes()
API.

The previous patch and this one enable ArmVirtPkg/QemuFwCfgLib to
overwrite part of a writeable fw_cfg file, which will be particularly
useful for the upcoming QEMU_LOADER_WRITE_POINTER command in
OvmfPkg/AcpiPlatformDxe.

Cc: Ard Biesheuvel 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Ard Biesheuvel 
Reviewed-by: Jordan Justen 

commit e8ae381f608ae02662f4dcc7379898162645d2ca
Author: Laszlo Ersek 
Date:   Fri Jan 27 07:29:12 2017 +0100

ArmVirtPkg/QemuFwCfgLib: use DMA for QemuFwCfgWriteBytes() if available

We use the "InternalQemuFwCfgReadBytes" static function pointer to
dispatch the reading of fw_cfg bytes between MMIO and DMA. This pointer is
initialized to MMIO, and we set it to DMA in the library constructor if
DMA is available.

Unlike the above, we write fw_cfg bytes only with MMIO at the moment.
Extend the write functionality so that it follows the read pattern:
- introduce the new function typedef WRITE_BYTES_FUNCTION,
- extract the current (MMIO-only) write internals from
  QemuFwCfgWriteBytes() to MmioWriteBytes(),
- provide a DMA-based implementation in DmaWriteBytes() -- a thin wrapper
  around DmaTransferBytes(),
- set the new static function pointer "InternalQemuFwCfgWriteBytes"
  according to the DMA feature provided by QEMU,
- In QemuFwCfgWriteBytes(), call the best available method through
  "InternalQemuFwCfgWriteBytes".

Cc: Ard Biesheuvel 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Ard Biesheuvel 
Reviewed-by: Jordan Justen 

commit 4175356fb4bfe89415677aed8fb4e6928ced2ff1
Author: Laszlo Ersek 
Date:   Fri Jan 27 06:56:19 2017 +0100

ArmVirtPkg/QemuFwCfgLib: extract generic DmaTransferBytes() function

The DmaReadBytes() function that we currently use only for reading --
through the InternalQemuFwCfgReadBytes function pointer, in case the DMA
interface is available -- is suitable with minimal changes for two more
operations provided by the DMA interface, WRITE and SKIP. Expose the
Control parameter in the function prototype, rename the function to
DmaTransferBytes(), and rebase DmaReadBytes() to it.

Cc: Ard Biesheuvel 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 

Re: [Xen-devel] [PATCH v1 0/7] Make building xSplice patches easier

[Doug Goldstein]

On 5/6/16 10:48 AM, Ross Lagerwall wrote:
> Here is a set of changes to make building xSplice patches easier.
> Tested to boot on x86.
> Compile-tested on arm.
> 
> This is probably too late to make it into 4.7, but hey, if someone wants
> to put it in I've CC'd Wei.

Ross,

What happened with this series? Some of these patches still appear
un-applied and they appear relevant still.

-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH RESEND v5 04/24] x86: refactor psr: implement CPU init and free flow.

[Konrad Rzeszutek Wilk]

On Thu, Jan 19, 2017 at 02:01:06PM +0800, Yi Sun wrote:
> This patch implements the CPU init and free flow including L3 CAT
> initialization and feature list free.
> 
> Signed-off-by: Yi Sun 
> ---
> v5:
> - modify commit message beacuse of code changes.
> - add 'struct cpuid_leaf_regs' to save cpu registers value to reduce
>   parameters of init_feature function.
> - modify comments to make them accurate.
> - modify variables names to make them better, e.g. 'feat_tmp' to 'feat'.
> - use 'list_for_each_entry_safe' when free features.
> - do not delete 'feat_l3_cat' to make it can be reused when cpu online.
> - use 'current_cpu_data'.
> - clear 'X86_FEATURE_PQE' if cpuid_level is not right.
> - Print socket info when 'opt_cpu_info' is true.
> - remove 'cpu_prepare_work' function and move contents of it into
>   'psr_cpu_prepare'.
> ---
>  xen/arch/x86/psr.c | 176 
> -
>  1 file changed, 174 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
> index f7ff3fc..e9dc07a 100644
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -35,6 +35,9 @@
>  #define PSR_CAT(1<<1)
>  #define PSR_CDP(1<<2)
>  
> +#define CAT_CBM_LEN_MASK 0x1f
> +#define CAT_COS_MAX_MASK 0x
> +
>  /*
>   * Per SDM chapter 'Cache Allocation Technology: Cache Mask Configuration',
>   * the MSRs range from 0C90H through 0D0FH (inclusive), enables support for
> @@ -127,6 +130,13 @@ struct feat_node {
>  struct list_head list;
>  };
>  
> +struct cpuid_leaf_regs {
> +unsigned int eax;
> +unsigned int ebx;
> +unsigned int ecx;
> +unsigned int edx;
> +};

Could you use 'struct cpuid_leaf' in x86_emulate.h ?

It would only require "#include " I believe.

> +
>  struct psr_assoc {
>  uint64_t val;
>  uint64_t cos_mask;
> @@ -134,11 +144,76 @@ struct psr_assoc {
>  
>  struct psr_cmt *__read_mostly psr_cmt;
>  
> +static struct psr_socket_info *__read_mostly socket_info;
> +
>  static unsigned int opt_psr;
>  static unsigned int __initdata opt_rmid_max = 255;
> +static unsigned int __read_mostly opt_cos_max = MAX_COS_REG_CNT;
>  static uint64_t rmid_mask;
>  static DEFINE_PER_CPU(struct psr_assoc, psr_assoc);
>  
> +/*
> + * Declare global feature list entry for every feature to facilitate the
> + * feature list creation. It will be allocated in psr_cpu_prepare() and
> + * inserted into feature list in cpu_init_work().

You may also want to say it is protected by the cpu_add_remove_lock
spinlock.

> + */
> +static struct feat_node *feat_l3_cat;
> +
> +/* Common functions. */
> +static void free_feature(struct psr_socket_info *info)
> +{
> +struct feat_node *feat, *next;
> +
> +if ( !info )
> +return;
> +
> +list_for_each_entry_safe(feat, next, >feat_list, list)
> +{
> +clear_bit(feat->feature, >feat_mask);

Would it make sense to use __clear_bit?

As in you have already a lock (cpu_add_remove_lock) so nobody
can change the feat_mask. Hence thinking there is no need for the
lock operation?

> +list_del(>list);
> +xfree(feat);
> +}
> +}
> +
> +/* L3 CAT functions implementation. */
> +static void l3_cat_init_feature(struct cpuid_leaf_regs regs,
> +struct feat_node *feat,
> +struct psr_socket_info *info)
> +{
> +struct psr_cat_hw_info l3_cat;
> +unsigned int socket;
> +
> +/* No valid value so do not enable feature. */
> +if ( !regs.eax || !regs.edx )
> +return;
> +
> +l3_cat.cbm_len = (regs.eax & CAT_CBM_LEN_MASK) + 1;
> +l3_cat.cos_max = min(opt_cos_max, regs.edx & CAT_COS_MAX_MASK);
> +
> +/* cos=0 is reserved as default cbm(all bits within cbm_len are 1). */
> +feat->cos_reg_val[0] = (1ull << l3_cat.cbm_len) - 1;
> +
> +feat->feature = PSR_SOCKET_L3_CAT;
> +__set_bit(PSR_SOCKET_L3_CAT, >feat_mask);

Aha! So you do reuse the enum! In which case you really
want to make sure you mention that in 'struct psr_socket_info'
the 'feat_mask' is actually the bit values of enum psr_feat_type.

Also do you want to add an ASSERT before you call the __set_bit:

ASSERT ( !test_bit(PSR_SOCKET_L3_CAT, >feat_mask) );

?
> +
> +feat->info.l3_cat_info = l3_cat;
> +
> +info->nr_feat++;
> +
> +/* Add this feature into list. */
> +list_add_tail(>list, >feat_list);
> +
> +socket = cpu_to_socket(smp_processor_id());
> +if ( opt_cpu_info )
> +printk(XENLOG_INFO
> +   "L3 CAT: enabled on socket %u, cos_max:%u, cbm_len:%u\n",

Odd spacing. I would think that the "L3 CAT: .. "
would be on the same column as XENLOG_INFO ?

Or you could flip this logic (if you are worried about the silly
80 characters requirement) around and do:

if ( !opt_cpu_info )
return

And then do the printk on its own line?
> +   socket, feat->info.l3_cat_info.cos_max,
> + 

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

[osstest service owner]

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

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   5 xen-buildfail   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  fe6e8188f3ad91e166338b9962a06afab9b776cd
baseline version:
 xen  5a77ccf609da289131bd1664ee20c17b1f9bb93c

Last test of basis   105021  2017-01-30 15:02:49 Z0 days
Testing same since   105036  2017-01-30 22:02:29 Z0 days2 attempts


People who touched revisions under test:
  George Dunlap 
  Konrad Rzeszutek Wilk 
  Razvan Cojocaru 
  Tamas K Lengyel 
  Wei Liu 

jobs:
 build-amd64  pass
 build-arm64  fail
 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=fe6e8188f3ad91e166338b9962a06afab9b776cd
+ . ./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 
fe6e8188f3ad91e166338b9962a06afab9b776cd
+ branch=xen-unstable-smoke
+ revision=fe6e8188f3ad91e166338b9962a06afab9b776cd
+ . ./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
+ '[' xfe6e8188f3ad91e166338b9962a06afab9b776cd = 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
++ : 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 7fcb735412998d536cb348049c4ea60897fa6886
baseline version:
 ovmf 465663e9f128428323e6c6e4431dd15ac287a24c

Last test of basis   104711  2017-01-26 14:45:09 Z4 days
Testing same since   105046  2017-01-30 23:47:18 Z0 days1 attempts


People who touched revisions under test:
  Laszlo Ersek 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=7fcb735412998d536cb348049c4ea60897fa6886
+ . ./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 ovmf 
7fcb735412998d536cb348049c4ea60897fa6886
+ branch=ovmf
+ revision=7fcb735412998d536cb348049c4ea60897fa6886
+ . ./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=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' x7fcb735412998d536cb348049c4ea60897fa6886 = 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
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : 

Re: [Xen-devel] [linux-linus test] 105012: regressions - FAIL

[Boris Ostrovsky]

On 01/30/2017 04:51 PM, osstest service owner wrote:

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

Regressions :-(

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



Is there any way to get onto merlot1?

I can see that populate_physmap failed but no indication why.

-boris

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386 15 guest-localmigrate/x10 fail REGR. 
vs. 105021

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   5 xen-buildfail   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  fe6e8188f3ad91e166338b9962a06afab9b776cd
baseline version:
 xen  5a77ccf609da289131bd1664ee20c17b1f9bb93c

Last test of basis   105021  2017-01-30 15:02:49 Z0 days
Testing same since   105036  2017-01-30 22:02:29 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Konrad Rzeszutek Wilk 
  Razvan Cojocaru 
  Tamas K Lengyel 
  Wei Liu 

jobs:
 build-amd64  pass
 build-arm64  fail
 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 fail
 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 fe6e8188f3ad91e166338b9962a06afab9b776cd
Author: Tamas K Lengyel 
Date:   Fri Jan 27 11:25:23 2017 -0700

xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

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

Also expose the xc_domain_cacheflush through xenctrl.h.

Signed-off-by: Tamas K Lengyel 
Acked-by: Wei Liu 
Reviewed-by: Stefano Stabellini 

commit a43a9ce34b0f8b3006101c34c2de39d9a3c8c686
Author: Tamas K Lengyel 
Date:   Fri Dec 9 12:59:25 2016 -0700

p2m: split mem_access into separate files

This patch relocates mem_access components that are currently mixed with p2m
code into separate files. This better aligns the code with similar 
subsystems,
such as mem_sharing and mem_paging, which are already in separate files. 
There
are no code-changes introduced, the patch is mechanical code movement.

On ARM we also relocate the static inline gfn_next_boundary function to 
p2m.h
as it is a function the mem_access code needs access to.

Signed-off-by: Tamas K Lengyel 
Acked-by: Razvan Cojocaru 
Reviewed-by: Stefano Stabellini 
Acked-by: George Dunlap 
Acked-by: Konrad Rzeszutek Wilk 

commit 821b88f390ab8f64f2164ce03080a9197dcb7ebc
Author: Tamas K Lengyel 
Date:   Fri Dec 9 12:59:24 2016 -0700

arm/mem_access: adjust check_and_get_page to not rely on current

The only caller of this function is get_page_from_gva which already takes
a vcpu pointer as input. Pass this along to make the function in-line with
its intended use-case.

Signed-off-by: Tamas K Lengyel 
Reviewed-by: Stefano Stabellini 
(qemu changes not included)

[Xen-devel] [qemu-mainline test] 105016: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

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
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-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-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuua0def594286d9110a6035e02eef558cf3cf5d847
baseline version:
 qemuu3aca12f841fcd6f3a7477076dad0d564360500de

Last test of basis   104844  2017-01-28 16:44:14 Z2 days
Testing same since   105016  2017-01-30 13:49:51 Z0 days1 attempts


People who touched revisions under test:
  Eric Farman 
  Ladi Prosek 
  Laszlo Ersek 
  Marc-André Lureau 
  Paolo Bonzini 
  Pavel Dovgalyuk 
  Peter Lieven 
  Peter Maydell 
  Peter Xu 
  Phil Dennis-Jordan 
  Thomas Huth 

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

Re: [Xen-devel] [PATCH RESEND v5 02/24] x86: refactor psr: remove L3 CAT/CDP codes.

[Konrad Rzeszutek Wilk]

On Thu, Jan 19, 2017 at 02:01:04PM +0800, Yi Sun wrote:
> The current cache allocation codes in psr.c do not consider
> future features addition and are not friendly to extend.
> 
> To make psr.c be more flexible to add new features and fulfill
> the program principle, open for extension but closed for
> modification, we have to refactor the psr.c:
> 1. Analyze cache allocation features and abstract general data
>structures.
> 2. Analyze the init and all other functions flow, abstract all
>steps that different features may have different implementations.
>Make these steps be callback functions and register feature
>specific fuctions. Then, the main processes will not be changed
>when introducing a new feature.
> 
> Because the quantity of refactor codes is big and the logics are
> changed a lot, it will cause reviewers confused if just change
> old codes. Reviewers have to understand both old codes and new
> implementations. After review iterations from V1 to V3, Jan has
> proposed to remove all old cache allocation codes firstly, then
> implement new codes step by step. This will help to make codes
> be more easily reviewable.
> 
> There is no construction without destruction. So, this patch
> removes all current L3 CAT/CDP codes in psr.c. The following
> patches will introduce the new mechanism.
> 
> Signed-off-by: Yi Sun 
> Acked-by: Jan Beulich 

Reviewed-by: Konrad Rzeszutek Wilk 

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

[Xen-devel] [linux-linus test] 105012: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl 15 guest-localmigrate fail in 104984 pass in 105012
 test-amd64-amd64-xl-multivcpu 14 guest-saverestore fail in 104984 pass in 
105012
 test-amd64-amd64-xl-credit2  15 guest-localmigrate fail pass in 104984
 test-amd64-i386-xl-xsm   15 guest-localmigrate fail pass in 104984
 test-amd64-amd64-xl-xsm   9 debian-install fail pass in 104984
 test-amd64-amd64-xl  15 guest-localmigrate fail pass in 104984

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline 
untested
 test-armhf-armhf-libvirt-raw  6 xen-bootfail baseline untested
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254

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

version targeted for testing:
 linux566cf877a1fcb6d6dc0126b076aad062054c2637
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  571 days
Failing since 59348  2015-07-10 04:24:05 Z  570 days  235 attempts
Testing same since   104984  2017-01-30 02:49:53 Z 

[Xen-devel] [linux-linus bisection] complete test-armhf-armhf-xl-multivcpu

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-armhf-armhf-xl-multivcpu
testid xen-boot

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  566cf877a1fcb6d6dc0126b076aad062054c2637
  Bug not present: 691429e13dfaf5b0994b07cc166db41bd608ee3d
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/105029/


  (Revision log too long, omitted.)


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-armhf-armhf-xl-multivcpu.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/test-armhf-armhf-xl-multivcpu.xen-boot
 --summary-out=tmp/105029.bisection-summary --basis-template=59254 
--blessings=real,real-bisect linux-linus test-armhf-armhf-xl-multivcpu xen-boot
Searching for failure / basis pass:
 105012 fail [host=arndale-bluewater] / 104684 [host=cubietruck-gleizes] 104637 
[host=cubietruck-picasso] 92228 [host=cubietruck-picasso] 92125 
[host=cubietruck-picasso] 92005 [host=cubietruck-picasso] 91862 
[host=cubietruck-picasso] 91779 [host=cubietruck-picasso] 91700 
[host=arndale-lakeside] 91591 [host=cubietruck-gleizes] 91416 
[host=cubietruck-metzinger] 91263 [host=cubietruck-metzinger] 90908 
[host=cubietruck-metzinger] 89304 [host=arndale-westfield] 88655 
[host=cubietruck-braque] 88539 [host=cubietruck-braque] 88416 
[host=cubietruck-braque] 85667 [host=cubietruck-braque] 85614 
[host=cubietruck-braque] 85509 [host=cubietruck-braque] 85353 
[host=cubietruck-braque] 85168 [host=cubietruck-braque] 84616 
[host=cubietruck-braque] 84472 [host=arndale-westfield] 84379 
[host=cubietruck-picasso] 84300 ok.
Failure / basis pass flights: 105012 / 84300
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 566cf877a1fcb6d6dc0126b076aad062054c2637 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
5cd2e1739763915e6b4c247eef71f948dc808bd5 
c13f0f9a331153a57eedfe8c80f1e2f6d4f01dcc
Basis pass 691429e13dfaf5b0994b07cc166db41bd608ee3d 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
316a862e5534249a6e6d876b4e203342d3fb870e 
abf8824fe530bcf060c757596f68663c87546a6a
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#691429e13dfaf5b0994b07cc166db41bd608ee3d-566cf877a1fcb6d6dc0126b076aad062054c2637
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen.git#316a862e5534249a6e6d876b4e203342d3fb870e-5cd2e1739763915e6b4c247eef71f948dc808bd5
 
git://xenbits.xen.org/xen.git#abf8824fe530bcf060c757596f68663c87546a6a-c13f0f9a331153a57eedfe8c80f1e2f6d4f01dcc
adhoc-revtuple-generator: tree discontiguous: linux-2.6
adhoc-revtuple-generator: tree discontiguous: qemu-xen
adhoc-revtuple-generator: tree discontiguous: xen
Loaded 4 nodes in revision graph
Searching for test results:
 82419 [host=cubietruck-metzinger]
 82614 [host=cubietruck-metzinger]
 82764 [host=cubietruck-metzinger]
 82911 [host=cubietruck-metzinger]
 83118 [host=cubietruck-metzinger]
 83452 [host=cubietruck-metzinger]
 83655 [host=cubietruck-metzinger]
 83810 [host=cubietruck-metzinger]
 84169 [host=arndale-metrocentre]
 84300 pass 691429e13dfaf5b0994b07cc166db41bd608ee3d 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
316a862e5534249a6e6d876b4e203342d3fb870e 
abf8824fe530bcf060c757596f68663c87546a6a
 84379 [host=cubietruck-picasso]
 84472 [host=arndale-westfield]
 84616 [host=cubietruck-braque]
 85168 [host=cubietruck-braque]
 85353 [host=cubietruck-braque]
 85509 [host=cubietruck-braque]
 85614 [host=cubietruck-braque]
 85667 [host=cubietruck-braque]
 85725 [host=cubietruck-braque]
 85776 [host=cubietruck-braque]
 85870 [host=cubietruck-braque]
 85988 [host=cubietruck-braque]
 86111 [host=cubietruck-braque]
 86047 [host=cubietruck-braque]
 86187 [host=cubietruck-braque]
 86279 [host=cubietruck-braque]
 86368 [host=cubietruck-braque]
 86449 [host=cubietruck-braque]
 86542 [host=cubietruck-braque]
 86626 [host=cubietruck-braque]
 86811 [host=cubietruck-braque]
 86715 [host=cubietruck-braque]
 86882 [host=cubietruck-braque]
 87133 []
 87236 []
 87315 []
 87418 [host=cubietruck-braque]
 87558 [host=cubietruck-braque]
 87701 [host=cubietruck-braque]
 87832 [host=cubietruck-braque]
 87977 [host=cubietruck-braque]
 88131 [host=cubietruck-braque]
 88284 

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

[Stefano Stabellini]

On Mon, 30 Jan 2017, Tamas K Lengyel wrote:
> On Mon, Jan 30, 2017 at 9:01 AM, Julien Grall  wrote:
> > Hi Stefano,
> >
> > On 27/01/17 23:53, Stefano Stabellini wrote:
> >>
> >> On Fri, 27 Jan 2017, Julien Grall wrote:
> >>>
> >>> On 27/01/2017 20:41, Stefano Stabellini wrote:
> 
>  On Fri, 27 Jan 2017, Tamas K Lengyel wrote:
> >>>
> >>> For the second instance, we have no other choice.
> >>
> >>
> >> Most alloc_heap_pages (alloc_xenheap_pages and alloc_domheap_pages) are
> >> done at domain initialization, so they would also be taken care by
> >> flushing the instruction cache before the domain is running. There are
> >> only very few exceptions to that, the main one being ballooning, and we
> >> need another icache flush in that case. But I think we should avoid
> >> doing global icache flushes every time alloc_heap_pages is called.
> >
> >
> > The invalidation of the full icache is unfortunate but necessary in non-PIPT
> > cache. For PIPT cache you could do invalidation by VA.
> >
> > Limiting the number of call is a nice optimization, but we need to be
> > careful how to do it. Until then, a full icache invalidation (or by VA for
> > PIPT) is the best solution.
> >
>  I am also wondering about all the libxc/libxl callers, many of whom
>  don't need an icache flush. Ideally we would have an argument in
>  XEN_DOMCTL_cacheflush to specify the type of cache flush we need,
>  similar to GNTTABOP_cache_flush.
> >>>
> >>>
> >>> Unless the instruction cache will be flushed before the guest is booting,
> >>> all
> >>> the callers of DOMCTL_cacheflush will require the invalidation.
> >>
> >>
> >> DOMCTL_cacheflush is called several time during the domain build, it is
> >> certainly better to do the icache flush once, rather than many times.
> >>
> >> If we decide to perform one icache flush at domain creation in Xen at
> >> the right time, we still need XEN_DOMCTL_cacheflush in its current form
> >> to flush the dcache.
> >>
> >> Also we still need a way to flush the icache to solve Tamas' problem
> >> with mem_access at run time.
> >>
> >> As a consequence, even after introducing one icache flush in Xen at
> >> domain creation, I think we still need a new "icache flush" flag in
> >> XEN_DOMCTL_cacheflush: all the current callers would not use it, but
> >> mem_access userspace components will be able to use it.
> >
> >
> > Why do we need a flag? No matter the way the flag is defined (set -> icache
> > invalidation vs set -> no icache invalidation), a user will likely misuse
> > it. The hypervisor is the best person to decide whether the icache flush is
> > needed. Aside at domain building time, 99.9% (to not say 100%) of the call
> > to cacheflush will require the invalidation of the icache.
> >
> > Furthermore, if you implement the optimization for invalidating PIP icache
> > (e.g by VA rather than full), a user will not have the possibility to
> > invalidate the full icache.
> >
> > So I would go the same way as it has been done for tlbflush (see bbb17f6
> > "move TLB-flush filtering out into populate_physmap during vm creation").
> > Let Xen decides when to optimize the invalidation.
> >
> 
> Giving the user the option during the domctl to choose which cache to
> flush I think would be fine. I would agree that the most likely case
> is that both caches should be flushed at the same time, but who knows,
> having the option may be useful for someone. At least the linux
> syscall has that option as well
> (http://man7.org/linux/man-pages/man2/cacheflush.2.html).
> 
> In any rate, I already made the patch that implements it:
> https://github.com/tklengyel/xen/compare/icache?expand=1. Let me know
> if you would want me to send it or not.

Thanks Tamas. I'll take your v4 patch as is. Then, we'll figure out
what's the best way to avoid flushing the icache too often, especially
at VM creation time.

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

Re: [Xen-devel] [PATCH v2 2/2] p2m: split mem_access into separate files

[Stefano Stabellini]

On Fri, 9 Dec 2016, Tamas K Lengyel wrote:
> This patch relocates mem_access components that are currently mixed with p2m
> code into separate files. This better aligns the code with similar subsystems,
> such as mem_sharing and mem_paging, which are already in separate files. There
> are no code-changes introduced, the patch is mechanical code movement.
> 
> On ARM we also relocate the static inline gfn_next_boundary function to p2m.h
> as it is a function the mem_access code needs access to.
> 
> Signed-off-by: Tamas K Lengyel 
> Acked-by: Razvan Cojocaru 

Reviewed-by: Stefano Stabellini 

I'll commit both patches shortly.

> ---
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> 
> v2: Don't move ARM radix tree functions
> Include asm/mem_accesss.h in xen/mem_access.h
> ---
>  MAINTAINERS  |   2 +
>  xen/arch/arm/Makefile|   1 +
>  xen/arch/arm/mem_access.c| 431 
>  xen/arch/arm/p2m.c   | 414 +--
>  xen/arch/arm/traps.c |   1 +
>  xen/arch/x86/mm/Makefile |   1 +
>  xen/arch/x86/mm/mem_access.c | 462 
> +++
>  xen/arch/x86/mm/p2m.c| 421 ---
>  xen/arch/x86/vm_event.c  |   3 +-
>  xen/common/mem_access.c  |   2 +-
>  xen/include/asm-arm/mem_access.h |  53 +
>  xen/include/asm-arm/p2m.h|  31 ++-
>  xen/include/asm-x86/mem_access.h |  61 ++
>  xen/include/asm-x86/p2m.h|  24 +-
>  xen/include/xen/mem_access.h |  67 +-
>  xen/include/xen/p2m-common.h |  52 -
>  16 files changed, 1089 insertions(+), 937 deletions(-)
>  create mode 100644 xen/arch/arm/mem_access.c
>  create mode 100644 xen/arch/x86/mm/mem_access.c
>  create mode 100644 xen/include/asm-arm/mem_access.h
>  create mode 100644 xen/include/asm-x86/mem_access.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f0d0202..fb26be3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -402,6 +402,8 @@ S:Supported
>  F:   tools/tests/xen-access
>  F:   xen/arch/*/monitor.c
>  F:   xen/arch/*/vm_event.c
> +F:   xen/arch/arm/mem_access.c
> +F:   xen/arch/x86/mm/mem_access.c
>  F:   xen/arch/x86/hvm/monitor.c
>  F:   xen/common/mem_access.c
>  F:   xen/common/monitor.c
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index da39d39..b095e8a 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -24,6 +24,7 @@ obj-y += io.o
>  obj-y += irq.o
>  obj-y += kernel.o
>  obj-$(CONFIG_LIVEPATCH) += livepatch.o
> +obj-y += mem_access.o
>  obj-y += mm.o
>  obj-y += monitor.o
>  obj-y += p2m.o
> diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
> new file mode 100644
> index 000..a6e5bcd
> --- /dev/null
> +++ b/xen/arch/arm/mem_access.c
> @@ -0,0 +1,431 @@
> +/*
> + * arch/arm/mem_access.c
> + *
> + * Architecture-specific mem_access handling routines
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public
> + * License v2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> + * License along with this program; If not, see 
> .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static int __p2m_get_mem_access(struct domain *d, gfn_t gfn,
> +xenmem_access_t *access)
> +{
> +struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +void *i;
> +unsigned int index;
> +
> +static const xenmem_access_t memaccess[] = {
> +#define ACCESS(ac) [p2m_access_##ac] = XENMEM_access_##ac
> +ACCESS(n),
> +ACCESS(r),
> +ACCESS(w),
> +ACCESS(rw),
> +ACCESS(x),
> +ACCESS(rx),
> +ACCESS(wx),
> +ACCESS(rwx),
> +ACCESS(rx2rw),
> +ACCESS(n2rwx),
> +#undef ACCESS
> +};
> +
> +ASSERT(p2m_is_locked(p2m));
> +
> +/* If no setting was ever set, just return rwx. */
> +if ( !p2m->mem_access_enabled )
> +{
> +*access = XENMEM_access_rwx;
> +return 0;
> +}
> +
> +/* If request to get default access. */
> +if ( gfn_eq(gfn, INVALID_GFN) )
> +{
> +*access = memaccess[p2m->default_access];
> +return 0;
> +

Re: [Xen-devel] [PATCH v2 1/2] arm/mem_access: adjust check_and_get_page to not rely on current

[Stefano Stabellini]

On Fri, 9 Dec 2016, Tamas K Lengyel wrote:
> The only caller of this function is get_page_from_gva which already takes
> a vcpu pointer as input. Pass this along to make the function in-line with
> its intended use-case.
> 
> Signed-off-by: Tamas K Lengyel 

Reviewed-by: Stefano Stabellini 

> ---
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> ---
>  xen/arch/arm/p2m.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index cc5634b..837be1d 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1461,7 +1461,8 @@ mfn_t gfn_to_mfn(struct domain *d, gfn_t gfn)
>   * we indeed found a conflicting mem_access setting.
>   */
>  static struct page_info*
> -p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned long flag)
> +p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned long flag,
> +  const struct vcpu *v)
>  {
>  long rc;
>  paddr_t ipa;
> @@ -1470,7 +1471,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
> long flag)
>  xenmem_access_t xma;
>  p2m_type_t t;
>  struct page_info *page = NULL;
> -struct p2m_domain *p2m = >domain->arch.p2m;
> +struct p2m_domain *p2m = >domain->arch.p2m;
>  
>  rc = gva_to_ipa(gva, , flag);
>  if ( rc < 0 )
> @@ -1482,7 +1483,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
> long flag)
>   * We do this first as this is faster in the default case when no
>   * permission is set on the page.
>   */
> -rc = __p2m_get_mem_access(current->domain, gfn, );
> +rc = __p2m_get_mem_access(v->domain, gfn, );
>  if ( rc < 0 )
>  goto err;
>  
> @@ -1546,7 +1547,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
> long flag)
>  
>  page = mfn_to_page(mfn_x(mfn));
>  
> -if ( unlikely(!get_page(page, current->domain)) )
> +if ( unlikely(!get_page(page, v->domain)) )
>  page = NULL;
>  
>  err:
> @@ -1587,7 +1588,7 @@ struct page_info *get_page_from_gva(struct vcpu *v, 
> vaddr_t va,
>  
>  err:
>  if ( !page && p2m->mem_access_enabled )
> -page = p2m_mem_access_check_and_get_page(va, flags);
> +page = p2m_mem_access_check_and_get_page(va, flags, v);
>  
>  p2m_read_unlock(p2m);
>  
> -- 
> 2.10.2
> 

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

[Xen-devel] [RFC v2] Device memory mappings for Dom0 on ARM64 ACPI systems

[Stefano Stabellini]

Hi all,

a couple of weeks ago I sent a detailed email asking for feedback on a
problem with Linux on Xen on ACPI systems:

http://marc.info/?l=linux-arm-kernel=148469169210500=2

In short, on BUS_NOTIFY_ADD_DEVICE events, Linux (as Dom0) requests
stage-2 MMIO regions mappings via hypercall to Xen. This works well for
devices, but few MMIO regions exist which do not belong to any devices,
therefore today they don't get mapped. For example: ACPI
OperationRegion, ECAM, other memory regions described in static tables
such as BERT.

In the email linked above, I suggested a few different approaches to
solving this issue. It looks like the consensus is around solution b):

> b) Otherwise, we could write an alternative implementation of ioremap
> on arm64. The Xen specific ioremap would request a stage-2 mapping
> first, then create the stage-1 mapping as usual. However, this means
> issuing an hypercall for every ioremap call.

If that's OK for you, we are going to move forward with this approach.

Thanks,

Stefano

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

Re: [Xen-devel] [PATCH RESEND v5 01/24] docs: create L2 Cache Allocation Technology (CAT) feature document

[Konrad Rzeszutek Wilk]

> > +# Testing
> > +
> > +L2 CAT uses same xl interfaces as L3 CAT/CDP. So, we can execute these
> > +commands to verify L2 CAT and L3 CAT/CDP on different HWs support them.
> > +
> > +For example:
> > +root@:~$ xl psr-hwinfo --cat
> > +Cache Allocation Technology (CAT): L2
> > +Socket ID   : 0
> > +Maximum COS : 3
> > +CBM length  : 8
> > +Default CBM : 0xff
> > +
> > +root@:~$ xl psr-cat-cbm-set -l2 1 0x7f
> > +
> > +root@:~$ xl psr-cat-show -l2 1
> > +Socket ID   : 0
> > +Default CBM : 0xff
> > +   ID NAME CBM
> > +1 ubuntu140x7f
> > +

I tried finding the Intel SDM (December 2016) what the format
of CBM is as the value '0x7f' does not really mean much to me.

Right above Figure 17.28 it says:

"Figure 17-27 also shows three examples of sets of Cache Capacity Bitmasks. For 
simplicity these are represented
as 8-bit vectors, though this may vary _depending on the implementation and how 
the mask is mapped to the avail-
able cache capacity._"


So in other words - not documented. 

Then later is says:

" Rather, this is a convenient manner to represent capacity,
overlap and isolation of cache space. For example, executing a POPCNT 
instruction (population count of set bits) on
the capacity bitmask can provide the fraction of cache space that a class of 
service can allocate into."

OK, so _can_ (but not _MUST_), so again implementation specific - and
can provide a fraction of cache space.

Which would imply that the values could be:

0x0F - half of L2
0x03 - quarter of L2

Is there some other documentation that explains this in more details?

If it is like I mentioned would it make sense to have 'xl' be capable
of dealing with string values? such as "three-quarters", "half", etc
and then set it? Or percentage and map that to the correct value?

Like:

xl psr-cat-cbm-set -l2 ubuntu14 50%

would be quite obvious instead of say 0x0F?

Thanks.

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

[Xen-devel] [xtf test] 105019: all pass - PUSHED

[osstest service owner]

flight 105019 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105019/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  013927f81afb08e06314b66c8c8cd8549d5711c1
baseline version:
 xtf  7e1bc8009286dcf505a1be3587d8d8388d8ab95d

Last test of basis   104606  2017-01-23 11:46:13 Z7 days
Testing same since   105019  2017-01-30 14:14:51 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   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=xtf
+ revision=013927f81afb08e06314b66c8c8cd8549d5711c1
+ . ./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 xtf 
013927f81afb08e06314b66c8c8cd8549d5711c1
+ branch=xtf
+ revision=013927f81afb08e06314b66c8c8cd8549d5711c1
+ . ./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=xtf
+ xenbranch=xen-unstable
+ '[' xxtf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' x013927f81afb08e06314b66c8c8cd8549d5711c1 = 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
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' 

Re: [Xen-devel] [PATCH] xen-netfront: Delete rx_refill_timer in xennet_disconnect_backend()

[Boris Ostrovsky]

On 01/30/2017 02:06 PM, Eric Dumazet wrote:
> On Mon, 2017-01-30 at 13:23 -0500, Boris Ostrovsky wrote:
>
>> We do netif_carrier_off() first thing in xennet_disconnect_backend() and
>> the only place where the timer is rearmed is xennet_alloc_rx_buffers(),
>> which is guarded by netif_carrier_ok() check.
> Oh well, testing netif_carrier_ok() in packet processing fast path looks
> unusual and a waste of cpu cycles. I've never seen that pattern before.
>
> If one day, we remove this netif_carrier_ok() test during a cleanup,
> then the race window will open again.


I don't know much about napi but I wonder whether I can indeed disable
it in xennet_disconnect_backend(). I don't see how anything can happen
after disconnect since it unmaps the rings. And then napi is re-enabled
during reconnection in xennet_create_queues(). In which case am not sure
there is any need for xennet_destroy_queues() as everything there could
be folded into xennet_disconnect_backend().

-boris



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

Re: [Xen-devel] [PATCH] xen-netfront: Delete rx_refill_timer in xennet_disconnect_backend()

[Eric Dumazet]

On Mon, 2017-01-30 at 13:23 -0500, Boris Ostrovsky wrote:

> We do netif_carrier_off() first thing in xennet_disconnect_backend() and
> the only place where the timer is rearmed is xennet_alloc_rx_buffers(),
> which is guarded by netif_carrier_ok() check.

Oh well, testing netif_carrier_ok() in packet processing fast path looks
unusual and a waste of cpu cycles. I've never seen that pattern before.

If one day, we remove this netif_carrier_ok() test during a cleanup,
then the race window will open again.



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

Re: [Xen-devel] [PATCH] xen/p2m: Remove np2m-specific filter from generic p2m_flush_table

[Matt Leinhos]

George / Tamas,

I'm away from my dev machine so I cannot test. Thank you both for
working so quickly to resolve this behavior!

Best regards,
--Matt

On 01/30/2017 11:07 AM, Tamas K Lengyel wrote:
> Hi George,
> yeap, this solves old mem_access settings being triggered when I
> recreate altp2m views. Thanks!
> 
> On Mon, Jan 30, 2017 at 8:17 AM, George Dunlap  
> wrote:
>> Commit 71bb7304e7a7a35ea6df4b0cedebc35028e4c159 added flushing of
>> nested p2m tables whenever the host p2m table changed.  Unfortunately
>> in the process, it added a filter to the generic p2m_flush_table()
>> function so that the p2m would only be flushed if it was being used as
>> a nested p2m.  This meant that the p2m was not being flushed at all
>> for altp2m callers.
>>
>> Instead do the nested p2m filtering in p2m_flush_nestedp2m().
>>
>> NB that this is not a security issue: The only time this codepath is
>> called is in cases where either nestedp2m or altp2m is enabled, and
>> neither of them are in security support.
>>
>> Reported-by: Matt Leinhos 
>> Signed-off-by: George Dunlap 
>> ---
>> I've smoke-tested this with nested virt and it seems to work fine.
>> Matt / Tamas, could you test this with altp2m and see if it fixes your
>> issue?
> 
> Tested-by: Tamas K Lengyel 
> 
>>
>>
>> CC: Liang Li 
>> CC: Yang Zhang 
>> CC: Tim Deegan 
>> CC: Tamas K Lengyel 
>> CC: Andrew Cooper 
>> CC: Jan Beulich 
>> CC: Matt Leinhos 
>> ---
>>  xen/arch/x86/mm/p2m.c | 12 +---
>>  1 file changed, 5 insertions(+), 7 deletions(-)
>>
>> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
>> index aa627d8..0849c6e 100644
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -2048,12 +2048,6 @@ p2m_flush_table(struct p2m_domain *p2m)
>>  ASSERT(page_list_empty(>pod.super));
>>  ASSERT(page_list_empty(>pod.single));
>>
>> -if ( p2m->np2m_base == P2M_BASE_EADDR )
>> -{
>> -p2m_unlock(p2m);
>> -return;
>> -}
>> -
>>  /* This is no longer a valid nested p2m for any address space */
>>  p2m->np2m_base = P2M_BASE_EADDR;
>>
>> @@ -2088,7 +2082,11 @@ p2m_flush_nestedp2m(struct domain *d)
>>  {
>>  int i;
>>  for ( i = 0; i < MAX_NESTEDP2M; i++ )
>> -p2m_flush_table(d->arch.nested_p2m[i]);
>> +{
>> +struct p2m_domain *p2m = d->arch.nested_p2m[i];
>> +if ( p2m->np2m_base != P2M_BASE_EADDR )
>> +p2m_flush_table(p2m);
>> +}
>>  }
>>
>>  struct p2m_domain *
>> --
>> 2.1.4
>>

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

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

[Xen-devel] [PATCH 25/28] ARM: vITS: handle INVALL command

[Andre Przywara]

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 | 37 +
 1 file changed, 37 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 82f7bcc..75d1e12 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -316,6 +316,40 @@ 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. Since our property table is referenced when
+ * needed, we don't need to sync anything, really. But we have to take care
+ * of LPIs getting enabled if there is an interrupt pending.
+ * To catch every LPI without iterating through the device table we just
+ * look for set bits in our virtual pending table and check the status of
+ * the enabled bit in the respective property table entry.
+ * This actually covers every (pending) LPI from every redistributor,
+ * but update_lpi_enabled_status() is a NOP for LPIs not being mapped
+ * to the redistributor/VCPU we are interested in.
+ */
+static int its_handle_invall(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t collid = its_cmd_get_collection(cmdptr);
+struct vcpu *vcpu;
+int vlpi = 0;
+
+spin_lock(>its_lock);
+vcpu = get_vcpu_from_collection(its, collid);
+spin_unlock(>its_lock);
+
+do {
+vlpi = find_next_bit(vcpu->arch.vgic.pendtable,
+ its->d->arch.vgic.nr_lpis, vlpi);
+if ( vlpi >= its->d->arch.vgic.nr_lpis )
+break;
+
+update_lpi_enabled_status(its, vcpu, vlpi);
+} while (1);
+
+return 0;
+}
+
 static int its_handle_mapc(struct virt_its *its, uint64_t *cmdptr)
 {
 uint32_t collid = its_cmd_get_collection(cmdptr);
@@ -462,6 +496,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its,
 case GITS_CMD_INV:
 its_handle_inv(its, cmdptr);
break;
+case GITS_CMD_INVALL:
+its_handle_invall(its, cmdptr);
+   break;
 case GITS_CMD_MAPC:
 its_handle_mapc(its, cmdptr);
 break;
-- 
2.9.0


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

[Xen-devel] [PATCH 22/28] ARM: vITS: handle MOVI command

[Andre Przywara]

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| 14 ++
 xen/arch/arm/gic-v3-lpi.c| 13 +
 xen/arch/arm/vgic-v3-its.c   | 23 +++
 xen/include/asm-arm/gic_v3_its.h |  4 
 4 files changed, 54 insertions(+)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 1268d64..d37b7b6 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -690,6 +690,20 @@ int gicv3_assign_guest_event(struct domain *d, uint32_t 
devid, uint32_t eventid,
 return 0;
 }
 
+/* Changes the target VCPU for a given host LPI assigned to a domain. */
+int gicv3_lpi_change_vcpu(struct domain *d,
+  uint32_t devid, uint32_t eventid, int vcpu_id)
+{
+uint32_t host_lpi = translate_event(d, devid, eventid);
+
+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 494ae22..66d6eff 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -153,6 +153,19 @@ int gicv3_lpi_update_host_entry(uint32_t host_lpi, int 
domain_id, int vcpu_id,
 return 0;
 }
 
+int gicv3_lpi_update_host_vcpuid(uint32_t host_lpi, int vcpu_id)
+{
+union host_lpi *hlpip;
+
+host_lpi -= LPI_OFFSET;
+
+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;
+}
+
 uint64_t gicv3_lpi_allocate_pendtable(void)
 {
 uint64_t reg;
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 3e74f46..fb9caf0 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -329,6 +329,23 @@ 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, 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,
@@ -365,6 +382,12 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its,
 case GITS_CMD_MAPTI:
 its_handle_mapti(its, cmdptr);
 break;
+case GITS_CMD_MOVALL:
+gdprintk(XENLOG_G_INFO, "ITS: ignoring MOVALL command\n");
+break;
+case GITS_CMD_MOVI:
+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 160ece3..bac0fe5 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -162,8 +162,12 @@ int gicv3_free_host_lpi_block(struct host_its *its, 
uint32_t lpi);
 int gicv3_assign_guest_event(struct domain *d,
  uint32_t devid, uint32_t eventid,
  struct vcpu *v, uint32_t virt_lpi);
+int gicv3_lpi_change_vcpu(struct domain *d,
+  uint32_t devid, uint32_t eventid, int vcpu_id);
 int gicv3_lpi_update_host_entry(uint32_t host_lpi, int domain_id, int vcpu_id,
 uint32_t virt_lpi);
+int gicv3_lpi_update_host_vcpuid(uint32_t host_lpi, int vcpu_id);
+
 #else
 
 static inline void gicv3_its_dt_init(const struct dt_device_node *node)
-- 
2.9.0


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

[Xen-devel] [PATCH 26/28] ARM: vITS: create and initialize virtual ITSes for Dom0

[Andre Przywara]

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   | 28 
 xen/arch/arm/vgic-v3.c   | 12 
 xen/include/asm-arm/domain.h |  1 +
 xen/include/asm-arm/gic_v3_its.h | 10 ++
 4 files changed, 51 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 75d1e12..6404ebd 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -891,6 +891,34 @@ 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)
+{
+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;
+its->baser0  = GITS_BASER_TYPE_DEVICE << GITS_BASER_TYPE_SHIFT;
+its->baser0 |= (7ULL << GITS_BASER_ENTRY_SIZE_SHIFT) | base_attr;
+its->baser1  = GITS_BASER_TYPE_COLLECTION << GITS_BASER_TYPE_SHIFT;
+its->baser1 |= (1ULL << GITS_BASER_ENTRY_SIZE_SHIFT) | base_attr;
+its->d = d;
+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 d1382be..8faec95 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1651,6 +1652,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;
@@ -1676,6 +1678,16 @@ 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;
+
+list_for_each_entry(hw_its, _its_list, entry)
+{
+/* Emulate the control registers frame (lower 64K). */
+vgic_v3_its_init_virtual(d, hw_its->addr);
+
+d->arch.vgic.has_its = true;
+}
+
 }
 else
 {
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 33c1851..27cc310 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -115,6 +115,7 @@ struct arch_domain
 uint8_t *proptable;
 struct rb_root its_devices; /* devices mapped to an ITS */
 spinlock_t its_devices_lock;/* protects the its_devices 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 bac0fe5..e75249b 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -146,6 +146,12 @@ uint64_t gicv3_get_redist_address(int cpu, bool use_pta);
 /* Map a collection for this host CPU to each host ITS. */
 int gicv3_its_setup_collection(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 LPIs.
+ */
+int vgic_v3_its_init_virtual(struct domain *d, paddr_t guest_addr);
+
 /* Map a device on the host by allocating an ITT on the host (ITS).
  * "bits" specifies how many events (interrupts) this device will need.
  * Setting "valid" to false deallocates the device.
@@ -202,6 +208,10 @@ static inline int gicv3_its_map_guest_device(struct domain 
*d, int host_devid,
 {
 return -ENODEV;
 }
+static inline int vgic_v3_its_init_virtual(struct domain *d, paddr_t 
guest_addr)
+{
+return 0;
+}
 
 #endif /* CONFIG_HAS_ITS */
 
-- 
2.9.0


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

[Xen-devel] [PATCH 13/28] ARM: vGICv3: handle virtual LPI pending and property tables

[Andre Przywara]

Allow a guest to provide the address and size for the memory regions
it has reserved for the GICv3 pending and property tables.
We sanitise the various fields of the respective redistributor
registers and map those pages into Xen's address space to have easy
access.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3.c   | 220 +++
 xen/arch/arm/vgic.c  |   4 +
 xen/include/asm-arm/domain.h |   8 +-
 xen/include/asm-arm/vgic.h   |  24 -
 4 files changed, 233 insertions(+), 23 deletions(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index b0653c2..c6db2d7 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -20,12 +20,14 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -229,12 +231,15 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 goto read_reserved;
 
 case VREG64(GICR_PROPBASER):
-/* LPI's not implemented */
-goto read_as_zero_64;
+if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
+*r = vgic_reg64_extract(v->domain->arch.vgic.rdist_propbase, info);
+return 1;
 
 case VREG64(GICR_PENDBASER):
-/* LPI's not implemented */
-goto read_as_zero_64;
+if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
+*r = vgic_reg64_extract(v->arch.vgic.rdist_pendbase, info);
+*r &= ~GICR_PENDBASER_PTZ;   /* WO, reads as 0 */
+return 1;
 
 case 0x0080:
 goto read_reserved;
@@ -302,11 +307,6 @@ bad_width:
 domain_crash_synchronous();
 return 0;
 
-read_as_zero_64:
-if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
-*r = 0;
-return 1;
-
 read_as_zero_32:
 if ( dabt.size != DABT_WORD ) goto bad_width;
 *r = 0;
@@ -331,11 +331,179 @@ read_unknown:
 return 1;
 }
 
+static uint64_t vgic_sanitise_field(uint64_t reg, uint64_t field_mask,
+int field_shift,
+uint64_t (*sanitise_fn)(uint64_t))
+{
+uint64_t field = (reg & field_mask) >> field_shift;
+
+field = sanitise_fn(field) << field_shift;
+
+return (reg & ~field_mask) | field;
+}
+
+/* We want to avoid outer shareable. */
+static uint64_t vgic_sanitise_shareability(uint64_t field)
+{
+switch (field) {
+case GIC_BASER_OuterShareable:
+return GIC_BASER_InnerShareable;
+default:
+return field;
+}
+}
+
+/* Avoid any inner non-cacheable mapping. */
+static uint64_t vgic_sanitise_inner_cacheability(uint64_t field)
+{
+switch (field) {
+case GIC_BASER_CACHE_nCnB:
+case GIC_BASER_CACHE_nC:
+return GIC_BASER_CACHE_RaWb;
+default:
+return field;
+}
+}
+
+/* Non-cacheable or same-as-inner are OK. */
+static uint64_t vgic_sanitise_outer_cacheability(uint64_t field)
+{
+switch (field) {
+case GIC_BASER_CACHE_SameAsInner:
+case GIC_BASER_CACHE_nC:
+return field;
+default:
+return GIC_BASER_CACHE_nC;
+}
+}
+
+static uint64_t sanitize_propbaser(uint64_t reg)
+{
+reg = vgic_sanitise_field(reg, GICR_PROPBASER_SHAREABILITY_MASK,
+  GICR_PROPBASER_SHAREABILITY_SHIFT,
+  vgic_sanitise_shareability);
+reg = vgic_sanitise_field(reg, GICR_PROPBASER_INNER_CACHEABILITY_MASK,
+  GICR_PROPBASER_INNER_CACHEABILITY_SHIFT,
+  vgic_sanitise_inner_cacheability);
+reg = vgic_sanitise_field(reg, GICR_PROPBASER_OUTER_CACHEABILITY_MASK,
+  GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT,
+  vgic_sanitise_outer_cacheability);
+
+reg &= ~GICR_PROPBASER_RES0_MASK;
+return reg;
+}
+
+static uint64_t sanitize_pendbaser(uint64_t reg)
+{
+reg = vgic_sanitise_field(reg, GICR_PENDBASER_SHAREABILITY_MASK,
+  GICR_PENDBASER_SHAREABILITY_SHIFT,
+  vgic_sanitise_shareability);
+reg = vgic_sanitise_field(reg, GICR_PENDBASER_INNER_CACHEABILITY_MASK,
+  GICR_PENDBASER_INNER_CACHEABILITY_SHIFT,
+  vgic_sanitise_inner_cacheability);
+reg = vgic_sanitise_field(reg, GICR_PENDBASER_OUTER_CACHEABILITY_MASK,
+  GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT,
+  vgic_sanitise_outer_cacheability);
+
+reg &= ~GICR_PENDBASER_RES0_MASK;
+return reg;
+}
+
+/*
+ * Mark a given number of guest pages as used (by increasing their refcount),
+ * starting with the given guest address. This needs to be called once before
+ * calling (possibly repeatedly) map_guest_pages().
+ * Before the domain gets destroyed, call put_guest_pages() to drop the
+ * reference.
+ */
+int get_guest_pages(struct domain *d, 

[Xen-devel] [PATCH 28/28] ARM: vGIC: advertising LPI support

[Andre Przywara]

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 | 88 +++---
 1 file changed, 83 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 8faec95..6d5b7f4 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),
+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;
 
 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;
@@ -502,6 +507,40 @@ bool vgic_can_inject_lpi(struct vcpu *vcpu, uint32_t vlpi)
 return false;
 }
 
+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.proptable )
+{
+v->domain->arch.vgic.nr_lpis = nr_lpis;
+nr_pages = DIV_ROUND_UP(nr_lpis, PAGE_SIZE);
+
+get_guest_pages(v->domain, reg & GENMASK(51, 12), nr_pages);
+v->domain->arch.vgic.proptable = map_guest_pages(v->domain,
+ reg & GENMASK(51, 12),
+ nr_pages);
+printk("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(51, 12), nr_pages);
+v->arch.vgic.pendtable = map_guest_pages(v->domain,
+ reg & GENMASK(51, 12), nr_pages);
+
+printk("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)
@@ -512,8 +551,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) )
+return 1;
+
+vgic_vcpu_enable_lpis(v);
+
+return 1;
 
 case VREG32(GICR_IIDR):
 /* RO */
@@ -1113,6 +1162,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;
+}
 typer |= (irq_bits - 1) << GICD_TYPE_ID_BITS_SHIFT;
 
 *r = vgic_reg32_extract(typer, info);
@@ -1729,6 +1783,30 @@ static int vgic_v3_domain_init(struct domain *d)
 
 static void vgic_v3_domain_free(struct domain *d)
 {
+int nr_pages;
+struct vcpu *v;
+
+if ( d->arch.vgic.proptable )
+{
+nr_pages = 

[Xen-devel] [PATCH 24/28] ARM: vITS: handle INV command

[Andre Przywara]

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 | 57 ++
 1 file changed, 57 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 8747890..82f7bcc 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -262,6 +262,60 @@ static int its_handle_int(struct virt_its *its, uint64_t 
*cmdptr)
 return 0;
 }
 
+/*
+ * For a given virtual LPI read the enabled bit 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 *pirq = lpi_to_pending(vcpu, vlpi, false);
+uint8_t property = its->d->arch.vgic.proptable[vlpi - LPI_OFFSET];
+
+if ( property & LPI_PROP_ENABLED )
+{
+if ( pirq )
+{
+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, property & LPI_PROP_PRIO_MASK);
+spin_unlock_irqrestore(>arch.vgic.lock, flags);
+}
+
+/* Check whether the LPI has fired while the guest had it disabled. */
+if ( test_and_clear_bit(vlpi - LPI_OFFSET, vcpu->arch.vgic.pendtable) )
+vgic_vcpu_inject_irq(vcpu, vlpi);
+}
+else
+{
+if ( pirq )
+{
+clear_bit(GIC_IRQ_GUEST_ENABLED, >status);
+gic_remove_from_queues(vcpu, vlpi);
+}
+}
+}
+
+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);
@@ -405,6 +459,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its,
 case GITS_CMD_INT:
 its_handle_int(its, cmdptr);
 break;
+case GITS_CMD_INV:
+its_handle_inv(its, cmdptr);
+   break;
 case GITS_CMD_MAPC:
 its_handle_mapc(its, cmdptr);
 break;
-- 
2.9.0


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

[Xen-devel] [PATCH 18/28] ARM: vITS: handle INT command

[Andre Przywara]

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 | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 48eb924..9307235 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -242,6 +242,26 @@ 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 vcpu *vcpu;
+uint32_t vlpi;
+uint8_t prop;
+
+if ( !read_itte(its, devid, eventid, , ) )
+return -1;
+
+prop = vcpu->domain->arch.vgic.proptable[vlpi - LPI_OFFSET];
+if ( prop & LPI_PROP_ENABLED )
+vgic_vcpu_inject_irq(vcpu, vlpi);
+else
+set_bit(vlpi - LPI_OFFSET, vcpu->arch.vgic.pendtable);
+
+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,
@@ -265,6 +285,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its,
 case GITS_CMD_CLEAR:
 its_handle_clear(its, cmdptr);
 break;
+case GITS_CMD_INT:
+its_handle_int(its, cmdptr);
+break;
 case GITS_CMD_SYNC:
 /* We handle ITS commands synchronously, so we ignore SYNC. */
break;
-- 
2.9.0


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

[Xen-devel] [PATCH 11/28] ARM: GICv3: forward pending LPIs to guests

[Andre Przywara]

Upon receiving an LPI, we need to find the right VCPU and virtual IRQ
number to get this IRQ injected.
Iterate our two-level LPI table to find this information quickly when
the host takes an LPI. Call the existing injection function to let the
GIC emulation deal with this interrupt.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v3-lpi.c | 41 +
 xen/arch/arm/gic.c|  6 --
 xen/include/asm-arm/irq.h |  8 
 3 files changed, 53 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index 8f6e7f3..d270053 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -86,6 +86,47 @@ uint64_t gicv3_get_redist_address(int cpu, bool use_pta)
 return per_cpu(redist_id, cpu) << 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;
+
+WRITE_SYSREG32(lpi, ICC_EOIR1_EL1);
+
+hlpip = gic_get_host_lpi(lpi);
+if ( !hlpip )
+return;
+
+hlpi.data = read_u64_atomic(>data);
+
+/* We may have mapped more host LPIs than the guest actually asked for. */
+if ( !hlpi.virt_lpi )
+return;
+
+d = get_domain_by_id(hlpi.dom_id);
+if ( !d )
+return;
+
+if ( hlpi.vcpu_id >= d->max_vcpus )
+{
+put_domain(d);
+return;
+}
+
+vcpu = d->vcpu[hlpi.vcpu_id];
+
+put_domain(d);
+
+vgic_vcpu_inject_irq(vcpu, hlpi.virt_lpi);
+}
+
 uint64_t gicv3_lpi_allocate_pendtable(void)
 {
 uint64_t reg;
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index bd3c032..7286e5d 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -700,8 +700,10 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
 local_irq_enable();
 do_IRQ(regs, irq, is_fiq);
 local_irq_disable();
-}
-else if (unlikely(irq < 16))
+} else if ( is_lpi(irq) )
+{
+do_LPI(irq);
+} else if ( unlikely(irq < 16) )
 {
 do_sgi(regs, irq);
 }
diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
index 8f7a167..ee47de8 100644
--- a/xen/include/asm-arm/irq.h
+++ b/xen/include/asm-arm/irq.h
@@ -34,6 +34,14 @@ struct irq_desc *__irq_to_desc(int irq);
 
 void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq);
 
+#ifdef CONFIG_HAS_ITS
+void do_LPI(unsigned int irq);
+#else
+static inline void do_LPI(unsigned int irq)
+{
+}
+#endif
+
 #define domain_pirq_to_irq(d, pirq) (pirq)
 
 bool_t is_assignable_irq(unsigned int irq);
-- 
2.9.0


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

[Xen-devel] [PATCH 17/28] ARM: vITS: handle CLEAR command

[Andre Przywara]

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.

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

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 982c51d..48eb924 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -129,8 +129,8 @@ static void put_devid_evid(struct virt_its *its, struct 
vits_itte *itte)
  * protect the ITTs with their less-than-page-size granularity.
  * Takes and drops the its_lock.
  */
-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;
 int collid;
@@ -214,6 +214,34 @@ static uint64_t its_cmd_mask_field(uint64_t *its_cmd,
 #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 *pirq;
+struct vcpu *vcpu;
+uint32_t vlpi;
+
+if ( !read_itte(its, devid, eventid, , ) )
+return -1;
+
+/* Remove a pending, but not yet injected guest IRQ. */
+pirq = lpi_to_pending(vcpu, vlpi, false);
+if ( pirq )
+{
+clear_bit(GIC_IRQ_GUEST_QUEUED, >status);
+gic_remove_from_queues(vcpu, vlpi);
+
+/* Mark this pending IRQ struct as availabe again. */
+if ( !test_bit(GIC_IRQ_GUEST_VISIBLE, >status) )
+pirq->irq = 0;
+}
+
+clear_bit(vlpi - LPI_OFFSET, vcpu->arch.vgic.pendtable);
+
+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,
@@ -234,6 +262,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its,
 cmdptr = its->cmdbuf + (its->creadr / sizeof(*its->cmdbuf));
 switch (its_cmd_get_command(cmdptr))
 {
+case GITS_CMD_CLEAR:
+its_handle_clear(its, cmdptr);
+break;
 case GITS_CMD_SYNC:
 /* We handle ITS commands synchronously, so we ignore SYNC. */
break;
-- 
2.9.0


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

[Xen-devel] [PATCH 23/28] ARM: vITS: handle DISCARD command

[Andre Przywara]

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 | 33 +
 1 file changed, 33 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index fb9caf0..8747890 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -346,6 +346,36 @@ 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(vcpu, vlpi, false);
+if ( pirq )
+{
+clear_bit(GIC_IRQ_GUEST_QUEUED, >status);
+gic_remove_from_queues(vcpu, vlpi);
+
+/* Mark this pending IRQ struct as availabe again. */
+if ( !test_bit(GIC_IRQ_GUEST_VISIBLE, >status) )
+pirq->irq = 0;
+}
+
+if ( !write_itte(its, devid, eventid, ~0, INVALID_LPI, NULL) )
+return -1;
+
+gicv3_assign_guest_event(its->d, devid, eventid, NULL, 0);
+
+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,
@@ -369,6 +399,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its,
 case GITS_CMD_CLEAR:
 its_handle_clear(its, cmdptr);
 break;
+case GITS_CMD_DISCARD:
+its_handle_discard(its, cmdptr);
+break;
 case GITS_CMD_INT:
 its_handle_int(its, cmdptr);
 break;
-- 
2.9.0


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

[Xen-devel] [PATCH 12/28] ARM: GICv3: enable ITS and LPIs on the host

[Andre Przywara]

Now that the host part of the ITS code is in place, we can enable the
ITS and also LPIs on each redistributor to get the show rolling.
At this point there would be no LPIs mapped, as guests don't know about
the ITS yet.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v3-its.c | 34 --
 xen/arch/arm/gic-v3.c | 19 +++
 2 files changed, 51 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index f073ab5..2a7093f 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -62,6 +62,28 @@ static int its_send_command(struct host_its *hw_its, const 
void *its_cmd)
 return 0;
 }
 
+/* Wait for an ITS to finish processing all commands. */
+static int gicv3_its_wait_commands(struct host_its *hw_its)
+{
+s_time_t deadline = NOW() + MILLISECS(1000);
+uint64_t readp, writep;
+
+do {
+spin_lock(_its->cmd_lock);
+readp = readq_relaxed(hw_its->its_base + GITS_CREADR) & BUFPTR_MASK;
+writep = readq_relaxed(hw_its->its_base + GITS_CWRITER) & BUFPTR_MASK;
+spin_unlock(_its->cmd_lock);
+
+if ( readp == writep )
+return 0;
+
+cpu_relax();
+udelay(1);
+} while ( NOW() <= deadline );
+
+return -ETIMEDOUT;
+}
+
 static uint64_t encode_rdbase(struct host_its *hw_its, int cpu, uint64_t reg)
 {
 reg &= ~GENMASK(51, 16);
@@ -161,6 +183,10 @@ int gicv3_its_setup_collection(int cpu)
 ret = its_send_cmd_sync(its, cpu);
 if ( ret )
 return ret;
+
+ret = gicv3_its_wait_commands(its);
+if ( ret )
+return ret;
 }
 
 return 0;
@@ -367,6 +393,10 @@ int gicv3_its_init(struct host_its *hw_its)
 return -ENOMEM;
 writeq_relaxed(0, hw_its->its_base + GITS_CWRITER);
 
+/* Now enable interrupt translation and command processing on that ITS. */
+reg = readl_relaxed(hw_its->its_base + GITS_CTLR);
+writel_relaxed(reg | GITS_CTLR_ENABLE, hw_its->its_base + GITS_CTLR);
+
 /*
  * We issue the collection mapping calls upon initialising the
  * redistributors, which for CPU 0 happens before the ITS gets initialised
@@ -381,7 +411,7 @@ int gicv3_its_init(struct host_its *hw_its)
 if ( ret )
 return ret;
 
-return 0;
+return gicv3_its_wait_commands(hw_its);
 }
 
 static void remove_mapped_guest_device(struct its_devices *dev)
@@ -424,7 +454,7 @@ int gicv3_its_map_host_events(struct host_its *its,
 if ( ret )
 return ret;
 
-return 0;
+return gicv3_its_wait_commands(its);
 }
 
 int gicv3_its_map_guest_device(struct domain *d, int host_devid,
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 5f825a6..23cf33d 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -647,6 +647,21 @@ static int gicv3_rdist_init_lpis(void __iomem * rdist_base)
 return gicv3_its_setup_collection(smp_processor_id());
 }
 
+/* Enable LPIs on this redistributor (only useful when the host has an ITS. */
+static bool gicv3_enable_lpis(void)
+{
+uint32_t val;
+
+val = readl_relaxed(GICD_RDIST_BASE + GICR_TYPER);
+if ( !(val & GICR_TYPER_PLPIS) )
+return false;
+
+val = readl_relaxed(GICD_RDIST_BASE + GICR_CTLR);
+writel_relaxed(val | GICR_CTLR_ENABLE_LPIS, GICD_RDIST_BASE + GICR_CTLR);
+
+return true;
+}
+
 static int __init gicv3_populate_rdist(void)
 {
 int i;
@@ -755,6 +770,10 @@ static int gicv3_cpu_init(void)
 if ( gicv3_enable_redist() )
 return -ENODEV;
 
+/* If the host has any ITSes, enable LPIs now. */
+if ( !list_empty(_its_list) )
+gicv3_enable_lpis();
+
 /* Set priority on PPI and SGI interrupts */
 priority = (GIC_PRI_IPI << 24 | GIC_PRI_IPI << 16 | GIC_PRI_IPI << 8 |
 GIC_PRI_IPI);
-- 
2.9.0


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

[Xen-devel] [PATCH 15/28] ARM: vGICv3: introduce basic ITS emulation bits

[Andre Przywara]

Create a new file to hold the emulation code for the ITS widget.
For now we emulate the memory mapped ITS registers and provide a stub
to introduce the ITS command handling framework (but without actually
emulating any commands at this time).

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/Makefile |   1 +
 xen/arch/arm/vgic-v3-its.c| 485 ++
 xen/arch/arm/vgic-v3.c|   9 -
 xen/include/asm-arm/gic_v3_defs.h |  19 ++
 4 files changed, 505 insertions(+), 9 deletions(-)
 create mode 100644 xen/arch/arm/vgic-v3-its.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 4ccf2eb..a1cbc27 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -46,6 +46,7 @@ obj-y += traps.o
 obj-y += vgic.o
 obj-y += vgic-v2.o
 obj-$(CONFIG_HAS_GICV3) += vgic-v3.o
+obj-$(CONFIG_HAS_ITS) += vgic-v3-its.o
 obj-y += vm_event.o
 obj-y += vtimer.o
 obj-y += vpsci.o
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
new file mode 100644
index 000..fc28376
--- /dev/null
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -0,0 +1,485 @@
+/*
+ * xen/arch/arm/vgic-v3-its.c
+ *
+ * ARM Interrupt Translation Service (ITS) emulation
+ *
+ * Andre Przywara 
+ * Copyright (c) 2016 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Data structure to describe a virtual ITS */
+struct virt_its {
+struct domain *d;
+spinlock_t vcmd_lock;   /* protects the virtual command buffer */
+uint64_t cbaser;
+uint64_t *cmdbuf;
+int cwriter;
+int creadr;
+spinlock_t its_lock;/* protects the collection and device tables */
+uint64_t baser0, baser1;
+uint16_t *coll_table;
+int max_collections;
+uint64_t *dev_table;
+int max_devices;
+bool enabled;
+};
+
+/*
+ * An Interrupt Translation Table Entry: this is indexed by a
+ * DeviceID/EventID pair and is located in guest memory.
+ */
+struct vits_itte
+{
+uint32_t vlpi;
+uint16_t collection;
+};
+
+/**
+ * Functions that handle ITS commands *
+ **/
+
+static uint64_t its_cmd_mask_field(uint64_t *its_cmd,
+   int word, int shift, int size)
+{
+return (le64_to_cpu(its_cmd[word]) >> shift) & (BIT(size) - 1);
+}
+
+#define its_cmd_get_command(cmd)its_cmd_mask_field(cmd, 0,  0,  8)
+#define its_cmd_get_deviceid(cmd)   its_cmd_mask_field(cmd, 0, 32, 32)
+#define its_cmd_get_size(cmd)   its_cmd_mask_field(cmd, 1,  0,  5)
+#define its_cmd_get_id(cmd) its_cmd_mask_field(cmd, 1,  0, 32)
+#define its_cmd_get_physical_id(cmd)its_cmd_mask_field(cmd, 1, 32, 32)
+#define its_cmd_get_collection(cmd) its_cmd_mask_field(cmd, 2,  0, 16)
+#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)
+
+#define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
+
+static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
+uint32_t writer)
+{
+uint64_t *cmdptr;
+
+if ( !its->cmdbuf )
+return -1;
+
+if ( writer >= ITS_CMD_BUFFER_SIZE(its->cbaser) )
+return -1;
+
+spin_lock(>vcmd_lock);
+
+while ( its->creadr != writer )
+{
+cmdptr = its->cmdbuf + (its->creadr / sizeof(*its->cmdbuf));
+switch (its_cmd_get_command(cmdptr))
+{
+case GITS_CMD_SYNC:
+/* We handle ITS commands synchronously, so we ignore SYNC. */
+   break;
+default:
+gdprintk(XENLOG_G_WARNING, "ITS: unhandled ITS command %ld\n",
+   its_cmd_get_command(cmdptr));
+break;
+}
+
+its->creadr += ITS_CMD_SIZE;
+if ( its->creadr == ITS_CMD_BUFFER_SIZE(its->cbaser) )
+its->creadr = 0;
+}
+its->cwriter = writer;
+
+spin_unlock(>vcmd_lock);
+
+return 0;
+}
+
+/*
+ * ITS registers read access *
+ */
+
+/*
+ * 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 

[Xen-devel] [PATCH 09/28] ARM: GICv3 ITS: map device and LPIs to the ITS on physdev_op hypercall

[Andre Przywara]

To get MSIs from devices forwarded to a CPU, we need to name the device
and its MSIs by mapping them to an ITS.
Since this involves queueing commands to the ITS command queue, we can't
really afford to do this during the guest's runtime, as this would open
up a denial-of-service attack vector.
So we require every device with MSI interrupts to be mapped explicitly by
Dom0. For Dom0 itself we can just use the existing PCI physdev_op
hypercalls, which the existing Linux kernel issues already.
So upon receipt of this hypercall we map the device to the hardware ITS
and prepare it to be later mapped by the virtual ITS by using the very
same device ID (for Dom0 only).
Also we ask for mapping 32 LPIs to cover 32 MSIs that the device may
use.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/physdev.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/xen/arch/arm/physdev.c b/xen/arch/arm/physdev.c
index 27bbbda..6e02de4 100644
--- a/xen/arch/arm/physdev.c
+++ b/xen/arch/arm/physdev.c
@@ -9,11 +9,32 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 
 int do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
+struct physdev_manage_pci manage;
+u32 devid;
+int ret;
+
+switch (cmd)
+{
+case PHYSDEVOP_manage_pci_add:
+case PHYSDEVOP_manage_pci_remove:
+if ( copy_from_guest(, arg, 1) != 0 )
+return -EFAULT;
+
+devid = manage.bus << 8 | manage.devfn;
+/* Allocate an ITS device table with space for 32 MSIs */
+ret = gicv3_its_map_guest_device(hardware_domain, devid, devid, 5,
+ cmd == PHYSDEVOP_manage_pci_add);
+
+return ret;
+}
+
 gdprintk(XENLOG_DEBUG, "PHYSDEVOP cmd=%d: not implemented\n", cmd);
 return -ENOSYS;
 }
-- 
2.9.0


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

[Xen-devel] [PATCH 27/28] ARM: vITS: create ITS subnodes for Dom0 DT

[Andre Przywara]

Dom0 expects all ITSes in the system to be propagated to be able to
use MSIs.
Create Dom0 DT nodes for each hardware ITS, keeping the register frame
address the same, as the doorbell address that the Dom0 drivers program
into the BARs has to match the hardware.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v3-its.c| 73 
 xen/arch/arm/gic-v3.c|  4 ++-
 xen/include/asm-arm/gic_v3_its.h | 13 +++
 3 files changed, 89 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index d37b7b6..36839c9 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -704,6 +704,79 @@ int gicv3_lpi_change_vcpu(struct domain *d,
 return 0;
 }
 
+/*
+ * Create the respective guest DT nodes for a list of host ITSes.
+ * This copies the reg property, so the guest sees the ITS at the same address
+ * as the host.
+ */
+int gicv3_its_make_dt_nodes(struct list_head *its_list,
+const struct domain *d,
+const struct dt_device_node *gic,
+void *fdt)
+{
+uint32_t len;
+int res;
+const void *prop = NULL;
+const struct dt_device_node *its = NULL;
+const struct host_its *its_data;
+
+if ( list_empty(its_list) )
+return 0;
+
+/* The sub-nodes require the ranges property */
+prop = dt_get_property(gic, "ranges", );
+if ( !prop )
+{
+printk(XENLOG_ERR "Can't find ranges property for the gic node\n");
+return -FDT_ERR_XEN(ENOENT);
+}
+
+res = fdt_property(fdt, "ranges", prop, len);
+if ( res )
+return res;
+
+list_for_each_entry(its_data, its_list, entry)
+{
+its = its_data->dt_node;
+
+res = fdt_begin_node(fdt, its->name);
+if ( res )
+return res;
+
+res = fdt_property_string(fdt, "compatible", "arm,gic-v3-its");
+if ( res )
+return res;
+
+res = fdt_property(fdt, "msi-controller", NULL, 0);
+if ( res )
+return res;
+
+if ( its->phandle )
+{
+res = fdt_property_cell(fdt, "phandle", its->phandle);
+if ( res )
+return res;
+}
+
+/* Use the same reg regions as the ITS node in host DTB. */
+prop = dt_get_property(its, "reg", );
+if ( !prop )
+{
+printk(XENLOG_ERR "GICv3: Can't find ITS reg property.\n");
+res = -FDT_ERR_XEN(ENOENT);
+return res;
+}
+
+res = fdt_property(fdt, "reg", prop, len);
+if ( res )
+return res;
+
+fdt_end_node(fdt);
+}
+
+return res;
+}
+
 /* 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.c b/xen/arch/arm/gic-v3.c
index 23cf33d..7041d48 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1190,8 +1190,10 @@ static int gicv3_make_hwdom_dt_node(const struct domain 
*d,
 
 res = fdt_property(fdt, "reg", new_cells, len);
 xfree(new_cells);
+if ( res )
+return res;
 
-return res;
+return gicv3_its_make_dt_nodes(_its_list, d, gic, fdt);
 }
 
 static const hw_irq_controller gicv3_host_irq_type = {
diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
index e75249b..4f5a453 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -152,6 +152,12 @@ int gicv3_its_setup_collection(int cpu);
  */
 int vgic_v3_its_init_virtual(struct domain *d, paddr_t guest_addr);
 
+/* Given a list of ITSes, create the appropriate DT nodes for a domain. */
+int gicv3_its_make_dt_nodes(struct list_head *its_list,
+const struct domain *d,
+const struct dt_device_node *gic,
+void *fdt);
+
 /* Map a device on the host by allocating an ITT on the host (ITS).
  * "bits" specifies how many events (interrupts) this device will need.
  * Setting "valid" to false deallocates the device.
@@ -212,6 +218,13 @@ static inline int vgic_v3_its_init_virtual(struct domain 
*d, paddr_t guest_addr)
 {
 return 0;
 }
+static inline int gicv3_its_make_dt_nodes(struct list_head *its_list,
+   const struct domain *d,
+   const struct dt_device_node *gic,
+   void *fdt)
+{
+return 0;
+}
 
 #endif /* CONFIG_HAS_ITS */
 
-- 
2.9.0


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

[Xen-devel] [PATCH 14/28] ARM: vGICv3: Handle disabled LPIs

[Andre Przywara]

If a guest disables an LPI, we do not forward this to the associated
host LPI to avoid queueing commands to the host ITS command queue.
So it may happen that an LPI fires nevertheless on the host. In this
case we can bail out early, but have to save the pending state on the
virtual side.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v3-lpi.c  |  8 
 xen/arch/arm/vgic-v3.c | 12 
 xen/include/asm-arm/vgic.h |  6 ++
 3 files changed, 26 insertions(+)

diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index d270053..ade8b69 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -124,6 +124,14 @@ void do_LPI(unsigned int lpi)
 
 put_domain(d);
 
+/*
+ * We keep all host LPIs enabled, so check if it's disabled on the guest
+ * side and just record this LPI in the virtual pending table in this case.
+ * The guest picks it up once it gets enabled again.
+ */
+if ( !vgic_can_inject_lpi(vcpu, hlpi.virt_lpi) )
+return;
+
 vgic_vcpu_inject_irq(vcpu, hlpi.virt_lpi);
 }
 
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index c6db2d7..de625bf 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -498,6 +498,18 @@ bool vgic_lpi_is_enabled(struct domain *d, uint32_t vlpi)
 return d->arch.vgic.proptable[vlpi - LPI_OFFSET] & LPI_PROP_ENABLED;
 }
 
+bool vgic_can_inject_lpi(struct vcpu *vcpu, uint32_t vlpi)
+{
+if ( vlpi >= vcpu->domain->arch.vgic.nr_lpis )
+return false;
+
+if ( vgic_lpi_is_enabled(vcpu->domain, vlpi) )
+return true;
+
+set_bit(vlpi - LPI_OFFSET, vcpu->arch.vgic.pendtable);
+return false;
+}
+
 static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu *v, mmio_info_t *info,
   uint32_t gicr_reg,
   register_t r)
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index a882fe8..e71b18b 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -323,6 +323,7 @@ int vgic_v3_init(struct domain *d, int *mmio_count);
 #ifdef CONFIG_HAS_GICV3
 extern int vgic_lpi_get_priority(struct domain *d, uint32_t vlpi);
 extern bool vgic_lpi_is_enabled(struct domain *d, uint32_t vlpi);
+extern bool vgic_can_inject_lpi(struct vcpu *v, uint32_t vlpi);
 #else
 static inline int vgic_lpi_get_priority(struct domain *d, uint32_t vlpi)
 {
@@ -333,6 +334,11 @@ static inline bool vgic_lpi_is_enabled(struct domain *d, 
uint32_t vlpi)
 {
 return false;
 }
+
+static inline bool vgic_can_inject_lpi(struct vcpu *v, uint32_t vlpi)
+{
+return false;
+}
 #endif
 
 extern int domain_vgic_register(struct domain *d, int *mmio_count);
-- 
2.9.0


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

[Xen-devel] [PATCH 21/28] ARM: vITS: handle MAPTI command

[Andre Przywara]

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.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v3-its.c| 58 
 xen/arch/arm/gic-v3-lpi.c| 18 +
 xen/arch/arm/vgic-v3-its.c   | 27 +--
 xen/include/asm-arm/gic_v3_its.h |  5 
 4 files changed, 106 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 2a7093f..1268d64 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -632,6 +632,64 @@ int gicv3_its_unmap_device(struct domain *d, int 
guest_devid)
 return -ENOENT;
 }
 
+/*
+ * Translates an event for a given guest device ID into the associated host
+ * LPI number. This can be used to look up the mapped guest LPI.
+ */
+static uint32_t translate_event(struct domain *d,
+uint32_t devid, uint32_t eventid)
+{
+struct rb_node *node;
+struct its_devices *dev;
+uint32_t host_lpi = 0;
+
+spin_lock(>arch.vgic.its_devices_lock);
+node = d->arch.vgic.its_devices.rb_node;
+while (node)
+{
+dev = rb_entry(node, struct its_devices, rbnode);
+if ( dev->guest_devid == devid )
+{
+if ( eventid >= dev->eventids )
+goto out;
+
+host_lpi = dev->host_lpis[eventid / 32] + (eventid % 32);
+if ( !is_lpi(host_lpi) )
+host_lpi = 0;
+goto out;
+}
+
+if ( devid < dev->guest_devid )
+node = node->rb_left;
+else
+node = node->rb_right;
+}
+
+out:
+spin_unlock(>arch.vgic.its_devices_lock);
+
+return host_lpi;
+}
+
+/*
+ * 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.
+ */
+int gicv3_assign_guest_event(struct domain *d, uint32_t devid, uint32_t 
eventid,
+ struct vcpu *v, uint32_t virt_lpi)
+{
+uint32_t host_lpi = translate_event(d, devid, eventid);
+
+if ( !host_lpi )
+return -ENOENT;
+
+gicv3_lpi_update_host_entry(host_lpi, d->domain_id, v->vcpu_id, virt_lpi);
+
+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 ade8b69..494ae22 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -135,6 +135,24 @@ void do_LPI(unsigned int lpi)
 vgic_vcpu_inject_irq(vcpu, hlpi.virt_lpi);
 }
 
+int gicv3_lpi_update_host_entry(uint32_t host_lpi, int domain_id, int vcpu_id,
+uint32_t virt_lpi)
+{
+union host_lpi *hlpip, hlpi;
+
+host_lpi -= LPI_OFFSET;
+
+hlpip = _data.host_lpis[host_lpi / HOST_LPIS_PER_PAGE][host_lpi % 
HOST_LPIS_PER_PAGE];
+
+hlpi.virt_lpi = virt_lpi;
+hlpi.dom_id = domain_id;
+hlpi.vcpu_id = vcpu_id;
+
+write_u64_atomic(>data, hlpi.data);
+
+return 0;
+}
+
 uint64_t gicv3_lpi_allocate_pendtable(void)
 {
 uint64_t reg;
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 5be40d8..3e74f46 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -164,8 +164,8 @@ static bool read_itte(struct virt_its *its, uint32_t devid, 
uint32_t evid,
 }
 
 #define SKIP_LPI_UPDATE 1
-bool write_itte(struct virt_its *its, uint32_t devid, uint32_t evid,
-uint32_t collid, uint32_t vlpi, struct vcpu **vcpu)
+static bool write_itte(struct virt_its *its, uint32_t devid, uint32_t evid,
+   uint32_t collid, uint32_t vlpi, struct vcpu **vcpu)
 {
 struct vits_itte *itte;
 
@@ -310,6 +310,25 @@ static int its_handle_mapd(struct virt_its *its, uint64_t 
*cmdptr)
 return 0;
 }
 
+static int its_handle_mapti(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+uint32_t intid = its_cmd_get_physical_id(cmdptr);
+int collid = its_cmd_get_collection(cmdptr);
+struct vcpu *vcpu;
+
+if ( its_cmd_get_command(cmdptr) == GITS_CMD_MAPI )
+intid = eventid;
+
+if ( !write_itte(its, devid, eventid, collid, intid, ) )
+return -1;
+
+gicv3_assign_guest_event(its->d, devid, eventid, vcpu, intid);
+
+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,
@@ -342,6 +361,10 

[Xen-devel] [PATCH 16/28] ARM: vITS: introduce translation table walks

[Andre Przywara]

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.
Since the final interrupt translation tables can be smaller than a page,
we map them 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.

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

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index fc28376..982c51d 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -60,6 +60,141 @@ struct vits_itte
 uint16_t collection;
 };
 
+#define UNMAPPED_COLLECTION  ((uint16_t)~0)
+
+/* Must be called with the ITS lock held. */
+static struct vcpu *get_vcpu_from_collection(struct virt_its *its, int collid)
+{
+uint16_t vcpu_id;
+
+if ( collid >= its->max_collections )
+return NULL;
+
+vcpu_id = its->coll_table[collid];
+if ( vcpu_id == UNMAPPED_COLLECTION || vcpu_id >= its->d->max_vcpus )
+return NULL;
+
+return its->d->vcpu[vcpu_id];
+}
+
+#define DEV_TABLE_ITT_ADDR(x) ((x) & GENMASK(51, 8))
+#define DEV_TABLE_ITT_SIZE(x) (BIT(((x) & GENMASK(7, 0)) + 1))
+#define DEV_TABLE_ENTRY(addr, bits) \
+(((addr) & GENMASK(51, 8)) | (((bits) - 1) & GENMASK(7, 0)))
+
+static paddr_t get_itte_address(struct virt_its *its,
+uint32_t devid, uint32_t evid)
+{
+paddr_t addr;
+
+if ( devid >= its->max_devices )
+return ~0;
+
+if ( evid >= DEV_TABLE_ITT_SIZE(its->dev_table[devid]) )
+return ~0;
+
+addr = DEV_TABLE_ITT_ADDR(its->dev_table[devid]);
+
+return addr + evid * sizeof(struct vits_itte);
+}
+
+/*
+ * 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_devid_evid() to unmap
+ * the page again.
+ * Must be called with the ITS lock held.
+ */
+static struct vits_itte *get_devid_evid(struct virt_its *its,
+uint32_t devid, uint32_t evid)
+{
+paddr_t addr = get_itte_address(its, devid, evid);
+
+if ( addr == ~0 )
+return NULL;
+
+return map_guest_pages(its->d, addr, 1);
+}
+
+/* Must be called with the ITS lock held. */
+static void put_devid_evid(struct virt_its *its, struct vits_itte *itte)
+{
+unmap_guest_pages(itte, 1);
+}
+
+/*
+ * 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.
+ * Takes and drops the its_lock.
+ */
+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);
+itte = get_devid_evid(its, devid, evid);
+if ( !itte )
+{
+spin_unlock(>its_lock);
+return false;
+}
+collid = itte->collection;
+_vlpi = itte->vlpi;
+put_devid_evid(its, itte);
+
+_vcpu = get_vcpu_from_collection(its, collid);
+spin_unlock(>its_lock);
+
+if ( !_vcpu )
+return false;
+
+if ( collid >= its->max_collections )
+return false;
+
+*vcpu = _vcpu;
+*vlpi = _vlpi;
+
+return true;
+}
+
+#define SKIP_LPI_UPDATE 1
+bool write_itte(struct virt_its *its, uint32_t devid, uint32_t evid,
+uint32_t collid, uint32_t vlpi, struct vcpu **vcpu)
+{
+struct vits_itte *itte;
+
+if ( collid >= its->max_collections )
+return false;
+
+/* TODO: validate vlpi */
+
+spin_lock(>its_lock);
+itte = get_devid_evid(its, devid, evid);
+if ( !itte )
+{
+spin_unlock(>its_lock);
+return false;
+}
+
+itte->collection = collid;
+if ( vlpi != SKIP_LPI_UPDATE )
+itte->vlpi = vlpi;
+
+if ( vcpu )
+*vcpu = get_vcpu_from_collection(its, collid);
+
+put_devid_evid(its, itte);
+spin_unlock(>its_lock);
+
+return true;
+}
+
 /**
  * Functions that handle ITS commands *
  **/
-- 
2.9.0


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

[Xen-devel] [PATCH 19/28] ARM: vITS: handle MAPC command

[Andre Przywara]

The MAPC command associates a given collection ID with a given
redistributor, thus mapping collections to VCPUs.
We just store the vcpu_id in the collection table for that.

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 9307235..e6523a3 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -262,6 +262,33 @@ static int its_handle_int(struct virt_its *its, uint64_t 
*cmdptr)
 return 0;
 }
 
+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);
+int ret = -1;
+
+if ( collid >= its->max_collections )
+return ret;
+
+if ( rdbase >= its->d->max_vcpus )
+return ret;
+
+spin_lock(>its_lock);
+if ( its->coll_table )
+{
+if ( its_cmd_get_validbit(cmdptr) )
+its->coll_table[collid] = rdbase;
+else
+its->coll_table[collid] = UNMAPPED_COLLECTION;
+
+ret = 0;
+}
+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,
@@ -288,6 +315,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its,
 case GITS_CMD_INT:
 its_handle_int(its, cmdptr);
 break;
+case GITS_CMD_MAPC:
+its_handle_mapc(its, cmdptr);
+break;
 case GITS_CMD_SYNC:
 /* We handle ITS commands synchronously, so we ignore SYNC. */
break;
-- 
2.9.0


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

[Xen-devel] [PATCH 20/28] ARM: vITS: handle MAPD command

[Andre Przywara]

The MAPD command maps a device by associating a memory region for
storing ITTEs with a certain device ID.
We just store the given guest physical address in the device table.
We don't map the device tables permanently, as their alignment
requirement is only 256 Bytes, thus making mapping of several tables
complicated. We map the device tables on demand when we need them later.

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

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index e6523a3..5be40d8 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -289,6 +289,27 @@ static int its_handle_mapc(struct virt_its *its, uint64_t 
*cmdptr)
 return ret;
 }
 
+static int its_handle_mapd(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+int size = its_cmd_get_size(cmdptr);
+bool valid = its_cmd_get_validbit(cmdptr);
+paddr_t itt_addr = its_cmd_mask_field(cmdptr, 2, 0, 52) & GENMASK(51, 8);
+
+if ( !its->dev_table )
+return -1;
+
+spin_lock(>its_lock);
+if ( valid )
+its->dev_table[devid] = DEV_TABLE_ENTRY(itt_addr, size + 1);
+else
+its->dev_table[devid] = 0;
+
+spin_unlock(>its_lock);
+
+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,
@@ -318,6 +339,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its,
 case GITS_CMD_MAPC:
 its_handle_mapc(its, cmdptr);
 break;
+case GITS_CMD_MAPD:
+its_handle_mapd(its, cmdptr);
+   break;
 case GITS_CMD_SYNC:
 /* We handle ITS commands synchronously, so we ignore SYNC. */
break;
-- 
2.9.0


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

[Xen-devel] [PATCH 08/28] ARM: GICv3 ITS: introduce host LPI array

[Andre Przywara]

The number of LPIs on a host can be potentially huge (millions),
although in practise will be mostly reasonable. So prematurely allocating
an array of struct irq_desc's for each LPI is not an option.
However Xen itself does not care about LPIs, as every LPI will be injected
into a guest (Dom0 for now).
Create a dense data structure (8 Bytes) for each LPI which holds just
enough information to determine the virtual IRQ number and the VCPU into
which the LPI needs to be injected.
Also to not artificially limit the number of LPIs, we create a 2-level
table for holding those structures.
This patch introduces functions to initialize these tables and to
create, lookup and destroy entries for a given LPI.
We allocate and access LPI information in a way that does not require
a lock.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v3-its.c|  80 -
 xen/arch/arm/gic-v3-lpi.c| 187 ++-
 xen/include/asm-arm/atomic.h |   6 +-
 xen/include/asm-arm/gic.h|   5 ++
 xen/include/asm-arm/gic_v3_its.h |   9 ++
 5 files changed, 282 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 4a3a394..f073ab5 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -83,6 +83,20 @@ static int its_send_cmd_sync(struct host_its *its, int cpu)
 return its_send_command(its, cmd);
 }
 
+static int its_send_cmd_mapti(struct host_its *its,
+  uint32_t deviceid, uint32_t eventid,
+  uint32_t pintid, uint16_t icid)
+{
+uint64_t cmd[4];
+
+cmd[0] = GITS_CMD_MAPTI | ((uint64_t)deviceid << 32);
+cmd[1] = eventid | ((uint64_t)pintid << 32);
+cmd[2] = icid;
+cmd[3] = 0x00;
+
+return its_send_command(its, cmd);
+}
+
 static int its_send_cmd_mapc(struct host_its *its, int collection_id, int cpu)
 {
 uint64_t cmd[4];
@@ -111,6 +125,19 @@ static int its_send_cmd_mapd(struct host_its *its, 
uint32_t deviceid,
 return its_send_command(its, cmd);
 }
 
+static int its_send_cmd_inv(struct host_its *its,
+uint32_t deviceid, uint32_t eventid)
+{
+uint64_t cmd[4];
+
+cmd[0] = GITS_CMD_INV | ((uint64_t)deviceid << 32);
+cmd[1] = eventid;
+cmd[2] = 0x00;
+cmd[3] = 0x00;
+
+return its_send_command(its, cmd);
+}
+
 /* Set up the (1:1) collection mapping for the given host CPU. */
 int gicv3_its_setup_collection(int cpu)
 {
@@ -359,13 +386,47 @@ int gicv3_its_init(struct host_its *hw_its)
 
 static void remove_mapped_guest_device(struct its_devices *dev)
 {
+int i;
+
 if ( dev->hw_its )
 its_send_cmd_mapd(dev->hw_its, dev->host_devid, 0, 0, false);
 
+for ( i = 0; i < dev->eventids / 32; i++ )
+gicv3_free_host_lpi_block(dev->hw_its, dev->host_lpis[i]);
+
 xfree(dev->itt_addr);
+xfree(dev->host_lpis);
 xfree(dev);
 }
 
+/*
+ * On the host ITS @its, map @nr_events consecutive LPIs.
+ * The mapping connects a device @devid and event @eventid pair to LPI @lpi,
+ * increasing both @eventid and @lpi to cover the number of requested LPIs.
+ */
+int gicv3_its_map_host_events(struct host_its *its,
+  int devid, int eventid, int lpi,
+  int nr_events)
+{
+int i, ret;
+
+for ( i = 0; i < nr_events; i++ )
+{
+ret = its_send_cmd_mapti(its, devid, eventid + i, lpi + i, 0);
+if ( ret )
+return ret;
+ret = its_send_cmd_inv(its, devid, eventid + i);
+if ( ret )
+return ret;
+}
+
+ret = its_send_cmd_sync(its, 0);
+if ( ret )
+return ret;
+
+return 0;
+}
+
 int gicv3_its_map_guest_device(struct domain *d, int host_devid,
int guest_devid, int bits, bool valid)
 {
@@ -373,7 +434,7 @@ int gicv3_its_map_guest_device(struct domain *d, int 
host_devid,
 struct its_devices *dev, *temp;
 struct rb_node **new = >arch.vgic.its_devices.rb_node, *parent = NULL;
 struct host_its *hw_its;
-int ret;
+int ret, i;
 
 /* check for already existing mappings */
 spin_lock(>arch.vgic.its_devices_lock);
@@ -430,10 +491,19 @@ int gicv3_its_map_guest_device(struct domain *d, int 
host_devid,
 goto out_unlock;
 }
 
+dev->host_lpis = xzalloc_array(uint32_t, BIT(bits) / 32);
+if ( !dev->host_lpis )
+{
+xfree(dev);
+xfree(itt_addr);
+return -ENOMEM;
+}
+
 ret = its_send_cmd_mapd(hw_its, host_devid, bits - 1,
 virt_to_maddr(itt_addr), true);
 if ( ret )
 {
+xfree(dev->host_lpis);
 xfree(itt_addr);
 xfree(dev);
 goto out_unlock;
@@ -450,6 +520,14 @@ int gicv3_its_map_guest_device(struct domain *d, int 
host_devid,
 
 spin_unlock(>arch.vgic.its_devices_lock);
 
+/*
+ * Map all host LPIs within this device already. We can't 

[Xen-devel] [PATCH 07/28] ARM: GICv3 ITS: introduce device mapping

[Andre Przywara]

The ITS uses device IDs to map LPIs to a device. Dom0 will later use
those IDs, which we directly pass on to the host.
For this we have to map each device that Dom0 may request to a host
ITS device with the same identifier.
Allocate the respective memory and enter each device into an rbtree to
later be able to iterate over it or to easily teardown guests.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v3-its.c| 188 ++-
 xen/arch/arm/vgic-v3.c   |   3 +
 xen/include/asm-arm/domain.h |   3 +
 xen/include/asm-arm/gic_v3_its.h |  28 ++
 4 files changed, 221 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 6578e8a..4a3a394 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -21,8 +21,10 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -94,6 +96,21 @@ static int its_send_cmd_mapc(struct host_its *its, int 
collection_id, int cpu)
 return its_send_command(its, cmd);
 }
 
+static int its_send_cmd_mapd(struct host_its *its, uint32_t deviceid,
+ int size, uint64_t itt_addr, bool valid)
+{
+uint64_t cmd[4];
+
+cmd[0] = GITS_CMD_MAPD | ((uint64_t)deviceid << 32);
+cmd[1] = size & GENMASK(4, 0);
+cmd[2] = itt_addr & GENMASK(51, 8);
+if ( valid )
+cmd[2] |= GITS_VALID_BIT;
+cmd[3] = 0x00;
+
+return its_send_command(its, cmd);
+}
+
 /* Set up the (1:1) collection mapping for the given host CPU. */
 int gicv3_its_setup_collection(int cpu)
 {
@@ -293,6 +310,7 @@ int gicv3_its_init(struct host_its *hw_its)
 reg = readq_relaxed(hw_its->its_base + GITS_TYPER);
 if ( reg & GITS_TYPER_PTA )
 hw_its->flags |= HOST_ITS_USES_PTA;
+hw_its->itte_size = GITS_TYPER_ITT_SIZE(reg);
 
 for ( i = 0; i < GITS_BASER_NR_REGS; i++ )
 {
@@ -339,6 +357,173 @@ int gicv3_its_init(struct host_its *hw_its)
 return 0;
 }
 
+static void remove_mapped_guest_device(struct its_devices *dev)
+{
+if ( dev->hw_its )
+its_send_cmd_mapd(dev->hw_its, dev->host_devid, 0, 0, false);
+
+xfree(dev->itt_addr);
+xfree(dev);
+}
+
+int gicv3_its_map_guest_device(struct domain *d, int host_devid,
+   int guest_devid, int bits, bool valid)
+{
+void *itt_addr = NULL;
+struct its_devices *dev, *temp;
+struct rb_node **new = >arch.vgic.its_devices.rb_node, *parent = NULL;
+struct host_its *hw_its;
+int ret;
+
+/* check for already existing mappings */
+spin_lock(>arch.vgic.its_devices_lock);
+while (*new)
+{
+temp = rb_entry(*new, struct its_devices, rbnode);
+
+if ( temp->guest_devid == guest_devid )
+{
+if ( !valid )
+rb_erase(>rbnode, >arch.vgic.its_devices);
+
+spin_unlock(>arch.vgic.its_devices_lock);
+
+if ( valid )
+return -EBUSY;
+
+remove_mapped_guest_device(temp);
+
+return 0;
+}
+
+if ( guest_devid < temp->guest_devid )
+new = &((*new)->rb_right);
+else
+new = &((*new)->rb_left);
+}
+
+if ( !valid )
+{
+ret = -ENOENT;
+goto out_unlock;
+}
+
+/*
+ * TODO: Work out the correct hardware ITS to use here.
+ * Maybe a per-platform function: devid -> ITS?
+ * Or parsing the DT to find the msi_parent?
+ * Or get Dom0 to give us this information?
+ * For now just use the first ITS.
+ */
+hw_its = list_first_entry(_its_list, struct host_its, entry);
+
+ret = -ENOMEM;
+
+itt_addr = _xmalloc(BIT(bits) * hw_its->itte_size, 256);
+if ( !itt_addr )
+goto out_unlock;
+
+dev = xmalloc(struct its_devices);
+if ( !dev )
+{
+xfree(itt_addr);
+goto out_unlock;
+}
+
+ret = its_send_cmd_mapd(hw_its, host_devid, bits - 1,
+virt_to_maddr(itt_addr), true);
+if ( ret )
+{
+xfree(itt_addr);
+xfree(dev);
+goto out_unlock;
+}
+
+dev->itt_addr = itt_addr;
+dev->hw_its = hw_its;
+dev->guest_devid = guest_devid;
+dev->host_devid = host_devid;
+dev->eventids = BIT(bits);
+
+rb_link_node(>rbnode, parent, new);
+rb_insert_color(>rbnode, >arch.vgic.its_devices);
+
+spin_unlock(>arch.vgic.its_devices_lock);
+
+return 0;
+
+out_unlock:
+spin_unlock(>arch.vgic.its_devices_lock);
+return ret;
+}
+
+/* Removing any connections a domain had to any ITS in the system. */
+void gicv3_its_unmap_all_devices(struct domain *d)
+{
+struct rb_node *victim;
+struct its_devices *dev;
+
+/*
+ * This is an easily readable, yet inefficient implementation.
+ * It uses the provided iteration wrapper and erases each node, which
+ * possibly triggers rebalancing.
+ * This seems overkill 

[Xen-devel] [PATCH 06/28] ARM: GICv3 ITS: introduce ITS command handling

[Andre Przywara]

To be able to easily send commands to the ITS, create the respective
wrapper functions, which take care of the ring buffer.
The first two commands we implement provide methods to map a collection
to a redistributor (aka host core) and to flush the command queue (SYNC).
Start using these commands for mapping one collection to each host CPU.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v3-its.c | 142 +-
 xen/arch/arm/gic-v3-lpi.c |  20 ++
 xen/arch/arm/gic-v3.c |  18 -
 xen/include/asm-arm/gic_v3_defs.h |   2 +
 xen/include/asm-arm/gic_v3_its.h  |  36 ++
 5 files changed, 215 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index ad7cd2a..6578e8a 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -29,6 +30,98 @@
 
 #define ITS_CMD_QUEUE_SZSZ_64K
 
+#define BUFPTR_MASK GENMASK(19, 5)
+static int its_send_command(struct host_its *hw_its, const void *its_cmd)
+{
+uint64_t readp, writep;
+
+spin_lock(_its->cmd_lock);
+
+readp = readq_relaxed(hw_its->its_base + GITS_CREADR) & BUFPTR_MASK;
+writep = readq_relaxed(hw_its->its_base + GITS_CWRITER) & BUFPTR_MASK;
+
+if ( ((writep + ITS_CMD_SIZE) % ITS_CMD_QUEUE_SZ) == readp )
+{
+spin_unlock(_its->cmd_lock);
+return -EBUSY;
+}
+
+memcpy(hw_its->cmd_buf + writep, its_cmd, ITS_CMD_SIZE);
+if ( hw_its->flags & HOST_ITS_FLUSH_CMD_QUEUE )
+__flush_dcache_area(hw_its->cmd_buf + writep, ITS_CMD_SIZE);
+else
+dsb(ishst);
+
+writep = (writep + ITS_CMD_SIZE) % ITS_CMD_QUEUE_SZ;
+writeq_relaxed(writep & BUFPTR_MASK, hw_its->its_base + GITS_CWRITER);
+
+spin_unlock(_its->cmd_lock);
+
+return 0;
+}
+
+static uint64_t encode_rdbase(struct host_its *hw_its, int cpu, uint64_t reg)
+{
+reg &= ~GENMASK(51, 16);
+
+reg |= gicv3_get_redist_address(cpu, hw_its->flags & HOST_ITS_USES_PTA);
+
+return reg;
+}
+
+static int its_send_cmd_sync(struct host_its *its, int cpu)
+{
+uint64_t cmd[4];
+
+cmd[0] = GITS_CMD_SYNC;
+cmd[1] = 0x00;
+cmd[2] = encode_rdbase(its, cpu, 0x0);
+cmd[3] = 0x00;
+
+return its_send_command(its, cmd);
+}
+
+static int its_send_cmd_mapc(struct host_its *its, int collection_id, int cpu)
+{
+uint64_t cmd[4];
+
+cmd[0] = GITS_CMD_MAPC;
+cmd[1] = 0x00;
+cmd[2] = encode_rdbase(its, cpu, (collection_id & GENMASK(15, 0)));
+cmd[2] |= GITS_VALID_BIT;
+cmd[3] = 0x00;
+
+return its_send_command(its, cmd);
+}
+
+/* Set up the (1:1) collection mapping for the given host CPU. */
+int gicv3_its_setup_collection(int cpu)
+{
+struct host_its *its;
+int ret;
+
+list_for_each_entry(its, _its_list, entry)
+{
+/*
+ * This function is called on CPU0 before any ITSes have been
+ * properly initialized. Skip the collection setup in this case,
+ * it will be done explicitly for CPU0 upon initializing the ITS.
+ */
+if ( !its->cmd_buf )
+continue;
+
+ret = its_send_cmd_mapc(its, cpu, cpu);
+if ( ret )
+return ret;
+
+ret = its_send_cmd_sync(its, cpu);
+if ( ret )
+return ret;
+}
+
+return 0;
+}
+
 #define BASER_ATTR_MASK   \
 ((0x3UL << GITS_BASER_SHAREABILITY_SHIFT)   | \
  (0x7UL << GITS_BASER_OUTER_CACHEABILITY_SHIFT) | \
@@ -156,18 +249,51 @@ static int its_map_baser(void __iomem *basereg, uint64_t 
regc, int nr_items)
 return -EINVAL;
 }
 
+/* Wait for an ITS to become quiescient (all ITS operations completed). */
+static int gicv3_its_wait_quiescient(struct host_its *hw_its)
+{
+uint32_t reg;
+s_time_t deadline = NOW() + MILLISECS(1000);
+
+reg = readl_relaxed(hw_its->its_base + GITS_CTLR);
+if ( (reg & (GITS_CTLR_QUIESCENT | GITS_CTLR_ENABLE)) == 
GITS_CTLR_QUIESCENT )
+return 0;
+
+writel_relaxed(reg & ~GITS_CTLR_ENABLE, hw_its->its_base + GITS_CTLR);
+
+do {
+reg = readl_relaxed(hw_its->its_base + GITS_CTLR);
+if ( reg & GITS_CTLR_QUIESCENT )
+return 0;
+
+cpu_relax();
+udelay(1);
+} while ( NOW() <= deadline );
+
+dprintk(XENLOG_ERR, "ITS not quiescient\n");
+return -ETIMEDOUT;
+}
+
 static unsigned int max_its_device_bits = CONFIG_MAX_PHYS_ITS_DEVICE_BITS;
 integer_param("max_its_device_bits", max_its_device_bits);
 
 int gicv3_its_init(struct host_its *hw_its)
 {
 uint64_t reg;
-int i;
+int i, ret;
 
 hw_its->its_base = ioremap_nocache(hw_its->addr, hw_its->size);
 if ( !hw_its->its_base )
 return -ENOMEM;
 
+ret = gicv3_its_wait_quiescient(hw_its);
+if ( ret )
+return ret;

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

[Andre Przywara]

Each ITS maps a pair of a DeviceID (usually the 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 the ITS.
The maximum number of devices is limited to a compile-time constant
exposed in Kconfig.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/Kconfig |  14 +
 xen/arch/arm/gic-v3-its.c| 129 +++
 xen/arch/arm/gic-v3.c|   5 ++
 xen/include/asm-arm/gic_v3_its.h |  55 -
 4 files changed, 202 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 71734a1..81bc233 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -64,6 +64,20 @@ config MAX_PHYS_LPI_BITS
   This can be overriden on the command line with the max_lpi_bits
   parameter.
 
+config MAX_PHYS_ITS_DEVICE_BITS
+depends on HAS_ITS
+int "Number of device bits the ITS supports"
+range 1 32
+default "10"
+help
+  Specifies the maximum number of devices which want to use the ITS.
+  Xen needs to allocates memory for the whole range very early.
+  The allocation scheme may be sparse, so a much larger number must
+  be supported to cover devices with a high bus number or those on
+  separate bus segments.
+  This can be overriden on the command line with the 
max_its_device_bits
+  parameter.
+
 endmenu
 
 menu "ARM errata workaround via the alternative framework"
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index ff0f571..c31fef6 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -20,9 +20,138 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
+#include 
+
+#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(58, 56) | GENMASK(52, 48))
+
+static uint64_t encode_phys_addr(paddr_t addr, int page_bits)
+{
+uint64_t ret;
+
+if ( page_bits < 16 )
+return (uint64_t)addr & GENMASK(47, page_bits);
+
+ret = addr & GENMASK(47, 16);
+return ret | (addr & GENMASK(51, 48)) >> (48 - 12);
+}
+
+#define PAGE_BITS(sz) ((sz) * 2 + PAGE_SHIFT)
+
+static int its_map_baser(void __iomem *basereg, uint64_t regc, int nr_items)
+{
+uint64_t attr, reg;
+int entry_size = ((regc >> GITS_BASER_ENTRY_SIZE_SHIFT) & 0x1f) + 1;
+int pagesz = 0, order, table_size;
+void *buffer = NULL;
+
+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.
+ */
+while ( 1 )
+{
+table_size = ROUNDUP(nr_items * entry_size, BIT(PAGE_BITS(pagesz)));
+order = get_order_from_bytes(table_size);
+
+if ( !buffer )
+buffer = alloc_xenheap_pages(order, 0);
+if ( !buffer )
+return -ENOMEM;
+
+reg  = attr;
+reg |= (pagesz << GITS_BASER_PAGE_SIZE_SHIFT);
+reg |= table_size >> PAGE_BITS(pagesz);
+reg |= regc & BASER_RO_MASK;
+reg |= GITS_VALID_BIT;
+reg |= encode_phys_addr(virt_to_maddr(buffer), PAGE_BITS(pagesz));
+
+writeq_relaxed(reg, basereg);
+regc = readl_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;
+attr = regc & BASER_ATTR_MASK;
+continue;
+}
+attr = regc & BASER_ATTR_MASK;
+}
+
+/* If the host accepted our page size, we are done. */
+if ( (regc & (3UL << GITS_BASER_PAGE_SIZE_SHIFT)) == pagesz )
+return 0;
+
+/* None of the page sizes was accepted, give up */
+if ( pagesz >= 2 )
+break;
+
+free_xenheap_pages(buffer, order);
+buffer = NULL;
+
+pagesz++;
+}
+
+if ( buffer )
+free_xenheap_pages(buffer, order);
+
+return -EINVAL;
+}
+

[Xen-devel] [PATCH 03/28] ARM: GICv3: allocate LPI pending and property table

[Andre Przywara]

The ARM GICv3 provides a new kind of interrupt called LPIs.
The pending bits and the configuration data (priority, enable bits) for
those LPIs are stored in tables in normal memory, which software has to
provide to the hardware.
Allocate the required memory, initialize it and hand it over to each
redistributor. The maximum number of LPIs to be used can be adjusted with
the command line option "max_lpi_bits", which defaults to a compile time
constant exposed in Kconfig.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/Kconfig  |  15 +
 xen/arch/arm/Makefile |   1 +
 xen/arch/arm/gic-v3-lpi.c | 129 ++
 xen/arch/arm/gic-v3.c |  44 +
 xen/include/asm-arm/bitops.h  |   1 +
 xen/include/asm-arm/gic.h |   2 +
 xen/include/asm-arm/gic_v3_defs.h |  52 ++-
 xen/include/asm-arm/gic_v3_its.h  |  22 ++-
 8 files changed, 264 insertions(+), 2 deletions(-)
 create mode 100644 xen/arch/arm/gic-v3-lpi.c

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index bf64c61..71734a1 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -49,6 +49,21 @@ config HAS_ITS
 bool "GICv3 ITS MSI controller support"
 depends on HAS_GICV3
 
+config MAX_PHYS_LPI_BITS
+depends on HAS_ITS
+int "Maximum bits for GICv3 host LPIs (14-32)"
+range 14 32
+default "20"
+help
+  Specifies the maximum number of LPIs (in bits) Xen should take
+  care of. The host ITS may provide support for a very large number
+  of supported LPIs, for all of which we may not want to allocate
+  memory, so this number here allows to limit this.
+  Xen itself does not know how many LPIs domains will ever need
+  beforehand.
+  This can be overriden on the command line with the max_lpi_bits
+  parameter.
+
 endmenu
 
 menu "ARM errata workaround via the alternative framework"
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 5f4ff23..4ccf2eb 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -19,6 +19,7 @@ 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-$(CONFIG_HAS_ITS) += gic-v3-lpi.o
 obj-y += guestcopy.o
 obj-y += hvm.o
 obj-y += io.o
diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
new file mode 100644
index 000..e2fc901
--- /dev/null
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -0,0 +1,129 @@
+/*
+ * xen/arch/arm/gic-v3-lpi.c
+ *
+ * ARM GICv3 Locality-specific Peripheral Interrupts (LPI) 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Global state */
+static struct {
+uint8_t *lpi_property;
+unsigned int host_lpi_bits;
+} lpi_data;
+
+/* Pending table for each redistributor */
+static DEFINE_PER_CPU(void *, pending_table);
+
+#define MAX_PHYS_LPIS   (BIT_ULL(lpi_data.host_lpi_bits) - LPI_OFFSET)
+
+uint64_t gicv3_lpi_allocate_pendtable(void)
+{
+uint64_t reg;
+void *pendtable;
+
+reg  = GIC_BASER_CACHE_RaWaWb << GICR_PENDBASER_INNER_CACHEABILITY_SHIFT;
+reg |= GIC_BASER_CACHE_SameAsInner << 
GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT;
+reg |= GIC_BASER_InnerShareable << GICR_PENDBASER_SHAREABILITY_SHIFT;
+
+if ( !this_cpu(pending_table) )
+{
+/*
+ * The pending table holds one bit per LPI and even covers bits for
+ * interrupt IDs below 8192, so we allocate the full range.
+ * The GICv3 imposes a 64KB alignment requirement.
+ */
+pendtable = _xmalloc(BIT_ULL(lpi_data.host_lpi_bits) / 8, SZ_64K);
+if ( !pendtable )
+return 0;
+
+memset(pendtable, 0, BIT_ULL(lpi_data.host_lpi_bits) / 8);
+__flush_dcache_area(pendtable, BIT_ULL(lpi_data.host_lpi_bits) / 8);
+
+this_cpu(pending_table) = pendtable;
+}
+else
+{
+pendtable = this_cpu(pending_table);
+}
+
+reg |= GICR_PENDBASER_PTZ;
+
+ASSERT(!(virt_to_maddr(pendtable) & ~GENMASK(51, 16)));
+reg |= virt_to_maddr(pendtable);
+
+return reg;
+}
+
+uint64_t gicv3_lpi_get_proptable(void)
+{
+uint64_t reg;
+
+reg  = GIC_BASER_CACHE_RaWaWb << GICR_PENDBASER_INNER_CACHEABILITY_SHIFT;
+reg |= GIC_BASER_CACHE_SameAsInner << 
GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT;
+reg |= 

[Xen-devel] [PATCH 05/28] ARM: GICv3 ITS: map ITS command buffer

[Andre Przywara]

Instead of directly manipulating the tables in memory, an ITS driver
sends commands via a ring buffer to the ITS h/w to create or alter the
LPI mappings.
Allocate memory for that buffer and tell the ITS about it to be able
to send ITS commands.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v3-its.c| 46 
 xen/include/asm-arm/gic_v3_its.h |  6 ++
 2 files changed, 52 insertions(+)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index c31fef6..ad7cd2a 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -27,6 +27,8 @@
 #include 
 #include 
 
+#define ITS_CMD_QUEUE_SZSZ_64K
+
 #define BASER_ATTR_MASK   \
 ((0x3UL << GITS_BASER_SHAREABILITY_SHIFT)   | \
  (0x7UL << GITS_BASER_OUTER_CACHEABILITY_SHIFT) | \
@@ -44,6 +46,45 @@ static uint64_t encode_phys_addr(paddr_t addr, int page_bits)
 return ret | (addr & GENMASK(51, 48)) >> (48 - 12);
 }
 
+static void *its_map_cbaser(struct host_its *its)
+{
+void __iomem *cbasereg = its->its_base + GITS_CBASER;
+uint64_t reg, regc;
+void *buffer;
+paddr_t paddr;
+
+reg  = GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
+reg |= GIC_BASER_CACHE_SameAsInner << GITS_BASER_OUTER_CACHEABILITY_SHIFT;
+reg |= GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT;
+
+buffer = _xzalloc(ITS_CMD_QUEUE_SZ, PAGE_SIZE);
+if ( !buffer )
+return NULL;
+paddr = virt_to_maddr(buffer);
+ASSERT(!(paddr & ~GENMASK(51, 12)));
+
+reg |= GITS_VALID_BIT | paddr;
+reg |= ((ITS_CMD_QUEUE_SZ / PAGE_SIZE) - 1) & GITS_CBASER_SIZE_MASK;
+writeq_relaxed(reg, cbasereg);
+regc = readq_relaxed(cbasereg);
+
+/* If the ITS dropped shareability, drop cacheability as well. */
+if ( (regc & GITS_BASER_SHAREABILITY_MASK) == 0 )
+{
+regc &= ~GITS_BASER_INNER_CACHEABILITY_MASK;
+writeq_relaxed(regc, cbasereg);
+}
+
+/*
+ * If the command queue memory is mapped as uncached, we need to flush
+ * it on every access.
+ */
+if ( !(regc & GITS_BASER_INNER_CACHEABILITY_MASK) )
+its->flags |= HOST_ITS_FLUSH_CMD_QUEUE;
+
+return buffer;
+}
+
 #define PAGE_BITS(sz) ((sz) * 2 + PAGE_SHIFT)
 
 static int its_map_baser(void __iomem *basereg, uint64_t regc, int nr_items)
@@ -150,6 +191,11 @@ int gicv3_its_init(struct host_its *hw_its)
 }
 }
 
+hw_its->cmd_buf = its_map_cbaser(hw_its);
+if ( !hw_its->cmd_buf )
+return -ENOMEM;
+writeq_relaxed(0, hw_its->its_base + GITS_CWRITER);
+
 return 0;
 }
 
diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
index ed44bdb..ff5572f 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -65,9 +65,13 @@
 #define GITS_BASER_OUTER_CACHEABILITY_MASK   (0x7ULL << 
GITS_BASER_OUTER_CACHEABILITY_SHIFT)
 #define GITS_BASER_INNER_CACHEABILITY_MASK   (0x7ULL << 
GITS_BASER_INNER_CACHEABILITY_SHIFT)
 
+#define GITS_CBASER_SIZE_MASK   0xff
+
 #ifndef __ASSEMBLY__
 #include 
 
+#define HOST_ITS_FLUSH_CMD_QUEUE(1U << 0)
+
 /* data structure for each hardware ITS */
 struct host_its {
 struct list_head entry;
@@ -75,6 +79,8 @@ struct host_its {
 paddr_t addr;
 paddr_t size;
 void __iomem *its_base;
+void *cmd_buf;
+unsigned int flags;
 };
 
 extern struct list_head host_its_list;
-- 
2.9.0


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

[Xen-devel] [PATCH 02/28] ARM: GICv3 ITS: parse and store ITS subnodes from hardware DT

[Andre Przywara]

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 |  4 +++
 xen/arch/arm/Makefile|  1 +
 xen/arch/arm/gic-v3-its.c| 71 
 xen/arch/arm/gic-v3.c| 12 ---
 xen/include/asm-arm/gic_v3_its.h | 57 
 5 files changed, 141 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 2e023d1..bf64c61 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -45,6 +45,10 @@ config ACPI
 config HAS_GICV3
bool
 
+config HAS_ITS
+bool "GICv3 ITS MSI controller support"
+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 59b3b53..5f4ff23 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..ff0f571
--- /dev/null
+++ b/xen/arch/arm/gic-v3-its.c
@@ -0,0 +1,71 @@
+/*
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* 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)
+{
+paddr_t addr, size;
+
+if ( !dt_device_is_compatible(its, "arm,gic-v3-its") )
+continue;
+
+if ( !dt_device_is_available(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 b8be395..838dd11 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -43,9 +43,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
+LIST_HEAD(host_its_list);
+
 /* Global state */
 static struct {
 void __iomem *map_dbase;  /* Mapped address of distributor registers */
@@ -1224,11 +1227,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 gicv3_iomem_deny_access(const struct domain *d)
diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
new file mode 100644
index 000..2f5c51c
--- /dev/null
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -0,0 +1,57 @@
+/*
+ * ARM GICv3 ITS support
+ *
+ * Andre Przywara 
+ * Copyright (c) 2016 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 

[Xen-devel] [PATCH 10/28] ARM: GICv3: introduce separate pending_irq structs for LPIs

[Andre Przywara]

For the same reason that allocating a struct irq_desc for each
possible LPI is not an option, having a struct pending_irq for each LPI
is also not feasible. However we actually only need those when an
interrupt is on a vCPU (or is about to be injected).
Maintain a list of those structs that we can use for the lifecycle of
a guest LPI. We allocate new entries if necessary, however reuse
pre-owned entries whenever possible.
I added some locking around this list here, however my gut feeling is
that we don't need one because this a per-VCPU structure anyway.
If someone could confirm this, I'd be grateful.
Teach the existing VGIC functions to find the right pointer when being
given a virtual LPI number.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic.c   |  3 +++
 xen/arch/arm/vgic-v3.c   |  3 +++
 xen/arch/arm/vgic.c  | 64 +---
 xen/include/asm-arm/domain.h |  2 ++
 xen/include/asm-arm/vgic.h   | 14 ++
 5 files changed, 83 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index a5348f2..bd3c032 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -509,6 +509,9 @@ static void gic_update_one_lr(struct vcpu *v, int i)
 struct vcpu *v_target = vgic_get_target_vcpu(v, irq);
 irq_set_affinity(p->desc, cpumask_of(v_target->processor));
 }
+/* If this was an LPI, mark this struct as available again. */
+if ( is_lpi(p->irq) )
+p->irq = 0;
 }
 }
 }
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 1fadb00..b0653c2 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1426,6 +1426,9 @@ static int vgic_v3_vcpu_init(struct vcpu *v)
 if ( v->vcpu_id == last_cpu || (v->vcpu_id == (d->max_vcpus - 1)) )
 v->arch.vgic.flags |= VGIC_V3_RDIST_LAST;
 
+spin_lock_init(>arch.vgic.pending_lpi_list_lock);
+INIT_LIST_HEAD(>arch.vgic.pending_lpi_list);
+
 return 0;
 }
 
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 364d5f0..7e3440f 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -31,6 +31,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v, int rank)
 {
@@ -61,7 +63,7 @@ struct vgic_irq_rank *vgic_rank_irq(struct vcpu *v, unsigned 
int irq)
 return vgic_get_rank(v, rank);
 }
 
-static void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq)
+void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq)
 {
 INIT_LIST_HEAD(>inflight);
 INIT_LIST_HEAD(>lr_queue);
@@ -244,10 +246,14 @@ struct vcpu *vgic_get_target_vcpu(struct vcpu *v, 
unsigned int virq)
 
 static int vgic_get_virq_priority(struct vcpu *v, unsigned int virq)
 {
-struct vgic_irq_rank *rank = vgic_rank_irq(v, virq);
+struct vgic_irq_rank *rank;
 unsigned long flags;
 int priority;
 
+if ( is_lpi(virq) )
+return vgic_lpi_get_priority(v->domain, virq);
+
+rank = vgic_rank_irq(v, virq);
 vgic_lock_rank(v, rank, flags);
 priority = rank->priority[virq & INTERRUPT_RANK_MASK];
 vgic_unlock_rank(v, rank, flags);
@@ -446,13 +452,63 @@ bool vgic_to_sgi(struct vcpu *v, register_t sgir, enum 
gic_sgi_mode irqmode,
 return true;
 }
 
+/*
+ * Holding struct pending_irq's for each possible virtual LPI in each domain
+ * requires too much Xen memory, also a malicious guest could potentially
+ * spam Xen with LPI map requests. We cannot cover those with (guest allocated)
+ * ITS memory, so we use a dynamic scheme of allocating struct pending_irq's
+ * on demand.
+ */
+struct pending_irq *lpi_to_pending(struct vcpu *v, unsigned int lpi,
+   bool allocate)
+{
+struct lpi_pending_irq *lpi_irq, *empty = NULL;
+
+spin_lock(>arch.vgic.pending_lpi_list_lock);
+list_for_each_entry(lpi_irq, >arch.vgic.pending_lpi_list, entry)
+{
+if ( lpi_irq->pirq.irq == lpi )
+{
+spin_unlock(>arch.vgic.pending_lpi_list_lock);
+return _irq->pirq;
+}
+
+if ( lpi_irq->pirq.irq == 0 && !empty )
+empty = lpi_irq;
+}
+
+if ( !allocate )
+{
+spin_unlock(>arch.vgic.pending_lpi_list_lock);
+return NULL;
+}
+
+if ( !empty )
+{
+empty = xzalloc(struct lpi_pending_irq);
+vgic_init_pending_irq(>pirq, lpi);
+list_add_tail(>entry, >arch.vgic.pending_lpi_list);
+} else
+{
+empty->pirq.status = 0;
+empty->pirq.irq = lpi;
+}
+
+spin_unlock(>arch.vgic.pending_lpi_list_lock);
+
+return >pirq;
+}
+
 struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
 {
 struct pending_irq *n;
+
 /* Pending irqs allocation strategy: the first vgic.nr_spis irqs
  * are used for SPIs; the rests are used for per cpu irqs */
 if ( irq < 32 )

[Xen-devel] [PATCH 01/28] ARM: export __flush_dcache_area()

[Andre Przywara]

The ability to clean a cache line is not only useful for EFI, but will
be needed later for the ITS support.
Export the function to be usable from the whole Xen/ARM code.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/efi/efi-boot.h | 1 -
 xen/include/asm-arm/cache.h | 4 
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index 045d6ce..dc64aec 100644
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -10,7 +10,6 @@
 #include "efi-dom0.h"
 
 void noreturn efi_xen_start(void *fdt_ptr, uint32_t fdt_size);
-void __flush_dcache_area(const void *vaddr, unsigned long size);
 
 #define DEVICE_TREE_GUID \
 {0xb1b621d5, 0xf19c, 0x41a5, {0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0}}
diff --git a/xen/include/asm-arm/cache.h b/xen/include/asm-arm/cache.h
index 2de6564..af96eee 100644
--- a/xen/include/asm-arm/cache.h
+++ b/xen/include/asm-arm/cache.h
@@ -7,6 +7,10 @@
 #define L1_CACHE_SHIFT  (CONFIG_ARM_L1_CACHE_SHIFT)
 #define L1_CACHE_BYTES  (1 << L1_CACHE_SHIFT)
 
+#ifndef __ASSEMBLY__
+void __flush_dcache_area(const void *vaddr, unsigned long size);
+#endif
+
 #define __read_mostly __section(".data.read_mostly")
 
 #endif
-- 
2.9.0


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

[Xen-devel] [PATCH 00/28] arm64: Dom0 ITS emulation

[Andre Przywara]

Hi,

after the two RFC versions now the first "serious" attempt for emulating
an ARM GICv3 ITS interrupt controller, for Dom0 only at the moment.
The ITS is an interrupt controller widget providing a sophisticated way
of dealing with MSIs in a scalable manner.
For hardware which relies on the ITS to provide interrupts for its
peripherals this code is needed to get a machine booted into Dom0 at all.
ITS emulation for DomUs is only really useful with PCI passthrough,
which is not yet available for ARM. It is expected that this feature
will be co-developed with the ITS DomU code. However this code drop here
considered DomU emulation already, to keep later architectural changes
to a minimum.

Some generic design principles:

* The current GIC code statically allocates structures for each supported
IRQ (both for the host and the guest), which due to the potentially
millions of LPI interrupts is not feasible to copy for the ITS.
So we refrain from introducing the ITS as a first class Xen interrupt
controller, also we don't hold struct irq_desc's or struct pending_irq's
for each possible LPI.
Fortunately LPIs are only interesting to guests, so we get away with
storing only the virtual IRQ number and the guest VCPU for each allocated
host LPI, which can be stashed into one uint64_t. This data is stored in
a two-level table, which is both memory efficient and quick to access.
We hook into the existing IRQ handling and VGIC code to avoid accessing
the normal structures, providing alternative methods for getting the
needed information (priority, is enabled?) for LPIs.
For interrupts which are queued to or are actually in a guest we
allocate struct pending_irq's on demand. As it is expected that only a
very small number of interrupts is ever on a VCPU at the same time, this
seems like the best approach. For now allocated structs are re-used and
held in a linked list. Should it emerge that traversing a linked list
is a performance issue, this can be changed to use a hash table.

* On the guest side we (later will) have to deal with malicious guests
trying to hog Xen with mapping requests for a lot of LPIs, for instance.
As the ITS actually uses system memory for storing status information,
we use this memory (which the guest has to provide) to naturally limit
a guest. For those tables which are page sized (devices, collections (CPUs),
LPI properties) we map those pages into Xen, so we can easily access
them from the virtual GIC code.
Unfortunately the actual interrupt mapping tables are not necessarily
page aligned, also can be much smaller than a page, so mapping all of
them permanently is fiddly. As ITS commands in need to iterate those
tables are pretty rare after all, we for now map them on demand upon
emulating a virtual ITS command. This is acceptable because "mapping"
them is actually very cheap on arm64. Also as we can't properly protect
those areas due to their sub-page-size property, we validate the data
in there before actually using it. The vITS code basically just stores
the data in there which the guest has actually transferred via the
virtual ITS command queue before, so there is no secret revealed nor
does it create an attack vector for a malicious guest.

* An obvious approach to handling some guest ITS commands would be to
propagate them to the host, for instance to map devices and LPIs and
to enable or disable LPIs.
However this (later with DomU support) will create an attack vector, as
a malicious guest could try to fill the host command queue with
propagated commands.
So (in contrast to the first RFC post) we completely avoid this situation.
For mapping devices and LPIs we rely on this being done via a hypercall
prior to the actual guest run. For enabling and disabling LPIs we keep
this bit on the virtual side and let LPIs always be enabled on the host side,
dealing with the consequences this approach creates.

As it is expected that the ITS support will become a tech preview in the
first release, there is a Kconfig option to enable it. Also it is
supported on arm64 only, which will most likely not change in the future.
This leads to some hideous constructs like an #ifdef'ed header file with
empty function stubs, I have some hope we can still clean this up.
Also some parameters are config options which can be overridden on the
Xen commandline. This is to support experimentation and adaption to
various platforms, ideally we find either one-size-fits-all values or
find another way of getting rid of this.

Compared to the previous post (RFC-v2) this has seen a lot of reworks
and cleanups in various areas.
I tried to address all of the review comments, though some are hard to
follow due to rewrites. So apologies if some points have slipped through.
Allocating and mapping of memory for both the physical and virtual ITS
and redistributor tables has been improved, though I didn't manage to
write protect the virtual tables from a guest without impacting access
from Xen at the same time. I will need to 

[Xen-devel] [PATCH] acpi: Switch to dynamic mapping at SYS_STATE_boot

[Boris Ostrovsky]

We can switch ACPI from using fixmap to dynamic mapping as soon as
the system enters SYS_STATE_boot. This will allow us, for example,
to map MADT on systems with large number of processors where the
table might not fit into NUM_FIXMAP_ACPI_PAGES (currently set to 4).

Signed-off-by: Boris Ostrovsky 
---
 xen/drivers/acpi/osl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
index 3616dfd..7199047 100644
--- a/xen/drivers/acpi/osl.c
+++ b/xen/drivers/acpi/osl.c
@@ -89,7 +89,7 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
 void __iomem *
 acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
 {
-   if (system_state >= SYS_STATE_active) {
+   if (system_state >= SYS_STATE_boot) {
mfn_t mfn = _mfn(PFN_DOWN(phys));
unsigned int offs = phys & (PAGE_SIZE - 1);
 
@@ -104,7 +104,7 @@ acpi_os_map_memory(acpi_physical_address phys, acpi_size 
size)
 
 void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
 {
-   if (system_state >= SYS_STATE_active)
+   if (system_state >= SYS_STATE_boot)
vunmap((void *)((unsigned long)virt & PAGE_MASK));
 }
 
-- 
1.8.3.1


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

Re: [Xen-devel] [PATCH] xen-netfront: Delete rx_refill_timer in xennet_disconnect_backend()

[Boris Ostrovsky]

On 01/30/2017 01:07 PM, Eric Dumazet wrote:
> On Mon, 2017-01-30 at 12:45 -0500, Boris Ostrovsky wrote:
>> rx_refill_timer should be deleted as soon as we disconnect from the
>> backend since otherwise it is possible for the timer to go off before
>> we get to xennet_destroy_queues(). If this happens we may dereference
>> queue->rx.sring which is set to NULL in xennet_disconnect_backend().
>>
>> Signed-off-by: Boris Ostrovsky 
>> CC: sta...@vger.kernel.org
>> ---
>>  drivers/net/xen-netfront.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
>> index 8315fe7..722fe9f 100644
>> --- a/drivers/net/xen-netfront.c
>> +++ b/drivers/net/xen-netfront.c
>> @@ -1379,6 +1379,8 @@ static void xennet_disconnect_backend(struct 
>> netfront_info *info)
>>  for (i = 0; i < num_queues && info->queues; ++i) {
>>  struct netfront_queue *queue = >queues[i];
>>  
>> +del_timer_sync(>rx_refill_timer);
>> +
> If napi_disable() was not called before this del_timer_sync(), another
> RX might come here and rearm rx_refill_timer.

We do netif_carrier_off() first thing in xennet_disconnect_backend() and
the only place where the timer is rearmed is xennet_alloc_rx_buffers(),
which is guarded by netif_carrier_ok() check.

-boris


>
>>  if (queue->tx_irq && (queue->tx_irq == queue->rx_irq))
>>  unbind_from_irqhandler(queue->tx_irq, queue);
>>  if (queue->tx_irq && (queue->tx_irq != queue->rx_irq)) {
>> @@ -1733,7 +1735,6 @@ static void xennet_destroy_queues(struct netfront_info 
>> *info)
>>  
>>  if (netif_running(info->netdev))
>>  napi_disable(>napi);
>> -del_timer_sync(>rx_refill_timer);
>>  netif_napi_del(>napi);
>>  }
>>  
>


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

Re: [Xen-devel] [PATCH RESEND v5 01/24] docs: create L2 Cache Allocation Technology (CAT) feature document

[Konrad Rzeszutek Wilk]

On Thu, Jan 19, 2017 at 02:01:03PM +0800, Yi Sun wrote:
> This patch creates L2 CAT feature document in doc/features/.
> It describes details of L2 CAT.

Perhaps also mention what is the title in the Intel SDM 
to look into as well?
Perhaps:
"See Intel Resource Director Technology Monitoring Features"
in the Intel SDM."

> 
> Signed-off-by: Yi Sun 
> ---
>  docs/features/intel_psr_l2_cat.pandoc | 347 
> ++
>  1 file changed, 347 insertions(+)
>  create mode 100644 docs/features/intel_psr_l2_cat.pandoc
> 
> diff --git a/docs/features/intel_psr_l2_cat.pandoc 
> b/docs/features/intel_psr_l2_cat.pandoc
> new file mode 100644
> index 000..77bd61f
> --- /dev/null
> +++ b/docs/features/intel_psr_l2_cat.pandoc
> @@ -0,0 +1,347 @@
> +% Intel L2 Cache Allocation Technology (L2 CAT) Feature
> +% Revision 1.0
> +
> +\clearpage
> +
> +# Basics
> +
> + 
> + Status: **Tech Preview**
> +
> +Architecture(s): Intel x86
> +
> +   Component(s): Hypervisor, toolstack
> +
> +   Hardware: Atom codename Goldmont and beyond CPUs
> + 
> +
> +# Overview
> +
> +L2 CAT allows an OS or Hypervisor/VMM to control allocation of a
> +CPU's shared L2 cache based on application priority or Class of Service
> +(COS). Each CLOS is configured using capacity bitmasks (CBM) which
> +represent cache capacity and indicate the degree of overlap and

indicates
> +isolation between classes. Once L2 CAT is configured, the processor
> +allows access to portions of L2 cache according to the established
> +class of service.
> +
> +## Terminology
> +
> +* CAT Cache Allocation Technology
> +* CBM Capacity BitMasks
> +* CDP Code and Data Prioritization
> +* COS/CLOSClass of Service
> +* MSRsMachine Specific Registers
> +* PSR Intel Platform Shared Resource
> +* VMM Virtual Machine Monitor
> +
> +# User details
> +
> +* Feature Enabling:
> +
> +  Add "psr=cat" to boot line parameter to enable all supported level CAT
> +  features.
> +
> +* xl interfaces:
> +
> +  1. `psr-cat-show [OPTIONS] domain-id`:
> +
> + Show domain L2 or L3 CAT CBM.
> +
> + New option `-l` is added.
> + `-l2`: Show cbm for L2 cache.
> + `-l3`: Show cbm for L3 cache.
> +
> + If neither `-l2` nor `-l3` is given, show both of them. If any one
> + is not supported, will print error info.
> +
> +  2. `psr-cat-cbm-set [OPTIONS] domain-id cbm`:
> +
> + Set domain L2 or L3 CBM.
> +
> + New option `-l` is added.
> + `-l2`: Specify cbm for L2 cache.
> + `-l3`: Specify cbm for L3 cache.
> +
> + If neither `-l2` nor `-l3` is given, level 3 is the default option.
> +
> +  3. `psr-hwinfo [OPTIONS]`:
> +
> + Show L2 & L3 CAT HW informations on every socket.
> +
> +# Technical details
> +
> +L2 CAT is a member of Intel PSR features and part of CAT, it shares
> +some base PSR infrastructure in Xen.
> +
> +## Hardware perspective
> +
> +L2 CAT defines a new range MSRs to assign different L2 cache access
 ^- 'of'

> +patterns which are known as CBMs, each CBM is associated with a COS.
> +
> +```
> +
> ++++
> +   IA32_PQR_ASSOC   | MSR (per socket)   |Address |
> + ++---+---+ +++
> + ||COS|   | | IA32_L2_QOS_MASK_0 | 0xD10  |
> + ++---+---+ +++
> +└-> | ...|  ...   |
> ++++
> +| IA32_L2_QOS_MASK_n | 0xD10+n (n<64) |
> ++++
> +```
> +
> +When context switch happens, the COS of VCPU is written to per-thread
> +MSR `IA32_PQR_ASSOC`, and then hardware enforces L2 cache allocation
> +according to the corresponding CBM.
> +
> +## The relationship between L2 CAT and L3 CAT/CDP
> +
> +L2 CAT is independent of L3 CAT/CDP, which means L2 CAT would be enabled
> +while L3 CAT/CDP is disabled, or L2 CAT and L3 CAT/CDP are all enabled.

s/all/both/

> +
> +L2 CAT uses a new range CBMs from 0xD10 ~ 0xD10+n (n<64), following by

s/by//
> +the L3 CAT/CDP CBMs, and supports setting different L2 cache accessing
> +patterns from L3 cache. Like L3 CAT/CDP requirement, the bits of CBM of
> +L2 CAT must be continuous too.
> +
> +N.B. L2 CAT and L3 CAT/CDP share the same COS field in the same
> +associate register `IA32_PQR_ASSOC`, which means one COS associates to a

s/associates to a/is associated with a/

> +pair of L2 CBM and L3 CBM.
> +
> +Besides, the max COS of L2 CAT may be different from L3 CAT/CDP (or
> +other PSR features in future). In some 

Re: [Xen-devel] [PATCH] xen-netfront: Delete rx_refill_timer in xennet_disconnect_backend()

[Eric Dumazet]

On Mon, 2017-01-30 at 12:45 -0500, Boris Ostrovsky wrote:
> rx_refill_timer should be deleted as soon as we disconnect from the
> backend since otherwise it is possible for the timer to go off before
> we get to xennet_destroy_queues(). If this happens we may dereference
> queue->rx.sring which is set to NULL in xennet_disconnect_backend().
> 
> Signed-off-by: Boris Ostrovsky 
> CC: sta...@vger.kernel.org
> ---
>  drivers/net/xen-netfront.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 8315fe7..722fe9f 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -1379,6 +1379,8 @@ static void xennet_disconnect_backend(struct 
> netfront_info *info)
>   for (i = 0; i < num_queues && info->queues; ++i) {
>   struct netfront_queue *queue = >queues[i];
>  
> + del_timer_sync(>rx_refill_timer);
> +

If napi_disable() was not called before this del_timer_sync(), another
RX might come here and rearm rx_refill_timer.

>   if (queue->tx_irq && (queue->tx_irq == queue->rx_irq))
>   unbind_from_irqhandler(queue->tx_irq, queue);
>   if (queue->tx_irq && (queue->tx_irq != queue->rx_irq)) {
> @@ -1733,7 +1735,6 @@ static void xennet_destroy_queues(struct netfront_info 
> *info)
>  
>   if (netif_running(info->netdev))
>   napi_disable(>napi);
> - del_timer_sync(>rx_refill_timer);
>   netif_napi_del(>napi);
>   }
>  



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

Re: [Xen-devel] [PATCH 2/2] x86/vmx: Drop ept_get_*() helpers

[George Dunlap]

On 30/01/17 16:54, Andrew Cooper wrote:
> The ept_get_*() helpers are not used consistently, and are more verbose than
> the code they wrap.  Drop the wrappers and use the internal union names
> consistently.
> 
> While making these adjustments, drop the redundant ept_* prefix from mt, wl
> and ad, and rename the asr field to mfn for consistency with Xen's existing
> terminology.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: George Dunlap 


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

[Xen-devel] [PATCH] xen-netfront: Delete rx_refill_timer in xennet_disconnect_backend()

[Boris Ostrovsky]

rx_refill_timer should be deleted as soon as we disconnect from the
backend since otherwise it is possible for the timer to go off before
we get to xennet_destroy_queues(). If this happens we may dereference
queue->rx.sring which is set to NULL in xennet_disconnect_backend().

Signed-off-by: Boris Ostrovsky 
CC: sta...@vger.kernel.org
---
 drivers/net/xen-netfront.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 8315fe7..722fe9f 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1379,6 +1379,8 @@ static void xennet_disconnect_backend(struct 
netfront_info *info)
for (i = 0; i < num_queues && info->queues; ++i) {
struct netfront_queue *queue = >queues[i];
 
+   del_timer_sync(>rx_refill_timer);
+
if (queue->tx_irq && (queue->tx_irq == queue->rx_irq))
unbind_from_irqhandler(queue->tx_irq, queue);
if (queue->tx_irq && (queue->tx_irq != queue->rx_irq)) {
@@ -1733,7 +1735,6 @@ static void xennet_destroy_queues(struct netfront_info 
*info)
 
if (netif_running(info->netdev))
napi_disable(>napi);
-   del_timer_sync(>rx_refill_timer);
netif_napi_del(>napi);
}
 
-- 
1.8.3.1


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

[Xen-devel] [PATCH 1/2] x86/mm: Plumb a error return through {paging, hap, shadow}_vcpu_init()

[Andrew Cooper]

No functional change yet, but required for subsequent changes.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Tim Deegan 
CC: George Dunlap 
---
 xen/arch/x86/domain.c   | 3 ++-
 xen/arch/x86/mm/hap/hap.c   | 3 ++-
 xen/arch/x86/mm/paging.c| 6 +++---
 xen/arch/x86/mm/shadow/common.c | 3 ++-
 xen/arch/x86/mm/shadow/none.c   | 3 ++-
 xen/include/asm-x86/hap.h   | 2 +-
 xen/include/asm-x86/paging.h| 2 +-
 xen/include/asm-x86/shadow.h| 2 +-
 8 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 71c0e3c..4edc4c8 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -384,7 +384,8 @@ int vcpu_initialise(struct vcpu *v)
 
 if ( !is_idle_domain(d) )
 {
-paging_vcpu_init(v);
+if ( (rc = paging_vcpu_init(v)) )
+return rc;
 
 if ( (rc = vcpu_init_fpu(v)) != 0 )
 return rc;
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 6dbb3cc..2d52dbd 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -641,10 +641,11 @@ static const struct paging_mode hap_paging_protected_mode;
 static const struct paging_mode hap_paging_pae_mode;
 static const struct paging_mode hap_paging_long_mode;
 
-void hap_vcpu_init(struct vcpu *v)
+int hap_vcpu_init(struct vcpu *v)
 {
 v->arch.paging.mode = _paging_real_mode;
 v->arch.paging.nestedmode = _paging_real_mode;
+return 0;
 }
 
 //
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index d964ed5..bd4f469 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -673,12 +673,12 @@ int paging_domain_init(struct domain *d, unsigned int 
domcr_flags)
 }
 
 /* vcpu paging struct initialization goes here */
-void paging_vcpu_init(struct vcpu *v)
+int paging_vcpu_init(struct vcpu *v)
 {
 if ( hap_enabled(v->domain) )
-hap_vcpu_init(v);
+return hap_vcpu_init(v);
 else
-shadow_vcpu_init(v);
+return shadow_vcpu_init(v);
 }
 
 
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index a619d65..aa0b8f0 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -81,7 +81,7 @@ int shadow_domain_init(struct domain *d, unsigned int 
domcr_flags)
  * matter to have v->arch.paging.mode pointing to any mode, as long as it can
  * be compiled.
  */
-void shadow_vcpu_init(struct vcpu *v)
+int shadow_vcpu_init(struct vcpu *v)
 {
 #if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
 int i, j;
@@ -98,6 +98,7 @@ void shadow_vcpu_init(struct vcpu *v)
 v->arch.paging.mode = is_pv_vcpu(v) ?
   _INTERNAL_NAME(sh_paging_mode, 4) :
   _INTERNAL_NAME(sh_paging_mode, 3);
+return 0;
 }
 
 #if SHADOW_AUDIT
diff --git a/xen/arch/x86/mm/shadow/none.c b/xen/arch/x86/mm/shadow/none.c
index 69e56c5..81ab42a 100644
--- a/xen/arch/x86/mm/shadow/none.c
+++ b/xen/arch/x86/mm/shadow/none.c
@@ -71,8 +71,9 @@ static const struct paging_mode sh_paging_none = {
 .write_p2m_entry   = _write_p2m_entry,
 };
 
-void shadow_vcpu_init(struct vcpu *v)
+int shadow_vcpu_init(struct vcpu *v)
 {
 ASSERT(is_pv_vcpu(v));
 v->arch.paging.mode = _paging_none;
+return 0;
 }
diff --git a/xen/include/asm-x86/hap.h b/xen/include/asm-x86/hap.h
index 88587c4..ca55328 100644
--- a/xen/include/asm-x86/hap.h
+++ b/xen/include/asm-x86/hap.h
@@ -39,7 +39,7 @@ int   hap_domctl(struct domain *d, xen_domctl_shadow_op_t *sc,
 int   hap_enable(struct domain *d, u32 mode);
 void  hap_final_teardown(struct domain *d);
 void  hap_teardown(struct domain *d, bool *preempted);
-void  hap_vcpu_init(struct vcpu *v);
+int   hap_vcpu_init(struct vcpu *v);
 int   hap_track_dirty_vram(struct domain *d,
unsigned long begin_pfn,
unsigned long nr,
diff --git a/xen/include/asm-x86/paging.h b/xen/include/asm-x86/paging.h
index cec6bfd..4857871 100644
--- a/xen/include/asm-x86/paging.h
+++ b/xen/include/asm-x86/paging.h
@@ -197,7 +197,7 @@ struct sh_dirty_vram {
 
 /* Initialize the paging resource for vcpu struct. It is called by
  * vcpu_initialise() in domain.c */
-void paging_vcpu_init(struct vcpu *v);
+int paging_vcpu_init(struct vcpu *v);
 
 /* Set up the paging-assistance-specific parts of a domain struct at
  * start of day.  Called for every domain from arch_domain_create() */
diff --git a/xen/include/asm-x86/shadow.h b/xen/include/asm-x86/shadow.h
index 7e1ed3b..da83188 100644
--- a/xen/include/asm-x86/shadow.h
+++ b/xen/include/asm-x86/shadow.h
@@ -52,7 +52,7 @@ int shadow_domain_init(struct domain *d, unsigned int 
domcr_flags);
 
 /* Setup the shadow-specific parts of a vcpu struct. It is called by
  * paging_vcpu_init() in paging.c */
-void 

[Xen-devel] [PATCH 2/2] x86/shadow: Move shadow pagetable fields into struct shadow_vcpu

[Andrew Cooper]

The vTLB and last_write* booleans are used exclusively by the shadow pagetable
code.  Move them from paging_vcpu to shadow_vcpu, which causes them to be
entirely omitted on a build without shadow paging support.

While changing the qualified names of these variables, drop an unnessary NULL
check before freeing the vTLB, and move allocation of the vTLB from
sh_update_paging_modes() to shadow_vcpu_init() where it more logically
belongs.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Tim Deegan 
CC: George Dunlap 
---
 xen/arch/x86/mm/shadow/common.c  | 35 ---
 xen/arch/x86/mm/shadow/multi.c   | 22 +++---
 xen/arch/x86/mm/shadow/private.h | 24 
 xen/include/asm-x86/domain.h | 18 ++
 4 files changed, 45 insertions(+), 54 deletions(-)

diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index aa0b8f0..1075d56 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -95,6 +95,14 @@ int shadow_vcpu_init(struct vcpu *v)
 }
 #endif
 
+#if (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB)
+/* Allocate a virtual TLB for this vcpu. */
+v->arch.paging.shadow.vtlb = xzalloc_array(struct shadow_vtlb, 
VTLB_ENTRIES);
+if ( !v->arch.paging.shadow.vtlb )
+return -ENOMEM;
+spin_lock_init(>arch.paging.shadow.vtlb_lock);
+#endif /* (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB) */
+
 v->arch.paging.mode = is_pv_vcpu(v) ?
   _INTERNAL_NAME(sh_paging_mode, 4) :
   _INTERNAL_NAME(sh_paging_mode, 3);
@@ -1459,7 +1467,7 @@ void shadow_free(struct domain *d, mfn_t smfn)
 v->arch.paging.shadow.last_writeable_pte_smfn = 0;
 #endif
 #if SHADOW_OPTIMIZATIONS & SHOPT_FAST_EMULATION
-v->arch.paging.last_write_emul_ok = 0;
+v->arch.paging.shadow.last_write_emul_ok = 0;
 #endif
 }
 #endif
@@ -1680,7 +1688,7 @@ static mfn_t emulate_gva_to_mfn(struct vcpu *v, unsigned 
long vaddr,
 mfn = page_to_mfn(page);
 ASSERT(mfn_valid(mfn));
 
-v->arch.paging.last_write_was_pt = !!sh_mfn_is_a_page_table(mfn);
+v->arch.paging.shadow.last_write_was_pt = !!sh_mfn_is_a_page_table(mfn);
 /*
  * Note shadow cannot page out or unshare this mfn, so the map won't
  * disappear. Otherwise, caller must hold onto page until done.
@@ -2864,22 +2872,6 @@ static void sh_update_paging_modes(struct vcpu *v)
 
 ASSERT(paging_locked_by_me(d));
 
-#if (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB)
-/* Make sure this vcpu has a virtual TLB array allocated */
-if ( unlikely(!v->arch.paging.vtlb) )
-{
-v->arch.paging.vtlb = xzalloc_array(struct shadow_vtlb, VTLB_ENTRIES);
-if ( unlikely(!v->arch.paging.vtlb) )
-{
-SHADOW_ERROR("Could not allocate vTLB space for dom %u vcpu %u\n",
- d->domain_id, v->vcpu_id);
-domain_crash(v->domain);
-return;
-}
-spin_lock_init(>arch.paging.vtlb_lock);
-}
-#endif /* (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB) */
-
 #if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
 if ( mfn_eq(v->arch.paging.shadow.oos_snapshot[0], INVALID_MFN) )
 {
@@ -3206,11 +3198,8 @@ void shadow_teardown(struct domain *d, bool *preempted)
 for_each_vcpu(d, v)
 {
 #if (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB)
-if ( v->arch.paging.vtlb )
-{
-xfree(v->arch.paging.vtlb);
-v->arch.paging.vtlb = NULL;
-}
+xfree(v->arch.paging.shadow.vtlb);
+v->arch.paging.shadow.vtlb = NULL;
 #endif /* (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB) */
 
 #if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index d4090d7..20db60f 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -2881,7 +2881,7 @@ static int sh_page_fault(struct vcpu *v,
  * it's highly likely to reach same emulation action for this frame.
  * Then try to emulate early to avoid lock aquisition.
  */
-if ( v->arch.paging.last_write_emul_ok
+if ( v->arch.paging.shadow.last_write_emul_ok
  && v->arch.paging.shadow.last_emulated_frame == (va >> PAGE_SHIFT) )
 {
 /* check whether error code is 3, or else fall back to normal path
@@ -2898,7 +2898,7 @@ static int sh_page_fault(struct vcpu *v,
 if ( mfn_valid(gmfn) && mfn_is_out_of_sync(gmfn) )
 {
 fast_emul = 0;
-v->arch.paging.last_write_emul_ok = 0;
+v->arch.paging.shadow.last_write_emul_ok = 0;
 goto page_fault_slow_path;
 }
 #endif /* OOS */
@@ -2907,7 +2907,7 @@ static int sh_page_fault(struct vcpu *v,
 goto early_emulation;
 }
 else
-

[Xen-devel] [RFC v1 1/6] xen/arm: traps: Reorder early overwrite of FID

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

Move the early setting of PSCI_RESULT_REG to a later stage
avoiding the early override of the FID that's stored in
the same register.

No functional change.

Signed-off-by: Edgar E. Iglesias 
---
 xen/arch/arm/traps.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 35d8e8b..a5fbf1e 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1334,8 +1334,6 @@ static void do_trap_psci(struct cpu_user_regs *regs)
 {
 register_t fid = PSCI_ARG(regs,0);
 
-/* preloading in case psci_mode_check fails */
-PSCI_RESULT_REG(regs) = PSCI_INVALID_PARAMETERS;
 switch( fid )
 {
 case PSCI_cpu_off:
@@ -1368,6 +1366,7 @@ static void do_trap_psci(struct cpu_user_regs *regs)
 case PSCI_0_2_FN_MIGRATE_INFO_UP_CPU:
 case PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU:
 perfc_incr(vpsci_migrate_info_up_cpu);
+PSCI_RESULT_REG(regs) = PSCI_INVALID_PARAMETERS;
 if ( psci_mode_check(current->domain, fid) )
 PSCI_RESULT_REG(regs) = do_psci_0_2_migrate_info_up_cpu();
 break;
@@ -1384,6 +1383,7 @@ static void do_trap_psci(struct cpu_user_regs *regs)
 case PSCI_0_2_FN_CPU_ON:
 case PSCI_0_2_FN64_CPU_ON:
 perfc_incr(vpsci_cpu_on);
+PSCI_RESULT_REG(regs) = PSCI_INVALID_PARAMETERS;
 if ( psci_mode_check(current->domain, fid) )
 {
 register_t vcpuid = PSCI_ARG(regs,1);
@@ -1396,6 +1396,7 @@ static void do_trap_psci(struct cpu_user_regs *regs)
 case PSCI_0_2_FN_CPU_SUSPEND:
 case PSCI_0_2_FN64_CPU_SUSPEND:
 perfc_incr(vpsci_cpu_suspend);
+PSCI_RESULT_REG(regs) = PSCI_INVALID_PARAMETERS;
 if ( psci_mode_check(current->domain, fid) )
 {
 uint32_t pstate = PSCI_ARG32(regs,1);
@@ -1408,6 +1409,7 @@ static void do_trap_psci(struct cpu_user_regs *regs)
 case PSCI_0_2_FN_AFFINITY_INFO:
 case PSCI_0_2_FN64_AFFINITY_INFO:
 perfc_incr(vpsci_cpu_affinity_info);
+PSCI_RESULT_REG(regs) = PSCI_INVALID_PARAMETERS;
 if ( psci_mode_check(current->domain, fid) )
 {
 register_t taff = PSCI_ARG(regs,1);
@@ -1419,6 +1421,7 @@ static void do_trap_psci(struct cpu_user_regs *regs)
 case PSCI_0_2_FN_MIGRATE:
 case PSCI_0_2_FN64_MIGRATE:
 perfc_incr(vpsci_cpu_migrate);
+PSCI_RESULT_REG(regs) = PSCI_INVALID_PARAMETERS;
 if ( psci_mode_check(current->domain, fid) )
 {
 uint32_t tcpu = PSCI_ARG32(regs,1);
-- 
2.7.4


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

[Xen-devel] [RFC v1 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

Allow platform_hvc to handle guest SMC calls (as well as
HVC calls) in a platform specific way.

Signed-off-by: Edgar E. Iglesias 
---
 xen/arch/arm/traps.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index e8cd111..1925122 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2622,6 +2622,9 @@ static void do_trap_smc(struct cpu_user_regs *regs, const 
union hsr hsr)
 if ( current->domain->arch.monitor.privileged_call_enabled )
 rc = monitor_smc();
 
+if ( platform_hvc(regs) )
+rc = 1;
+
 if ( rc != 1 )
 inject_undef_exception(regs, hsr);
 }
-- 
2.7.4


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

[Xen-devel] [RFC v1 5/6] xen/arm: zynqmp: Forward plaform specific firmware calls

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

Forward platform specific firmware calls from the hardware
domain to firmware.

Signed-off-by: Edgar E. Iglesias 
---
 xen/arch/arm/platforms/xilinx-zynqmp.c | 63 ++
 1 file changed, 63 insertions(+)

diff --git a/xen/arch/arm/platforms/xilinx-zynqmp.c 
b/xen/arch/arm/platforms/xilinx-zynqmp.c
index 2adee91..bde7f52 100644
--- a/xen/arch/arm/platforms/xilinx-zynqmp.c
+++ b/xen/arch/arm/platforms/xilinx-zynqmp.c
@@ -19,6 +19,46 @@
 
 #include 
 
+/* Service calls.  */
+#define SVC_MASK 0x3F00
+#define SVC_SIP  0x0200/* SoC Implementation Specific.  */
+
+/* SMC function IDs for SiP Service queries */
+#define ZYNQMP_SIP_SVC_CALL_COUNT   0xff00
+#define ZYNQMP_SIP_SVC_UID  0xff01
+#define ZYNQMP_SIP_SVC_VERSION  0xff03
+
+enum pm_api_id {
+/* Miscellaneous API functions: */
+GET_API_VERSION = 1,
+SET_CONFIGURATION,
+GET_NODE_STATUS,
+GET_OPERATING_CHARACTERISTIC,
+REGISTER_NOTIFIER,
+/* API for suspending of PUs: */
+REQUEST_SUSPEND,
+SELF_SUSPEND,
+FORCE_POWERDOWN,
+ABORT_SUSPEND,
+REQUEST_WAKEUP,
+SET_WAKEUP_SOURCE,
+SYSTEM_SHUTDOWN,
+/* API for managing PM slaves: */
+REQUEST_NODE,
+RELEASE_NODE,
+SET_REQUIREMENT,
+SET_MAX_LATENCY,
+/* Direct control API functions: */
+RESET_ASSERT,
+RESET_GET_STATUS,
+MMIO_WRITE,
+MMIO_READ,
+PM_INIT,
+FPGA_LOAD,
+FPGA_GET_STATUS,
+GET_CHIPID,
+};
+
 static const char * const zynqmp_dt_compat[] __initconst =
 {
 "xlnx,zynqmp",
@@ -32,8 +72,31 @@ static const struct dt_device_match zynqmp_blacklist_dev[] 
__initconst =
 { /* sentinel */ },
 };
 
+bool zynqmp_hvc(struct cpu_user_regs *regs)
+{
+uint32_t fid = regs->x0;
+uint32_t svc = fid & SVC_MASK;
+register_t ret[4];
+
+/* We only forward SiP service calls from the hw domain to firmware.  */
+if ( svc != SVC_SIP || !is_hardware_domain(current->domain) )
+return false;
+
+/* Forward the call.  */
+call_smcc64(regs->x0, regs->x1, regs->x2, regs->x3,
+regs->x4, regs->x5, regs->x6, ret);
+
+/* Transfer return values into guest registers.  */
+regs->x0 = ret[0];
+regs->x1 = ret[1];
+regs->x2 = ret[2];
+regs->x3 = ret[3];
+return true;
+}
+
 PLATFORM_START(xgene_storm, "Xilinx ZynqMP")
 .compatible = zynqmp_dt_compat,
+.hvc = zynqmp_hvc,
 .blacklist_dev = zynqmp_blacklist_dev,
 PLATFORM_END
 
-- 
2.7.4


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

[Xen-devel] [RFC v1 6/6] xen/arm: zynqmp: Remove blacklist of ZynqMP's PM node

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

Stop blacklisting ZynqMP's power management node.
This is now possible since we allow the hardware domain to
issue HVC/SMC calls to firmware.

Signed-off-by: Edgar E. Iglesias 
---
 xen/arch/arm/platforms/xilinx-zynqmp.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/xen/arch/arm/platforms/xilinx-zynqmp.c 
b/xen/arch/arm/platforms/xilinx-zynqmp.c
index bde7f52..d21bd87 100644
--- a/xen/arch/arm/platforms/xilinx-zynqmp.c
+++ b/xen/arch/arm/platforms/xilinx-zynqmp.c
@@ -65,13 +65,6 @@ static const char * const zynqmp_dt_compat[] __initconst =
 NULL
 };
 
-static const struct dt_device_match zynqmp_blacklist_dev[] __initconst =
-{
-/* Power management is not yet supported.  */
-DT_MATCH_COMPATIBLE("xlnx,zynqmp-pm"),
-{ /* sentinel */ },
-};
-
 bool zynqmp_hvc(struct cpu_user_regs *regs)
 {
 uint32_t fid = regs->x0;
@@ -97,7 +90,6 @@ bool zynqmp_hvc(struct cpu_user_regs *regs)
 PLATFORM_START(xgene_storm, "Xilinx ZynqMP")
 .compatible = zynqmp_dt_compat,
 .hvc = zynqmp_hvc,
-.blacklist_dev = zynqmp_blacklist_dev,
 PLATFORM_END
 
 /*
-- 
2.7.4


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

[Xen-devel] [RFC v1 4/6] xen/arm: Introduce call_smcc64

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

Introduce call_smcc64, a helper function to issue 64-bit SMC
calls that follow the SMC Calling Convention. This includes
returning up to 4 64-bit values.

Signed-off-by: Edgar E. Iglesias 
---
 xen/include/asm-arm/processor.h | 40 
 1 file changed, 40 insertions(+)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index afc0e9a..a604f8c 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -706,6 +706,46 @@ void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
 int call_smc(register_t function_id, register_t arg0, register_t arg1,
  register_t arg2);
 
+/*
+ * Helper to issue a 64-bit SMC according to the SMC Calling Convention.
+ *
+ * @fid:  Function Identifier
+ * @a0 - a5:  6 arguments
+ * @ret:  Pointer to 4 register_t carrying return values
+ */
+static inline register_t call_smcc64(register_t fid,
+ register_t a0,
+ register_t a1,
+ register_t a2,
+ register_t a3,
+ register_t a4,
+ register_t a5,
+ register_t *ret)
+{
+register register_t x0 asm("x0") = fid;
+register register_t x1 asm("x1") = a0;
+register register_t x2 asm("x2") = a1;
+register register_t x3 asm("x3") = a2;
+register register_t x4 asm("x4") = a3;
+register register_t x5 asm("x5") = a4;
+register register_t x6 asm("x6") = a5;
+
+asm volatile ("smc #0\n"
+  : "+r" (x0), "+r" (x1), "+r" (x2), "+r" (x3),
+"+r" (x4), "+r" (x5), "+r" (x6)
+  :
+  : "x7", "x8", "x9", "x10", "x11", "x12",
+"x13", "x14", "x15", "x16", "x17" );
+
+if (ret) {
+ret[0] = x0;
+ret[1] = x1;
+ret[2] = x2;
+ret[3] = x3;
+}
+return x0;
+}
+
 void do_trap_guest_error(struct cpu_user_regs *regs);
 
 #endif /* __ASSEMBLY__ */
-- 
2.7.4


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

[Xen-devel] [RFC v1 0/6] zynqmp: Add forwarding of platform specific firmware calls

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

The ZynqMP software stack has an extensive Firmware API.
Software at EL1 is increasingly dependant on this API. In fact,
a large set of use-cases for Linux already require access
to firmware. In a couple of months, we expect that most setups
will need it, so this is becoming somewhat urgent.

Services provided by the API, among other things include:
* Clock Management
* PHY Configuration
* Power Management
* FPGA configuration
* etc

Adding support for accessing firmware comes in two steps.

1. Allow the hw domain (dom0) to call into firmware. This enables
   all devices to work with PV setups.

2. Allow other guests to use the Firmware API. This will be needed
   to fully support Device pass-through.
   We cannot give un-supervised access to unprivileged guests, so
   the idea is to mediate these calls in Xen or preferably in
   dom0. Mediation mainly consists of ref-counting and filtering.

This RFC patch series implements step #1.

There are quite a few options on how to implement step #2, e.g:
1. Trap HVC/SMC calls from unpriv guests and handle them in dom0.
   This could be done in a user-space agent.
2. Add a PV protocol carrying these calls. This is similar to #1.
3. Add several generic PV protocols carrying a set of platform independent
   generic calls that get translated or mapped to firmware calls
   in dom0. E.g PV-Clock, PV-Power, PV-FPGA.
4. Others??

A benefit with #1 is that we could support unmodified bare-metal
guests. Such guests would continue to issue SMC calls from EL1 just as
if they were running without a hypervisor.

Best regards,
Edgar

Edgar E. Iglesias (6):
  xen/arm: traps: Reorder early overwrite of FID
  xen/arm: Introduce platform_hvc
  xen/arm: Allow platform_hvc to handle guest SMC calls
  xen/arm: Introduce call_smcc64
  xen/arm: zynqmp: Forward plaform specific firmware calls
  xen/arm: zynqmp: Remove blacklist of ZynqMP's PM node

 xen/arch/arm/platform.c|  8 
 xen/arch/arm/platforms/xilinx-zynqmp.c | 67 +++---
 xen/arch/arm/traps.c   | 13 ++-
 xen/include/asm-arm/platform.h |  5 +++
 xen/include/asm-arm/processor.h| 40 
 5 files changed, 125 insertions(+), 8 deletions(-)

-- 
2.7.4


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

[Xen-devel] [RFC v1 2/6] xen/arm: Introduce platform_hvc

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

Introduce platform_hvc as a way to handle hypercalls that
Xen does not know about in a platform specific way. This
is particularly useful for implementing the SiP (SoC
implementation specific) service calls.

Signed-off-by: Edgar E. Iglesias 
---
 xen/arch/arm/platform.c| 8 
 xen/arch/arm/traps.c   | 3 +++
 xen/include/asm-arm/platform.h | 5 +
 3 files changed, 16 insertions(+)

diff --git a/xen/arch/arm/platform.c b/xen/arch/arm/platform.c
index 0af6d57..90ea6b8 100644
--- a/xen/arch/arm/platform.c
+++ b/xen/arch/arm/platform.c
@@ -127,6 +127,14 @@ void platform_poweroff(void)
 platform->poweroff();
 }
 
+bool platform_hvc(struct cpu_user_regs *regs)
+{
+if ( platform && platform->hvc )
+return platform->hvc(regs);
+
+return false;
+}
+
 bool_t platform_has_quirk(uint32_t quirk)
 {
 uint32_t quirks = 0;
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index a5fbf1e..e8cd111 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "decode.h"
 #include "vtimer.h"
@@ -1429,6 +1430,8 @@ static void do_trap_psci(struct cpu_user_regs *regs)
 }
 break;
 default:
+if ( platform_hvc(regs) )
+return;
 domain_crash_synchronous();
 return;
 }
diff --git a/xen/include/asm-arm/platform.h b/xen/include/asm-arm/platform.h
index 08010ba..4d51f0a 100644
--- a/xen/include/asm-arm/platform.h
+++ b/xen/include/asm-arm/platform.h
@@ -26,6 +26,10 @@ struct platform_desc {
 void (*reset)(void);
 /* Platform power-off */
 void (*poweroff)(void);
+/* Platform specific HVC handler.
+ * Returns true if the call was handled and false if not.
+ */
+bool (*hvc)(struct cpu_user_regs *regs);
 /*
  * Platform quirks
  * Defined has a function because a platform can support multiple
@@ -55,6 +59,7 @@ int platform_cpu_up(int cpu);
 #endif
 void platform_reset(void);
 void platform_poweroff(void);
+bool platform_hvc(struct cpu_user_regs *regs);
 bool_t platform_has_quirk(uint32_t quirk);
 bool_t platform_device_is_blacklisted(const struct dt_device_node *node);
 
-- 
2.7.4


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

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

[Tamas K Lengyel]

On Mon, Jan 30, 2017 at 9:01 AM, Julien Grall  wrote:
> Hi Stefano,
>
> On 27/01/17 23:53, Stefano Stabellini wrote:
>>
>> On Fri, 27 Jan 2017, Julien Grall wrote:
>>>
>>> On 27/01/2017 20:41, Stefano Stabellini wrote:

 On Fri, 27 Jan 2017, Tamas K Lengyel wrote:
>>>
>>> For the second instance, we have no other choice.
>>
>>
>> Most alloc_heap_pages (alloc_xenheap_pages and alloc_domheap_pages) are
>> done at domain initialization, so they would also be taken care by
>> flushing the instruction cache before the domain is running. There are
>> only very few exceptions to that, the main one being ballooning, and we
>> need another icache flush in that case. But I think we should avoid
>> doing global icache flushes every time alloc_heap_pages is called.
>
>
> The invalidation of the full icache is unfortunate but necessary in non-PIPT
> cache. For PIPT cache you could do invalidation by VA.
>
> Limiting the number of call is a nice optimization, but we need to be
> careful how to do it. Until then, a full icache invalidation (or by VA for
> PIPT) is the best solution.
>
 I am also wondering about all the libxc/libxl callers, many of whom
 don't need an icache flush. Ideally we would have an argument in
 XEN_DOMCTL_cacheflush to specify the type of cache flush we need,
 similar to GNTTABOP_cache_flush.
>>>
>>>
>>> Unless the instruction cache will be flushed before the guest is booting,
>>> all
>>> the callers of DOMCTL_cacheflush will require the invalidation.
>>
>>
>> DOMCTL_cacheflush is called several time during the domain build, it is
>> certainly better to do the icache flush once, rather than many times.
>>
>> If we decide to perform one icache flush at domain creation in Xen at
>> the right time, we still need XEN_DOMCTL_cacheflush in its current form
>> to flush the dcache.
>>
>> Also we still need a way to flush the icache to solve Tamas' problem
>> with mem_access at run time.
>>
>> As a consequence, even after introducing one icache flush in Xen at
>> domain creation, I think we still need a new "icache flush" flag in
>> XEN_DOMCTL_cacheflush: all the current callers would not use it, but
>> mem_access userspace components will be able to use it.
>
>
> Why do we need a flag? No matter the way the flag is defined (set -> icache
> invalidation vs set -> no icache invalidation), a user will likely misuse
> it. The hypervisor is the best person to decide whether the icache flush is
> needed. Aside at domain building time, 99.9% (to not say 100%) of the call
> to cacheflush will require the invalidation of the icache.
>
> Furthermore, if you implement the optimization for invalidating PIP icache
> (e.g by VA rather than full), a user will not have the possibility to
> invalidate the full icache.
>
> So I would go the same way as it has been done for tlbflush (see bbb17f6
> "move TLB-flush filtering out into populate_physmap during vm creation").
> Let Xen decides when to optimize the invalidation.
>

Giving the user the option during the domctl to choose which cache to
flush I think would be fine. I would agree that the most likely case
is that both caches should be flushed at the same time, but who knows,
having the option may be useful for someone. At least the linux
syscall has that option as well
(http://man7.org/linux/man-pages/man2/cacheflush.2.html).

In any rate, I already made the patch that implements it:
https://github.com/tklengyel/xen/compare/icache?expand=1. Let me know
if you would want me to send it or not.

Thanks,
Tamas

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

Re: [Xen-devel] [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

[Vineeth Remanan Pillai]

On 01/30/2017 09:06 AM, Boris Ostrovsky wrote:

On 01/30/2017 11:47 AM, Vineeth Remanan Pillai wrote:


2. It tickles a latent bug during resume where the timer triggers
before we re-connect. The trouble is that we now try to dereference
queue->rx.sring which is NULL since we disconnect in
netfront_resume(). (Curiously, I only observe it with 32-bit guests)

I think we may hit this bug after removing the timer as well. We call
RING_PUSH_REQUESTS_AND_CHECK_NOTIFY soon after, which also dereference
queue->rx.sring.

If the timer is deleted in xennet_disconnect_backend() then why would
anyone be pushing anything to the backend after that?

Sorry, I got the ordering wrong. Thanks for the clarification..

Thanks,
Vineeth



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

Re: [Xen-devel] [PATCH] xen/p2m: Remove np2m-specific filter from generic p2m_flush_table

[Tamas K Lengyel]

Hi George,
yeap, this solves old mem_access settings being triggered when I
recreate altp2m views. Thanks!

On Mon, Jan 30, 2017 at 8:17 AM, George Dunlap  wrote:
> Commit 71bb7304e7a7a35ea6df4b0cedebc35028e4c159 added flushing of
> nested p2m tables whenever the host p2m table changed.  Unfortunately
> in the process, it added a filter to the generic p2m_flush_table()
> function so that the p2m would only be flushed if it was being used as
> a nested p2m.  This meant that the p2m was not being flushed at all
> for altp2m callers.
>
> Instead do the nested p2m filtering in p2m_flush_nestedp2m().
>
> NB that this is not a security issue: The only time this codepath is
> called is in cases where either nestedp2m or altp2m is enabled, and
> neither of them are in security support.
>
> Reported-by: Matt Leinhos 
> Signed-off-by: George Dunlap 
> ---
> I've smoke-tested this with nested virt and it seems to work fine.
> Matt / Tamas, could you test this with altp2m and see if it fixes your
> issue?

Tested-by: Tamas K Lengyel 

>
>
> CC: Liang Li 
> CC: Yang Zhang 
> CC: Tim Deegan 
> CC: Tamas K Lengyel 
> CC: Andrew Cooper 
> CC: Jan Beulich 
> CC: Matt Leinhos 
> ---
>  xen/arch/x86/mm/p2m.c | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index aa627d8..0849c6e 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -2048,12 +2048,6 @@ p2m_flush_table(struct p2m_domain *p2m)
>  ASSERT(page_list_empty(>pod.super));
>  ASSERT(page_list_empty(>pod.single));
>
> -if ( p2m->np2m_base == P2M_BASE_EADDR )
> -{
> -p2m_unlock(p2m);
> -return;
> -}
> -
>  /* This is no longer a valid nested p2m for any address space */
>  p2m->np2m_base = P2M_BASE_EADDR;
>
> @@ -2088,7 +2082,11 @@ p2m_flush_nestedp2m(struct domain *d)
>  {
>  int i;
>  for ( i = 0; i < MAX_NESTEDP2M; i++ )
> -p2m_flush_table(d->arch.nested_p2m[i]);
> +{
> +struct p2m_domain *p2m = d->arch.nested_p2m[i];
> +if ( p2m->np2m_base != P2M_BASE_EADDR )
> +p2m_flush_table(p2m);
> +}
>  }
>
>  struct p2m_domain *
> --
> 2.1.4
>

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

Re: [Xen-devel] [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

[Boris Ostrovsky]

On 01/30/2017 11:47 AM, Vineeth Remanan Pillai wrote:
>
>> 2. It tickles a latent bug during resume where the timer triggers
>> before we re-connect. The trouble is that we now try to dereference
>> queue->rx.sring which is NULL since we disconnect in
>> netfront_resume(). (Curiously, I only observe it with 32-bit guests)
> I think we may hit this bug after removing the timer as well. We call
> RING_PUSH_REQUESTS_AND_CHECK_NOTIFY soon after, which also dereference
> queue->rx.sring.


If the timer is deleted in xennet_disconnect_backend() then why would
anyone be pushing anything to the backend after that?

-boris

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

[Xen-devel] [PATCH 2/2] x86/vmx: Drop ept_get_*() helpers

[Andrew Cooper]

The ept_get_*() helpers are not used consistently, and are more verbose than
the code they wrap.  Drop the wrappers and use the internal union names
consistently.

While making these adjustments, drop the redundant ept_* prefix from mt, wl
and ad, and rename the asr field to mfn for consistency with Xen's existing
terminology.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: George Dunlap 
CC: Jun Nakajima 
CC: Kevin Tian 
---
 xen/arch/x86/hvm/vmx/vmcs.c|  6 +++---
 xen/arch/x86/hvm/vmx/vmx.c |  6 +++---
 xen/arch/x86/hvm/vmx/vvmx.c|  9 +++-
 xen/arch/x86/mm/p2m-ept.c  | 44 +++---
 xen/include/asm-x86/hvm/vmx/vmcs.h | 16 ++
 5 files changed, 37 insertions(+), 44 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 59ef199..3fe1783 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1247,8 +1247,8 @@ static int construct_vmcs(struct vcpu *v)
 struct p2m_domain *p2m = p2m_get_hostp2m(d);
 struct ept_data *ept = >ept;
 
-ept->asr  = pagetable_get_pfn(p2m_get_pagetable(p2m));
-__vmwrite(EPT_POINTER, ept_get_eptp(ept));
+ept->mfn = pagetable_get_pfn(p2m_get_pagetable(p2m));
+__vmwrite(EPT_POINTER, ept->eptp);
 }
 
 if ( paging_mode_hap(d) )
@@ -1593,7 +1593,7 @@ void vmx_domain_update_eptp(struct domain *d)
 ASSERT(atomic_read(>pause_count));
 
 for_each_vcpu ( d, v )
-vmx_vcpu_update_eptp(v, ept_get_eptp(>ept));
+vmx_vcpu_update_eptp(v, p2m->ept.eptp);
 
 ept_sync_domain(p2m);
 }
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index eca4f7d..9078cf9 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1996,11 +1996,11 @@ static void vmx_vcpu_update_eptp(struct vcpu *v)
 p2m = p2m_get_hostp2m(d);
 
 ept = >ept;
-ept->asr = pagetable_get_pfn(p2m_get_pagetable(p2m));
+ept->mfn = pagetable_get_pfn(p2m_get_pagetable(p2m));
 
 vmx_vmcs_enter(v);
 
-__vmwrite(EPT_POINTER, ept_get_eptp(ept));
+__vmwrite(EPT_POINTER, ept->eptp);
 
 if ( v->arch.hvm_vmx.secondary_exec_control &
  SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS )
@@ -3953,7 +3953,7 @@ void vmx_vmenter_helper(const struct cpu_user_regs *regs)
 if ( cpumask_test_cpu(cpu, ept->invalidate) )
 {
 cpumask_clear_cpu(cpu, ept->invalidate);
-__invept(INVEPT_SINGLE_CONTEXT, ept_get_eptp(ept), 0);
+__invept(INVEPT_SINGLE_CONTEXT, ept->eptp, 0);
 }
 }
 
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 9caebe5..5acb88a 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -1043,16 +1043,13 @@ uint64_t get_shadow_eptp(struct vcpu *v)
 struct p2m_domain *p2m = p2m_get_nestedp2m(v, np2m_base);
 struct ept_data *ept = >ept;
 
-ept->asr = pagetable_get_pfn(p2m_get_pagetable(p2m));
-return ept_get_eptp(ept);
+ept->mfn = pagetable_get_pfn(p2m_get_pagetable(p2m));
+return ept->eptp;
 }
 
 static uint64_t get_host_eptp(struct vcpu *v)
 {
-struct domain *d = v->domain;
-struct ept_data *ept_data = _get_hostp2m(d)->ept;
-
-return ept_get_eptp(ept_data);
+return p2m_get_hostp2m(v->domain)->ept.eptp;
 }
 
 static bool_t nvmx_vpid_enabled(const struct vcpu *v)
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 04878f5..6c1b835 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -430,7 +430,7 @@ static int ept_invalidate_emt_range(struct p2m_domain *p2m,
 int wrc, rc = 0, ret = GUEST_TABLE_MAP_FAILED;
 
 table = map_domain_page(_mfn(pagetable_get_pfn(p2m_get_pagetable(p2m;
-for ( i = ept_get_wl(>ept); i > target; --i )
+for ( i = p2m->ept.wl; i > target; --i )
 {
 ret = ept_next_level(p2m, 1, , _remainder, i);
 if ( ret == GUEST_TABLE_MAP_FAILED )
@@ -500,8 +500,8 @@ static int ept_invalidate_emt_range(struct p2m_domain *p2m,
 static int resolve_misconfig(struct p2m_domain *p2m, unsigned long gfn)
 {
 struct ept_data *ept = >ept;
-unsigned int level = ept_get_wl(ept);
-unsigned long mfn = ept_get_asr(ept);
+unsigned int level = ept->wl;
+unsigned long mfn = ept->mfn;
 ept_entry_t *epte;
 int wrc, rc = 0;
 
@@ -687,7 +687,7 @@ ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, 
mfn_t mfn,
  * 3. passing a valid order.
  */
 if ( ((gfn | mfn_x(mfn)) & ((1UL << order) - 1)) ||
- ((u64)gfn >> ((ept_get_wl(ept) + 1) * EPT_TABLE_ORDER)) ||
+ ((u64)gfn >> ((ept->wl + 1) * EPT_TABLE_ORDER)) ||
  (order % EPT_TABLE_ORDER) )
 return -EINVAL;
 
@@ -704,7 +704,7 @@ ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, 
mfn_t 

[Xen-devel] [PATCH 1/2] x86/vmx: Introduce a bitfield structure for EPT_VIOLATION EXIT_QUALIFICATIONs

[Andrew Cooper]

This results in rather more readable code.  No functional change.

All fields currently specified are included, but commented out as no support
for their use is present.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Jun Nakajima 
CC: Kevin Tian 
---
 xen/arch/x86/hvm/vmx/vmx.c| 41 ++-
 xen/include/asm-x86/hvm/vmx/vmx.h | 27 +++---
 2 files changed, 30 insertions(+), 38 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 8177401..eca4f7d 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2986,7 +2986,7 @@ static void vmx_wbinvd_intercept(void)
 wbinvd();
 }
 
-static void ept_handle_violation(unsigned long qualification, paddr_t gpa)
+static void ept_handle_violation(ept_qual_t q, paddr_t gpa)
 {
 unsigned long gla, gfn = gpa >> PAGE_SHIFT;
 mfn_t mfn;
@@ -3006,13 +3006,10 @@ static void ept_handle_violation(unsigned long 
qualification, paddr_t gpa)
  *   Volume 3C: System Programming Guide, Part 3
  */
 struct npfec npfec = {
-.read_access = !!(qualification & EPT_READ_VIOLATION) ||
-   !!(qualification & EPT_WRITE_VIOLATION),
-.write_access = !!(qualification & EPT_WRITE_VIOLATION),
-.insn_fetch = !!(qualification & EPT_EXEC_VIOLATION),
-.present = !!(qualification & (EPT_EFFECTIVE_READ |
-   EPT_EFFECTIVE_WRITE |
-   EPT_EFFECTIVE_EXEC))
+.read_access = q.read || q.write,
+.write_access = q.write,
+.insn_fetch = q.fetch,
+.present = q.eff_read || q.eff_write || q.eff_exec,
 };
 
 if ( tb_init_done )
@@ -3025,17 +3022,17 @@ static void ept_handle_violation(unsigned long 
qualification, paddr_t gpa)
 } _d;
 
 _d.gpa = gpa;
-_d.qualification = qualification;
+_d.qualification = q.raw;
 _d.mfn = mfn_x(get_gfn_query_unlocked(d, gfn, &_d.p2mt));
 
 __trace_var(TRC_HVM_NPF, 0, sizeof(_d), &_d);
 }
 
-if ( qualification & EPT_GLA_VALID )
+if ( q.gla_valid )
 {
 __vmread(GUEST_LINEAR_ADDRESS, );
 npfec.gla_valid = 1;
-if( qualification & EPT_GLA_FAULT )
+if( q.gla_fault )
 npfec.kind = npfec_kind_with_gla;
 else
 npfec.kind = npfec_kind_in_gpt;
@@ -3065,18 +3062,18 @@ static void ept_handle_violation(unsigned long 
qualification, paddr_t gpa)
 mfn = get_gfn_query_unlocked(d, gfn, );
 gprintk(XENLOG_ERR,
 "EPT violation %#lx (%c%c%c/%c%c%c) gpa %#"PRIpaddr" mfn %#lx type 
%i\n",
-qualification,
-(qualification & EPT_READ_VIOLATION) ? 'r' : '-',
-(qualification & EPT_WRITE_VIOLATION) ? 'w' : '-',
-(qualification & EPT_EXEC_VIOLATION) ? 'x' : '-',
-(qualification & EPT_EFFECTIVE_READ) ? 'r' : '-',
-(qualification & EPT_EFFECTIVE_WRITE) ? 'w' : '-',
-(qualification & EPT_EFFECTIVE_EXEC) ? 'x' : '-',
+q.raw,
+q.read  ? 'r' : '-',
+q.write ? 'w' : '-',
+q.fetch ? 'x' : '-',
+q.eff_read  ? 'r' : '-',
+q.eff_write ? 'w' : '-',
+q.eff_exec  ? 'x' : '-',
 gpa, mfn_x(mfn), p2mt);
 
 ept_walk_table(d, gfn);
 
-if ( qualification & EPT_GLA_VALID )
+if ( q.gla_valid )
 gprintk(XENLOG_ERR, " --- GLA %#lx\n", gla);
 
 domain_crash(d);
@@ -3792,11 +3789,11 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
 
 case EXIT_REASON_EPT_VIOLATION:
 {
-paddr_t gpa;
+paddr_t gpa; ept_qual_t q;
 
 __vmread(GUEST_PHYSICAL_ADDRESS, );
-__vmread(EXIT_QUALIFICATION, _qualification);
-ept_handle_violation(exit_qualification, gpa);
+__vmread(EXIT_QUALIFICATION, );
+ept_handle_violation(q, gpa);
 break;
 }
 
diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h 
b/xen/include/asm-x86/hvm/vmx/vmx.h
index 4bf4d50..00e6172 100644
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -578,22 +578,17 @@ void vmx_pi_hooks_assign(struct domain *d);
 void vmx_pi_hooks_deassign(struct domain *d);
 
 /* EPT violation qualifications definitions */
-#define _EPT_READ_VIOLATION 0
-#define EPT_READ_VIOLATION  (1UL<<_EPT_READ_VIOLATION)
-#define _EPT_WRITE_VIOLATION1
-#define EPT_WRITE_VIOLATION (1UL<<_EPT_WRITE_VIOLATION)
-#define _EPT_EXEC_VIOLATION 2
-#define EPT_EXEC_VIOLATION  (1UL<<_EPT_EXEC_VIOLATION)
-#define _EPT_EFFECTIVE_READ 3
-#define EPT_EFFECTIVE_READ  (1UL<<_EPT_EFFECTIVE_READ)
-#define _EPT_EFFECTIVE_WRITE4
-#define EPT_EFFECTIVE_WRITE (1UL<<_EPT_EFFECTIVE_WRITE)
-#define _EPT_EFFECTIVE_EXEC 5

Re: [Xen-devel] [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

[Vineeth Remanan Pillai]

On 01/29/2017 03:09 PM, Boris Ostrovsky wrote:


There are couple of problems with this patch.
1. The 'if' clause now evaluates to true on pretty much every call to 
xennet_alloc_rx_buffers().
Thanks for catching this. In my testing I did not notice this - mostly 
because of the nature of the workload in my testing.


2. It tickles a latent bug during resume where the timer triggers 
before we re-connect. The trouble is that we now try to dereference 
queue->rx.sring which is NULL since we disconnect in 
netfront_resume(). (Curiously, I only observe it with 32-bit guests)
I think we may hit this bug after removing the timer as well. We call 
RING_PUSH_REQUESTS_AND_CHECK_NOTIFY soon after, which also dereference 
queue->rx.sring.


Thanks,
Vineeth


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

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

[osstest service owner]

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

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   5 xen-buildfail   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  5a77ccf609da289131bd1664ee20c17b1f9bb93c
baseline version:
 xen  7a4cf23e2653e8abf4793820487df32b094de56a

Last test of basis   105009  2017-01-30 12:06:27 Z0 days
Testing same since   105021  2017-01-30 15:02:49 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Paul Durrant 

jobs:
 build-amd64  pass
 build-arm64  fail
 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=5a77ccf609da289131bd1664ee20c17b1f9bb93c
+ . ./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 
5a77ccf609da289131bd1664ee20c17b1f9bb93c
+ branch=xen-unstable-smoke
+ revision=5a77ccf609da289131bd1664ee20c17b1f9bb93c
+ . ./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
+ '[' x5a77ccf609da289131bd1664ee20c17b1f9bb93c = 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] Xen 4.9 Development Update

[Wei Liu]

On Mon, Jan 30, 2017 at 03:33:19PM +, Julien Grall wrote:
> 
> == Testing == 
> 
> *  Continuous fuzzing of Xen code using Google oss-fuzz
>   -  Wei Liu
> 

Stuck as we need someone to write the code to integrate things into
oss-fuzz.

Wei.

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

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

[Julien Grall]

Hi Stefano,

On 27/01/17 23:53, Stefano Stabellini wrote:

On Fri, 27 Jan 2017, Julien Grall wrote:

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

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

For the second instance, we have no other choice.


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


The invalidation of the full icache is unfortunate but necessary in 
non-PIPT cache. For PIPT cache you could do invalidation by VA.


Limiting the number of call is a nice optimization, but we need to be 
careful how to do it. Until then, a full icache invalidation (or by VA 
for PIPT) is the best solution.



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


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


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

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

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

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


Why do we need a flag? No matter the way the flag is defined (set -> 
icache invalidation vs set -> no icache invalidation), a user will 
likely misuse it. The hypervisor is the best person to decide whether 
the icache flush is needed. Aside at domain building time, 99.9% (to not 
say 100%) of the call to cacheflush will require the invalidation of the 
icache.


Furthermore, if you implement the optimization for invalidating PIP 
icache (e.g by VA rather than full), a user will not have the 
possibility to invalidate the full icache.


So I would go the same way as it has been done for tlbflush (see bbb17f6 
"move TLB-flush filtering out into populate_physmap during vm 
creation"). Let Xen decides when to optimize the invalidation.






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


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [Qemu-devel] [PATCH] xen: use qdev_unplug() insteda of g_free() in xen_pv_find_xendev()

[Juergen Gross]

On 30/01/17 16:46, Peter Maydell wrote:
> On 30 January 2017 at 15:14, Juergen Gross  wrote:
>> The error exits of xen_pv_find_xendev() free the new xen-device via
>> g_free() which is wrong.
>>
>> As the xen-device has been initialized as qdev it must be removed
>> via qdev_unplug().
>>
>> This bug has been introduced with commit 3a6c9172ac5951e6dac2b3f6
>> ("xen: create qdev for each backend device").
>>
>> Reported-by: Roger Pau Monné 
>> Tested-by: Roger Pau Monné 
>> Signed-off-by: Juergen Gross 
>> ---
>>  hw/xen/xen_backend.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
>> index d119004..030772b 100644
>> --- a/hw/xen/xen_backend.c
>> +++ b/hw/xen/xen_backend.c
>> @@ -145,7 +145,7 @@ static struct XenDevice *xen_be_get_xendev(const char 
>> *type, int dom, int dev,
>>  xendev->evtchndev = xenevtchn_open(NULL, 0);
>>  if (xendev->evtchndev == NULL) {
>>  xen_pv_printf(NULL, 0, "can't open evtchn device\n");
>> -g_free(xendev);
>> +qdev_unplug(>qdev, NULL);
>>  return NULL;
>>  }
>>  fcntl(xenevtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
>> @@ -155,7 +155,7 @@ static struct XenDevice *xen_be_get_xendev(const char 
>> *type, int dom, int dev,
>>  if (xendev->gnttabdev == NULL) {
>>  xen_pv_printf(NULL, 0, "can't open gnttab device\n");
>>  xenevtchn_close(xendev->evtchndev);
>> -g_free(xendev);
>> +qdev_unplug(>qdev, NULL);
>>  return NULL;
>>  }
>>  } else {
> 
> I think this will leak memory (and that we're already leaking
> memory), because the code is creating the xendev with
> xendev = g_malloc0(ops->size);
> object_initialize(>qdev, ops->size, TYPE_XENBACKEND);
> 
> This is saying "I own and am responsible for freeing the memory
> that the device object lives in". If you want the object system
> to handle freeing the memory for you when the reference count
> goes to zero, then you need to create it with
>xendev = object_new()
> which we can't do here because we're allocating ops->size bytes
> rather than just the size of the object type.
> 
> Two options I think:
>  (1) have your code do
> OBJECT(xendev)->free = g_free;
>  after the object_initialize (to tell the object system how
> to free this object)
>  (2) call both qdev_unplug and g_free
> 
> I think (1) is better because it will definitely work even
> if the qdev bus system is holding on to an object reference
> after it returns from qdev_unplug() for some reason, and
> it will also mean we free the memory when we do a
> qdev_unplug in xen_pv_del_xendev(), rather than leaking it.

I agree. I'll send V2 with (1) included.

> Side note: Using DEVICE(xendev) is better QOM style than
> >qdev.

Okay. Will change.

Thanks for the very precise description.


Juergen


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

Re: [Xen-devel] [Qemu-devel] [PATCH] xen: use qdev_unplug() insteda of g_free() in xen_pv_find_xendev()

[Peter Maydell]

On 30 January 2017 at 15:14, Juergen Gross  wrote:
> The error exits of xen_pv_find_xendev() free the new xen-device via
> g_free() which is wrong.
>
> As the xen-device has been initialized as qdev it must be removed
> via qdev_unplug().
>
> This bug has been introduced with commit 3a6c9172ac5951e6dac2b3f6
> ("xen: create qdev for each backend device").
>
> Reported-by: Roger Pau Monné 
> Tested-by: Roger Pau Monné 
> Signed-off-by: Juergen Gross 
> ---
>  hw/xen/xen_backend.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
> index d119004..030772b 100644
> --- a/hw/xen/xen_backend.c
> +++ b/hw/xen/xen_backend.c
> @@ -145,7 +145,7 @@ static struct XenDevice *xen_be_get_xendev(const char 
> *type, int dom, int dev,
>  xendev->evtchndev = xenevtchn_open(NULL, 0);
>  if (xendev->evtchndev == NULL) {
>  xen_pv_printf(NULL, 0, "can't open evtchn device\n");
> -g_free(xendev);
> +qdev_unplug(>qdev, NULL);
>  return NULL;
>  }
>  fcntl(xenevtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
> @@ -155,7 +155,7 @@ static struct XenDevice *xen_be_get_xendev(const char 
> *type, int dom, int dev,
>  if (xendev->gnttabdev == NULL) {
>  xen_pv_printf(NULL, 0, "can't open gnttab device\n");
>  xenevtchn_close(xendev->evtchndev);
> -g_free(xendev);
> +qdev_unplug(>qdev, NULL);
>  return NULL;
>  }
>  } else {

I think this will leak memory (and that we're already leaking
memory), because the code is creating the xendev with
xendev = g_malloc0(ops->size);
object_initialize(>qdev, ops->size, TYPE_XENBACKEND);

This is saying "I own and am responsible for freeing the memory
that the device object lives in". If you want the object system
to handle freeing the memory for you when the reference count
goes to zero, then you need to create it with
   xendev = object_new()
which we can't do here because we're allocating ops->size bytes
rather than just the size of the object type.

Two options I think:
 (1) have your code do
OBJECT(xendev)->free = g_free;
 after the object_initialize (to tell the object system how
to free this object)
 (2) call both qdev_unplug and g_free

I think (1) is better because it will definitely work even
if the qdev bus system is holding on to an object reference
after it returns from qdev_unplug() for some reason, and
it will also mean we free the memory when we do a
qdev_unplug in xen_pv_del_xendev(), rather than leaking it.

Side note: Using DEVICE(xendev) is better QOM style than
>qdev.

(The weirdness with doing a g_malloc0(ops->size) appears
to be because Xen backends have their own setup for saying
"allocate this many bytes for my data", rather than having
XenBlkDev, XenConsole, etc be QOM subclasses of XenDevice.
Presumably that code all predates QEMU's QOMification.)

We also do OBJECT(thing)->free = something in hw/core/sysbus.c;
maybe we should have a function to abstract this away?
Not sure.

thanks
-- PMM

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

Re: [Xen-devel] Xen 4.9 Development Update

[Wei Liu]

On Mon, Jan 30, 2017 at 03:32:49PM +, Julien Grall wrote:
[...]
> > > > 
> > > > I think it would be good to main two lists.  One of "the stuff people
> > > > are working on overall", and "the subset of it intended/expected for the
> > > > forthcoming release".
> > > > 
> > > > Stuff will invariably slip, but even if the work isn't intended for the
> > > > forthcoming release, it it still useful to see if anyone in the
> > > > community is working on a related topic.
> > > 
> > > I am thinking to re-introduce the state of a series (none, fair, ok, good,
> > > done) as it was done in the past [1].
> > > 
> > > "The states are: none -> fair -> ok -> good -> done
> > > 
> > > none - nothing yet
> > > fair - still working on it, patches are prototypes or RFC
> > > ok   - patches posted, acting on review
> > > good - some last minute pieces
> > > done - all done, might have bugs"
> > > 
> > 
> > We (I?) ditched them because they weren't that useful.  "None" is just
> > signalling of intent, which doesn't carry enough of meaningful
> > information.  "Fair", "ok" and "good" are all subjective -- we've seen
> > "good" series slipped due to last minute issues.
> > 
> > If we really want status, I would suggest more concrete status:
> > 
> >   design / design.vX -> rfc / rfc.vX -> wip / wip.vX -> committed
> > 
> > These are more tangible and objective.
> 
> I agree this is more objective but we loose the time estimation. The number
> of revisions sent depends a lot on the contributor, complexity of the
> series... So a series tagged wip.v5 might be in better shape of one tagged
> wip.v10.

Yes, that's true. I've given up on hoping a certain thing manage to get
in a certain release. This is just how open source software development
works -- upstream has no very limited leverage on what people do. :-)

The value of revision number, imo, is that it objectively indicate if a
project is going on well or not. Say, a project in rfc.v10 or wip.v25 is
definitely alarming -- we (RM and committers) probably need to do
something process-wise to get it back on track.  That probably includes
understanding the issues / disputes between parties, provide
suggestions, mediate and sometimes make difficult decisions on various
issues.

Wei.

> 
> Although, I don't have better idea so far.
> 
> Cheers,
> 
> -- 
> Julien Grall

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

[Xen-devel] [PATCH] xen/p2m: Remove np2m-specific filter from generic p2m_flush_table

[George Dunlap]

Commit 71bb7304e7a7a35ea6df4b0cedebc35028e4c159 added flushing of
nested p2m tables whenever the host p2m table changed.  Unfortunately
in the process, it added a filter to the generic p2m_flush_table()
function so that the p2m would only be flushed if it was being used as
a nested p2m.  This meant that the p2m was not being flushed at all
for altp2m callers.

Instead do the nested p2m filtering in p2m_flush_nestedp2m().

NB that this is not a security issue: The only time this codepath is
called is in cases where either nestedp2m or altp2m is enabled, and
neither of them are in security support.

Reported-by: Matt Leinhos 
Signed-off-by: George Dunlap 
---
I've smoke-tested this with nested virt and it seems to work fine.
Matt / Tamas, could you test this with altp2m and see if it fixes your
issue?


CC: Liang Li 
CC: Yang Zhang 
CC: Tim Deegan 
CC: Tamas K Lengyel 
CC: Andrew Cooper 
CC: Jan Beulich 
CC: Matt Leinhos 
---
 xen/arch/x86/mm/p2m.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index aa627d8..0849c6e 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2048,12 +2048,6 @@ p2m_flush_table(struct p2m_domain *p2m)
 ASSERT(page_list_empty(>pod.super));
 ASSERT(page_list_empty(>pod.single));
 
-if ( p2m->np2m_base == P2M_BASE_EADDR )
-{
-p2m_unlock(p2m);
-return;
-}
-
 /* This is no longer a valid nested p2m for any address space */
 p2m->np2m_base = P2M_BASE_EADDR;
 
@@ -2088,7 +2082,11 @@ p2m_flush_nestedp2m(struct domain *d)
 {
 int i;
 for ( i = 0; i < MAX_NESTEDP2M; i++ )
-p2m_flush_table(d->arch.nested_p2m[i]);
+{
+struct p2m_domain *p2m = d->arch.nested_p2m[i];
+if ( p2m->np2m_base != P2M_BASE_EADDR )
+p2m_flush_table(p2m);
+}
 }
 
 struct p2m_domain *
-- 
2.1.4


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

[Xen-devel] Xen 4.9 Development Update

[Julien Grall]

This email only tracks big items for xen.git tree. Please reply for items you
woulk like to see in 4.9 so that people have an idea what is going on and
prioritise accordingly.

You're welcome to provide description and use cases of the feature you're
working on.

= Timeline =

We now adopt a fixed cut-off date scheme. We will release twice a
year. The upcoming 4.9 timeline are as followed:

* Last posting date: March 17th, 2017
* Hard code freeze: March 31th, 2017
* RC1: TBD
* Release: June 2, 2017

Note that we don't have freeze exception scheme anymore. All patches
that wish to go into 4.9 must be posted no later than the last posting
date. All patches posted after that date will be automatically queued
into next release.

RCs will be arranged immediately after freeze.

= Projects =

== Hypervisor == 

*  Boot Xen on EFI platforms using GRUB2 (multiboot2 protocol)
  -  Daniel Kiper

*  Per-cpu tasklet
  -  Konrad Rzeszutek Wilk

=== x86 === 

*  Allow ioreq server interface to support XenGT
  -  Yu Zhang
  -  Paul Durrant

*  PVHv2 support
  -  Roger Pau Monne

*  vNVDIMM support
  -  Haozhong Zhang

*  Completion of the x86 insn emulator (as far as possible)
  -  Jan Beulich

*  Getting guest CPUID handling into a better shape
  -  Andrew Cooper

*  Enable L2 Cache Allocation Technology
  -  Yi Sun

*  Enable Memory Bandwidth Allocation
  -  Yi Sun

=== ARM === 

*  ITS emulation (Dom0 only)
  -  Andre Przywara

*  Altp2m for ARM
  -  Sergej Proskurin

*  Support Tegra SoCs
  -  Kyle Temkin

== Toolstack == 

*  Libxl PVSCSI support
  -  Olaf Hering

*  Libxl depriv QEMU
  -  Ian Jackson

*  Remove blktap2
  -  Wei Liu

== Mini-OS == 

== PV Drivers == 

*  Xen transport for 9pfs
  -  Stefano Stabellini

*  PV calls
  -  Stefano Stabellini

== GRUB == 

*  Support booting Xen ARM
  -  Fu Wei

== Testing == 

*  Continuous fuzzing of Xen code using Google oss-fuzz
  -  Wei Liu

== Blocker == 

*  Fix issues with zero-length records in migration v2
  Link: https://bugs.xenproject.org/xen/bug/56
  -  Andrew Cooper

== Completed == 

*  Rework gcov support in hypervisor
  -  Wei Liu

*  XenStore XS_DIRECTORY_PART extension
  -  Juergen Gross


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

Re: [Xen-devel] Xen 4.9 Development Update

[Julien Grall]

Hi,

On 26/01/17 17:06, Wei Liu wrote:

On Thu, Jan 26, 2017 at 12:27:15PM +, Julien Grall wrote:

Hi,

On 09/12/2016 19:09, Andrew Cooper wrote:

On 09/12/16 19:01, Stefano Stabellini wrote:

On Fri, 9 Dec 2016, Oleksandr Andrushchenko wrote:

On 12/09/2016 03:57 PM, Pasi Kärkkäinen wrote:

On Fri, Dec 09, 2016 at 02:57:04PM +0200, Oleksandr Andrushchenko wrote:

Should we have a section on new PV drivers? If so, I suggest to add:
- Xen transport for 9pfs
- PV Calls

Good idea. We could also include DRM and PV Sound (CC Oleksandr).


This is a great idea. Let me explain what we have and what the direction
is:
1. Frontends which we already have, working, but need to refactor/cleanup:
1.1. PV sound
1.2. PV DRM
1.3. DISPL protocol, I will push v1 for review right after sndif done
1.3. PV DRM mapper (Dom0 generic DRM driver to implement DRM zero copy
via DRM Prime buffer sharing)
1.4. PV events not done, but we are considering [1]. If it fits and
is maintained,
then we'll probably stick to it, otherwise new PV will be created

2. Backends, for the above frontends already implemented:
2.1. A unified library for Xen backends (libxenbe)
2.2. DRM + Wayland
2.3. ALSA
2.4. Events not implemented yet

All the above sources are available on *public* Github repos
(I can provide links on request) and the intention is to
upstream.


Please do post the links..

Please note these are all WIP:
1. Frontends
https://github.com/andr2000?tab=repositories
2. Backends
https://github.com/al1img?tab=repositories

Now, I don't want to sound pessimistic, but I thought I was being
audacious when I wrote both PV Calls and 9pfs for 4.9 - do you really
think it is feasable to complete upstreaming of PV sound, PV DRM, DISPL,
PV DRM frontends and backends, all by April? I would probably reduce the
list a bit.


I think it would be good to main two lists.  One of "the stuff people
are working on overall", and "the subset of it intended/expected for the
forthcoming release".

Stuff will invariably slip, but even if the work isn't intended for the
forthcoming release, it it still useful to see if anyone in the
community is working on a related topic.


I am thinking to re-introduce the state of a series (none, fair, ok, good,
done) as it was done in the past [1].

"The states are: none -> fair -> ok -> good -> done

none - nothing yet
fair - still working on it, patches are prototypes or RFC
ok   - patches posted, acting on review
good - some last minute pieces
done - all done, might have bugs"



We (I?) ditched them because they weren't that useful.  "None" is just
signalling of intent, which doesn't carry enough of meaningful
information.  "Fair", "ok" and "good" are all subjective -- we've seen
"good" series slipped due to last minute issues.

If we really want status, I would suggest more concrete status:

  design / design.vX -> rfc / rfc.vX -> wip / wip.vX -> committed

These are more tangible and objective.


I agree this is more objective but we loose the time estimation. The 
number of revisions sent depends a lot on the contributor, complexity of 
the series... So a series tagged wip.v5 might be in better shape of one 
tagged wip.v10.


Although, I don't have better idea so far.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] VT-d/RMRR: Avoid memory corruption in add_user_rmrr()

[Venu Busireddy]

Jan,

Sure. I will look in to it.

Venu


> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, January 30, 2017 04:39 AM
> To: Andrew Cooper; Elena Ufimtseva; Venu Busireddy
> Cc: Xen-devel
> Subject: Re: [PATCH] VT-d/RMRR: Avoid memory corruption in add_user_rmrr()
> 
> >>> On 30.01.17 at 11:10,  wrote:
> > register_one_rmrr() already frees its parameter if errors are
> encountered.
> >
> > Introduced by c/s 431685e8de and spotted by Coverity.
> >
> > Coverity-ID: 1399607
> > Signed-off-by: Andrew Cooper 
> 
> Reviewed-by: Jan Beulich 
> 
> I notice, however, that register_one_rmrr() returning success
> doesn't always mean success, so in non-debug builds we may be
> left without any log message here despite there being a problem
> with what the user specified. Elena, Venu, can you look into this
> please? Perhaps the function should return a positive value in
> that case, so that the original caller can retain its current behavior
> but the newly added caller can be adjusted?
> 
> Jan
> 
> > --- a/xen/drivers/passthrough/vtd/dmar.c
> > +++ b/xen/drivers/passthrough/vtd/dmar.c
> > @@ -975,13 +975,9 @@ static int __init add_user_rmrr(void)
> >  rmrr->scope.devices_cnt = user_rmrrs[i].dev_count;
> >
> >  if ( register_one_rmrr(rmrr) )
> > -{
> >  printk(XENLOG_ERR VTDPREFIX
> > "Could not register RMMR range "ERMRRU_FMT"\n",
> > ERMRRU_ARG(user_rmrrs[i]));
> > -scope_devices_free(>scope);
> > -xfree(rmrr);
> > -}
> >  }
> >
> >  return 0;
> > --
> > 2.1.4
> 
> 
> 

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

[Xen-devel] [PATCH] xen: use qdev_unplug() insteda of g_free() in xen_pv_find_xendev()

[Juergen Gross]

The error exits of xen_pv_find_xendev() free the new xen-device via
g_free() which is wrong.

As the xen-device has been initialized as qdev it must be removed
via qdev_unplug().

This bug has been introduced with commit 3a6c9172ac5951e6dac2b3f6
("xen: create qdev for each backend device").

Reported-by: Roger Pau Monné 
Tested-by: Roger Pau Monné 
Signed-off-by: Juergen Gross 
---
 hw/xen/xen_backend.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index d119004..030772b 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -145,7 +145,7 @@ static struct XenDevice *xen_be_get_xendev(const char 
*type, int dom, int dev,
 xendev->evtchndev = xenevtchn_open(NULL, 0);
 if (xendev->evtchndev == NULL) {
 xen_pv_printf(NULL, 0, "can't open evtchn device\n");
-g_free(xendev);
+qdev_unplug(>qdev, NULL);
 return NULL;
 }
 fcntl(xenevtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
@@ -155,7 +155,7 @@ static struct XenDevice *xen_be_get_xendev(const char 
*type, int dom, int dev,
 if (xendev->gnttabdev == NULL) {
 xen_pv_printf(NULL, 0, "can't open gnttab device\n");
 xenevtchn_close(xendev->evtchndev);
-g_free(xendev);
+qdev_unplug(>qdev, NULL);
 return NULL;
 }
 } else {
-- 
2.10.2


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

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

[Juergen Gross]

Instead of using the default resolution of 800*600 for the pointing
device of xen-kbdfront try to read the resolution of the (virtual)
framebuffer device. Use the default as fallback only.

Signed-off-by: Juergen Gross 
---
V3: add case of late framebuffer registration (Oleksandr Andrushchenko)
V2: get framebuffer resolution only if CONFIG_FB (Dmitry Torokhov)
---
 drivers/input/misc/xen-kbdfront.c | 46 ---
 1 file changed, 43 insertions(+), 3 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c 
b/drivers/input/misc/xen-kbdfront.c
index 3900875..9a20800 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -39,6 +40,9 @@ struct xenkbd_info {
int irq;
struct xenbus_device *xbdev;
char phys[32];
+#ifdef CONFIG_FB_NOTIFY
+   struct notifier_block nb;
+#endif
 };
 
 static int xenkbd_remove(struct xenbus_device *);
@@ -105,10 +109,29 @@ static irqreturn_t input_handler(int rq, void *dev_id)
return IRQ_HANDLED;
 }
 
+#ifdef CONFIG_FB
+#ifdef CONFIG_FB_NOTIFY
+static int xenkbd_fb_event(struct notifier_block *self,
+  unsigned long action, void *data)
+{
+   struct xenkbd_info *info = container_of(self, struct xenkbd_info, nb);
+   struct fb_info *fb = registered_fb[0];
+
+   if (action != FB_EVENT_FB_REGISTERED || !fb)
+   return 0;
+
+   input_set_abs_params(info->ptr, ABS_X, 0, fb->var.xres_virtual, 0, 0);
+   input_set_abs_params(info->ptr, ABS_Y, 0, fb->var.yres_virtual, 0, 0);
+
+   return 0;
+}
+#endif
+#endif
+
 static int xenkbd_probe(struct xenbus_device *dev,
  const struct xenbus_device_id *id)
 {
-   int ret, i;
+   int ret, i, width, height;
unsigned int abs;
struct xenkbd_info *info;
struct input_dev *kbd, *ptr;
@@ -173,9 +196,22 @@ static int xenkbd_probe(struct xenbus_device *dev,
ptr->id.product = 0xfffe;
 
if (abs) {
+   width = XENFB_WIDTH;
+   height = XENFB_HEIGHT;
+#ifdef CONFIG_FB
+   if (registered_fb[0]) {
+   width = registered_fb[0]->var.xres_virtual;
+   height = registered_fb[0]->var.yres_virtual;
+   } else {
+#ifdef CONFIG_FB_NOTIFY
+   info->nb.notifier_call = xenkbd_fb_event;
+   fb_register_client(>nb);
+#endif
+   }
+#endif
__set_bit(EV_ABS, ptr->evbit);
-   input_set_abs_params(ptr, ABS_X, 0, XENFB_WIDTH, 0, 0);
-   input_set_abs_params(ptr, ABS_Y, 0, XENFB_HEIGHT, 0, 0);
+   input_set_abs_params(ptr, ABS_X, 0, width, 0, 0);
+   input_set_abs_params(ptr, ABS_Y, 0, height, 0, 0);
} else {
input_set_capability(ptr, EV_REL, REL_X);
input_set_capability(ptr, EV_REL, REL_Y);
@@ -222,6 +258,10 @@ static int xenkbd_remove(struct xenbus_device *dev)
struct xenkbd_info *info = dev_get_drvdata(>dev);
 
xenkbd_disconnect_backend(info);
+#ifdef CONFIG_FB_NOTIFY
+   if (info->nb.notifier_call)
+   fb_unregister_client(>nb);
+#endif
if (info->kbd)
input_unregister_device(info->kbd);
if (info->ptr)
-- 
2.10.2


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

[Xen-devel] [PATCH] xl: Fix assertion on domain reboot with new configuration

[Fatih Acar]

libxl_domain_build_info_dispose is not resetting the type field to 
LIBXL_DOMAIN_TYPE_INVALID.
Instead, it is memseting the struct to 0 thus when 
libxl_domain_build_info_init_type is called
after a dispose on the same struct, an assertion is triggered because type != 
LIBXL_DOMAIN_TYPE_INVALID.
Calling libxl_domain_build_info_init makes sure the type field is correctly 
initialized.

Signed-off-by: Fatih Acar 
Signed-off-by: Nikita Kozlov 
Signed-off-by: Vincent Legout 
Signed-off-by: Baptiste Daroussin 
---
 tools/libxl/xl_cmdimpl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 7e8a8ae..196b8a6 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2535,6 +2535,7 @@ static void reload_domain_config(uint32_t domid,
 if (t_len > 0) {
 LOG("\"xl\" configuration found, using it\n");
 libxl_domain_config_dispose(d_config);
+libxl_domain_config_init(d_config);
 parse_config_data("", (const char *)t_data,
   t_len, d_config);
 free(t_data);
-- 
bapt is my cto


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

[Xen-devel] [PATCH] xl: Fix segfault on domain reboot

[Fatih Acar]

If we have no disk attached at startup, diskws is left unallocated
but `d_config.num_disks` may change if we attach a disk later.
When a domain is rebooted `evdisable_disk_ejects` is called
this will later result in a segfault if num_disks has changed.

Expand diskws when num_disks increases.

Signed-off-by: Fatih Acar 
Signed-off-by: Nikita Kozlov 
Signed-off-by: Vincent Legout 
Signed-off-by: Baptiste Daroussin 
---
 tools/libxl/xl_cmdimpl.c | 34 --
 1 file changed, 28 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 7e8a8ae..f244e63 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2517,13 +2517,25 @@ skip_usbdev:
 xlu_cfg_destroy(config);
 }
 
+static void realloc_diskws(libxl_evgen_disk_eject ***diskws, int old_count, 
int new_count)
+{
+libxl_evgen_disk_eject **diskws_new;
+
+diskws_new = xcalloc(new_count, sizeof(*diskws_new));
+memcpy(diskws_new, *diskws, sizeof(**diskws) * old_count);
+free(*diskws);
+*diskws = diskws_new;
+}
+
 static void reload_domain_config(uint32_t domid,
- libxl_domain_config *d_config)
+ libxl_domain_config *d_config,
+ libxl_evgen_disk_eject ***diskws)
 {
 int rc;
 uint8_t *t_data;
 int ret, t_len;
 libxl_domain_config d_config_new;
+int disk_count;
 
 /* In case user has used "config-update" to store a new config
  * file.
@@ -2534,9 +2546,14 @@ static void reload_domain_config(uint32_t domid,
 }
 if (t_len > 0) {
 LOG("\"xl\" configuration found, using it\n");
+disk_count = d_config->num_disks;
 libxl_domain_config_dispose(d_config);
 parse_config_data("", (const char *)t_data,
   t_len, d_config);
+if (d_config->num_disks > disk_count) {
+/* reallocate bigger diskws */
+realloc_diskws(diskws, disk_count, d_config->num_disks);
+}
 free(t_data);
 libxl_userdata_unlink(ctx, domid, "xl");
 return;
@@ -2549,6 +2566,10 @@ static void reload_domain_config(uint32_t domid,
 "reusing old configuration", rc);
 libxl_domain_config_dispose(_config_new);
 } else {
+if (d_config_new.num_disks > d_config->num_disks) {
+/* reallocate bigger diskws */
+realloc_diskws(diskws, d_config->num_disks, 
d_config_new.num_disks);
+}
 libxl_domain_config_dispose(d_config);
 /* Steal allocations */
 memcpy(d_config, _config_new, sizeof(libxl_domain_config));
@@ -2558,7 +2579,8 @@ static void reload_domain_config(uint32_t domid,
 /* Can update r_domid if domain is destroyed */
 static domain_restart_type handle_domain_death(uint32_t *r_domid,
libxl_event *event,
-   libxl_domain_config *d_config)
+   libxl_domain_config *d_config,
+   libxl_evgen_disk_eject 
***diskws)
 {
 domain_restart_type restart = DOMAIN_RESTART_NONE;
 libxl_action_on_shutdown action;
@@ -2614,12 +2636,12 @@ static domain_restart_type handle_domain_death(uint32_t 
*r_domid,
 break;
 
 case LIBXL_ACTION_ON_SHUTDOWN_RESTART_RENAME:
-reload_domain_config(*r_domid, d_config);
+reload_domain_config(*r_domid, d_config, diskws);
 restart = DOMAIN_RESTART_RENAME;
 break;
 
 case LIBXL_ACTION_ON_SHUTDOWN_RESTART:
-reload_domain_config(*r_domid, d_config);
+reload_domain_config(*r_domid, d_config, diskws);
 restart = DOMAIN_RESTART_NORMAL;
 /* fall-through */
 case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
@@ -2630,7 +2652,7 @@ static domain_restart_type handle_domain_death(uint32_t 
*r_domid,
 break;
 
 case LIBXL_ACTION_ON_SHUTDOWN_SOFT_RESET:
-reload_domain_config(*r_domid, d_config);
+reload_domain_config(*r_domid, d_config, diskws);
 restart = DOMAIN_RESTART_SOFT_RESET;
 break;
 
@@ -3137,7 +3159,7 @@ start:
 LOG("Domain %u has shut down, reason code %d 0x%x", domid,
 event->u.domain_shutdown.shutdown_reason,
 event->u.domain_shutdown.shutdown_reason);
-switch (handle_domain_death(, event, _config)) {
+switch (handle_domain_death(, event, _config, )) {
 case DOMAIN_RESTART_SOFT_RESET:
 domid_soft_reset = domid;
 domid = INVALID_DOMID;
-- 
bapt is my cto


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

Re: [Xen-devel] [PATCH 3/7] x86: extract macros to x86-defns.h

[Wei Liu]

On Mon, Jan 30, 2017 at 07:24:57AM -0700, Jan Beulich wrote:
> >>> On 30.01.17 at 15:17,  wrote:
> > On Mon, Jan 30, 2017 at 07:14:23AM -0700, Jan Beulich wrote:
> >> >>> On 30.01.17 at 13:46,  wrote:
> >> > On Mon, Jan 30, 2017 at 12:32:27PM +, Wei Liu wrote:
> >> >> On Thu, Jan 26, 2017 at 03:55:27AM -0700, Jan Beulich wrote:
> >> >> > >>> On 25.01.17 at 16:44,  wrote:
> >> >> > > ... so that they can be used by userspace x86 instruction emulator 
> >> >> > > test
> >> >> > > program and fuzzer as well.
> >> >> > 
> >> >> > Ah, here we go. This should be patch 2 then imo.
> >> >> > 
> >> >> > > --- /dev/null
> >> >> > > +++ b/xen/include/asm-x86/x86-defns.h
> >> >> > > @@ -0,0 +1,125 @@
> >> >> > > +#ifndef __XEN_X86_DEFNS_H__
> >> >> > > +#define __XEN_X86_DEFNS_H__
> >> >> > > +
> >> >> > > +/*
> >> >> > > + * CPU vendor IDs
> >> >> > > + */
> >> >> > > +#define X86_VENDOR_INTEL 0
> >> >> > > +#define X86_VENDOR_AMD 1
> >> >> > > +#define X86_VENDOR_CENTAUR 2
> >> >> > > +#define X86_VENDOR_NUM 3
> >> >> > > +#define X86_VENDOR_UNKNOWN 0xff
> >> >> > 
> >> >> > Let's strictly separate things: These aren't architectural 
> >> >> > definitions,
> >> >> > so should - if we really mean to share them - go into another header.
> >> >> > I'm not sure though whether sharing these is all that useful.
> >> >> 
> >> >> Actually I don't think these are needed.
> >> >> 
> >> >> I moved them because there were duplicates in x86emul/test. But after
> >> >> having a closer look those duplicates are not used.
> >> > 
> >> > Spoke too soon. I only grepped for X86_VENDOR_INTEL and came to that
> >> > conclusion. Actually X86_VENDOR_AMD is used in
> >> > x86_emualte/x86_emualte.c and X86_VENDOR_UNKNOWN in test_x86_emulate.c.
> >> > 
> >> > I propose we move these to x86-vendors.h. What do you think?
> >> 
> >> Well, if you really think moving them is useful, then the header name
> >> would be fine. But as said, I don't really see the point.
> > 
> > Yes, I think that's going to be useful because that allows emulator
> > compiles in both xen and userspace harness. The other route is to
> > disentangle some more code to achieve the same effect. But since you
> > don't object to the proposed approach, I would avoid the more
> > complicated route.
> 
> Just to clarify - the main reason for me not really liking the idea is
> that (other than the architecture defines) the X86_VENDOR_*
> values have no need to be in sync (regarding their values) in
> hypervisor and test harness. All we need is for constants of that
> name (with whatever values) to be in scope. And that's being
> achieved by current code already.
> 

That's true. And I understand that.

My idea is that I want to avoid unnecessary duplication to reduce the
distraction when one needs to modify userspace test harness. If there is
already definitions in xen, I will just use that.

Wei.

> Jan
> 

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

Re: [Xen-devel] [PATCH 3/7] x86: extract macros to x86-defns.h

[Jan Beulich]

>>> On 30.01.17 at 15:17,  wrote:
> On Mon, Jan 30, 2017 at 07:14:23AM -0700, Jan Beulich wrote:
>> >>> On 30.01.17 at 13:46,  wrote:
>> > On Mon, Jan 30, 2017 at 12:32:27PM +, Wei Liu wrote:
>> >> On Thu, Jan 26, 2017 at 03:55:27AM -0700, Jan Beulich wrote:
>> >> > >>> On 25.01.17 at 16:44,  wrote:
>> >> > > ... so that they can be used by userspace x86 instruction emulator 
>> >> > > test
>> >> > > program and fuzzer as well.
>> >> > 
>> >> > Ah, here we go. This should be patch 2 then imo.
>> >> > 
>> >> > > --- /dev/null
>> >> > > +++ b/xen/include/asm-x86/x86-defns.h
>> >> > > @@ -0,0 +1,125 @@
>> >> > > +#ifndef __XEN_X86_DEFNS_H__
>> >> > > +#define __XEN_X86_DEFNS_H__
>> >> > > +
>> >> > > +/*
>> >> > > + * CPU vendor IDs
>> >> > > + */
>> >> > > +#define X86_VENDOR_INTEL 0
>> >> > > +#define X86_VENDOR_AMD 1
>> >> > > +#define X86_VENDOR_CENTAUR 2
>> >> > > +#define X86_VENDOR_NUM 3
>> >> > > +#define X86_VENDOR_UNKNOWN 0xff
>> >> > 
>> >> > Let's strictly separate things: These aren't architectural definitions,
>> >> > so should - if we really mean to share them - go into another header.
>> >> > I'm not sure though whether sharing these is all that useful.
>> >> 
>> >> Actually I don't think these are needed.
>> >> 
>> >> I moved them because there were duplicates in x86emul/test. But after
>> >> having a closer look those duplicates are not used.
>> > 
>> > Spoke too soon. I only grepped for X86_VENDOR_INTEL and came to that
>> > conclusion. Actually X86_VENDOR_AMD is used in
>> > x86_emualte/x86_emualte.c and X86_VENDOR_UNKNOWN in test_x86_emulate.c.
>> > 
>> > I propose we move these to x86-vendors.h. What do you think?
>> 
>> Well, if you really think moving them is useful, then the header name
>> would be fine. But as said, I don't really see the point.
> 
> Yes, I think that's going to be useful because that allows emulator
> compiles in both xen and userspace harness. The other route is to
> disentangle some more code to achieve the same effect. But since you
> don't object to the proposed approach, I would avoid the more
> complicated route.

Just to clarify - the main reason for me not really liking the idea is
that (other than the architecture defines) the X86_VENDOR_*
values have no need to be in sync (regarding their values) in
hypervisor and test harness. All we need is for constants of that
name (with whatever values) to be in scope. And that's being
achieved by current code already.

Jan


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

Re: [Xen-devel] [PATCH 3/7] x86: extract macros to x86-defns.h

[Wei Liu]

On Mon, Jan 30, 2017 at 07:14:23AM -0700, Jan Beulich wrote:
> >>> On 30.01.17 at 13:46,  wrote:
> > On Mon, Jan 30, 2017 at 12:32:27PM +, Wei Liu wrote:
> >> On Thu, Jan 26, 2017 at 03:55:27AM -0700, Jan Beulich wrote:
> >> > >>> On 25.01.17 at 16:44,  wrote:
> >> > > ... so that they can be used by userspace x86 instruction emulator test
> >> > > program and fuzzer as well.
> >> > 
> >> > Ah, here we go. This should be patch 2 then imo.
> >> > 
> >> > > --- /dev/null
> >> > > +++ b/xen/include/asm-x86/x86-defns.h
> >> > > @@ -0,0 +1,125 @@
> >> > > +#ifndef __XEN_X86_DEFNS_H__
> >> > > +#define __XEN_X86_DEFNS_H__
> >> > > +
> >> > > +/*
> >> > > + * CPU vendor IDs
> >> > > + */
> >> > > +#define X86_VENDOR_INTEL 0
> >> > > +#define X86_VENDOR_AMD 1
> >> > > +#define X86_VENDOR_CENTAUR 2
> >> > > +#define X86_VENDOR_NUM 3
> >> > > +#define X86_VENDOR_UNKNOWN 0xff
> >> > 
> >> > Let's strictly separate things: These aren't architectural definitions,
> >> > so should - if we really mean to share them - go into another header.
> >> > I'm not sure though whether sharing these is all that useful.
> >> 
> >> Actually I don't think these are needed.
> >> 
> >> I moved them because there were duplicates in x86emul/test. But after
> >> having a closer look those duplicates are not used.
> > 
> > Spoke too soon. I only grepped for X86_VENDOR_INTEL and came to that
> > conclusion. Actually X86_VENDOR_AMD is used in
> > x86_emualte/x86_emualte.c and X86_VENDOR_UNKNOWN in test_x86_emulate.c.
> > 
> > I propose we move these to x86-vendors.h. What do you think?
> 
> Well, if you really think moving them is useful, then the header name
> would be fine. But as said, I don't really see the point.
> 

Yes, I think that's going to be useful because that allows emulator
compiles in both xen and userspace harness. The other route is to
disentangle some more code to achieve the same effect. But since you
don't object to the proposed approach, I would avoid the more
complicated route.

Wei.

> Jan
> 

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

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

[osstest service owner]

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

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   5 xen-buildfail   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  7a4cf23e2653e8abf4793820487df32b094de56a
baseline version:
 xen  40705830907aae52dc679362b7ec214b9ff25681

Last test of basis   104764  2017-01-27 13:01:16 Z3 days
Testing same since   105009  2017-01-30 12:06:27 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Wei Liu 

jobs:
 build-amd64  pass
 build-arm64  fail
 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=7a4cf23e2653e8abf4793820487df32b094de56a
+ . ./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 
7a4cf23e2653e8abf4793820487df32b094de56a
+ branch=xen-unstable-smoke
+ revision=7a4cf23e2653e8abf4793820487df32b094de56a
+ . ./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
+ '[' x7a4cf23e2653e8abf4793820487df32b094de56a = 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 3/7] x86: extract macros to x86-defns.h

[Jan Beulich]

>>> On 30.01.17 at 13:46,  wrote:
> On Mon, Jan 30, 2017 at 12:32:27PM +, Wei Liu wrote:
>> On Thu, Jan 26, 2017 at 03:55:27AM -0700, Jan Beulich wrote:
>> > >>> On 25.01.17 at 16:44,  wrote:
>> > > ... so that they can be used by userspace x86 instruction emulator test
>> > > program and fuzzer as well.
>> > 
>> > Ah, here we go. This should be patch 2 then imo.
>> > 
>> > > --- /dev/null
>> > > +++ b/xen/include/asm-x86/x86-defns.h
>> > > @@ -0,0 +1,125 @@
>> > > +#ifndef __XEN_X86_DEFNS_H__
>> > > +#define __XEN_X86_DEFNS_H__
>> > > +
>> > > +/*
>> > > + * CPU vendor IDs
>> > > + */
>> > > +#define X86_VENDOR_INTEL 0
>> > > +#define X86_VENDOR_AMD 1
>> > > +#define X86_VENDOR_CENTAUR 2
>> > > +#define X86_VENDOR_NUM 3
>> > > +#define X86_VENDOR_UNKNOWN 0xff
>> > 
>> > Let's strictly separate things: These aren't architectural definitions,
>> > so should - if we really mean to share them - go into another header.
>> > I'm not sure though whether sharing these is all that useful.
>> 
>> Actually I don't think these are needed.
>> 
>> I moved them because there were duplicates in x86emul/test. But after
>> having a closer look those duplicates are not used.
> 
> Spoke too soon. I only grepped for X86_VENDOR_INTEL and came to that
> conclusion. Actually X86_VENDOR_AMD is used in
> x86_emualte/x86_emualte.c and X86_VENDOR_UNKNOWN in test_x86_emulate.c.
> 
> I propose we move these to x86-vendors.h. What do you think?

Well, if you really think moving them is useful, then the header name
would be fine. But as said, I don't really see the point.

Jan


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

Re: [Xen-devel] Commit 3a6c9 breaks QEMU on FreeBSD/Xen

[Roger Pau Monné]

On Fri, Jan 27, 2017 at 12:13:58PM +0100, Juergen Gross wrote:
> On 24/01/17 17:42, Roger Pau Monné wrote:
> > Hello,
> > 
> > The following commit:
> > 
> > commit 3a6c9172ac5951e6dac2b3f6cbce3cfccdec5894
> > Author: Juergen Gross 
> > Date:   Tue Nov 22 07:10:58 2016 +0100
> > 
> > xen: create qdev for each backend device
> > 
> > Prevents me from running QEMU on FreeBSD/Xen, the following is printed on 
> > the
> > QEMU log:
> > 
> > char device redirected to /dev/pts/2 (label serial0)
> > xen be core: xen be core: can't open gnttab device
> > can't open gnttab device
> > xen be core: xen be core: can't open gnttab device
> > can't open gnttab device
> > 
> > # xl create -c ~/domain.cfg
> > Parsing config from /root/domain.cfg
> > libxl: error: libxl_dm.c:2201:device_model_spawn_outcome: Domain 32:domain 
> > 32 device model: spawn failed (rc=-3)
> > libxl: error: libxl_create.c:1506:domcreate_devmodel_started: Domain 
> > 32:device model did not start: -3
> > libxl: error: libxl_dm.c:2315:kill_device_model: Device Model already exited
> > libxl: error: libxl.c:1572:libxl__destroy_domid: Domain 32:Non-existant 
> > domain
> > libxl: error: libxl.c:1531:domain_destroy_callback: Domain 32:Unable to 
> > destroy guest
> > libxl: error: libxl.c:1458:domain_destroy_cb: Domain 32:Destruction of 
> > domain failed
> > # cat /var/log/xen/qemu-dm-domain.log
> > char device redirected to /dev/pts/2 (label serial0)
> > xen be core: xen be core: can't open gnttab device
> > can't open gnttab device
> > xen be core: xen be core: can't open gnttab device
> > can't open gnttab device
> > 
> > I'm not really familiar with any of that code, but I think that using
> > qdev_init_nofail is wrong, since on FreeBSD/Xen for example we don't yet
> > support the gnttab device, so initialization of the Xen Qdisk backend can 
> > fail
> > (and possibly the same applies to Linux if someone decides to compile a 
> > kernel
> > without the gnttab device). Yet QEMU can be used without the Qdisk backend.
> 
> I don't think this is due to qdev_init_nofail(). As the gnttab related
> messages are printed _after_ calling qdev_init_nofail() I don't see how
> it could be related.
> 
> I think the error exits of xen_be_get_xendev() are just wrong in using
> g_free(xendev) instead of qdev_unplug(>qdev, NULL).
> 
> I'll do a test with that modification. Could you test it in parallel?

Yes, that does indeed fix the issue. If you send the patch please add my
"Tested-by".

Roger.

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale   6 xen-boot fail in 104924 pass in 104981
 test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail in 104924 pass in 
104981
 test-armhf-armhf-xl   7 host-ping-check-xenfail pass in 104924

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

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

[Xen-devel] [linux-linus test] 104984: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-armhf-armhf-libvirt-raw  6 xen-bootfail baseline untested
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254

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

version targeted for testing:
 linux566cf877a1fcb6d6dc0126b076aad062054c2637
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  571 days
Failing since 59348  2015-07-10 04:24:05 Z  570 days  234 attempts
Testing same since   104984  2017-01-30 02:49:53 Z0 days1 attempts


7543 people touched revisions under test,
not listing them all

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

Re: [Xen-devel] [PATCH 3/7] x86: extract macros to x86-defns.h

[Wei Liu]

On Mon, Jan 30, 2017 at 12:32:27PM +, Wei Liu wrote:
> On Thu, Jan 26, 2017 at 03:55:27AM -0700, Jan Beulich wrote:
> > >>> On 25.01.17 at 16:44,  wrote:
> > > ... so that they can be used by userspace x86 instruction emulator test
> > > program and fuzzer as well.
> > 
> > Ah, here we go. This should be patch 2 then imo.
> > 
> > > --- /dev/null
> > > +++ b/xen/include/asm-x86/x86-defns.h
> > > @@ -0,0 +1,125 @@
> > > +#ifndef __XEN_X86_DEFNS_H__
> > > +#define __XEN_X86_DEFNS_H__
> > > +
> > > +/*
> > > + * CPU vendor IDs
> > > + */
> > > +#define X86_VENDOR_INTEL 0
> > > +#define X86_VENDOR_AMD 1
> > > +#define X86_VENDOR_CENTAUR 2
> > > +#define X86_VENDOR_NUM 3
> > > +#define X86_VENDOR_UNKNOWN 0xff
> > 
> > Let's strictly separate things: These aren't architectural definitions,
> > so should - if we really mean to share them - go into another header.
> > I'm not sure though whether sharing these is all that useful.
> 
> Actually I don't think these are needed.
> 
> I moved them because there were duplicates in x86emul/test. But after
> having a closer look those duplicates are not used.

Spoke too soon. I only grepped for X86_VENDOR_INTEL and came to that
conclusion. Actually X86_VENDOR_AMD is used in
x86_emualte/x86_emualte.c and X86_VENDOR_UNKNOWN in test_x86_emulate.c.

I propose we move these to x86-vendors.h. What do you think?

Wei.

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

Re: [Xen-devel] [PATCH 3/7] x86: extract macros to x86-defns.h

[Wei Liu]

On Thu, Jan 26, 2017 at 03:55:27AM -0700, Jan Beulich wrote:
> >>> On 25.01.17 at 16:44,  wrote:
> > ... so that they can be used by userspace x86 instruction emulator test
> > program and fuzzer as well.
> 
> Ah, here we go. This should be patch 2 then imo.
> 
> > --- /dev/null
> > +++ b/xen/include/asm-x86/x86-defns.h
> > @@ -0,0 +1,125 @@
> > +#ifndef __XEN_X86_DEFNS_H__
> > +#define __XEN_X86_DEFNS_H__
> > +
> > +/*
> > + * CPU vendor IDs
> > + */
> > +#define X86_VENDOR_INTEL 0
> > +#define X86_VENDOR_AMD 1
> > +#define X86_VENDOR_CENTAUR 2
> > +#define X86_VENDOR_NUM 3
> > +#define X86_VENDOR_UNKNOWN 0xff
> 
> Let's strictly separate things: These aren't architectural definitions,
> so should - if we really mean to share them - go into another header.
> I'm not sure though whether sharing these is all that useful.

Actually I don't think these are needed.

I moved them because there were duplicates in x86emul/test. But after
having a closer look those duplicates are not used.

> 
> > +/* Set for entry via SYSCALL. Informs return code to use SYSRETQ not 
> > IRETQ. */
> > +/* NB. Same as VGCF_in_syscall. No bits in common with any other TRAP_ 
> > defn. */
> > +#define TRAP_syscall 256
> > +
> > +/* Boolean return code: the reason for a fault has been fixed. */
> > +#define EXCRET_fault_fixed 1
> > +
> > +/* 'trap_bounce' flags values */
> > +#define TBF_EXCEPTION  1
> > +#define TBF_EXCEPTION_ERRCODE  2
> > +#define TBF_INTERRUPT  8
> > +
> > +/* 'arch_vcpu' flags values */
> > +#define _TF_kernel_mode0
> > +#define TF_kernel_mode (1<<_TF_kernel_mode)
> 
> None of these should be needed by the emulator, nor is any of this
> dictated by the architecture, so they all should remain in processor.h.
> 

OK.

Wei.

> Jan
> 

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

Re: [Xen-devel] [PATCH 2/7] x86_emulate: lift a bunch of macros to header file

[Wei Liu]

On Thu, Jan 26, 2017 at 03:51:35AM -0700, Jan Beulich wrote:
> >>> On 25.01.17 at 16:44,  wrote:
> > Some of them can be shared between hypervisor and userspace fuzzing /
> > test code. Instead of lifting the ones as we need, lift them all.
> 
> While I appreciate the intention, I don't think we should start having
> the hypervisor build deal with potential (or actual, but differently
> named) duplicate defines. In particular, despite its location in the
> tree, xen/arch/x86/x86_emulate/x86_emulate.h is a header
> included by various other source files, representing the interface to
> the emulator. The definitions you move there aren't part of that
> interface. I think Andrew and I had agreed (Andrew, correct me if
> I'm wrong) that we would want to eliminate that duplication, but
> then fully, i.e. also covering what processor.h and msr-index.h
> (and maybe a few more headers) define. I.e. we'd like to introduce
> a header of x86 arch definitions which can be used in both the
> hypervisor and the test harness builds.
> 

I see. Let me go through all those flags and change x86emul to use the
ones in xen headers.

Wei.

> Jan
> 

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