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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   5 xen-buildfail REGR. vs. 110078
 build-amd64   5 xen-buildfail REGR. vs. 110078
 build-i3865 xen-buildfail REGR. vs. 110078
 build-i386-xsm5 xen-buildfail REGR. vs. 110078

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf 4275f38507a4a44260555495dfb6da1d8a307307
baseline version:
 ovmf b941c34ef859971e29683ffb57c309e24e6a96be

Last test of basis   110078  2017-06-07 10:03:04 Z1 days
Testing same since   110104  2017-06-08 00:46:13 Z1 days3 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Laszlo Ersek 

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



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 4275f38507a4a44260555495dfb6da1d8a307307
Author: Laszlo Ersek 
Date:   Sat Jun 3 16:11:08 2017 +0200

OvmfPkg/AcpiPlatformDxe: alloc blobs from 64-bit space unless restricted

... by narrower than 8-byte ADD_POINTER references.

Introduce the CollectAllocationsRestrictedTo32Bit() function, which
iterates over the linker/loader script, and collects the names of the
fw_cfg blobs that are referenced by QEMU_LOADER_ADD_POINTER.PointeeFile
fields, such that QEMU_LOADER_ADD_POINTER.PointerSize is less than 8. This
means that the pointee blob's address will have to be patched into a
narrower-than-8 byte pointer field, hence the pointee blob must not be
allocated from 64-bit address space.

In ProcessCmdAllocate(), consult these restrictions when setting the
maximum address for gBS->AllocatePages(). The default is now MAX_UINT64,
unless restricted like described above to the pre-patch MAX_UINT32 limit.

In combination with Ard's QEMU commit cb51ac2ffe36 ("hw/arm/virt: generate
64-bit addressable ACPI objects", 2017-04-10), this patch enables
OvmfPkg/AcpiPlatformDxe to work entirely above the 4GB mark.

(An upcoming / planned aarch64 QEMU machine type will have no RAM under
4GB at all. Plus, moving the allocations higher is beneficial to the
current "virt" machine type as well; in Ard's words: "having all firmware
allocations inside the same 1 GB (or 512 MB for 64k pages) frame reduces
the TLB footprint".)

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Igor Mammedov 
Cc: Jordan Justen 
Suggested-by: Igor Mammedov 
Suggested-by: Gerd Hoffmann 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Tested-by: Ard Biesheuvel 
Reviewed-by: Jordan Justen 

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

[Xen-devel] [xen-4.9-testing test] 110124: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-xtf-amd64-amd64-2  74 xtf/test-pv64-xsa-188 fail in 110095 pass in 110124
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 17 
guest-start/debianhvm.repeat fail in 110095 pass in 110124
 test-amd64-amd64-xl-rtds  9 debian-install fail pass in 110095

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 110063

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop   fail in 110095 like 110044
 test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail like 110044
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64  9 windows-installfail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64  9 windows-installfail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-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-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-start/win.repeat  fail never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemut-win10-i386  9 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386  9 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386  9 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386  9 windows-install fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64  9 windows-install fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64  9 windows-install fail never pass

version targeted for testing:
 xen  5698869a723b36e768daf811ec1170258e6e9cf2
baseline version:
 xen  

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qcow210 guest-start  fail REGR. vs. 109975
 test-amd64-amd64-libvirt-vhd 10 guest-start  fail REGR. vs. 109975
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
109975
 test-armhf-armhf-libvirt-raw 14 guest-start/debian.repeat fail REGR. vs. 109975
 test-armhf-armhf-xl-vhd  10 guest-start  fail REGR. vs. 109975

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop   fail blocked in 109975
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 109975
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 109975
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 109975
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64  9 windows-installfail never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386  9 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386  9 windows-installfail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64  9 windows-install fail never pass

version targeted for testing:
 qemuu64175afc695c0672876fbbfc31b299c86d562cb4
baseline version:
 qemuuc6e84fbd447a51e1161d74d71566a5f67b47eac5

Last test of basis   109975  2017-06-04 00:16:43 Z5 days
Failing since110013  2017-06-05 10:45:10 Z3 days6 attempts
Testing same since   110114  2017-06-08 09:24:28 Z0 days1 attempts


People who touched revisions under test:
  Aaron Larson 
  Alex Bennée 
  Aurelien Jarno 
  Cédric Le Goater 
  Daniel Barboza 
  Daniel P. Berrange 
  David Gibson 
  David Hildenbrand 
  Eduardo Habkost 
  Emilio G. Cota 
  Eric Blake 
  Felipe Franciosi 
  Greg Kurz 
  Igor Mammedov 
  Jason Wang 
  John Paul Adrian Glaubitz 
  John 

[Xen-devel] Delivery Status Notification (Delay)

[f4da1594]

** Delivery incomplete **

There was a temporary problem delivering your message to 
curtiskwo...@gmail.com. Gmail will retry for 46 more hours. You'll be notified 
if the delivery fails permanently.



Reporting-MTA: dns; googlemail.com
Received-From-MTA: dns; FWD-737QHYSMHVAYQAUCAOIQBDAAGAQLMA2YAMHECCJDLIBAYAWYAKIAZAQHSMCCWMBLIA4UANQUEIGCIMBKMAZUZ4AAEAACA===@opayq.com
Arrival-Date: Wed, 07 Jun 2017 16:34:12 -0700 (PDT)
X-Original-Message-ID: 

Final-Recipient: rfc822; curtiskwong9@gmail.com
Action: delayed
Status: 4.0.0
Last-Attempt-Date: Thu, 08 Jun 2017 18:15:21 -0700 (PDT)
Will-Retry-Until: Sat, 10 Jun 2017 16:34:12 -0700 (PDT)


[Xen-changelog] [xen master] x86/HAP: don't open code
Description: Message attachment
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] Delivery Status Notification (Delay)

[f4da1594]

** Delivery incomplete **

There was a temporary problem delivering your message to 
curtiskwo...@gmail.com. Gmail will retry for 46 more hours. You'll be notified 
if the delivery fails permanently.



Reporting-MTA: dns; googlemail.com
Received-From-MTA: dns; FWD-737QHYSMHVAYQAUCAOIQBDAAGAQLMA2YAMHECCJDLIBAYAWYAKIAZAQHSMCCWMBLIA4UANQUEIGCIMBKMAZUZ4AAEAACA===@opayq.com
Arrival-Date: Wed, 07 Jun 2017 16:33:28 -0700 (PDT)
X-Original-Message-ID: 

Final-Recipient: rfc822; curtiskwong9@gmail.com
Action: delayed
Status: 4.0.0
Last-Attempt-Date: Thu, 08 Jun 2017 18:07:51 -0700 (PDT)
Will-Retry-Until: Sat, 10 Jun 2017 16:33:28 -0700 (PDT)


[Xen-changelog] [xen master] x86/PoD: drop a pointless local
Description: Message attachment
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/5] xen/pvh*: Support > 32 VCPUs at restore

[Ankur Arora]

On 2017-06-08 03:53 PM, Konrad Rzeszutek Wilk wrote:

On Thu, Jun 08, 2017 at 10:28:15AM +0200, Juergen Gross wrote:

On 03/06/17 02:05, Ankur Arora wrote:

This patch series fixes a bunch of issues in the xen_vcpu setup
logic.

Simplify xen_vcpu related code: code refactoring in advance of the
rest of the patch series.

Support > 32 VCPUs at restore: unify all vcpu restore logic in
xen_vcpu_restore() and support > 32 VCPUs for PVH*.

Remove vcpu info placement from restore (!SMP): some pv_ops are
marked RO after init so lets not redo xen_setup_vcpu_info_placement
at restore.

Handle xen_vcpu_setup() failure in hotplug: handle vcpu_info
registration failures by propagating them from the cpuhp-prepare
callback back up to the cpuhp logic.

Handle xen_vcpu_setup() failure at boot: pull CPUs (> MAX_VIRT_CPUS)
down if we fall back to xen_have_vcpu_info_placement = 0.

Tested with various combinations of PV/PVHv2/PVHVM save/restore
and cpu-hotadd-hotremove. Also tested by simulating failure in
VCPUOP_register_vcpu_info.

Please review.


Just a question regarding the sequence of tags (Reviewed-by: and
Signed-off-by:) in the patches:

It seems a little bit odd to have the Reviewed-by: tag before the
S-o-b: tag. This suggests the review was done before you wrote the
patches, which is hard to believe. :-)

Heh :). As Konrad surmises, I was unsure of the order and manually
ordered them to comport with Linux style. (Now that I see arch/x86/xen/,
I see that Xen puts them in time-order.)

Happy to reorder in case of V2.

Ankur



That is how the Linux orders the tags, just do 'git log' and you
will see that pattern >>

So please reorder the tags in future patches to be in their logical
sequence.


While Xen orders it in the other order (SoB first, then Reviewed-by).



I can fix this up in this series in case there is no need for V2.


Juergen



Ankur Arora (5):
   xen/vcpu: Simplify xen_vcpu related code
   xen/pvh*: Support > 32 VCPUs at domain restore
   xen/pv: Fix OOPS on restore for a PV, !SMP domain
   xen/vcpu: Handle xen_vcpu_setup() failure in hotplug
   xen/vcpu: Handle xen_vcpu_setup() failure at boot

  arch/x86/xen/enlighten.c | 154 +++
  arch/x86/xen/enlighten_hvm.c |  33 --
  arch/x86/xen/enlighten_pv.c  |  87 +++-
  arch/x86/xen/smp.c   |  31 +
  arch/x86/xen/smp.h   |   2 +
  arch/x86/xen/smp_hvm.c   |  14 +++-
  arch/x86/xen/smp_pv.c|   6 +-
  arch/x86/xen/suspend_hvm.c   |  11 +---
  arch/x86/xen/xen-ops.h   |   3 +-
  include/xen/xen-ops.h|   2 +
  10 files changed, 218 insertions(+), 125 deletions(-)




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


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

[Xen-devel] [linux-4.9 test] 110112: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2   6 xen-boot fail REGR. vs. 107358
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
107358
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 
fail in 110082 REGR. vs. 107358

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl  3 host-install(3) broken in 110082 pass in 110112
 test-amd64-amd64-xl-multivcpu 11 guest-start fail in 110082 pass in 110112
 test-amd64-amd64-i386-pvgrub 9 debian-di-install fail in 110082 pass in 110112
 test-amd64-i386-rumprun-i386 16 rumprun-demo-xenstorels/xenstorels.repeat fail 
in 110082 pass in 110112
 test-amd64-i386-libvirt 17 guest-start/debian.repeat fail in 110082 pass in 
110112
 test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail in 110082 
pass in 110112
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 110082 
pass in 110112
 test-amd64-amd64-xl-xsm15 guest-localmigrate fail in 110082 pass in 110112
 test-amd64-i386-xl-raw 18 guest-start/debian.repeat fail in 110082 pass in 
110112
 test-armhf-armhf-libvirt  5 xen-install  fail in 110082 pass in 110112
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
pass in 110082
 test-amd64-i386-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail pass in 
110082

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail REGR. vs. 107358
 test-amd64-amd64-xl-rtds  9 debian-install   fail REGR. vs. 107358

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop   fail in 110082 like 107358
 test-armhf-armhf-xl-rtds  6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail  like 107358
 test-armhf-armhf-xl-vhd   6 xen-boot fail  like 107358
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail like 107358
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 107358
 test-armhf-armhf-libvirt-raw  6 xen-boot fail  like 107358
 test-armhf-armhf-xl   6 xen-boot fail  like 107358
 test-armhf-armhf-xl-xsm   6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt  6 xen-boot fail  like 107358
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64  9 windows-installfail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64  9 windows-installfail never pass
 test-armhf-armhf-examine  6 reboot   fail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386  9 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386  9 windows-install fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64  9 windows-install fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64  9 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386  9 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386  9 windows-installfail never pass

version targeted for testing:
 linux

[Xen-devel] Delivery Status Notification (Delay)

[f4da1594]

** Delivery incomplete **

There was a temporary problem delivering your message to 
curtiskwo...@gmail.com. Gmail will retry for 47 more hours. You'll be notified 
if the delivery fails permanently.



Reporting-MTA: dns; googlemail.com
Received-From-MTA: dns; FWD-737QHYSMHVAYQAUCAOIQBDAAGAQLMA2YAMHECCJDLIBAYAWYAKIAZAQHSMCCWMBLIA4UANQUEIGCIMBKMAZUZ4AAEAACA===@opayq.com
Arrival-Date: Wed, 07 Jun 2017 16:33:33 -0700 (PDT)
X-Original-Message-ID: 

Final-Recipient: rfc822; curtiskwong9@gmail.com
Action: delayed
Status: 4.0.0
Last-Attempt-Date: Thu, 08 Jun 2017 16:35:50 -0700 (PDT)
Will-Retry-Until: Sat, 10 Jun 2017 16:33:33 -0700 (PDT)


[Xen-changelog] [xen master] x86/vlapic: fix two flaws in emulating
Description: Message attachment
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/5] xen/pvh*: Support > 32 VCPUs at restore

[Konrad Rzeszutek Wilk]

On Thu, Jun 08, 2017 at 10:28:15AM +0200, Juergen Gross wrote:
> On 03/06/17 02:05, Ankur Arora wrote:
> > This patch series fixes a bunch of issues in the xen_vcpu setup
> > logic.
> > 
> > Simplify xen_vcpu related code: code refactoring in advance of the
> > rest of the patch series.
> > 
> > Support > 32 VCPUs at restore: unify all vcpu restore logic in
> > xen_vcpu_restore() and support > 32 VCPUs for PVH*.
> > 
> > Remove vcpu info placement from restore (!SMP): some pv_ops are
> > marked RO after init so lets not redo xen_setup_vcpu_info_placement
> > at restore.
> > 
> > Handle xen_vcpu_setup() failure in hotplug: handle vcpu_info
> > registration failures by propagating them from the cpuhp-prepare
> > callback back up to the cpuhp logic.
> > 
> > Handle xen_vcpu_setup() failure at boot: pull CPUs (> MAX_VIRT_CPUS)
> > down if we fall back to xen_have_vcpu_info_placement = 0.
> > 
> > Tested with various combinations of PV/PVHv2/PVHVM save/restore
> > and cpu-hotadd-hotremove. Also tested by simulating failure in
> > VCPUOP_register_vcpu_info.
> > 
> > Please review.
> 
> Just a question regarding the sequence of tags (Reviewed-by: and
> Signed-off-by:) in the patches:
> 
> It seems a little bit odd to have the Reviewed-by: tag before the
> S-o-b: tag. This suggests the review was done before you wrote the
> patches, which is hard to believe. :-)

That is how the Linux orders the tags, just do 'git log' and you
will see that pattern.
> 
> So please reorder the tags in future patches to be in their logical
> sequence.

While Xen orders it in the other order (SoB first, then Reviewed-by).

> 
> I can fix this up in this series in case there is no need for V2.
> 
> 
> Juergen
> 
> > 
> > Ankur Arora (5):
> >   xen/vcpu: Simplify xen_vcpu related code
> >   xen/pvh*: Support > 32 VCPUs at domain restore
> >   xen/pv: Fix OOPS on restore for a PV, !SMP domain
> >   xen/vcpu: Handle xen_vcpu_setup() failure in hotplug
> >   xen/vcpu: Handle xen_vcpu_setup() failure at boot
> > 
> >  arch/x86/xen/enlighten.c | 154 
> > +++
> >  arch/x86/xen/enlighten_hvm.c |  33 --
> >  arch/x86/xen/enlighten_pv.c  |  87 +++-
> >  arch/x86/xen/smp.c   |  31 +
> >  arch/x86/xen/smp.h   |   2 +
> >  arch/x86/xen/smp_hvm.c   |  14 +++-
> >  arch/x86/xen/smp_pv.c|   6 +-
> >  arch/x86/xen/suspend_hvm.c   |  11 +---
> >  arch/x86/xen/xen-ops.h   |   3 +-
> >  include/xen/xen-ops.h|   2 +
> >  10 files changed, 218 insertions(+), 125 deletions(-)
> > 
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH 2/4] xenfb: Activate mouse handler

[Stefano Stabellini]

On Thu, 8 Jun 2017, Owen Smith wrote:
> Mouse events are only delivered to the first handler in the chain.
> Activating the xenfb mouse event handler so that mouse events can
> be passed over the shared ring protocol.
> Note: The keyboard handler is activated internally by the add
> call.

I am not sure I follow: why do we need this now? How is it working
today?


> Signed-off-by: Owen Smith 
> ---
>  hw/display/xenfb.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
> index 2ebc81b..b0a5726 100644
> --- a/hw/display/xenfb.c
> +++ b/hw/display/xenfb.c
> @@ -385,6 +385,7 @@ static void input_connected(struct XenDevice *xendev)
>  in->qmouse = qemu_add_mouse_event_handler(xenfb_mouse_event, in,
> in->abs_pointer_wanted,
> "Xen PVFB Mouse");
> +qemu_activate_mouse_event_handler(in->qmouse);
>  }
>  
>  static void input_disconnect(struct XenDevice *xendev)
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] [PATCH 1/4] xenfb: Add feature-vkbd-standalone

[Stefano Stabellini]

On Thu, 8 Jun 2017, Owen Smith wrote:
> Advertise "feature-vkbd-standalone" to indicate the backend
> can connect without a vfb device connection.
> When "request-vkbd-standalone" is set to 1, the backend does
> not wait for a QemuConsole to be setup before connecting the 
> vkbd device. This also means that absolute coordinates cannot
> be scaled to the non-existent QemuConsole's sizes, and remain
> unscaled, in the range [0, 0x7FFF].
> 
> Signed-off-by: Owen Smith 
> ---
>  hw/display/xenfb.c | 32 ++--
>  1 file changed, 22 insertions(+), 10 deletions(-)
> 
> diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
> index e76c0d8..2ebc81b 100644
> --- a/hw/display/xenfb.c
> +++ b/hw/display/xenfb.c
> @@ -52,6 +52,7 @@ struct common {
>  struct XenInput {
>  struct common c;
>  int abs_pointer_wanted; /* Whether guest supports absolute pointer */
> +int vkbd_standalone;/* Guest supports vkbd without vfb device */
>  int button_state;   /* Last seen pointer button state */
>  int extended;
>  QEMUPutMouseEntry *qmouse;
> @@ -306,18 +307,22 @@ static void xenfb_mouse_event(void *opaque,
> int dx, int dy, int dz, int button_state)
>  {
>  struct XenInput *xenfb = opaque;
> -DisplaySurface *surface = qemu_console_surface(xenfb->c.con);
> -int dw = surface_width(surface);
> -int dh = surface_height(surface);
> -int i;
> +int i, x, y;
> +if (xenfb->c.con != NULL) {
> +DisplaySurface *surface = qemu_console_surface(xenfb->c.con);
> +int dw = surface_width(surface);
> +int dh = surface_height(surface);
> +x = dx * (dh - 1) / 0x7fff;
> +y = dy * (dw - 1) / 0x7fff;
> +} else {
> +x = dx;
> +y = dy;
> +}
>  
>  trace_xenfb_mouse_event(opaque, dx, dy, dz, button_state,
>  xenfb->abs_pointer_wanted);
>  if (xenfb->abs_pointer_wanted)
> - xenfb_send_position(xenfb,
> - dx * (dw - 1) / 0x7fff,
> - dy * (dh - 1) / 0x7fff,
> - dz);
> +xenfb_send_position(xenfb, x, y, dz);
>  else
>   xenfb_send_motion(xenfb, dx, dy, dz);
>  
> @@ -336,6 +341,7 @@ static void xenfb_mouse_event(void *opaque,
>  static int input_init(struct XenDevice *xendev)
>  {
>  xenstore_write_be_int(xendev, "feature-abs-pointer", 1);
> +xenstore_write_be_int(xendev, "feature-vkbd-standalone", 1);
>  return 0;
>  }
>  
> @@ -345,8 +351,14 @@ static int input_initialise(struct XenDevice *xendev)
>  int rc;
>  
>  if (!in->c.con) {
> -xen_pv_printf(xendev, 1, "ds not set (yet)\n");
> -return -1;
> +if (xenstore_read_fe_int(xendev, "request-vkbd-standalone",
> + >vkbd_standalone) == -1) {
> +in->vkbd_standalone = 0;
> +}
> +if (in->vkbd_standalone == 0) {
> +xen_pv_printf(xendev, 1, "ds not set (yet)\n");
> +return -1;
> +}

In your changes to include/public/io/kbdif.h, make sure to write when
(at what xenstore status stage) the frontend needs to write
request-vkbd-standalone. 

This patch looks good:

Reviewed-by: Stefano Stabellini 



>  }
>  
>  rc = common_bind(>c);

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

Re: [Xen-devel] [PATCH 0/4] xenfb: Add vkbd-only option

[Stefano Stabellini]

On Thu, 8 Jun 2017, Owen Smith wrote:
> Adds the ability for a vkbd device to connect without the
> QemuConsole, in order to support a standalone PV mouse and
> keyboard frontend.
> This series adds a new feature flag, which will need adding
> to the xen's include/public/io/kbdif.h

Please do so, I would like that change to be applied to xen before this
series is applied to QEMU.


> "feature-vkbd-standalone" is set to 1 by backends that allow 
> the vkbd device model to connect without requiring a vfb device
> connected. The vkbd device will only bypass the check for
> the vfb device if the frontend sets "request-vkbd-standalone"
> to 1.
> The last 2 patches add a couple of missing input handler
> functions, and uses these to remove a leak in the vkbd device
> model.
> 
> Owen Smith (4):
>   xenfb: Add feature-vkbd-standalone
>   xenfb: Activate mouse handler
>   ui/input: Add activate/remove for keyboard handlers
>   xenfb: Fix leak by adding/removing keyboard handler
> 
>  hw/display/xenfb.c   | 44 
>  include/ui/console.h |  2 ++
>  ui/input-legacy.c| 12 
>  3 files changed, 46 insertions(+), 12 deletions(-)
> 
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] [RFC 6/6] acpi:arm64: Add support for parsing IORT table

[Stefano Stabellini]

CCing Jan

On Thu, 8 Jun 2017, Sameer Goel wrote:
> Add limited support for parsing IORT table to initialize SMMU devices.
> 
> Signed-off-by: Sameer Goel 
> ---
>  xen/arch/arm/setup.c|   3 +
>  xen/drivers/acpi/Makefile   |   1 +
>  xen/drivers/acpi/arm/Makefile   |   1 +
>  xen/drivers/acpi/arm/iort.c | 232 
> +++-
>  xen/drivers/passthrough/arm/iommu.c |  15 +--
>  xen/include/acpi/acpi.h |   1 +
>  xen/include/acpi/acpi_iort.h|  25 ++--
>  xen/include/asm-arm/device.h|   2 +
>  xen/include/xen/acpi.h  |  21 
>  xen/include/xen/lib.h   |   7 +-
>  xen/include/xen/pci.h   |   1 +
>  11 files changed, 184 insertions(+), 125 deletions(-)
>  create mode 100644 xen/drivers/acpi/arm/Makefile

This patch doesn't apply with "git am" and doesn't build on x86 with:

In file included from /local/repos/xen-upstream/xen/include/xen/iommu.h:24:0,
 from /local/repos/xen-upstream/xen/include/asm/hvm/domain.h:23,
 from /local/repos/xen-upstream/xen/include/asm/domain.h:7,
 from /local/repos/xen-upstream/xen/include/xen/domain.h:8,
 from /local/repos/xen-upstream/xen/include/xen/sched.h:11,
 from x86_64/asm-offsets.c:9:
/local/repos/xen-upstream/xen/include/xen/pci.h:91:19: error: field ‘dev’ has 
incomplete type
 struct device dev;
   ^
In file included from /local/repos/xen-upstream/xen/include/acpi/acpi.h:63:0,
 from /local/repos/xen-upstream/xen/include/xen/acpi.h:33,
 from /local/repos/xen-upstream/xen/include/asm/fixmap.h:21,
 from x86_64/asm-offsets.c:12:
/local/repos/xen-upstream/xen/include/acpi/acpi_iort.h:60:23: error: expected 
‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘iort_iommu_configure’
 acpi_status iommu_ops iort_iommu_configure(struct device *dev)
   ^
make[3]: *** [asm-offsets.s] Error 1


And it doesn't build on arm64 with:

/local/repos/xen-upstream/xen/arch/arm/setup.c:765: undefined reference to 
`acpi_iort_init'
/local/repos/gcc-linaro-4.9-2014.05-aarch64-linux-gnu-x86_64-linux-gnu/bin/aarch64-linux-gnu-ld:
 /local/repos/xen-upstream/xen/.xen-syms.0: hidden symbol `acpi_iort_init' 
isn't defined
/local/repos/gcc-linaro-4.9-2014.05-aarch64-linux-gnu-x86_64-linux-gnu/bin/aarch64-linux-gnu-ld:
 final link failed: Bad value
make[3]: *** [/local/repos/xen-upstream/xen/xen-syms] Error 1


> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 92a2de6..5dc93ff 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -753,6 +753,9 @@ void __init start_xen(unsigned long boot_phys_offset,
>  /* Parse the ACPI tables for possible boot-time configuration */
>  acpi_boot_table_init();
>  
> +/* Initialize the IORT tables */
> +acpi_iort_init();
> +
>  if ( acpi_disabled )
>  printk("Booting using Device Tree\n");
>  else
> diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile
> index 444b11d..4165318 100644
> --- a/xen/drivers/acpi/Makefile
> +++ b/xen/drivers/acpi/Makefile
> @@ -1,5 +1,6 @@
>  subdir-y += tables
>  subdir-y += utilities
> +subdir-$(CONFIG_ARM_64) += arm
>  subdir-$(CONFIG_X86) += apei
>  
>  obj-bin-y += tables.init.o
> diff --git a/xen/drivers/acpi/arm/Makefile b/xen/drivers/acpi/arm/Makefile
> new file mode 100644
> index 000..7c039bb
> --- /dev/null
> +++ b/xen/drivers/acpi/arm/Makefile
> @@ -0,0 +1 @@
> +obj-y += iort.o
> diff --git a/xen/drivers/acpi/arm/iort.c b/xen/drivers/acpi/arm/iort.c
> index 4a5bb96..c22ec31 100644
> --- a/xen/drivers/acpi/arm/iort.c
> +++ b/xen/drivers/acpi/arm/iort.c
> @@ -14,29 +14,40 @@
>   * This file implements early detection/parsing of I/O mapping
>   * reported to OS through firmware via I/O Remapping Table (IORT)
>   * IORT document number: ARM DEN 0049A
> + *
> + * Based on Linux drivers/acpi/arm64/iort.c
> + * => commit ca78d3173cff3503bcd15723b049757f75762d15
> + *
> + * Xen modification:
> + * Sameer Goel 
> + * Copyright (C) 2017, The Linux Foundation, All rights reserved.
> + *
>   */
>  
> -#define pr_fmt(fmt)  "ACPI: IORT: " fmt
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
>  
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
>  
>  #define IORT_TYPE_MASK(type) (1 << (type))
>  #define IORT_MSI_TYPE(1 << ACPI_IORT_NODE_ITS_GROUP)
>  #define IORT_IOMMU_TYPE  ((1 << ACPI_IORT_NODE_SMMU) |   \
>   (1 << ACPI_IORT_NODE_SMMU_V3))
>  
> +#if 0
>  struct iort_its_msi_chip {
>   struct list_headlist;
>   struct fwnode_handle*fw_node;
>   u32 translation_id;
>  };
>  
> +#endif
> +
>  struct iort_fwnode {
>   struct list_head list;
>   

Re: [Xen-devel] linux-next: bad commit in the xen-tip tree

[Stefano Stabellini]

On Fri, 9 Jun 2017, Stephen Rothwell wrote:
> Hi all,
> 
> The current top commit of the xen-tip tree
> 
>   9e925824eccd ("xen: avoid type warning in xchg_xen_ulong")
> 
> has no Signed-off-by for its committer.

Fixed, thanks for pointing it out.

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

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

[Andrew Cooper]

On 08/06/2017 22:17, Boris Ostrovsky wrote:
> On 06/08/2017 05:02 PM, Tom Lendacky wrote:
>> On 6/8/2017 3:51 PM, Boris Ostrovsky wrote:
> What may be needed is making sure X86_FEATURE_SME is not set for PV
> guests.
 And that may be something that Xen will need to control through either
 CPUID or MSR support for the PV guests.
>>>
>>> Only on newer versions of Xen. On earlier versions (2-3 years old) leaf
>>> 0x8007 is passed to the guest unchanged. And so is MSR_K8_SYSCFG.
>> The SME feature is in leaf 0x801f, is that leaf passed to the guest
>> unchanged?
> Oh, I misread the patch where X86_FEATURE_SME is defined. Then all
> versions, including the current one, pass it unchanged.
>
> All that's needed is setup_clear_cpu_cap(X86_FEATURE_SME) in
> xen_init_capabilities().

AMD processors still don't support CPUID Faulting (or at least, I
couldn't find any reference to it in the latest docs), so we cannot
actually hide SME from a guest which goes looking at native CPUID. 
Furthermore, I'm not aware of any CPUID masking support covering that leaf.

However, if Linux is using the paravirtual cpuid hook, things are
slightly better.

On Xen 4.9 and later, no guests will see the feature.  On earlier
versions of Xen (before I fixed the logic), plain domUs will not see the
feature, while dom0 will.

For safely, I'd recommend unilaterally clobbering the feature as Boris
suggested.  There is no way SME will be supportable on a per-PV guest
basis, although (as far as I am aware) Xen as a whole would be able to
encompass itself and all of its PV guests inside one single SME instance.

~Andrew

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

[Xen-devel] linux-next: bad commit in the xen-tip tree

[Stephen Rothwell]

Hi all,

The current top commit of the xen-tip tree

  9e925824eccd ("xen: avoid type warning in xchg_xen_ulong")

has no Signed-off-by for its committer.

-- 
Cheers,
Stephen Rothwell

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

Re: [Xen-devel] [RFC 2/6] arm64: Add definitions for fwnode_handle

[Stefano Stabellini]

On Thu, 8 Jun 2017, Goel, Sameer wrote:
> >> diff --git a/xen/include/xen/fwnode.h b/xen/include/xen/fwnode.h
> >> new file mode 100644
> >> index 000..db65b15
> >> --- /dev/null
> >> +++ b/xen/include/xen/fwnode.h
> >> @@ -0,0 +1,35 @@
> >> +/*
> >> + * fwnode.h - Firmware device node object handle type definition.
> >> + *
> >> + * Copyright (C) 2015, Intel Corporation
> >> + * Author: Rafael J. Wysocki 
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License version 2 as
> >> + * published by the Free Software Foundation.
> >> + *
> >> + * Ported from Linux include/linux/fwnode.h
> >> + *  => commit ce793486e23e0162a732c605189c8028e0910e86
> >> + *
> >> + * No functional Xen modifications.
> >> + */
> >> +
> >> +#ifndef __XEN_FWNODE_H_
> >> +#define __XEN_FWNODE_H_
> >> +
> >> +enum fwnode_type {
> >> +FWNODE_INVALID = 0,
> >> +FWNODE_OF,
> >> +FWNODE_ACPI,
> >> +FWNODE_ACPI_DATA,
> >> +FWNODE_ACPI_STATIC,
> >> +FWNODE_PDATA,
> >> +FWNODE_IRQCHIP
> > 
> > Do you really need to introduce all of them?
> > 
> Not really. We are interested in OF and ACPI_STATIC for now. Since the 
> verbatim file from Linux applied ok, I did not remove the other entries.
> What's your recommendation?

Usually we keep the imported Linux definitions as-is.


> >> +};
> >> +
> >> +struct fwnode_handle {
> >> +enum fwnode_type type;
> >> +struct fwnode_handle *secondary;
> >> +};
> >> +
> >> +#endif
> >>

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

Re: [Xen-devel] [RFC 3/6] Introduce _xrealloc

[Stefano Stabellini]

On Thu, 8 Jun 2017, Sameer Goel wrote:
> Introduce a memory realloc function.
> 
> Signed-off-by: Sameer Goel 
> ---
>  xen/common/xmalloc_tlsf.c | 13 +
>  xen/include/xen/xmalloc.h |  1 +
>  2 files changed, 14 insertions(+)
> 
> diff --git a/xen/common/xmalloc_tlsf.c b/xen/common/xmalloc_tlsf.c
> index b256dc5..52385a8 100644
> --- a/xen/common/xmalloc_tlsf.c
> +++ b/xen/common/xmalloc_tlsf.c
> @@ -612,6 +612,19 @@ void *_xzalloc(unsigned long size, unsigned long align)
>  return p ? memset(p, 0, size) : p;
>  }
>  
> +void *_xrealloc(void *p, unsigned long new_size, unsigned long align)
> +{
> +void *new_p = _xmalloc(new_size, align);

It might be best to handle the case where new_size is 0 explicitly, and
only free p.


> +if(new_p && p)
> +{
> +memcpy(new_p, p, new_size);
> +xfree(p);
> +}
> +
> +return new_p;
> +}
> +
>  void xfree(void *p)
>  {
>  struct bhdr *b;
> diff --git a/xen/include/xen/xmalloc.h b/xen/include/xen/xmalloc.h
> index 24a99ac..41a9b2f 100644
> --- a/xen/include/xen/xmalloc.h
> +++ b/xen/include/xen/xmalloc.h
> @@ -29,6 +29,7 @@ extern void xfree(void *);
>  /* Underlying functions */
>  extern void *_xmalloc(unsigned long size, unsigned long align);
>  extern void *_xzalloc(unsigned long size, unsigned long align);
> +extern void *_xrealloc(void *p, unsigned long new_size, unsigned long align);
>  
>  static inline void *_xmalloc_array(
>  unsigned long size, unsigned long align, unsigned long num)
> -- 
> Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, 
> Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a 
> Linux Foundation Collaborative Project.
> 

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

Re: [Xen-devel] [RFC 2/6] arm64: Add definitions for fwnode_handle

[Goel, Sameer]

On 6/8/2017 1:59 PM, Julien Grall wrote:
> 
> 
> On 08/06/2017 20:30, Sameer Goel wrote:
>> This will be used as a device property to match the DMA capable devices
>> with the associated SMMU. The header file is a port from linux.
>>
>> Linux ChangeId:ce793486e23e: driver core / ACPI: Represent ACPI
>> companions using fwnode_handle
>>
>> Signed-off-by: Sameer Goel 
>> ---
>>  xen/include/asm-arm/device.h |  2 ++
>>  xen/include/xen/fwnode.h | 35 +++
>>  2 files changed, 37 insertions(+)
>>  create mode 100644 xen/include/xen/fwnode.h
>>
>> diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
>> index 6734ae8..78c38fe 100644
>> --- a/xen/include/asm-arm/device.h
>> +++ b/xen/include/asm-arm/device.h
>> @@ -2,6 +2,7 @@
>>  #define __ASM_ARM_DEVICE_H
>>
>>  #include 
>> +#include 
>>
>>  enum device_type
>>  {
>> @@ -19,6 +20,7 @@ struct device
>>  #ifdef CONFIG_HAS_DEVICE_TREE
>>  struct dt_device_node *of_node; /* Used by drivers imported from Linux 
>> */
>>  #endif
>> +struct fwnode_handle *fwnode; /*fw device node identifier */
> 
> I am a bit surprised you don't rework struct dev. As of_node is now redundant 
> with fwnode.

I agree that this will eventually be removed. I have kept this in now just to 
maintain compatibility
(compilation and otherwise) with smmuv2 driver. I will add a comment to 
indicate this. So that it can 
be easily identified and remove when we do a final cleanup. Can I prefix the 
comment with with XEN:TODO:? 

> 
>>  struct dev_archdata archdata;
>>  };
>>
>> diff --git a/xen/include/xen/fwnode.h b/xen/include/xen/fwnode.h
>> new file mode 100644
>> index 000..db65b15
>> --- /dev/null
>> +++ b/xen/include/xen/fwnode.h
>> @@ -0,0 +1,35 @@
>> +/*
>> + * fwnode.h - Firmware device node object handle type definition.
>> + *
>> + * Copyright (C) 2015, Intel Corporation
>> + * Author: Rafael J. Wysocki 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * Ported from Linux include/linux/fwnode.h
>> + *  => commit ce793486e23e0162a732c605189c8028e0910e86
>> + *
>> + * No functional Xen modifications.
>> + */
>> +
>> +#ifndef __XEN_FWNODE_H_
>> +#define __XEN_FWNODE_H_
>> +
>> +enum fwnode_type {
>> +FWNODE_INVALID = 0,
>> +FWNODE_OF,
>> +FWNODE_ACPI,
>> +FWNODE_ACPI_DATA,
>> +FWNODE_ACPI_STATIC,
>> +FWNODE_PDATA,
>> +FWNODE_IRQCHIP
> 
> Do you really need to introduce all of them?
> 
Not really. We are interested in OF and ACPI_STATIC for now. Since the verbatim 
file from Linux applied ok, I did not remove the other entries.
What's your recommendation?

>> +};
>> +
>> +struct fwnode_handle {
>> +enum fwnode_type type;
>> +struct fwnode_handle *secondary;
>> +};
>> +
>> +#endif
>>
> 
> Cheers,
> 

Thanks,
Sameer
-- 
 Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, 
Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

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

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

[Boris Ostrovsky]

On 06/08/2017 05:02 PM, Tom Lendacky wrote:
> On 6/8/2017 3:51 PM, Boris Ostrovsky wrote:
>>
>>>
 What may be needed is making sure X86_FEATURE_SME is not set for PV
 guests.
>>>
>>> And that may be something that Xen will need to control through either
>>> CPUID or MSR support for the PV guests.
>>
>>
>> Only on newer versions of Xen. On earlier versions (2-3 years old) leaf
>> 0x8007 is passed to the guest unchanged. And so is MSR_K8_SYSCFG.
>
> The SME feature is in leaf 0x801f, is that leaf passed to the guest
> unchanged?

Oh, I misread the patch where X86_FEATURE_SME is defined. Then all
versions, including the current one, pass it unchanged.

All that's needed is setup_clear_cpu_cap(X86_FEATURE_SME) in
xen_init_capabilities().


-boris

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

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

[Tom Lendacky]

On 6/8/2017 3:51 PM, Boris Ostrovsky wrote:





What may be needed is making sure X86_FEATURE_SME is not set for PV
guests.


And that may be something that Xen will need to control through either
CPUID or MSR support for the PV guests.



Only on newer versions of Xen. On earlier versions (2-3 years old) leaf
0x8007 is passed to the guest unchanged. And so is MSR_K8_SYSCFG.


The SME feature is in leaf 0x801f, is that leaf passed to the guest
unchanged?

Thanks,
Tom



-boris



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

Re: [Xen-devel] [for-4.9] Re: HVM guest performance regression

[Dario Faggioli]

Bringing in Konrad because...

On Thu, 2017-06-08 at 11:37 +0200, Juergen Gross wrote:
> On 07/06/17 20:19, Stefano Stabellini wrote:
> > On Wed, 7 Jun 2017, Juergen Gross wrote:
> > > On 06/06/17 21:08, Stefano Stabellini wrote:
> > > > 
> > > > 2) PV suspend/resume
> > > > 3) vector callback
> > > > 4) interrupt remapping
> > > > 
> > > > 2) is not on the hot path.
> > > > I did individual measurements of 3) at some points and it was a
> > > > clear win.
> > > 
> > > That might depend on the hardware. Could it be newer processors
> > > are
> > > faster here?
> > 
> > I don't think so: the alternative it's an emulated interrupt. It's
> > slower under all points of view.
> 
> What about APIC virtualization of modern processors? Are you sure
> e.g.
> timer interrupts aren't handled completely by the processor? I guess
> this might be faster than letting it be handled by the hypervisor and
> then use the callback into the guest.
> 
... I kind of remember an email exchange we had, not here on the list,
but in private, about some apparently weird scheduling behavior you
were seeing, there at Oracle, on a particular benchmark/customer's
workload.

Not that this is directly related, but I seem to also recall that you
managed to find out that some of the perf difference (between baremetal
and guest) was due to vAPIC being faster than the PV path we were
taking? What I don't recall, though, is whether your guest was PV or
(PV)HVM... Do you remember anything more precisely than this?

It was like one or two years ago... (I'll dig in the archives for the
emails.)

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

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

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

[Boris Ostrovsky]

>
>> What may be needed is making sure X86_FEATURE_SME is not set for PV
>> guests.
>
> And that may be something that Xen will need to control through either
> CPUID or MSR support for the PV guests.


Only on newer versions of Xen. On earlier versions (2-3 years old) leaf
0x8007 is passed to the guest unchanged. And so is MSR_K8_SYSCFG.

-boris

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale   3 host-install(3)  broken pass in 110079
 test-armhf-armhf-libvirt  5 xen-install  fail in 110079 pass in 110109
 test-amd64-amd64-xl-qcow210 guest-start  fail in 110079 pass in 110109
 test-amd64-amd64-pygrub  10 guest-start  fail in 110079 pass in 110109
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail in 110079 pass in 
110109
 test-armhf-armhf-xl-credit2   5 xen-installfail pass in 110079
 test-armhf-armhf-libvirt-raw  7 host-ping-check-xenfail pass in 110079
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 fail pass in 110079
 test-amd64-i386-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail pass in 
110079

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail in 110079 REGR. vs. 
109754

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  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-libvirt-raw 12 saverestore-support-check fail in 110079 like 
109754
 test-armhf-armhf-xl-credit2 12 migrate-support-check fail in 110079 never pass
 test-armhf-armhf-xl-credit2 13 saverestore-support-check fail in 110079 never 
pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-check fail in 110079 never pass
 test-armhf-armhf-xl-arndale 12 migrate-support-check fail in 110079 never pass
 test-armhf-armhf-xl-arndale 13 saverestore-support-check fail in 110079 never 
pass
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 109754
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 109754
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 109754
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64  9 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64  9 windows-installfail 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
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386  9 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386  9 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386  9 windows-installfail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64  9 windows-install fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64  9 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386  9 windows-install fail never pass

version targeted for testing:
 linux

Re: [Xen-devel] [RFC 4/6] xen/passthrough/arm: Introduce iommu_fwspec

[Julien Grall]

Hi,

On 08/06/2017 20:30, Sameer Goel wrote:

Introduce a common structure to hold the fw (ACPI or DT) defined
configuration for SMMU hw. The current use case is for arm SMMUs. So,
making this architecture specific.

Based on Linux kernel commit 57f98d2f61e1: iommu: Introduce iommu_fwspec
Signed-off-by: Sameer Goel 
---
 xen/drivers/passthrough/arm/iommu.c | 57 +
 xen/include/asm-arm/device.h|  1 +
 xen/include/xen/iommu.h | 28 ++
 3 files changed, 86 insertions(+)

diff --git a/xen/drivers/passthrough/arm/iommu.c 
b/xen/drivers/passthrough/arm/iommu.c
index 95b1abb..edf70c2 100644
--- a/xen/drivers/passthrough/arm/iommu.c
+++ b/xen/drivers/passthrough/arm/iommu.c
@@ -73,3 +73,60 @@ int arch_iommu_populate_page_table(struct domain *d)
 /* The IOMMU shares the p2m with the CPU */
 return -ENOSYS;
 }
+
+int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
+const struct iommu_ops *ops)


If you put code in iommu.c then you need to respect the coding style of 
the file. So this should be correctly indented.



+{
+struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+
+if (fwspec)


Coding style.


+return ops == fwspec->ops ? 0 : -EINVAL;
+
+fwspec = xzalloc(struct iommu_fwspec);
+if (!fwspec)


Ditto.


+return -ENOMEM;
+
+/* Ref counting for the dt device node is not needed */
+
+/*of_node_get(to_of_node(iommu_fwnode));*/


I am a bit confused. You put this in a comment here and drop it in patch 
#5. So you probably want to drop here.



+
+fwspec->iommu_fwnode = iommu_fwnode;
+fwspec->ops = ops;
+dev->iommu_fwspec = fwspec;


Newline here please.


+return 0;
+}
+
+void iommu_fwspec_free(struct device *dev)
+{
+struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+
+if (fwspec) {


Coding style.


+/*fwnode_handle_put(fwspec->iommu_fwnode);*/


And ditto for the comment.


+xfree(fwspec);
+dev->iommu_fwspec = NULL;
+}
+}
+
+int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids)


As you don't respect the Linux coding style (you are using soft-tab). I 
see little point to stay close to Linux for this code as it would be 
difficult to port anyway.


So s/u32/uint32_t/


+{
+struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+size_t size;
+int i;
+
+if (!fwspec)


Coding style.


+return -EINVAL;
+
+size = offsetof(struct iommu_fwspec, ids[fwspec->num_ids + num_ids]);
+if (size > sizeof(*fwspec)) {


Coding style.


+fwspec = _xrealloc(dev->iommu_fwspec, size, sizeof(void *));


If you introduce _xrealloc (I will leave the REST maintainers decide 
whether they want it), then please introduce xrealloc macro.



+if (!fwspec)


Coding style.


+return -ENOMEM;
+}
+
+for (i = 0; i < num_ids; i++)


Coding style.


+fwspec->ids[fwspec->num_ids + i] = ids[i];
+
+fwspec->num_ids += num_ids;
+dev->iommu_fwspec = fwspec;


newline.


+return 0;
+}
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 78c38fe..5027c87 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -21,6 +21,7 @@ struct device
 struct dt_device_node *of_node; /* Used by drivers imported from Linux */
 #endif
 struct fwnode_handle *fwnode; /*fw device node identifier */
+struct iommu_fwspec *iommu_fwspec;
 struct dev_archdata archdata;
 };

diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 5803e3f..7ef9b93 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -224,4 +224,32 @@ DECLARE_PER_CPU(bool_t, iommu_dont_flush_iotlb);
 extern struct spinlock iommu_pt_cleanup_lock;
 extern struct page_list_head iommu_pt_cleanup_list;

+/**
+ * Following block was ported from Linux to help with the implementation of
+ * arm64 iommu devices. Hence the architecture specific compile
+ */
+
+#if defined(CONFIG_ARM_64) || defined(CONFIG_ARM)


No ifdef ARCH in xen/* headers. If this is only used by ARM, then it 
should go in asm-arm/iommu.h.



+/**
+ * struct iommu_fwspec - per-device IOMMU instance data
+ * @ops: ops for this device's IOMMU
+ * @iommu_fwnode: firmware handle for this device's IOMMU
+ * @iommu_priv: IOMMU driver private data for this device
+ * @num_ids: number of associated device IDs
+ * @ids: IDs which this device may present to the IOMMU
+ */
+struct iommu_fwspec {
+   const struct iommu_ops  *ops;
+   struct fwnode_handle*iommu_fwnode;
+   void*iommu_priv;
+   unsigned intnum_ids;
+   u32 ids[1];
+};
+
+int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
+ const struct iommu_ops *ops);
+void iommu_fwspec_free(struct device *dev);
+int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids);
+

Re: [Xen-devel] [RFC 2/6] arm64: Add definitions for fwnode_handle

[Julien Grall]

On 08/06/2017 20:30, Sameer Goel wrote:

This will be used as a device property to match the DMA capable devices
with the associated SMMU. The header file is a port from linux.

Linux ChangeId:ce793486e23e: driver core / ACPI: Represent ACPI
companions using fwnode_handle

Signed-off-by: Sameer Goel 
---
 xen/include/asm-arm/device.h |  2 ++
 xen/include/xen/fwnode.h | 35 +++
 2 files changed, 37 insertions(+)
 create mode 100644 xen/include/xen/fwnode.h

diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 6734ae8..78c38fe 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -2,6 +2,7 @@
 #define __ASM_ARM_DEVICE_H

 #include 
+#include 

 enum device_type
 {
@@ -19,6 +20,7 @@ struct device
 #ifdef CONFIG_HAS_DEVICE_TREE
 struct dt_device_node *of_node; /* Used by drivers imported from Linux */
 #endif
+struct fwnode_handle *fwnode; /*fw device node identifier */


I am a bit surprised you don't rework struct dev. As of_node is now 
redundant with fwnode.



 struct dev_archdata archdata;
 };

diff --git a/xen/include/xen/fwnode.h b/xen/include/xen/fwnode.h
new file mode 100644
index 000..db65b15
--- /dev/null
+++ b/xen/include/xen/fwnode.h
@@ -0,0 +1,35 @@
+/*
+ * fwnode.h - Firmware device node object handle type definition.
+ *
+ * Copyright (C) 2015, Intel Corporation
+ * Author: Rafael J. Wysocki 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Ported from Linux include/linux/fwnode.h
+ *  => commit ce793486e23e0162a732c605189c8028e0910e86
+ *
+ * No functional Xen modifications.
+ */
+
+#ifndef __XEN_FWNODE_H_
+#define __XEN_FWNODE_H_
+
+enum fwnode_type {
+   FWNODE_INVALID = 0,
+   FWNODE_OF,
+   FWNODE_ACPI,
+   FWNODE_ACPI_DATA,
+   FWNODE_ACPI_STATIC,
+   FWNODE_PDATA,
+   FWNODE_IRQCHIP


Do you really need to introduce all of them?


+};
+
+struct fwnode_handle {
+   enum fwnode_type type;
+   struct fwnode_handle *secondary;
+};
+
+#endif



Cheers,

--
Julien Grall

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   5 xen-buildfail REGR. vs. 110078
 build-amd64   5 xen-buildfail REGR. vs. 110078
 build-i3865 xen-buildfail REGR. vs. 110078
 build-i386-xsm5 xen-buildfail REGR. vs. 110078

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf 4275f38507a4a44260555495dfb6da1d8a307307
baseline version:
 ovmf b941c34ef859971e29683ffb57c309e24e6a96be

Last test of basis   110078  2017-06-07 10:03:04 Z1 days
Testing same since   110104  2017-06-08 00:46:13 Z0 days2 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Laszlo Ersek 

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



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 4275f38507a4a44260555495dfb6da1d8a307307
Author: Laszlo Ersek 
Date:   Sat Jun 3 16:11:08 2017 +0200

OvmfPkg/AcpiPlatformDxe: alloc blobs from 64-bit space unless restricted

... by narrower than 8-byte ADD_POINTER references.

Introduce the CollectAllocationsRestrictedTo32Bit() function, which
iterates over the linker/loader script, and collects the names of the
fw_cfg blobs that are referenced by QEMU_LOADER_ADD_POINTER.PointeeFile
fields, such that QEMU_LOADER_ADD_POINTER.PointerSize is less than 8. This
means that the pointee blob's address will have to be patched into a
narrower-than-8 byte pointer field, hence the pointee blob must not be
allocated from 64-bit address space.

In ProcessCmdAllocate(), consult these restrictions when setting the
maximum address for gBS->AllocatePages(). The default is now MAX_UINT64,
unless restricted like described above to the pre-patch MAX_UINT32 limit.

In combination with Ard's QEMU commit cb51ac2ffe36 ("hw/arm/virt: generate
64-bit addressable ACPI objects", 2017-04-10), this patch enables
OvmfPkg/AcpiPlatformDxe to work entirely above the 4GB mark.

(An upcoming / planned aarch64 QEMU machine type will have no RAM under
4GB at all. Plus, moving the allocations higher is beneficial to the
current "virt" machine type as well; in Ard's words: "having all firmware
allocations inside the same 1 GB (or 512 MB for 64k pages) frame reduces
the TLB footprint".)

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Igor Mammedov 
Cc: Jordan Justen 
Suggested-by: Igor Mammedov 
Suggested-by: Gerd Hoffmann 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Tested-by: Ard Biesheuvel 
Reviewed-by: Jordan Justen 

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

Re: [Xen-devel] [RFC 3/6] Introduce _xrealloc

[Julien Grall]

CC the REST maintainers

On 08/06/2017 20:30, Sameer Goel wrote:

Introduce a memory realloc function.

Signed-off-by: Sameer Goel 
---
 xen/common/xmalloc_tlsf.c | 13 +
 xen/include/xen/xmalloc.h |  1 +
 2 files changed, 14 insertions(+)

diff --git a/xen/common/xmalloc_tlsf.c b/xen/common/xmalloc_tlsf.c
index b256dc5..52385a8 100644
--- a/xen/common/xmalloc_tlsf.c
+++ b/xen/common/xmalloc_tlsf.c
@@ -612,6 +612,19 @@ void *_xzalloc(unsigned long size, unsigned long align)
 return p ? memset(p, 0, size) : p;
 }

+void *_xrealloc(void *p, unsigned long new_size, unsigned long align)
+{
+void *new_p = _xmalloc(new_size, align);
+
+if(new_p && p)


Coding style: if ( ... )


+{
+memcpy(new_p, p, new_size);
+xfree(p);
+}
+
+return new_p;
+}
+
 void xfree(void *p)
 {
 struct bhdr *b;
diff --git a/xen/include/xen/xmalloc.h b/xen/include/xen/xmalloc.h
index 24a99ac..41a9b2f 100644
--- a/xen/include/xen/xmalloc.h
+++ b/xen/include/xen/xmalloc.h
@@ -29,6 +29,7 @@ extern void xfree(void *);
 /* Underlying functions */
 extern void *_xmalloc(unsigned long size, unsigned long align);
 extern void *_xzalloc(unsigned long size, unsigned long align);
+extern void *_xrealloc(void *p, unsigned long new_size, unsigned long align);

 static inline void *_xmalloc_array(
 unsigned long size, unsigned long align, unsigned long num)



--
Julien Grall

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

Re: [Xen-devel] [RFC 2/6] arm64: Add definitions for fwnode_handle

[Julien Grall]

Hi,

Please CC all the relevant maintainers on this patch.

On 08/06/2017 20:30, Sameer Goel wrote:

This will be used as a device property to match the DMA capable devices
with the associated SMMU. The header file is a port from linux.

Linux ChangeId:ce793486e23e: driver core / ACPI: Represent ACPI
companions using fwnode_handle

Signed-off-by: Sameer Goel 
---
 xen/include/asm-arm/device.h |  2 ++
 xen/include/xen/fwnode.h | 35 +++


I am not totally convinced this is the right place for this header. But 
I will leave the REST maintainers deciding.



 2 files changed, 37 insertions(+)
 create mode 100644 xen/include/xen/fwnode.h

diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 6734ae8..78c38fe 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -2,6 +2,7 @@
 #define __ASM_ARM_DEVICE_H

 #include 
+#include 

 enum device_type
 {
@@ -19,6 +20,7 @@ struct device
 #ifdef CONFIG_HAS_DEVICE_TREE
 struct dt_device_node *of_node; /* Used by drivers imported from Linux */
 #endif
+struct fwnode_handle *fwnode; /*fw device node identifier */
 struct dev_archdata archdata;
 };

diff --git a/xen/include/xen/fwnode.h b/xen/include/xen/fwnode.h
new file mode 100644
index 000..db65b15
--- /dev/null
+++ b/xen/include/xen/fwnode.h
@@ -0,0 +1,35 @@
+/*
+ * fwnode.h - Firmware device node object handle type definition.
+ *
+ * Copyright (C) 2015, Intel Corporation
+ * Author: Rafael J. Wysocki 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Ported from Linux include/linux/fwnode.h
+ *  => commit ce793486e23e0162a732c605189c8028e0910e86
+ *
+ * No functional Xen modifications.
+ */
+
+#ifndef __XEN_FWNODE_H_
+#define __XEN_FWNODE_H_
+
+enum fwnode_type {
+   FWNODE_INVALID = 0,
+   FWNODE_OF,
+   FWNODE_ACPI,
+   FWNODE_ACPI_DATA,
+   FWNODE_ACPI_STATIC,
+   FWNODE_PDATA,
+   FWNODE_IRQCHIP
+};
+
+struct fwnode_handle {
+   enum fwnode_type type;
+   struct fwnode_handle *secondary;
+};
+
+#endif



--
Julien Grall

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

[Xen-devel] [RFC 1/6] passthrough/arm: Modify SMMU driver to use generic device definition

[Sameer Goel]

Modify the SMMU code to use generic device instead of dt_device_node for
functions that can be used for ACPI based systems too.

Signed-off-by: Sameer Goel 
---
 xen/drivers/passthrough/arm/smmu.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index 1082fcf..a298661 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -76,7 +76,7 @@ struct resource
 
 #define resource_size(res) (res)->size;
 
-#define platform_device dt_device_node
+#define platform_device device
 
 #define IORESOURCE_MEM 0
 #define IORESOURCE_IRQ 1
@@ -97,12 +97,12 @@ static struct resource *platform_get_resource(struct 
platform_device *pdev,
 
switch (type) {
case IORESOURCE_MEM:
-   ret = dt_device_get_address(pdev, num, , );
+   ret = dt_device_get_address(dev_to_dt(pdev), num, , 
);
 
return ((ret) ? NULL : );
 
case IORESOURCE_IRQ:
-   ret = platform_get_irq(pdev, num);
+   ret = platform_get_irq(dev_to_dt(pdev), num);
if (ret < 0)
return NULL;
 
@@ -2285,7 +2285,7 @@ static int arm_smmu_device_dt_probe(struct 
platform_device *pdev)
const struct of_device_id *of_id;
struct resource *res;
struct arm_smmu_device *smmu;
-   struct device *dev = >dev;
+   struct device *dev = pdev;
struct rb_node *node;
struct of_phandle_args masterspec;
int num_irqs, i, err;
@@ -2338,7 +2338,7 @@ static int arm_smmu_device_dt_probe(struct 
platform_device *pdev)
}
 
for (i = 0; i < num_irqs; ++i) {
-   int irq = platform_get_irq(pdev, i);
+   int irq = platform_get_irq(dev_to_dt(pdev), i);
 
if (irq < 0) {
dev_err(dev, "failed to get irq index %d\n", i);
@@ -2821,7 +2821,7 @@ static __init int arm_smmu_dt_init(struct dt_device_node 
*dev,
 */
dt_device_set_used_by(dev, DOMID_XEN);
 
-   rc = arm_smmu_device_dt_probe(dev);
+   rc = arm_smmu_device_dt_probe(dt_to_dev(dev));
if (rc)
return rc;
 
-- 
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. 
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.


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

[Xen-devel] [RFC 4/6] xen/passthrough/arm: Introduce iommu_fwspec

[Sameer Goel]

Introduce a common structure to hold the fw (ACPI or DT) defined
configuration for SMMU hw. The current use case is for arm SMMUs. So,
making this architecture specific.

Based on Linux kernel commit 57f98d2f61e1: iommu: Introduce iommu_fwspec
Signed-off-by: Sameer Goel 
---
 xen/drivers/passthrough/arm/iommu.c | 57 +
 xen/include/asm-arm/device.h|  1 +
 xen/include/xen/iommu.h | 28 ++
 3 files changed, 86 insertions(+)

diff --git a/xen/drivers/passthrough/arm/iommu.c 
b/xen/drivers/passthrough/arm/iommu.c
index 95b1abb..edf70c2 100644
--- a/xen/drivers/passthrough/arm/iommu.c
+++ b/xen/drivers/passthrough/arm/iommu.c
@@ -73,3 +73,60 @@ int arch_iommu_populate_page_table(struct domain *d)
 /* The IOMMU shares the p2m with the CPU */
 return -ENOSYS;
 }
+
+int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
+const struct iommu_ops *ops)
+{
+struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+
+if (fwspec)
+return ops == fwspec->ops ? 0 : -EINVAL;
+
+fwspec = xzalloc(struct iommu_fwspec);
+if (!fwspec)
+return -ENOMEM;
+
+/* Ref counting for the dt device node is not needed */
+
+/*of_node_get(to_of_node(iommu_fwnode));*/
+
+fwspec->iommu_fwnode = iommu_fwnode;
+fwspec->ops = ops;
+dev->iommu_fwspec = fwspec;
+return 0;
+}
+
+void iommu_fwspec_free(struct device *dev)
+{
+struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+
+if (fwspec) {
+/*fwnode_handle_put(fwspec->iommu_fwnode);*/
+xfree(fwspec);
+dev->iommu_fwspec = NULL;
+}
+}
+
+int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids)
+{
+struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+size_t size;
+int i;
+
+if (!fwspec)
+return -EINVAL;
+
+size = offsetof(struct iommu_fwspec, ids[fwspec->num_ids + num_ids]);
+if (size > sizeof(*fwspec)) {
+fwspec = _xrealloc(dev->iommu_fwspec, size, sizeof(void *));
+if (!fwspec)
+return -ENOMEM;
+}
+
+for (i = 0; i < num_ids; i++)
+fwspec->ids[fwspec->num_ids + i] = ids[i];
+
+fwspec->num_ids += num_ids;
+dev->iommu_fwspec = fwspec;
+return 0;
+}
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 78c38fe..5027c87 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -21,6 +21,7 @@ struct device
 struct dt_device_node *of_node; /* Used by drivers imported from Linux */
 #endif
 struct fwnode_handle *fwnode; /*fw device node identifier */
+struct iommu_fwspec *iommu_fwspec;
 struct dev_archdata archdata;
 };
 
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 5803e3f..7ef9b93 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -224,4 +224,32 @@ DECLARE_PER_CPU(bool_t, iommu_dont_flush_iotlb);
 extern struct spinlock iommu_pt_cleanup_lock;
 extern struct page_list_head iommu_pt_cleanup_list;
 
+/**
+ * Following block was ported from Linux to help with the implementation of
+ * arm64 iommu devices. Hence the architecture specific compile
+ */
+
+#if defined(CONFIG_ARM_64) || defined(CONFIG_ARM)
+/**
+ * struct iommu_fwspec - per-device IOMMU instance data
+ * @ops: ops for this device's IOMMU
+ * @iommu_fwnode: firmware handle for this device's IOMMU
+ * @iommu_priv: IOMMU driver private data for this device
+ * @num_ids: number of associated device IDs
+ * @ids: IDs which this device may present to the IOMMU
+ */
+struct iommu_fwspec {
+   const struct iommu_ops  *ops;
+   struct fwnode_handle*iommu_fwnode;
+   void*iommu_priv;
+   unsigned intnum_ids;
+   u32 ids[1];
+};
+
+int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
+ const struct iommu_ops *ops);
+void iommu_fwspec_free(struct device *dev);
+int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids);
+
+#endif
 #endif /* _IOMMU_H_ */
-- 
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. 
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.


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

[Xen-devel] [RFC 5/6] ACPI: arm: Support for IORT

[Sameer Goel]

Verbatim files from Linux kernel.
iort.c: commit ca78d3173cff:Merge tag 'arm64-upstream'
acpi_iort.h: commit 18b709beb503:ACPI/IORT: Make dma masks set-up IORT
specific

Signed-off-by: Sameer Goel 
---
 xen/drivers/acpi/arm/iort.c  | 961 +++
 xen/include/acpi/acpi_iort.h |  58 +++
 2 files changed, 1019 insertions(+)
 create mode 100644 xen/drivers/acpi/arm/iort.c
 create mode 100644 xen/include/acpi/acpi_iort.h

diff --git a/xen/drivers/acpi/arm/iort.c b/xen/drivers/acpi/arm/iort.c
new file mode 100644
index 000..4a5bb96
--- /dev/null
+++ b/xen/drivers/acpi/arm/iort.c
@@ -0,0 +1,961 @@
+/*
+ * Copyright (C) 2016, Semihalf
+ * Author: Tomasz Nowicki 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ * This file implements early detection/parsing of I/O mapping
+ * reported to OS through firmware via I/O Remapping Table (IORT)
+ * IORT document number: ARM DEN 0049A
+ */
+
+#define pr_fmt(fmt)"ACPI: IORT: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IORT_TYPE_MASK(type)   (1 << (type))
+#define IORT_MSI_TYPE  (1 << ACPI_IORT_NODE_ITS_GROUP)
+#define IORT_IOMMU_TYPE((1 << ACPI_IORT_NODE_SMMU) |   \
+   (1 << ACPI_IORT_NODE_SMMU_V3))
+
+struct iort_its_msi_chip {
+   struct list_headlist;
+   struct fwnode_handle*fw_node;
+   u32 translation_id;
+};
+
+struct iort_fwnode {
+   struct list_head list;
+   struct acpi_iort_node *iort_node;
+   struct fwnode_handle *fwnode;
+};
+static LIST_HEAD(iort_fwnode_list);
+static DEFINE_SPINLOCK(iort_fwnode_lock);
+
+/**
+ * iort_set_fwnode() - Create iort_fwnode and use it to register
+ *iommu data in the iort_fwnode_list
+ *
+ * @node: IORT table node associated with the IOMMU
+ * @fwnode: fwnode associated with the IORT node
+ *
+ * Returns: 0 on success
+ *  <0 on failure
+ */
+static inline int iort_set_fwnode(struct acpi_iort_node *iort_node,
+ struct fwnode_handle *fwnode)
+{
+   struct iort_fwnode *np;
+
+   np = kzalloc(sizeof(struct iort_fwnode), GFP_ATOMIC);
+
+   if (WARN_ON(!np))
+   return -ENOMEM;
+
+   INIT_LIST_HEAD(>list);
+   np->iort_node = iort_node;
+   np->fwnode = fwnode;
+
+   spin_lock(_fwnode_lock);
+   list_add_tail(>list, _fwnode_list);
+   spin_unlock(_fwnode_lock);
+
+   return 0;
+}
+
+/**
+ * iort_get_fwnode() - Retrieve fwnode associated with an IORT node
+ *
+ * @node: IORT table node to be looked-up
+ *
+ * Returns: fwnode_handle pointer on success, NULL on failure
+ */
+static inline
+struct fwnode_handle *iort_get_fwnode(struct acpi_iort_node *node)
+{
+   struct iort_fwnode *curr;
+   struct fwnode_handle *fwnode = NULL;
+
+   spin_lock(_fwnode_lock);
+   list_for_each_entry(curr, _fwnode_list, list) {
+   if (curr->iort_node == node) {
+   fwnode = curr->fwnode;
+   break;
+   }
+   }
+   spin_unlock(_fwnode_lock);
+
+   return fwnode;
+}
+
+/**
+ * iort_delete_fwnode() - Delete fwnode associated with an IORT node
+ *
+ * @node: IORT table node associated with fwnode to delete
+ */
+static inline void iort_delete_fwnode(struct acpi_iort_node *node)
+{
+   struct iort_fwnode *curr, *tmp;
+
+   spin_lock(_fwnode_lock);
+   list_for_each_entry_safe(curr, tmp, _fwnode_list, list) {
+   if (curr->iort_node == node) {
+   list_del(>list);
+   kfree(curr);
+   break;
+   }
+   }
+   spin_unlock(_fwnode_lock);
+}
+
+typedef acpi_status (*iort_find_node_callback)
+   (struct acpi_iort_node *node, void *context);
+
+/* Root pointer to the mapped IORT table */
+static struct acpi_table_header *iort_table;
+
+static LIST_HEAD(iort_msi_chip_list);
+static DEFINE_SPINLOCK(iort_msi_chip_lock);
+
+/**
+ * iort_register_domain_token() - register domain token and related ITS ID
+ * to the list from where we can get it back later on.
+ * @trans_id: ITS ID.
+ * @fw_node: Domain token.
+ *
+ * Returns: 0 on success, -ENOMEM if no memory when allocating list element
+ */
+int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node)
+{
+   struct iort_its_msi_chip *its_msi_chip;
+
+   its_msi_chip = kzalloc(sizeof(*its_msi_chip), GFP_KERNEL);
+   if (!its_msi_chip)

[Xen-devel] [RFC 6/6] acpi:arm64: Add support for parsing IORT table

[Sameer Goel]

Add limited support for parsing IORT table to initialize SMMU devices.

Signed-off-by: Sameer Goel 
---
 xen/arch/arm/setup.c|   3 +
 xen/drivers/acpi/Makefile   |   1 +
 xen/drivers/acpi/arm/Makefile   |   1 +
 xen/drivers/acpi/arm/iort.c | 232 +++-
 xen/drivers/passthrough/arm/iommu.c |  15 +--
 xen/include/acpi/acpi.h |   1 +
 xen/include/acpi/acpi_iort.h|  25 ++--
 xen/include/asm-arm/device.h|   2 +
 xen/include/xen/acpi.h  |  21 
 xen/include/xen/lib.h   |   7 +-
 xen/include/xen/pci.h   |   1 +
 11 files changed, 184 insertions(+), 125 deletions(-)
 create mode 100644 xen/drivers/acpi/arm/Makefile

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 92a2de6..5dc93ff 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -753,6 +753,9 @@ void __init start_xen(unsigned long boot_phys_offset,
 /* Parse the ACPI tables for possible boot-time configuration */
 acpi_boot_table_init();
 
+/* Initialize the IORT tables */
+acpi_iort_init();
+
 if ( acpi_disabled )
 printk("Booting using Device Tree\n");
 else
diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile
index 444b11d..4165318 100644
--- a/xen/drivers/acpi/Makefile
+++ b/xen/drivers/acpi/Makefile
@@ -1,5 +1,6 @@
 subdir-y += tables
 subdir-y += utilities
+subdir-$(CONFIG_ARM_64) += arm
 subdir-$(CONFIG_X86) += apei
 
 obj-bin-y += tables.init.o
diff --git a/xen/drivers/acpi/arm/Makefile b/xen/drivers/acpi/arm/Makefile
new file mode 100644
index 000..7c039bb
--- /dev/null
+++ b/xen/drivers/acpi/arm/Makefile
@@ -0,0 +1 @@
+obj-y += iort.o
diff --git a/xen/drivers/acpi/arm/iort.c b/xen/drivers/acpi/arm/iort.c
index 4a5bb96..c22ec31 100644
--- a/xen/drivers/acpi/arm/iort.c
+++ b/xen/drivers/acpi/arm/iort.c
@@ -14,29 +14,40 @@
  * This file implements early detection/parsing of I/O mapping
  * reported to OS through firmware via I/O Remapping Table (IORT)
  * IORT document number: ARM DEN 0049A
+ *
+ * Based on Linux drivers/acpi/arm64/iort.c
+ * => commit ca78d3173cff3503bcd15723b049757f75762d15
+ *
+ * Xen modification:
+ * Sameer Goel 
+ * Copyright (C) 2017, The Linux Foundation, All rights reserved.
+ *
  */
 
-#define pr_fmt(fmt)"ACPI: IORT: " fmt
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 
 #define IORT_TYPE_MASK(type)   (1 << (type))
 #define IORT_MSI_TYPE  (1 << ACPI_IORT_NODE_ITS_GROUP)
 #define IORT_IOMMU_TYPE((1 << ACPI_IORT_NODE_SMMU) |   \
(1 << ACPI_IORT_NODE_SMMU_V3))
 
+#if 0
 struct iort_its_msi_chip {
struct list_headlist;
struct fwnode_handle*fw_node;
u32 translation_id;
 };
 
+#endif
+
 struct iort_fwnode {
struct list_head list;
struct acpi_iort_node *iort_node;
@@ -60,7 +71,7 @@ static inline int iort_set_fwnode(struct acpi_iort_node 
*iort_node,
 {
struct iort_fwnode *np;
 
-   np = kzalloc(sizeof(struct iort_fwnode), GFP_ATOMIC);
+   np = xzalloc(struct iort_fwnode);
 
if (WARN_ON(!np))
return -ENOMEM;
@@ -114,7 +125,7 @@ static inline void iort_delete_fwnode(struct acpi_iort_node 
*node)
list_for_each_entry_safe(curr, tmp, _fwnode_list, list) {
if (curr->iort_node == node) {
list_del(>list);
-   kfree(curr);
+   xfree(curr);
break;
}
}
@@ -127,6 +138,7 @@ typedef acpi_status (*iort_find_node_callback)
 /* Root pointer to the mapped IORT table */
 static struct acpi_table_header *iort_table;
 
+#if 0
 static LIST_HEAD(iort_msi_chip_list);
 static DEFINE_SPINLOCK(iort_msi_chip_lock);
 
@@ -199,7 +211,7 @@ struct fwnode_handle *iort_find_domain_token(int trans_id)
 
return fw_node;
 }
-
+#endif
 static struct acpi_iort_node *iort_scan_node(enum acpi_iort_node_type type,
 iort_find_node_callback callback,
 void *context)
@@ -219,9 +231,10 @@ static struct acpi_iort_node *iort_scan_node(enum 
acpi_iort_node_type type,
iort_table->length);
 
for (i = 0; i < iort->node_count; i++) {
-   if (WARN_TAINT(iort_node >= iort_end, TAINT_FIRMWARE_WORKAROUND,
-  "IORT node pointer overflows, bad table!\n"))
+   if (iort_node >= iort_end) {
+   printk(XENLOG_ERR "IORT node pointer overflows, bad 
table!\n");
return NULL;
+   }
 
if (iort_node->type == type &&
ACPI_SUCCESS(callback(iort_node, context)))
@@ 

[Xen-devel] [RFC 0/6] IORT support and introduce fwspec

[Sameer Goel]

This changelist is in preparation for porting the latest SMMUv3 driver from
Linux kernel  4.11 release.

Scope of the changes:
- Introduce the iommu_fwspec implementation
* This implementation is a direct port from Linux. The code that is not
  needed for Xen is removed.
- IORT port from Linux. The differences are as under:
* The DMA ops are removed.
* Modified the code for creating the SMMU devices. This also initializes
  the discoverd SMMU devices.
* MSI code is commented out till the MSI framework API usage is clearer.
* IORT node data parsing is delegated to the driver. Looking for comments
  on enabling the code in IORT driver. This will need a standard resource
  object. (Direct port from Linux or a new define for Xen?)
* Assumptions on PCI IORT SMMU interaction. PCI assign device will call
  iort_iommu_configure to setup the streamids.Then it will call SMMU
  assign device with the right struct device argument.

Sameer Goel (6):
  passthrough/arm: Modify SMMU driver to use generic device definition
  arm64: Add definitions for fwnode_handle
  Introduce _xrealloc
  xen/passthrough/arm: Introduce iommu_fwspec
  ACPI: arm: Support for IORT
  acpi:arm64: Add support for parsing IORT table

 xen/arch/arm/setup.c|   3 +
 xen/common/xmalloc_tlsf.c   |  13 +
 xen/drivers/acpi/Makefile   |   1 +
 xen/drivers/acpi/arm/Makefile   |   1 +
 xen/drivers/acpi/arm/iort.c | 977 
 xen/drivers/passthrough/arm/iommu.c |  58 +++
 xen/drivers/passthrough/arm/smmu.c  |  12 +-
 xen/include/acpi/acpi.h |   1 +
 xen/include/acpi/acpi_iort.h|  65 +++
 xen/include/asm-arm/device.h|   5 +
 xen/include/xen/acpi.h  |  21 +
 xen/include/xen/fwnode.h|  35 ++
 xen/include/xen/iommu.h |  28 ++
 xen/include/xen/lib.h   |   7 +-
 xen/include/xen/pci.h   |   1 +
 xen/include/xen/xmalloc.h   |   1 +
 16 files changed, 1222 insertions(+), 7 deletions(-)
 create mode 100644 xen/drivers/acpi/arm/Makefile
 create mode 100644 xen/drivers/acpi/arm/iort.c
 create mode 100644 xen/include/acpi/acpi_iort.h
 create mode 100644 xen/include/xen/fwnode.h

-- 
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. 
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

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

[Xen-devel] [RFC 3/6] Introduce _xrealloc

[Sameer Goel]

Introduce a memory realloc function.

Signed-off-by: Sameer Goel 
---
 xen/common/xmalloc_tlsf.c | 13 +
 xen/include/xen/xmalloc.h |  1 +
 2 files changed, 14 insertions(+)

diff --git a/xen/common/xmalloc_tlsf.c b/xen/common/xmalloc_tlsf.c
index b256dc5..52385a8 100644
--- a/xen/common/xmalloc_tlsf.c
+++ b/xen/common/xmalloc_tlsf.c
@@ -612,6 +612,19 @@ void *_xzalloc(unsigned long size, unsigned long align)
 return p ? memset(p, 0, size) : p;
 }
 
+void *_xrealloc(void *p, unsigned long new_size, unsigned long align)
+{
+void *new_p = _xmalloc(new_size, align);
+
+if(new_p && p)
+{
+memcpy(new_p, p, new_size);
+xfree(p);
+}
+
+return new_p;
+}
+
 void xfree(void *p)
 {
 struct bhdr *b;
diff --git a/xen/include/xen/xmalloc.h b/xen/include/xen/xmalloc.h
index 24a99ac..41a9b2f 100644
--- a/xen/include/xen/xmalloc.h
+++ b/xen/include/xen/xmalloc.h
@@ -29,6 +29,7 @@ extern void xfree(void *);
 /* Underlying functions */
 extern void *_xmalloc(unsigned long size, unsigned long align);
 extern void *_xzalloc(unsigned long size, unsigned long align);
+extern void *_xrealloc(void *p, unsigned long new_size, unsigned long align);
 
 static inline void *_xmalloc_array(
 unsigned long size, unsigned long align, unsigned long num)
-- 
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. 
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.


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

[Xen-devel] [RFC 2/6] arm64: Add definitions for fwnode_handle

[Sameer Goel]

This will be used as a device property to match the DMA capable devices
with the associated SMMU. The header file is a port from linux.

Linux ChangeId:ce793486e23e: driver core / ACPI: Represent ACPI
companions using fwnode_handle

Signed-off-by: Sameer Goel 
---
 xen/include/asm-arm/device.h |  2 ++
 xen/include/xen/fwnode.h | 35 +++
 2 files changed, 37 insertions(+)
 create mode 100644 xen/include/xen/fwnode.h

diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 6734ae8..78c38fe 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -2,6 +2,7 @@
 #define __ASM_ARM_DEVICE_H
 
 #include 
+#include 
 
 enum device_type
 {
@@ -19,6 +20,7 @@ struct device
 #ifdef CONFIG_HAS_DEVICE_TREE
 struct dt_device_node *of_node; /* Used by drivers imported from Linux */
 #endif
+struct fwnode_handle *fwnode; /*fw device node identifier */
 struct dev_archdata archdata;
 };
 
diff --git a/xen/include/xen/fwnode.h b/xen/include/xen/fwnode.h
new file mode 100644
index 000..db65b15
--- /dev/null
+++ b/xen/include/xen/fwnode.h
@@ -0,0 +1,35 @@
+/*
+ * fwnode.h - Firmware device node object handle type definition.
+ *
+ * Copyright (C) 2015, Intel Corporation
+ * Author: Rafael J. Wysocki 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Ported from Linux include/linux/fwnode.h
+ *  => commit ce793486e23e0162a732c605189c8028e0910e86
+ *
+ * No functional Xen modifications.
+ */
+
+#ifndef __XEN_FWNODE_H_
+#define __XEN_FWNODE_H_
+
+enum fwnode_type {
+   FWNODE_INVALID = 0,
+   FWNODE_OF,
+   FWNODE_ACPI,
+   FWNODE_ACPI_DATA,
+   FWNODE_ACPI_STATIC,
+   FWNODE_PDATA,
+   FWNODE_IRQCHIP
+};
+
+struct fwnode_handle {
+   enum fwnode_type type;
+   struct fwnode_handle *secondary;
+};
+
+#endif
-- 
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. 
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.


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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop  fail blocked in 110071
 test-armhf-armhf-xl-rtds   15 guest-start/debian.repeat fail blocked in 110071
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 110071
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 110071
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 110071
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 110071
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 110071
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 110071
 test-amd64-amd64-xl-qemut-ws16-amd64  9 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64  9 windows-installfail never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-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-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-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-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-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-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386  9 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386  9 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386  9 windows-installfail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64  9 windows-install fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64  9 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386  9 windows-installfail never pass

version targeted for testing:
 xen  08463297d33d075b6529229c9d43c90356093bae
baseline version:
 xen  3d2010f9ffeacc8836811420460e15f2c1233695

Last test of basis   110071  2017-06-07 08:24:59 Z1 days
Testing same since   110102  2017-06-07 23:50:34 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian 

[Xen-devel] [PATCH v2 1/1] xl.cfg man page cleanup and fixes

[Armando Vega]

- fixed some minor numbering and syntax issues in the CPU allocation
  examples for the 'cpus' option
- semantic fixes to make explanations more clear throughout
- fixed all the typo's I could see
- general styling and makeup fixes to make everything look more consistent

Signed-off-by: Armando Vega 
Reviewed-by: Dario Faggioli 
---
 docs/man/xl.cfg.pod.5.in | 1107 --
 1 file changed, 588 insertions(+), 519 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 13167ff2b6..06ffd59980 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -1,6 +1,6 @@
 =head1 NAME
 
-xl.cfg - XL Domain Configuration File Syntax
+xl.cfg - xl domain configuration file syntax
 
 =head1 SYNOPSIS
 
@@ -8,20 +8,21 @@ xl.cfg - XL Domain Configuration File Syntax
 
 =head1 DESCRIPTION
 
-To create a VM (a domain in Xen terminology, sometimes called a guest)
-with xl requires the provision of a domain config file.  Typically
-these live in `/etc/xen/DOMAIN.cfg` where DOMAIN is the name of the
+Creating a VM (a domain in Xen terminology, sometimes called a guest)
+with xl requires the provision of a domain configuration file.  Typically,
+these live in F, where DOMAIN is the name of the
 domain.
 
 =head1 SYNTAX
 
-A domain config file consists of a series of 

[Xen-devel] [PATCH v2 0/1] xl.cfg man page cleanup and fixes

[Armando Vega]

Hey everyone,

so I'm respinning the patch after Dario confirmed the NUMA example is correct
now.

Armando Vega (1):
  xl.cfg man page cleanup and fixes

 docs/man/xl.cfg.pod.5.in | 1107 --
 1 file changed, 588 insertions(+), 519 deletions(-)

-- 
2.11.0


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

Re: [Xen-devel] [for-4.9] Re: HVM guest performance regression

[Juergen Gross]

On 08/06/17 20:09, Stefano Stabellini wrote:
> On Thu, 8 Jun 2017, Juergen Gross wrote:
>> On 07/06/17 20:19, Stefano Stabellini wrote:
>>> On Wed, 7 Jun 2017, Juergen Gross wrote:
 On 06/06/17 21:08, Stefano Stabellini wrote:
> On Tue, 6 Jun 2017, Juergen Gross wrote:
>> On 06/06/17 18:39, Stefano Stabellini wrote:
>>> On Tue, 6 Jun 2017, Juergen Gross wrote:
 On 26/05/17 21:01, Stefano Stabellini wrote:
> On Fri, 26 May 2017, Juergen Gross wrote:
>> On 26/05/17 18:19, Ian Jackson wrote:
>>> Juergen Gross writes ("HVM guest performance regression"):
 Looking for the reason of a performance regression of HVM guests 
 under
 Xen 4.7 against 4.5 I found the reason to be commit
 c26f92b8fce3c9df17f7ef035b54d97cbe931c7a ("libxl: remove 
 freemem_slack")
 in Xen 4.6.

 The problem occurred when dom0 had to be ballooned down when 
 starting
 the guest. The performance of some micro benchmarks dropped by 
 about
 a factor of 2 with above commit.

 Interesting point is that the performance of the guest will depend 
 on
 the amount of free memory being available at guest creation time.
 When there was barely enough memory available for starting the 
 guest
 the performance will remain low even if memory is being freed 
 later.

 I'd like to suggest we either revert the commit or have some other
 mechanism to try to have some reserve free memory when starting a
 domain.
>>>
>>> Oh, dear.  The memory accounting swamp again.  Clearly we are not
>>> going to drain that swamp now, but I don't like regressions.
>>>
>>> I am not opposed to reverting that commit.  I was a bit iffy about 
>>> it
>>> at the time; and according to the removal commit message, it was
>>> basically removed because it was a piece of cargo cult for which we
>>> had no justification in any of our records.
>>>
>>> Indeed I think fixing this is a candidate for 4.9.
>>>
>>> Do you know the mechanism by which the freemem slack helps ?  I 
>>> think
>>> that would be a prerequisite for reverting this.  That way we can 
>>> have
>>> an understanding of why we are doing things, rather than just
>>> flailing at random...
>>
>> I wish I would understand it.
>>
>> One candidate would be 2M/1G pages being possible with enough free
>> memory, but I haven't proofed this yet. I can have a try by disabling
>> big pages in the hypervisor.
>
> Right, if I had to bet, I would put my money on superpages shattering
> being the cause of the problem.

 Seems you would have lost your money...

 Meanwhile I've found a way to get the "good" performance in the micro
 benchmark. Unfortunately this requires to switch off the pv interfaces
 in the HVM guest via "xen_nopv" kernel boot parameter.

 I have verified that pv spinlocks are not to blame (via "xen_nopvspin"
 kernel boot parameter). Switching to clocksource TSC in the running
 system doesn't help either.
>>>
>>> What about xen_hvm_exit_mmap (an optimization for shadow pagetables) and
>>> xen_hvm_smp_init (PV IPI)?
>>
>> xen_hvm_exit_mmap isn't active (kernel message telling me so was
>> issued).
>>
 Unfortunately the kernel seems no longer to be functional when I try to
 tweak it not to use the PVHVM enhancements.
>>>
>>> I guess you are not talking about regular PV drivers like netfront and
>>> blkfront, right?
>>
>> The plan was to be able to use PV drivers without having to use PV
>> callbacks and PV timers. This isn't possible right now.
>
> I think the code to handle that scenario was gradually removed over time
> to simplify the code base.

 Hmm, too bad.

 I'm wondering now whether
 there have ever been any benchmarks to proof PVHVM really being faster
 than non-PVHVM? My findings seem to suggest there might be a huge
 performance gap with PVHVM. OTOH this might depend on hardware and 
 other
 factors.

 Stefano, didn't you do the PVHVM stuff back in 2010? Do you have any
 data from then regarding performance figures?
>>>
>>> Yes, I still have these slides:
>>>
>>> https://www.slideshare.net/xen_com_mgr/linux-pv-on-hvm
>>
>> Thanks. So you measured the overall package, not the single items like
>> callbacks, timers, time source? I'm asking because I start to believe
>> there are some of those slower 

Re: [Xen-devel] [PATCH v2] xen: avoid type warning in xchg_xen_ulong

[Stefano Stabellini]

On Thu, 8 Jun 2017, Arnd Bergmann wrote:
> The improved type-checking version of container_of() triggers a warning for
> xchg_xen_ulong, pointing out that 'xen_ulong_t' is unsigned, but atomic64_t
> contains a signed value:
> 
> drivers/xen/events/events_2l.c: In function 'evtchn_2l_handle_events':
> drivers/xen/events/events_2l.c:187:1020: error: call to 
> '__compiletime_assert_187' declared with attribute error: pointer type 
> mismatch in container_of()
> 
> This adds a cast to work around the warning.
> 
> Cc: Ian Abbott 
> Fixes: 85323a991d40 ("xen: arm: mandate EABI and use generic atomic 
> operations.")
> Fixes: daa2ac80834d ("kernel.h: handle pointers to arrays better in 
> container_of()")
> Signed-off-by: Arnd Bergmann 

Reviewed-by: Stefano Stabellini 

I'll queue it up on xentip for Linux 4.13.


> ---
> v2: found the correct warning message and updated the changelog
> ---
>  arch/arm/include/asm/xen/events.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/xen/events.h 
> b/arch/arm/include/asm/xen/events.h
> index 71e473d05fcc..620dc75362e5 100644
> --- a/arch/arm/include/asm/xen/events.h
> +++ b/arch/arm/include/asm/xen/events.h
> @@ -16,7 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
>   return raw_irqs_disabled_flags(regs->ARM_cpsr);
>  }
>  
> -#define xchg_xen_ulong(ptr, val) atomic64_xchg(container_of((ptr),   \
> +#define xchg_xen_ulong(ptr, val) atomic64_xchg(container_of((long 
> long*)(ptr),\
>   atomic64_t, \
>   counter), (val))
>  
> -- 
> 2.9.0
> 

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

Re: [Xen-devel] [for-4.9] Re: HVM guest performance regression

[Stefano Stabellini]

On Thu, 8 Jun 2017, Juergen Gross wrote:
> On 07/06/17 20:19, Stefano Stabellini wrote:
> > On Wed, 7 Jun 2017, Juergen Gross wrote:
> >> On 06/06/17 21:08, Stefano Stabellini wrote:
> >>> On Tue, 6 Jun 2017, Juergen Gross wrote:
>  On 06/06/17 18:39, Stefano Stabellini wrote:
> > On Tue, 6 Jun 2017, Juergen Gross wrote:
> >> On 26/05/17 21:01, Stefano Stabellini wrote:
> >>> On Fri, 26 May 2017, Juergen Gross wrote:
>  On 26/05/17 18:19, Ian Jackson wrote:
> > Juergen Gross writes ("HVM guest performance regression"):
> >> Looking for the reason of a performance regression of HVM guests 
> >> under
> >> Xen 4.7 against 4.5 I found the reason to be commit
> >> c26f92b8fce3c9df17f7ef035b54d97cbe931c7a ("libxl: remove 
> >> freemem_slack")
> >> in Xen 4.6.
> >>
> >> The problem occurred when dom0 had to be ballooned down when 
> >> starting
> >> the guest. The performance of some micro benchmarks dropped by 
> >> about
> >> a factor of 2 with above commit.
> >>
> >> Interesting point is that the performance of the guest will depend 
> >> on
> >> the amount of free memory being available at guest creation time.
> >> When there was barely enough memory available for starting the 
> >> guest
> >> the performance will remain low even if memory is being freed 
> >> later.
> >>
> >> I'd like to suggest we either revert the commit or have some other
> >> mechanism to try to have some reserve free memory when starting a
> >> domain.
> >
> > Oh, dear.  The memory accounting swamp again.  Clearly we are not
> > going to drain that swamp now, but I don't like regressions.
> >
> > I am not opposed to reverting that commit.  I was a bit iffy about 
> > it
> > at the time; and according to the removal commit message, it was
> > basically removed because it was a piece of cargo cult for which we
> > had no justification in any of our records.
> >
> > Indeed I think fixing this is a candidate for 4.9.
> >
> > Do you know the mechanism by which the freemem slack helps ?  I 
> > think
> > that would be a prerequisite for reverting this.  That way we can 
> > have
> > an understanding of why we are doing things, rather than just
> > flailing at random...
> 
>  I wish I would understand it.
> 
>  One candidate would be 2M/1G pages being possible with enough free
>  memory, but I haven't proofed this yet. I can have a try by disabling
>  big pages in the hypervisor.
> >>>
> >>> Right, if I had to bet, I would put my money on superpages shattering
> >>> being the cause of the problem.
> >>
> >> Seems you would have lost your money...
> >>
> >> Meanwhile I've found a way to get the "good" performance in the micro
> >> benchmark. Unfortunately this requires to switch off the pv interfaces
> >> in the HVM guest via "xen_nopv" kernel boot parameter.
> >>
> >> I have verified that pv spinlocks are not to blame (via "xen_nopvspin"
> >> kernel boot parameter). Switching to clocksource TSC in the running
> >> system doesn't help either.
> >
> > What about xen_hvm_exit_mmap (an optimization for shadow pagetables) and
> > xen_hvm_smp_init (PV IPI)?
> 
>  xen_hvm_exit_mmap isn't active (kernel message telling me so was
>  issued).
> 
> >> Unfortunately the kernel seems no longer to be functional when I try to
> >> tweak it not to use the PVHVM enhancements.
> >
> > I guess you are not talking about regular PV drivers like netfront and
> > blkfront, right?
> 
>  The plan was to be able to use PV drivers without having to use PV
>  callbacks and PV timers. This isn't possible right now.
> >>>
> >>> I think the code to handle that scenario was gradually removed over time
> >>> to simplify the code base.
> >>
> >> Hmm, too bad.
> >>
> >> I'm wondering now whether
> >> there have ever been any benchmarks to proof PVHVM really being faster
> >> than non-PVHVM? My findings seem to suggest there might be a huge
> >> performance gap with PVHVM. OTOH this might depend on hardware and 
> >> other
> >> factors.
> >>
> >> Stefano, didn't you do the PVHVM stuff back in 2010? Do you have any
> >> data from then regarding performance figures?
> >
> > Yes, I still have these slides:
> >
> > https://www.slideshare.net/xen_com_mgr/linux-pv-on-hvm
> 
>  Thanks. So you measured the overall package, not the single items like
>  callbacks, timers, time source? I'm asking because I start to believe
>  there are some of those slower than their non-PV variants.
> >>>
> >>> There 

[Xen-devel] [libvirt test] 110107: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 110065
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 110065
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 110065
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 saverestore-support-checkfail 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-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  e146264aaadf5aecf727d8c7b3d85683b55b6c48
baseline version:
 libvirt  46f5eca4b2d2e5685cd334f8351a1e62dce261ee

Last test of basis   110065  2017-06-07 04:20:12 Z1 days
Testing same since   110107  2017-06-08 04:22:16 Z0 days1 attempts


People who touched revisions under test:
  Erik Skultety 
  Jiri Denemark 
  Ján Tomko 
  Laine Stump 
  Michal Privoznik 
  Peter Krempa 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 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 pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 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   pass
 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
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

Re: [Xen-devel] [PATCH v2] xen: fix HYPERVISOR_dm_op() prototype

[Juergen Gross]

On 07/06/17 09:20, Sergey Dyasli wrote:
> Change the third parameter to be the required struct xen_dm_op_buf *
> instead of a generic void * (which blindly accepts any pointer).
> 
> Signed-off-by: Sergey Dyasli 

Committed to xen/tip.git for-linus-4.13


Thanks,

Juergen

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

[Xen-devel] [PATCH v4 20/27] x86: move hypercall_page_initialise_ring1_kernel

[Wei Liu]

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/hypercall.c| 31 +++
 xen/arch/x86/x86_64/compat/traps.c | 31 ---
 xen/include/asm-x86/hypercall.h|  1 +
 3 files changed, 32 insertions(+), 31 deletions(-)

diff --git a/xen/arch/x86/pv/hypercall.c b/xen/arch/x86/pv/hypercall.c
index 287340e774..58dc0f5c32 100644
--- a/xen/arch/x86/pv/hypercall.c
+++ b/xen/arch/x86/pv/hypercall.c
@@ -291,6 +291,37 @@ void hypercall_page_initialise_ring3_kernel(void 
*hypercall_page)
 *(u16 *)(p+ 9) = 0x050f;  /* syscall */
 }
 
+void hypercall_page_initialise_ring1_kernel(void *hypercall_page)
+{
+char *p;
+int i;
+
+/* Fill in all the transfer points with template machine code. */
+
+for ( i = 0; i < (PAGE_SIZE / 32); i++ )
+{
+if ( i == __HYPERVISOR_iret )
+continue;
+
+p = (char *)(hypercall_page + (i * 32));
+*(u8  *)(p+ 0) = 0xb8;/* mov  $,%eax */
+*(u32 *)(p+ 1) = i;
+*(u16 *)(p+ 5) = (HYPERCALL_VECTOR << 8) | 0xcd; /* int  $xx */
+*(u8  *)(p+ 7) = 0xc3;/* ret */
+}
+
+/*
+ * HYPERVISOR_iret is special because it doesn't return and expects a
+ * special stack frame. Guests jump at this transfer point instead of
+ * calling it.
+ */
+p = (char *)(hypercall_page + (__HYPERVISOR_iret * 32));
+*(u8  *)(p+ 0) = 0x50;/* push %eax */
+*(u8  *)(p+ 1) = 0xb8;/* mov  $__HYPERVISOR_iret,%eax */
+*(u32 *)(p+ 2) = __HYPERVISOR_iret;
+*(u16 *)(p+ 6) = (HYPERCALL_VECTOR << 8) | 0xcd; /* int  $xx */
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/x86_64/compat/traps.c 
b/xen/arch/x86/x86_64/compat/traps.c
index 1751ec67e8..f485299c88 100644
--- a/xen/arch/x86/x86_64/compat/traps.c
+++ b/xen/arch/x86/x86_64/compat/traps.c
@@ -374,37 +374,6 @@ int 
compat_set_trap_table(XEN_GUEST_HANDLE(trap_info_compat_t) traps)
 return rc;
 }
 
-static void hypercall_page_initialise_ring1_kernel(void *hypercall_page)
-{
-char *p;
-int i;
-
-/* Fill in all the transfer points with template machine code. */
-
-for ( i = 0; i < (PAGE_SIZE / 32); i++ )
-{
-if ( i == __HYPERVISOR_iret )
-continue;
-
-p = (char *)(hypercall_page + (i * 32));
-*(u8  *)(p+ 0) = 0xb8;/* mov  $,%eax */
-*(u32 *)(p+ 1) = i;
-*(u16 *)(p+ 5) = (HYPERCALL_VECTOR << 8) | 0xcd; /* int  $xx */
-*(u8  *)(p+ 7) = 0xc3;/* ret */
-}
-
-/*
- * HYPERVISOR_iret is special because it doesn't return and expects a
- * special stack frame. Guests jump at this transfer point instead of
- * calling it.
- */
-p = (char *)(hypercall_page + (__HYPERVISOR_iret * 32));
-*(u8  *)(p+ 0) = 0x50;/* push %eax */
-*(u8  *)(p+ 1) = 0xb8;/* mov  $__HYPERVISOR_iret,%eax */
-*(u32 *)(p+ 2) = __HYPERVISOR_iret;
-*(u16 *)(p+ 6) = (HYPERCALL_VECTOR << 8) | 0xcd; /* int  $xx */
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-x86/hypercall.h b/xen/include/asm-x86/hypercall.h
index 5631cf2694..3eb4a8db89 100644
--- a/xen/include/asm-x86/hypercall.h
+++ b/xen/include/asm-x86/hypercall.h
@@ -27,6 +27,7 @@ extern const hypercall_args_t 
hypercall_args_table[NR_hypercalls];
 
 void pv_hypercall(struct cpu_user_regs *regs);
 void hypercall_page_initialise_ring3_kernel(void *hypercall_page);
+void hypercall_page_initialise_ring1_kernel(void *hypercall_page);
 
 /*
  * Both do_mmuext_op() and do_mmu_update():
-- 
2.11.0


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

[Xen-devel] [PATCH v4 24/27] x86: move compat_show_guest_statck near its non-compat variant

[Wei Liu]

And make it static, remove the declaration in header.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/traps.c   | 64 ++
 xen/arch/x86/x86_64/compat/traps.c | 63 -
 xen/include/asm-x86/processor.h|  3 --
 3 files changed, 64 insertions(+), 66 deletions(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 287503cd56..0cedd5159b 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -186,6 +186,70 @@ static void show_code(const struct cpu_user_regs *regs)
 printk("\n");
 }
 
+static void compat_show_guest_stack(struct vcpu *v,
+const struct cpu_user_regs *regs,
+int debug_stack_lines)
+{
+unsigned int i, *stack, addr, mask = STACK_SIZE;
+
+stack = (unsigned int *)(unsigned long)regs->esp;
+printk("Guest stack trace from esp=%08lx:\n ", (unsigned long)stack);
+
+if ( !__compat_access_ok(v->domain, stack, sizeof(*stack)) )
+{
+printk("Guest-inaccessible memory.\n");
+return;
+}
+
+if ( v != current )
+{
+struct vcpu *vcpu;
+unsigned long mfn;
+
+ASSERT(guest_kernel_mode(v, regs));
+mfn = read_cr3() >> PAGE_SHIFT;
+for_each_vcpu( v->domain, vcpu )
+if ( pagetable_get_pfn(vcpu->arch.guest_table) == mfn )
+break;
+if ( !vcpu )
+{
+stack = do_page_walk(v, (unsigned long)stack);
+if ( (unsigned long)stack < PAGE_SIZE )
+{
+printk("Inaccessible guest memory.\n");
+return;
+}
+mask = PAGE_SIZE;
+}
+}
+
+for ( i = 0; i < debug_stack_lines * 8; i++ )
+{
+if ( (((long)stack - 1) ^ ((long)(stack + 1) - 1)) & mask )
+break;
+if ( __get_user(addr, stack) )
+{
+if ( i != 0 )
+printk("\n");
+printk("Fault while accessing guest memory.");
+i = 1;
+break;
+}
+if ( (i != 0) && ((i % 8) == 0) )
+printk("\n ");
+printk(" %08x", addr);
+stack++;
+}
+if ( mask == PAGE_SIZE )
+{
+BUILD_BUG_ON(PAGE_SIZE == STACK_SIZE);
+unmap_domain_page(stack);
+}
+if ( i == 0 )
+printk("Stack empty.");
+printk("\n");
+}
+
 static void show_guest_stack(struct vcpu *v, const struct cpu_user_regs *regs)
 {
 int i;
diff --git a/xen/arch/x86/x86_64/compat/traps.c 
b/xen/arch/x86/x86_64/compat/traps.c
index 6e146a62a7..18cd2c017c 100644
--- a/xen/arch/x86/x86_64/compat/traps.c
+++ b/xen/arch/x86/x86_64/compat/traps.c
@@ -3,69 +3,6 @@
 #include 
 #include 
 
-void compat_show_guest_stack(struct vcpu *v, const struct cpu_user_regs *regs,
- int debug_stack_lines)
-{
-unsigned int i, *stack, addr, mask = STACK_SIZE;
-
-stack = (unsigned int *)(unsigned long)regs->esp;
-printk("Guest stack trace from esp=%08lx:\n ", (unsigned long)stack);
-
-if ( !__compat_access_ok(v->domain, stack, sizeof(*stack)) )
-{
-printk("Guest-inaccessible memory.\n");
-return;
-}
-
-if ( v != current )
-{
-struct vcpu *vcpu;
-unsigned long mfn;
-
-ASSERT(guest_kernel_mode(v, regs));
-mfn = read_cr3() >> PAGE_SHIFT;
-for_each_vcpu( v->domain, vcpu )
-if ( pagetable_get_pfn(vcpu->arch.guest_table) == mfn )
-break;
-if ( !vcpu )
-{
-stack = do_page_walk(v, (unsigned long)stack);
-if ( (unsigned long)stack < PAGE_SIZE )
-{
-printk("Inaccessible guest memory.\n");
-return;
-}
-mask = PAGE_SIZE;
-}
-}
-
-for ( i = 0; i < debug_stack_lines * 8; i++ )
-{
-if ( (((long)stack - 1) ^ ((long)(stack + 1) - 1)) & mask )
-break;
-if ( __get_user(addr, stack) )
-{
-if ( i != 0 )
-printk("\n");
-printk("Fault while accessing guest memory.");
-i = 1;
-break;
-}
-if ( (i != 0) && ((i % 8) == 0) )
-printk("\n ");
-printk(" %08x", addr);
-stack++;
-}
-if ( mask == PAGE_SIZE )
-{
-BUILD_BUG_ON(PAGE_SIZE == STACK_SIZE);
-unmap_domain_page(stack);
-}
-if ( i == 0 )
-printk("Stack empty.");
-printk("\n");
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
index 6a335d3a61..5bf56b45e1 100644
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -480,9 +480,6 @@ void show_execution_state(const struct cpu_user_regs *regs);
 void show_page_walk(unsigned long addr);
 void noreturn fatal_trap(const struct cpu_user_regs *regs, 

[Xen-devel] [PATCH v4 27/27] x86: clean up traps.c

[Wei Liu]

Replace bool_t with bool. Delete trailing white spaces. Fix some
coding style issues.

Signed-off-by: Wei Liu 
Acked-by: Jan Beulich 
---
 xen/arch/x86/traps.c | 77 +++-
 1 file changed, 40 insertions(+), 37 deletions(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 0cedd5159b..e568586573 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1,18 +1,18 @@
 /**
  * arch/x86/traps.c
- * 
+ *
  * Modifications to Linux original are copyright (c) 2002-2004, K A Fraser
- * 
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
  * the Free Software Foundation; either version 2 of the License, or
  * (at your option) any later version.
- * 
+ *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
- * 
+ *
  * You should have received a copy of the GNU General Public License
  * along with this program; If not, see .
  */
@@ -112,7 +112,7 @@ void (*ioemul_handle_quirk)(
 static int debug_stack_lines = 20;
 integer_param("debug_stack_lines", debug_stack_lines);
 
-static bool_t opt_ler;
+static bool opt_ler;
 boolean_param("ler", opt_ler);
 
 #define stack_words_per_line 4
@@ -591,7 +591,7 @@ void vcpu_show_execution_state(struct vcpu *v)
 }
 
 static cpumask_t show_state_mask;
-static bool_t opt_show_all;
+static bool opt_show_all;
 boolean_param("async-show-all", opt_show_all);
 
 static int nmi_show_execution_state(const struct cpu_user_regs *regs, int cpu)
@@ -602,8 +602,8 @@ static int nmi_show_execution_state(const struct 
cpu_user_regs *regs, int cpu)
 if ( opt_show_all )
 show_execution_state(regs);
 else
-printk(XENLOG_ERR "CPU%d @ %04x:%08lx (%pS)\n", cpu, regs->cs, 
regs->rip,
-   guest_mode(regs) ? _p(regs->rip) : NULL);
+printk(XENLOG_ERR "CPU%d @ %04x:%08lx (%pS)\n", cpu, regs->cs,
+   regs->rip, guest_mode(regs) ? _p(regs->rip) : NULL);
 cpumask_clear_cpu(cpu, _state_mask);
 
 return 1;
@@ -628,7 +628,7 @@ const char *trapstr(unsigned int trapnr)
  * are disabled). In such situations we can't do much that is safe. We try to
  * print out some tracing and then we just spin.
  */
-void fatal_trap(const struct cpu_user_regs *regs, bool_t show_remote)
+void fatal_trap(const struct cpu_user_regs *regs, bool show_remote)
 {
 static DEFINE_PER_CPU(char, depth);
 unsigned int trapnr = regs->entry_vector;
@@ -1081,8 +1081,8 @@ void do_int3(struct cpu_user_regs *regs)
 pv_inject_hw_exception(TRAP_int3, X86_EVENT_NO_EC);
 }
 
-static void reserved_bit_page_fault(
-unsigned long addr, struct cpu_user_regs *regs)
+static void reserved_bit_page_fault(unsigned long addr,
+struct cpu_user_regs *regs)
 {
 printk("%pv: reserved bit in page table (ec=%04X)\n",
current, regs->error_code);
@@ -1090,8 +1090,8 @@ static void reserved_bit_page_fault(
 show_execution_state(regs);
 }
 
-static int handle_gdt_ldt_mapping_fault(
-unsigned long offset, struct cpu_user_regs *regs)
+static int handle_gdt_ldt_mapping_fault(unsigned long offset,
+struct cpu_user_regs *regs)
 {
 struct vcpu *curr = current;
 /* Which vcpu's area did we fault in, and is it in the ldt sub-area? */
@@ -1159,8 +1159,8 @@ enum pf_type {
 spurious_fault
 };
 
-static enum pf_type __page_fault_type(
-unsigned long addr, const struct cpu_user_regs *regs)
+static enum pf_type __page_fault_type(unsigned long addr,
+  const struct cpu_user_regs *regs)
 {
 unsigned long mfn, cr3 = read_cr3();
 l4_pgentry_t l4e, *l4t;
@@ -1266,8 +1266,8 @@ leaf:
 return spurious_fault;
 }
 
-static enum pf_type spurious_page_fault(
-unsigned long addr, const struct cpu_user_regs *regs)
+static enum pf_type spurious_page_fault(unsigned long addr,
+const struct cpu_user_regs *regs)
 {
 unsigned long flags;
 enum pf_type pf_type;
@@ -1376,7 +1376,8 @@ void do_page_fault(struct cpu_user_regs *regs)
 if ( (pf_type == smep_fault) || (pf_type == smap_fault) )
 {
 console_start_sync();
-printk("Xen SM%cP violation\n", (pf_type == smep_fault) ? 'E' : 
'A');
+printk("Xen SM%cP violation\n",
+   (pf_type == smep_fault) ? 'E' : 'A');
 fatal_trap(regs, 0);
 }
 
@@ -1426,9 +1427,9 @@ void do_page_fault(struct cpu_user_regs *regs)
 
 /*
  * Early #PF handler to print CR2, error code, and stack.
- * 
+ *
  * We 

[Xen-devel] [PATCH v4 22/27] x86: move compat_iret along side its non-compat variant

[Wei Liu]

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/iret.c | 120 +
 xen/arch/x86/x86_64/compat/traps.c | 120 -
 2 files changed, 120 insertions(+), 120 deletions(-)

diff --git a/xen/arch/x86/pv/iret.c b/xen/arch/x86/pv/iret.c
index 358ae7cf08..013e619b3f 100644
--- a/xen/arch/x86/pv/iret.c
+++ b/xen/arch/x86/pv/iret.c
@@ -61,6 +61,126 @@ unsigned long do_iret(void)
 return 0;
 }
 
+unsigned int compat_iret(void)
+{
+struct cpu_user_regs *regs = guest_cpu_user_regs();
+struct vcpu *v = current;
+u32 eflags;
+
+/* Trim stack pointer to 32 bits. */
+regs->rsp = (u32)regs->rsp;
+
+/* Restore EAX (clobbered by hypercall). */
+if ( unlikely(__get_user(regs->eax, (u32 *)regs->rsp)) )
+{
+domain_crash(v->domain);
+return 0;
+}
+
+/* Restore CS and EIP. */
+if ( unlikely(__get_user(regs->eip, (u32 *)regs->rsp + 1)) ||
+unlikely(__get_user(regs->cs, (u32 *)regs->rsp + 2)) )
+{
+domain_crash(v->domain);
+return 0;
+}
+
+/*
+ * Fix up and restore EFLAGS. We fix up in a local staging area
+ * to avoid firing the BUG_ON(IOPL) check in arch_get_info_guest.
+ */
+if ( unlikely(__get_user(eflags, (u32 *)regs->rsp + 3)) )
+{
+domain_crash(v->domain);
+return 0;
+}
+
+if ( VM_ASSIST(v->domain, architectural_iopl) )
+v->arch.pv_vcpu.iopl = eflags & X86_EFLAGS_IOPL;
+
+regs->eflags = (eflags & ~X86_EFLAGS_IOPL) | X86_EFLAGS_IF;
+
+if ( unlikely(eflags & X86_EFLAGS_VM) )
+{
+/*
+ * Cannot return to VM86 mode: inject a GP fault instead. Note that
+ * the GP fault is reported on the first VM86 mode instruction, not on
+ * the IRET (which is why we can simply leave the stack frame as-is
+ * (except for perhaps having to copy it), which in turn seems better
+ * than teaching create_bounce_frame() to needlessly deal with vm86
+ * mode frames).
+ */
+const struct trap_info *ti;
+u32 x, ksp = v->arch.pv_vcpu.kernel_sp - 40;
+unsigned int i;
+int rc = 0;
+
+gdprintk(XENLOG_ERR, "VM86 mode unavailable (ksp:%08X->%08X)\n",
+ regs->esp, ksp);
+if ( ksp < regs->esp )
+{
+for (i = 1; i < 10; ++i)
+{
+rc |= __get_user(x, (u32 *)regs->rsp + i);
+rc |= __put_user(x, (u32 *)(unsigned long)ksp + i);
+}
+}
+else if ( ksp > regs->esp )
+{
+for ( i = 9; i > 0; --i )
+{
+rc |= __get_user(x, (u32 *)regs->rsp + i);
+rc |= __put_user(x, (u32 *)(unsigned long)ksp + i);
+}
+}
+if ( rc )
+{
+domain_crash(v->domain);
+return 0;
+}
+regs->esp = ksp;
+regs->ss = v->arch.pv_vcpu.kernel_ss;
+
+ti = >arch.pv_vcpu.trap_ctxt[TRAP_gp_fault];
+if ( TI_GET_IF(ti) )
+eflags &= ~X86_EFLAGS_IF;
+regs->eflags &= ~(X86_EFLAGS_VM|X86_EFLAGS_RF|
+  X86_EFLAGS_NT|X86_EFLAGS_TF);
+if ( unlikely(__put_user(0, (u32 *)regs->rsp)) )
+{
+domain_crash(v->domain);
+return 0;
+}
+regs->eip = ti->address;
+regs->cs = ti->cs;
+}
+else if ( unlikely(ring_0(regs)) )
+{
+domain_crash(v->domain);
+return 0;
+}
+else if ( ring_1(regs) )
+regs->esp += 16;
+/* Return to ring 2/3: restore ESP and SS. */
+else if ( __get_user(regs->ss, (u32 *)regs->rsp + 5) ||
+  __get_user(regs->esp, (u32 *)regs->rsp + 4) )
+{
+domain_crash(v->domain);
+return 0;
+}
+
+/* Restore upcall mask from supplied EFLAGS.IF. */
+vcpu_info(v, evtchn_upcall_mask) = !(eflags & X86_EFLAGS_IF);
+
+async_exception_cleanup(v);
+
+/*
+ * The hypercall exit path will overwrite EAX with this return
+ * value.
+ */
+return regs->eax;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/x86_64/compat/traps.c 
b/xen/arch/x86/x86_64/compat/traps.c
index add4af3403..df691f0ae3 100644
--- a/xen/arch/x86/x86_64/compat/traps.c
+++ b/xen/arch/x86/x86_64/compat/traps.c
@@ -66,126 +66,6 @@ void compat_show_guest_stack(struct vcpu *v, const struct 
cpu_user_regs *regs,
 printk("\n");
 }
 
-unsigned int compat_iret(void)
-{
-struct cpu_user_regs *regs = guest_cpu_user_regs();
-struct vcpu *v = current;
-u32 eflags;
-
-/* Trim stack pointer to 32 bits. */
-regs->rsp = (u32)regs->rsp;
-
-/* Restore EAX (clobbered by hypercall). */
-if ( unlikely(__get_user(regs->eax, (u32 *)regs->rsp)) )
-{
-domain_crash(v->domain);
-return 0;
-}
-
-/* Restore CS and EIP. */
-if ( unlikely(__get_user(regs->eip, (u32 

[Xen-devel] [PATCH v4 23/27] x86: move the compat callback ops next to the non-compat variant

[Wei Liu]

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/callback.c | 142 
 xen/arch/x86/x86_64/compat/traps.c | 143 -
 2 files changed, 142 insertions(+), 143 deletions(-)

diff --git a/xen/arch/x86/pv/callback.c b/xen/arch/x86/pv/callback.c
index dbd602c89d..00981d0f47 100644
--- a/xen/arch/x86/pv/callback.c
+++ b/xen/arch/x86/pv/callback.c
@@ -1,6 +1,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -155,3 +156,144 @@ long do_set_callbacks(unsigned long event_address,
 return 0;
 }
 
+static long compat_register_guest_callback(struct compat_callback_register 
*reg)
+{
+long ret = 0;
+struct vcpu *v = current;
+
+fixup_guest_code_selector(v->domain, reg->address.cs);
+
+switch ( reg->type )
+{
+case CALLBACKTYPE_event:
+v->arch.pv_vcpu.event_callback_cs = reg->address.cs;
+v->arch.pv_vcpu.event_callback_eip= reg->address.eip;
+break;
+
+case CALLBACKTYPE_failsafe:
+v->arch.pv_vcpu.failsafe_callback_cs  = reg->address.cs;
+v->arch.pv_vcpu.failsafe_callback_eip = reg->address.eip;
+if ( reg->flags & CALLBACKF_mask_events )
+set_bit(_VGCF_failsafe_disables_events,
+>arch.vgc_flags);
+else
+clear_bit(_VGCF_failsafe_disables_events,
+  >arch.vgc_flags);
+break;
+
+case CALLBACKTYPE_syscall32:
+v->arch.pv_vcpu.syscall32_callback_cs = reg->address.cs;
+v->arch.pv_vcpu.syscall32_callback_eip= reg->address.eip;
+v->arch.pv_vcpu.syscall32_disables_events =
+(reg->flags & CALLBACKF_mask_events) != 0;
+break;
+
+case CALLBACKTYPE_sysenter:
+v->arch.pv_vcpu.sysenter_callback_cs = reg->address.cs;
+v->arch.pv_vcpu.sysenter_callback_eip= reg->address.eip;
+v->arch.pv_vcpu.sysenter_disables_events =
+(reg->flags & CALLBACKF_mask_events) != 0;
+break;
+
+case CALLBACKTYPE_nmi:
+ret = register_guest_nmi_callback(reg->address.eip);
+break;
+
+default:
+ret = -ENOSYS;
+break;
+}
+
+return ret;
+}
+
+static long compat_unregister_guest_callback(
+struct compat_callback_unregister *unreg)
+{
+long ret;
+
+switch ( unreg->type )
+{
+case CALLBACKTYPE_event:
+case CALLBACKTYPE_failsafe:
+case CALLBACKTYPE_syscall32:
+case CALLBACKTYPE_sysenter:
+ret = -EINVAL;
+break;
+
+case CALLBACKTYPE_nmi:
+ret = unregister_guest_nmi_callback();
+break;
+
+default:
+ret = -ENOSYS;
+break;
+}
+
+return ret;
+}
+
+
+long compat_callback_op(int cmd, XEN_GUEST_HANDLE(void) arg)
+{
+long ret;
+
+switch ( cmd )
+{
+case CALLBACKOP_register:
+{
+struct compat_callback_register reg;
+
+ret = -EFAULT;
+if ( copy_from_guest(, arg, 1) )
+break;
+
+ret = compat_register_guest_callback();
+}
+break;
+
+case CALLBACKOP_unregister:
+{
+struct compat_callback_unregister unreg;
+
+ret = -EFAULT;
+if ( copy_from_guest(, arg, 1) )
+break;
+
+ret = compat_unregister_guest_callback();
+}
+break;
+
+default:
+ret = -EINVAL;
+break;
+}
+
+return ret;
+}
+
+long compat_set_callbacks(unsigned long event_selector,
+  unsigned long event_address,
+  unsigned long failsafe_selector,
+  unsigned long failsafe_address)
+{
+struct compat_callback_register event = {
+.type = CALLBACKTYPE_event,
+.address = {
+.cs = event_selector,
+.eip = event_address
+}
+};
+struct compat_callback_register failsafe = {
+.type = CALLBACKTYPE_failsafe,
+.address = {
+.cs = failsafe_selector,
+.eip = failsafe_address
+}
+};
+
+compat_register_guest_callback();
+compat_register_guest_callback();
+
+return 0;
+}
diff --git a/xen/arch/x86/x86_64/compat/traps.c 
b/xen/arch/x86/x86_64/compat/traps.c
index df691f0ae3..6e146a62a7 100644
--- a/xen/arch/x86/x86_64/compat/traps.c
+++ b/xen/arch/x86/x86_64/compat/traps.c
@@ -66,149 +66,6 @@ void compat_show_guest_stack(struct vcpu *v, const struct 
cpu_user_regs *regs,
 printk("\n");
 }
 
-static long compat_register_guest_callback(
-struct compat_callback_register *reg)
-{
-long ret = 0;
-struct vcpu *v = current;
-
-fixup_guest_code_selector(v->domain, reg->address.cs);
-
-switch ( reg->type )
-{
-case CALLBACKTYPE_event:
-v->arch.pv_vcpu.event_callback_cs = reg->address.cs;
-v->arch.pv_vcpu.event_callback_eip= reg->address.eip;
-break;
-
-case CALLBACKTYPE_failsafe:
-

[Xen-devel] [PATCH v4 14/27] x86: move do_iret to pv/iret.c

[Wei Liu]

Signed-off-by: Wei Liu 
---
There is no copyright header in the original file. Use the default
one?
---
 xen/arch/x86/pv/Makefile|  1 +
 xen/arch/x86/pv/iret.c  | 72 +
 xen/arch/x86/x86_64/traps.c | 56 ---
 3 files changed, 73 insertions(+), 56 deletions(-)
 create mode 100644 xen/arch/x86/pv/iret.c

diff --git a/xen/arch/x86/pv/Makefile b/xen/arch/x86/pv/Makefile
index 939ea60bea..7e3da332d8 100644
--- a/xen/arch/x86/pv/Makefile
+++ b/xen/arch/x86/pv/Makefile
@@ -8,4 +8,5 @@ obj-y += emul-gate-op.o
 obj-y += emul-inv-op.o
 obj-y += emul-priv-op.o
 obj-bin-y += gpr_switch.o
+obj-y += iret.o
 obj-y += misc-hypercalls.o
diff --git a/xen/arch/x86/pv/iret.c b/xen/arch/x86/pv/iret.c
new file mode 100644
index 00..358ae7cf08
--- /dev/null
+++ b/xen/arch/x86/pv/iret.c
@@ -0,0 +1,72 @@
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+unsigned long do_iret(void)
+{
+struct cpu_user_regs *regs = guest_cpu_user_regs();
+struct iret_context iret_saved;
+struct vcpu *v = current;
+
+if ( unlikely(copy_from_user(_saved, (void *)regs->rsp,
+ sizeof(iret_saved))) )
+{
+gprintk(XENLOG_ERR,
+"Fault while reading IRET context from guest stack\n");
+goto exit_and_crash;
+}
+
+/* Returning to user mode? */
+if ( (iret_saved.cs & 3) == 3 )
+{
+if ( unlikely(pagetable_is_null(v->arch.guest_table_user)) )
+{
+gprintk(XENLOG_ERR,
+"Guest switching to user mode with no user page tables\n");
+goto exit_and_crash;
+}
+toggle_guest_mode(v);
+}
+
+if ( VM_ASSIST(v->domain, architectural_iopl) )
+v->arch.pv_vcpu.iopl = iret_saved.rflags & X86_EFLAGS_IOPL;
+
+regs->rip= iret_saved.rip;
+regs->cs = iret_saved.cs | 3; /* force guest privilege */
+regs->rflags = ((iret_saved.rflags & ~(X86_EFLAGS_IOPL|X86_EFLAGS_VM))
+| X86_EFLAGS_IF);
+regs->rsp= iret_saved.rsp;
+regs->ss = iret_saved.ss | 3; /* force guest privilege */
+
+if ( !(iret_saved.flags & VGCF_in_syscall) )
+{
+regs->entry_vector &= ~TRAP_syscall;
+regs->r11 = iret_saved.r11;
+regs->rcx = iret_saved.rcx;
+}
+
+/* Restore upcall mask from supplied EFLAGS.IF. */
+vcpu_info(v, evtchn_upcall_mask) = !(iret_saved.rflags & X86_EFLAGS_IF);
+
+async_exception_cleanup(v);
+
+/* Saved %rax gets written back to regs->rax in entry.S. */
+return iret_saved.rax;
+
+ exit_and_crash:
+domain_crash(v->domain);
+return 0;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
index 36b694c605..4641bc6d06 100644
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -254,62 +254,6 @@ void do_double_fault(struct cpu_user_regs *regs)
 panic("DOUBLE FAULT -- system shutdown");
 }
 
-unsigned long do_iret(void)
-{
-struct cpu_user_regs *regs = guest_cpu_user_regs();
-struct iret_context iret_saved;
-struct vcpu *v = current;
-
-if ( unlikely(copy_from_user(_saved, (void *)regs->rsp,
- sizeof(iret_saved))) )
-{
-gprintk(XENLOG_ERR,
-"Fault while reading IRET context from guest stack\n");
-goto exit_and_crash;
-}
-
-/* Returning to user mode? */
-if ( (iret_saved.cs & 3) == 3 )
-{
-if ( unlikely(pagetable_is_null(v->arch.guest_table_user)) )
-{
-gprintk(XENLOG_ERR,
-"Guest switching to user mode with no user page tables\n");
-goto exit_and_crash;
-}
-toggle_guest_mode(v);
-}
-
-if ( VM_ASSIST(v->domain, architectural_iopl) )
-v->arch.pv_vcpu.iopl = iret_saved.rflags & X86_EFLAGS_IOPL;
-
-regs->rip= iret_saved.rip;
-regs->cs = iret_saved.cs | 3; /* force guest privilege */
-regs->rflags = ((iret_saved.rflags & ~(X86_EFLAGS_IOPL|X86_EFLAGS_VM))
-| X86_EFLAGS_IF);
-regs->rsp= iret_saved.rsp;
-regs->ss = iret_saved.ss | 3; /* force guest privilege */
-
-if ( !(iret_saved.flags & VGCF_in_syscall) )
-{
-regs->entry_vector &= ~TRAP_syscall;
-regs->r11 = iret_saved.r11;
-regs->rcx = iret_saved.rcx;
-}
-
-/* Restore upcall mask from supplied EFLAGS.IF. */
-vcpu_info(v, evtchn_upcall_mask) = !(iret_saved.rflags & X86_EFLAGS_IF);
-
-async_exception_cleanup(v);
-
-/* Saved %rax gets written back to regs->rax in entry.S. */
-return iret_saved.rax;
-
- exit_and_crash:
-domain_crash(v->domain);
-return 0;
-}
-
 static unsigned int write_stub_trampoline(
 unsigned char *stub, unsigned long stub_va,
 

[Xen-devel] [PATCH v4 26/27] x86: fix coding a style issue in asm-x86/traps.h

[Wei Liu]

And add an emacs block.

Signed-off-by: Wei Liu 
---
 xen/include/asm-x86/traps.h | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/xen/include/asm-x86/traps.h b/xen/include/asm-x86/traps.h
index 8cf6105d8d..1ac6718257 100644
--- a/xen/include/asm-x86/traps.h
+++ b/xen/include/asm-x86/traps.h
@@ -38,7 +38,7 @@ bool guest_has_trap_callback(const struct domain *d, unsigned 
int vcpuid,
  * return 0 on successful delivery
  */
 extern int send_guest_trap(struct domain *d, uint16_t vcpuid,
-   unsigned int trap_nr);
+   unsigned int trap_nr);
 
 uint32_t guest_io_read(unsigned int port, unsigned int bytes,
struct domain *);
@@ -48,3 +48,13 @@ void guest_io_write(unsigned int port, unsigned int bytes, 
uint32_t data,
 const char *trapstr(unsigned int trapnr);
 
 #endif /* ASM_TRAP_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.11.0


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

[Xen-devel] [PATCH v4 12/27] x86/traps: move guest_has_trap_callback to pv/traps.c

[Wei Liu]

Take the chance to constify pointers, replace uint16_t with unsigned
int etc.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/traps.c | 18 ++
 xen/arch/x86/traps.c| 18 --
 xen/include/asm-x86/traps.h |  6 +++---
 3 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index d0e651616d..be215df57a 100644
--- a/xen/arch/x86/pv/traps.c
+++ b/xen/arch/x86/pv/traps.c
@@ -219,6 +219,24 @@ long unregister_guest_nmi_callback(void)
 return 0;
 }
 
+bool guest_has_trap_callback(const struct domain *d, unsigned int vcpuid,
+ unsigned int trap_nr)
+{
+const struct vcpu *v;
+const struct trap_info *t;
+
+BUG_ON(d == NULL);
+BUG_ON(vcpuid >= d->max_vcpus);
+
+/* Sanity check - XXX should be more fine grained. */
+BUG_ON(trap_nr >= NR_VECTORS);
+
+v = d->vcpu[vcpuid];
+t = >arch.pv_vcpu.trap_ctxt[trap_nr];
+
+return t->address;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index babb476097..8861dfd332 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1909,24 +1909,6 @@ void __init trap_init(void)
 open_softirq(PCI_SERR_SOFTIRQ, pci_serr_softirq);
 }
 
-int guest_has_trap_callback(struct domain *d, uint16_t vcpuid, unsigned int 
trap_nr)
-{
-struct vcpu *v;
-struct trap_info *t;
-
-BUG_ON(d == NULL);
-BUG_ON(vcpuid >= d->max_vcpus);
-
-/* Sanity check - XXX should be more fine grained. */
-BUG_ON(trap_nr >= NR_VECTORS);
-
-v = d->vcpu[vcpuid];
-t = >arch.pv_vcpu.trap_ctxt[trap_nr];
-
-return (t->address != 0);
-}
-
-
 int send_guest_trap(struct domain *d, uint16_t vcpuid, unsigned int trap_nr)
 {
 struct vcpu *v;
diff --git a/xen/include/asm-x86/traps.h b/xen/include/asm-x86/traps.h
index f1d2513e6b..26625ce5a6 100644
--- a/xen/include/asm-x86/traps.h
+++ b/xen/include/asm-x86/traps.h
@@ -32,10 +32,10 @@ void async_exception_cleanup(struct vcpu *);
 /**
  * guest_has_trap_callback
  *
- * returns true (non-zero) if guest registered a trap handler
+ * returns true if guest registered a trap handler
  */
-extern int guest_has_trap_callback(struct domain *d, uint16_t vcpuid,
-   unsigned int trap_nr);
+bool guest_has_trap_callback(const struct domain *d, unsigned int vcpuid,
+ unsigned int trap_nr);
 
 /**
  * send_guest_trap
-- 
2.11.0


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

[Xen-devel] [PATCH v4 25/27] x86: remove the now empty x86_64/compat/traps.c

[Wei Liu]

Signed-off-by: Wei Liu 
---
 xen/arch/x86/x86_64/compat/traps.c | 14 --
 xen/arch/x86/x86_64/traps.c|  2 --
 2 files changed, 16 deletions(-)
 delete mode 100644 xen/arch/x86/x86_64/compat/traps.c

diff --git a/xen/arch/x86/x86_64/compat/traps.c 
b/xen/arch/x86/x86_64/compat/traps.c
deleted file mode 100644
index 18cd2c017c..00
--- a/xen/arch/x86/x86_64/compat/traps.c
+++ /dev/null
@@ -1,14 +0,0 @@
-#include 
-#include 
-#include 
-#include 
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * tab-width: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
index 79bfc4d3f0..a15231ca0c 100644
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -335,8 +335,6 @@ void subarch_percpu_traps_init(void)
 wrmsrl(MSR_SYSCALL_MASK, XEN_SYSCALL_MASK);
 }
 
-#include "compat/traps.c"
-
 void hypercall_page_initialise(struct domain *d, void *hypercall_page)
 {
 memset(hypercall_page, 0xCC, PAGE_SIZE);
-- 
2.11.0


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

[Xen-devel] [PATCH v4 10/27] x86/traps: move set_guest_{machine, nmi}_trapbounce

[Wei Liu]

Take the opportunity to change their return type to bool. And rename
"v" to "curr".

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/traps.c | 27 +++
 xen/arch/x86/traps.c| 27 ---
 2 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index ec7ff1040b..e374cd73b4 100644
--- a/xen/arch/x86/pv/traps.c
+++ b/xen/arch/x86/pv/traps.c
@@ -156,6 +156,33 @@ void pv_inject_event(const struct x86_event *event)
 }
 }
 
+/*
+ * Called from asm to set up the MCE trapbounce info.
+ * Returns false no callback is set up, else true.
+ */
+bool set_guest_machinecheck_trapbounce(void)
+{
+struct vcpu *curr = current;
+struct trap_bounce *tb = >arch.pv_vcpu.trap_bounce;
+
+pv_inject_hw_exception(TRAP_machine_check, X86_EVENT_NO_EC);
+tb->flags &= ~TBF_EXCEPTION; /* not needed for MCE delivery path */
+return !null_trap_bounce(curr, tb);
+}
+
+/*
+ * Called from asm to set up the NMI trapbounce info.
+ * Returns false if no callback is set up, else true.
+ */
+bool set_guest_nmi_trapbounce(void)
+{
+struct vcpu *curr = current;
+struct trap_bounce *tb = >arch.pv_vcpu.trap_bounce;
+pv_inject_hw_exception(TRAP_nmi, X86_EVENT_NO_EC);
+tb->flags &= ~TBF_EXCEPTION; /* not needed for NMI delivery path */
+return !null_trap_bounce(curr, tb);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 6abfb62c0c..013de702ad 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -626,33 +626,6 @@ void fatal_trap(const struct cpu_user_regs *regs, bool_t 
show_remote)
   (regs->eflags & X86_EFLAGS_IF) ? "" : ", IN INTERRUPT CONTEXT");
 }
 
-/*
- * Called from asm to set up the MCE trapbounce info.
- * Returns 0 if no callback is set up, else 1.
- */
-int set_guest_machinecheck_trapbounce(void)
-{
-struct vcpu *v = current;
-struct trap_bounce *tb = >arch.pv_vcpu.trap_bounce;
- 
-pv_inject_hw_exception(TRAP_machine_check, X86_EVENT_NO_EC);
-tb->flags &= ~TBF_EXCEPTION; /* not needed for MCE delivery path */
-return !null_trap_bounce(v, tb);
-}
-
-/*
- * Called from asm to set up the NMI trapbounce info.
- * Returns 0 if no callback is set up, else 1.
- */
-int set_guest_nmi_trapbounce(void)
-{
-struct vcpu *v = current;
-struct trap_bounce *tb = >arch.pv_vcpu.trap_bounce;
-pv_inject_hw_exception(TRAP_nmi, X86_EVENT_NO_EC);
-tb->flags &= ~TBF_EXCEPTION; /* not needed for NMI delivery path */
-return !null_trap_bounce(v, tb);
-}
-
 void do_reserved_trap(struct cpu_user_regs *regs)
 {
 unsigned int trapnr = regs->entry_vector;
-- 
2.11.0


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

[Xen-devel] [PATCH v4 11/27] x86:/traps: move {un, }register_guest_nmi_callback

[Wei Liu]

Take the opportunity to rename "v" to "curr".

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/traps.c | 36 
 xen/arch/x86/traps.c| 36 
 2 files changed, 36 insertions(+), 36 deletions(-)

diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index e374cd73b4..d0e651616d 100644
--- a/xen/arch/x86/pv/traps.c
+++ b/xen/arch/x86/pv/traps.c
@@ -183,6 +183,42 @@ bool set_guest_nmi_trapbounce(void)
 return !null_trap_bounce(curr, tb);
 }
 
+long register_guest_nmi_callback(unsigned long address)
+{
+struct vcpu *curr = current;
+struct domain *d = curr->domain;
+struct trap_info *t = >arch.pv_vcpu.trap_ctxt[TRAP_nmi];
+
+if ( !is_canonical_address(address) )
+return -EINVAL;
+
+t->vector  = TRAP_nmi;
+t->flags   = 0;
+t->cs  = (is_pv_32bit_domain(d) ?
+  FLAT_COMPAT_KERNEL_CS : FLAT_KERNEL_CS);
+t->address = address;
+TI_SET_IF(t, 1);
+
+/*
+ * If no handler was registered we can 'lose the NMI edge'. Re-assert it
+ * now.
+ */
+if ( (curr->vcpu_id == 0) && (arch_get_nmi_reason(d) != 0) )
+curr->nmi_pending = 1;
+
+return 0;
+}
+
+long unregister_guest_nmi_callback(void)
+{
+struct vcpu *curr = current;
+struct trap_info *t = >arch.pv_vcpu.trap_ctxt[TRAP_nmi];
+
+memset(t, 0, sizeof(*t));
+
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 013de702ad..babb476097 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1909,42 +1909,6 @@ void __init trap_init(void)
 open_softirq(PCI_SERR_SOFTIRQ, pci_serr_softirq);
 }
 
-long register_guest_nmi_callback(unsigned long address)
-{
-struct vcpu *v = current;
-struct domain *d = v->domain;
-struct trap_info *t = >arch.pv_vcpu.trap_ctxt[TRAP_nmi];
-
-if ( !is_canonical_address(address) )
-return -EINVAL;
-
-t->vector  = TRAP_nmi;
-t->flags   = 0;
-t->cs  = (is_pv_32bit_domain(d) ?
-  FLAT_COMPAT_KERNEL_CS : FLAT_KERNEL_CS);
-t->address = address;
-TI_SET_IF(t, 1);
-
-/*
- * If no handler was registered we can 'lose the NMI edge'. Re-assert it
- * now.
- */
-if ( (v->vcpu_id == 0) && (arch_get_nmi_reason(d) != 0) )
-v->nmi_pending = 1;
-
-return 0;
-}
-
-long unregister_guest_nmi_callback(void)
-{
-struct vcpu *v = current;
-struct trap_info *t = >arch.pv_vcpu.trap_ctxt[TRAP_nmi];
-
-memset(t, 0, sizeof(*t));
-
-return 0;
-}
-
 int guest_has_trap_callback(struct domain *d, uint16_t vcpuid, unsigned int 
trap_nr)
 {
 struct vcpu *v;
-- 
2.11.0


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

[Xen-devel] [PATCH v4 18/27] x86/traps: move init_int80_direct_trap to pv/traps.c

[Wei Liu]

Signed-off-by: Wei Liu 
Acked-by: Jan Beulich 
---
 xen/arch/x86/pv/traps.c | 14 ++
 xen/arch/x86/x86_64/traps.c | 14 --
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index 0c1600d886..f2556c7e4a 100644
--- a/xen/arch/x86/pv/traps.c
+++ b/xen/arch/x86/pv/traps.c
@@ -342,6 +342,20 @@ int send_guest_trap(struct domain *d, uint16_t vcpuid, 
unsigned int trap_nr)
 return -EIO;
 }
 
+void init_int80_direct_trap(struct vcpu *v)
+{
+struct trap_info *ti = >arch.pv_vcpu.trap_ctxt[0x80];
+struct trap_bounce *tb = >arch.pv_vcpu.int80_bounce;
+
+tb->cs= ti->cs;
+tb->eip   = ti->address;
+
+if ( null_trap_bounce(v, tb) )
+tb->flags = 0;
+else
+tb->flags = TBF_EXCEPTION | (TI_GET_IF(ti) ? TBF_INTERRUPT : 0);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
index 1a8beb8068..d15c9023e8 100644
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -335,20 +335,6 @@ void subarch_percpu_traps_init(void)
 wrmsrl(MSR_SYSCALL_MASK, XEN_SYSCALL_MASK);
 }
 
-void init_int80_direct_trap(struct vcpu *v)
-{
-struct trap_info *ti = >arch.pv_vcpu.trap_ctxt[0x80];
-struct trap_bounce *tb = >arch.pv_vcpu.int80_bounce;
-
-tb->cs= ti->cs;
-tb->eip   = ti->address;
-
-if ( null_trap_bounce(v, tb) )
-tb->flags = 0;
-else
-tb->flags = TBF_EXCEPTION | (TI_GET_IF(ti) ? TBF_INTERRUPT : 0);
-}
-
 static void hypercall_page_initialise_ring3_kernel(void *hypercall_page)
 {
 char *p;
-- 
2.11.0


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

[Xen-devel] [PATCH v4 16/27] x86/traps: factor out pv_trap_init

[Wei Liu]

Signed-off-by: Wei Liu 
---
 xen/arch/x86/traps.c   | 22 ++
 xen/include/asm-x86/pv/traps.h |  4 
 2 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 8861dfd332..29a83994bd 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1871,14 +1871,8 @@ void __init init_idt_traps(void)
 this_cpu(compat_gdt_table) = boot_cpu_compat_gdt_table;
 }
 
-extern void (*const autogen_entrypoints[NR_VECTORS])(void);
-void __init trap_init(void)
+void __init pv_trap_init(void)
 {
-unsigned int vector;
-
-/* Replace early pagefault with real pagefault handler. */
-set_intr_gate(TRAP_page_fault, _fault);
-
 /* The 32-on-64 hypercall vector is only accessible from ring 1. */
 _set_gate(idt_table + HYPERCALL_VECTOR,
   SYS_DESC_trap_gate, 1, entry_int82);
@@ -1886,6 +1880,19 @@ void __init trap_init(void)
 /* Fast trap for int80 (faster than taking the #GP-fixup path). */
 _set_gate(idt_table + 0x80, SYS_DESC_trap_gate, 3, _direct_trap);
 
+open_softirq(NMI_MCE_SOFTIRQ, nmi_mce_softirq);
+}
+
+extern void (*const autogen_entrypoints[NR_VECTORS])(void);
+void __init trap_init(void)
+{
+unsigned int vector;
+
+pv_trap_init();
+
+/* Replace early pagefault with real pagefault handler. */
+set_intr_gate(TRAP_page_fault, _fault);
+
 for ( vector = 0; vector < NR_VECTORS; ++vector )
 {
 if ( autogen_entrypoints[vector] )
@@ -1905,7 +1912,6 @@ void __init trap_init(void)
 
 cpu_init();
 
-open_softirq(NMI_MCE_SOFTIRQ, nmi_mce_softirq);
 open_softirq(PCI_SERR_SOFTIRQ, pci_serr_softirq);
 }
 
diff --git a/xen/include/asm-x86/pv/traps.h b/xen/include/asm-x86/pv/traps.h
index a4af69e486..426c8f6216 100644
--- a/xen/include/asm-x86/pv/traps.h
+++ b/xen/include/asm-x86/pv/traps.h
@@ -25,6 +25,8 @@
 
 #include 
 
+void pv_trap_init(void);
+
 int pv_emulate_privileged_op(struct cpu_user_regs *regs);
 void pv_emulate_gate_op(struct cpu_user_regs *regs);
 int pv_emulate_invalid_rdtscp(struct cpu_user_regs *regs);
@@ -32,6 +34,8 @@ int pv_emulate_forced_invalid_op(struct cpu_user_regs *regs);
 
 #else  /* !CONFIG_PV */
 
+void pv_trap_init(void) {}
+
 int pv_emulate_privileged_op(struct cpu_user_regs *regs) { return 0; }
 void pv_emulate_gate_op(struct cpu_user_regs *regs) {}
 int pv_emulate_invalid_rdtscp(struct cpu_user_regs *regs) { return 0; }
-- 
2.11.0


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

[Xen-devel] [PATCH v4 21/27] x86: move compat_set_trap_table along side the non-compat variant

[Wei Liu]

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/traps.c| 45 ++
 xen/arch/x86/x86_64/compat/traps.c | 45 --
 2 files changed, 45 insertions(+), 45 deletions(-)

diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index f2556c7e4a..3dcb3f1877 100644
--- a/xen/arch/x86/pv/traps.c
+++ b/xen/arch/x86/pv/traps.c
@@ -87,6 +87,51 @@ long 
do_set_trap_table(XEN_GUEST_HANDLE_PARAM(const_trap_info_t) traps)
 return rc;
 }
 
+int compat_set_trap_table(XEN_GUEST_HANDLE(trap_info_compat_t) traps)
+{
+struct compat_trap_info cur;
+struct trap_info *dst = current->arch.pv_vcpu.trap_ctxt;
+long rc = 0;
+
+/* If no table is presented then clear the entire virtual IDT. */
+if ( guest_handle_is_null(traps) )
+{
+memset(dst, 0, NR_VECTORS * sizeof(*dst));
+init_int80_direct_trap(current);
+return 0;
+}
+
+for ( ; ; )
+{
+if ( copy_from_guest(, traps, 1) )
+{
+rc = -EFAULT;
+break;
+}
+
+if ( cur.address == 0 )
+break;
+
+fixup_guest_code_selector(current->domain, cur.cs);
+
+XLAT_trap_info(dst + cur.vector, );
+
+if ( cur.vector == 0x80 )
+init_int80_direct_trap(current);
+
+guest_handle_add_offset(traps, 1);
+
+if ( hypercall_preempt_check() )
+{
+rc = hypercall_create_continuation(
+__HYPERVISOR_set_trap_table, "h", traps);
+break;
+}
+}
+
+return rc;
+}
+
 void pv_inject_event(const struct x86_event *event)
 {
 struct vcpu *curr = current;
diff --git a/xen/arch/x86/x86_64/compat/traps.c 
b/xen/arch/x86/x86_64/compat/traps.c
index f485299c88..add4af3403 100644
--- a/xen/arch/x86/x86_64/compat/traps.c
+++ b/xen/arch/x86/x86_64/compat/traps.c
@@ -329,51 +329,6 @@ long compat_set_callbacks(unsigned long event_selector,
 return 0;
 }
 
-int compat_set_trap_table(XEN_GUEST_HANDLE(trap_info_compat_t) traps)
-{
-struct compat_trap_info cur;
-struct trap_info *dst = current->arch.pv_vcpu.trap_ctxt;
-long rc = 0;
-
-/* If no table is presented then clear the entire virtual IDT. */
-if ( guest_handle_is_null(traps) )
-{
-memset(dst, 0, NR_VECTORS * sizeof(*dst));
-init_int80_direct_trap(current);
-return 0;
-}
-
-for ( ; ; )
-{
-if ( copy_from_guest(, traps, 1) )
-{
-rc = -EFAULT;
-break;
-}
-
-if ( cur.address == 0 )
-break;
-
-fixup_guest_code_selector(current->domain, cur.cs);
-
-XLAT_trap_info(dst + cur.vector, );
-
-if ( cur.vector == 0x80 )
-init_int80_direct_trap(current);
-
-guest_handle_add_offset(traps, 1);
-
-if ( hypercall_preempt_check() )
-{
-rc = hypercall_create_continuation(
-__HYPERVISOR_set_trap_table, "h", traps);
-break;
-}
-}
-
-return rc;
-}
-
 /*
  * Local variables:
  * mode: C
-- 
2.11.0


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

[Xen-devel] [PATCH v4 17/27] x86/traps: move some PV specific functions and struct to pv/traps.c

[Wei Liu]

Those functions need to be moved at the same time. Also move
softirq_trap because it is only used in that one place.

Fix some coding style issues while moving.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/traps.c | 105 
 xen/arch/x86/traps.c|  93 ---
 xen/include/asm-x86/traps.h |   6 ---
 3 files changed, 105 insertions(+), 99 deletions(-)

diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index be215df57a..0c1600d886 100644
--- a/xen/arch/x86/pv/traps.c
+++ b/xen/arch/x86/pv/traps.c
@@ -237,6 +237,111 @@ bool guest_has_trap_callback(const struct domain *d, 
unsigned int vcpuid,
 return t->address;
 }
 
+struct softirq_trap {
+struct domain *domain;  /* domain to inject trap */
+struct vcpu *vcpu;  /* vcpu to inject trap */
+int processor;  /* physical cpu to inject trap */
+};
+static DEFINE_PER_CPU(struct softirq_trap, softirq_trap);
+
+static void nmi_mce_softirq(void)
+{
+int cpu = smp_processor_id();
+struct softirq_trap *st = _cpu(softirq_trap, cpu);
+
+BUG_ON(st->vcpu == NULL);
+
+/*
+ * Set the tmp value unconditionally, so that
+ * the check in the iret hypercall works.
+ */
+cpumask_copy(st->vcpu->cpu_hard_affinity_tmp,
+ st->vcpu->cpu_hard_affinity);
+
+if ( (cpu != st->processor) ||
+ (st->processor != st->vcpu->processor) )
+{
+/*
+ * We are on a different physical cpu.
+ * Make sure to wakeup the vcpu on the
+ * specified processor.
+ */
+vcpu_set_hard_affinity(st->vcpu, cpumask_of(st->processor));
+
+/* Affinity is restored in the iret hypercall. */
+}
+
+/*
+ * Only used to defer wakeup of domain/vcpu to
+ * a safe (non-NMI/MCE) context.
+ */
+vcpu_kick(st->vcpu);
+st->vcpu = NULL;
+}
+
+void __init pv_trap_init(void)
+{
+/* The 32-on-64 hypercall vector is only accessible from ring 1. */
+_set_gate(idt_table + HYPERCALL_VECTOR,
+  SYS_DESC_trap_gate, 1, entry_int82);
+
+/* Fast trap for int80 (faster than taking the #GP-fixup path). */
+_set_gate(idt_table + 0x80, SYS_DESC_trap_gate, 3, _direct_trap);
+
+open_softirq(NMI_MCE_SOFTIRQ, nmi_mce_softirq);
+}
+
+int send_guest_trap(struct domain *d, uint16_t vcpuid, unsigned int trap_nr)
+{
+struct vcpu *v;
+struct softirq_trap *st = _cpu(softirq_trap, smp_processor_id());
+
+BUG_ON(d == NULL);
+BUG_ON(vcpuid >= d->max_vcpus);
+v = d->vcpu[vcpuid];
+
+switch ( trap_nr )
+{
+case TRAP_nmi:
+if ( cmpxchgptr(>vcpu, NULL, v) )
+return -EBUSY;
+if ( !test_and_set_bool(v->nmi_pending) )
+{
+st->domain = d;
+st->processor = v->processor;
+
+/* not safe to wake up a vcpu here */
+raise_softirq(NMI_MCE_SOFTIRQ);
+return 0;
+}
+st->vcpu = NULL;
+break;
+
+case TRAP_machine_check:
+if ( cmpxchgptr(>vcpu, NULL, v) )
+return -EBUSY;
+
+/*
+* We are called by the machine check (exception or polling) handlers
+* on the physical CPU that reported a machine check error.
+ */
+if ( !test_and_set_bool(v->mce_pending) )
+{
+st->domain = d;
+st->processor = v->processor;
+
+/* not safe to wake up a vcpu here */
+raise_softirq(NMI_MCE_SOFTIRQ);
+return 0;
+}
+st->vcpu = NULL;
+break;
+}
+
+/* delivery failed */
+return -EIO;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 29a83994bd..287503cd56 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1477,39 +1477,6 @@ void do_general_protection(struct cpu_user_regs *regs)
 panic("GENERAL PROTECTION FAULT\n[error_code=%04x]", regs->error_code);
 }
 
-static DEFINE_PER_CPU(struct softirq_trap, softirq_trap);
-
-static void nmi_mce_softirq(void)
-{
-int cpu = smp_processor_id();
-struct softirq_trap *st = _cpu(softirq_trap, cpu);
-
-BUG_ON(st->vcpu == NULL);
-
-/* Set the tmp value unconditionally, so that
- * the check in the iret hypercall works. */
-cpumask_copy(st->vcpu->cpu_hard_affinity_tmp,
- st->vcpu->cpu_hard_affinity);
-
-if ((cpu != st->processor)
-   || (st->processor != st->vcpu->processor))
-{
-/* We are on a different physical cpu.
- * Make sure to wakeup the vcpu on the
- * specified processor.
- */
-vcpu_set_hard_affinity(st->vcpu, cpumask_of(st->processor));
-
-/* Affinity is restored in the iret hypercall. */
-}
-
-/* Only used to defer wakeup of domain/vcpu to
- * a safe (non-NMI/MCE) context.
- */
-vcpu_kick(st->vcpu);
-st->vcpu = NULL;
-}
-
 static void 

[Xen-devel] [PATCH v4 13/27] x86: move toggle_guest_mode to pv/domain.c

[Wei Liu]

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/domain.c| 30 ++
 xen/arch/x86/x86_64/traps.c | 30 --
 2 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index 1c0c040ca0..0f3f0e85d6 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -213,6 +213,36 @@ int pv_domain_initialise(struct domain *d, unsigned int 
domcr_flags,
 return rc;
 }
 
+void toggle_guest_mode(struct vcpu *v)
+{
+if ( is_pv_32bit_vcpu(v) )
+return;
+if ( cpu_has_fsgsbase )
+{
+if ( v->arch.flags & TF_kernel_mode )
+v->arch.pv_vcpu.gs_base_kernel = __rdgsbase();
+else
+v->arch.pv_vcpu.gs_base_user = __rdgsbase();
+}
+v->arch.flags ^= TF_kernel_mode;
+asm volatile ( "swapgs" );
+update_cr3(v);
+/* Don't flush user global mappings from the TLB. Don't tick TLB clock. */
+asm volatile ( "mov %0, %%cr3" : : "r" (v->arch.cr3) : "memory" );
+
+if ( !(v->arch.flags & TF_kernel_mode) )
+return;
+
+if ( v->arch.pv_vcpu.need_update_runstate_area &&
+ update_runstate_area(v) )
+v->arch.pv_vcpu.need_update_runstate_area = 0;
+
+if ( v->arch.pv_vcpu.pending_system_time.version &&
+ update_secondary_system_time(v,
+  >arch.pv_vcpu.pending_system_time) )
+v->arch.pv_vcpu.pending_system_time.version = 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
index 78f410517c..36b694c605 100644
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -254,36 +254,6 @@ void do_double_fault(struct cpu_user_regs *regs)
 panic("DOUBLE FAULT -- system shutdown");
 }
 
-void toggle_guest_mode(struct vcpu *v)
-{
-if ( is_pv_32bit_vcpu(v) )
-return;
-if ( cpu_has_fsgsbase )
-{
-if ( v->arch.flags & TF_kernel_mode )
-v->arch.pv_vcpu.gs_base_kernel = __rdgsbase();
-else
-v->arch.pv_vcpu.gs_base_user = __rdgsbase();
-}
-v->arch.flags ^= TF_kernel_mode;
-asm volatile ( "swapgs" );
-update_cr3(v);
-/* Don't flush user global mappings from the TLB. Don't tick TLB clock. */
-asm volatile ( "mov %0, %%cr3" : : "r" (v->arch.cr3) : "memory" );
-
-if ( !(v->arch.flags & TF_kernel_mode) )
-return;
-
-if ( v->arch.pv_vcpu.need_update_runstate_area &&
- update_runstate_area(v) )
-v->arch.pv_vcpu.need_update_runstate_area = 0;
-
-if ( v->arch.pv_vcpu.pending_system_time.version &&
- update_secondary_system_time(v,
-  >arch.pv_vcpu.pending_system_time) )
-v->arch.pv_vcpu.pending_system_time.version = 0;
-}
-
 unsigned long do_iret(void)
 {
 struct cpu_user_regs *regs = guest_cpu_user_regs();
-- 
2.11.0


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

[Xen-devel] [PATCH v4 15/27] x86: move callback_op code to pv/callback.c

[Wei Liu]

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/Makefile|   1 +
 xen/arch/x86/pv/callback.c  | 157 
 xen/arch/x86/x86_64/traps.c | 148 -
 3 files changed, 158 insertions(+), 148 deletions(-)
 create mode 100644 xen/arch/x86/pv/callback.c

diff --git a/xen/arch/x86/pv/Makefile b/xen/arch/x86/pv/Makefile
index 7e3da332d8..bd1a7081fc 100644
--- a/xen/arch/x86/pv/Makefile
+++ b/xen/arch/x86/pv/Makefile
@@ -1,6 +1,7 @@
 obj-y += hypercall.o
 obj-y += traps.o
 
+obj-y += callback.o
 obj-bin-y += dom0_build.init.o
 obj-y += domain.o
 obj-y += emulate.o
diff --git a/xen/arch/x86/pv/callback.c b/xen/arch/x86/pv/callback.c
new file mode 100644
index 00..dbd602c89d
--- /dev/null
+++ b/xen/arch/x86/pv/callback.c
@@ -0,0 +1,157 @@
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+static long register_guest_callback(struct callback_register *reg)
+{
+long ret = 0;
+struct vcpu *v = current;
+
+if ( !is_canonical_address(reg->address) )
+return -EINVAL;
+
+switch ( reg->type )
+{
+case CALLBACKTYPE_event:
+v->arch.pv_vcpu.event_callback_eip= reg->address;
+break;
+
+case CALLBACKTYPE_failsafe:
+v->arch.pv_vcpu.failsafe_callback_eip = reg->address;
+if ( reg->flags & CALLBACKF_mask_events )
+set_bit(_VGCF_failsafe_disables_events,
+>arch.vgc_flags);
+else
+clear_bit(_VGCF_failsafe_disables_events,
+  >arch.vgc_flags);
+break;
+
+case CALLBACKTYPE_syscall:
+v->arch.pv_vcpu.syscall_callback_eip  = reg->address;
+if ( reg->flags & CALLBACKF_mask_events )
+set_bit(_VGCF_syscall_disables_events,
+>arch.vgc_flags);
+else
+clear_bit(_VGCF_syscall_disables_events,
+  >arch.vgc_flags);
+break;
+
+case CALLBACKTYPE_syscall32:
+v->arch.pv_vcpu.syscall32_callback_eip = reg->address;
+v->arch.pv_vcpu.syscall32_disables_events =
+!!(reg->flags & CALLBACKF_mask_events);
+break;
+
+case CALLBACKTYPE_sysenter:
+v->arch.pv_vcpu.sysenter_callback_eip = reg->address;
+v->arch.pv_vcpu.sysenter_disables_events =
+!!(reg->flags & CALLBACKF_mask_events);
+break;
+
+case CALLBACKTYPE_nmi:
+ret = register_guest_nmi_callback(reg->address);
+break;
+
+default:
+ret = -ENOSYS;
+break;
+}
+
+return ret;
+}
+
+static long unregister_guest_callback(struct callback_unregister *unreg)
+{
+long ret;
+
+switch ( unreg->type )
+{
+case CALLBACKTYPE_event:
+case CALLBACKTYPE_failsafe:
+case CALLBACKTYPE_syscall:
+case CALLBACKTYPE_syscall32:
+case CALLBACKTYPE_sysenter:
+ret = -EINVAL;
+break;
+
+case CALLBACKTYPE_nmi:
+ret = unregister_guest_nmi_callback();
+break;
+
+default:
+ret = -ENOSYS;
+break;
+}
+
+return ret;
+}
+
+
+long do_callback_op(int cmd, XEN_GUEST_HANDLE_PARAM(const_void) arg)
+{
+long ret;
+
+switch ( cmd )
+{
+case CALLBACKOP_register:
+{
+struct callback_register reg;
+
+ret = -EFAULT;
+if ( copy_from_guest(, arg, 1) )
+break;
+
+ret = register_guest_callback();
+}
+break;
+
+case CALLBACKOP_unregister:
+{
+struct callback_unregister unreg;
+
+ret = -EFAULT;
+if ( copy_from_guest(, arg, 1) )
+break;
+
+ret = unregister_guest_callback();
+}
+break;
+
+default:
+ret = -ENOSYS;
+break;
+}
+
+return ret;
+}
+
+long do_set_callbacks(unsigned long event_address,
+  unsigned long failsafe_address,
+  unsigned long syscall_address)
+{
+struct callback_register event = {
+.type = CALLBACKTYPE_event,
+.address = event_address,
+};
+struct callback_register failsafe = {
+.type = CALLBACKTYPE_failsafe,
+.address = failsafe_address,
+};
+struct callback_register syscall = {
+.type = CALLBACKTYPE_syscall,
+.address = syscall_address,
+};
+
+register_guest_callback();
+register_guest_callback();
+register_guest_callback();
+
+return 0;
+}
+
diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
index 4641bc6d06..1a8beb8068 100644
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 
 
 static void print_xen_info(void)
@@ -350,153 +349,6 @@ void init_int80_direct_trap(struct vcpu *v)
 tb->flags = TBF_EXCEPTION | (TI_GET_IF(ti) ? TBF_INTERRUPT : 0);
 }
 
-static long register_guest_callback(struct callback_register *reg)
-{
-long ret = 0;
-struct vcpu 

[Xen-devel] [PATCH v4 19/27] x86: move hypercall_page_initialise_ring3_kernel to pv/hypercall.c

[Wei Liu]

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/hypercall.c | 36 
 xen/arch/x86/x86_64/traps.c | 36 
 xen/include/asm-x86/hypercall.h |  1 +
 3 files changed, 37 insertions(+), 36 deletions(-)

diff --git a/xen/arch/x86/pv/hypercall.c b/xen/arch/x86/pv/hypercall.c
index 7c5e5a629d..287340e774 100644
--- a/xen/arch/x86/pv/hypercall.c
+++ b/xen/arch/x86/pv/hypercall.c
@@ -255,6 +255,42 @@ enum mc_disposition arch_do_multicall_call(struct mc_state 
*state)
  ? mc_continue : mc_preempt;
 }
 
+void hypercall_page_initialise_ring3_kernel(void *hypercall_page)
+{
+char *p;
+int i;
+
+/* Fill in all the transfer points with template machine code. */
+for ( i = 0; i < (PAGE_SIZE / 32); i++ )
+{
+if ( i == __HYPERVISOR_iret )
+continue;
+
+p = (char *)(hypercall_page + (i * 32));
+*(u8  *)(p+ 0) = 0x51;/* push %rcx */
+*(u16 *)(p+ 1) = 0x5341;  /* push %r11 */
+*(u8  *)(p+ 3) = 0xb8;/* mov  $,%eax */
+*(u32 *)(p+ 4) = i;
+*(u16 *)(p+ 8) = 0x050f;  /* syscall */
+*(u16 *)(p+10) = 0x5b41;  /* pop  %r11 */
+*(u8  *)(p+12) = 0x59;/* pop  %rcx */
+*(u8  *)(p+13) = 0xc3;/* ret */
+}
+
+/*
+ * HYPERVISOR_iret is special because it doesn't return and expects a
+ * special stack frame. Guests jump at this transfer point instead of
+ * calling it.
+ */
+p = (char *)(hypercall_page + (__HYPERVISOR_iret * 32));
+*(u8  *)(p+ 0) = 0x51;/* push %rcx */
+*(u16 *)(p+ 1) = 0x5341;  /* push %r11 */
+*(u8  *)(p+ 3) = 0x50;/* push %rax */
+*(u8  *)(p+ 4) = 0xb8;/* mov  $__HYPERVISOR_iret,%eax */
+*(u32 *)(p+ 5) = __HYPERVISOR_iret;
+*(u16 *)(p+ 9) = 0x050f;  /* syscall */
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
index d15c9023e8..79bfc4d3f0 100644
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -335,42 +335,6 @@ void subarch_percpu_traps_init(void)
 wrmsrl(MSR_SYSCALL_MASK, XEN_SYSCALL_MASK);
 }
 
-static void hypercall_page_initialise_ring3_kernel(void *hypercall_page)
-{
-char *p;
-int i;
-
-/* Fill in all the transfer points with template machine code. */
-for ( i = 0; i < (PAGE_SIZE / 32); i++ )
-{
-if ( i == __HYPERVISOR_iret )
-continue;
-
-p = (char *)(hypercall_page + (i * 32));
-*(u8  *)(p+ 0) = 0x51;/* push %rcx */
-*(u16 *)(p+ 1) = 0x5341;  /* push %r11 */
-*(u8  *)(p+ 3) = 0xb8;/* mov  $,%eax */
-*(u32 *)(p+ 4) = i;
-*(u16 *)(p+ 8) = 0x050f;  /* syscall */
-*(u16 *)(p+10) = 0x5b41;  /* pop  %r11 */
-*(u8  *)(p+12) = 0x59;/* pop  %rcx */
-*(u8  *)(p+13) = 0xc3;/* ret */
-}
-
-/*
- * HYPERVISOR_iret is special because it doesn't return and expects a
- * special stack frame. Guests jump at this transfer point instead of
- * calling it.
- */
-p = (char *)(hypercall_page + (__HYPERVISOR_iret * 32));
-*(u8  *)(p+ 0) = 0x51;/* push %rcx */
-*(u16 *)(p+ 1) = 0x5341;  /* push %r11 */
-*(u8  *)(p+ 3) = 0x50;/* push %rax */
-*(u8  *)(p+ 4) = 0xb8;/* mov  $__HYPERVISOR_iret,%eax */
-*(u32 *)(p+ 5) = __HYPERVISOR_iret;
-*(u16 *)(p+ 9) = 0x050f;  /* syscall */
-}
-
 #include "compat/traps.c"
 
 void hypercall_page_initialise(struct domain *d, void *hypercall_page)
diff --git a/xen/include/asm-x86/hypercall.h b/xen/include/asm-x86/hypercall.h
index cfbcefe52f..5631cf2694 100644
--- a/xen/include/asm-x86/hypercall.h
+++ b/xen/include/asm-x86/hypercall.h
@@ -26,6 +26,7 @@ typedef struct {
 extern const hypercall_args_t hypercall_args_table[NR_hypercalls];
 
 void pv_hypercall(struct cpu_user_regs *regs);
+void hypercall_page_initialise_ring3_kernel(void *hypercall_page);
 
 /*
  * Both do_mmuext_op() and do_mmu_update():
-- 
2.11.0


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

[Xen-devel] [PATCH v4 04/27] x86: move PV invalid op emulation code

[Wei Liu]

Move the code to pv/emul-inv-op.c. Prefix emulate_* functions with pv_
and export them via pv/traps.h.

Pure code motion except for the rename.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/Makefile   |   1 +
 xen/arch/x86/pv/emul-inv-op.c  | 123 +
 xen/arch/x86/traps.c   |  75 +
 xen/include/asm-x86/pv/traps.h |   4 ++
 4 files changed, 130 insertions(+), 73 deletions(-)
 create mode 100644 xen/arch/x86/pv/emul-inv-op.c

diff --git a/xen/arch/x86/pv/Makefile b/xen/arch/x86/pv/Makefile
index 1f6fbd3f5c..42ca64dc9e 100644
--- a/xen/arch/x86/pv/Makefile
+++ b/xen/arch/x86/pv/Makefile
@@ -5,5 +5,6 @@ obj-bin-y += dom0_build.init.o
 obj-y += domain.o
 obj-y += emulate.o
 obj-y += emul-gate-op.o
+obj-y += emul-inv-op.o
 obj-y += emul-priv-op.o
 obj-bin-y += gpr_switch.o
diff --git a/xen/arch/x86/pv/emul-inv-op.c b/xen/arch/x86/pv/emul-inv-op.c
new file mode 100644
index 00..6a731c6049
--- /dev/null
+++ b/xen/arch/x86/pv/emul-inv-op.c
@@ -0,0 +1,123 @@
+/**
+ * arch/x86/pv/emul-inv-op.c
+ *
+ * Emulate invalid op for PV guests
+ *
+ * Modifications to Linux original are copyright (c) 2002-2004, K A Fraser
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "emulate.h"
+
+int pv_emulate_invalid_rdtscp(struct cpu_user_regs *regs)
+{
+char opcode[3];
+unsigned long eip, rc;
+struct vcpu *v = current;
+
+eip = regs->rip;
+if ( (rc = copy_from_user(opcode, (char *)eip, sizeof(opcode))) != 0 )
+{
+pv_inject_page_fault(0, eip + sizeof(opcode) - rc);
+return EXCRET_fault_fixed;
+}
+if ( memcmp(opcode, "\xf\x1\xf9", sizeof(opcode)) )
+return 0;
+eip += sizeof(opcode);
+pv_soft_rdtsc(v, regs, 1);
+pv_emul_instruction_done(regs, eip);
+return EXCRET_fault_fixed;
+}
+
+int pv_emulate_forced_invalid_op(struct cpu_user_regs *regs)
+{
+char sig[5], instr[2];
+unsigned long eip, rc;
+struct cpuid_leaf res;
+
+eip = regs->rip;
+
+/* Check for forced emulation signature: ud2 ; .ascii "xen". */
+if ( (rc = copy_from_user(sig, (char *)eip, sizeof(sig))) != 0 )
+{
+pv_inject_page_fault(0, eip + sizeof(sig) - rc);
+return EXCRET_fault_fixed;
+}
+if ( memcmp(sig, "\xf\xbxen", sizeof(sig)) )
+return 0;
+eip += sizeof(sig);
+
+/* We only emulate CPUID. */
+if ( ( rc = copy_from_user(instr, (char *)eip, sizeof(instr))) != 0 )
+{
+pv_inject_page_fault(0, eip + sizeof(instr) - rc);
+return EXCRET_fault_fixed;
+}
+if ( memcmp(instr, "\xf\xa2", sizeof(instr)) )
+return 0;
+
+/* If cpuid faulting is enabled and CPL>0 inject a #GP in place of #UD. */
+if ( current->arch.cpuid_faulting && !guest_kernel_mode(current, regs) )
+{
+regs->rip = eip;
+pv_inject_hw_exception(TRAP_gp_fault, regs->error_code);
+return EXCRET_fault_fixed;
+}
+
+eip += sizeof(instr);
+
+guest_cpuid(current, regs->eax, regs->ecx, );
+
+regs->rax = res.a;
+regs->rbx = res.b;
+regs->rcx = res.c;
+regs->rdx = res.d;
+
+pv_emul_instruction_done(regs, eip);
+
+trace_trap_one_addr(TRC_PV_FORCED_INVALID_OP, regs->rip);
+
+return EXCRET_fault_fixed;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 7b781f17db..ff25f679f5 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -968,77 +968,6 @@ void cpuid_hypervisor_leaves(const struct vcpu *v, 
uint32_t leaf,
 }
 }
 
-static int emulate_invalid_rdtscp(struct cpu_user_regs *regs)
-{
-char opcode[3];
-unsigned long eip, rc;
-struct vcpu *v = current;
-
-eip = regs->rip;
-if ( (rc = copy_from_user(opcode, (char *)eip, sizeof(opcode))) != 0 )
-{
-pv_inject_page_fault(0, eip + sizeof(opcode) - rc);
-return EXCRET_fault_fixed;
-}
-if ( memcmp(opcode, "\xf\x1\xf9", sizeof(opcode)) )
-

[Xen-devel] [PATCH v4 02/27] x86: move PV privileged instruction emulation code

[Wei Liu]

Move the code to pv/emul-priv-op.c. Prefix emulate_privileged_op with
pv_ and export it via pv/traps.h.

Also move gpr_switch.S since it is used by the privileged instruction
emulation code only.

Code motion only except for the rename. Cleanup etc will come later.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/Makefile |2 +
 xen/arch/x86/pv/emul-priv-op.c   | 1414 ++
 xen/arch/x86/{x86_64 => pv}/gpr_switch.S |0
 xen/arch/x86/traps.c | 1360 +---
 xen/arch/x86/x86_64/Makefile |1 -
 xen/include/asm-x86/pv/traps.h   |   46 +
 6 files changed, 1464 insertions(+), 1359 deletions(-)
 create mode 100644 xen/arch/x86/pv/emul-priv-op.c
 rename xen/arch/x86/{x86_64 => pv}/gpr_switch.S (100%)
 create mode 100644 xen/include/asm-x86/pv/traps.h

diff --git a/xen/arch/x86/pv/Makefile b/xen/arch/x86/pv/Makefile
index 564202cbb7..e48c460680 100644
--- a/xen/arch/x86/pv/Makefile
+++ b/xen/arch/x86/pv/Makefile
@@ -4,3 +4,5 @@ obj-y += traps.o
 obj-bin-y += dom0_build.init.o
 obj-y += domain.o
 obj-y += emulate.o
+obj-y += emul-priv-op.o
+obj-bin-y += gpr_switch.o
diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
new file mode 100644
index 00..fd5fd74bd1
--- /dev/null
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -0,0 +1,1414 @@
+/**
+ * arch/x86/pv/emul-priv-op.c
+ *
+ * Emulate privileged instructions for PV guests
+ *
+ * Modifications to Linux original are copyright (c) 2002-2004, K A Fraser
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "../x86_64/mmconfig.h"
+#include "emulate.h"
+
+/***
+ * I/O emulation support
+ */
+
+struct priv_op_ctxt {
+struct x86_emulate_ctxt ctxt;
+struct {
+unsigned long base, limit;
+} cs;
+char *io_emul_stub;
+unsigned int bpmatch;
+unsigned int tsc;
+#define TSC_BASE 1
+#define TSC_AUX 2
+};
+
+/* I/O emulation support. Helper routines for, and type of, the stack stub.*/
+void host_to_guest_gpr_switch(struct cpu_user_regs *);
+unsigned long guest_to_host_gpr_switch(unsigned long);
+
+void (*pv_post_outb_hook)(unsigned int port, u8 value);
+
+typedef void io_emul_stub_t(struct cpu_user_regs *);
+
+static io_emul_stub_t *io_emul_stub_setup(struct priv_op_ctxt *ctxt, u8 opcode,
+  unsigned int port, unsigned int 
bytes)
+{
+if ( !ctxt->io_emul_stub )
+ctxt->io_emul_stub = map_domain_page(_mfn(this_cpu(stubs.mfn))) +
+ (this_cpu(stubs.addr) &
+  ~PAGE_MASK) +
+ STUB_BUF_SIZE / 2;
+
+/* movq $host_to_guest_gpr_switch,%rcx */
+ctxt->io_emul_stub[0] = 0x48;
+ctxt->io_emul_stub[1] = 0xb9;
+*(void **)>io_emul_stub[2] = (void *)host_to_guest_gpr_switch;
+/* callq *%rcx */
+ctxt->io_emul_stub[10] = 0xff;
+ctxt->io_emul_stub[11] = 0xd1;
+/* data16 or nop */
+ctxt->io_emul_stub[12] = (bytes != 2) ? 0x90 : 0x66;
+/*  */
+ctxt->io_emul_stub[13] = opcode;
+/* imm8 or nop */
+ctxt->io_emul_stub[14] = !(opcode & 8) ? port : 0x90;
+/* ret (jumps to guest_to_host_gpr_switch) */
+ctxt->io_emul_stub[15] = 0xc3;
+BUILD_BUG_ON(STUB_BUF_SIZE / 2 < 16);
+
+if ( ioemul_handle_quirk )
+ioemul_handle_quirk(opcode, >io_emul_stub[12], ctxt->ctxt.regs);
+
+/* Handy function-typed pointer to the stub. */
+return (void *)(this_cpu(stubs.addr) + STUB_BUF_SIZE / 2);
+}
+
+
+/* Perform IOPL check between the vcpu's shadowed IOPL, and the assumed cpl. */
+static bool_t iopl_ok(const struct vcpu *v, const struct cpu_user_regs *regs)
+{
+unsigned int cpl = guest_kernel_mode(v, regs) ?
+(VM_ASSIST(v->domain, architectural_iopl) ? 0 : 1) : 3;
+
+ASSERT((v->arch.pv_vcpu.iopl & ~X86_EFLAGS_IOPL) == 0);
+
+return IOPL(cpl) <= v->arch.pv_vcpu.iopl;
+}
+
+/* Has the guest requested sufficient permission for this I/O access? */
+static int 

[Xen-devel] [PATCH v4 08/27] x86: move some misc PV hypercalls to misc-hypercalls.c

[Wei Liu]

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/Makefile  |  1 +
 xen/arch/x86/pv/misc-hypercalls.c | 78 +++
 xen/arch/x86/traps.c  | 44 --
 3 files changed, 79 insertions(+), 44 deletions(-)
 create mode 100644 xen/arch/x86/pv/misc-hypercalls.c

diff --git a/xen/arch/x86/pv/Makefile b/xen/arch/x86/pv/Makefile
index 42ca64dc9e..939ea60bea 100644
--- a/xen/arch/x86/pv/Makefile
+++ b/xen/arch/x86/pv/Makefile
@@ -8,3 +8,4 @@ obj-y += emul-gate-op.o
 obj-y += emul-inv-op.o
 obj-y += emul-priv-op.o
 obj-bin-y += gpr_switch.o
+obj-y += misc-hypercalls.o
diff --git a/xen/arch/x86/pv/misc-hypercalls.c 
b/xen/arch/x86/pv/misc-hypercalls.c
new file mode 100644
index 00..5862130697
--- /dev/null
+++ b/xen/arch/x86/pv/misc-hypercalls.c
@@ -0,0 +1,78 @@
+/**
+ * arch/x86/pv/misc-hypercalls.c
+ *
+ * Misc hypercall handlers
+ *
+ * Modifications to Linux original are copyright (c) 2002-2004, K A Fraser
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see .
+ */
+
+#include 
+
+#include 
+
+long do_set_debugreg(int reg, unsigned long value)
+{
+return set_debugreg(current, reg, value);
+}
+
+unsigned long do_get_debugreg(int reg)
+{
+struct vcpu *curr = current;
+
+switch ( reg )
+{
+case 0 ... 3:
+case 6:
+return curr->arch.debugreg[reg];
+case 7:
+return (curr->arch.debugreg[7] |
+curr->arch.debugreg[5]);
+case 4 ... 5:
+return ((curr->arch.pv_vcpu.ctrlreg[4] & X86_CR4_DE) ?
+curr->arch.debugreg[reg + 2] : 0);
+}
+
+return -EINVAL;
+}
+
+long do_fpu_taskswitch(int set)
+{
+struct vcpu *v = current;
+
+if ( set )
+{
+v->arch.pv_vcpu.ctrlreg[0] |= X86_CR0_TS;
+stts();
+}
+else
+{
+v->arch.pv_vcpu.ctrlreg[0] &= ~X86_CR0_TS;
+if ( v->fpu_dirtied )
+clts();
+}
+
+return 0;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 440aad182b..6923c2ef01 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1488,25 +1488,6 @@ void __init do_early_page_fault(struct cpu_user_regs 
*regs)
 }
 }
 
-long do_fpu_taskswitch(int set)
-{
-struct vcpu *v = current;
-
-if ( set )
-{
-v->arch.pv_vcpu.ctrlreg[0] |= X86_CR0_TS;
-stts();
-}
-else
-{
-v->arch.pv_vcpu.ctrlreg[0] &= ~X86_CR0_TS;
-if ( v->fpu_dirtied )
-clts();
-}
-
-return 0;
-}
-
 void do_general_protection(struct cpu_user_regs *regs)
 {
 struct vcpu *v = current;
@@ -2249,31 +2230,6 @@ long set_debugreg(struct vcpu *v, unsigned int reg, 
unsigned long value)
 return 0;
 }
 
-long do_set_debugreg(int reg, unsigned long value)
-{
-return set_debugreg(current, reg, value);
-}
-
-unsigned long do_get_debugreg(int reg)
-{
-struct vcpu *curr = current;
-
-switch ( reg )
-{
-case 0 ... 3:
-case 6:
-return curr->arch.debugreg[reg];
-case 7:
-return (curr->arch.debugreg[7] |
-curr->arch.debugreg[5]);
-case 4 ... 5:
-return ((curr->arch.pv_vcpu.ctrlreg[4] & X86_CR4_DE) ?
-curr->arch.debugreg[reg + 2] : 0);
-}
-
-return -EINVAL;
-}
-
 void asm_domain_crash_synchronous(unsigned long addr)
 {
 /*
-- 
2.11.0


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

[Xen-devel] [PATCH v4 07/27] x86: move do_set_trap_table to pv/traps.c

[Wei Liu]

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/traps.c | 52 +
 xen/arch/x86/traps.c| 49 --
 2 files changed, 52 insertions(+), 49 deletions(-)

diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index 51125a8d86..6e69f2ad58 100644
--- a/xen/arch/x86/pv/traps.c
+++ b/xen/arch/x86/pv/traps.c
@@ -19,7 +19,10 @@
  * Copyright (c) 2017 Citrix Systems Ltd.
  */
 
+#include 
+#include 
 #include 
+#include 
 
 #include 
 
@@ -31,6 +34,55 @@ void do_entry_int82(struct cpu_user_regs *regs)
 pv_hypercall(regs);
 }
 
+long do_set_trap_table(XEN_GUEST_HANDLE_PARAM(const_trap_info_t) traps)
+{
+struct trap_info cur;
+struct vcpu *curr = current;
+struct trap_info *dst = curr->arch.pv_vcpu.trap_ctxt;
+long rc = 0;
+
+/* If no table is presented then clear the entire virtual IDT. */
+if ( guest_handle_is_null(traps) )
+{
+memset(dst, 0, NR_VECTORS * sizeof(*dst));
+init_int80_direct_trap(curr);
+return 0;
+}
+
+for ( ; ; )
+{
+if ( copy_from_guest(, traps, 1) )
+{
+rc = -EFAULT;
+break;
+}
+
+if ( cur.address == 0 )
+break;
+
+if ( !is_canonical_address(cur.address) )
+return -EINVAL;
+
+fixup_guest_code_selector(curr->domain, cur.cs);
+
+memcpy([cur.vector], , sizeof(cur));
+
+if ( cur.vector == 0x80 )
+init_int80_direct_trap(curr);
+
+guest_handle_add_offset(traps, 1);
+
+if ( hypercall_preempt_check() )
+{
+rc = hypercall_create_continuation(
+__HYPERVISOR_set_trap_table, "h", traps);
+break;
+}
+}
+
+return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index b5642b0f9a..440aad182b 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2126,55 +2126,6 @@ int send_guest_trap(struct domain *d, uint16_t vcpuid, 
unsigned int trap_nr)
 }
 
 
-long do_set_trap_table(XEN_GUEST_HANDLE_PARAM(const_trap_info_t) traps)
-{
-struct trap_info cur;
-struct vcpu *curr = current;
-struct trap_info *dst = curr->arch.pv_vcpu.trap_ctxt;
-long rc = 0;
-
-/* If no table is presented then clear the entire virtual IDT. */
-if ( guest_handle_is_null(traps) )
-{
-memset(dst, 0, NR_VECTORS * sizeof(*dst));
-init_int80_direct_trap(curr);
-return 0;
-}
-
-for ( ; ; )
-{
-if ( copy_from_guest(, traps, 1) )
-{
-rc = -EFAULT;
-break;
-}
-
-if ( cur.address == 0 )
-break;
-
-if ( !is_canonical_address(cur.address) )
-return -EINVAL;
-
-fixup_guest_code_selector(curr->domain, cur.cs);
-
-memcpy([cur.vector], , sizeof(cur));
-
-if ( cur.vector == 0x80 )
-init_int80_direct_trap(curr);
-
-guest_handle_add_offset(traps, 1);
-
-if ( hypercall_preempt_check() )
-{
-rc = hypercall_create_continuation(
-__HYPERVISOR_set_trap_table, "h", traps);
-break;
-}
-}
-
-return rc;
-}
-
 void activate_debugregs(const struct vcpu *curr)
 {
 ASSERT(curr == current);
-- 
2.11.0


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

[Xen-devel] [PATCH v4 00/27] x86: refactor trap handling code

[Wei Liu]

V4 of this series, rebased on top of staging.

 git://xenbits.xen.org/people/liuw/xen.git wip.move-traps-v4

Wei Liu (27):
  x86: factor out common PV emulation code
  x86: move PV privileged instruction emulation code
  x86: move PV gate op emulation code
  x86: move PV invalid op emulation code
  x86/traps: remove now unused inclusion of emulate.h
  x86: clean up PV emulation code
  x86: move do_set_trap_table to pv/traps.c
  x86: move some misc PV hypercalls to misc-hypercalls.c
  x86/traps: move pv_inject_event to pv/traps.c
  x86/traps: move set_guest_{machine,nmi}_trapbounce
  x86:/traps: move {un,}register_guest_nmi_callback
  x86/traps: move guest_has_trap_callback to pv/traps.c
  x86: move toggle_guest_mode to pv/domain.c
  x86: move do_iret to pv/iret.c
  x86: move callback_op code to pv/callback.c
  x86/traps: factor out pv_trap_init
  x86/traps: move some PV specific functions and struct to pv/traps.c
  x86/traps: move init_int80_direct_trap to pv/traps.c
  x86: move hypercall_page_initialise_ring3_kernel to pv/hypercall.c
  x86: move hypercall_page_initialise_ring1_kernel
  x86: move compat_set_trap_table along side the non-compat variant
  x86: move compat_iret along side its non-compat variant
  x86: move the compat callback ops next to the non-compat variant
  x86: move compat_show_guest_statck near its non-compat variant
  x86: remove the now empty x86_64/compat/traps.c
  x86: fix coding a style issue in asm-x86/traps.h
  x86: clean up traps.c

 xen/arch/x86/pv/Makefile |8 +
 xen/arch/x86/pv/callback.c   |  299 
 xen/arch/x86/pv/domain.c |   30 +
 xen/arch/x86/pv/emul-gate-op.c   |  439 ++
 xen/arch/x86/pv/emul-inv-op.c|  123 ++
 xen/arch/x86/pv/emul-priv-op.c   | 1418 +
 xen/arch/x86/pv/emulate.c|   98 ++
 xen/arch/x86/pv/emulate.h|   10 +
 xen/arch/x86/{x86_64 => pv}/gpr_switch.S |0
 xen/arch/x86/pv/hypercall.c  |   67 +
 xen/arch/x86/pv/iret.c   |  192 +++
 xen/arch/x86/pv/misc-hypercalls.c|   78 +
 xen/arch/x86/pv/traps.c  |  370 +
 xen/arch/x86/traps.c | 2497 +++---
 xen/arch/x86/x86_64/Makefile |1 -
 xen/arch/x86/x86_64/compat/traps.c   |  416 -
 xen/arch/x86/x86_64/traps.c  |  286 
 xen/include/asm-x86/hypercall.h  |2 +
 xen/include/asm-x86/processor.h  |3 -
 xen/include/asm-x86/pv/traps.h   |   56 +
 xen/include/asm-x86/traps.h  |   24 +-
 21 files changed, 3382 insertions(+), 3035 deletions(-)
 create mode 100644 xen/arch/x86/pv/callback.c
 create mode 100644 xen/arch/x86/pv/emul-gate-op.c
 create mode 100644 xen/arch/x86/pv/emul-inv-op.c
 create mode 100644 xen/arch/x86/pv/emul-priv-op.c
 create mode 100644 xen/arch/x86/pv/emulate.c
 create mode 100644 xen/arch/x86/pv/emulate.h
 rename xen/arch/x86/{x86_64 => pv}/gpr_switch.S (100%)
 create mode 100644 xen/arch/x86/pv/iret.c
 create mode 100644 xen/arch/x86/pv/misc-hypercalls.c
 delete mode 100644 xen/arch/x86/x86_64/compat/traps.c
 create mode 100644 xen/include/asm-x86/pv/traps.h

-- 
2.11.0


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

[Xen-devel] [PATCH v4 06/27] x86: clean up PV emulation code

[Wei Liu]

Replace bool_t with bool. Fix coding style issues. Add spaces around
binary ops. Use 1U for shifting. Eliminate TOGGLE_MODE.

Signed-off-by: Wei Liu 
Signed-off-by: Andrew Cooper 
---
 xen/arch/x86/pv/emul-gate-op.c |  5 ++-
 xen/arch/x86/pv/emul-priv-op.c | 82 ++
 2 files changed, 45 insertions(+), 42 deletions(-)

diff --git a/xen/arch/x86/pv/emul-gate-op.c b/xen/arch/x86/pv/emul-gate-op.c
index 97a4b31a56..cdf3b308f2 100644
--- a/xen/arch/x86/pv/emul-gate-op.c
+++ b/xen/arch/x86/pv/emul-gate-op.c
@@ -50,7 +50,6 @@ static int read_gate_descriptor(unsigned int gate_sel,
 struct desc_struct desc;
 const struct desc_struct *pdesc;
 
-
 pdesc = (const struct desc_struct *)
 (!(gate_sel & 4) ? GDT_VIRT_START(v) : LDT_VIRT_START(v))
 + (gate_sel >> 3);
@@ -97,8 +96,8 @@ static int read_gate_descriptor(unsigned int gate_sel,
 return 1;
 }
 
-static inline int check_stack_limit(unsigned int ar, unsigned int limit,
-unsigned int esp, unsigned int decr)
+static inline bool check_stack_limit(unsigned int ar, unsigned int limit,
+ unsigned int esp, unsigned int decr)
 {
 return (((esp - decr) < (esp - 1)) &&
 (!(ar & _SEGMENT_EC) ? (esp - 1) <= limit : (esp - decr) > limit));
diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
index fd5fd74bd1..85185b6b29 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -58,7 +58,7 @@ struct priv_op_ctxt {
 #define TSC_AUX 2
 };
 
-/* I/O emulation support. Helper routines for, and type of, the stack stub.*/
+/* I/O emulation support. Helper routines for, and type of, the stack stub. */
 void host_to_guest_gpr_switch(struct cpu_user_regs *);
 unsigned long guest_to_host_gpr_switch(unsigned long);
 
@@ -101,7 +101,7 @@ static io_emul_stub_t *io_emul_stub_setup(struct 
priv_op_ctxt *ctxt, u8 opcode,
 
 
 /* Perform IOPL check between the vcpu's shadowed IOPL, and the assumed cpl. */
-static bool_t iopl_ok(const struct vcpu *v, const struct cpu_user_regs *regs)
+static bool iopl_ok(const struct vcpu *v, const struct cpu_user_regs *regs)
 {
 unsigned int cpl = guest_kernel_mode(v, regs) ?
 (VM_ASSIST(v->domain, architectural_iopl) ? 0 : 1) : 3;
@@ -112,16 +112,14 @@ static bool_t iopl_ok(const struct vcpu *v, const struct 
cpu_user_regs *regs)
 }
 
 /* Has the guest requested sufficient permission for this I/O access? */
-static int guest_io_okay(
-unsigned int port, unsigned int bytes,
-struct vcpu *v, struct cpu_user_regs *regs)
+static bool guest_io_okay(unsigned int port, unsigned int bytes,
+  struct vcpu *v, struct cpu_user_regs *regs)
 {
 /* If in user mode, switch to kernel mode just to read I/O bitmap. */
-int user_mode = !(v->arch.flags & TF_kernel_mode);
-#define TOGGLE_MODE() if ( user_mode ) toggle_guest_mode(v)
+const bool user_mode = !(v->arch.flags & TF_kernel_mode);
 
 if ( iopl_ok(v, regs) )
-return 1;
+return true;
 
 if ( v->arch.pv_vcpu.iobmp_limit > (port + bytes) )
 {
@@ -131,7 +129,9 @@ static int guest_io_okay(
  * Grab permission bytes from guest space. Inaccessible bytes are
  * read as 0xff (no access allowed).
  */
-TOGGLE_MODE();
+if ( user_mode )
+toggle_guest_mode(v);
+
 switch ( __copy_from_guest_offset(x.bytes, v->arch.pv_vcpu.iobmp,
   port>>3, 2) )
 {
@@ -141,43 +141,45 @@ static int guest_io_okay(
 /* fallthrough */
 case 0:  break;
 }
-TOGGLE_MODE();
 
-if ( (x.mask & (((1<

[Xen-devel] [PATCH v4 05/27] x86/traps: remove now unused inclusion of emulate.h

[Wei Liu]

Signed-off-by: Wei Liu 
---
Can be squashed into previous patch. Kept separated in case further
code churn is required.
---
 xen/arch/x86/traps.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index ff25f679f5..b5642b0f9a 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -79,8 +79,6 @@
 #include 
 #include 
 
-#include "pv/emulate.h"
-
 /*
  * opt_nmi: one of 'ignore', 'dom0', or 'fatal'.
  *  fatal:  Xen prints diagnostic message and then hangs.
-- 
2.11.0


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

[Xen-devel] [PATCH v4 09/27] x86/traps: move pv_inject_event to pv/traps.c

[Wei Liu]

Take the opportunity to rename "v" to "curr".

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/traps.c | 73 +
 xen/arch/x86/traps.c| 69 --
 2 files changed, 73 insertions(+), 69 deletions(-)

diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index 6e69f2ad58..ec7ff1040b 100644
--- a/xen/arch/x86/pv/traps.c
+++ b/xen/arch/x86/pv/traps.c
@@ -22,9 +22,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #include 
+#include 
+#include 
 
 void do_entry_int82(struct cpu_user_regs *regs)
 {
@@ -83,6 +87,75 @@ long 
do_set_trap_table(XEN_GUEST_HANDLE_PARAM(const_trap_info_t) traps)
 return rc;
 }
 
+void pv_inject_event(const struct x86_event *event)
+{
+struct vcpu *curr = current;
+struct cpu_user_regs *regs = guest_cpu_user_regs();
+struct trap_bounce *tb;
+const struct trap_info *ti;
+const uint8_t vector = event->vector;
+unsigned int error_code = event->error_code;
+bool use_error_code;
+
+ASSERT(vector == event->vector); /* Confirm no truncation. */
+if ( event->type == X86_EVENTTYPE_HW_EXCEPTION )
+{
+ASSERT(vector < 32);
+use_error_code = TRAP_HAVE_EC & (1u << vector);
+}
+else
+{
+ASSERT(event->type == X86_EVENTTYPE_SW_INTERRUPT);
+use_error_code = false;
+}
+if ( use_error_code )
+ASSERT(error_code != X86_EVENT_NO_EC);
+else
+ASSERT(error_code == X86_EVENT_NO_EC);
+
+tb = >arch.pv_vcpu.trap_bounce;
+ti = >arch.pv_vcpu.trap_ctxt[vector];
+
+tb->flags = TBF_EXCEPTION;
+tb->cs= ti->cs;
+tb->eip   = ti->address;
+
+if ( event->type == X86_EVENTTYPE_HW_EXCEPTION &&
+ vector == TRAP_page_fault )
+{
+curr->arch.pv_vcpu.ctrlreg[2] = event->cr2;
+arch_set_cr2(curr, event->cr2);
+
+/* Re-set error_code.user flag appropriately for the guest. */
+error_code &= ~PFEC_user_mode;
+if ( !guest_kernel_mode(curr, regs) )
+error_code |= PFEC_user_mode;
+
+trace_pv_page_fault(event->cr2, error_code);
+}
+else
+trace_pv_trap(vector, regs->rip, use_error_code, error_code);
+
+if ( use_error_code )
+{
+tb->flags |= TBF_EXCEPTION_ERRCODE;
+tb->error_code = error_code;
+}
+
+if ( TI_GET_IF(ti) )
+tb->flags |= TBF_INTERRUPT;
+
+if ( unlikely(null_trap_bounce(curr, tb)) )
+{
+gprintk(XENLOG_WARNING,
+"Unhandled %s fault/trap [#%d, ec=%04x]\n",
+trapstr(vector), vector, error_code);
+
+if ( vector == TRAP_page_fault )
+show_page_walk(event->cr2);
+}
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 6923c2ef01..6abfb62c0c 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -626,75 +626,6 @@ void fatal_trap(const struct cpu_user_regs *regs, bool_t 
show_remote)
   (regs->eflags & X86_EFLAGS_IF) ? "" : ", IN INTERRUPT CONTEXT");
 }
 
-void pv_inject_event(const struct x86_event *event)
-{
-struct vcpu *v = current;
-struct cpu_user_regs *regs = guest_cpu_user_regs();
-struct trap_bounce *tb;
-const struct trap_info *ti;
-const uint8_t vector = event->vector;
-unsigned int error_code = event->error_code;
-bool use_error_code;
-
-ASSERT(vector == event->vector); /* Confirm no truncation. */
-if ( event->type == X86_EVENTTYPE_HW_EXCEPTION )
-{
-ASSERT(vector < 32);
-use_error_code = TRAP_HAVE_EC & (1u << vector);
-}
-else
-{
-ASSERT(event->type == X86_EVENTTYPE_SW_INTERRUPT);
-use_error_code = false;
-}
-if ( use_error_code )
-ASSERT(error_code != X86_EVENT_NO_EC);
-else
-ASSERT(error_code == X86_EVENT_NO_EC);
-
-tb = >arch.pv_vcpu.trap_bounce;
-ti = >arch.pv_vcpu.trap_ctxt[vector];
-
-tb->flags = TBF_EXCEPTION;
-tb->cs= ti->cs;
-tb->eip   = ti->address;
-
-if ( event->type == X86_EVENTTYPE_HW_EXCEPTION &&
- vector == TRAP_page_fault )
-{
-v->arch.pv_vcpu.ctrlreg[2] = event->cr2;
-arch_set_cr2(v, event->cr2);
-
-/* Re-set error_code.user flag appropriately for the guest. */
-error_code &= ~PFEC_user_mode;
-if ( !guest_kernel_mode(v, regs) )
-error_code |= PFEC_user_mode;
-
-trace_pv_page_fault(event->cr2, error_code);
-}
-else
-trace_pv_trap(vector, regs->rip, use_error_code, error_code);
-
-if ( use_error_code )
-{
-tb->flags |= TBF_EXCEPTION_ERRCODE;
-tb->error_code = error_code;
-}
-
-if ( TI_GET_IF(ti) )
-tb->flags |= TBF_INTERRUPT;
-
-if ( unlikely(null_trap_bounce(v, tb)) )
-{
-gprintk(XENLOG_WARNING,
-"Unhandled %s fault/trap [#%d, ec=%04x]\n",
- 

[Xen-devel] [PATCH v4 03/27] x86: move PV gate op emulation code

[Wei Liu]

Move the code to pv/emul-gate-op.c. Prefix emulate_gate_op with pv_
and export it via pv/traps.h.

Pure code motion except for the rename.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/Makefile   |   1 +
 xen/arch/x86/pv/emul-gate-op.c | 440 +
 xen/arch/x86/traps.c   | 390 +---
 xen/include/asm-x86/pv/traps.h |   2 +
 4 files changed, 444 insertions(+), 389 deletions(-)
 create mode 100644 xen/arch/x86/pv/emul-gate-op.c

diff --git a/xen/arch/x86/pv/Makefile b/xen/arch/x86/pv/Makefile
index e48c460680..1f6fbd3f5c 100644
--- a/xen/arch/x86/pv/Makefile
+++ b/xen/arch/x86/pv/Makefile
@@ -4,5 +4,6 @@ obj-y += traps.o
 obj-bin-y += dom0_build.init.o
 obj-y += domain.o
 obj-y += emulate.o
+obj-y += emul-gate-op.o
 obj-y += emul-priv-op.o
 obj-bin-y += gpr_switch.o
diff --git a/xen/arch/x86/pv/emul-gate-op.c b/xen/arch/x86/pv/emul-gate-op.c
new file mode 100644
index 00..97a4b31a56
--- /dev/null
+++ b/xen/arch/x86/pv/emul-gate-op.c
@@ -0,0 +1,440 @@
+/**
+ * arch/x86/pv/emul-gate-op.c
+ *
+ * Emulate gate op for PV guests
+ *
+ * Modifications to Linux original are copyright (c) 2002-2004, K A Fraser
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "emulate.h"
+
+static int read_gate_descriptor(unsigned int gate_sel,
+const struct vcpu *v,
+unsigned int *sel,
+unsigned long *off,
+unsigned int *ar)
+{
+struct desc_struct desc;
+const struct desc_struct *pdesc;
+
+
+pdesc = (const struct desc_struct *)
+(!(gate_sel & 4) ? GDT_VIRT_START(v) : LDT_VIRT_START(v))
++ (gate_sel >> 3);
+if ( (gate_sel < 4) ||
+ ((gate_sel >= FIRST_RESERVED_GDT_BYTE) && !(gate_sel & 4)) ||
+ __get_user(desc, pdesc) )
+return 0;
+
+*sel = (desc.a >> 16) & 0xfffc;
+*off = (desc.a & 0x) | (desc.b & 0x);
+*ar = desc.b & 0x;
+
+/*
+ * check_descriptor() clears the DPL field and stores the
+ * guest requested DPL in the selector's RPL field.
+ */
+if ( *ar & _SEGMENT_DPL )
+return 0;
+*ar |= (desc.a >> (16 - 13)) & _SEGMENT_DPL;
+
+if ( !is_pv_32bit_vcpu(v) )
+{
+if ( (*ar & 0x1f00) != 0x0c00 ||
+ (gate_sel >= FIRST_RESERVED_GDT_BYTE - 8 && !(gate_sel & 4)) ||
+ __get_user(desc, pdesc + 1) ||
+ (desc.b & 0x1f00) )
+return 0;
+
+*off |= (unsigned long)desc.a << 32;
+return 1;
+}
+
+switch ( *ar & 0x1f00 )
+{
+case 0x0400:
+*off &= 0x;
+break;
+case 0x0c00:
+break;
+default:
+return 0;
+}
+
+return 1;
+}
+
+static inline int check_stack_limit(unsigned int ar, unsigned int limit,
+unsigned int esp, unsigned int decr)
+{
+return (((esp - decr) < (esp - 1)) &&
+(!(ar & _SEGMENT_EC) ? (esp - 1) <= limit : (esp - decr) > limit));
+}
+
+struct gate_op_ctxt {
+struct x86_emulate_ctxt ctxt;
+struct {
+unsigned long base, limit;
+} cs;
+bool insn_fetch;
+};
+
+static int gate_op_read(
+enum x86_segment seg,
+unsigned long offset,
+void *p_data,
+unsigned int bytes,
+struct x86_emulate_ctxt *ctxt)
+{
+const struct gate_op_ctxt *goc =
+container_of(ctxt, struct gate_op_ctxt, ctxt);
+unsigned int rc = bytes, sel = 0;
+unsigned long addr = offset, limit = 0;
+
+switch ( seg )
+{
+case x86_seg_cs:
+addr += goc->cs.base;
+limit = goc->cs.limit;
+break;
+case x86_seg_ds:
+sel = read_sreg(ds);
+break;
+case x86_seg_es:
+sel = read_sreg(es);
+break;
+case x86_seg_fs:
+sel = read_sreg(fs);
+break;
+case x86_seg_gs:
+sel = read_sreg(gs);
+break;
+case x86_seg_ss:
+sel = ctxt->regs->ss;
+break;
+default:
+return 

[Xen-devel] [PATCH v4 01/27] x86: factor out common PV emulation code

[Wei Liu]

We're going to split PV emulation code into several files. This patch
extracts the functions needed by them into a dedicated file.

The functions are now prefixed with "pv_emul_" and exported via a
local header file.

While at it, change bool_t to bool.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/Makefile  |  1 +
 xen/arch/x86/pv/emulate.c | 98 +++
 xen/arch/x86/pv/emulate.h | 10 +
 xen/arch/x86/traps.c  | 95 -
 4 files changed, 126 insertions(+), 78 deletions(-)
 create mode 100644 xen/arch/x86/pv/emulate.c
 create mode 100644 xen/arch/x86/pv/emulate.h

diff --git a/xen/arch/x86/pv/Makefile b/xen/arch/x86/pv/Makefile
index 489a9f59cb..564202cbb7 100644
--- a/xen/arch/x86/pv/Makefile
+++ b/xen/arch/x86/pv/Makefile
@@ -3,3 +3,4 @@ obj-y += traps.o
 
 obj-bin-y += dom0_build.init.o
 obj-y += domain.o
+obj-y += emulate.o
diff --git a/xen/arch/x86/pv/emulate.c b/xen/arch/x86/pv/emulate.c
new file mode 100644
index 00..5750c7699b
--- /dev/null
+++ b/xen/arch/x86/pv/emulate.c
@@ -0,0 +1,98 @@
+/**
+ * arch/x86/pv/emulate.c
+ *
+ * Common PV emulation code
+ *
+ * Modifications to Linux original are copyright (c) 2002-2004, K A Fraser
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see .
+ */
+
+#include 
+
+#include 
+
+#include "emulate.h"
+
+int pv_emul_read_descriptor(unsigned int sel, const struct vcpu *v,
+unsigned long *base, unsigned long *limit,
+unsigned int *ar, bool insn_fetch)
+{
+struct desc_struct desc;
+
+if ( sel < 4)
+desc.b = desc.a = 0;
+else if ( __get_user(desc,
+ (const struct desc_struct *)(!(sel & 4)
+  ? GDT_VIRT_START(v)
+  : LDT_VIRT_START(v))
+ + (sel >> 3)) )
+return 0;
+if ( !insn_fetch )
+desc.b &= ~_SEGMENT_L;
+
+*ar = desc.b & 0x00f0ff00;
+if ( !(desc.b & _SEGMENT_L) )
+{
+*base = ((desc.a >> 16) + ((desc.b & 0xff) << 16) +
+ (desc.b & 0xff00));
+*limit = (desc.a & 0x) | (desc.b & 0x000f);
+if ( desc.b & _SEGMENT_G )
+*limit = ((*limit + 1) << 12) - 1;
+#ifndef NDEBUG
+if ( sel > 3 )
+{
+unsigned int a, l;
+unsigned char valid;
+
+asm volatile (
+"larl %2,%0 ; setz %1"
+: "=r" (a), "=qm" (valid) : "rm" (sel));
+BUG_ON(valid && ((a & 0x00f0ff00) != *ar));
+asm volatile (
+"lsll %2,%0 ; setz %1"
+: "=r" (l), "=qm" (valid) : "rm" (sel));
+BUG_ON(valid && (l != *limit));
+}
+#endif
+}
+else
+{
+*base = 0UL;
+*limit = ~0UL;
+}
+
+return 1;
+}
+
+void pv_emul_instruction_done(struct cpu_user_regs *regs, unsigned long rip)
+{
+regs->rip = rip;
+regs->eflags &= ~X86_EFLAGS_RF;
+if ( regs->eflags & X86_EFLAGS_TF )
+{
+current->arch.debugreg[6] |= DR_STEP | DR_STATUS_RESERVED_ONE;
+pv_inject_hw_exception(TRAP_debug, X86_EVENT_NO_EC);
+}
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/x86/pv/emulate.h b/xen/arch/x86/pv/emulate.h
new file mode 100644
index 00..b2b1192d48
--- /dev/null
+++ b/xen/arch/x86/pv/emulate.h
@@ -0,0 +1,10 @@
+#ifndef __PV_EMULATE_H__
+#define __PV_EMULATE_H__
+
+int pv_emul_read_descriptor(unsigned int sel, const struct vcpu *v,
+unsigned long *base, unsigned long *limit,
+unsigned int *ar, bool insn_fetch);
+
+void pv_emul_instruction_done(struct cpu_user_regs *regs, unsigned long rip);
+
+#endif /* __PV_EMULATE_H__ */
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 52e740f11f..dcc48f9860 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -78,6 +78,8 @@
 #include 
 #include 
 
+#include "pv/emulate.h"
+
 /*
  * opt_nmi: one of 'ignore', 'dom0', or 'fatal'.
  *  fatal:  Xen prints diagnostic message and then hangs.
@@ 

Re: [Xen-devel] Deployment usage and performance of a network domain

[Dario Faggioli]

On Thu, 2017-06-08 at 14:32 +0200, Kashyap Thimmaraju wrote:
> Hi,
> 
> I'm Kashyap Thimmaraju, a second year PhD student at TU Berlin in
> Germany. This is my first post here, and I'm a Xen newbie.
> 
> I saw George Dunlap's presentation "Securing Your Xen-Based Cloud" at
> the LinuxCon on youtube recently as I am interested in using the
> driver domain for networking.
> 
> In the presentation he proposed placing the network driver  and
> forwarding functionality (bridge, iptables, etc.) into a (network)
> driver domain. This is indeed good for security.
> 
> However, I am curious if people are really adopting such an approach.
> Are there cloud providers or PV vendors deploying such an
> architecture? If so, is there any impact on the networking
> performance
> of say VM-VM or VM-Internet traffic?
> 
I'm not aware of any cloud providers doing that (but, that's mostly
because there's not much info about how cloud providers configure their
infrastructure).

Driver domains and stubdomains are hugely used in contexts targeting
really strong security, like Qubes and OpenXT:

https://www.qubes-os.org/
http://openxt.org/

Qubes targets laptops. I've tried it on mine, which is quite old, and
the drop in perf, e.g., wrt a regular (as in, one that does not use
virtualization at all) Linux desktop, although present, I don't think
it comes too much from the driver domain(s).

I haven't run any benchmarks with it, but despite (as I said) the
laptop being quite old, the system is definitely usable.

I know less of OpenXT. The picture int the front page mentions multi-
tenancy (although, it also mention 'clients').

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

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

Re: [Xen-devel] [PATCH 03/44] dmaengine: ioat: don't use DMA_ERROR_CODE

[Dave Jiang]

On 06/08/2017 06:25 AM, Christoph Hellwig wrote:
> DMA_ERROR_CODE is not a public API and will go away.  Instead properly
> unwind based on the loop counter.
> 
> Signed-off-by: Christoph Hellwig 

Acked-by: Dave Jiang 

> ---
>  drivers/dma/ioat/init.c | 24 +++-
>  1 file changed, 7 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/dma/ioat/init.c b/drivers/dma/ioat/init.c
> index 6ad4384b3fa8..ed8ed1192775 100644
> --- a/drivers/dma/ioat/init.c
> +++ b/drivers/dma/ioat/init.c
> @@ -839,8 +839,6 @@ static int ioat_xor_val_self_test(struct ioatdma_device 
> *ioat_dma)
>   goto free_resources;
>   }
>  
> - for (i = 0; i < IOAT_NUM_SRC_TEST; i++)
> - dma_srcs[i] = DMA_ERROR_CODE;
>   for (i = 0; i < IOAT_NUM_SRC_TEST; i++) {
>   dma_srcs[i] = dma_map_page(dev, xor_srcs[i], 0, PAGE_SIZE,
>  DMA_TO_DEVICE);
> @@ -910,8 +908,6 @@ static int ioat_xor_val_self_test(struct ioatdma_device 
> *ioat_dma)
>  
>   xor_val_result = 1;
>  
> - for (i = 0; i < IOAT_NUM_SRC_TEST + 1; i++)
> - dma_srcs[i] = DMA_ERROR_CODE;
>   for (i = 0; i < IOAT_NUM_SRC_TEST + 1; i++) {
>   dma_srcs[i] = dma_map_page(dev, xor_val_srcs[i], 0, PAGE_SIZE,
>  DMA_TO_DEVICE);
> @@ -965,8 +961,6 @@ static int ioat_xor_val_self_test(struct ioatdma_device 
> *ioat_dma)
>   op = IOAT_OP_XOR_VAL;
>  
>   xor_val_result = 0;
> - for (i = 0; i < IOAT_NUM_SRC_TEST + 1; i++)
> - dma_srcs[i] = DMA_ERROR_CODE;
>   for (i = 0; i < IOAT_NUM_SRC_TEST + 1; i++) {
>   dma_srcs[i] = dma_map_page(dev, xor_val_srcs[i], 0, PAGE_SIZE,
>  DMA_TO_DEVICE);
> @@ -1017,18 +1011,14 @@ static int ioat_xor_val_self_test(struct 
> ioatdma_device *ioat_dma)
>   goto free_resources;
>  dma_unmap:
>   if (op == IOAT_OP_XOR) {
> - if (dest_dma != DMA_ERROR_CODE)
> - dma_unmap_page(dev, dest_dma, PAGE_SIZE,
> -DMA_FROM_DEVICE);
> - for (i = 0; i < IOAT_NUM_SRC_TEST; i++)
> - if (dma_srcs[i] != DMA_ERROR_CODE)
> - dma_unmap_page(dev, dma_srcs[i], PAGE_SIZE,
> -DMA_TO_DEVICE);
> + while (--i >= 0)
> + dma_unmap_page(dev, dma_srcs[i], PAGE_SIZE,
> +DMA_TO_DEVICE);
> + dma_unmap_page(dev, dest_dma, PAGE_SIZE, DMA_FROM_DEVICE);
>   } else if (op == IOAT_OP_XOR_VAL) {
> - for (i = 0; i < IOAT_NUM_SRC_TEST + 1; i++)
> - if (dma_srcs[i] != DMA_ERROR_CODE)
> - dma_unmap_page(dev, dma_srcs[i], PAGE_SIZE,
> -DMA_TO_DEVICE);
> + while (--i >= 0)
> + dma_unmap_page(dev, dma_srcs[i], PAGE_SIZE,
> +DMA_TO_DEVICE);
>   }
>  free_resources:
>   dma->device_free_chan_resources(dma_chan);
> 

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

Re: [Xen-devel] [PATCH 19/44] s390: implement ->mapping_error

[Gerald Schaefer]

On Thu,  8 Jun 2017 15:25:44 +0200
Christoph Hellwig  wrote:

> s390 can also use noop_dma_ops, and while that currently does not return
> errors it will so in the future.  Implementing the mapping_error method
> is the proper way to have per-ops error conditions.
> 
> Signed-off-by: Christoph Hellwig 

Acked-by: Gerald Schaefer 


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

Re: [Xen-devel] [PATCH 00/15] xen/tools: add tracing to various Xen subsystems

[Dario Faggioli]

On Wed, 2017-06-07 at 10:13 -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Jun 01, 2017 at 07:33:33PM +0200, Dario Faggioli wrote:
> > 
> > Patch 5 deserves special mention. In fact, now that we have
> > Kconfig, I thought
> > it could be a nice thing to make it possible to select, at build
> > config time,
> > whether we want tracing or not, in the hypervisor (like, for
> > instance, we do
> > for performance counters).
> 
> Did you have thoughts on perhaps using asm goto as an
> alterantive to unlikely?
> 
> In Linux it is called jump labels or such - the idea is that the 
> code has (by default and on x86) five NOP instructions. But you
> can patch it over and add an call to the unlikely code.
> 
Yes, I know. I've never actually looked at the code, but I know they do
that, and I think it's cool.

> But perhaps that is more of an future idea as looking at the Linux
> code
> it looks quite large and not that simple.
> 
I would love for us to do something similar in Xen. I've _thought_
about that many times, but that's it. :-/

Let's see... right now, I can't look into this, as I agree with you
that it would be a major piece of work.

But yes, it's been in my thoughts! :-)

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

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

Re: [Xen-devel] [PATCH 06/15] xen: trace IRQ enabling/disabling

[Dario Faggioli]

On Thu, 2017-06-08 at 17:01 +0100, George Dunlap wrote:
> On 01/06/17 18:34, Dario Faggioli wrote:
> > diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
> > index 374c1c0..81910c9 100644
> > --- a/xen/Kconfig.debug
> > +++ b/xen/Kconfig.debug
> > @@ -98,7 +98,7 @@ config PERF_ARRAYS
> >     ---help---
> >       Enables software performance counter array histograms.
> >  
> > -config TRACING
> > +menuconfig TRACING
> >     bool "Tracing"
> >     default y
> >     ---help---
> > @@ -106,6 +106,15 @@ config TRACING
> >       in per-CPU ring buffers. The 'xentrace' tool can be used
> > to read
> >       the buffers and dump the content on the disk.
> >  
> > +config TRACE_IRQSOFF
> > +   bool "Trace when IRQs are disabled and (re)enabled" if
> > EXPERT = "y"
> > +   default n
> > +   depends on TRACING
> > +   ---help---
> > +     Makes it possible to generate events _every_ time IRQs
> > are disabled
> > +  and (re)enabled, with also an indication of where that
> > happened.
> > +  Note that this comes with high overead and produces huge
> > amount of
> > +  tracing data.
> 
> I think I might emphasize that the overhead well be present even when
> tracing is off.  What about something like this?
> 
Yes, good point.

> "Note that this comes with an overhead even when tracing is disabled;
> and has a high overhead and produces a large amount of tracing data
> when
> enabled."
> 
I like it, I'll go for it.

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

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

Re: [Xen-devel] [PATCH 06/15] xen: trace IRQ enabling/disabling

[Jan Beulich]

>>> On 02.06.17 at 01:42,  wrote:
> On Thu, 2017-06-01 at 20:08 +0100, Andrew Cooper wrote:
>> By writing the trace record while interrupts are disabled, you do
>> prevent nesting in the general case (but not in NMIs/MCEs or the
>> irqsave() variants), 
>>
> Forgive the ignorance, what's special about NMIs/MCAs that is relevant
> for this?

NMI/#MC can nest nevertheless, so preventing nesting in the
common case doesn't mean you won't see nesting at all.

>> Does the logic cope with the fact that interrupt gates automatically
>> disable interrupts?
>> 
> Ah, right. No, it does not. I probably should mention this in the
> changelog. Any ideas of how to deal with that? If yes, I'm more than
> happy to fix this...

Well, respective entry points will need to update tracking state.
See how Linux has placed certain macros to that effect on
various entry paths.

Jan


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

Re: [Xen-devel] [PATCH 06/15] xen: trace IRQ enabling/disabling

[George Dunlap]

On 01/06/17 18:34, Dario Faggioli wrote:
> Trace when interrupts are disabled and (re)enabled.
> Basically, we replace the IRQ disabling and enabling
> functions with helpers that does the same, but also
> output the proper trace record.
> 
> For putting in the record something that will let
> us identify _where_ in the code (i.e., in what function)
> the IRQ manipulation is happening, use either:
>  - current_text_addr(),
>  - or __builtin_return_address(0).
> 
> In fact, depending on whether the disabling/enabling
> happens in macros (like for local_irq_disable() and
> local_irq_enable()) or in actual functions (like in
> spin_lock_irq*()), it is either:
>  - the actual content of the instruction pointer when
>IRQ are disabled/enabled,
>  - or the return address of the utility function where
>IRQ are disabled/enabled,
> that will tell us what it is the actual piece of code
> that is asking for the IRQ manipulation operation.
> 
> Gate this with its specific Kconfig option, and keep
> it in disabled state by default (i.e., don't build it,
> if not explicitly specified), as the impact on
> performance may be non negligible.
> 
> Signed-off-by: Dario Faggioli 
> ---
> Cc: George Dunlap 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Jennifer Herbert 
> ---
>  xen/Kconfig.debug  |   11 -
>  xen/common/spinlock.c  |   16 +--
>  xen/common/trace.c |   10 +++-
>  xen/include/asm-arm/arm32/system.h |   12 +
>  xen/include/asm-arm/arm64/system.h |   12 +
>  xen/include/asm-x86/system.h   |   85 
> ++--
>  xen/include/public/trace.h |2 +
>  xen/include/xen/rwlock.h   |   33 +++---
>  8 files changed, 161 insertions(+), 20 deletions(-)
> 
> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
> index 374c1c0..81910c9 100644
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -98,7 +98,7 @@ config PERF_ARRAYS
>   ---help---
> Enables software performance counter array histograms.
>  
> -config TRACING
> +menuconfig TRACING
>   bool "Tracing"
>   default y
>   ---help---
> @@ -106,6 +106,15 @@ config TRACING
> in per-CPU ring buffers. The 'xentrace' tool can be used to read
> the buffers and dump the content on the disk.
>  
> +config TRACE_IRQSOFF
> + bool "Trace when IRQs are disabled and (re)enabled" if EXPERT = "y"
> + default n
> + depends on TRACING
> + ---help---
> +   Makes it possible to generate events _every_ time IRQs are disabled
> +  and (re)enabled, with also an indication of where that happened.
> +  Note that this comes with high overead and produces huge amount of
> +  tracing data.

*overhead (yours is missing an 'h')

I think I might emphasize that the overhead well be present even when
tracing is off.  What about something like this?

"Note that this comes with an overhead even when tracing is disabled;
and has a high overhead and produces a large amount of tracing data when
enabled."

With that change:

Acked-by: George Dunlap 


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

Re: [Xen-devel] [Resend][PATCH 01/17] rb_tree: reorganize code in rb_erase() for additional changes

[Jan Beulich]

>>> On 31.05.17 at 23:20,  wrote:
> First, move some code around in order to make the next change more obvious.
> 
> commit 16c047add3ceaf0ab882e3e094d1ec904d02312d from linux tree
> 
> Signed-off-by: Praveen Kumar 

You've completely lost all original authorship - this is a no-go. You'll
need to introduce a From: tag and retain at least the S-o-b-s of
people having actively contributed to the change. Considering the
original commit message, that's at least Peter and Andrew. If in
doubt, keep all of them. You'd add yours below the ones you keep.
Also please reproduce the full commit message (i.e. here also
including Andrew's remark in square brackets).

I guess the same will apply to the rest of the series, and since
actually reviewing the content (when it comes from another, pre-
reviewed source) is pretty pointless, I'll drop the entire series for
now, in expectation of a v2.

Jan


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

Re: [Xen-devel] [PATCH 06/15] xen: trace IRQ enabling/disabling

[George Dunlap]

On 02/06/17 00:42, Dario Faggioli wrote:
> On Thu, 2017-06-01 at 20:08 +0100, Andrew Cooper wrote:
>> On 01/06/17 18:34, Dario Faggioli wrote:
>>> diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
>>> index 2a06406..33b903e 100644
>>> --- a/xen/common/spinlock.c
>>> +++ b/xen/common/spinlock.c
>>> @@ -150,7 +150,9 @@ void _spin_lock(spinlock_t *lock)
>>>  void _spin_lock_irq(spinlock_t *lock)
>>>  {
>>>  ASSERT(local_irq_is_enabled());
>>> -local_irq_disable();
>>> +_local_irq_disable();
>>> +if ( unlikely(tb_init_done) )
>>> +trace_irq_disable_ret();
>>>  _spin_lock(lock);
>>>  }
>>
>> Is it sensible to do this way around?
>>
> Well, I guess either variant has up and down sides, and it looks to me
> that there is no way to measure this, without interfering with the
> behavior of the thing being measured ("Once upon a time, there was a
> cat, who lived in a box. His name was Schrödinger..." :-D :-D :-D)
> 
>> By writing the trace record while interrupts are disabled, you do
>> prevent nesting in the general case (but not in NMIs/MCEs or the
>> irqsave() variants), 
>>
> Forgive the ignorance, what's special about NMIs/MCAs that is relevant
> for this? About _irqsave(), I'm also not sure what you mean, as
> _irqsave() is already done differently than this.
> 
>> but you increase the critical region while
>> interrupts are disabled.
>>
> I know.
> 
>> Alternatively, writing the trace record outside of the critical
>> region
>> would reduce the size of the region.  Interpretation logic already
>> needs
>> to cope with nesting, so is one extra level of nesting in this corner
>> case a problem?
>>
> TBH, I was indeed trying to offer to the component that will be looking
> at and interpreting the data, the as clear as possible view on when
> IRQs are _actually_ disabled and enabled. As in, if nesting occurs,
> only the event corresponding to:
>  - the first local_irq_disable()
>  - the last local_irq_enable()
> 
> I.e., to not require that it (the interpretation logic) does understand
> nesting.
> 
> But more than this, what I was concerned about was the accuracy of the
> reporting itself. In fact, if I do as you suggest, I can be interrupted
> (as interrupts are still on) after having called trace_irq_disable().
> That means the report will show higher IRQ disabled time period, for
> this instance, than what the reality is.
> 
> And the same is true on the enabling side, when I call
> trace_irq_enable() _before_ re-enabling interrupts, which has the same
> bad effect on the length of IRQ disabled section.
> 
> Maybe, considering that anything that will interrupt me in these cases,
> are other interrupts, that will most likely disable interrupts
> themselves, I should not worry too much about this... What do you
> think?

I think it would make the analysis easier to do it the way you've done
it.  It certainly does increase the length of the actual critical
section, but we're already assuming that all of this code is going to be
disabled unless people specifically want to do IRQ analysis, so I don't
think that should be an issue.

 -George


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

[Xen-devel] [PATCH] x86emul: minor cleanup

[Jan Beulich]

Drop a redundant input constraint, correct a comment, and (re)move
fix.insn_bytes adjustments (these aren't needed for custom stub
invocations when the instruction placed in the stub can't raise #XF)
plus a corresponding check_xmm_exn() invocation.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -5681,8 +5681,7 @@ x86_emulate(
 [eflags] "+g" (_regs.eflags),
 [tmp] "=" (dummy), "+m" (*mmvalp),
 "+m" (fic.exn_raised)
-: [func] "rm" (stub.func), "a" (mmvalp),
-  [mask] "i" (EFLAGS_MASK));
+: "a" (mmvalp), [mask] "i" (EFLAGS_MASK));
 
 put_stub(stub);
 check_xmm_exn();
@@ -6086,7 +6085,7 @@ x86_emulate(
 case X86EMUL_OPC_F3(0x0f, 0x6f): /* movdqu xmm/m128,xmm */
 case X86EMUL_OPC_VEX_F3(0x0f, 0x6f): /* vmovdqu {x,y}mm/mem,{x,y}mm */
 case X86EMUL_OPC_66(0x0f, 0x7f): /* movdqa xmm,xmm/m128 */
-case X86EMUL_OPC_VEX_66(0x0f, 0x7f): /* vmovdqa {x,y}mm,{x,y}mm/m128 */
+case X86EMUL_OPC_VEX_66(0x0f, 0x7f): /* vmovdqa {x,y}mm,{x,y}mm/mem */
 case X86EMUL_OPC_F3(0x0f, 0x7f): /* movdqu xmm,xmm/m128 */
 case X86EMUL_OPC_VEX_F3(0x0f, 0x7f): /* vmovdqu {x,y}mm,{x,y}mm/mem */
 movdqa:
@@ -7022,7 +7021,6 @@ x86_emulate(
 if ( !mode_64bit() )
 vex.w = 0;
 opc[1] = modrm & 0xc7;
-fic.insn_bytes = PFX_BYTES + 2;
 opc[2] = 0xc3;
 
 copy_REX_VEX(opc, rex_prefix, vex);
@@ -7035,6 +7033,7 @@ x86_emulate(
 opc = init_prefixes(stub);
 opc[0] = b;
 opc[1] = modrm;
+fic.insn_bytes = PFX_BYTES + 2;
 /* Restore high bit of XMM destination. */
 if ( sfence )
 {
@@ -7469,20 +7468,16 @@ x86_emulate(
 vex.w = 0;
 opc[1] = modrm & 0x38;
 opc[2] = imm1;
-fic.insn_bytes = PFX_BYTES + 3;
 opc[3] = 0xc3;
 if ( vex.opcx == vex_none )
 {
 /* Cover for extra prefix byte. */
 --opc;
-++fic.insn_bytes;
 }
 
 copy_REX_VEX(opc, rex_prefix, vex);
 invoke_stub("", "", "=m" (dst.val) : "a" ());
-
 put_stub(stub);
-check_xmm_exn();
 
 ASSERT(!state->simd_size);
 dst.bytes = dst.type == OP_REG || b == 0x17 ? 4 : 1 << (b & 3);



x86emul: minor cleanup

Drop a redundant input constraint, correct a comment, and (re)move
fix.insn_bytes adjustments (these aren't needed for custom stub
invocations when the instruction placed in the stub can't raise #XF)
plus a corresponding check_xmm_exn() invocation.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -5681,8 +5681,7 @@ x86_emulate(
 [eflags] "+g" (_regs.eflags),
 [tmp] "=" (dummy), "+m" (*mmvalp),
 "+m" (fic.exn_raised)
-: [func] "rm" (stub.func), "a" (mmvalp),
-  [mask] "i" (EFLAGS_MASK));
+: "a" (mmvalp), [mask] "i" (EFLAGS_MASK));
 
 put_stub(stub);
 check_xmm_exn();
@@ -6086,7 +6085,7 @@ x86_emulate(
 case X86EMUL_OPC_F3(0x0f, 0x6f): /* movdqu xmm/m128,xmm */
 case X86EMUL_OPC_VEX_F3(0x0f, 0x6f): /* vmovdqu {x,y}mm/mem,{x,y}mm */
 case X86EMUL_OPC_66(0x0f, 0x7f): /* movdqa xmm,xmm/m128 */
-case X86EMUL_OPC_VEX_66(0x0f, 0x7f): /* vmovdqa {x,y}mm,{x,y}mm/m128 */
+case X86EMUL_OPC_VEX_66(0x0f, 0x7f): /* vmovdqa {x,y}mm,{x,y}mm/mem */
 case X86EMUL_OPC_F3(0x0f, 0x7f): /* movdqu xmm,xmm/m128 */
 case X86EMUL_OPC_VEX_F3(0x0f, 0x7f): /* vmovdqu {x,y}mm,{x,y}mm/mem */
 movdqa:
@@ -7022,7 +7021,6 @@ x86_emulate(
 if ( !mode_64bit() )
 vex.w = 0;
 opc[1] = modrm & 0xc7;
-fic.insn_bytes = PFX_BYTES + 2;
 opc[2] = 0xc3;
 
 copy_REX_VEX(opc, rex_prefix, vex);
@@ -7035,6 +7033,7 @@ x86_emulate(
 opc = init_prefixes(stub);
 opc[0] = b;
 opc[1] = modrm;
+fic.insn_bytes = PFX_BYTES + 2;
 /* Restore high bit of XMM destination. */
 if ( sfence )
 {
@@ -7469,20 +7468,16 @@ x86_emulate(
 vex.w = 0;
 opc[1] = modrm & 0x38;
 opc[2] = imm1;
-fic.insn_bytes = PFX_BYTES + 3;
 opc[3] = 0xc3;
 if ( vex.opcx == vex_none )
 {
 /* Cover for extra prefix byte. */
 --opc;
-++fic.insn_bytes;
 }
 
 copy_REX_VEX(opc, rex_prefix, vex);
 invoke_stub("", "", "=m" (dst.val) : "a" ());
-
 put_stub(stub);
-check_xmm_exn();
 
 ASSERT(!state->simd_size);
 dst.bytes = dst.type == OP_REG || b == 0x17 ? 4 : 1 << (b & 3);
___
Xen-devel mailing list

Re: [Xen-devel] [PATCH 05/15] xen: make it possible to disable tracing in Kconfig.

[Jan Beulich]

>>> On 08.06.17 at 17:37,  wrote:
> On 08/06/17 16:35, Jan Beulich wrote:
> On 08.06.17 at 17:16,  wrote:
>>> On 07/06/17 16:14, Jan Beulich wrote:
>>> On 01.06.17 at 19:34,  wrote:
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -98,6 +98,14 @@ config PERF_ARRAYS
>   ---help---
> Enables software performance counter array histograms.
>  
> +config TRACING
> + bool "Tracing"
> + default y

 default DEBUG (you don't want to suggest turning it on for a
 release build)
>>>
>>> In the past I've found it pretty useful to have on in release builds of
>>> XenServer, to analyze performance problems a customer was having, and
>>> sometimes to see where the guest was crashing.
>> 
>> Well, that's your choice. I'm only asking to default to off in release
>> builds, not to prevent enabling it.
> 
> Of course; the question is, as you say, what we're "suggesting"; and
> what people will experience if they just go with the default.
> 
> If it were up to me I'd leave it on by default, but I don't have a
> strong opinion.

If you look at that section in Kconfig.debug, nothing defaults to
y, and I think this is appropriate for debug options in general. I
additionally think that defaults suggested in EXPERT mode should
match the values automatically chosen in non-EXPERT mode.

Jan


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

Re: [Xen-devel] [PATCH 05/15] xen: make it possible to disable tracing in Kconfig.

[George Dunlap]

On 08/06/17 16:35, Jan Beulich wrote:
 On 08.06.17 at 17:16,  wrote:
>> On 07/06/17 16:14, Jan Beulich wrote:
>> On 01.06.17 at 19:34,  wrote:
 --- a/xen/Kconfig.debug
 +++ b/xen/Kconfig.debug
 @@ -98,6 +98,14 @@ config PERF_ARRAYS
---help---
  Enables software performance counter array histograms.
  
 +config TRACING
 +  bool "Tracing"
 +  default y
>>>
>>> default DEBUG (you don't want to suggest turning it on for a
>>> release build)
>>
>> In the past I've found it pretty useful to have on in release builds of
>> XenServer, to analyze performance problems a customer was having, and
>> sometimes to see where the guest was crashing.
> 
> Well, that's your choice. I'm only asking to default to off in release
> builds, not to prevent enabling it.

Of course; the question is, as you say, what we're "suggesting"; and
what people will experience if they just go with the default.

If it were up to me I'd leave it on by default, but I don't have a
strong opinion.

 -George

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

Re: [Xen-devel] [PATCH 05/15] xen: make it possible to disable tracing in Kconfig.

[Jan Beulich]

>>> On 08.06.17 at 17:16,  wrote:
> On 07/06/17 16:14, Jan Beulich wrote:
> On 01.06.17 at 19:34,  wrote:
>>> --- a/xen/Kconfig.debug
>>> +++ b/xen/Kconfig.debug
>>> @@ -98,6 +98,14 @@ config PERF_ARRAYS
>>> ---help---
>>>   Enables software performance counter array histograms.
>>>  
>>> +config TRACING
>>> +   bool "Tracing"
>>> +   default y
>> 
>> default DEBUG (you don't want to suggest turning it on for a
>> release build)
> 
> In the past I've found it pretty useful to have on in release builds of
> XenServer, to analyze performance problems a customer was having, and
> sometimes to see where the guest was crashing.

Well, that's your choice. I'm only asking to default to off in release
builds, not to prevent enabling it.

Jan


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

Re: [Xen-devel] [PATCH 03/15] xen/tools: tracing: several improvements on IRQs tracing

[Jan Beulich]

>>> On 08.06.17 at 16:53,  wrote:
> On 07/06/17 16:58, Jan Beulich wrote:
> On 07.06.17 at 17:45,  wrote:
>>> On Wed, 2017-06-07 at 09:05 -0600, Jan Beulich wrote:
>>> On 01.06.17 at 19:33,  wrote:
> @@ -884,9 +919,13 @@ void do_IRQ(struct cpu_user_regs *regs)
>  desc->rl_quantum_start = now;
>  }
>  
> -tsc_in = tb_init_done ? get_cycles() : 0;
> +if ( unlikely(tb_init_done) )
> +{
> +__trace_var(TRC_HW_IRQ_GUEST, 0, sizeof(irq), );
> +tsc_in = get_cycles();
> +}
>  __do_IRQ_guest(irq);
> -TRACE_3D(TRC_HW_IRQ_HANDLED, irq, tsc_in, get_cycles());
> +trace_irq_handled(irq, get_cycles() - tsc_in);
>  goto out_no_end;
>  }

 Before this change, the get_cycles() invocation was after
 the tb_init_done check. Now you move it ahead of it (as
 the function arguments are evaluated before executing the
 function body) - are you sure all compiler versions will suitably
 re-order this?

 Additionally I'm afraid this will trigger compiler warnings on at
 least some compiler versions, as tsc_in is now possibly
 uninitialized (and there's no clear way to disprove this for the
 compiler, again because function arguments are being
 evaluated before the function body is reached).

>>> I understand and (now that I see it) agree with your remark on when
>>> get_cycles() is called. I'll reorganize things so that the patched
>>> behavior matches the existing one.
>>>
>>> OTOH, I'm not sure I see the "potentially uninitialized" issue for
>>> tsc_in, but since I'm reworking the code, I'll keep that in mind too.
>> 
>> You initialize tsc_in only when tb_init_done is set, but you use
>> it without that conditional. And even if you used it under that
>> same conditional, older compiler versions aren't able to track
>> that fact (same conditional) and raise a warning anyway.
> 
> This patch changes thing to initialize tsc_in on declaration (at the top
> of the function).

Oh, it's only now that I actually see an initializer is being added.
I'm sorry for the noise then.

> If we want to keep the compiler "uninitialized variable" analysis
> around, that would have to go away and we'd want to do something like
> was there before.  (I'm ambivalent about it, but I know Jan likes it.)

No, I'm fine with the change. I was just being blind.

Jan


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

[Xen-devel] [PATCH] x86/mm: drop further relics of translated PV domains

[Jan Beulich]

For PV domains paging_mode_{refcounts,translate}() are always false as
of commits 4045953527 ("x86/paging: Enforce PG_external == PG_translate
== PG_refcounts") and 92942fd3d4 ("x86/mm: drop
guest_{map,get_eff}_l1e() hooks").

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1591,7 +1591,7 @@ void init_guest_l4_table(l4_pgentry_t l4
 l4e_from_pfn(domain_page_map_to_mfn(l4tab), __PAGE_HYPERVISOR_RW);
 l4tab[l4_table_offset(PERDOMAIN_VIRT_START)] =
 l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW);
-if ( zap_ro_mpt || is_pv_32bit_domain(d) || paging_mode_refcounts(d) )
+if ( zap_ro_mpt || is_pv_32bit_domain(d) )
 l4tab[l4_table_offset(RO_MPT_VIRT_START)] = l4e_empty();
 }
 
@@ -1902,12 +1902,7 @@ static int mod_l1_entry(l1_pgentry_t *pl
 if ( unlikely(__copy_from_user(, pl1e, sizeof(ol1e)) != 0) )
 return -EFAULT;
 
-if ( unlikely(paging_mode_refcounts(pt_dom)) )
-{
-if ( UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, preserve_ad) )
-return 0;
-return -EBUSY;
-}
+ASSERT(!paging_mode_refcounts(pt_dom));
 
 if ( l1e_get_flags(nl1e) & _PAGE_PRESENT )
 {
@@ -2359,8 +2354,7 @@ int free_page_type(struct page_info *pag
 /* A page table is dirtied when its type count becomes zero. */
 paging_mark_dirty(owner, _mfn(page_to_mfn(page)));
 
-if ( shadow_mode_refcounts(owner) )
-return 0;
+ASSERT(!shadow_mode_refcounts(owner));
 
 gmfn = mfn_to_gmfn(owner, page_to_mfn(page));
 ASSERT(VALID_M2P(gmfn));
@@ -2960,14 +2954,11 @@ int new_guest_cr3(unsigned long mfn)
 unsigned long gt_mfn = pagetable_get_pfn(curr->arch.guest_table);
 l4_pgentry_t *pl4e = map_domain_page(_mfn(gt_mfn));
 
-rc = paging_mode_refcounts(d)
- ? -EINVAL /* Old code was broken, but what should it be? */
- : mod_l4_entry(
-pl4e,
-l4e_from_pfn(
-mfn,
-(_PAGE_PRESENT|_PAGE_RW|_PAGE_USER|_PAGE_ACCESSED)),
-gt_mfn, 0, curr);
+rc = mod_l4_entry(pl4e,
+  l4e_from_pfn(mfn,
+   (_PAGE_PRESENT | _PAGE_RW |
+_PAGE_USER | _PAGE_ACCESSED)),
+  gt_mfn, 0, curr);
 unmap_domain_page(pl4e);
 switch ( rc )
 {
@@ -3069,13 +3060,6 @@ static struct domain *get_pg_owner(domid
 goto out;
 }
 
-if ( !is_hvm_domain(curr) && unlikely(paging_mode_translate(curr)) )
-{
-gdprintk(XENLOG_WARNING,
- "Cannot mix foreign mappings with translated domains\n");
-goto out;
-}
-
 switch ( domid )
 {
 case DOMID_IO:
@@ -3384,11 +3368,9 @@ long do_mmuext_op(
 
 if ( op.arg1.mfn != 0 )
 {
-if ( paging_mode_refcounts(d) )
-rc = get_page_from_pagenr(op.arg1.mfn, d) ? 0 : -EINVAL;
-else
-rc = get_page_and_type_from_pagenr(
-op.arg1.mfn, PGT_root_page_table, d, 0, 1);
+rc = get_page_and_type_from_pagenr(op.arg1.mfn,
+   PGT_root_page_table,
+   d, 0, 1);
 
 if ( unlikely(rc) )
 {
@@ -3400,7 +3382,7 @@ long do_mmuext_op(
  rc, op.arg1.mfn);
 break;
 }
-if ( VM_ASSIST(d, m2p_strict) && !paging_mode_refcounts(d) )
+if ( VM_ASSIST(d, m2p_strict) )
 zap_ro_mpt(op.arg1.mfn);
 }
 
@@ -3410,21 +3392,18 @@ long do_mmuext_op(
 {
 page = mfn_to_page(old_mfn);
 
-if ( paging_mode_refcounts(d) )
-put_page(page);
-else
-switch ( rc = put_page_and_type_preemptible(page) )
-{
-case -EINTR:
-rc = -ERESTART;
-/* fallthrough */
-case -ERESTART:
-curr->arch.old_guest_table = page;
-break;
-default:
-BUG_ON(rc);
-break;
-}
+switch ( rc = put_page_and_type_preemptible(page) )
+{
+case -EINTR:
+rc = -ERESTART;
+/* fallthrough */
+case -ERESTART:
+curr->arch.old_guest_table = page;
+break;
+default:
+BUG_ON(rc);
+break;
+}
 }
 
 break;
@@ -4035,8 +4014,7 @@ 

[Xen-devel] [PATCH] x86: get_page_from_gfn() should not return misleading type

[Jan Beulich]

It is not impossible that the page owner is dom_io. While no current
caller cares about this case, let's nevertheless return an appropriate
type even in that case.

Signed-off-by: Jan Beulich 

--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -479,9 +479,9 @@ static inline struct page_info *get_page
 if ( paging_mode_translate(d) )
 return get_page_from_gfn_p2m(d, p2m_get_hostp2m(d), gfn, t, NULL, q);
 
-/* Non-translated guests see 1-1 RAM mappings everywhere */
-if (t)
-*t = p2m_ram_rw;
+/* Non-translated guests see 1-1 RAM / MMIO mappings everywhere */
+if ( t )
+*t = likely(d != dom_io) ? p2m_ram_rw : p2m_mmio_direct;
 page = __mfn_to_page(gfn);
 return mfn_valid(_mfn(gfn)) && get_page(page, d) ? page : NULL;
 }



x86: get_page_from_gfn() should not return misleading type

It is not impossible that the page owner is dom_io. While no current
caller cares about this case, let's nevertheless return an appropriate
type even in that case.

Signed-off-by: Jan Beulich 

--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -479,9 +479,9 @@ static inline struct page_info *get_page
 if ( paging_mode_translate(d) )
 return get_page_from_gfn_p2m(d, p2m_get_hostp2m(d), gfn, t, NULL, q);
 
-/* Non-translated guests see 1-1 RAM mappings everywhere */
-if (t)
-*t = p2m_ram_rw;
+/* Non-translated guests see 1-1 RAM / MMIO mappings everywhere */
+if ( t )
+*t = likely(d != dom_io) ? p2m_ram_rw : p2m_mmio_direct;
 page = __mfn_to_page(gfn);
 return mfn_valid(_mfn(gfn)) && get_page(page, d) ? page : NULL;
 }
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH] public: there's no MMUEXT_SET_FOREIGNDOM

[Jan Beulich]

Correct respective comments.

Signed-off-by: Jan Beulich 
---
MMUEXT_{CLEAR,COPY}_PAGE in fact also allow to be invoked on DOMID_IO
owned pages at present. I've intentionally not added this to the text,
as I'm not sure we really mean to allow this. If we do, I think the
operation should also be allowed for MMIO pages not happening to have
an associated struct page_info.

--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -550,16 +550,19 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t);
  * is useful to ensure that no mappings to the OS's own heap are accidentally
  * installed. (e.g., in Linux this could cause havoc as reference counts
  * aren't adjusted on the I/O-mapping code path).
- * This only makes sense in MMUEXT_SET_FOREIGNDOM, but in that context can
- * be specified by any calling domain.
+ * This only makes sense as HYPERVISOR_mmu_update()'s and
+ * HYPERVISOR_update_va_mapping_otherdomain()'s "foreigndom" argument. For
+ * HYPERVISOR_mmu_update() context it can be specified by any calling domain,
+ * otherwise it's only permitted if the caller is privileged.
  */
 #define DOMID_IO xen_mk_uint(0x7FF1)
 
 /*
  * DOMID_XEN is used to allow privileged domains to map restricted parts of
  * Xen's heap space (e.g., the machine_to_phys table).
- * This only makes sense in MMUEXT_SET_FOREIGNDOM, and is only permitted if
- * the caller is privileged.
+ * This only makes sense as HYPERVISOR_mmu_update()'s, 
HYPERVISOR_mmuext_op()'s,
+ * or HYPERVISOR_update_va_mapping_otherdomain()'s "foreigndom" argument, and 
is
+ * only permitted if the caller is privileged.
  */
 #define DOMID_XENxen_mk_uint(0x7FF2)
 



public: there's no MMUEXT_SET_FOREIGNDOM

Correct respective comments.

Signed-off-by: Jan Beulich 
---
MMUEXT_{CLEAR,COPY}_PAGE in fact also allow to be invoked on DOMID_IO
owned pages at present. I've intentionally not added this to the text,
as I'm not sure we really mean to allow this. If we do, I think the
operation should also be allowed for MMIO pages not happening to have
an associated struct page_info.

--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -550,16 +550,19 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t);
  * is useful to ensure that no mappings to the OS's own heap are accidentally
  * installed. (e.g., in Linux this could cause havoc as reference counts
  * aren't adjusted on the I/O-mapping code path).
- * This only makes sense in MMUEXT_SET_FOREIGNDOM, but in that context can
- * be specified by any calling domain.
+ * This only makes sense as HYPERVISOR_mmu_update()'s and
+ * HYPERVISOR_update_va_mapping_otherdomain()'s "foreigndom" argument. For
+ * HYPERVISOR_mmu_update() context it can be specified by any calling domain,
+ * otherwise it's only permitted if the caller is privileged.
  */
 #define DOMID_IO xen_mk_uint(0x7FF1)
 
 /*
  * DOMID_XEN is used to allow privileged domains to map restricted parts of
  * Xen's heap space (e.g., the machine_to_phys table).
- * This only makes sense in MMUEXT_SET_FOREIGNDOM, and is only permitted if
- * the caller is privileged.
+ * This only makes sense as HYPERVISOR_mmu_update()'s, 
HYPERVISOR_mmuext_op()'s,
+ * or HYPERVISOR_update_va_mapping_otherdomain()'s "foreigndom" argument, and 
is
+ * only permitted if the caller is privileged.
  */
 #define DOMID_XENxen_mk_uint(0x7FF2)
 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 05/15] xen: make it possible to disable tracing in Kconfig.

[George Dunlap]

On 01/06/17 18:34, Dario Faggioli wrote:
> And compile it out of the hypervisor entirely.
> 
> Code and other sections' sizes change as follows.
> 
> Output of `size`:
>   vanilla  patched-Y  patched-N
> text  192900719290071902783
> data   337784 337784 337688
> bss   131046413104641310336
> 
> Output of `size -A`:
> vanilla  patched-Y  patched-N
> .text   137260213726021348026
> .rodata  312152 312152 310680
> .init.text   244209 244209 244033
> .init.data   224576 224576 224576
> .data 57472  57472  57376
> .bss131046413104641310336
> Total  23026516   23027008   22858069
> 
> No functional change intended.
> 
> Signed-off-by: Dario Faggioli 

Thanks Dario -- patch looks good overall; I agree with all of Jan and
Andy's comments that I haven't responded to. :-)

 -George


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

Re: [Xen-devel] [PATCH 05/15] xen: make it possible to disable tracing in Kconfig.

[George Dunlap]

On 07/06/17 16:14, Jan Beulich wrote:
 On 01.06.17 at 19:34,  wrote:
>> --- a/xen/Kconfig.debug
>> +++ b/xen/Kconfig.debug
>> @@ -98,6 +98,14 @@ config PERF_ARRAYS
>>  ---help---
>>Enables software performance counter array histograms.
>>  
>> +config TRACING
>> +bool "Tracing"
>> +default y
> 
> default DEBUG (you don't want to suggest turning it on for a
> release build)

In the past I've found it pretty useful to have on in release builds of
XenServer, to analyze performance problems a customer was having, and
sometimes to see where the guest was crashing.

 -George


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

Re: [Xen-devel] [PATCH 04/15] tools: xenalyze: fix dumping of PM_IDLE events.

[George Dunlap]

On Thu, Jun 1, 2017 at 6:34 PM, Dario Faggioli
 wrote:
> In fact, not all the information present in the trace
> record were used and printed.
>
> Signed-off-by: Dario Faggioli 

Reviewed-by: George Dunlap 

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

Re: [Xen-devel] [PATCH 03/15] xen/tools: tracing: several improvements on IRQs tracing

[George Dunlap]

On 01/06/17 18:33, Dario Faggioli wrote:
> More specifically:
>  - the handling of the TRC_HW_IRQ_HANDLED is fixed, both in
>xentrace_format and in xenalyze;
>  - simple events for recording when we enter and exit the
>do_IRQ function, as well as when we deal with a guest
>IRQ, are added;
>  - tracing of IRQs handled with direct vectors is also
>added.
> 
> With all the above, a trace will now look like this (using
> xenalyze):
> 
>  0.001299072 .x- d32768v5 irq_enter, irq 8000
>  0.001299072 .x- d32768v5 irq_direct, vec fa, handler = 0x82d08026d7e4
>  0.001300014 .x- d32768v5 raise_softirq nr 0
>  0.001300487 .x- d32768v5 irq_exit irq 8000, in_irq = 0
> 
> Or like this:
> 
>  0.049437892 -|- d32767v12 irq_enter, irq 4
>  0.049437892 -|- d32767v12 irq_handled irq 4, 85428 cycles
>  0.049474336 -|- d32767v12 irq_exit irq 4, status = 0x0, in_irq = 0
> 
> Making it much easier to figure out when interrupt
> processing start, what it does and when it ends.
> 
> Signed-off-by: Dario Faggioli 

Generally looks good to me.  I mostly agree with the commentary as well.

 -George


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

Re: [Xen-devel] [PATCH 03/15] xen/tools: tracing: several improvements on IRQs tracing

[George Dunlap]

On 07/06/17 16:58, Jan Beulich wrote:
 On 07.06.17 at 17:45,  wrote:
>> On Wed, 2017-06-07 at 09:05 -0600, Jan Beulich wrote:
>> On 01.06.17 at 19:33,  wrote:
 @@ -884,9 +919,13 @@ void do_IRQ(struct cpu_user_regs *regs)
  desc->rl_quantum_start = now;
  }
  
 -tsc_in = tb_init_done ? get_cycles() : 0;
 +if ( unlikely(tb_init_done) )
 +{
 +__trace_var(TRC_HW_IRQ_GUEST, 0, sizeof(irq), );
 +tsc_in = get_cycles();
 +}
  __do_IRQ_guest(irq);
 -TRACE_3D(TRC_HW_IRQ_HANDLED, irq, tsc_in, get_cycles());
 +trace_irq_handled(irq, get_cycles() - tsc_in);
  goto out_no_end;
  }
>>>
>>> Before this change, the get_cycles() invocation was after
>>> the tb_init_done check. Now you move it ahead of it (as
>>> the function arguments are evaluated before executing the
>>> function body) - are you sure all compiler versions will suitably
>>> re-order this?
>>>
>>> Additionally I'm afraid this will trigger compiler warnings on at
>>> least some compiler versions, as tsc_in is now possibly
>>> uninitialized (and there's no clear way to disprove this for the
>>> compiler, again because function arguments are being
>>> evaluated before the function body is reached).
>>>
>> I understand and (now that I see it) agree with your remark on when
>> get_cycles() is called. I'll reorganize things so that the patched
>> behavior matches the existing one.
>>
>> OTOH, I'm not sure I see the "potentially uninitialized" issue for
>> tsc_in, but since I'm reworking the code, I'll keep that in mind too.
> 
> You initialize tsc_in only when tb_init_done is set, but you use
> it without that conditional. And even if you used it under that
> same conditional, older compiler versions aren't able to track
> that fact (same conditional) and raise a warning anyway.

This patch changes thing to initialize tsc_in on declaration (at the top
of the function).

If we want to keep the compiler "uninitialized variable" analysis
around, that would have to go away and we'd want to do something like
was there before.  (I'm ambivalent about it, but I know Jan likes it.)

 -George

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

Re: [Xen-devel] [PATCH 25/44] arm: implement ->mapping_error

[Russell King - ARM Linux]

BOn Thu, Jun 08, 2017 at 03:25:50PM +0200, Christoph Hellwig wrote:
> +static int dmabounce_mapping_error(struct device *dev, dma_addr_t dma_addr)
> +{
> + if (dev->archdata.dmabounce)
> + return 0;

I'm not convinced that we need this check here:

dev->archdata.dmabounce = device_info;
set_dma_ops(dev, _ops);

There shouldn't be any chance of dev->archdata.dmabounce being NULL if
the dmabounce_ops has been set as the current device DMA ops.  So I
think that test can be killed.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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

Re: [Xen-devel] [PATCH 01/15] xen: in do_softirq() sample smp_processor_id() once and for all.

[Jan Beulich]

>>> On 08.06.17 at 16:20,  wrote:
> On 01/06/17 18:33, Dario Faggioli wrote:
>> In fact, right now, we read it at every iteration of the loop.
>> The reason it's done like this is how context switch was handled
>> on IA64 (see commit ae9bfcdc, "[XEN] Various softirq cleanups" [1]).
>> 
>> However:
>> 1) we don't have IA64 any longer, and all the achitectures that
>>we do support, are ok with sampling once and for all;
>> 2) sampling at every iteration (slightly) affect performance;
>> 3) sampling at every iteration is misleading, as it makes people
>>believe that it is currently possible that SCHEDULE_SOFTIRQ
>>moves the execution flow on another CPU (and the comment,
>>by reinforcing this belief, makes things even worse!).
>> 
>> Therefore, let's:
>> - do the sampling once and for all, and remove the comment;
> 
> "Once and for all" has a much stronger sense of finality than you're
> using here: reading smp_processor_id() in that function "once and for
> all" would mean you would never have to read it on that function, on
> that particular core, ever again, until the end of the universe. :-)
> 
> I think I'd say, "only once".  The scope of the "only" in that case is
> "this function call", not "all calls forever".
> 
> With that changed:
> 
> Reviewed-by: George Dunlap 
> 
> (Although we till need Jan's acquiescence.)

I've voiced my opinion, but I don't mean to block the patch. After
all there's no active issue the change introduces.

Jan


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

Re: [Xen-devel] [PATCH 02/15] xen: tracing: avoid checking tb_init_done multiple times.

[George Dunlap]

On 01/06/17 18:33, Dario Faggioli wrote:
> In fact, when calling __trace_var() directly, we can
> assume that tb_init_done has been checked to be true,
> and the if is hence redundant.

You probably want to adjust the comment before the smp_rmb() that
mentions tb_init_done as well.

Other than that, looks good.

 -George


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

Re: [Xen-devel] [PATCH 02/15] xen: tracing: avoid checking tb_init_done multiple times.

[George Dunlap]

On 07/06/17 17:06, Jan Beulich wrote:
 On 07.06.17 at 17:55,  wrote:
>> On Wed, 2017-06-07 at 08:46 -0600, Jan Beulich wrote:
>> On 01.06.17 at 19:33,  wrote:

 In fact, when calling __trace_var() directly, we can
 assume that tb_init_done has been checked to be true,
 and the if is hence redundant.
>>>
>>> The "assume" here worries me: What if there's a single place
>>> somewhere that a grep can't easily find where no check is
>>> present? Is it certain that ...
>>>
 @@ -691,7 +691,8 @@ void __trace_var(u32 event, bool_t cycles,
 unsigned int extra,
  unsigned int extra_word;
  bool_t started_below_highwater;
  
 -if( !tb_init_done )
 +/* If the event is not interesting, bail, as early as possible
 */
 +if ( (tb_event_mask & event) == 0 )
  return;
>>>
>>> ... this check would always be false then (i.e. tb_event_mask is
>>> always zero) in that case?
>>>
>> As said when replying to Andrew, I originally put an ASSERT() there.
>>
>> That made me realize, though, that the existing if(!tb_init_done) is
>> ineffective and potentially racy (or, if you want to be kind "it's a
>> best effort kind of measure") already.
>>
>> In fact, even right now, without my patches, we don't hold the tracing
>> lock when we execute that if. Nothing prevents tb_init_done to become 0
>> _right_after_ we saw it being 1 and decide to go ahead.
>>
>> This, to me, looks like an even more compelling reason to remove it.
>> But I think I can improve the commit message so that it explains this
>> thing that I just said above too.
> 
> Well, my question wasn't about a possible race (as the code would
> need to be able to deal with that no matter what change you do
> here), but about the case where tb_init_done has never been set.
> Would tb_event_mask be reliably zero in that case, no matter
> what other operations may have been performed?

Looks like tb_event_mask can be set even if opt_tbuf_size == 0; so yes,
if someone enabled the event mask before allocating any buffers, *and*
there was a bug where __trace_var() was called without first checking
tb_init_done, then we might get past this point.

But it looks like that's still OK -- we'll then bail when our bit in
tb_cpu_mask isn't set, or finally bail when we find t_bufs to be zero.

 -George



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

Re: [Xen-devel] [PATCH for-next v3 06/22] x86/traps: move PV hypercall handlers to pv/traps.c

[Wei Liu]

On Thu, Jun 08, 2017 at 12:30:02PM +0100, Andrew Cooper wrote:
> I'd prefer not to have individual files for individual functions; that
> is going too far IMO.  I'd also prefer not to mix misc hypercalls into
> this file.
> 
> pv/misc-hypercalls.c ?
> 

Sure this is fine by me.

I will move the *_debugreg and fpu_switch hypercall handlers there.

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

Re: [Xen-devel] [PATCH 01/15] xen: in do_softirq() sample smp_processor_id() once and for all.

[George Dunlap]

On 01/06/17 18:33, Dario Faggioli wrote:
> In fact, right now, we read it at every iteration of the loop.
> The reason it's done like this is how context switch was handled
> on IA64 (see commit ae9bfcdc, "[XEN] Various softirq cleanups" [1]).
> 
> However:
> 1) we don't have IA64 any longer, and all the achitectures that
>we do support, are ok with sampling once and for all;
> 2) sampling at every iteration (slightly) affect performance;
> 3) sampling at every iteration is misleading, as it makes people
>believe that it is currently possible that SCHEDULE_SOFTIRQ
>moves the execution flow on another CPU (and the comment,
>by reinforcing this belief, makes things even worse!).
> 
> Therefore, let's:
> - do the sampling once and for all, and remove the comment;

"Once and for all" has a much stronger sense of finality than you're
using here: reading smp_processor_id() in that function "once and for
all" would mean you would never have to read it on that function, on
that particular core, ever again, until the end of the universe. :-)

I think I'd say, "only once".  The scope of the "only" in that case is
"this function call", not "all calls forever".

With that changed:

Reviewed-by: George Dunlap 

(Although we till need Jan's acquiescence.)

> - leave an ASSERT() around, so that, if context switching
>   logic changes (in current or new arches), we will notice.
> 
> [1] Some more (historical) information here:
> 
> http://old-list-archives.xenproject.org/archives/html/xen-devel/2006-06/msg01262.html
> 
> Signed-off-by: Dario Faggioli 


> ---
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: Tim Deegan 
> ---
>  xen/common/softirq.c |8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/common/softirq.c b/xen/common/softirq.c
> index ac12cf8..67c84ba 100644
> --- a/xen/common/softirq.c
> +++ b/xen/common/softirq.c
> @@ -27,16 +27,12 @@ static DEFINE_PER_CPU(unsigned int, batching);
>  
>  static void __do_softirq(unsigned long ignore_mask)
>  {
> -unsigned int i, cpu;
> +unsigned int i, cpu = smp_processor_id();
>  unsigned long pending;
>  
>  for ( ; ; )
>  {
> -/*
> - * Initialise @cpu on every iteration: SCHEDULE_SOFTIRQ may move
> - * us to another processor.
> - */
> -cpu = smp_processor_id();
> +ASSERT(cpu == smp_processor_id());
>  
>  if ( rcu_pending(cpu) )
>  rcu_check_callbacks(cpu);
> 


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