[Xen-devel] Xen 4.11 Development Update

[Juergen Gross]

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

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

= Timeline =

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

* Last posting date: March 16th, 2018
* Hard code freeze: March 30th, 2018
* RC1: TBD
* Release: June 1st, 2018

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

RCs will be arranged immediately after freeze.

We recently introduced a jira instance to track all the tasks (not only big)
for the project. See: https://xenproject.atlassian.net/projects/XEN/issues.

Most of the tasks tracked by this e-mail also have a corresponding jira task
referred by XEN-N.

I have started to include the version number of series associated to each
feature. Can each owner send an update on the version number if the series
was posted upstream?

= Projects =

== Hypervisor == 

*  Per-cpu tasklet
  -  XEN-28
  -  Konrad Rzeszutek Wilk

=== x86 === 

*  Enable Memory Bandwidth Allocation in Xen (v10)
  -  XEN-48
  -  Yi Sun

*  guest resource mapping (v17)
  -  Paul Durrant

*  vNVDIMM support for HVM guest (RFC v4)
  -  XEN-45
  -  Haozhong Zhang

*  Comet: Run PV in PVH container (v2)
  -  Wei Liu

*  per-CPU/L4-shadowing (fairly-RFC)
  -  Andrew Cooper

*  hypervisor x86 instruction emulator additions
  -  Jan Beulich

*  PV-IOMMU
  -  Paul Durrant

*  HVM guest CPU topology support (RFC)
  -  Chao Gao

*  Mitigations for SP2/CVE-2017-5715/Branch Target Injection (v7)
  -  Andrew Cooper

*  Vixen: A PV-in-HVM shim (v3)
  -  Anthony Liguori

*  Add dmops to allow use of VGA with restricted QEMU (v3)
  -  Ross Lagerwall

*  Intel Processor Trace virtulization enabling (v1)
  -  Luwei Kang

=== ARM === 

*  SMMUv3 driver (RFC v4)
  -  Sameer Goel

*  IORT support (RFC)
  -  Manish Jaggi

*  Implement branch predictor hardening for affected Cortex-A CPUs (v1)
  -  Julien Grall

== Grub2 == 

*  Support PVH guest boot (v1)
  -  Juergen Gross


Juergen Gross

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118394
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118394
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 118394
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  f2e16994f7d660a54daba1059441dc0dcf4d9cbd
baseline version:
 libvirt  614be3b8827604c730856d8c90f0854f76df9fcc

Last test of basis   118394  2018-01-27 18:32:49 Z3 days
Testing same since   118447  2018-01-30 04:20:27 Z1 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Erik Skultety 
  John Ferlan 
  Julio Faracco 
  Kashyap Chamarthy 
  Martin Kletzander 
  Michal Privoznik 

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

[Xen-devel] [xen-4.8-testing test] 118446: FAIL

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-win7-amd64   broken in 118369
 test-amd64-i386-livepatchbroken  in 118369

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 4 host-install(4) broken in 118369 pass in 
118446
 test-amd64-i386-livepatch4 host-install(4) broken in 118369 pass in 118446
 test-xtf-amd64-amd64-3 49 xtf/test-hvm64-lbr-tsx-vmentry fail in 118369 pass 
in 118446
 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail in 118369 
pass in 118446
 test-armhf-armhf-libvirt-raw 10 debian-di-install fail in 118369 pass in 118446
 test-amd64-amd64-xl-qemuu-ovmf-amd64 16 guest-localmigrate/x10 fail in 118431 
pass in 118446
 test-xtf-amd64-amd64-4   49 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 118369
 test-xtf-amd64-amd64-5   49 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 118431

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-2 49 xtf/test-hvm64-lbr-tsx-vmentry fail in 118431 like 
118170
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 118431 like 
118170
 test-xtf-amd64-amd64-1  49 xtf/test-hvm64-lbr-tsx-vmentry fail like 118170
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118170
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118170
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118170
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118170
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 118170
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118170
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 118170
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118170
 build-amd64-prev  7 xen-build/dist-test  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 build-i386-prev   7 xen-build/dist-test  fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 

Re: [Xen-devel] GPU passthrough on ARM

[Martin Kelly]

On 01/30/2018 11:53 AM, Oleksandr Tyshchenko wrote:


I'm wondering what the GPU would like to the guest. Would it be the same
interface as on a native machine, or would I need PV drivers?


It depends on what guest domain contains.

If DomU has both Display Unit and GPU assigned then PV driver is not needed.
So, here we have the same interface as on a native machine.

But if DomU has only GPU assigned then something like PV display
frontend is needed here,
plus PV display backend running in a guest domain which owns Display Unit.

The possible hint is that if Display Unit has independent crtcs,
connectors, etc it might be possible to split it
into the separate units and assign them to different guest domains (of
course, the HW must be splittable).
I think, this would avoid PV driver usage.



That makes sense. Thanks again for your help understanding this better.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail REGR. vs. 118324
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start   fail REGR. vs. 118324

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail REGR. vs. 118324

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

version targeted for testing:
 linux0a4b6e2f80aad46fb55a5cf7b1664c0aef030ee0
baseline version:
 linux5b7d27967dabfb17c21b0d98b29153b9e3ee71e5

Last test of basis   118324  2018-01-25 07:31:24 Z5 days
Failing since118362  2018-01-26 16:56:17 Z4 days4 attempts
Testing same since   118445  2018-01-29 21:35:17 Z1 days1 attempts

[Xen-devel] kernel-ml-4.15.0-1.el7.elrepo.x86_64 doesn't boot as Xen PV domU

[Adi Pircalabu]

Initially submitted here: http://elrepo.org/bugs/view.php?id=820

No issues with the latest 4.14.1x versions. The crash replicates on 3 
hypervisors:
- CentOS 7.4 running kernel 4.9.77-30.el7.x86_64 and 
xen-4.6.6-9.el7.x86_64 on Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz
- CentOS 7.4 running kernel 4.9.77-30.el7.x86_64 and 
xen-4.6.6-9.el7.x86_64 on AMD Phenom(tm) II X6 1090T Processor
- CentOS 6.9 running kernel 4.9.75-30.el6.x86_64 and 
xen-4.6.6-8.el6.x86_64 on Intel(R) Xeon(R) CPU E5420  @ 2.50GHz


xl dmesg on CentOS 7.4
[...]
(d6) HVM Loader
(d6) Detected Xen v4.6.6-9.el7
(d6) Xenbus rings @0xfeffc000, event channel 1
(d6) System requested SeaBIOS
(d6) CPU speed is 3607 MHz
(d6) Relocating guest memory for lowmem MMIO space disabled
(d6) PCI-ISA link 0 routed to IRQ5
(d6) PCI-ISA link 1 routed to IRQ10
(d6) PCI-ISA link 2 routed to IRQ11
(d6) PCI-ISA link 3 routed to IRQ5
(d6) pci dev 01:2 INTD->IRQ5
(d6) pci dev 01:3 INTA->IRQ10
(d6) pci dev 02:0 INTA->IRQ11
(d6) pci dev 04:0 INTA->IRQ5
(d6) No RAM in high memory; setting high_mem resource base to 1
(d6) pci dev 03:0 bar 10 size 00200: 0f008
(d6) pci dev 02:0 bar 14 size 00100: 0f208
(d6) pci dev 04:0 bar 30 size 4: 0f300
(d6) pci dev 03:0 bar 30 size 1: 0f304
(d6) pci dev 03:0 bar 14 size 01000: 0f305
(d6) pci dev 02:0 bar 10 size 00100: 0c001
(d6) pci dev 04:0 bar 10 size 00100: 0c101
(d6) pci dev 04:0 bar 14 size 00100: 0f3051000
(d6) pci dev 01:2 bar 20 size 00020: 0c201
(d6) pci dev 01:1 bar 20 size 00010: 0c221
(d6) Multiprocessor initialisation:
(d6) - CPU0 ... 39-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... 
done.
(d6) - CPU1 ... 39-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... 
done.

(d6) Writing SMBIOS tables ...
(d6) Loading SeaBIOS ...
(d6) Creating MP tables ...
(d6) Loading ACPI ...
(d6) vm86 TSS at fc00a180
(d6) BIOS map:
(d6) 1-100e3: Scratch space
(d6) c-f: Main BIOS
(d6) E820 table:
(d6) [00]: : - :000a: RAM
(d6) HOLE: :000a - :000c
(d6) [01]: :000c - :0010: RESERVED
(d6) [02]: :0010 - :bf80: RAM
(d6) HOLE: :bf80 - :fc00
(d6) [03]: :fc00 - 0001:: RESERVED
(d6) Invoking SeaBIOS ...
(d6) SeaBIOS (version ?-20150729_130325-)
(d6)
(d6) Found Xen hypervisor signature at 4000
(d6) Running on QEMU (i440fx)
(d6) xen: copy e820...
(d6) Relocating init from 0x000de920 to 0xbf7aec10 (size 70448)
(d6) CPU Mhz=3608
(d6) Found 8 PCI devices (max PCI bus is 00)
(d6) Allocated Xen hypercall page at bf7ff000
(d6) Detected Xen v4.6.6-9.el7
(d6) xen: copy BIOS tables...
(d6) Copying SMBIOS entry point from 0x00010020 to 0x000f6600
(d6) Copying MPTABLE from 0xfc001160/fc001170 to 0x000f6500
(d6) Copying PIR from 0x00010040 to 0x000f6480
(d6) Copying ACPI RSDP from 0x000100c0 to 0x000f6450
(d6) Using pmtimer, ioport 0xb008
(d6) Scan for VGA option rom
(d6) Running option rom at c000:0003
(d6) pmm call arg1=0
(d6) Turning on vga text mode console
(d6) SeaBIOS (version ?-20150729_130325-)
(d6) Machine UUID 8ebc5a48-2f57-4408-9fcb-344604913e27
(d6) UHCI init on dev 00:01.2 (io=c200)
(d6) Found 0 lpt ports
(d6) Found 1 serial ports
(d6) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
(d6) ATA controller 2 at 170/374/0 (irq 15 dev 9)
(d6) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (40960 MiBytes)
(d6) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
(d6) DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD]
(d6) Searching bootorder for: /pci@i0cf8/*@1,1/drive@1/disk@0
(d6) PS2 keyboard initialized
(d6) All threads complete.
(d6) Scan for option roms
(d6) Running option rom at c980:0003
(d6) pmm call arg1=1
(d6) pmm call arg1=0
(d6) pmm call arg1=1
(d6) pmm call arg1=0
(d6) Searching bootorder for: /pci@i0cf8/*@4
(d6)
(d6) Press F12 for boot menu.
(d6)
(d6) Searching bootorder for: HALT
(d6) drive 0x000f6400: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 
s=83886080

(d6) Space available for UMB: ca800-ee800, f5e20-f63a0
(d6) Returned 258048 bytes of ZoneHigh
(d6) e820 map has 6 items:
(d6) 0:  - 0009fc00 = 1 RAM
(d6) 1: 0009fc00 - 000a = 2 RESERVED
(d6) 2: 000f - 0010 = 2 RESERVED
(d6) 3: 0010 - bf7ff000 = 1 RAM
(d6) 4: bf7ff000 - bf80 = 2 RESERVED
(d6) 5: fc00 - 0001 = 2 RESERVED
(d6) enter handle_19:
(d6) NULL
(d6) Booting from Hard Disk...
(d6) Booting from :7c00
(d7) HVM Loader
(d7) Detected Xen v4.6.6-9.el7
(d7) Xenbus rings @0xfeffc000, event channel 1
(d7) System requested SeaBIOS
(d7) CPU speed is 3607 MHz
(d7) Relocating guest memory for lowmem MMIO space disabled
(d7) PCI-ISA link 0 routed to IRQ5
(d7) PCI-ISA link 1 routed to IRQ10
(d7) PCI-ISA link 2 routed to IRQ11
(d7) PCI-ISA link 3 routed to IRQ5
(d7) pci dev 01:2 INTD->IRQ5
(d7) pci dev 01:3 INTA->IRQ10

[Xen-devel] ThunderX support in Xen

[Stefano Stabellini]

Hi Manish,

I am testing Xen support in ThunderX, but I am having some issues
booting Dom0 using Xen staging and the Ubuntu Xenial kernel (it has
CONFIG_XEN enabled). The trace is appened to this email. I am using the
device tree converted from /proc/device-tree on the running system
without Xen.

Do I need to update Linux kernel? Do I need to use a specific DTB? If
so, could you please post the kernel config and dts? Any help would be
appreciated.

Thanks!

- Stefano


[3.273098] Unable to handle kernel NULL pointer dereference at virtual 
address 0080
[3.281254] pgd = 0946d000
[3.284721] [0080] *pgd=bfffe003, *pud=bfffd003, 
*pmd=
[3.293059] Internal error: Oops: 9604 [#1] SMP
[3.298001] Modules linked in:
[3.301127] CPU: 81 PID: 1 Comm: swapper/0 Not tainted 4.10.0-38-generic 
#42~16.04.1-Ubuntu
[3.309564] Hardware name: cavium,thunder-88xx (DT)
[3.314492] task: 80007c573a00 task.stack: 80007c578000
[3.320485] PC is at arm_smmu_device_cfg_probe+0x300/0x770
[3.326039] LR is at arm_smmu_device_cfg_probe+0x25c/0x770
[3.331590] pc : [] lr : [] pstate: 
80400045
[3.339053] sp : 80007c57b9d0
[3.342439] x29: 80007c57b9d0 x28:  
[3.347820] x27:  x26: 09444000 
[3.353201] x25: 0001 x24:  
[3.358582] x23: 0936f000 x22:  
[3.363963] x21: 8000791e2010 x20: 5800f555 
[3.369344] x19: 8000791e1818 x18: 09228b10 
[3.374726] x17: 145befc4 x16: deadbeef 
[3.380107] x15: 89381857 x14: 29796c6e6f20322d 
[3.385488] x13: 6567617473203028 x12: 20736b6e61622074 
[3.390869] x11: 7865746e6f632038 x10: 323109203a30756d 
[3.396251] x9 : 6d732e3030303030 x8 : 0865d450 
[3.401632] x7 : 08eda000 x6 : 01f9 
[3.407013] x5 : 093838c8 x4 :  
[3.412394] x3 : 09444ee8 x2 :  
[3.417775] x1 : 0002 x0 :  
[3.423156] 
[3.424719] Process swapper/0 (pid: 1, stack limit = 0x80007c578000)
[3.431490] Stack: (0x80007c57b9d0 to 0x80007c57c000)
[3.437306] b9c0:   80007c57ba20 
0869a230
[3.445204] b9e0: 8000791e1818 0081 0081 
8000791e2000
[3.453102] ba00: 8000791e2010 09228000 092d5000 
8000791e2000
[3.461001] ba20: 80007c57ba80 086acea8 092d5730 
8000791e2010
[3.468919] ba40: 092d5708   

[3.476797] ba60: 092d5000 09444000 8300 
00040a11
[3.484695] ba80: 80007c57bab0 086aa6fc 8000791e2010 
09444000
[3.492593] baa0: 092d5730 09444000 80007c57baf0 
086aaa6c
[3.500511] bac0: 0001 092d5730 8000791e2010 
80007c57bbc8
[3.508390] bae0:  8000791e22e0 80007c57bb20 
086a8068
[3.516288] bb00:  80007c57bbc8 086aa9b8 
09228000
[3.524186] bb20: 80007c57bb80 086aa258 8000791e2010 
09228000
[3.532104] bb40: 8000791e2070  0001 
086aa240
[3.539986] bb60: 8000791e2010 80007abffac8 80007917ad68 
00040a11
[3.547881] bb80: 80007c57bbe0 086aab94 8000791e2010 
8000791e2010
[3.555779] bba0: 092d64c0  09228000 
8000791e2010
[3.563697] bbc0: 092d61c0 8000791e2010 0001 
00040a11
[3.571576] bbe0: 80007c57bc00 086a9490 8000791e2020 

[3.579474] bc00: 80007c57bc30 086a699c 8000791e2020 
8000791e2010
[3.587372] bc20: 092d61c0 086a6994 80007c57bcb0 
0889ac48
[3.595290] bc40: 8000791e2000 8000791e2010  
80007ffd7e50
[3.603169] bc60:  08e69a78 08e004b8 
08dea7f0
[3.611067] bc80: 08e69a48 08ed8200  
8000791e2010
[3.618965] bca0:  00040a11 80007c57bcd0 
0889b6b4
[3.626883] bcc0: 8000791e2000 8000791e2010 80007c57bd10 
0889b748
[3.634761] bce0: 80007ffd7db8   
08d1d140
[3.642660] bd00: 09362000 08e4e200 80007c57bd40 
08e4e270
[3.650558] bd20: 80007ffd7db8 08ed4e00 80007ffd7db8 
08d1d140
[3.658476] bd40: 80007c57bd60 08e4e17c 09228000 
092fa000
[3.666354] bd60: 80007c57bda0 08083b5c 09228000 
80007c573a00
[3.674253] bd80: 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  16a31ca735165e63d67e86f60996f2b6a31cc0ee
baseline version:
 xen  6fd572826c26f777b72e3b5f64a137dbcfdd6361

Last test of basis   118459  2018-01-30 18:11:53 Z0 days
Testing same since   118460  2018-01-30 20:01:40 Z0 days1 attempts


People who touched revisions under test:
  Andre Przywara 
  Stefano Stabellini 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   6fd572826c..16a31ca735  16a31ca735165e63d67e86f60996f2b6a31cc0ee -> smoke

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

Re: [Xen-devel] [PATCH 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c

[Julien Grall]

On 30 January 2018 at 19:35, Volodymyr Babchuk
 wrote:
>
>
> On 30.01.18 20:44, Julien Grall wrote:
>>
>>
>>
>> On 30/01/18 18:28, Volodymyr Babchuk wrote:
>>>
>>> Hi Julien,
>>>
>>> On 30.01.18 20:01, Julien Grall wrote:



 On 26/01/18 18:27, Volodymyr Babchuk wrote:
>
> Hi,


 Hi Volodymyr,

> On 26.01.18 20:15, Julien Grall wrote:
>>
>> Hi,
>>
>> On 26/01/18 18:09, Volodymyr Babchuk wrote:
>>>
>>> On 24.01.18 20:34, Julien Grall wrote:

 -case PSCI_0_2_FN32(AFFINITY_INFO):
 -case PSCI_0_2_FN64(AFFINITY_INFO):
 +switch ( fid )
   {
 -register_t taff = PSCI_ARG(regs, 1);
 -uint32_t laff = PSCI_ARG32(regs, 2);
 -
 -perfc_incr(vpsci_cpu_affinity_info);
 -PSCI_SET_RESULT(regs, do_psci_0_2_affinity_info(taff,
 laff));
 -return true;
 -}
 -
   case ARM_SMCCC_FUNC_CALL_COUNT(STANDARD):
   return fill_function_call_count(regs,
 SSSC_SMCCC_FUNCTION_COUNT);
>>>
>>> Now definition SSSC_SMCCC_FUNCTION_COUNT depends on code in vscpi.c.
>>> Maybe it is time to introduce function get_psci_0_2_fn_count() and
>>> use it there, what do you think?
>>
>>
>> Definitely not a function. It is a static number. But I can think of
>> separate the call count.
>
> Yep, separate call count for vPSCI and for SSSC itself would be a good
> thing.


 Looking a bit more into it, this will not make a real improvement. This
 will be equally difficult to remember to update the call count.
>>>
>>> Nevertheless, I think that it is right thing to hold call count in the
>>> same file, where calls are implemented. This increases chances that call
>>> count will be held in sync.
>>
>>
>> So you are suggesting to implement a function? If so, that's a no-go from
>> my side.
>
> I'm not insist on function if you can propose alternative.
> But why you are against getter function in the first place?

Because a function returning a const value is pretty dumb.

>
> I wanted to propose another approach: define this call count in
> vpsci.h, but there is no vpsci.h, instead you use psci.h, which is confusing
> in itself.

I thought about vpsci.h, but basically you will have only 2 functions in it and
the number of PSCI calls. That's it.

So it is not going to help to update because the header will unlikely need to
change when adding new PSCI call.

[...]

>>
>> I looked at some implementation of SMCCC and those calls are either not
>> handled or the number are not correct.
>
> I agree that *some* implementations can not conform to SMCCC.But, I thought
> you want Xen to follow standards as close as possible...

It is not about cannot conform but only implements partially SMCCC. I could name
ATF for that (yes).

So it makes me more confident the call count is not something people seem to
care.

Cheers,

-- 
Julien Grall

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

Re: [Xen-devel] GPU passthrough on ARM

[Oleksandr Tyshchenko]

Hi

On Tue, Jan 30, 2018 at 2:22 AM, Martin Kelly  wrote:
> On 01/29/2018 08:31 AM, Oleksandr Tyshchenko wrote:
>>
>> Hi
>>
>> On Sat, Jan 27, 2018 at 2:41 AM, Martin Kelly  wrote:
>>>
>>> On 01/26/2018 10:13 AM, Oleksandr Tyshchenko wrote:


 Hi, Martin

 On Fri, Jan 26, 2018 at 8:05 PM, Oleksandr Tyshchenko
  wrote:
>
>
> On Fri, Jan 26, 2018 at 3:49 PM, Julien Grall 
> wrote:
>>
>>
>> Hi,
>>
>> I am CCing Oleksandr. He knows better than me this platform.
>
>
>
> Hi, Julien.
>
> OK, thank you, I will try to provide some pointers.
>
>>
>> Cheers,
>>
>> On 26/01/18 00:29, Martin Kelly wrote:
>>>
>>>
>>>
>>> On 01/25/2018 04:17 AM, Julien Grall wrote:





 On 24/01/18 22:10, Martin Kelly wrote:
>
>
>
> Hi,




 Hello,

> Does anyone know if GPU passthrough is supported on ARM? (e.g. for
> a
> GPU
> integrated into an ARM SoC). I checked documentation and the code,
> but I
> couldn't tell for sure.
>
> If so, what are the hardware requirements for it? If not, is it
> feasible
> to do in the future?




 Xen Arm supports device integrated into an ARM SoC. In general we
 highly
 recommend to have the GPU behind an IOMMU. So passthrough would be
 fully
 secure.

 Does your platform has an IOMMU? If so which one? Do you know if the
 GPU
 is behind it?

 It would be possible to do passthrough without IOMMU, but that's
 more
 complex and would require some hack in Xen to make sure the guest
 memory is
 direct mapped (e.g guest physical address = host physical address).

 For more documentation on how to do it (see [1] and [2]).

 Cheers,

 [1]


 https://events.static.linuxfound.org/sites/events/files/slides/talk_5.pdf
 [2] https://wiki.xen.org/images/1/17/Device_passthrough_xen.pdf

>>>
>>> Hi Julien,
>>>
>>> Thanks very much for the information. I'm looking at the Renesas
>>> R-Car
>>> H3
>>> R8A7795, which has an IOMMU (using the Linux ipmmu-vmsa driver in
>>> drivers/iommu/ipmmu-vmsa.c). Looking at the device tree for it
>>> (r8a7795.dtsi), it appears you could pass through the
>>> display@feb0
>>> node
>>> for the DRM driver.
>>>
>>> I did notice this patch series, which didn't get merged:
>>>
>>>
>>>
>>> https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg02679.html
>>>
>>> Presumably that driver would be needed in Xen.
>>>
>>> Are there any gotchas I'm missing? Is GPU passthrough on ARM
>>> something
>>> that is "theoretically doable" or something that has been done
>>> already
>>> and
>>> shown to be performant?



 I assume the H3 SoC version you are using is ES2.0, because of
 r8a7795.dtsi.

 BTW, what BSP version are you using? I am wondering what is your
 use-case?
 If you want to keep GPU in some dedicated domain without no hardware
 at all, you have to use something like PV DRM frontend running here
 and PV DRM backend in the hardware/driver domain.
 The things are going to be much simple if you pass through all
 required display sub-components as well, for the "rcar-du" DRM to be
 functional.
 Which way are you looking for?
>>>
>>>
>>>
>>> My BSP and kernel version is flexible, and I'd be happy to use whatever
>>> works best. The use-case is using OpenCL inside a VM for high-performance
>>> GPGPU.
>>
>> Sounds indeed interesting.
>>
>>> This means that performance is critical, and I would go with whatever
>>> solution offers the best performance.
>>
>> Oh, I see.
>>
>>>
>>>

 Anyway, in both cases you have to pass through GPU. For that some
 activities should be done:

 1. Xen side:

 As for the patch series, you are right, you have to base on it. There
 are two separate patch series which haven't upstreamed yet,
 but needed for the passthrough feature to work on R-Car Gen3 SoCs (M3,
 H3).

 https://www.mail-archive.com/xen-devel@lists.xen.org/msg115901.html
 https://www.mail-archive.com/xen-devel@lists.xen.org/msg116038.html

 Also additional patch is needed to teach IPMMU-VMSA driver to handle
 devices which are hooked up to multiple IPMMU caches.
 Since the GPU on H3 SoC is connected to multiple IPMMU caches: PV0 -
 PV3.

 I have created new branch you can simply base on to get required
 support 

Re: [Xen-devel] [PATCH 4/5] x86/alternative: Implement NMI/#MC-safe patching

[Andrew Cooper]

On 30/01/18 08:39, Jan Beulich wrote:
 On 29.01.18 at 16:38,  wrote:
>> +bool init_or_livepatch text_poke_live(const struct cpu_user_regs *regs)
>> +{
>> +struct live_poke_info *i = _poke_info;
>> +
>> +if ( unlikely(i->cpu != smp_processor_id()) )
>> +{
>> +ASSERT(regs);
>> +
>> +/*
>> + * We hit a breakpoint, on a CPU which was not performing the
>> + * patching.  This is only expected to be possible for the NMI/#MC
>> + * paths, and even then, only if we hit the tiny race window below
>> + * while patching in the NMI/#MC handlers.
>> + *
>> + * We can't safely evaluate whether we hit a transient breakpoint
>> + * because i->cpu has likely completed the patch and moved on to the
>> + * next patch site.
>> + *
>> + * Go to sleep for a bit and synchronise the pipeline as we are now 
>> in
>> + * a cross-modifying scenario.
>> + */
>> +cpu_relax();
>> +cpuid_eax(0);
>> +
>> +/*
>> + * Presume that we hit the transient breakpoint, as we can't confirm
>> + * whether we did or not.  We don't expect there to be any other
>> + * breakpoints to hit, but if we did hit another one, then in the
>> + * worse case we will only livelock until i->cpu has finished all of
>> + * its patching.
>> + */
>> +return true;
>> +}
>> +
>> +/*
>> + * We are the CPU performing the patching, and might have ended up here 
>> by
>> + * hitting a breakpoint.
>> + *
>> + * Either way, we need to complete particular patch to make forwards
>> + * progress.  This logic is safe even if executed recursively in the
>> + * breakpoint handler; the worst that will happen when normal execution
>> + * resumes is that we will rewrite the same bytes a second time.
>> + */
>> +
>> +/* First, insert a breakpoint to prevent execution of the patch site. */
>> +i->addr[0] = 0xcc;
>> +smp_wmb();
> This is necessary, but not sufficient when replacing more than a
> single insn: The other CPU may be executing instructions _after_
> the initial one that is being replaced, and ...
>
>> +/* Second, copy the remaining instructions into place. */
>> +memcpy(i->addr + 1, i->opcode + 1, i->len - 1);
> ... this may be altering things underneath its feet.

Hmm.

It is completely impossible to recover if another CPU hits the middle of
this memcpy().  It is impossible to synchronise a specific write against
the remote CPU pipelines.

The only way to be safe is to guarantee that CPUs can't hit the code to
begin with.

On AMD, we can use STGI/CLGI to do this sensibly, and really really
inhibit all interrupts.  For Intel, we can fix the NMI problem by
rendezvousing and running the patching loop in NMI context, at which
point the hardware latch will prevent further NMIs.

However, there is literally nothing we can do to prevent #MC from
arriving.  We can stop servicing #MC by disabling CR4.MCE, but then the
processor will shut down.

We can't put a big barrier at the head of #MC handler which delays
processing, because we have no way to ensure that processors aren't
already later in the #MC handler.  Furthermore, attempting to do so
heightens the risk of hitting a shutdown condition from a second queued #MC.


The chance of hitting an NMI/#MC collide with patching is already
minuscule.  Alternatives and livepatching have been used (by XenServer
alone) in this form for nearly 3 years, across millions of servers,
without a single report of such a collision.  The chance of an #MC
collision is far less likely than an NMI collision, and in the best case.

While we can arrange and test full NMI safety, we cannot test #MC safety
at all.  Any code to try and implement #MC safety is going to be
complicated, and make things worse if an #MC does hit.

Therefore, I agree with the Linux view that trying to do anything for
#MC safety is going to be worse than doing nothing at all.

>> @@ -153,7 +231,31 @@ void init_or_livepatch add_nops(void *insns, unsigned 
>> int len)
>>  void init_or_livepatch noinline
>>  text_poke(void *addr, const void *opcode, size_t len, bool live)
>>  {
>> -memcpy(addr, opcode, len);
>> +if ( !live || len == 1 )
>> +{
>> +/*
>> + * If we know *addr can't be executed, or we are patching a single
>> + * byte, it is safe to use a straight memcpy().
>> + */
>> +memcpy(addr, opcode, len);
> Is it really worth special casing this? Whether to actually ack
> patches 2 and 3 depends on that.

Yes, and even more so if we are going to use an NMI rendezvous.  We
definitely don't want to have an NMI rendezvous while applying
alternatives as part of livepatch preparation.

>
>> +};
>> +smp_wmb();
>> +active_text_patching = true;
>> +smp_wmb();
>> +text_poke_live(NULL);
>> +smp_wmb();

Re: [Xen-devel] [PATCH 0/3] xen/arm: Inject an exception to the guest rather than crashing it

[Andrew Cooper]

On 30/01/18 19:21, Stefano Stabellini wrote:
> On Tue, 30 Jan 2018, Julien Grall wrote:
>> Hi,
>>
>> On 30/01/18 18:29, Andrew Cooper wrote:
>>> On 30/01/18 17:00, Julien Grall wrote:

 On 30/01/18 16:38, Andrew Cooper wrote:
> On 30/01/18 16:14, Julien Grall wrote:
>> Hi all,
>>
>> This small series replaces all call to domain_crash_synchronous by
>> injecting
>> an exception to the guest.
>>
>> This will result to a nicer trace from the guest (no need to
>> manually walk
>> the stack) and give a chance to the guest to give a bit more
>> information on
>> what it was doing.
>>
>> Cheers,
>>
>> Julien Grall (3):
>>     xen/arm: io: Distinguish unhandled IO from aborted one
>>     xen/arm: Don't crash domain on bad MMIO emulation
>>     xen/arm: Don't crash the domain on invalid HVC immediate
> Thanks.
>
> I don't feel qualified to review these, but some notes.
>
> Patch 1.  s/avodi/avoid/ in the commit message
>
> Patches 2 and 3.  You probably want to convert the printks to
> gdprintk()s, otherwise guests can choke up the ratelimited log.  Doing
> so will also mean that the vcpu will be identified consistently, which
> it isn't currently.
 We didn't use g*printk because it would be more confusing to print the
 current vCPU in some cases (e.g when accessing the re-distributor of
 another vCPU) or does not matter (e.g for ITS).
>>> In the former case, you'd want to print both current, and the target
>>> vcpu.  The latter still matters what current is if something goes wrong.
>>>
>>> We have plenty of similar cases in x86, but at the point you are
>>> printing an diagnostic message, ignoring current is almost always the
>>> wrong think to do.
>> I will look at it on another series.
>>
 The problem with the debug version is those information are actually
 quite useful in non-debug build. We found quite a few issues thanks to
 them.

 I think it would make more sense for Xen to provide per-guest
 ratelimited than hiding those messages in non-debug build.
>>> Per guest is quite a lot more complicated than global, and would still
>>> require a global limit to prevent a concerted attack from multiple
>>> guests to avoid DoSing the system.
>>>
>>> Debug vs unilateral is your prerogative as a maintainer, but as you've
>>> said yourself, the are used for debugging purposes, which proves my point.
>> So on x86, you always request the user to reproduce it with debug build
>> enable?
>>
>> Stefano, what's your opinion here?
> I think it would be great to have per-guest rate limiting.
>
> On ARM, it would be impossible to ask users to repro with debug enabled,
> given that many deployments are embedded (set-top boxes, etc).
>
> I think it is OK to keep the XENLOG_DEBUG, they should be filtered out
> by loglvl. But we need to be careful about the others. We might want to
> convert the XENLOG_WARNING in traps.c to XENLOG_DEBUG: they are warning
> about guests misbehaving, but from the hypervisor point of view, it's not
> a problem, guests can shoot themselves if they want to; it's OK.

This is a valid argument, but to do it consistently, you'll want to
provide an arch-specific version of gdprintk() so that the common code
printk()s don't evaporate into /dev/null.

~Andrew

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

Re: [Xen-devel] [PATCH 0/3] xen/arm: Inject an exception to the guest rather than crashing it

[Stefano Stabellini]

On Tue, 30 Jan 2018, Julien Grall wrote:
> Hi,
> 
> On 30/01/18 18:29, Andrew Cooper wrote:
> > On 30/01/18 17:00, Julien Grall wrote:
> > > 
> > > 
> > > On 30/01/18 16:38, Andrew Cooper wrote:
> > > > On 30/01/18 16:14, Julien Grall wrote:
> > > > > Hi all,
> > > > > 
> > > > > This small series replaces all call to domain_crash_synchronous by
> > > > > injecting
> > > > > an exception to the guest.
> > > > > 
> > > > > This will result to a nicer trace from the guest (no need to
> > > > > manually walk
> > > > > the stack) and give a chance to the guest to give a bit more
> > > > > information on
> > > > > what it was doing.
> > > > > 
> > > > > Cheers,
> > > > > 
> > > > > Julien Grall (3):
> > > > >     xen/arm: io: Distinguish unhandled IO from aborted one
> > > > >     xen/arm: Don't crash domain on bad MMIO emulation
> > > > >     xen/arm: Don't crash the domain on invalid HVC immediate
> > > > 
> > > > Thanks.
> > > > 
> > > > I don't feel qualified to review these, but some notes.
> > > > 
> > > > Patch 1.  s/avodi/avoid/ in the commit message
> > > > 
> > > > Patches 2 and 3.  You probably want to convert the printks to
> > > > gdprintk()s, otherwise guests can choke up the ratelimited log.  Doing
> > > > so will also mean that the vcpu will be identified consistently, which
> > > > it isn't currently.
> > > We didn't use g*printk because it would be more confusing to print the
> > > current vCPU in some cases (e.g when accessing the re-distributor of
> > > another vCPU) or does not matter (e.g for ITS).
> > 
> > In the former case, you'd want to print both current, and the target
> > vcpu.  The latter still matters what current is if something goes wrong.
> > 
> > We have plenty of similar cases in x86, but at the point you are
> > printing an diagnostic message, ignoring current is almost always the
> > wrong think to do.
> 
> I will look at it on another series.
> 
> > 
> > > 
> > > The problem with the debug version is those information are actually
> > > quite useful in non-debug build. We found quite a few issues thanks to
> > > them.
> > > 
> > > I think it would make more sense for Xen to provide per-guest
> > > ratelimited than hiding those messages in non-debug build.
> > 
> > Per guest is quite a lot more complicated than global, and would still
> > require a global limit to prevent a concerted attack from multiple
> > guests to avoid DoSing the system.
> > 
> > Debug vs unilateral is your prerogative as a maintainer, but as you've
> > said yourself, the are used for debugging purposes, which proves my point.
> 
> So on x86, you always request the user to reproduce it with debug build
> enable?
> 
> Stefano, what's your opinion here?

I think it would be great to have per-guest rate limiting.

On ARM, it would be impossible to ask users to repro with debug enabled,
given that many deployments are embedded (set-top boxes, etc).

I think it is OK to keep the XENLOG_DEBUG, they should be filtered out
by loglvl. But we need to be careful about the others. We might want to
convert the XENLOG_WARNING in traps.c to XENLOG_DEBUG: they are warning
about guests misbehaving, but from the hypervisor point of view, it's not
a problem, guests can shoot themselves if they want to; it's OK.___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 0/3] xen/arm: Inject an exception to the guest rather than crashing it

[Andrew Cooper]

On 30/01/18 18:46, Julien Grall wrote:
> Hi,
>
> On 30/01/18 18:29, Andrew Cooper wrote:
>> On 30/01/18 17:00, Julien Grall wrote:
>>>
>>>
>>> On 30/01/18 16:38, Andrew Cooper wrote:
 On 30/01/18 16:14, Julien Grall wrote:
> Hi all,
>
> This small series replaces all call to domain_crash_synchronous by
> injecting
> an exception to the guest.
>
> This will result to a nicer trace from the guest (no need to
> manually walk
> the stack) and give a chance to the guest to give a bit more
> information on
> what it was doing.
>
> Cheers,
>
> Julien Grall (3):
>     xen/arm: io: Distinguish unhandled IO from aborted one
>     xen/arm: Don't crash domain on bad MMIO emulation
>     xen/arm: Don't crash the domain on invalid HVC immediate

 Thanks.

 I don't feel qualified to review these, but some notes.

 Patch 1.  s/avodi/avoid/ in the commit message

 Patches 2 and 3.  You probably want to convert the printks to
 gdprintk()s, otherwise guests can choke up the ratelimited log.  Doing
 so will also mean that the vcpu will be identified consistently, which
 it isn't currently.
>>> We didn't use g*printk because it would be more confusing to print the
>>> current vCPU in some cases (e.g when accessing the re-distributor of
>>> another vCPU) or does not matter (e.g for ITS).
>>
>> In the former case, you'd want to print both current, and the target
>> vcpu.  The latter still matters what current is if something goes wrong.
>>
>> We have plenty of similar cases in x86, but at the point you are
>> printing an diagnostic message, ignoring current is almost always the
>> wrong think to do.
>
> I will look at it on another series.

Fair enough.

>
>>
>>>
>>> The problem with the debug version is those information are actually
>>> quite useful in non-debug build. We found quite a few issues thanks to
>>> them.
>>>
>>> I think it would make more sense for Xen to provide per-guest
>>> ratelimited than hiding those messages in non-debug build.
>>
>> Per guest is quite a lot more complicated than global, and would still
>> require a global limit to prevent a concerted attack from multiple
>> guests to avoid DoSing the system.
>>
>> Debug vs unilateral is your prerogative as a maintainer, but as you've
>> said yourself, the are used for debugging purposes, which proves my
>> point.
>
> So on x86, you always request the user to reproduce it with debug
> build enable?

That is very specific to what goes wrong, but no, we generally don't
have release-build messages for "the guest screwed up and we hit it
expected way for doing so".  We do (well - are trying to, which is how I
found this domain_crash_sync issue in the first place) get consistent at
printing useful release-build messages for abnormal termination of the
guest.

In terms of making it easier to debug, XenServer always ships with a
release and debug hypervisor built from the same source so customers can
trivially switch into the debug version and collect logs if we think
that is a useful thing to do, but this is only used in a fraction of
cases in the first place.

Anything more complicated is definitely going to require an experienced
human to investigate, at which point they can do whatever they want.

~Andrew

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

Re: [Xen-devel] [PATCH 1/3] xen/arm: io: Distinguish unhandled IO from aborted one

[Stefano Stabellini]

On Tue, 30 Jan 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 30/01/18 18:14, Stefano Stabellini wrote:
> > On Tue, 30 Jan 2018, Julien Grall wrote:
> > > Currently, Xen is considering that an IO could either be handled or
> > > unhandled. When unhandled, the stage-2 abort function will try another
> > > way to resolve the abort.
> > > 
> > > However, the MMIO emulation may return unhandled when the address
> > > belongs to an emulated range but was not correct. In that case, Xen
> > > should avodi to try another way and directly inject a guest data abort.
> >   ^ avoid
> > 
> > 
> > > Introduce a tri-state return to distinguish the following state:
> > >  * IO_ABORT: The IO was handled but resulted to an abort
> >^ in an abort
> > 
> > 
> > >  * IO_HANDLED: The IO was handled
> > >  * IO_UNHANDLED: The IO was unhandled
> > > 
> > > For now, it is considered that an IO belonging to an emulated range
> > > could either be handled or inject an abort. This could be revisit in the
> > > future if overlapped region exist (or we want to try another way to
> > > resolve the abort).
> > > 
> > > Signed-off-by: Julien Grall 
> > > ---
> > >   xen/arch/arm/io.c  | 24 ++--
> > >   xen/arch/arm/traps.c   | 34 +++---
> > >   xen/include/asm-arm/mmio.h |  9 -
> > >   3 files changed, 45 insertions(+), 22 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
> > > index c748d8f5bf..a74ec21b86 100644
> > > --- a/xen/arch/arm/io.c
> > > +++ b/xen/arch/arm/io.c
> > > @@ -23,8 +23,9 @@
> > >   #include 
> > >   #include 
> > >   -static int handle_read(const struct mmio_handler *handler, struct vcpu
> > > *v,
> > > -   mmio_info_t *info)
> > > +static enum io_state handle_read(const struct mmio_handler *handler,
> > > + struct vcpu *v,
> > > + mmio_info_t *info)
> > >   {
> > >   const struct hsr_dabt dabt = info->dabt;
> > >   struct cpu_user_regs *regs = guest_cpu_user_regs();
> > > @@ -37,7 +38,7 @@ static int handle_read(const struct mmio_handler
> > > *handler, struct vcpu *v,
> > >   uint8_t size = (1 << dabt.size) * 8;
> > > if ( !handler->ops->read(v, info, , handler->priv) )
> > > -return 0;
> > > +return IO_ABORT;
> > > /*
> > >* Sign extend if required.
> > > @@ -57,17 +58,20 @@ static int handle_read(const struct mmio_handler
> > > *handler, struct vcpu *v,
> > > set_user_reg(regs, dabt.reg, r);
> > >   -return 1;
> > > +return IO_HANDLED;
> > >   }
> > >   -static int handle_write(const struct mmio_handler *handler, struct vcpu
> > > *v,
> > > -mmio_info_t *info)
> > > +static enum io_state handle_write(const struct mmio_handler *handler,
> > > +  struct vcpu *v,
> > > +  mmio_info_t *info)
> > >   {
> > >   const struct hsr_dabt dabt = info->dabt;
> > >   struct cpu_user_regs *regs = guest_cpu_user_regs();
> > > +int ret;
> > >   -return handler->ops->write(v, info, get_user_reg(regs, dabt.reg),
> > > -   handler->priv);
> > > +ret = handler->ops->write(v, info, get_user_reg(regs, dabt.reg),
> > > +  handler->priv);
> > > +return ( ret ) ? IO_HANDLED : IO_ABORT;
> > >   }
> > > /* This function assumes that mmio regions are not overlapped */
> > > @@ -100,14 +104,14 @@ static const struct mmio_handler
> > > *find_mmio_handler(struct domain *d,
> > >   return handler;
> > >   }
> > >   -int handle_mmio(mmio_info_t *info)
> > > +enum io_state handle_mmio(mmio_info_t *info)
> > >   {
> > >   struct vcpu *v = current;
> > >   const struct mmio_handler *handler = NULL;
> > > handler = find_mmio_handler(v->domain, info->gpa);
> > >   if ( !handler )
> > > -return 0;
> > > +return IO_UNHANDLED;
> > > if ( info->dabt.write )
> > >   return handle_write(handler, v, info);
> > > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > > index c8534d6cff..843adf4959 100644
> > > --- a/xen/arch/arm/traps.c
> > > +++ b/xen/arch/arm/traps.c
> > > @@ -1864,10 +1864,10 @@ static inline bool hpfar_is_valid(bool s1ptw,
> > > uint8_t fsc)
> > >   return s1ptw || (fsc == FSC_FLT_TRANS &&
> > > !check_workaround_834220());
> > >   }
> > >   -static bool try_handle_mmio(struct cpu_user_regs *regs,
> > > -const union hsr hsr,
> > > -paddr_t gpa)
> > > -{
> > > +static enum io_state try_handle_mmio(struct cpu_user_regs *regs,
> > > + const union hsr hsr,
> > > + paddr_t gpa)
> > > + {
> > >   const struct hsr_dabt dabt = hsr.dabt;
> > >  

Re: [Xen-devel] [PATCH] ARM: GICv3: copy Dom0 GICv3 reg property from host DT

[Stefano Stabellini]

On Tue, 30 Jan 2018, Andre Przywara wrote:
> At the moment we re-generate the Dom0 GICv3 DT node, by creating the
> "reg" property from scratch using our previously parsed and
> translated(!) host addresses. However we then write the *absolute*
> addresses into the new node, not considering possible "range" mappings
> in any of the GIC's parent nodes. So whenever one of the parents has a
> non-empty ranges property, Dom0 will wrongly translate the addresses.
> Properly incorporating the ranges properties sounds tedious, so let's
> just copy the first part of the reg property instead (as we do for GICv2),
> since the addresses for Dom0 are identical to those from the hardware.
> 
> The mainline kernel DT for the Espressobin board with an Marvell 3720 SoC
> has the GIC in such an translated bus, so this patch allows this board
> to boot properly (after adding support for the SoC's UART).
> 
> Signed-off-by: Andre Przywara 

There is one code style issue below, but I'll fix it on commit.

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/gic-v3.c | 29 +++--
>  1 file changed, 11 insertions(+), 18 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index a0d290b55c..6b17abd0a1 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1147,10 +1147,9 @@ static int gicv3_make_hwdom_dt_node(const struct 
> domain *d,
>  const struct dt_device_node *gic,
>  void *fdt)
>  {
> -const void *compatible = NULL;
> -uint32_t len;
> -__be32 *new_cells, *tmp;
> -int i, res = 0;
> +const void *compatible, *hw_reg;
> +uint32_t len, new_len;
> +int res;
>  
>  compatible = dt_get_property(gic, "compatible", );
>  if ( !compatible )
> @@ -1173,27 +1172,21 @@ static int gicv3_make_hwdom_dt_node(const struct 
> domain *d,
>  if ( res )
>  return res;
>  
> -len = dt_cells_to_size(dt_n_addr_cells(gic) + dt_n_size_cells(gic));
> +new_len = dt_cells_to_size(dt_n_addr_cells(gic) + dt_n_size_cells(gic));
>  /*
>   * GIC has two memory regions: Distributor + rdist regions
>   * CPU interface and virtual cpu interfaces accessesed as System 
> registers
>   * So cells are created only for Distributor and rdist regions
>   */
> -len = len * (d->arch.vgic.nr_regions + 1);
> -new_cells = xzalloc_bytes(len);
> -if ( new_cells == NULL )
> -return -FDT_ERR_XEN(ENOMEM);
> -
> -tmp = new_cells;
> -
> -dt_set_range(, gic, d->arch.vgic.dbase, SZ_64K);
> +new_len = new_len * (d->arch.vgic.nr_regions + 1);
>  
> -for ( i = 0; i < d->arch.vgic.nr_regions; i++ )
> -dt_set_range(, gic, d->arch.vgic.rdist_regions[i].base,
> - d->arch.vgic.rdist_regions[i].size);
> +hw_reg = dt_get_property(gic, "reg", );
> +if ( !hw_reg )
> +return -FDT_ERR_XEN(ENOENT);
> +if ( new_len > len )
> + return -FDT_ERR_XEN(ERANGE);
>  
> -res = fdt_property(fdt, "reg", new_cells, len);
> -xfree(new_cells);
> +res = fdt_property(fdt, "reg", hw_reg, new_len);
>  if ( res )
>  return res;
>  
> -- 
> 2.14.1
> 

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

Re: [Xen-devel] firmware/shim: fix build process to use POSIX find options

[Michael Glasgow]

Roger Pau [Monn_] wrote:
> On Fri, Jan 26, 2018 at 01:54:30PM -0600, Michael Glasgow wrote:
> > This recent patch can be simplified a bit.  (The patch below is
> > untested, just a suggestion.)
> 
> Thanks, this LGTM, but it needs your Signed-off-by tag in order to be
> applied.

Simplify posix-friendly changes a bit.

Signed-off-by: Michael Glasgow 
---

diff -ur a/tools/firmware/xen-dir/Makefile b/tools/firmware/xen-dir/Makefile
--- a/tools/firmware/xen-dir/Makefile   2018-01-26 11:40:00.711389605 -0600
+++ b/tools/firmware/xen-dir/Makefile   2018-01-26 11:51:41.279825142 -0600
@@ -20,9 +20,8 @@
rm -f linkfarm.stamp.tmp
$(foreach d, $(LINK_DIRS), \
 (mkdir -p $(D)/$(d); \
- cd $(D)/$(d); \
- find $(XEN_ROOT)/$(d)/ -type d -exec sh -c \
- "echo {} | sed 's,^$(XEN_ROOT)/$(d)/,,g' | xargs mkdir -p"
 \;);)
+ cd $(D)/$(d) && \
+ (cd $(XEN_ROOT)/$(d) && find . -type d) | xargs mkdir -p \;);)
$(foreach d, $(LINK_DIRS), \
(cd $(XEN_ROOT); \
 find $(d) ! -type l -type f \


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

Re: [Xen-devel] [PATCH 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c

[Julien Grall]

On 30/01/18 18:28, Volodymyr Babchuk wrote:

Hi Julien,

On 30.01.18 20:01, Julien Grall wrote:



On 26/01/18 18:27, Volodymyr Babchuk wrote:

Hi,


Hi Volodymyr,


On 26.01.18 20:15, Julien Grall wrote:

Hi,

On 26/01/18 18:09, Volodymyr Babchuk wrote:

On 24.01.18 20:34, Julien Grall wrote:

-    case PSCI_0_2_FN32(AFFINITY_INFO):
-    case PSCI_0_2_FN64(AFFINITY_INFO):
+    switch ( fid )
  {
-    register_t taff = PSCI_ARG(regs, 1);
-    uint32_t laff = PSCI_ARG32(regs, 2);
-
-    perfc_incr(vpsci_cpu_affinity_info);
-    PSCI_SET_RESULT(regs, do_psci_0_2_affinity_info(taff, 
laff));

-    return true;
-    }
-
  case ARM_SMCCC_FUNC_CALL_COUNT(STANDARD):
  return fill_function_call_count(regs, 
SSSC_SMCCC_FUNCTION_COUNT);

Now definition SSSC_SMCCC_FUNCTION_COUNT depends on code in vscpi.c.
Maybe it is time to introduce function get_psci_0_2_fn_count() and 
use it there, what do you think?


Definitely not a function. It is a static number. But I can think of 
separate the call count.
Yep, separate call count for vPSCI and for SSSC itself would be a 
good thing.


Looking a bit more into it, this will not make a real improvement. 
This will be equally difficult to remember to update the call count.

Nevertheless, I think that it is right thing to hold call count in the
same file, where calls are implemented. This increases chances that call 
count will be held in sync.


So you are suggesting to implement a function? If so, that's a no-go 
from my side.





Also, based on the recent SMCCC update (2.1.5 [1]):
"The General Service Queries for SMCCC call ranges are described in 
SMCCC section 6.2. These functions are not always well suited to 
firmware that is integrated with multiple sub-services being combined 
into one service range. For example, PSCI and SDEI in the Standard 
Service range. In particular, the ‘call count’ and ‘revision’ 
functions do not provide useful information to the caller when 
multiple functions are provided. As a result, these are not widely 
used to identify firmware services."


So I would not worry that much if the function count is not sync in 
the future. BTW, it is already wrong in Xen 4.10. For standard 
service, we don't implement 13 but 52.
2.1.5 deprecates general service queries in SMCCC 1.1. So, either we 
upgradeSMCCC in Xen to 1.1 or we should be conform with SMCCC 1.0 and 
should return right number of functions, including changes in Xen 4.10 
that you mentioned.


BTW, personally I'm not happy with call UID and call version 
deprecation. This makes impossible dynamic discovery of TEE, which was 
used in my TEE mediator patch series.


2.1.5 only deprecates for Architecture service which is not implemented 
for Xen at moment. Nothing is been said for the rest of them OP-TEE. The 
documentation only acknowledge the fact it is difficult for some service 
(such as SSSC) to infer information from that.


I looked at some implementation of SMCCC and those calls are either not 
handled or the number are not correct.


Anyway, I have a SMCCC 1.1 patch series coming up soon.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 0/3] xen/arm: Inject an exception to the guest rather than crashing it

[Andrew Cooper]

On 30/01/18 17:00, Julien Grall wrote:
>
>
> On 30/01/18 16:38, Andrew Cooper wrote:
>> On 30/01/18 16:14, Julien Grall wrote:
>>> Hi all,
>>>
>>> This small series replaces all call to domain_crash_synchronous by
>>> injecting
>>> an exception to the guest.
>>>
>>> This will result to a nicer trace from the guest (no need to
>>> manually walk
>>> the stack) and give a chance to the guest to give a bit more
>>> information on
>>> what it was doing.
>>>
>>> Cheers,
>>>
>>> Julien Grall (3):
>>>    xen/arm: io: Distinguish unhandled IO from aborted one
>>>    xen/arm: Don't crash domain on bad MMIO emulation
>>>    xen/arm: Don't crash the domain on invalid HVC immediate
>>
>> Thanks.
>>
>> I don't feel qualified to review these, but some notes.
>>
>> Patch 1.  s/avodi/avoid/ in the commit message
>>
>> Patches 2 and 3.  You probably want to convert the printks to
>> gdprintk()s, otherwise guests can choke up the ratelimited log.  Doing
>> so will also mean that the vcpu will be identified consistently, which
>> it isn't currently.
> We didn't use g*printk because it would be more confusing to print the
> current vCPU in some cases (e.g when accessing the re-distributor of
> another vCPU) or does not matter (e.g for ITS).

In the former case, you'd want to print both current, and the target
vcpu.  The latter still matters what current is if something goes wrong.

We have plenty of similar cases in x86, but at the point you are
printing an diagnostic message, ignoring current is almost always the
wrong think to do.

>
> The problem with the debug version is those information are actually
> quite useful in non-debug build. We found quite a few issues thanks to
> them.
>
> I think it would make more sense for Xen to provide per-guest
> ratelimited than hiding those messages in non-debug build.

Per guest is quite a lot more complicated than global, and would still
require a global limit to prevent a concerted attack from multiple
guests to avoid DoSing the system.

Debug vs unilateral is your prerogative as a maintainer, but as you've
said yourself, the are used for debugging purposes, which proves my point.

~Andrew

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

Re: [Xen-devel] [PATCH 1/3] xen/arm: io: Distinguish unhandled IO from aborted one

[Julien Grall]

Hi Stefano,

On 30/01/18 18:14, Stefano Stabellini wrote:

On Tue, 30 Jan 2018, Julien Grall wrote:

Currently, Xen is considering that an IO could either be handled or
unhandled. When unhandled, the stage-2 abort function will try another
way to resolve the abort.

However, the MMIO emulation may return unhandled when the address
belongs to an emulated range but was not correct. In that case, Xen
should avodi to try another way and directly inject a guest data abort.

  ^ avoid



Introduce a tri-state return to distinguish the following state:
 * IO_ABORT: The IO was handled but resulted to an abort

   ^ in an abort



 * IO_HANDLED: The IO was handled
 * IO_UNHANDLED: The IO was unhandled

For now, it is considered that an IO belonging to an emulated range
could either be handled or inject an abort. This could be revisit in the
future if overlapped region exist (or we want to try another way to
resolve the abort).

Signed-off-by: Julien Grall 
---
  xen/arch/arm/io.c  | 24 ++--
  xen/arch/arm/traps.c   | 34 +++---
  xen/include/asm-arm/mmio.h |  9 -
  3 files changed, 45 insertions(+), 22 deletions(-)

diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index c748d8f5bf..a74ec21b86 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -23,8 +23,9 @@
  #include 
  #include 
  
-static int handle_read(const struct mmio_handler *handler, struct vcpu *v,

-   mmio_info_t *info)
+static enum io_state handle_read(const struct mmio_handler *handler,
+ struct vcpu *v,
+ mmio_info_t *info)
  {
  const struct hsr_dabt dabt = info->dabt;
  struct cpu_user_regs *regs = guest_cpu_user_regs();
@@ -37,7 +38,7 @@ static int handle_read(const struct mmio_handler *handler, 
struct vcpu *v,
  uint8_t size = (1 << dabt.size) * 8;
  
  if ( !handler->ops->read(v, info, , handler->priv) )

-return 0;
+return IO_ABORT;
  
  /*

   * Sign extend if required.
@@ -57,17 +58,20 @@ static int handle_read(const struct mmio_handler *handler, 
struct vcpu *v,
  
  set_user_reg(regs, dabt.reg, r);
  
-return 1;

+return IO_HANDLED;
  }
  
-static int handle_write(const struct mmio_handler *handler, struct vcpu *v,

-mmio_info_t *info)
+static enum io_state handle_write(const struct mmio_handler *handler,
+  struct vcpu *v,
+  mmio_info_t *info)
  {
  const struct hsr_dabt dabt = info->dabt;
  struct cpu_user_regs *regs = guest_cpu_user_regs();
+int ret;
  
-return handler->ops->write(v, info, get_user_reg(regs, dabt.reg),

-   handler->priv);
+ret = handler->ops->write(v, info, get_user_reg(regs, dabt.reg),
+  handler->priv);
+return ( ret ) ? IO_HANDLED : IO_ABORT;
  }
  
  /* This function assumes that mmio regions are not overlapped */

@@ -100,14 +104,14 @@ static const struct mmio_handler 
*find_mmio_handler(struct domain *d,
  return handler;
  }
  
-int handle_mmio(mmio_info_t *info)

+enum io_state handle_mmio(mmio_info_t *info)
  {
  struct vcpu *v = current;
  const struct mmio_handler *handler = NULL;
  
  handler = find_mmio_handler(v->domain, info->gpa);

  if ( !handler )
-return 0;
+return IO_UNHANDLED;
  
  if ( info->dabt.write )

  return handle_write(handler, v, info);
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index c8534d6cff..843adf4959 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1864,10 +1864,10 @@ static inline bool hpfar_is_valid(bool s1ptw, uint8_t 
fsc)
  return s1ptw || (fsc == FSC_FLT_TRANS && !check_workaround_834220());
  }
  
-static bool try_handle_mmio(struct cpu_user_regs *regs,

-const union hsr hsr,
-paddr_t gpa)
-{
+static enum io_state try_handle_mmio(struct cpu_user_regs *regs,
+ const union hsr hsr,
+ paddr_t gpa)
+ {
  const struct hsr_dabt dabt = hsr.dabt;
  mmio_info_t info = {
  .gpa = gpa,
@@ -1879,11 +1879,11 @@ static bool try_handle_mmio(struct cpu_user_regs *regs,
  
  /* stage-1 page table should never live in an emulated MMIO region */

  if ( dabt.s1ptw )
-return false;
+return IO_UNHANDLED;
  
  /* All the instructions used on emulated MMIO region should be valid */

  if ( !dabt.valid )
-return false;
+return IO_UNHANDLED;
  
  /*

   * Erratum 766422: Thumb store translation fault to Hypervisor may
@@ -1896,11 +1896,11 @@ static bool try_handle_mmio(struct cpu_user_regs *regs,
  if ( rc )
  {
  

Re: [Xen-devel] [PATCH 3/3] xen/arm: Don't crash the domain on invalid HVC immediate

[Stefano Stabellini]

On Tue, 30 Jan 2018, Julien Grall wrote:
> domain_crash_synchronous() should only be used when something went wrong
> in Xen. It is better to inject to the guest as it will be in better
  ^ a better


> position to provide helpful information (stack trace...).
> 
> Signed-off-by: Julien Grall 
> 
> ---
> 
> We potentially want to return -1 instead. This would make Xen more
> future-proof if we decide to implement the other HVC immediate.
> ---
>  xen/arch/arm/traps.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 843adf4959..18da45dff3 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -1473,14 +1473,17 @@ static void do_debug_trap(struct cpu_user_regs *regs, 
> unsigned int code)
>  #endif
>  
>  static void do_trap_hypercall(struct cpu_user_regs *regs, register_t *nr,
> -  unsigned long iss)
> +  const union hsr hsr)
>  {
>  arm_hypercall_fn_t call = NULL;
>  
>  BUILD_BUG_ON(NR_hypercalls < ARRAY_SIZE(arm_hypercall_table) );
>  
> -if ( iss != XEN_HYPERCALL_TAG )
> -domain_crash_synchronous();
> +if ( hsr.iss != XEN_HYPERCALL_TAG )
> +{
> +gprintk(XENLOG_WARNING, "Invalid HVC imm 0x%x\n", hsr.iss);
> +return inject_undef_exception(regs, hsr);

It looks a bit weird, given that inject_undef_exception doesn't return
anything. This is just code style so anyway:

Reviewed-by: Stefano Stabellini 


> +}
>  
>  if ( *nr >= ARRAY_SIZE(arm_hypercall_table) )
>  {
> @@ -2150,7 +2153,7 @@ void do_trap_guest_sync(struct cpu_user_regs *regs)
>  if ( hsr.iss == 0 )
>  return do_trap_hvc_smccc(regs);
>  nr = regs->r12;
> -do_trap_hypercall(regs, , hsr.iss);
> +do_trap_hypercall(regs, , hsr);
>  regs->r12 = (uint32_t)nr;
>  break;
>  }
> @@ -2164,7 +2167,7 @@ void do_trap_guest_sync(struct cpu_user_regs *regs)
>  #endif
>  if ( hsr.iss == 0 )
>  return do_trap_hvc_smccc(regs);
> -do_trap_hypercall(regs, >x16, hsr.iss);
> +do_trap_hypercall(regs, >x16, hsr);
>  break;
>  case HSR_EC_SMC64:
>  /*
> -- 
> 2.11.0
> 

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

[Xen-devel] [PATCH] xen/arm: Park CPUs with a MIDR different from the boot CPU.

[Julien Grall]

Xen does not properly support big.LITTLE platform. All vCPUs of a guest
will always have the MIDR of the boot CPU (see arch_domain_create).
At best the guest may see unreliable performance (vCPU switching between
big and LITTLE), at worst the guest will become unreliable or insecure.

This is becoming more apparent with branch predictor hardening in Linux
because they target a specific kind of CPUs and may not work on other
CPUs.

For the time being, park any CPUs with a MDIR different from the boot
CPU. This will be revisited in the future once Xen gains understanding
of big.LITTLE.

[1] https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg00826.html

Signed-off-by: Julien Grall 

---

We probably want to backport this as part of XSA-254. Using big.LITTLE
on Xen has never been supported but we didn't make it clearly. This is
becoming more apparent with code targeting specific CPUs.
---
 xen/arch/arm/smpboot.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 1255185a9c..2c2815f9ee 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -292,6 +292,21 @@ void start_secondary(unsigned long boot_phys_offset,
 
 init_traps();
 
+/*
+ * Currently Xen assumes the platform has only one kind of CPUs.
+ * This assumption does not hold on big.LITTLE platform and may
+ * result to unstability. Better to park them for now.
+ *
+ * TODO: Add big.LITTLE support.
+ */
+if ( current_cpu_data.midr.bits != boot_cpu_data.midr.bits )
+{
+printk(XENLOG_ERR "CPU%u MIDR (0x%x) does not match boot CPU MIDR 
(0x%x).\n",
+   smp_processor_id(), current_cpu_data.midr.bits,
+   boot_cpu_data.midr.bits);
+stop_cpu();
+}
+
 mmu_init_secondary_cpu();
 
 gic_init_secondary_cpu();
-- 
2.11.0


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

Re: [Xen-devel] [PATCH 2/3] xen/arm: Don't crash domain on bad MMIO emulation

[Stefano Stabellini]

On Tue, 30 Jan 2018, Julien Grall wrote:
> Now the MMIO emulation is able to distinguish unhandled IO from aborted
> one, there are no need to crash the domain when the region is access
> with a bad width.
> 
> Instead let Xen inject a data abort to the guest and decide what to do.
> 
> Signed-off-by: Julien Grall 

Nice!

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/vgic-v2.c | 2 --
>  xen/arch/arm/vgic-v3-its.c | 3 ---
>  xen/arch/arm/vgic-v3.c | 8 
>  xen/arch/arm/vpl011.c  | 2 --
>  4 files changed, 15 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
> index 2bdb25261a..646d1f3d12 100644
> --- a/xen/arch/arm/vgic-v2.c
> +++ b/xen/arch/arm/vgic-v2.c
> @@ -348,7 +348,6 @@ static int vgic_v2_distr_mmio_read(struct vcpu *v, 
> mmio_info_t *info,
>  bad_width:
>  printk(XENLOG_G_ERR "%pv: vGICD: bad read width %d r%d offset %#08x\n",
> v, dabt.size, dabt.reg, gicd_reg);
> -domain_crash_synchronous();
>  return 0;
>  
>  read_as_zero_32:
> @@ -613,7 +612,6 @@ bad_width:
>  printk(XENLOG_G_ERR
> "%pv: vGICD: bad write width %d r%d=%"PRIregister" offset 
> %#08x\n",
> v, dabt.size, dabt.reg, r, gicd_reg);
> -domain_crash_synchronous();
>  return 0;
>  
>  write_ignore_32:
> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
> index d8fa44258d..32061c6b03 100644
> --- a/xen/arch/arm/vgic-v3-its.c
> +++ b/xen/arch/arm/vgic-v3-its.c
> @@ -1136,7 +1136,6 @@ read_reserved:
>  bad_width:
>  printk(XENLOG_G_ERR "vGITS: bad read width %d r%d offset %#04lx\n",
> info->dabt.size, info->dabt.reg, (unsigned long)info->gpa & 
> 0x);
> -domain_crash_synchronous();
>  
>  return 0;
>  }
> @@ -1446,8 +1445,6 @@ bad_width:
>  printk(XENLOG_G_ERR "vGITS: bad write width %d r%d offset %#08lx\n",
> info->dabt.size, info->dabt.reg, (unsigned long)info->gpa & 
> 0x);
>  
> -domain_crash_synchronous();
> -
>  return 0;
>  }
>  
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index af16dfd005..2ad8a6be62 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -328,7 +328,6 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, 
> mmio_info_t *info,
>  bad_width:
>  printk(XENLOG_G_ERR "%pv vGICR: bad read width %d r%d offset %#08x\n",
> v, dabt.size, dabt.reg, gicr_reg);
> -domain_crash_synchronous();
>  return 0;
>  
>  read_as_zero_64:
> @@ -648,7 +647,6 @@ bad_width:
>  printk(XENLOG_G_ERR
>"%pv: vGICR: bad write width %d r%d=%"PRIregister" offset %#08x\n",
>v, dabt.size, dabt.reg, r, gicr_reg);
> -domain_crash_synchronous();
>  return 0;
>  
>  write_ignore_64:
> @@ -760,7 +758,6 @@ static int __vgic_v3_distr_common_mmio_read(const char 
> *name, struct vcpu *v,
>  bad_width:
>  printk(XENLOG_G_ERR "%pv: %s: bad read width %d r%d offset %#08x\n",
> v, name, dabt.size, dabt.reg, reg);
> -domain_crash_synchronous();
>  return 0;
>  
>  read_as_zero:
> @@ -876,7 +873,6 @@ bad_width:
>  printk(XENLOG_G_ERR
> "%pv: %s: bad write width %d r%d=%"PRIregister" offset %#08x\n",
> v, name, dabt.size, dabt.reg, r, reg);
> -domain_crash_synchronous();
>  return 0;
>  
>  write_ignore_32:
> @@ -937,7 +933,6 @@ static int vgic_v3_rdistr_sgi_mmio_read(struct vcpu *v, 
> mmio_info_t *info,
>  bad_width:
>  printk(XENLOG_G_ERR "%pv: vGICR: SGI: bad read width %d r%d offset 
> %#08x\n",
> v, dabt.size, dabt.reg, gicr_reg);
> -domain_crash_synchronous();
>  return 0;
>  
>  read_as_zero_32:
> @@ -1017,7 +1012,6 @@ bad_width:
>  printk(XENLOG_G_ERR
> "%pv: vGICR: SGI: bad write width %d r%d=%"PRIregister" offset 
> %#08x\n",
> v, dabt.size, dabt.reg, r, gicr_reg);
> -domain_crash_synchronous();
>  return 0;
>  
>  write_ignore_32:
> @@ -1268,7 +1262,6 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, 
> mmio_info_t *info,
>  bad_width:
>  printk(XENLOG_G_ERR "%pv: vGICD: bad read width %d r%d offset %#08x\n",
> v, dabt.size, dabt.reg, gicd_reg);
> -domain_crash_synchronous();
>  return 0;
>  
>  read_as_zero_32:
> @@ -1456,7 +1449,6 @@ bad_width:
>  printk(XENLOG_G_ERR
> "%pv: vGICD: bad write width %d r%d=%"PRIregister" offset 
> %#08x\n",
> v, dabt.size, dabt.reg, r, gicd_reg);
> -domain_crash_synchronous();
>  return 0;
>  
>  write_ignore_32:
> diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> index 725b2e03ad..7788c2fc32 100644
> --- a/xen/arch/arm/vpl011.c
> +++ b/xen/arch/arm/vpl011.c
> @@ -296,7 +296,6 @@ static int vpl011_mmio_read(struct vcpu *v,
>  bad_width:
>  gprintk(XENLOG_ERR, "vpl011: bad read width %d r%d offset %#08x\n",
>  dabt.size, dabt.reg, vpl011_reg);
> -

Re: [Xen-devel] [PATCH 1/3] xen/arm: io: Distinguish unhandled IO from aborted one

[Stefano Stabellini]

On Tue, 30 Jan 2018, Julien Grall wrote:
> Currently, Xen is considering that an IO could either be handled or
> unhandled. When unhandled, the stage-2 abort function will try another
> way to resolve the abort.
> 
> However, the MMIO emulation may return unhandled when the address
> belongs to an emulated range but was not correct. In that case, Xen
> should avodi to try another way and directly inject a guest data abort.
 ^ avoid


> Introduce a tri-state return to distinguish the following state:
> * IO_ABORT: The IO was handled but resulted to an abort
  ^ in an abort


> * IO_HANDLED: The IO was handled
> * IO_UNHANDLED: The IO was unhandled
> 
> For now, it is considered that an IO belonging to an emulated range
> could either be handled or inject an abort. This could be revisit in the
> future if overlapped region exist (or we want to try another way to
> resolve the abort).
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/io.c  | 24 ++--
>  xen/arch/arm/traps.c   | 34 +++---
>  xen/include/asm-arm/mmio.h |  9 -
>  3 files changed, 45 insertions(+), 22 deletions(-)
> 
> diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
> index c748d8f5bf..a74ec21b86 100644
> --- a/xen/arch/arm/io.c
> +++ b/xen/arch/arm/io.c
> @@ -23,8 +23,9 @@
>  #include 
>  #include 
>  
> -static int handle_read(const struct mmio_handler *handler, struct vcpu *v,
> -   mmio_info_t *info)
> +static enum io_state handle_read(const struct mmio_handler *handler,
> + struct vcpu *v,
> + mmio_info_t *info)
>  {
>  const struct hsr_dabt dabt = info->dabt;
>  struct cpu_user_regs *regs = guest_cpu_user_regs();
> @@ -37,7 +38,7 @@ static int handle_read(const struct mmio_handler *handler, 
> struct vcpu *v,
>  uint8_t size = (1 << dabt.size) * 8;
>  
>  if ( !handler->ops->read(v, info, , handler->priv) )
> -return 0;
> +return IO_ABORT;
>  
>  /*
>   * Sign extend if required.
> @@ -57,17 +58,20 @@ static int handle_read(const struct mmio_handler 
> *handler, struct vcpu *v,
>  
>  set_user_reg(regs, dabt.reg, r);
>  
> -return 1;
> +return IO_HANDLED;
>  }
>  
> -static int handle_write(const struct mmio_handler *handler, struct vcpu *v,
> -mmio_info_t *info)
> +static enum io_state handle_write(const struct mmio_handler *handler,
> +  struct vcpu *v,
> +  mmio_info_t *info)
>  {
>  const struct hsr_dabt dabt = info->dabt;
>  struct cpu_user_regs *regs = guest_cpu_user_regs();
> +int ret;
>  
> -return handler->ops->write(v, info, get_user_reg(regs, dabt.reg),
> -   handler->priv);
> +ret = handler->ops->write(v, info, get_user_reg(regs, dabt.reg),
> +  handler->priv);
> +return ( ret ) ? IO_HANDLED : IO_ABORT;
>  }
>  
>  /* This function assumes that mmio regions are not overlapped */
> @@ -100,14 +104,14 @@ static const struct mmio_handler 
> *find_mmio_handler(struct domain *d,
>  return handler;
>  }
>  
> -int handle_mmio(mmio_info_t *info)
> +enum io_state handle_mmio(mmio_info_t *info)
>  {
>  struct vcpu *v = current;
>  const struct mmio_handler *handler = NULL;
>  
>  handler = find_mmio_handler(v->domain, info->gpa);
>  if ( !handler )
> -return 0;
> +return IO_UNHANDLED;
>  
>  if ( info->dabt.write )
>  return handle_write(handler, v, info);
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index c8534d6cff..843adf4959 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -1864,10 +1864,10 @@ static inline bool hpfar_is_valid(bool s1ptw, uint8_t 
> fsc)
>  return s1ptw || (fsc == FSC_FLT_TRANS && !check_workaround_834220());
>  }
>  
> -static bool try_handle_mmio(struct cpu_user_regs *regs,
> -const union hsr hsr,
> -paddr_t gpa)
> -{
> +static enum io_state try_handle_mmio(struct cpu_user_regs *regs,
> + const union hsr hsr,
> + paddr_t gpa)
> + {
>  const struct hsr_dabt dabt = hsr.dabt;
>  mmio_info_t info = {
>  .gpa = gpa,
> @@ -1879,11 +1879,11 @@ static bool try_handle_mmio(struct cpu_user_regs 
> *regs,
>  
>  /* stage-1 page table should never live in an emulated MMIO region */
>  if ( dabt.s1ptw )
> -return false;
> +return IO_UNHANDLED;
>  
>  /* All the instructions used on emulated MMIO region should be valid */
>  if ( !dabt.valid )
> -return false;
> +return IO_UNHANDLED;
>  
>  /*
>   * Erratum 766422: Thumb store translation fault to Hypervisor may
> @@ -1896,11 

Re: [Xen-devel] [PATCH 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c

[Julien Grall]

On 26/01/18 18:27, Volodymyr Babchuk wrote:

Hi,


Hi Volodymyr,


On 26.01.18 20:15, Julien Grall wrote:

Hi,

On 26/01/18 18:09, Volodymyr Babchuk wrote:

On 24.01.18 20:34, Julien Grall wrote:

-    case PSCI_0_2_FN32(AFFINITY_INFO):
-    case PSCI_0_2_FN64(AFFINITY_INFO):
+    switch ( fid )
  {
-    register_t taff = PSCI_ARG(regs, 1);
-    uint32_t laff = PSCI_ARG32(regs, 2);
-
-    perfc_incr(vpsci_cpu_affinity_info);
-    PSCI_SET_RESULT(regs, do_psci_0_2_affinity_info(taff, laff));
-    return true;
-    }
-
  case ARM_SMCCC_FUNC_CALL_COUNT(STANDARD):
  return fill_function_call_count(regs, 
SSSC_SMCCC_FUNCTION_COUNT);

Now definition SSSC_SMCCC_FUNCTION_COUNT depends on code in vscpi.c.
Maybe it is time to introduce function get_psci_0_2_fn_count() and 
use it there, what do you think?


Definitely not a function. It is a static number. But I can think of 
separate the call count.
Yep, separate call count for vPSCI and for SSSC itself would be a good 
thing.


Looking a bit more into it, this will not make a real improvement. This 
will be equally difficult to remember to update the call count.


Also, based on the recent SMCCC update (2.1.5 [1]):
"The General Service Queries for SMCCC call ranges are described in 
SMCCC section 6.2. These functions are not always well suited to 
firmware that is integrated with multiple sub-services being combined 
into one service range. For example, PSCI and SDEI in the Standard 
Service range. In particular, the ‘call count’ and ‘revision’ functions 
do not provide useful information to the caller when multiple functions 
are provided. As a result, these are not widely used to identify 
firmware services."


So I would not worry that much if the function count is not sync in the 
future. BTW, it is already wrong in Xen 4.10. For standard service, we 
don't implement 13 but 52.


Cheers,

[1] 
https://developer.arm.com/-/media/developer/pdf/ARM%20DEN%200070A%20Firmware%20interfaces%20for%20mitigating%20CVE-2017-5715_V1.0.pdf?revision=d20d1476-b770-4739-aebe-2d3147788e3f=en


I don't expect PSCI to be


--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 2/2] xen/arm: GICv3: Only initialize ITS when the distributor supports LPIs.

[Stefano Stabellini]

On Wed, 24 Jan 2018, Julien Grall wrote:
> There are firmware tables out describing the ITS but does not support
> LPIs. This will result to a data abort when trying to initialize ITS.
> 
> While this can be consider a bug in the Device-Tree, same configuration
> boots on Linux. So gate the ITS initialization with the support of LPIs
> in the distributor.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/gic-v3.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 9f9cf59f82..730450e34b 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1637,6 +1637,11 @@ static unsigned long 
> gicv3_get_hwdom_extra_madt_size(const struct domain *d)
>  }
>  #endif
>  
> +static bool gic_dist_supports_lpis(void)
> +{
> +return (readl_relaxed(GICD + GICD_TYPER) & GICD_TYPE_LPIS);
> +}
> +
>  /* Set up the GIC */
>  static int __init gicv3_init(void)
>  {
> @@ -1699,9 +1704,12 @@ static int __init gicv3_init(void)
>  
>  gicv3_dist_init();
>  
> -res = gicv3_its_init();
> -if ( res )
> -panic("GICv3: ITS: initialization failed: %d\n", res);
> +if ( gic_dist_supports_lpis() )
> +{
> +res = gicv3_its_init();
> +if ( res )
> +panic("GICv3: ITS: initialization failed: %d\n", res);
> +}
>  
>  res = gicv3_cpu_init();
>  if ( res )
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH v2 1/2] xen/arm: GICv3: Parse ITS information from the firmware tables later on

[Stefano Stabellini]

On Wed, 24 Jan 2018, Julien Grall wrote:
> There are Device Tree (e.g for the Foundation Model) out that describes the
> ITS but LPIs is not supported by the platform. Booting with such DT will
> result to an early Data Abort. The same DT is booting fine with a
> baremetal  Linux because ITS will be initialized only when LPIs is
> supported.
> 
> While this is a bug in the DT, I think Xen should be boot with the same
> hardware level support (e.g ITS will not be used) as with a baremetal
> Linux.
> 
> The slight problem is Xen is relying on gicv3_its_host_has_its() to know
> if ITS can be used. The list is populated by gicv3_its_{dt,acpi}_init().
> It would theoritical be possible to gate those with a check of
   ^ theoretically


> GICD_TYPER.LPIS because we don't know yet whether the HW is an actual
> GICv3/GICv4.
> 
> Looking at the callers of gicv3_its_host_has_its(), they will only be
> done after gicv3_its_init() is called. Therefore move the parsing of ITS
> information from firmware tables later on.
> 
> Note that gicv3_its_init() has been moved at the end of the file to
> avoid forward declaration.
> 
> Signed-off-by: Julien Grall 
> 
> ---
> 
> I can move the code movement in a separate patch if necessary. It was
> small enough that I thought it would not be worth.

Yeah, that's OK, thanks for pointing it out

Reviewed-by: Stefano Stabellini 


> Changes in v2:
> - Actually test compilation and boot of this patch...
> ---
>  xen/arch/arm/gic-v3-its.c| 47 
> +---
>  xen/arch/arm/gic-v3.c|  5 -
>  xen/include/asm-arm/gic_v3_its.h | 12 --
>  3 files changed, 30 insertions(+), 34 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> index e57ae05771..6127894d0b 100644
> --- a/xen/arch/arm/gic-v3-its.c
> +++ b/xen/arch/arm/gic-v3-its.c
> @@ -515,21 +515,6 @@ static int gicv3_its_init_single_its(struct host_its 
> *hw_its)
>  return 0;
>  }
>  
> -int gicv3_its_init(void)
> -{
> -struct host_its *hw_its;
> -int ret;
> -
> -list_for_each_entry(hw_its, _its_list, entry)
> -{
> -ret = gicv3_its_init_single_its(hw_its);
> -if ( ret )
> -return ret;
> -}
> -
> -return 0;
> -}
> -
>  /*
>   * TODO: Investigate the interaction when a guest removes a device while
>   * some LPIs are still in flight.
> @@ -1019,7 +1004,7 @@ static void add_to_host_its_list(paddr_t addr, paddr_t 
> size,
>  }
>  
>  /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. 
> */
> -void gicv3_its_dt_init(const struct dt_device_node *node)
> +static void gicv3_its_dt_init(const struct dt_device_node *node)
>  {
>  const struct dt_device_node *its = NULL;
>  
> @@ -1056,7 +1041,7 @@ static int gicv3_its_acpi_probe(struct 
> acpi_subtable_header *header,
>  return 0;
>  }
>  
> -void gicv3_its_acpi_init(void)
> +static void gicv3_its_acpi_init(void)
>  {
>  /* Parse ITS information */
>  acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
> @@ -1081,8 +1066,36 @@ unsigned long gicv3_its_make_hwdom_madt(const struct 
> domain *d, void *base_ptr)
>  
>  return sizeof(struct acpi_madt_generic_translator) * 
> vgic_v3_its_count(d);
>  }
> +#else /* !CONFIG_ACPI */
> +
> +static void gicv3_its_acpi_init(void)
> +{
> +ASSERT_UNREACHABLE();
> +}
> +
>  #endif
>  
> +int gicv3_its_init(void)
> +{
> +struct host_its *hw_its;
> +int ret;
> +
> +if ( acpi_disabled )
> +gicv3_its_dt_init(dt_interrupt_controller);
> +else
> +gicv3_its_acpi_init();
> +
> +list_for_each_entry(hw_its, _its_list, entry)
> +{
> +ret = gicv3_its_init_single_its(hw_its);
> +if ( ret )
> +return ret;
> +}
> +
> +return 0;
> +}
> +
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index a0d290b55c..9f9cf59f82 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1314,9 +1314,6 @@ static void __init gicv3_dt_init(void)
>  if ( !res )
>  dt_device_get_address(node, 1 + gicv3.rdist_count + 2,
>, );
> -
> -/* Check for ITS child nodes and build the host ITS list accordingly. */
> -gicv3_its_dt_init(node);
>  }
>  
>  static int gicv3_iomem_deny_access(const struct domain *d)
> @@ -1608,8 +1605,6 @@ static void __init gicv3_acpi_init(void)
>  
>  gicv3.rdist_stride = 0;
>  
> -gicv3_its_acpi_init();
> -
>  /*
>   * In ACPI, 0 is considered as the invalid address. However the rest
>   * of the initialization rely on the invalid address to be
> diff --git a/xen/include/asm-arm/gic_v3_its.h 
> b/xen/include/asm-arm/gic_v3_its.h
> index 40dffdc0fa..78a9bb14de 100644
> --- a/xen/include/asm-arm/gic_v3_its.h
> +++ b/xen/include/asm-arm/gic_v3_its.h
> @@ -133,11 +133,7 @@ struct host_its {

[Xen-devel] [PATCH v4 2/7] xen: xsm: flask: introduce XENMAPSPACE_gmfn_share for memory sharing

[Zhongze Liu]

The existing XENMAPSPACE_gmfn_foreign subop of XENMEM_add_to_physmap forbids
a Dom0 to map memory pages from one DomU to another, which restricts some useful
yet not dangerous use cases -- such as sharing pages among DomU's so that they
can do shm-based communication.

This patch introduces XENMAPSPACE_gmfn_share to address this inconvenience,
which is mostly the same as XENMAPSPACE_gmfn_foreign but has its own xsm check.

Specifically, the patch:

* Introduces a new av permission MMU__SHARE_MEM to denote if two domains can
  share memory by using the new subop;
* Introduces xsm_map_gmfn_share() to check if (current) has proper permission
  over (t) AND MMU__SHARE_MEM is allowed between (d) and (t);
* Modify the default xen.te to allow MMU__SHARE_MEM for normal domains that
  allow grant mapping/event channels.

The new subop is marked unsupported for x86 because calling p2m_add_foregin
on two DomU's is currently not supported on x86.

This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).

[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html

Signed-off-by: Zhongze Liu 

Cc: Daniel De Graaf 
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: xen-de...@lists.xen.org
---
  V3:
  * Change several if statements to the GCC '... = a ?: b' extention.
  * Lookup the current domain in the hooks instead of passing it as an arg.

  V4:
  * Eliminate the duplicated (c) over (d) check.
  * Added a new subop instead of modifying the old subop.
---
 tools/flask/policy/modules/xen.if   | 2 ++
 xen/arch/arm/mm.c   | 8 +++-
 xen/arch/x86/mm.c   | 4 
 xen/include/public/memory.h | 4 
 xen/include/xsm/dummy.h | 6 ++
 xen/include/xsm/xsm.h   | 6 ++
 xen/xsm/dummy.c | 1 +
 xen/xsm/flask/hooks.c   | 7 +++
 xen/xsm/flask/policy/access_vectors | 5 +
 9 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/tools/flask/policy/modules/xen.if 
b/tools/flask/policy/modules/xen.if
index 459880bb01..f02d49114f 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -127,6 +127,8 @@ define(`domain_comms', `
domain_event_comms($1, $2)
allow $1 $2:grant { map_read map_write copy unmap };
allow $2 $1:grant { map_read map_write copy unmap };
+   allow $1 $2:mmu share_mem;
+   allow $2 $1:mmu share_mem;
 ')
 
 # domain_self_comms(domain)
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 3c328e2df5..8e385d62a8 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1251,6 +1251,7 @@ int xenmem_add_to_physmap_one(
 
 break;
 case XENMAPSPACE_gmfn_foreign:
+case XENMAPSPACE_gmfn_share:
 {
 struct domain *od;
 p2m_type_t p2mt;
@@ -1265,7 +1266,12 @@ int xenmem_add_to_physmap_one(
 return -EINVAL;
 }
 
-rc = xsm_map_gmfn_foreign(XSM_TARGET, d, od);
+if ( space == XENMAPSPACE_gmfn_foreign ) {
+rc = xsm_map_gmfn_foreign(XSM_TARGET, d, od);
+} else {
+rc = xsm_map_gmfn_share(XSM_TARGET, d, od);
+}
+
 if ( rc )
 {
 rcu_unlock_domain(od);
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index c732734ac1..684403f737 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4126,6 +4126,10 @@ int xenmem_add_to_physmap_one(
 }
 case XENMAPSPACE_gmfn_foreign:
 return p2m_add_foreign(d, idx, gfn_x(gpfn), extra.foreign_domid);
+case XENMAPSPACE_gmfn_share:
+gdprintk(XENLOG_WARNING,
+ "XENMAPSPACE_gmfn_share is currently not supported on 
x86\n");
+break;
 default:
 break;
 }
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 29386df98b..ce70788660 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -227,6 +227,10 @@ DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
   Stage-2 using the Normal Memory
   Inner/Outer Write-Back Cacheable
   memory attribute. */
+#define XENMAPSPACE_gmfn_share   6 /* Same as *_gmfn_foreign, but this is
+  for a privileged dom to share pages
+  between two doms. */
+
 /* ` } */
 
 /*
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index d6ddadcafd..cda87dea12 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -521,6 +521,12 @@ static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG 
struct domain *d, str
 return xsm_default_action(action, d, t);
 }
 
+static XSM_INLINE int 

[Xen-devel] [PATCH v4 6/7] libxl:xl: add parsing code to parse "libxl_static_sshm" from xl config files

[Zhongze Liu]

Add the parsing utils for the newly introduced libxl_static_sshm struct
to the libxl/libxlu_* family. And add realated parsing code in xl to
parse the struct from xl config files. This is for the proposal "Allow
setting up shared memory areas between VMs from xl config file" (see [1]).

[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html

Signed-off-by: Zhongze Liu 

Cc: Wei Liu 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: xen-de...@lists.xen.org
---
 tools/libxl/Makefile  |   2 +-
 tools/libxl/libxlu_sshm.c | 210 ++
 tools/libxl/libxlutil.h   |   6 ++
 tools/xl/xl_parse.c   |  24 +-
 4 files changed, 240 insertions(+), 2 deletions(-)
 create mode 100644 tools/libxl/libxlu_sshm.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index e2834d84dc..dfd68bc2df 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -176,7 +176,7 @@ AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h 
_paths.h \
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
 AUTOSRCS += _libxl_save_msgs_callout.c _libxl_save_msgs_helper.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
-   libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o
+   libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o libxlu_sshm.o
 $(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 
 $(TEST_PROG_OBJS) _libxl.api-for-check: CFLAGS += $(CFLAGS_libxentoollog) 
$(CFLAGS_libxentoolcore)
diff --git a/tools/libxl/libxlu_sshm.c b/tools/libxl/libxlu_sshm.c
new file mode 100644
index 00..5276ff9395
--- /dev/null
+++ b/tools/libxl/libxlu_sshm.c
@@ -0,0 +1,210 @@
+#include "libxl_osdeps.h" /* must come before any other headers */
+#include "libxlu_internal.h"
+#include "xenctrl.h"
+
+#include 
+
+#define PARAM_RE(EXPR) "^\\s*" EXPR "\\s*(,|$)"
+#define WORD_RE "([_a-zA-Z0-9]+)"
+#define EQU_RE PARAM_RE(WORD_RE "\\s*=\\s*" WORD_RE)
+
+#define RET_INVAL(msg, curr_str)  do {  \
+xlu__sshm_err(cfg, msg, curr_str);  \
+rc = EINVAL;\
+goto out;   \
+} while(0)
+
+/* set a member in libxl_static_shm and report an error if it's respecified,
+ * @curr_str indicates the head of the remaining string. */
+#define SET_VAL(var, name, type, value, curr_str)  do { \
+if ((var) != LIBXL_SSHM_##type##_UNKNOWN && (var) != value) {   \
+RET_INVAL("\"" name "\" respecified", curr_str);\
+}   \
+(var) = value;  \
+} while(0)
+
+
+static void xlu__sshm_err(XLU_Config *cfg, const char *msg,
+  const char *curr_str) {
+fprintf(cfg->report,
+"%s: config parsing error in shared_memory: %s at '%s'\n",
+cfg->config_source, msg, curr_str);
+}
+
+static int parse_prot(XLU_Config *cfg, char *str, libxl_sshm_prot *prot)
+{
+int rc;
+libxl_sshm_prot new_prot;
+
+if (!strcmp(str, "rw")) {
+new_prot = LIBXL_SSHM_PROT_RW;
+} else {
+RET_INVAL("invalid permission flags", str);
+}
+
+SET_VAL(*prot, "permission flags", PROT, new_prot, str);
+
+rc = 0;
+
+ out:
+return rc;
+}
+
+static int parse_cachepolicy(XLU_Config *cfg, char *str,
+ libxl_sshm_cachepolicy *policy)
+{
+int rc;
+libxl_sshm_cachepolicy new_policy;
+
+if (!strcmp(str, "ARM_normal")) {
+new_policy = LIBXL_SSHM_CACHEPOLICY_ARM_NORMAL;
+} else if (!strcmp(str, "x86_normal")) {
+new_policy = LIBXL_SSHM_CACHEPOLICY_X86_NORMAL;
+} else {
+RET_INVAL("invalid cache policy", str);
+}
+
+SET_VAL(*policy, "cache policy", CACHEPOLICY, new_policy, str);
+rc = 0;
+
+ out:
+return rc;
+}
+
+/* handle key = value pairs */
+static int handle_equ(XLU_Config *cfg, char *key, char *val,
+  libxl_static_shm *sshm)
+{
+int rc;
+
+if (!strcmp(key, "id")) {
+if (strlen(val) > LIBXL_SSHM_ID_MAXLEN) { RET_INVAL("id too long", 
val); }
+if (sshm->id && !strcmp(sshm->id, val)) {
+RET_INVAL("id respecified", val);
+}
+
+sshm->id = strdup(val);
+if (!sshm->id) {
+fprintf(stderr, "sshm parser out of memory\n");
+rc = ENOMEM;
+goto out;
+}
+} else if (!strcmp(key, "role")) {
+libxl_sshm_role new_role;
+
+if (!strcmp("master", val)) {
+new_role = LIBXL_SSHM_ROLE_MASTER;
+} else if (!strcmp("slave", val)) {
+new_role = LIBXL_SSHM_ROLE_SLAVE;
+} else {
+RET_INVAL("invalid role", val);
+}
+
+SET_VAL(sshm->role, "role", 

[Xen-devel] [PATCH v4 7/7] docs: documentation about static shared memory regions

[Zhongze Liu]

Add docs to document the motivation, usage, use cases and other
relevant information about the static shared memory feature.

This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file". See:

  https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html

Signed-off-by: Zhongze Liu 

Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: xen-de...@lists.xen.org
---
 docs/man/xl-static-shm-configuration.pod.5 | 257 +
 docs/man/xl.cfg.pod.5.in   |   8 +
 docs/misc/xenstore-paths.markdown  |  47 ++
 3 files changed, 312 insertions(+)
 create mode 100644 docs/man/xl-static-shm-configuration.pod.5

diff --git a/docs/man/xl-static-shm-configuration.pod.5 
b/docs/man/xl-static-shm-configuration.pod.5
new file mode 100644
index 00..d68ed0ebf7
--- /dev/null
+++ b/docs/man/xl-static-shm-configuration.pod.5
@@ -0,0 +1,257 @@
+=head1 NAME
+
+xl-static-shm-configuration - XL Static Shared Memeory Configuration Syntax
+
+
+(B: This is currently only available to ARM guests.)
+
+=head1 DESCRIPTION
+
+The static_shm option allows users to statically setup shared memory regions
+among a group of VMs, enabling guests without grant table support to do
+shm-based communication.
+
+Every shared region is:
+
+=over 4
+
+* Uniquely identified by a string that is no longer than 128 characters, which
+is called an B in this document.
+
+* Backed by exactely one domain, which is called a B domain, and all
+the other domains who are also sharing this region are called Bs.
+
+=back
+
+=head1 SYNTAX
+
+This document specifies syntax of the static shared memory configuration in
+the xl config file. It has the following form:
+
+static_shm = [ "SSHM_SPEC", "SSHM_SPEC", ... ]
+
+where each C is in this form:
+
+[=,]*
+
+Valid examples of C are:
+
+id=ID1, begin=0x10, end=0x20, role=master, cache_policy=x86_normal
+id=ID1, offset = 0, begin=0x50, end=0x60, role=slave, prot=rw
+id=ID2, begin=0x30, end=0x40, role=master
+id=ID2, offset = 0x1, begin=0x69, end=0x80, role=slave
+id=ID2, offset = 0x1, begin=0x69, end=0x80, role=slave
+
+These might be specified in the domain config file like this:
+
+static_shm = ["id=ID2, offset = 0x1, begin=0x69, end=0x80,
+role=slave"]
+
+
+More formally, the string is a series of comma-separated keyword/value
+pairs. Each parameter may be specified at most once. Default values apply if
+the parameter is not specified.
+
+=head1 Parameters
+
+=over 4
+
+=item B
+
+=over 4
+
+=item Description
+
+The unique identifier of the shared memory region.
+
+Every identifier could appear only once in each xl config file.
+
+=item Supported values
+
+A string that contains alphanumerics and "_"s, and is no longer than 128
+characters.
+
+=item Default value
+
+None, this parameter is mandatory.
+
+=back
+
+=item B/B
+
+=over 4
+
+=item Description
+
+The boundaries of the shared memory area.
+
+=item Supported values
+
+Same with B.
+
+=item Default Value
+
+None, this parameter is mandatory.
+
+=back
+
+=item B
+
+=over 4
+
+=item Description
+
+Can only appear when B = slave. If set, the address mapping will not
+start from the beginning the backing memory region, but from the middle
+(B bytes away from the beginning) of it. See the graph below:
+
+With B = 0, the mapping will look like:
+
+  backing memory region:  #
+  |   |
+  |   |
+  |   |
+  V   V
+  slave's shared region:  #
+
+With B > 0:
+
+  backing memory region:   #
+   |<-- offset -->||   |
+   |   |
+   |   |
+   V   V
+  slave's memory region:   #
+
+=item Supported values
+
+Decimals or hexadecimals with a prefix "0x", and should be the multiple of the
+hypervisor page granularity (currently 4K on both ARM and x86).
+
+=item Default value
+
+0x0
+
+=back
+
+=item B
+
+=over 4
+
+=item Description
+
+The backing area would be taken from one domain, which we will mark
+as the "master domain", and this domain should be created prior to any
+other slave domains that depend on it.
+
+This arugment specifies the role of this domain.
+
+=item Supported values
+
+master, slave
+
+=item Default value
+
+slave
+
+=back
+
+=item B
+
+=over 4
+
+=item Description
+
+When B = master, this means the 

[Xen-devel] [PATCH v4 3/7] libxl: introduce a new structure to represent static shared memory regions

[Zhongze Liu]

Add a new structure to the IDL familiy to represent static shared memory regions
as proposed in the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).

And deleted some trailing white spaces.

[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html

Signed-off-by: Zhongze Liu 
Reviewed-by: Stefano Stabellini 
Acked-by: Wei Liu 

Cc: Wei Liu 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: xen-de...@lists.xen.org
---
 tools/libxl/libxl.h |  4 
 tools/libxl/libxl_types.idl | 32 ++--
 2 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index eca0ea2c50..372ad3cd32 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -2365,6 +2365,10 @@ int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int 
nonblock);
 int libxl_qemu_monitor_command(libxl_ctx *ctx, uint32_t domid,
const char *command_line, char **output);
 
+/* Constants for libxl_static_shm */
+#define LIBXL_SSHM_RANGE_UNKNOWN UINT64_MAX
+#define LIBXL_SSHM_ID_MAXLEN128
+
 #include 
 
 #endif /* LIBXL_H */
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 35038120ca..4e9accf168 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -559,10 +559,10 @@ libxl_domain_build_info = Struct("domain_build_info",[
("keymap",   string),
("sdl",  libxl_sdl_info),
("spice",libxl_spice_info),
-   
+
("gfx_passthru", libxl_defbool),
("gfx_passthru_kind", 
libxl_gfx_passthru_kind),
-   
+
("serial",   string),
("boot", string),
("usb",  libxl_defbool),
@@ -816,6 +816,33 @@ libxl_device_vdispl = Struct("device_vdispl", [
 ("connectors", Array(libxl_connector_param, "num_connectors"))
 ])
 
+libxl_sshm_cachepolicy = Enumeration("sshm_cachepolicy", [
+(-1, "UNKNOWN"),
+(0,  "ARM_NORMAL"),  # ARM policies should be < 32
+(32,  "X86_NORMAL"), # X86 policies should be >= 32
+], init_val = "LIBXL_SSHM_CHCHE_POLICY_UNKNOWN")
+
+libxl_sshm_prot = Enumeration("sshm_prot", [
+(-1, "UNKNOWN"),
+(3,  "RW"),
+], init_val = "LIBXL_SSHM_PROT_UNKNOWN")
+
+libxl_sshm_role = Enumeration("sshm_role", [
+(-1, "UNKNOWN"),
+(0,  "MASTER"),
+(1,  "SLAVE"),
+], init_val = "LIBXL_SSHM_ROLE_UNKNOWN")
+
+libxl_static_shm = Struct("static_shm", [
+("id", string),
+("offset", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
+("begin", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
+("end", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
+("prot", libxl_sshm_prot, {'init_val': 'LIBXL_SSHM_PROT_UNKNOWN'}),
+("cache_policy", libxl_sshm_cachepolicy, {'init_val': 
'LIBXL_SSHM_CACHEPOLICY_UNKNOWN'}),
+("role", libxl_sshm_role, {'init_val': 'LIBXL_SSHM_ROLE_UNKNOWN'}),
+])
+
 libxl_domain_config = Struct("domain_config", [
 ("c_info", libxl_domain_create_info),
 ("b_info", libxl_domain_build_info),
@@ -835,6 +862,7 @@ libxl_domain_config = Struct("domain_config", [
 ("channels", Array(libxl_device_channel, "num_channels")),
 ("usbctrls", Array(libxl_device_usbctrl, "num_usbctrls")),
 ("usbdevs", Array(libxl_device_usbdev, "num_usbdevs")),
+("sshms", Array(libxl_static_shm, "num_sshms")),
 
 ("on_poweroff", libxl_action_on_shutdown),
 ("on_reboot", libxl_action_on_shutdown),
-- 
2.16.1


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

[Xen-devel] [PATCH v4 4/7] libxl: support mapping static shared memory areas during domain creation

[Zhongze Liu]

Add libxl__sshm_add to map shared pages from one DomU to another, The mapping
process involves the follwing steps:

  * Set defaults and check for further errors in the static_shm configs:
overlapping areas, invalid ranges, duplicated master domain,
not page aligned, no master domain etc.
  * Use xc_domain_add_to_physmap_batch to do the page sharing.
  * When some of the pages can't be successfully mapped, roll back any
successfully mapped pages so that the system stays in a consistent state.
  * Write infomation about static shared memory areas into the appropriate
xenstore paths and set the refcount of the shared region accordingly.

Temporarily mark this as unsupported on x86 because calling p2m_add_foreign on
two domU's is currently not allowd on x86 (see the comments in
x86/mm/p2m.c:p2m_add_foreign for more details).

This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).

[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html

Signed-off-by: Zhongze Liu 

Cc: Wei Liu 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: xen-de...@lists.xen.org
---
  V3:
  * Unmap the successfully mapped pages whenever rc != 0.

  V4:
  * Use XENMAPSPACE_gmfn_share instead of *_gmfn_foreign.
---
 tools/libxl/Makefile |   2 +-
 tools/libxl/libxl_arch.h |   6 +
 tools/libxl/libxl_arm.c  |  15 ++
 tools/libxl/libxl_create.c   |  27 +++
 tools/libxl/libxl_internal.h |  14 ++
 tools/libxl/libxl_sshm.c | 397 +++
 tools/libxl/libxl_x86.c  |  19 +++
 7 files changed, 479 insertions(+), 1 deletion(-)
 create mode 100644 tools/libxl/libxl_sshm.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 917ceb0e72..e2834d84dc 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -139,7 +139,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o 
libxl_pci.o \
libxl_dom_suspend.o libxl_dom_save.o libxl_usb.o \
libxl_vtpm.o libxl_nic.o libxl_disk.o libxl_console.o \
libxl_cpupool.o libxl_mem.o libxl_sched.o libxl_tmem.o \
-   libxl_9pfs.o libxl_domain.o libxl_vdispl.o \
+   libxl_9pfs.o libxl_domain.o libxl_vdispl.o libxl_sshm.o 
\
 $(LIBXL_OBJS-y)
 LIBXL_OBJS += libxl_genid.o
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index 784ec7f609..11433fe466 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -78,6 +78,12 @@ int libxl__arch_extra_memory(libxl__gc *gc,
  const libxl_domain_build_info *info,
  uint64_t *out);
 
+_hidden
+bool libxl__arch_domain_support_sshm(const libxl_domain_build_info *b_info);
+
+_hidden
+int libxl__arch_domain_sshm_cachepolicy_setdefault(libxl_static_shm *sshm);
+
 #if defined(__i386__) || defined(__x86_64__)
 
 #define LAPIC_BASE_ADDRESS  0xfee0
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 3e46554301..e14879ec08 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -1154,6 +1154,21 @@ void libxl__arch_domain_build_info_acpi_setdefault(
 libxl_defbool_setdefault(_info->acpi, false);
 }
 
+bool libxl__arch_domain_support_sshm(const libxl_domain_build_info *b_info)
+{
+return true;
+}
+
+int libxl__arch_domain_sshm_cachepolicy_setdefault(libxl_static_shm *sshm)
+{
+if (sshm->cache_policy == LIBXL_SSHM_CACHEPOLICY_UNKNOWN)
+sshm->cache_policy = LIBXL_SSHM_CACHEPOLICY_ARM_NORMAL;
+if (sshm->cache_policy >= LIBXL_SSHM_CACHEPOLICY_X86_NORMAL)
+return ERROR_INVAL;
+
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index c498135246..98c16867bf 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -532,6 +532,14 @@ int libxl__domain_build(libxl__gc *gc,
 ret = ERROR_INVAL;
 goto out;
 }
+
+/* the p2m has been setup, we could map the static shared memory now. */
+ret = libxl__sshm_add(gc, domid, d_config->sshms, d_config->num_sshms);
+if (ret != 0) {
+LOG(ERROR, "failed to map static shared memory");
+goto out;
+}
+
 ret = libxl__build_post(gc, domid, info, state, vments, localents);
 out:
 return ret;
@@ -957,6 +965,25 @@ static void initiate_domain_create(libxl__egc *egc,
 goto error_out;
 }
 
+if (d_config->num_sshms != 0 &&
+!libxl__arch_domain_support_sshm(_config->b_info)) {
+LOGD(ERROR, domid, "static_shm is not supported by this domain type.");
+ret = ERROR_INVAL;
+goto error_out;
+}
+
+for (i = 0; i < d_config->num_sshms; ++i) {
+ 

[Xen-devel] [PATCH v4 1/7] libxc: add xc_domain_remove_from_physmap to wrap XENMEM_remove_from_physmap

[Zhongze Liu]

This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file". See:

  https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html

Then plan is to use XENMEM_add_to_physmap_batch to map the shared pages from
one domU to another and use XENMEM_remove_from_physmap to cancel the sharing.
A wrapper to XENMEM_add_to_physmap_batch was added in the following commit:

  commit 20e725e9364cff4a29945f66986ecd88cca8743d

Now add the wrapper to XENMEM_remove_from_physmap.

Signed-off-by: Zhongze Liu 
Reviewed-by: Stefano Stabellini 
Acked-by: Wei Liu 

Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: xen-de...@lists.xen.org
---
 tools/libxc/include/xenctrl.h |  4 
 tools/libxc/xc_domain.c   | 11 +++
 2 files changed, 15 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 235b8bb847..543abfcb34 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1416,6 +1416,10 @@ int xc_domain_add_to_physmap_batch(xc_interface *xch,
xen_pfn_t *gfpns,
int *errs);
 
+int xc_domain_remove_from_physmap(xc_interface *xch,
+  uint32_t domid,
+  xen_pfn_t gpfn);
+
 int xc_domain_populate_physmap(xc_interface *xch,
uint32_t domid,
unsigned long nr_extents,
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index da0aa2f6a8..ea3df1ef31 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1090,6 +1090,17 @@ out:
 return rc;
 }
 
+int xc_domain_remove_from_physmap(xc_interface *xch,
+  uint32_t domid,
+  xen_pfn_t gpfn)
+{
+struct xen_remove_from_physmap xrfp = {
+.domid = domid,
+.gpfn = gpfn,
+};
+return do_memory_op(xch, XENMEM_remove_from_physmap, , sizeof(xrfp));
+}
+
 int xc_domain_claim_pages(xc_interface *xch,
uint32_t domid,
unsigned long nr_pages)
-- 
2.16.1


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

[Xen-devel] [PATCH v4 0/7] Allow setting up shared memory areas between VMs from xl config files

[Zhongze Liu]

Hi,

This series implements the new xl config entry proposed in [1]. Users can use
the new config entry to statically setup shared memory areas among VMs that
don't have grant table support so that they could communicate with each other
through the static shared memory areas.

After several rounds of reviews, the current design is somewhat different
from what was described in the original proposal. So please refer to the
documentation in [patch 7/7] for the current design.

[1] Proposal to allow setting up shared memory areas between VMs from xl
config file:
  https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html

v3:
  * Added the docs
  * Changed the order of patches to reflect their internal dependencies
  * Fixed the error handling when memory mapping are done but the xs
trasaction fails
  * Changed the xsm hooks to lookup the current domain themselves instead of
getting it as a parameter
v4:
  * Place the sshm info, which should not be readable by guests, under the
/libxl/static_shm xs path.
  * Add a new subop to xenmem_add_to_physmap() to support the memory sharing,
instead of modifying an old one.

Cheers,

Zhongze Liu (7):
  libxc: add xc_domain_remove_from_physmap to wrap
XENMEM_remove_from_physmap
  xen: xsm: flask: introduce XENMAPSPACE_gmfn_share for memory sharing
  libxl: introduce a new structure to represent static shared memory
regions
  libxl: support mapping static shared memory areas during domain
creation
  libxl: support unmapping static shared memory areas during domain
destruction
  libxl:xl: add parsing code to parse "libxl_static_sshm" from xl config
files
  docs: documentation about static shared memory regions

 docs/man/xl-static-shm-configuration.pod.5 | 257 +++
 docs/man/xl.cfg.pod.5.in   |   8 +
 docs/misc/xenstore-paths.markdown  |  47 +++
 tools/flask/policy/modules/xen.if  |   2 +
 tools/libxc/include/xenctrl.h  |   4 +
 tools/libxc/xc_domain.c|  11 +
 tools/libxl/Makefile   |   4 +-
 tools/libxl/libxl.h|   4 +
 tools/libxl/libxl_arch.h   |   6 +
 tools/libxl/libxl_arm.c|  15 +
 tools/libxl/libxl_create.c |  27 ++
 tools/libxl/libxl_domain.c |   5 +
 tools/libxl/libxl_internal.h   |  16 +
 tools/libxl/libxl_sshm.c   | 503 +
 tools/libxl/libxl_types.idl|  32 +-
 tools/libxl/libxl_x86.c|  19 ++
 tools/libxl/libxlu_sshm.c  | 210 
 tools/libxl/libxlutil.h|   6 +
 tools/xl/xl_parse.c|  24 +-
 xen/arch/arm/mm.c  |   8 +-
 xen/arch/x86/mm.c  |   4 +
 xen/include/public/memory.h|   4 +
 xen/include/xsm/dummy.h|   6 +
 xen/include/xsm/xsm.h  |   6 +
 xen/xsm/dummy.c|   1 +
 xen/xsm/flask/hooks.c  |   7 +
 xen/xsm/flask/policy/access_vectors|   5 +
 27 files changed, 1235 insertions(+), 6 deletions(-)
 create mode 100644 docs/man/xl-static-shm-configuration.pod.5
 create mode 100644 tools/libxl/libxl_sshm.c
 create mode 100644 tools/libxl/libxlu_sshm.c

-- 
2.16.1


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

Re: [Xen-devel] [PATCH RFC v2 12/12] x86: activate per-vcpu stacks in case of xpti

[Juergen Gross]

On 30/01/18 17:33, Jan Beulich wrote:
 On 22.01.18 at 13:32,  wrote:
>> When scheduling a vcpu subject to xpti activate the per-vcpu stacks
>> by loading the vcpu specific gdt and tss. When de-scheduling such a
>> vcpu switch back to the per physical cpu gdt and tss.
>>
>> Accessing the user registers on the stack is done via helpers as
>> depending on XPTI active or not the registers are located either on
>> the per-vcpu stack or on the default stack.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>>  xen/arch/x86/domain.c  | 76 
>> +++---
>>  xen/arch/x86/pv/domain.c   | 34 +++--
>>  xen/include/asm-x86/desc.h |  5 +++
>>  xen/include/asm-x86/regs.h |  2 +
>>  4 files changed, 107 insertions(+), 10 deletions(-)
>>
>> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
>> index da1bf1a97b..d75234ca35 100644
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -1585,9 +1585,28 @@ static inline bool need_full_gdt(const struct domain 
>> *d)
>>  return is_pv_domain(d) && !is_idle_domain(d);
>>  }
>>  
>> +static void copy_user_regs_from_stack(struct vcpu *v)
>> +{
>> +struct cpu_user_regs *stack_regs;
> 
> const

Okay.

> 
>> +stack_regs = (is_pv_vcpu(v) && v->domain->arch.pv_domain.xpti)
>> + ? v->arch.pv_vcpu.stack_regs
>> + : _cpu_info()->guest_cpu_user_regs;
> 
> Ugly open coding of what previously was guest_cpu_user_regs().

I have to make sure to address the per physical cpu stack.

> 
>> +memcpy(>arch.user_regs, stack_regs, CTXT_SWITCH_STACK_BYTES);
>> +}
>> +
>> +static void copy_user_regs_to_stack(struct vcpu *v)
> 
> const

Okay.

> 
>> @@ -1635,7 +1654,7 @@ static void __context_switch(void)
>>  
>>  gdt = !is_pv_32bit_domain(nd) ? per_cpu(gdt_table, cpu) :
>>  per_cpu(compat_gdt_table, cpu);
>> -if ( need_full_gdt(nd) )
>> +if ( need_full_gdt(nd) && !nd->arch.pv_domain.xpti )
>>  {
>>  unsigned long mfn = virt_to_mfn(gdt);
>>  l1_pgentry_t *pl1e = pv_gdt_ptes(n);
>> @@ -1647,23 +1666,68 @@ static void __context_switch(void)
>>  }
>>  
>>  if ( need_full_gdt(pd) &&
>> - ((p->vcpu_id != n->vcpu_id) || !need_full_gdt(nd)) )
>> + ((p->vcpu_id != n->vcpu_id) || !need_full_gdt(nd) ||
>> +  pd->arch.pv_domain.xpti) )
>>  {
>>  gdt_desc.limit = LAST_RESERVED_GDT_BYTE;
>>  gdt_desc.base  = (unsigned long)(gdt - FIRST_RESERVED_GDT_ENTRY);
>>  
>> +if ( pd->arch.pv_domain.xpti )
>> +_set_tssldt_type(gdt + TSS_ENTRY - FIRST_RESERVED_GDT_ENTRY,
>> + SYS_DESC_tss_avail);
> 
> Why is this not done in the if() after lgdt()?

I had some problems here when developing the patches. Just wanted to
make sure all changes of the GDT are in place before activating it.
I can move it.

> 
>>  lgdt(_desc);
>> +
>> +if ( pd->arch.pv_domain.xpti )
>> +{
>> +unsigned long stub_va = this_cpu(stubs.addr);
>> +
>> +ltr(TSS_ENTRY << 3);
>> +get_cpu_info()->flags &= ~VCPUSTACK_ACTIVE;
>> +wrmsrl(MSR_LSTAR, stub_va);
>> +wrmsrl(MSR_CSTAR, stub_va + STUB_TRAMPOLINE_SIZE_PERCPU);
>> +if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
>> + boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR )
>> +wrmsrl(MSR_IA32_SYSENTER_ESP,
>> +   (unsigned 
>> long)_cpu_info()->guest_cpu_user_regs.es);
> 
> Why is this not - like below - _cpu_user_regs()->es?

Right, this would have been possible, but I needed to move restoring the
MSRs to another place where VCPUSTACK_ACTIVE was still set, so using
guest_cpu_user_regs() would be wrong.

I'll add a comment.

> 
>> +}
>>  }
>>  
>>  write_ptbase(n);
>>  
>>  if ( need_full_gdt(nd) &&
>> - ((p->vcpu_id != n->vcpu_id) || !need_full_gdt(pd)) )
>> + ((p->vcpu_id != n->vcpu_id) || !need_full_gdt(pd) ||
>> +  nd->arch.pv_domain.xpti) )
>>  {
>>  gdt_desc.limit = LAST_RESERVED_GDT_BYTE;
>>  gdt_desc.base = GDT_VIRT_START(n);
>>  
>> +if ( nd->arch.pv_domain.xpti )
>> +{
>> +struct cpu_info *info;
>> +
>> +gdt = (struct desc_struct *)GDT_VIRT_START(n);
>> +gdt[PER_CPU_GDT_ENTRY].a = cpu;
>> +_set_tssldt_type(gdt + TSS_ENTRY, SYS_DESC_tss_avail);
>> +info = (struct cpu_info *)(XPTI_START(n) + STACK_SIZE) - 1;
>> +info->stack_bottom_cpu = (unsigned long)guest_cpu_user_regs();
>> +}
>> +
>>  lgdt(_desc);
>> +
>> +if ( nd->arch.pv_domain.xpti )
>> +{
>> +unsigned long stub_va = XPTI_TRAMPOLINE(n);
>> +
>> +ltr(TSS_ENTRY << 3);
>> +get_cpu_info()->flags |= VCPUSTACK_ACTIVE;
>> +wrmsrl(MSR_LSTAR, 

Re: [Xen-devel] [PATCH v3 1/8] ARM: VGIC: drop unneeded gic_restore_pending_irqs()

[Stefano Stabellini]

On Wed, 24 Jan 2018, Andre Przywara wrote:
> In gic_restore_pending_irqs() we push our pending virtual IRQs into the
> list registers. This function is called once from gic_inject(), just
> before we return to the guest, but also in gic_restore_state(), when
> we context-switch a VCPU. Having a closer look it turns out that the
> later call is not needed, since we will always call gic_inject() anyway.
> So remove that call (and the forward declaration) to streamline this
> interface and make separating the GIC from the VGIC world later.
> 
> Signed-off-by: Andre Przywara 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/gic.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index bac8ada2bb..721a17a9d7 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -36,8 +36,6 @@
>  #include 
>  #include 
>  
> -static void gic_restore_pending_irqs(struct vcpu *v);
> -
>  static DEFINE_PER_CPU(uint64_t, lr_mask);
>  
>  #define lr_all_full() (this_cpu(lr_mask) == ((1 << gic_hw_ops->info->nr_lrs) 
> - 1))
> @@ -91,8 +89,6 @@ void gic_restore_state(struct vcpu *v)
>  gic_hw_ops->restore_state(v);
>  
>  isb();
> -
> -gic_restore_pending_irqs(v);
>  }
>  
>  /* desc->irq needs to be disabled before calling this function */
> -- 
> 2.14.1
> 

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

Re: [Xen-devel] [PATCH RFC v2 11/12] x86: modify interrupt handlers to support stack switching

[Juergen Gross]

On 30/01/18 17:07, Jan Beulich wrote:
 On 22.01.18 at 13:32,  wrote:
>> --- a/xen/arch/x86/x86_64/asm-offsets.c
>> +++ b/xen/arch/x86/x86_64/asm-offsets.c
>> @@ -137,6 +137,10 @@ void __dummy__(void)
>>  OFFSET(CPUINFO_processor_id, struct cpu_info, processor_id);
>>  OFFSET(CPUINFO_current_vcpu, struct cpu_info, current_vcpu);
>>  OFFSET(CPUINFO_cr4, struct cpu_info, cr4);
>> +OFFSET(CPUINFO_stack_bottom_cpu, struct cpu_info, stack_bottom_cpu);
>> +OFFSET(CPUINFO_flags, struct cpu_info, flags);
>> +DEFINE(ASM_ON_VCPUSTACK, ON_VCPUSTACK);
>> +DEFINE(ASM_VCPUSTACK_ACTIVE, VCPUSTACK_ACTIVE);
> 
> Seeing their uses in asm_defns.h it's not really clear to me why
> you can't use the C constants there, the more that those uses
> are inside C macros (which perhaps would better be assembler
> ones). The latter doesn't even appear to be used in assembly
> code.

I tried using the C constants but this led to rather nasty include
dependencies.

ASM_VCPUSTACK_ACTIVE will be used when %cr3 switching is being added.

> 
>> --- a/xen/arch/x86/x86_64/compat/entry.S
>> +++ b/xen/arch/x86/x86_64/compat/entry.S
>> @@ -19,6 +19,7 @@ ENTRY(entry_int82)
>>  movl  $HYPERCALL_VECTOR, 4(%rsp)
>>  SAVE_ALL compat=1 /* DPL1 gate, restricted to 32bit PV guests only. 
>> */
>>  mov   %rsp, %rdi
>> +SWITCH_FROM_VCPU_STACK
>>  CR4_PV32_RESTORE
> 
> Once again - why for compat mode guests?
> 
>> @@ -615,7 +623,9 @@ ENTRY(early_page_fault)
>>  movl  $TRAP_page_fault,4(%rsp)
>>  SAVE_ALL
>>  movq  %rsp,%rdi
>> +SWITCH_FROM_VCPU_STACK
> 
> Why, in this context?

Same as before: consistency. I can remove this.

> 
>>  call  do_early_page_fault
>> +movq  %rsp, %rdi
>>  jmp   restore_all_xen
> 
> Doesn't this belong in an earlier patch?

I have cleaned this up already.

> 
>> --- a/xen/common/wait.c
>> +++ b/xen/common/wait.c
>> @@ -122,10 +122,10 @@ void wake_up_all(struct waitqueue_head *wq)
>>  
>>  static void __prepare_to_wait(struct waitqueue_vcpu *wqv)
>>  {
>> -struct cpu_info *cpu_info = get_cpu_info();
>> +struct cpu_user_regs *user_regs = guest_cpu_user_regs();
>>  struct vcpu *curr = current;
>>  unsigned long dummy;
>> -u32 entry_vector = cpu_info->guest_cpu_user_regs.entry_vector;
>> +u32 entry_vector = user_regs->entry_vector;
>>  
>>  ASSERT(wqv->esp == 0);
>>  
>> @@ -160,7 +160,7 @@ static void __prepare_to_wait(struct waitqueue_vcpu *wqv)
>>  "pop %%r11; pop %%r10; pop %%r9;  pop %%r8;"
>>  "pop %%rbp; pop %%rdx; pop %%rbx; pop %%rax"
>>  : "=" (wqv->esp), "=" (dummy), "=" (dummy)
>> -: "i" (PAGE_SIZE), "0" (0), "1" (cpu_info), "2" (wqv->stack)
>> +: "i" (PAGE_SIZE), "0" (0), "1" (user_regs), "2" (wqv->stack)
>>  : "memory" );
>>  
>>  if ( unlikely(wqv->esp == 0) )
>> @@ -169,7 +169,7 @@ static void __prepare_to_wait(struct waitqueue_vcpu *wqv)
>>  domain_crash_synchronous();
>>  }
>>  
>> -cpu_info->guest_cpu_user_regs.entry_vector = entry_vector;
>> +user_regs->entry_vector = entry_vector;
>>  }
> 
> I don't see how this change is related to the purpose of this patch,
> or why the change is needed. All you do is utilize that
> guest_cpu_user_regs is the first field of struct cpu_info afaics.

guest_cpu_user_regs() might point to either stack, while get_cpu_info()
will always reference the Xen stack and never the per-vcpu one.

> 
>> --- a/xen/include/asm-x86/asm_defns.h
>> +++ b/xen/include/asm-x86/asm_defns.h
>> @@ -116,6 +116,25 @@ void ret_from_intr(void);
>>  GET_STACK_END(reg);   \
>>  __GET_CURRENT(reg)
>>  
>> +#define SWITCH_FROM_VCPU_STACK   \
>> +GET_STACK_END(ax);   \
>> +testb $ASM_ON_VCPUSTACK, STACK_CPUINFO_FIELD(flags)(%rax);   \
>> +jz1f;\
>> +movq  STACK_CPUINFO_FIELD(stack_bottom_cpu)(%rax), %rsp; \
>> +1:
>> +
>> +#define SWITCH_FROM_VCPU_STACK_IST   \
>> +GET_STACK_END(ax);   \
>> +testb $ASM_ON_VCPUSTACK, STACK_CPUINFO_FIELD(flags)(%rax);   \
>> +jz1f;\
>> +subq  $(CPUINFO_sizeof - 1), %rax;   \
>> +addq  CPUINFO_stack_bottom_cpu(%rax), %rsp;  \
>> +subq  %rax, %rsp;\
> 
> If I'm not mistaken, %rsp is complete rubbish for on instruction
> here. While quite likely not a problem in practice, it would still
> feel better if you went through an intermediate register. I also
> think the calculation might then end up easier to follow. It'll also
> make analysis of 

Re: [Xen-devel] [PATCH RFC v2 10/12] x86: allocate per-vcpu stacks for interrupt entries

[Juergen Gross]

On 30/01/18 16:40, Jan Beulich wrote:
 On 22.01.18 at 13:32,  wrote:
>> In case of XPTI being active for a pv-domain allocate and initialize
>> per-vcpu stacks. The stacks are added to the per-domain mappings of
>> the pv-domain.
> 
> Considering the intended use of these stacks (as per the overview
> mail) I consider 32k per vCPU a non-negligible amount of extra memory
> use.

Maybe I can shrink this by putting multiple entry stacks into one page.
In the end I only need struct cpu_info and maybe some spare for each
stack.

> 
>> +static int pv_vcpu_init_xpti(struct vcpu *v)
>> +{
>> +struct domain *d = v->domain;
>> +struct page_info *pg;
>> +void *ptr;
>> +struct cpu_info *info;
>> +unsigned long stack_bottom;
>> +int rc;
>> +
>> +/* Populate page tables. */
>> +rc = create_perdomain_mapping(d, XPTI_START(v), STACK_PAGES,
>> +  NIL(l1_pgentry_t *), NULL);
>> +if ( rc )
>> +goto done;
>> +
>> +/* Map stacks. */
>> +rc = create_perdomain_mapping(d, XPTI_START(v), IST_MAX,
>> +  NULL, NIL(struct page_info *));
>> +if ( rc )
>> +goto done;
>> +
>> +ptr = alloc_xenheap_page();
>> +if ( !ptr )
>> +{
>> +rc = -ENOMEM;
>> +goto done;
>> +}
>> +clear_page(ptr);
>> +addmfn_to_perdomain_mapping(d, XPTI_START(v) + STACK_SIZE - PAGE_SIZE,
>> +_mfn(virt_to_mfn(ptr)));
> 
> This can't be create_perdomain_mapping() because of ...? If it's
> the Xen heap page you use here - that would be the next question:
> Does it need to be such, rather than a domheap one? I do see ...

I need to reference the user regs in __context_switch() before
switching to the new address space (otherwise I'd had to rework
__context_switch() which I wanted to avoid).

> 
>> +info = (struct cpu_info *)((unsigned long)ptr + PAGE_SIZE) - 1;
>> +info->flags = ON_VCPUSTACK;
>> +v->arch.pv_vcpu.stack_regs = >guest_cpu_user_regs;
> 
> ... this pointer, but without a clear picture on intended use it's
> hard to judge.

See patch 12.

> 
>> +/* Map TSS. */
>> +rc = create_perdomain_mapping(d, XPTI_TSS(v), 1, NULL, );
>> +if ( rc )
>> +goto done;
>> +info = (struct cpu_info *)(XPTI_START(v) + STACK_SIZE) - 1;
> 
> Iiuc this is a pointer one absolutely must not de-reference. A bit
> dangerous, I would say, the more that further up the same
> variable is being de-referenced.

Okay, I'll add another variable for this purpose.

> 
> Also I would assume the TSS can be mapped r/o.

Right.

> 
>> +stack_bottom = (unsigned long)>guest_cpu_user_regs.es;
>> +ptr = __map_domain_page(pg);
>> +tss_init(ptr, stack_bottom);
>> +unmap_domain_page(ptr);
>> +
>> +/* Map stub trampolines. */
>> +rc = create_perdomain_mapping(d, XPTI_TRAMPOLINE(v), 1, NULL, );
>> +if ( rc )
>> +goto done;
>> +ptr = __map_domain_page(pg);
>> +write_stub_trampoline((unsigned char *)ptr, XPTI_TRAMPOLINE(v),
> 
> I would be very surprised if you really needed the cast here.

Oh, this is a leftover from a previous version where ptr was char *.

> 
>> @@ -25,6 +25,21 @@
>>   */
>>  
>>  /*
>> + * The vcpu stacks used for XPTI are arranged similar to the physical cpu
>> + * stacks with some modifications. The main difference are the primary stack
>> + * size (only 1 page) and usage of the unused mappings for TSS and IDT.
>> + *
>> + * 7 - Primary stack (with a struct cpu_info at the top)
>> + * 6 - unused
>> + * 5 - TSS
> 
> Judging by the comment this might mean "TSS / IDT", or slots 4 or 6
> might be used for the IDT. Otoh I don't see any IDT related logic in
> pv_vcpu_init_xpti(). Please clarify this.

Oh yes. I'll remove the IDT related comments, as I think I can just map
the original IDT.

> 
>> @@ -37,10 +52,24 @@ struct vcpu;
>>  
>>  struct cpu_info {
>>  struct cpu_user_regs guest_cpu_user_regs;
>> -unsigned int processor_id;
>> -struct vcpu *current_vcpu;
>> -unsigned long per_cpu_offset;
>> -unsigned long cr4;
>> +union {
>> +/* per physical cpu mapping */
>> +struct {
>> +struct vcpu *current_vcpu;
>> +unsigned long per_cpu_offset;
>> +unsigned long cr4;
>> +};
>> +/* per vcpu mapping (xpti) */
>> +struct {
>> +unsigned long pad1;
>> +unsigned long pad2;
>> +unsigned long stack_bottom_cpu;
>> +};
> 
> In order to avoid accidental use in the wrong context as much as
> possible, I think you want to name both structures.

Okay.


Juergen

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

Re: [Xen-devel] [PATCH 0/3] xen/arm: Inject an exception to the guest rather than crashing it

[Julien Grall]

On 30/01/18 16:38, Andrew Cooper wrote:

On 30/01/18 16:14, Julien Grall wrote:

Hi all,

This small series replaces all call to domain_crash_synchronous by injecting
an exception to the guest.

This will result to a nicer trace from the guest (no need to manually walk
the stack) and give a chance to the guest to give a bit more information on
what it was doing.

Cheers,

Julien Grall (3):
   xen/arm: io: Distinguish unhandled IO from aborted one
   xen/arm: Don't crash domain on bad MMIO emulation
   xen/arm: Don't crash the domain on invalid HVC immediate


Thanks.

I don't feel qualified to review these, but some notes.

Patch 1.  s/avodi/avoid/ in the commit message

Patches 2 and 3.  You probably want to convert the printks to
gdprintk()s, otherwise guests can choke up the ratelimited log.  Doing
so will also mean that the vcpu will be identified consistently, which
it isn't currently.
We didn't use g*printk because it would be more confusing to print the 
current vCPU in some cases (e.g when accessing the re-distributor of 
another vCPU) or does not matter (e.g for ITS).


The problem with the debug version is those information are actually 
quite useful in non-debug build. We found quite a few issues thanks to them.


I think it would make more sense for Xen to provide per-guest 
ratelimited than hiding those messages in non-debug build.




~Andrew



--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC v2 06/12] x86: add a xpti command line parameter

[Juergen Gross]

On 30/01/18 16:39, Jan Beulich wrote:
 On 22.01.18 at 13:32,  wrote:
>> @@ -212,6 +249,24 @@ int pv_domain_initialise(struct domain *d, unsigned int 
>> domcr_flags,
>>  /* 64-bit PV guest by default. */
>>  d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
>>  
>> +switch (opt_xpti)
> 
> Style.
> 
>> +{
>> +case XPTI_OFF:
>> +d->arch.pv_domain.xpti = false;
>> +break;
>> +case XPTI_ON:
>> +d->arch.pv_domain.xpti = true;
>> +break;
>> +case XPTI_NODOM0:
>> +d->arch.pv_domain.xpti = boot_cpu_data.x86_vendor != X86_VENDOR_AMD 
>> &&
>> + d->domain_id != 0 &&
>> + d->domain_id != hardware_domid;
>> +break;
>> +case XPTI_DEFAULT:
>> +d->arch.pv_domain.xpti = boot_cpu_data.x86_vendor != X86_VENDOR_AMD;
>> +break;
>> +}
> 
> Why does a 32-bit domain need this?

It doesn't. In my current version I have moved this initialization and
it will never run for 32 bit domains.


Juergen

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

Re: [Xen-devel] [PATCH RFC v2 09/12] x86: enhance syscall stub to work in per-domain mapping

[Juergen Gross]

On 30/01/18 16:11, Jan Beulich wrote:
 On 22.01.18 at 13:32,  wrote:
>> --- a/xen/arch/x86/x86_64/traps.c
>> +++ b/xen/arch/x86/x86_64/traps.c
>> @@ -260,10 +260,11 @@ void do_double_fault(struct cpu_user_regs *regs)
>>  panic("DOUBLE FAULT -- system shutdown");
>>  }
>>  
>> -static unsigned int write_stub_trampoline(
>> -unsigned char *stub, unsigned long stub_va,
>> -unsigned long stack_bottom, unsigned long target_va)
>> +void write_stub_trampoline(unsigned char *stub, unsigned long stub_va,
>> +   unsigned long stack_bottom, unsigned long 
>> target_va)
> 
> Why does the static go away?

I'll need it in patch 10.

> 
>> @@ -282,24 +283,32 @@ static unsigned int write_stub_trampoline(
>>  /* pushq %rax */
>>  stub[23] = 0x50;
>>  
>> -/* jmp target_va */
>> -stub[24] = 0xe9;
>> -*(int32_t *)[25] = target_va - (stub_va + 29);
>> -
>> -/* Round up to a multiple of 16 bytes. */
>> -return 32;
>> +target_diff = target_va - (stub_va + 29);
>> +if ( target_diff >> 31 == target_diff >> 63 )
>> +{
>> +/* jmp target_va */
>> +stub[24] = 0xe9;
>> +*(int32_t *)[25] = target_diff;
>> +}
>> +else
>> +{
>> +/* movabs target_va, %rax */
>> +stub[24] = 0x48;
>> +stub[25] = 0xb8;
>> +*(uint64_t *)[26] = target_va;
>> +/* jmpq *%rax */
>> +stub[34] = 0xff;
>> +stub[35] = 0xe0;
>> +}
> 
> This clearly needs another solution, as you'd have to go through a
> thunk now, and the thunk would be unreachable too.

Aah, right. So maybe it would be better not to share the code for
writing the stub page with XPTI.

I'll replace this patch with one adding a new function for XPTI.


Juergen

> 
>>  }
>>  
>>  DEFINE_PER_CPU(struct stubs, stubs);
>> -void lstar_enter(void);
>> -void cstar_enter(void);
> 
> Why do these move into a header?
> 
>> @@ -312,10 +321,9 @@ void subarch_percpu_traps_init(void)
>>   * start of the stubs.
>>   */
>>  wrmsrl(MSR_LSTAR, stub_va);
>> -offset = write_stub_trampoline(stub_page + (stub_va & ~PAGE_MASK),
>> -   stub_va, stack_bottom,
>> -   (unsigned long)lstar_enter);
>> -stub_va += offset;
>> +write_stub_trampoline(stub_page + (stub_va & ~PAGE_MASK), stub_va,
>> +  stack_bottom, (unsigned long)lstar_enter);
>> +stub_va += STUB_TRAMPOLINE_SIZE_PERCPU;
> 
> The function may have written more than 32 bytes now; you'd
> notice the breakage if you put a suitable BUILD_BUG_ON() into
> the function. Otherwise I recommend you stick to the current
> "return number of bytes written" model.
> 
>> @@ -328,12 +336,11 @@ void subarch_percpu_traps_init(void)
>>  
>>  /* Trampoline for SYSCALL entry from compatibility mode. */
>>  wrmsrl(MSR_CSTAR, stub_va);
>> -offset += write_stub_trampoline(stub_page + (stub_va & ~PAGE_MASK),
>> -stub_va, stack_bottom,
>> -(unsigned long)cstar_enter);
>> +write_stub_trampoline(stub_page + (stub_va & ~PAGE_MASK), stub_va,
>> +  stack_bottom, (unsigned long)cstar_enter);
>>  
>>  /* Don't consume more than half of the stub space here. */
>> -ASSERT(offset <= STUB_BUF_SIZE / 2);
>> +ASSERT(2 * STUB_TRAMPOLINE_SIZE_PERCPU <= STUB_BUF_SIZE / 2);
> 
> BUILD_BUG_ON() for compile time constants.
> 
> Jan
> 


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

Re: [Xen-devel] [PATCH 0/3] xen/arm: Inject an exception to the guest rather than crashing it

[Andrew Cooper]

On 30/01/18 16:14, Julien Grall wrote:
> Hi all,
>
> This small series replaces all call to domain_crash_synchronous by injecting
> an exception to the guest.
>
> This will result to a nicer trace from the guest (no need to manually walk
> the stack) and give a chance to the guest to give a bit more information on
> what it was doing.
>
> Cheers,
>
> Julien Grall (3):
>   xen/arm: io: Distinguish unhandled IO from aborted one
>   xen/arm: Don't crash domain on bad MMIO emulation
>   xen/arm: Don't crash the domain on invalid HVC immediate

Thanks.

I don't feel qualified to review these, but some notes.

Patch 1.  s/avodi/avoid/ in the commit message

Patches 2 and 3.  You probably want to convert the printks to
gdprintk()s, otherwise guests can choke up the ratelimited log.  Doing
so will also mean that the vcpu will be identified consistently, which
it isn't currently.

~Andrew

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

Re: [Xen-devel] [PATCH RFC v2 05/12] x86: don't access saved user regs via rsp in trap handlers

[Juergen Gross]

On 30/01/18 15:49, Jan Beulich wrote:
 On 22.01.18 at 13:32,  wrote:
>> In order to support switching stacks when entering the hypervisor for
>> support of page table isolation, don't use %rsp for accessing the
>> saved user registers, but do that via %rdi.
> 
> If this really turns out to be necessary ...
> 
>> @@ -58,20 +58,24 @@ compat_test_guest_events:
>>  jmp   compat_test_all_events
>>  
>>  ALIGN
>> -/* %rbx: struct vcpu */
>> +/* %rbx: struct vcpu, %rdi: user_regs */
>>  compat_process_softirqs:
>>  sti
>> +pushq %rdi
>>  call  do_softirq
>> +popq  %rdi
>>  jmp   compat_test_all_events
> 
> ... to avoid changes like this one (which unduly affect stack
> alignment) you will want to consider using e.g. %r12 instead.

Right. I have this already on my agenda for the next version of the
patches.

> But concerning specifically the compat entry code, it's unclear to
> me why you'd need to switch stacks there too.

That was just for consistency. I can drop that if you prefer.

> 
>> @@ -211,13 +218,15 @@ ENTRY(cstar_enter)
>>  testl $~3,%esi
>>  leal  (,%rcx,TBF_INTERRUPT),%ecx
>>  UNLIKELY_START(z, compat_syscall_gpf)
>> -movq  VCPU_trap_ctxt(%rbx),%rdi
>> -movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
>> -subl  $2,UREGS_rip(%rsp)
>> +pushq %rcx
>> +movq  VCPU_trap_ctxt(%rbx),%rcx
>> +movl  $TRAP_gp_fault,UREGS_entry_vector(%rdi)
>> +subl  $2,UREGS_rip(%rdi)
>>  movl  $0,TRAPBOUNCE_error_code(%rdx)
>> -movl  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rdi),%eax
>> -movzwl TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_cs(%rdi),%esi
>> -testb $4,TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_flags(%rdi)
>> +movl  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rcx),%eax
>> +movzwl TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_cs(%rcx),%esi
>> +testb $4,TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_flags(%rcx)
>> +popq  %rcx
> 
> Is there really no register available, requiring you to push/pop
> %rcx here?

With switching from %rdi to e.g. %r12 this is no longer an issue.

> 
>> --- a/xen/include/asm-x86/current.h
>> +++ b/xen/include/asm-x86/current.h
>> @@ -95,9 +95,13 @@ unsigned long get_stack_dump_bottom (unsigned long sp);
>>  ({  \
>>  __asm__ __volatile__ (  \
>>  "mov %0,%%"__OP"sp;"\
>> -CHECK_FOR_LIVEPATCH_WORK  \
>> - "jmp %c1"  \
>> -: : "r" (guest_cpu_user_regs()), "i" (__fn) : "memory" );   \
>> +"mov %1,%%"__OP"di;"\
>> +"pushq %%"__OP"di;" \
>> +CHECK_FOR_LIVEPATCH_WORK\
>> +"popq %%"__OP"di;"  \
>> +"jmp %c2"   \
>> +: : "r" (get_cpu_info()), "r" (guest_cpu_user_regs()),  \
>> +"i" (__fn) : "memory" );\
>>  unreachable();  \
>>  })
> 
> If you want guest_cpu_user_regs() in %rdi, why don't you use
> "D" as constraint? Why do you need to restore %rdi prior to the
> final JMP? And why do you need the value in %rdi before calling
> check_for_livepatch_work(), when the function takes no arguments?

Will change.


Juergen


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

Re: [Xen-devel] [PATCH RFC v2 12/12] x86: activate per-vcpu stacks in case of xpti

[Jan Beulich]

>>> On 22.01.18 at 13:32,  wrote:
> When scheduling a vcpu subject to xpti activate the per-vcpu stacks
> by loading the vcpu specific gdt and tss. When de-scheduling such a
> vcpu switch back to the per physical cpu gdt and tss.
> 
> Accessing the user registers on the stack is done via helpers as
> depending on XPTI active or not the registers are located either on
> the per-vcpu stack or on the default stack.
> 
> Signed-off-by: Juergen Gross 
> ---
>  xen/arch/x86/domain.c  | 76 
> +++---
>  xen/arch/x86/pv/domain.c   | 34 +++--
>  xen/include/asm-x86/desc.h |  5 +++
>  xen/include/asm-x86/regs.h |  2 +
>  4 files changed, 107 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index da1bf1a97b..d75234ca35 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -1585,9 +1585,28 @@ static inline bool need_full_gdt(const struct domain 
> *d)
>  return is_pv_domain(d) && !is_idle_domain(d);
>  }
>  
> +static void copy_user_regs_from_stack(struct vcpu *v)
> +{
> +struct cpu_user_regs *stack_regs;

const

> +stack_regs = (is_pv_vcpu(v) && v->domain->arch.pv_domain.xpti)
> + ? v->arch.pv_vcpu.stack_regs
> + : _cpu_info()->guest_cpu_user_regs;

Ugly open coding of what previously was guest_cpu_user_regs().

> +memcpy(>arch.user_regs, stack_regs, CTXT_SWITCH_STACK_BYTES);
> +}
> +
> +static void copy_user_regs_to_stack(struct vcpu *v)

const

> @@ -1635,7 +1654,7 @@ static void __context_switch(void)
>  
>  gdt = !is_pv_32bit_domain(nd) ? per_cpu(gdt_table, cpu) :
>  per_cpu(compat_gdt_table, cpu);
> -if ( need_full_gdt(nd) )
> +if ( need_full_gdt(nd) && !nd->arch.pv_domain.xpti )
>  {
>  unsigned long mfn = virt_to_mfn(gdt);
>  l1_pgentry_t *pl1e = pv_gdt_ptes(n);
> @@ -1647,23 +1666,68 @@ static void __context_switch(void)
>  }
>  
>  if ( need_full_gdt(pd) &&
> - ((p->vcpu_id != n->vcpu_id) || !need_full_gdt(nd)) )
> + ((p->vcpu_id != n->vcpu_id) || !need_full_gdt(nd) ||
> +  pd->arch.pv_domain.xpti) )
>  {
>  gdt_desc.limit = LAST_RESERVED_GDT_BYTE;
>  gdt_desc.base  = (unsigned long)(gdt - FIRST_RESERVED_GDT_ENTRY);
>  
> +if ( pd->arch.pv_domain.xpti )
> +_set_tssldt_type(gdt + TSS_ENTRY - FIRST_RESERVED_GDT_ENTRY,
> + SYS_DESC_tss_avail);

Why is this not done in the if() after lgdt()?

>  lgdt(_desc);
> +
> +if ( pd->arch.pv_domain.xpti )
> +{
> +unsigned long stub_va = this_cpu(stubs.addr);
> +
> +ltr(TSS_ENTRY << 3);
> +get_cpu_info()->flags &= ~VCPUSTACK_ACTIVE;
> +wrmsrl(MSR_LSTAR, stub_va);
> +wrmsrl(MSR_CSTAR, stub_va + STUB_TRAMPOLINE_SIZE_PERCPU);
> +if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
> + boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR )
> +wrmsrl(MSR_IA32_SYSENTER_ESP,
> +   (unsigned 
> long)_cpu_info()->guest_cpu_user_regs.es);

Why is this not - like below - _cpu_user_regs()->es?

> +}
>  }
>  
>  write_ptbase(n);
>  
>  if ( need_full_gdt(nd) &&
> - ((p->vcpu_id != n->vcpu_id) || !need_full_gdt(pd)) )
> + ((p->vcpu_id != n->vcpu_id) || !need_full_gdt(pd) ||
> +  nd->arch.pv_domain.xpti) )
>  {
>  gdt_desc.limit = LAST_RESERVED_GDT_BYTE;
>  gdt_desc.base = GDT_VIRT_START(n);
>  
> +if ( nd->arch.pv_domain.xpti )
> +{
> +struct cpu_info *info;
> +
> +gdt = (struct desc_struct *)GDT_VIRT_START(n);
> +gdt[PER_CPU_GDT_ENTRY].a = cpu;
> +_set_tssldt_type(gdt + TSS_ENTRY, SYS_DESC_tss_avail);
> +info = (struct cpu_info *)(XPTI_START(n) + STACK_SIZE) - 1;
> +info->stack_bottom_cpu = (unsigned long)guest_cpu_user_regs();
> +}
> +
>  lgdt(_desc);
> +
> +if ( nd->arch.pv_domain.xpti )
> +{
> +unsigned long stub_va = XPTI_TRAMPOLINE(n);
> +
> +ltr(TSS_ENTRY << 3);
> +get_cpu_info()->flags |= VCPUSTACK_ACTIVE;
> +wrmsrl(MSR_LSTAR, stub_va);
> +wrmsrl(MSR_CSTAR, stub_va + STUB_TRAMPOLINE_SIZE_PERVCPU);
> +if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
> + boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR )
> +wrmsrl(MSR_IA32_SYSENTER_ESP,
> +   (unsigned long)_cpu_user_regs()->es);
> +}

So on a switch from PV to PV you add two LTR and 6 WRMSR. Quite
a lot, and I'm not at all convinced that this double writing is all really
needed in such a case.

> --- a/xen/arch/x86/pv/domain.c
> +++ b/xen/arch/x86/pv/domain.c
> @@ -133,10 +133,36 @@ int 

[Xen-devel] [PATCH 1/3] xen/arm: io: Distinguish unhandled IO from aborted one

[Julien Grall]

Currently, Xen is considering that an IO could either be handled or
unhandled. When unhandled, the stage-2 abort function will try another
way to resolve the abort.

However, the MMIO emulation may return unhandled when the address
belongs to an emulated range but was not correct. In that case, Xen
should avodi to try another way and directly inject a guest data abort.

Introduce a tri-state return to distinguish the following state:
* IO_ABORT: The IO was handled but resulted to an abort
* IO_HANDLED: The IO was handled
* IO_UNHANDLED: The IO was unhandled

For now, it is considered that an IO belonging to an emulated range
could either be handled or inject an abort. This could be revisit in the
future if overlapped region exist (or we want to try another way to
resolve the abort).

Signed-off-by: Julien Grall 
---
 xen/arch/arm/io.c  | 24 ++--
 xen/arch/arm/traps.c   | 34 +++---
 xen/include/asm-arm/mmio.h |  9 -
 3 files changed, 45 insertions(+), 22 deletions(-)

diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index c748d8f5bf..a74ec21b86 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -23,8 +23,9 @@
 #include 
 #include 
 
-static int handle_read(const struct mmio_handler *handler, struct vcpu *v,
-   mmio_info_t *info)
+static enum io_state handle_read(const struct mmio_handler *handler,
+ struct vcpu *v,
+ mmio_info_t *info)
 {
 const struct hsr_dabt dabt = info->dabt;
 struct cpu_user_regs *regs = guest_cpu_user_regs();
@@ -37,7 +38,7 @@ static int handle_read(const struct mmio_handler *handler, 
struct vcpu *v,
 uint8_t size = (1 << dabt.size) * 8;
 
 if ( !handler->ops->read(v, info, , handler->priv) )
-return 0;
+return IO_ABORT;
 
 /*
  * Sign extend if required.
@@ -57,17 +58,20 @@ static int handle_read(const struct mmio_handler *handler, 
struct vcpu *v,
 
 set_user_reg(regs, dabt.reg, r);
 
-return 1;
+return IO_HANDLED;
 }
 
-static int handle_write(const struct mmio_handler *handler, struct vcpu *v,
-mmio_info_t *info)
+static enum io_state handle_write(const struct mmio_handler *handler,
+  struct vcpu *v,
+  mmio_info_t *info)
 {
 const struct hsr_dabt dabt = info->dabt;
 struct cpu_user_regs *regs = guest_cpu_user_regs();
+int ret;
 
-return handler->ops->write(v, info, get_user_reg(regs, dabt.reg),
-   handler->priv);
+ret = handler->ops->write(v, info, get_user_reg(regs, dabt.reg),
+  handler->priv);
+return ( ret ) ? IO_HANDLED : IO_ABORT;
 }
 
 /* This function assumes that mmio regions are not overlapped */
@@ -100,14 +104,14 @@ static const struct mmio_handler 
*find_mmio_handler(struct domain *d,
 return handler;
 }
 
-int handle_mmio(mmio_info_t *info)
+enum io_state handle_mmio(mmio_info_t *info)
 {
 struct vcpu *v = current;
 const struct mmio_handler *handler = NULL;
 
 handler = find_mmio_handler(v->domain, info->gpa);
 if ( !handler )
-return 0;
+return IO_UNHANDLED;
 
 if ( info->dabt.write )
 return handle_write(handler, v, info);
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index c8534d6cff..843adf4959 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1864,10 +1864,10 @@ static inline bool hpfar_is_valid(bool s1ptw, uint8_t 
fsc)
 return s1ptw || (fsc == FSC_FLT_TRANS && !check_workaround_834220());
 }
 
-static bool try_handle_mmio(struct cpu_user_regs *regs,
-const union hsr hsr,
-paddr_t gpa)
-{
+static enum io_state try_handle_mmio(struct cpu_user_regs *regs,
+ const union hsr hsr,
+ paddr_t gpa)
+ {
 const struct hsr_dabt dabt = hsr.dabt;
 mmio_info_t info = {
 .gpa = gpa,
@@ -1879,11 +1879,11 @@ static bool try_handle_mmio(struct cpu_user_regs *regs,
 
 /* stage-1 page table should never live in an emulated MMIO region */
 if ( dabt.s1ptw )
-return false;
+return IO_UNHANDLED;
 
 /* All the instructions used on emulated MMIO region should be valid */
 if ( !dabt.valid )
-return false;
+return IO_UNHANDLED;
 
 /*
  * Erratum 766422: Thumb store translation fault to Hypervisor may
@@ -1896,11 +1896,11 @@ static bool try_handle_mmio(struct cpu_user_regs *regs,
 if ( rc )
 {
 gprintk(XENLOG_DEBUG, "Unable to decode instruction\n");
-return false;
+return IO_ABORT;
 }
 }
 
-return !!handle_mmio();
+return handle_mmio();
 }
 
 /*
@@ -2005,10 +2005,21 @@ static void do_trap_stage2_abort_guest(struct 
cpu_user_regs 

[Xen-devel] [PATCH 2/3] xen/arm: Don't crash domain on bad MMIO emulation

[Julien Grall]

Now the MMIO emulation is able to distinguish unhandled IO from aborted
one, there are no need to crash the domain when the region is access
with a bad width.

Instead let Xen inject a data abort to the guest and decide what to do.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/vgic-v2.c | 2 --
 xen/arch/arm/vgic-v3-its.c | 3 ---
 xen/arch/arm/vgic-v3.c | 8 
 xen/arch/arm/vpl011.c  | 2 --
 4 files changed, 15 deletions(-)

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 2bdb25261a..646d1f3d12 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -348,7 +348,6 @@ static int vgic_v2_distr_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 bad_width:
 printk(XENLOG_G_ERR "%pv: vGICD: bad read width %d r%d offset %#08x\n",
v, dabt.size, dabt.reg, gicd_reg);
-domain_crash_synchronous();
 return 0;
 
 read_as_zero_32:
@@ -613,7 +612,6 @@ bad_width:
 printk(XENLOG_G_ERR
"%pv: vGICD: bad write width %d r%d=%"PRIregister" offset %#08x\n",
v, dabt.size, dabt.reg, r, gicd_reg);
-domain_crash_synchronous();
 return 0;
 
 write_ignore_32:
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index d8fa44258d..32061c6b03 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -1136,7 +1136,6 @@ read_reserved:
 bad_width:
 printk(XENLOG_G_ERR "vGITS: bad read width %d r%d offset %#04lx\n",
info->dabt.size, info->dabt.reg, (unsigned long)info->gpa & 0x);
-domain_crash_synchronous();
 
 return 0;
 }
@@ -1446,8 +1445,6 @@ bad_width:
 printk(XENLOG_G_ERR "vGITS: bad write width %d r%d offset %#08lx\n",
info->dabt.size, info->dabt.reg, (unsigned long)info->gpa & 0x);
 
-domain_crash_synchronous();
-
 return 0;
 }
 
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index af16dfd005..2ad8a6be62 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -328,7 +328,6 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 bad_width:
 printk(XENLOG_G_ERR "%pv vGICR: bad read width %d r%d offset %#08x\n",
v, dabt.size, dabt.reg, gicr_reg);
-domain_crash_synchronous();
 return 0;
 
 read_as_zero_64:
@@ -648,7 +647,6 @@ bad_width:
 printk(XENLOG_G_ERR
   "%pv: vGICR: bad write width %d r%d=%"PRIregister" offset %#08x\n",
   v, dabt.size, dabt.reg, r, gicr_reg);
-domain_crash_synchronous();
 return 0;
 
 write_ignore_64:
@@ -760,7 +758,6 @@ static int __vgic_v3_distr_common_mmio_read(const char 
*name, struct vcpu *v,
 bad_width:
 printk(XENLOG_G_ERR "%pv: %s: bad read width %d r%d offset %#08x\n",
v, name, dabt.size, dabt.reg, reg);
-domain_crash_synchronous();
 return 0;
 
 read_as_zero:
@@ -876,7 +873,6 @@ bad_width:
 printk(XENLOG_G_ERR
"%pv: %s: bad write width %d r%d=%"PRIregister" offset %#08x\n",
v, name, dabt.size, dabt.reg, r, reg);
-domain_crash_synchronous();
 return 0;
 
 write_ignore_32:
@@ -937,7 +933,6 @@ static int vgic_v3_rdistr_sgi_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 bad_width:
 printk(XENLOG_G_ERR "%pv: vGICR: SGI: bad read width %d r%d offset 
%#08x\n",
v, dabt.size, dabt.reg, gicr_reg);
-domain_crash_synchronous();
 return 0;
 
 read_as_zero_32:
@@ -1017,7 +1012,6 @@ bad_width:
 printk(XENLOG_G_ERR
"%pv: vGICR: SGI: bad write width %d r%d=%"PRIregister" offset 
%#08x\n",
v, dabt.size, dabt.reg, r, gicr_reg);
-domain_crash_synchronous();
 return 0;
 
 write_ignore_32:
@@ -1268,7 +1262,6 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 bad_width:
 printk(XENLOG_G_ERR "%pv: vGICD: bad read width %d r%d offset %#08x\n",
v, dabt.size, dabt.reg, gicd_reg);
-domain_crash_synchronous();
 return 0;
 
 read_as_zero_32:
@@ -1456,7 +1449,6 @@ bad_width:
 printk(XENLOG_G_ERR
"%pv: vGICD: bad write width %d r%d=%"PRIregister" offset %#08x\n",
v, dabt.size, dabt.reg, r, gicd_reg);
-domain_crash_synchronous();
 return 0;
 
 write_ignore_32:
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 725b2e03ad..7788c2fc32 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -296,7 +296,6 @@ static int vpl011_mmio_read(struct vcpu *v,
 bad_width:
 gprintk(XENLOG_ERR, "vpl011: bad read width %d r%d offset %#08x\n",
 dabt.size, dabt.reg, vpl011_reg);
-domain_crash_synchronous();
 return 0;
 
 }
@@ -366,7 +365,6 @@ write_ignore:
 bad_width:
 gprintk(XENLOG_ERR, "vpl011: bad write width %d r%d offset %#08x\n",
 dabt.size, dabt.reg, vpl011_reg);
-domain_crash_synchronous();
 return 0;
 
 }
-- 
2.11.0


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

[Xen-devel] [PATCH 3/3] xen/arm: Don't crash the domain on invalid HVC immediate

[Julien Grall]

domain_crash_synchronous() should only be used when something went wrong
in Xen. It is better to inject to the guest as it will be in better
position to provide helpful information (stack trace...).

Signed-off-by: Julien Grall 

---

We potentially want to return -1 instead. This would make Xen more
future-proof if we decide to implement the other HVC immediate.
---
 xen/arch/arm/traps.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 843adf4959..18da45dff3 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1473,14 +1473,17 @@ static void do_debug_trap(struct cpu_user_regs *regs, 
unsigned int code)
 #endif
 
 static void do_trap_hypercall(struct cpu_user_regs *regs, register_t *nr,
-  unsigned long iss)
+  const union hsr hsr)
 {
 arm_hypercall_fn_t call = NULL;
 
 BUILD_BUG_ON(NR_hypercalls < ARRAY_SIZE(arm_hypercall_table) );
 
-if ( iss != XEN_HYPERCALL_TAG )
-domain_crash_synchronous();
+if ( hsr.iss != XEN_HYPERCALL_TAG )
+{
+gprintk(XENLOG_WARNING, "Invalid HVC imm 0x%x\n", hsr.iss);
+return inject_undef_exception(regs, hsr);
+}
 
 if ( *nr >= ARRAY_SIZE(arm_hypercall_table) )
 {
@@ -2150,7 +2153,7 @@ void do_trap_guest_sync(struct cpu_user_regs *regs)
 if ( hsr.iss == 0 )
 return do_trap_hvc_smccc(regs);
 nr = regs->r12;
-do_trap_hypercall(regs, , hsr.iss);
+do_trap_hypercall(regs, , hsr);
 regs->r12 = (uint32_t)nr;
 break;
 }
@@ -2164,7 +2167,7 @@ void do_trap_guest_sync(struct cpu_user_regs *regs)
 #endif
 if ( hsr.iss == 0 )
 return do_trap_hvc_smccc(regs);
-do_trap_hypercall(regs, >x16, hsr.iss);
+do_trap_hypercall(regs, >x16, hsr);
 break;
 case HSR_EC_SMC64:
 /*
-- 
2.11.0


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

[Xen-devel] [PATCH 0/3] xen/arm: Inject an exception to the guest rather than crashing it

[Julien Grall]

Hi all,

This small series replaces all call to domain_crash_synchronous by injecting
an exception to the guest.

This will result to a nicer trace from the guest (no need to manually walk
the stack) and give a chance to the guest to give a bit more information on
what it was doing.

Cheers,

Julien Grall (3):
  xen/arm: io: Distinguish unhandled IO from aborted one
  xen/arm: Don't crash domain on bad MMIO emulation
  xen/arm: Don't crash the domain on invalid HVC immediate

 xen/arch/arm/io.c  | 24 +--
 xen/arch/arm/traps.c   | 47 ++
 xen/arch/arm/vgic-v2.c |  2 --
 xen/arch/arm/vgic-v3-its.c |  3 ---
 xen/arch/arm/vgic-v3.c |  8 
 xen/arch/arm/vpl011.c  |  2 --
 xen/include/asm-arm/mmio.h |  9 -
 7 files changed, 53 insertions(+), 42 deletions(-)

-- 
2.11.0


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

Re: [Xen-devel] [PATCH RFC v2 11/12] x86: modify interrupt handlers to support stack switching

[Jan Beulich]

>>> On 22.01.18 at 13:32,  wrote:
> --- a/xen/arch/x86/x86_64/asm-offsets.c
> +++ b/xen/arch/x86/x86_64/asm-offsets.c
> @@ -137,6 +137,10 @@ void __dummy__(void)
>  OFFSET(CPUINFO_processor_id, struct cpu_info, processor_id);
>  OFFSET(CPUINFO_current_vcpu, struct cpu_info, current_vcpu);
>  OFFSET(CPUINFO_cr4, struct cpu_info, cr4);
> +OFFSET(CPUINFO_stack_bottom_cpu, struct cpu_info, stack_bottom_cpu);
> +OFFSET(CPUINFO_flags, struct cpu_info, flags);
> +DEFINE(ASM_ON_VCPUSTACK, ON_VCPUSTACK);
> +DEFINE(ASM_VCPUSTACK_ACTIVE, VCPUSTACK_ACTIVE);

Seeing their uses in asm_defns.h it's not really clear to me why
you can't use the C constants there, the more that those uses
are inside C macros (which perhaps would better be assembler
ones). The latter doesn't even appear to be used in assembly
code.

> --- a/xen/arch/x86/x86_64/compat/entry.S
> +++ b/xen/arch/x86/x86_64/compat/entry.S
> @@ -19,6 +19,7 @@ ENTRY(entry_int82)
>  movl  $HYPERCALL_VECTOR, 4(%rsp)
>  SAVE_ALL compat=1 /* DPL1 gate, restricted to 32bit PV guests only. 
> */
>  mov   %rsp, %rdi
> +SWITCH_FROM_VCPU_STACK
>  CR4_PV32_RESTORE

Once again - why for compat mode guests?

> @@ -615,7 +623,9 @@ ENTRY(early_page_fault)
>  movl  $TRAP_page_fault,4(%rsp)
>  SAVE_ALL
>  movq  %rsp,%rdi
> +SWITCH_FROM_VCPU_STACK

Why, in this context?

>  call  do_early_page_fault
> +movq  %rsp, %rdi
>  jmp   restore_all_xen

Doesn't this belong in an earlier patch?

> --- a/xen/common/wait.c
> +++ b/xen/common/wait.c
> @@ -122,10 +122,10 @@ void wake_up_all(struct waitqueue_head *wq)
>  
>  static void __prepare_to_wait(struct waitqueue_vcpu *wqv)
>  {
> -struct cpu_info *cpu_info = get_cpu_info();
> +struct cpu_user_regs *user_regs = guest_cpu_user_regs();
>  struct vcpu *curr = current;
>  unsigned long dummy;
> -u32 entry_vector = cpu_info->guest_cpu_user_regs.entry_vector;
> +u32 entry_vector = user_regs->entry_vector;
>  
>  ASSERT(wqv->esp == 0);
>  
> @@ -160,7 +160,7 @@ static void __prepare_to_wait(struct waitqueue_vcpu *wqv)
>  "pop %%r11; pop %%r10; pop %%r9;  pop %%r8;"
>  "pop %%rbp; pop %%rdx; pop %%rbx; pop %%rax"
>  : "=" (wqv->esp), "=" (dummy), "=" (dummy)
> -: "i" (PAGE_SIZE), "0" (0), "1" (cpu_info), "2" (wqv->stack)
> +: "i" (PAGE_SIZE), "0" (0), "1" (user_regs), "2" (wqv->stack)
>  : "memory" );
>  
>  if ( unlikely(wqv->esp == 0) )
> @@ -169,7 +169,7 @@ static void __prepare_to_wait(struct waitqueue_vcpu *wqv)
>  domain_crash_synchronous();
>  }
>  
> -cpu_info->guest_cpu_user_regs.entry_vector = entry_vector;
> +user_regs->entry_vector = entry_vector;
>  }

I don't see how this change is related to the purpose of this patch,
or why the change is needed. All you do is utilize that
guest_cpu_user_regs is the first field of struct cpu_info afaics.

> --- a/xen/include/asm-x86/asm_defns.h
> +++ b/xen/include/asm-x86/asm_defns.h
> @@ -116,6 +116,25 @@ void ret_from_intr(void);
>  GET_STACK_END(reg);   \
>  __GET_CURRENT(reg)
>  
> +#define SWITCH_FROM_VCPU_STACK   \
> +GET_STACK_END(ax);   \
> +testb $ASM_ON_VCPUSTACK, STACK_CPUINFO_FIELD(flags)(%rax);   \
> +jz1f;\
> +movq  STACK_CPUINFO_FIELD(stack_bottom_cpu)(%rax), %rsp; \
> +1:
> +
> +#define SWITCH_FROM_VCPU_STACK_IST   \
> +GET_STACK_END(ax);   \
> +testb $ASM_ON_VCPUSTACK, STACK_CPUINFO_FIELD(flags)(%rax);   \
> +jz1f;\
> +subq  $(CPUINFO_sizeof - 1), %rax;   \
> +addq  CPUINFO_stack_bottom_cpu(%rax), %rsp;  \
> +subq  %rax, %rsp;\

If I'm not mistaken, %rsp is complete rubbish for on instruction
here. While quite likely not a problem in practice, it would still
feel better if you went through an intermediate register. I also
think the calculation might then end up easier to follow. It'll also
make analysis of a crash easier if an NMI or #MC hits exactly at
this boundary.

> +1:
> +
> +#define SWITCH_TO_VCPU_STACK \
> +movq  %rdi, %rsp

For these additions as a whole: At least in new pieces of code
please avoid insn suffixes when they're redundant with registers
used.

> @@ -94,9 +95,16 @@ static inline struct cpu_info *get_cpu_info(void)
>  #define set_processor_id(id)  do {  \
>  struct cpu_info *ci__ = get_cpu_info(); \
> 

[Xen-devel] Changes to Outreachy program : need URGENT input from mentors (was Re: Preparing for GSoC and Outreachy )

[Lars Kurth]

Hi all, (mentors on CC list)

a quick note that there are significant changes to Outreachy this year, which 
in my view will make it a little harder to participate.

Namely
* This round, instead of having communities create landing pages on their own 
websites or wikis coordinators and mentors will create accounts on the 
Outreachy website
* This means we would have to copy projects from our wiki to 
https://www.outreachy.org  - I don't know what the 
template is yet, but this may create some extra work for mentors 
* The Outreachy application period opens in two weeks, on February 12.
* Apart from this, there is fairly little information on the timeline and 
process for this round and Outreachy mail ended up in my spam folder: I was 
polling the website for info and there was not much 

Current status:
* I have claimed the Xen Project page on https://www.outreachy 
 - waiting for it to be approved (I tried with an 
xenproject.org  alias which did not work)
* We have funding for one intern (maybe more) and thus qualify. Whether I can 
find more funds, depends on the cost of the developer summit. Hopefully I will 
know more this week (I expect concrete developer summit proposal this week)

Need input:
* For us too participate I need at least 3-4 mentors and projects to be added 
to https://www.outreachy.org  
* If you are willing to do this, please raise your hand now by replying to this 
thread or contacting me privately and I will help 

Best Regards
Lars

> On 8 Jan 2018, at 15:19, Lars Kurth  wrote:
> 
> Hi All,
> 
> it's this time of the year again to prepare for GSoC/Outreachy! The 
> application deadline for orgs is January 23 - February 11: ideally we will 
> have a good updated lists of projects by then as Google will look at the 
> quality of the project list. I will also need co-org admins: @Mindy are you 
> willing to do this again? Maybe also someone from the Unikraft project. That 
> helps ensure that we have reps from various subproject that ensure that we 
> don't miss deadlines.
> 
> 
> Best Regards
> Lars
> 
> Existing Projects (for people on the CC list)
> =
> If you are CC'ed you have one or several projects listed on 
> https://wiki.xenproject.org/wiki/Outreach_Program_Projects ... What I need 
> you to do is to
> 
> a) Weed out any projects that have been completed or are not relevant any more
>   @Mindy: For MirageOS folks, please check and update 
> https://github.com/mirage/mirage-www/wiki/Pioneer-Projects and do the same
> 
> b) Decide whether you still want to mentor:
>   This requires some of your bandwidth from mid-Feb to March 2018 to work on 
> small projects
>   The actual work happens from May 14 - Aug 14
> 
>   If not, please reply and list projects affected
>   If yes, please also do so and I will update the Verified field accordingly
> 
> c) Add any new information to existing projects as relevant. 
> 
> 
> New Projects
> 
> Feel free to add new projects to the list, but if you do so please let the 
> list know. We are not going to be very strict with 
> https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Conventions_for_Projects_and_Project_Mentors,
>  but getting someone else to review your proposal is a good idea. 
> 
> Unikraft
> 
> I created a place-holder for Unikraft at 
> https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Unikraft as 
> Unikraft project members indicated they want to participate.
> You probably do want to set expectations with regards to start-up tasks and 
> come up with a set of tasks to act as a filter for applicants (e.g. showing 
> that they set up the environment, etc.) 
> 
> 
> Specific Improvements to the project documentation
> ==
> 
> Hypervisor start-up tasks
> -
> https://wiki.xenproject.org/wiki/Xen_Project_Development_Projects contains: 
> "An easy way to get started (and show that you can set up the Xen Development 
> Environment, fix an issue, build and test Xen, submit a patch, etc.) is to 
> address a suitable number of Coverity Scan issues. Ask on xen-devel@ for a 
> set of suitable Coverity issues. Note that this does not require any access 
> to the Coverity scan results. Open bugs to fix under the Small Code 
> Contribution Requirement can also be found on bugs.xenproject.org"
> 
> Do we want to change this? Finding small get started projects is always a 
> little bit of a problem. Maybe we can prepare a better list somewhere.
> 
> In-tree vs. Wiki based projects
> ---
> We could also decide to move Hypervisor related ideas in-tree somewhere and 
> generate a list if that makes things easier. But this is not necessary, in 
> particular given with everything that is going on. I just wanted to raise 
> this as an option: I am not particularly wedded 

[Xen-devel] [PATCH v2 4/4] x86/emul: Improvements to internal users of decode_register()

[Andrew Cooper]

Most users of decode_register() can be replaced with decode_gpr() right away.

For the few sites which do care about possibly using the legacy byteop
encoding, rename decode_register() to decode_gpr_byteop(), and adjust its 'int
highbyte_regs' parameter to the more correct 'bool legacy_byteop'.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 

v2:
 * s/highbyte/legacy_byteop/ across the patch
 * Keep decode_gpr_byteop() returning void.  It doesn't affect any usecases
---
 xen/arch/x86/x86_emulate/x86_emulate.c | 69 +++---
 1 file changed, 30 insertions(+), 39 deletions(-)

diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c 
b/xen/arch/x86/x86_emulate/x86_emulate.c
index 3766b7a..217 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1957,9 +1957,8 @@ const uint8_t cpu_user_regs_gpr_offsets[] = {
 #endif
 };
 
-void *
-decode_register(
-uint8_t modrm_reg, struct cpu_user_regs *regs, int highbyte_regs)
+static void *decode_gpr_byteop(
+struct cpu_user_regs *regs, unsigned int modrm_reg, bool legacy_byteop)
 {
 static const uint8_t byteop_offsets[] = {
 offsetof(struct cpu_user_regs, al),
@@ -1972,7 +1971,7 @@ decode_register(
 offsetof(struct cpu_user_regs, bh),
 };
 
-if ( !highbyte_regs )
+if ( !legacy_byteop )
 return decode_gpr(regs, modrm_reg);
 
 /* Check that the array is a power of two. */
@@ -1987,10 +1986,11 @@ decode_register(
 return (void *)regs + byteop_offsets[modrm_reg];
 }
 
-static void *decode_vex_gpr(unsigned int vex_reg, struct cpu_user_regs *regs,
-const struct x86_emulate_ctxt *ctxt)
+static unsigned long *decode_vex_gpr(
+unsigned int vex_reg, struct cpu_user_regs *regs,
+const struct x86_emulate_ctxt *ctxt)
 {
-return decode_register(~vex_reg & (mode_64bit() ? 0xf : 7), regs, 0);
+return decode_gpr(regs, ~vex_reg & (mode_64bit() ? 0xf : 7));
 }
 
 static bool is_aligned(enum x86_segment seg, unsigned long offs,
@@ -2799,8 +2799,7 @@ x86_decode(
 sib_index = ((sib >> 3) & 7) | ((rex_prefix << 2) & 8);
 sib_base  = (sib & 7) | ((rex_prefix << 3) & 8);
 if ( sib_index != 4 && !(d & vSIB) )
-ea.mem.off = *(long *)decode_register(sib_index,
-  state->regs, 0);
+ea.mem.off = *decode_gpr(state->regs, sib_index);
 ea.mem.off <<= (sib >> 6) & 3;
 if ( (modrm_mod == 0) && ((sib_base & 7) == 5) )
 ea.mem.off += insn_fetch_type(int32_t);
@@ -2819,15 +2818,13 @@ x86_decode(
 ea.mem.off += state->regs->r(bp);
 }
 else
-ea.mem.off += *(long *)decode_register(sib_base,
-   state->regs, 0);
+ea.mem.off += *decode_gpr(state->regs, sib_base);
 }
 else
 {
 generate_exception_if(d & vSIB, EXC_UD);
 modrm_rm |= (rex_prefix & 1) << 3;
-ea.mem.off = *(long *)decode_register(modrm_rm,
-  state->regs, 0);
+ea.mem.off = *decode_gpr(state->regs, modrm_rm);
 if ( (modrm_rm == 5) && (modrm_mod != 0) )
 ea.mem.seg = x86_seg_ss;
 }
@@ -3052,8 +3049,7 @@ x86_emulate(
 generate_exception_if(state->not_64bit && mode_64bit(), EXC_UD);
 
 if ( ea.type == OP_REG )
-ea.reg = decode_register(modrm_rm, &_regs,
- (d & ByteOp) && !rex_prefix);
+ea.reg = decode_gpr_byteop(&_regs, modrm_rm, (d & ByteOp) && 
!rex_prefix);
 
 memset(mmvalp, 0xaa /* arbitrary */, sizeof(*mmvalp));
 
@@ -3067,13 +3063,13 @@ x86_emulate(
 src.type = OP_REG;
 if ( d & ByteOp )
 {
-src.reg = decode_register(modrm_reg, &_regs, (rex_prefix == 0));
+src.reg = decode_gpr_byteop(&_regs, modrm_reg, !rex_prefix);
 src.val = *(uint8_t *)src.reg;
 src.bytes = 1;
 }
 else
 {
-src.reg = decode_register(modrm_reg, &_regs, 0);
+src.reg = decode_gpr(&_regs, modrm_reg);
 switch ( (src.bytes = op_bytes) )
 {
 case 2: src.val = *(uint16_t *)src.reg; break;
@@ -3143,13 +3139,13 @@ x86_emulate(
 dst.type = OP_REG;
 if ( d & ByteOp )
 {
-dst.reg = decode_register(modrm_reg, &_regs, (rex_prefix == 0));
+dst.reg = decode_gpr_byteop(&_regs, modrm_reg, !rex_prefix);
 dst.val = *(uint8_t *)dst.reg;
 dst.bytes = 1;
 }
 else
 {
-dst.reg = decode_register(modrm_reg, &_regs, 0);
+dst.reg 

[Xen-devel] [PATCH v2 1/4] x86/emul: Introduce a test covering legacy byte ops

[Andrew Cooper]

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 

v2:
 * New
---
 tools/tests/x86_emulator/test_x86_emulator.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/tools/tests/x86_emulator/test_x86_emulator.c 
b/tools/tests/x86_emulator/test_x86_emulator.c
index 7a8df41..850fba6 100644
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -442,6 +442,21 @@ int main(int argc, char **argv)
 goto fail;
 printf("okay\n");
 
+printf("%-40s", "Testing xchgl %bl,%ah...");
+instr[0] = 0x86; instr[1] = 0xdc;
+regs.eflags = 0x200;
+regs.eip= (unsigned long)[0];
+regs.eax= 0xbbcc;
+regs.ebx= 0xeeff;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) ||
+ (regs.eax != 0xffcc) ||
+ (regs.ebx != 0xeebb) ||
+ (regs.eflags != 0x200) ||
+ (regs.eip != (unsigned long)[2]) )
+goto fail;
+printf("okay\n");
+
 printf("%-40s", "Testing lock cmpxchgl %ecx,(%ebx)...");
 instr[0] = 0xf0; instr[1] = 0x0f; instr[2] = 0xb1; instr[3] = 0x0b;
 regs.eflags = 0x200;
-- 
2.1.4


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

[Xen-devel] [PATCH v2 2/4] x86/emul: Optimise decode_register() somewhat

[Andrew Cooper]

The positions of GPRs inside struct cpu_user_regs doesn't follow any
particular order, so as compiled, decode_register() becomes a jump table to 16
blocks which calculate the appropriate offset, at a total of 207 bytes.

Instead, pre-compute the offsets at build time and use pointer arithmetic to
calculate the result.  By observation, most callers in x86_emulate() inline
and constant-propagate the highbyte_regs value of 0.

The splitting of the general and legacy byte-op cases means that we will now
hit an ASSERT if any code path tries to use the legacy byte-op encoding with a
REX prefix.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 

v2:
 * Move byteop_offsets[] into function scope.  Rearrange to have a smaller
   byteop_offsets[] array.
---
 xen/arch/x86/x86_emulate/x86_emulate.c | 75 --
 1 file changed, 53 insertions(+), 22 deletions(-)

diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c 
b/xen/arch/x86/x86_emulate/x86_emulate.c
index ff0a003..123d941 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1935,36 +1935,67 @@ load_seg(
 return rc;
 }
 
+/* Map GPRs by ModRM encoding to their offset within struct cpu_user_regs. */
+static const uint8_t cpu_user_regs_gpr_offsets[] = {
+offsetof(struct cpu_user_regs, r(ax)),
+offsetof(struct cpu_user_regs, r(cx)),
+offsetof(struct cpu_user_regs, r(dx)),
+offsetof(struct cpu_user_regs, r(bx)),
+offsetof(struct cpu_user_regs, r(sp)),
+offsetof(struct cpu_user_regs, r(bp)),
+offsetof(struct cpu_user_regs, r(si)),
+offsetof(struct cpu_user_regs, r(di)),
+#ifdef __x86_64__
+offsetof(struct cpu_user_regs, r8),
+offsetof(struct cpu_user_regs, r9),
+offsetof(struct cpu_user_regs, r10),
+offsetof(struct cpu_user_regs, r11),
+offsetof(struct cpu_user_regs, r12),
+offsetof(struct cpu_user_regs, r13),
+offsetof(struct cpu_user_regs, r14),
+offsetof(struct cpu_user_regs, r15),
+#endif
+};
+
 void *
 decode_register(
 uint8_t modrm_reg, struct cpu_user_regs *regs, int highbyte_regs)
 {
-void *p;
+static const uint8_t byteop_offsets[] = {
+offsetof(struct cpu_user_regs, al),
+offsetof(struct cpu_user_regs, cl),
+offsetof(struct cpu_user_regs, dl),
+offsetof(struct cpu_user_regs, bl),
+offsetof(struct cpu_user_regs, ah),
+offsetof(struct cpu_user_regs, ch),
+offsetof(struct cpu_user_regs, dh),
+offsetof(struct cpu_user_regs, bh),
+};
 
-switch ( modrm_reg )
+if ( !highbyte_regs )
 {
-case  0: p = >r(ax); break;
-case  1: p = >r(cx); break;
-case  2: p = >r(dx); break;
-case  3: p = >r(bx); break;
-case  4: p = (highbyte_regs ? >ah : (void *)>r(sp)); break;
-case  5: p = (highbyte_regs ? >ch : (void *)>r(bp)); break;
-case  6: p = (highbyte_regs ? >dh : (void *)>r(si)); break;
-case  7: p = (highbyte_regs ? >bh : (void *)>r(di)); break;
-#if defined(__x86_64__)
-case  8: p = >r8;  break;
-case  9: p = >r9;  break;
-case 10: p = >r10; break;
-case 11: p = >r11; break;
-case 12: p = >r12; break;
-case 13: p = >r13; break;
-case 14: p = >r14; break;
-case 15: p = >r15; break;
-#endif
-default: BUG(); p = NULL; break;
+/* Check that the array is a power of two. */
+BUILD_BUG_ON(ARRAY_SIZE(cpu_user_regs_gpr_offsets) &
+ (ARRAY_SIZE(cpu_user_regs_gpr_offsets) - 1));
+
+ASSERT(modrm_reg < ARRAY_SIZE(cpu_user_regs_gpr_offsets));
+
+/* For safety in release builds.  Debug builds will hit the ASSERT() */
+modrm_reg &= ARRAY_SIZE(cpu_user_regs_gpr_offsets) - 1;
+
+return (void *)regs + cpu_user_regs_gpr_offsets[modrm_reg];
 }
 
-return p;
+/* Check that the array is a power of two. */
+BUILD_BUG_ON(ARRAY_SIZE(byteop_offsets) &
+ (ARRAY_SIZE(byteop_offsets) - 1));
+
+ASSERT(modrm_reg < ARRAY_SIZE(byteop_offsets));
+
+/* For safety in release builds.  Debug builds will hit the ASSERT() */
+modrm_reg &= ARRAY_SIZE(byteop_offsets) - 1;
+
+return (void *)regs + byteop_offsets[modrm_reg];
 }
 
 static void *decode_vex_gpr(unsigned int vex_reg, struct cpu_user_regs *regs,
-- 
2.1.4


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

[Xen-devel] [PATCH v2 3/4] x86/hvm: Improvements to external users of decode_register()

[Andrew Cooper]

 * Rename to decode_gpr() to be more specific as to its purpose
 * Drop the highbyte encoding handling, as no users currently care, and it
   unlikely that future users would care.
 * Change to a static inline, returning an unsigned long pointer.

Doing so highlights that the "invalid gpr" paths in hvm_mov_{to,from}_cr()
were actually unreachable.  All callers already passed in-range GPRs, and
out-of-range GPRs would have hit the BUG() previously.

Signed-off-by: Andrew Cooper 
Reviewed-by: Kevin Tian 
Reviewed-by: Jan Beulich 
---
v2:
 * Fix commit message
---
 xen/arch/x86/hvm/hvm.c | 17 ++---
 xen/arch/x86/hvm/vmx/vvmx.c| 16 +++-
 xen/arch/x86/x86_emulate/x86_emulate.c | 15 ++-
 xen/arch/x86/x86_emulate/x86_emulate.h | 29 +
 4 files changed, 32 insertions(+), 45 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 8d67851..18d721d 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2061,16 +2061,9 @@ static void hvm_set_uc_mode(struct vcpu *v, bool_t 
is_in_uc_mode)
 int hvm_mov_to_cr(unsigned int cr, unsigned int gpr)
 {
 struct vcpu *curr = current;
-unsigned long val, *reg;
+unsigned long val = *decode_gpr(guest_cpu_user_regs(), gpr);
 int rc;
 
-if ( (reg = decode_register(gpr, guest_cpu_user_regs(), 0)) == NULL )
-{
-gdprintk(XENLOG_ERR, "invalid gpr: %u\n", gpr);
-goto exit_and_crash;
-}
-
-val = *reg;
 HVMTRACE_LONG_2D(CR_WRITE, cr, TRC_PAR_LONG(val));
 HVM_DBG_LOG(DBG_LEVEL_1, "CR%u, value = %lx", cr, val);
 
@@ -2111,13 +2104,7 @@ int hvm_mov_to_cr(unsigned int cr, unsigned int gpr)
 int hvm_mov_from_cr(unsigned int cr, unsigned int gpr)
 {
 struct vcpu *curr = current;
-unsigned long val = 0, *reg;
-
-if ( (reg = decode_register(gpr, guest_cpu_user_regs(), 0)) == NULL )
-{
-gdprintk(XENLOG_ERR, "invalid gpr: %u\n", gpr);
-goto exit_and_crash;
-}
+unsigned long val = 0, *reg = decode_gpr(guest_cpu_user_regs(), gpr);
 
 switch ( cr )
 {
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 885eab3..dfe97b9 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -347,18 +347,14 @@ enum vmx_insn_errno set_vvmcs_real_safe(const struct vcpu 
*v, u32 encoding,
 static unsigned long reg_read(struct cpu_user_regs *regs,
   unsigned int index)
 {
-unsigned long *pval = decode_register(index, regs, 0);
-
-return *pval;
+return *decode_gpr(regs, index);
 }
 
 static void reg_write(struct cpu_user_regs *regs,
   unsigned int index,
   unsigned long value)
 {
-unsigned long *pval = decode_register(index, regs, 0);
-
-*pval = value;
+*decode_gpr(regs, index) = value;
 }
 
 static inline u32 __n2_pin_exec_control(struct vcpu *v)
@@ -2483,14 +2479,8 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs *regs,
 case VMX_CONTROL_REG_ACCESS_TYPE_MOV_TO_CR:
 {
 unsigned long gp = 
VMX_CONTROL_REG_ACCESS_GPR(exit_qualification);
-unsigned long *reg;
+val = *decode_gpr(guest_cpu_user_regs(), gp);
 
-if ( (reg = decode_register(gp, guest_cpu_user_regs(), 0)) == 
NULL )
-{
-gdprintk(XENLOG_ERR, "invalid gpr: %lx\n", gp);
-break;
-}
-val = *reg;
 if ( cr == 0 )
 {
 u64 cr0_gh_mask = get_vvmcs(v, CR0_GUEST_HOST_MASK);
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c 
b/xen/arch/x86/x86_emulate/x86_emulate.c
index 123d941..3766b7a 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1936,7 +1936,7 @@ load_seg(
 }
 
 /* Map GPRs by ModRM encoding to their offset within struct cpu_user_regs. */
-static const uint8_t cpu_user_regs_gpr_offsets[] = {
+const uint8_t cpu_user_regs_gpr_offsets[] = {
 offsetof(struct cpu_user_regs, r(ax)),
 offsetof(struct cpu_user_regs, r(cx)),
 offsetof(struct cpu_user_regs, r(dx)),
@@ -1973,18 +1973,7 @@ decode_register(
 };
 
 if ( !highbyte_regs )
-{
-/* Check that the array is a power of two. */
-BUILD_BUG_ON(ARRAY_SIZE(cpu_user_regs_gpr_offsets) &
- (ARRAY_SIZE(cpu_user_regs_gpr_offsets) - 1));
-
-ASSERT(modrm_reg < ARRAY_SIZE(cpu_user_regs_gpr_offsets));
-
-/* For safety in release builds.  Debug builds will hit the ASSERT() */
-modrm_reg &= ARRAY_SIZE(cpu_user_regs_gpr_offsets) - 1;
-
-return (void *)regs + cpu_user_regs_gpr_offsets[modrm_reg];
-}
+return decode_gpr(regs, modrm_reg);
 
 /* Check that the array is a power of two. */
 

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

[Julien Grall]

On 30/01/18 15:44, osstest service owner wrote:

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
  test-amd64-amd64-pairbroken
  build-armhf-xsm   6 xen-buildfail REGR. vs. 118174


From the log [1]:

failure (trapped): status 65280 at Osstest/TestSupport.pm line 486.

Ian, any idea?

Cheers,


[1] 
http://logs.test-lab.xenproject.org/osstest/logs/118441/build-armhf-xsm/6.ts-xen-build.log




Tests which are failing intermittently (not blocking):
  test-amd64-amd64-pair 4 host-install/src_host(4) broken pass in 118423
  test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail in 118423 pass 
in 118441
  test-armhf-armhf-xl-rtds 17 guest-start.2fail in 118423 pass in 118441
  test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail in 118423 
pass in 118441

Tests which did not succeed, but are not blocking:
  test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
  test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
  test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail in 118423 like 
118174
  test-armhf-armhf-xl-xsm 13 migrate-support-check fail in 118423 never pass
  test-armhf-armhf-xl-xsm 14 saverestore-support-check fail in 118423 never pass
  test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail in 118423 never 
pass
  test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118174
  test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118174
  test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118174
  test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118174
  test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118174
  test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118174
  test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 118174
  test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 118174
  test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118174
  test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
  test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
  test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
  test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
  test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
  test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
  test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
  test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
  test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
  test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
  test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
  test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
  test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
  test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
  test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
  test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
  test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
  test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
  test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
  test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
  test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
  test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
  test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
  test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
  test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
  test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
  test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
  test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
  test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
  test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
  test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
  test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
  test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
  

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pairbroken
 build-armhf-xsm   6 xen-buildfail REGR. vs. 118174

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pair 4 host-install/src_host(4) broken pass in 118423
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail in 118423 pass 
in 118441
 test-armhf-armhf-xl-rtds 17 guest-start.2fail in 118423 pass in 118441
 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail in 118423 
pass in 118441

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail in 118423 like 
118174
 test-armhf-armhf-xl-xsm 13 migrate-support-check fail in 118423 never pass
 test-armhf-armhf-xl-xsm 14 saverestore-support-check fail in 118423 never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail in 118423 never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118174
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118174
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118174
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118174
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118174
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118174
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 118174
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 118174
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118174
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-armhf-armhf-xl-vhd 

Re: [Xen-devel] [PATCH RFC v2 10/12] x86: allocate per-vcpu stacks for interrupt entries

[Jan Beulich]

>>> On 22.01.18 at 13:32,  wrote:
> In case of XPTI being active for a pv-domain allocate and initialize
> per-vcpu stacks. The stacks are added to the per-domain mappings of
> the pv-domain.

Considering the intended use of these stacks (as per the overview
mail) I consider 32k per vCPU a non-negligible amount of extra memory
use.

> +static int pv_vcpu_init_xpti(struct vcpu *v)
> +{
> +struct domain *d = v->domain;
> +struct page_info *pg;
> +void *ptr;
> +struct cpu_info *info;
> +unsigned long stack_bottom;
> +int rc;
> +
> +/* Populate page tables. */
> +rc = create_perdomain_mapping(d, XPTI_START(v), STACK_PAGES,
> +  NIL(l1_pgentry_t *), NULL);
> +if ( rc )
> +goto done;
> +
> +/* Map stacks. */
> +rc = create_perdomain_mapping(d, XPTI_START(v), IST_MAX,
> +  NULL, NIL(struct page_info *));
> +if ( rc )
> +goto done;
> +
> +ptr = alloc_xenheap_page();
> +if ( !ptr )
> +{
> +rc = -ENOMEM;
> +goto done;
> +}
> +clear_page(ptr);
> +addmfn_to_perdomain_mapping(d, XPTI_START(v) + STACK_SIZE - PAGE_SIZE,
> +_mfn(virt_to_mfn(ptr)));

This can't be create_perdomain_mapping() because of ...? If it's
the Xen heap page you use here - that would be the next question:
Does it need to be such, rather than a domheap one? I do see ...

> +info = (struct cpu_info *)((unsigned long)ptr + PAGE_SIZE) - 1;
> +info->flags = ON_VCPUSTACK;
> +v->arch.pv_vcpu.stack_regs = >guest_cpu_user_regs;

... this pointer, but without a clear picture on intended use it's
hard to judge.

> +/* Map TSS. */
> +rc = create_perdomain_mapping(d, XPTI_TSS(v), 1, NULL, );
> +if ( rc )
> +goto done;
> +info = (struct cpu_info *)(XPTI_START(v) + STACK_SIZE) - 1;

Iiuc this is a pointer one absolutely must not de-reference. A bit
dangerous, I would say, the more that further up the same
variable is being de-referenced.

Also I would assume the TSS can be mapped r/o.

> +stack_bottom = (unsigned long)>guest_cpu_user_regs.es;
> +ptr = __map_domain_page(pg);
> +tss_init(ptr, stack_bottom);
> +unmap_domain_page(ptr);
> +
> +/* Map stub trampolines. */
> +rc = create_perdomain_mapping(d, XPTI_TRAMPOLINE(v), 1, NULL, );
> +if ( rc )
> +goto done;
> +ptr = __map_domain_page(pg);
> +write_stub_trampoline((unsigned char *)ptr, XPTI_TRAMPOLINE(v),

I would be very surprised if you really needed the cast here.

> @@ -25,6 +25,21 @@
>   */
>  
>  /*
> + * The vcpu stacks used for XPTI are arranged similar to the physical cpu
> + * stacks with some modifications. The main difference are the primary stack
> + * size (only 1 page) and usage of the unused mappings for TSS and IDT.
> + *
> + * 7 - Primary stack (with a struct cpu_info at the top)
> + * 6 - unused
> + * 5 - TSS

Judging by the comment this might mean "TSS / IDT", or slots 4 or 6
might be used for the IDT. Otoh I don't see any IDT related logic in
pv_vcpu_init_xpti(). Please clarify this.

> @@ -37,10 +52,24 @@ struct vcpu;
>  
>  struct cpu_info {
>  struct cpu_user_regs guest_cpu_user_regs;
> -unsigned int processor_id;
> -struct vcpu *current_vcpu;
> -unsigned long per_cpu_offset;
> -unsigned long cr4;
> +union {
> +/* per physical cpu mapping */
> +struct {
> +struct vcpu *current_vcpu;
> +unsigned long per_cpu_offset;
> +unsigned long cr4;
> +};
> +/* per vcpu mapping (xpti) */
> +struct {
> +unsigned long pad1;
> +unsigned long pad2;
> +unsigned long stack_bottom_cpu;
> +};

In order to avoid accidental use in the wrong context as much as
possible, I think you want to name both structures.

Jan


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

Re: [Xen-devel] [PATCH RFC v2 06/12] x86: add a xpti command line parameter

[Jan Beulich]

>>> On 22.01.18 at 13:32,  wrote:
> @@ -212,6 +249,24 @@ int pv_domain_initialise(struct domain *d, unsigned int 
> domcr_flags,
>  /* 64-bit PV guest by default. */
>  d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
>  
> +switch (opt_xpti)

Style.

> +{
> +case XPTI_OFF:
> +d->arch.pv_domain.xpti = false;
> +break;
> +case XPTI_ON:
> +d->arch.pv_domain.xpti = true;
> +break;
> +case XPTI_NODOM0:
> +d->arch.pv_domain.xpti = boot_cpu_data.x86_vendor != X86_VENDOR_AMD 
> &&
> + d->domain_id != 0 &&
> + d->domain_id != hardware_domid;
> +break;
> +case XPTI_DEFAULT:
> +d->arch.pv_domain.xpti = boot_cpu_data.x86_vendor != X86_VENDOR_AMD;
> +break;
> +}

Why does a 32-bit domain need this?

Jan


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

Re: [Xen-devel] [PATCH RFC v2 09/12] x86: enhance syscall stub to work in per-domain mapping

[Jan Beulich]

>>> On 22.01.18 at 13:32,  wrote:
> --- a/xen/arch/x86/x86_64/traps.c
> +++ b/xen/arch/x86/x86_64/traps.c
> @@ -260,10 +260,11 @@ void do_double_fault(struct cpu_user_regs *regs)
>  panic("DOUBLE FAULT -- system shutdown");
>  }
>  
> -static unsigned int write_stub_trampoline(
> -unsigned char *stub, unsigned long stub_va,
> -unsigned long stack_bottom, unsigned long target_va)
> +void write_stub_trampoline(unsigned char *stub, unsigned long stub_va,
> +   unsigned long stack_bottom, unsigned long 
> target_va)

Why does the static go away?

> @@ -282,24 +283,32 @@ static unsigned int write_stub_trampoline(
>  /* pushq %rax */
>  stub[23] = 0x50;
>  
> -/* jmp target_va */
> -stub[24] = 0xe9;
> -*(int32_t *)[25] = target_va - (stub_va + 29);
> -
> -/* Round up to a multiple of 16 bytes. */
> -return 32;
> +target_diff = target_va - (stub_va + 29);
> +if ( target_diff >> 31 == target_diff >> 63 )
> +{
> +/* jmp target_va */
> +stub[24] = 0xe9;
> +*(int32_t *)[25] = target_diff;
> +}
> +else
> +{
> +/* movabs target_va, %rax */
> +stub[24] = 0x48;
> +stub[25] = 0xb8;
> +*(uint64_t *)[26] = target_va;
> +/* jmpq *%rax */
> +stub[34] = 0xff;
> +stub[35] = 0xe0;
> +}

This clearly needs another solution, as you'd have to go through a
thunk now, and the thunk would be unreachable too.

>  }
>  
>  DEFINE_PER_CPU(struct stubs, stubs);
> -void lstar_enter(void);
> -void cstar_enter(void);

Why do these move into a header?

> @@ -312,10 +321,9 @@ void subarch_percpu_traps_init(void)
>   * start of the stubs.
>   */
>  wrmsrl(MSR_LSTAR, stub_va);
> -offset = write_stub_trampoline(stub_page + (stub_va & ~PAGE_MASK),
> -   stub_va, stack_bottom,
> -   (unsigned long)lstar_enter);
> -stub_va += offset;
> +write_stub_trampoline(stub_page + (stub_va & ~PAGE_MASK), stub_va,
> +  stack_bottom, (unsigned long)lstar_enter);
> +stub_va += STUB_TRAMPOLINE_SIZE_PERCPU;

The function may have written more than 32 bytes now; you'd
notice the breakage if you put a suitable BUILD_BUG_ON() into
the function. Otherwise I recommend you stick to the current
"return number of bytes written" model.

> @@ -328,12 +336,11 @@ void subarch_percpu_traps_init(void)
>  
>  /* Trampoline for SYSCALL entry from compatibility mode. */
>  wrmsrl(MSR_CSTAR, stub_va);
> -offset += write_stub_trampoline(stub_page + (stub_va & ~PAGE_MASK),
> -stub_va, stack_bottom,
> -(unsigned long)cstar_enter);
> +write_stub_trampoline(stub_page + (stub_va & ~PAGE_MASK), stub_va,
> +  stack_bottom, (unsigned long)cstar_enter);
>  
>  /* Don't consume more than half of the stub space here. */
> -ASSERT(offset <= STUB_BUF_SIZE / 2);
> +ASSERT(2 * STUB_TRAMPOLINE_SIZE_PERCPU <= STUB_BUF_SIZE / 2);

BUILD_BUG_ON() for compile time constants.

Jan


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

[Xen-devel] test lab: laxton power cycle time changed to 30s

[Ian Jackson]

For our records.

14:41  Diziet: How long do we wait in off state when hard cycling the 
box in the colo?
14:42  I think the default is quite short but there's a per-host 
   override.
14:43  Default is 5s.  Some hosts have more.
14:44  Diziet: For softiron: Even though the firmware is still 
susceptible to self-bricking, we identified what activities 
cause it the most and can provide some input on avoiding that. 
(avoid using ipmi for power cycling, and when hard cycling wait 
at least 30s in off state)
14:44  It's normally easy to tell if it's too short: the host survives 
   the attempt to power cycle, but manual off and then manual on 
14:43  Default is 5s.  Some hosts have more.
14:44  Diziet: For softiron: Even though the firmware is still 
susceptible to self-bricking, we identified what activities 
cause it the most and can provide some input on avoiding that. 
(avoid using ipmi for power cycling, and when hard cycling wait 
at least 30s in off state)
14:44  It's normally easy to tell if it's too short: the host survives 
   the attempt to power cycle, but manual off and then manual on 
   reboots it.
14:44  Diziet: In a thread discussion within Arm.
14:44  wait at least 30s> I can totally do that.
14:45  julieng: Now done.
14:45  Diziet: Thank you! Hopefully laxton1 will stay alive longer :)
14:45  Yes...

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

Re: [Xen-devel] [PATCH RFC v2 05/12] x86: don't access saved user regs via rsp in trap handlers

[Jan Beulich]

>>> On 22.01.18 at 13:32,  wrote:
> In order to support switching stacks when entering the hypervisor for
> support of page table isolation, don't use %rsp for accessing the
> saved user registers, but do that via %rdi.

If this really turns out to be necessary ...

> @@ -58,20 +58,24 @@ compat_test_guest_events:
>  jmp   compat_test_all_events
>  
>  ALIGN
> -/* %rbx: struct vcpu */
> +/* %rbx: struct vcpu, %rdi: user_regs */
>  compat_process_softirqs:
>  sti
> +pushq %rdi
>  call  do_softirq
> +popq  %rdi
>  jmp   compat_test_all_events

... to avoid changes like this one (which unduly affect stack
alignment) you will want to consider using e.g. %r12 instead.

But concerning specifically the compat entry code, it's unclear to
me why you'd need to switch stacks there too.

> @@ -211,13 +218,15 @@ ENTRY(cstar_enter)
>  testl $~3,%esi
>  leal  (,%rcx,TBF_INTERRUPT),%ecx
>  UNLIKELY_START(z, compat_syscall_gpf)
> -movq  VCPU_trap_ctxt(%rbx),%rdi
> -movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
> -subl  $2,UREGS_rip(%rsp)
> +pushq %rcx
> +movq  VCPU_trap_ctxt(%rbx),%rcx
> +movl  $TRAP_gp_fault,UREGS_entry_vector(%rdi)
> +subl  $2,UREGS_rip(%rdi)
>  movl  $0,TRAPBOUNCE_error_code(%rdx)
> -movl  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rdi),%eax
> -movzwl TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_cs(%rdi),%esi
> -testb $4,TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_flags(%rdi)
> +movl  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rcx),%eax
> +movzwl TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_cs(%rcx),%esi
> +testb $4,TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_flags(%rcx)
> +popq  %rcx

Is there really no register available, requiring you to push/pop
%rcx here?

> --- a/xen/include/asm-x86/current.h
> +++ b/xen/include/asm-x86/current.h
> @@ -95,9 +95,13 @@ unsigned long get_stack_dump_bottom (unsigned long sp);
>  ({  \
>  __asm__ __volatile__ (  \
>  "mov %0,%%"__OP"sp;"\
> -CHECK_FOR_LIVEPATCH_WORK  \
> - "jmp %c1"  \
> -: : "r" (guest_cpu_user_regs()), "i" (__fn) : "memory" );   \
> +"mov %1,%%"__OP"di;"\
> +"pushq %%"__OP"di;" \
> +CHECK_FOR_LIVEPATCH_WORK\
> +"popq %%"__OP"di;"  \
> +"jmp %c2"   \
> +: : "r" (get_cpu_info()), "r" (guest_cpu_user_regs()),  \
> +"i" (__fn) : "memory" );\
>  unreachable();  \
>  })

If you want guest_cpu_user_regs() in %rdi, why don't you use
"D" as constraint? Why do you need to restore %rdi prior to the
final JMP? And why do you need the value in %rdi before calling
check_for_livepatch_work(), when the function takes no arguments?

Jan


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

Re: [Xen-devel] [PATCH v3 8/8] ARM: make nr_irqs a constant

[Roger Pau Monné]

On Wed, Jan 24, 2018 at 06:10:58PM +, Andre Przywara wrote:
> On ARM the maximum number of IRQs is a constant, but we share it being
> a variable to match x86. Since we are not supposed to alter it, let's
> mark it as "const" to avoid accidental change.
> 
> Suggested-by: Julien Grall 
> Signed-off-by: Andre Przywara 
> ---
>  xen/arch/arm/irq.c| 2 +-
>  xen/include/asm-arm/irq.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index 62103a20e3..d229cb6871 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -27,7 +27,7 @@
>  #include 
>  #include 
>  
> -unsigned int __read_mostly nr_irqs = NR_IRQS;
> +const unsigned int __read_mostly nr_irqs = NR_IRQS;

Shouldn't you remove the __read_mostly attribute, so the symbol it's
placed at the .rodata section by the compiler?

Roger.

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

Re: [Xen-devel] [PATCH 4/4] x86: avoid double CR3 reload when switching to guest user mode

[Andrew Cooper]

On 23/01/18 10:38, Jan Beulich wrote:
> When XPTI is active, the CR3 load in restore_all_guest is sufficient
> when switching to user mode, improving in particular system call and
> page fault exit paths for the guest.
>
> Signed-off-by: Jan Beulich 

While I can see the utility of this, we are starting to get into
complicated territory as to which cr3 is loaded.  Also, the name
"toggle" is no longer strictly accurate.

That being said, all of these helpers are only used in synchronous
contexts as far as I can tell, so some ASSERT(!in_irq()) would probably
go a long way.

>
> --- a/xen/arch/x86/pv/domain.c
> +++ b/xen/arch/x86/pv/domain.c
> @@ -220,10 +220,20 @@ int pv_domain_initialise(struct domain *
>  return rc;
>  }
>  
> -static void _toggle_guest_pt(struct vcpu *v)
> +static void _toggle_guest_pt(struct vcpu *v, bool force_cr3)
>  {
>  v->arch.flags ^= TF_kernel_mode;
>  update_cr3(v);
> +
> +/*
> + * There's no need to load CR3 here when it is going to be loaded on the
> + * way out to guest mode again anyway, and when the page tables we're
> + * currently on are the kernel ones (whereas when switching to kernel
> + * mode we need to be able to write a bounce frame onto the kernel 
> stack).
> + */
> +if ( !force_cr3 && !(v->arch.flags & TF_kernel_mode) )
> +return;
> +
>  /* Don't flush user global mappings from the TLB. Don't tick TLB clock. 
> */
>  asm volatile ( "mov %0, %%cr3" : : "r" (v->arch.cr3) : "memory" );
>  
> @@ -253,13 +263,13 @@ void toggle_guest_mode(struct vcpu *v)
>  }
>  asm volatile ( "swapgs" );
>  
> -_toggle_guest_pt(v);
> +_toggle_guest_pt(v, cpu_has_no_xpti);
>  }
>  
>  void toggle_guest_pt(struct vcpu *v)
>  {
>  if ( !is_pv_32bit_vcpu(v) )
> -_toggle_guest_pt(v);
> +_toggle_guest_pt(v, true);

This can be converted as well.  The only callers are the LDT-fault and
I/O perm check, both when we are currently on user pagetables, needing
to switch to kernel briefly, then back to user.

However, it would be better to drop the parameter and feed
cpu_has_no_xpti into the conditional above which explains why it is safe
to do.

~Andrew

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

Re: [Xen-devel] [PATCH 2/4] x86: eliminate most XPTI entry/exit code when it's not in use

[Jan Beulich]

>>> On 30.01.18 at 13:02,  wrote:
> On 23/01/18 10:37, Jan Beulich wrote:
>> Introduce a synthetic feature flag to use alternative instruction
>> patching to NOP out all code on entry/exit paths other than those
>> involved in NMI/#MC handling (the patching logic can't properly handle
>> those paths yet). Having NOPs here is generally better than using
>> conditional branches.
> 
> Given my other series, I'd prefer to fix the IST paths rather than
> introduce yet-more workarounds.

More workarounds? The patch simply avoids touching the IST path.

>> --- a/xen/arch/x86/x86_64/compat/entry.S
>> +++ b/xen/arch/x86/x86_64/compat/entry.S
>> @@ -189,7 +189,7 @@ ENTRY(compat_post_handle_exception)
>>  
>>  /* See lstar_enter for entry register state. */
>>  ENTRY(cstar_enter)
>> -/* sti could live here when we don't switch page tables below. */
>> +ALTERNATIVE nop, sti, X86_FEATURE_NO_XPTI
> 
> I do not think the complexity of of altering the position of sti
> outweighs the fractional extra delay which would result from
> unilaterally having the sti later.  Furthermore, if you really are
> concerned about microoptimising this, you don't want a singlebyte nop here.
> 
>>  CR4_PV32_RESTORE

There is, not the least, this, which I'm afraid is adding quite a bit
of a delay. While we're not real-time ready, I don't think we should
needlessly delay the enabling of interrupts.

As to the single byte NOP - are you suggesting it is worse than
the single byte STI?

>> @@ -210,6 +211,12 @@ ENTRY(cstar_enter)
>>  movq  $0, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
>>  .Lcstar_cr3_okay:
>>  sti
>> +.Lcstar_cr3_end:
>> +.pushsection .altinstructions, "a", @progbits
>> +altinstruction_entry .Lcstar_cr3_start, .Lcstar_cr3_start, \
>> + X86_FEATURE_NO_XPTI, \
>> + (.Lcstar_cr3_end - .Lcstar_cr3_start), 0
>> +.popsection
> 
> It occurs to me that this would be far more legible if we had an alt_nop
> wrapper.  Reusing .Lcstar_cr3_start and a length of 0 isn't obvious.

Could certainly do that, but one thing at a time.

>> --- a/xen/arch/x86/x86_64/entry.S
>> +++ b/xen/arch/x86/x86_64/entry.S
>> @@ -46,7 +47,6 @@ restore_all_guest:
>>  movabs $DIRECTMAP_VIRT_START, %rcx
>>  mov   %rdi, %rax
>>  and   %rsi, %rdi
>> -jz.Lrag_keep_cr3
> 
> This looks like a functional change?

Definitely not - the conditional branch simply becomes unnecessary
when the entire piece of code gets NOP-ed out.

>> @@ -492,9 +519,20 @@ ENTRY(common_interrupt)
>>  CR4_PV32_RESTORE
>>  movq %rsp,%rdi
>>  callq do_IRQ
>> +.Lintr_cr3_restore:
>>  mov   %r15, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
>> +.Lintr_cr3_end:
>>  jmp ret_from_intr
>>  
>> +.pushsection .altinstructions, "a", @progbits
>> +altinstruction_entry .Lintr_cr3_restore, .Lintr_cr3_restore, \
>> + X86_FEATURE_NO_XPTI, \
>> + (.Lintr_cr3_end - .Lintr_cr3_restore), 0
>> +altinstruction_entry .Lintr_cr3_start, .Lintr_cr3_start, \
>> + X86_FEATURE_NO_XPTI, \
>> + (.Lintr_cr3_okay - .Lintr_cr3_start), 0
> 
> This is now getting very complicated to follow.  Is it just for IST
> safety and liable to disappear?  If not, I think we need a different
> way,as this is now saying "sporadic instructions inside this block, but
> not all of them, turn into nops".

This is not an IST path, and it is also not NOP-ing out sporadic
instructions - we can't drop the first piece of code without also
dropping the second, as %r14 won't be set up if the first block
is gone. They're clearly framed by .Lintr_cr3_* labels - I'm not
sure how to make even more obvious what's going on.

Jan


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

Re: [Xen-devel] [PATCH 3/4] x86: re-organize toggle_guest_*()

[Andrew Cooper]

On 23/01/18 10:38, Jan Beulich wrote:
> toggle_guest_mode() is only ever being called for 64-bit PV vCPU-s -
> replace the 32-bit PV conditional by an ASSERT().
>
> Introduce a local helper without 32-bit PV conditional, to be used by
> both pre-existing functions.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

[Xen-devel] Issue with booting with xen,passthrough DTB

[Saumya Rajesh]

Hi

I am trying to passthrough the I2C bus[channel 2 group A] to DomU in
Xen. I am implementing this on R-Car H3.

I added xen,passthrough = "1" to the i2c2 node in r8a7795.dtsi and
rebuilt the dtb for Domain 0. The dtb works when I boot into Dom0, but
the kernel crashes when I try to boot again using the same dtb.
Assuming that the integrated device using i2c2 somehow gets corrupted
for the second run, I tried to passthrough the entire rcar sound
system, which is associated with i2c2. But I get the same result i.e.
Kernel boots for the first run but fails when I reboot using the same
dtb.

Following is the modification in Dom 0 dtb :

i2c2: i2c@e651 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "renesas,i2c-r8a7795";
reg = <0 0xe651 0 0x40>;
interrupts = ;
clocks = < CPG_MOD 929>;
power-domains = < R8A7795_PD_ALWAYS_ON>;
dmas = < 0x95>, < 0x94>;
dma-names = "tx", "rx";
i2c-scl-internal-delay-ns = <6>;
status = "disabled";
xen,passthrough = "1";
};

***
rcar_sound: sound@ec50 {
***
power-domains = < R8A7795_PD_ALWAYS_ON>;
status = "disabled";
xen,passthrough = "1";
***
Please see the attachment for the kernel log.

Any support or suggestion regarding the cause of this issue will be
much appreciated.

I have also posted another issue regarding passthrough [1]. Please
have a look into it also.

Regards
Saumya

[1] https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg02618.html

*
*   Booting using passthrough DTB for the first time
*

NOTICE:  BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.9
NOTICE:  BL2: PRR is R-Car H3 ES1.1
NOTICE:  BL2: Boot device is HyperFlash(80MHz)
NOTICE:  BL2: LCM state is CM
NOTICE:  BL2: AVS setting succeeded. DVFS_SetVID=0x52
NOTICE:  BL2: DDR2400(rev.0.15)
NOTICE:  BL2: DRAM Split is 4ch
NOTICE:  BL2: QoS is default setting(rev.0.32)
NOTICE:  BL2: v1.1(release):3ad02ac
NOTICE:  BL2: Built : 15:16:01, Feb 15 2017
NOTICE:  BL2: Normal boot
NOTICE:  BL2: dst=0xe631a208 src=0x818 len=512(0x200)
NOTICE:  BL2: dst=0x43f0 src=0x8180400 len=6144(0x1800)
NOTICE:  BL2: dst=0x4400 src=0x81c len=65536(0x1)
NOTICE:  BL2: dst=0x4410 src=0x820 len=524288(0x8)
NOTICE:  BL2: dst=0x4900 src=0x864 len=1048576(0x10)


U-Boot 2015.04 (Feb 15 2017 - 15:16:02)

CPU: Renesas Electronics R8A7795 rev 1.1
Board: Salvator-X
I2C:   ready
DRAM:  3.9 GiB
MMC:   sh-sdhi: 0, sh-sdhi: 1, sh-sdhi: 2
In:serial
Out:   serial
Err:   serial
Net:   ravb
Hit any key to stop autoboot:  0 
819584 bytes read in 100 ms (7.8 MiB/s)
65776 bytes read in 36 ms (1.7 MiB/s)
15067648 bytes read in 1305 ms (11 MiB/s)
10319 bytes read in 24 ms (418.9 KiB/s)
## Booting kernel from Legacy Image at 4808 ...
   Image Name:   XEN
   Image Type:   AArch64 Linux Kernel Image (uncompressed)
   Data Size:819520 Bytes = 800.3 KiB
   Load Address: 7808
   Entry Point:  7808
   Verifying Checksum ... OK
## Flattened Device Tree blob at 4800
   Booting using the fdt blob at 0x4800
   Loading Kernel Image ... OK
   Using Device Tree in place at 4800, end 480130ef

Starting kernel ...

 Xen 4.8.0
(XEN) Xen version 4.8.0 (aarch64-poky-linux-gcc (Linaro GCC 5.2-2015.11-2) 
5.2.1 20151005) debug=n  Wed Feb 15 14:56:12 IST 2017
(XEN) Latest ChangeSet: Wed Jun 22 17:28:18 2016 +0300 git:3fa5d2a-dirty
(XEN) Processor: 411fd073: "ARM Limited", variant: 0x1, part 0xd07, rev 0x3
(XEN) 64-bit Execution:
(XEN)   Processor Features:  
(XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
(XEN) Extensions: FloatingPoint AdvancedSIMD
(XEN)   Debug Features: 10305106 
(XEN)   Auxiliary Features:  
(XEN)   Memory Model Features: 1124 
(XEN)   ISA Features:  00011120 
(XEN) 32-bit Execution:
(XEN)   Processor Features: 0131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
(XEN) Extensions: GenericTimer Security
(XEN)   Debug Features: 03010066
(XEN)   Auxiliary Features: 
(XEN)   Memory Model Features: 10201105 4000 0126 02102211
(XEN)  ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121
(XEN) Using PSCI-1.0 for SMP bringup
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz
(XEN) GICv2 initialization:
(XEN) gic_dist_addr=f101
(XEN) gic_cpu_addr=f102
(XEN) gic_hyp_addr=f104
(XEN) gic_vcpu_addr=f106
(XEN) gic_maintenance_irq=25
(XEN) GICv2: Adjusting CPU interface base to 0xf102f000
(XEN) GICv2: 512 lines, 8 cpus, secure (IID 0200043b).
(XEN) XSM Framework v1.0.0 initialized
(XEN) xsm: Policy len = 0x0001 start at 0x7c00
(XEN) Flask: 128 avtab hash slots, 280 rules.
(XEN) 

Re: [Xen-devel] [PATCH v3 8/8] ARM: make nr_irqs a constant

[Julien Grall]

Hi Andre,

On 24/01/18 18:10, Andre Przywara wrote:

On ARM the maximum number of IRQs is a constant, but we share it being
a variable to match x86. Since we are not supposed to alter it, let's
mark it as "const" to avoid accidental change.

Suggested-by: Julien Grall 
Signed-off-by: Andre Przywara 


Acked-by: Julien Grall 

Cheers,


---
  xen/arch/arm/irq.c| 2 +-
  xen/include/asm-arm/irq.h | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 62103a20e3..d229cb6871 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -27,7 +27,7 @@
  #include 
  #include 
  
-unsigned int __read_mostly nr_irqs = NR_IRQS;

+const unsigned int __read_mostly nr_irqs = NR_IRQS;
  
  static unsigned int local_irqs_type[NR_LOCAL_IRQS];

  static DEFINE_SPINLOCK(local_irqs_type_lock);
diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
index 0d110ecb08..9d55e9b122 100644
--- a/xen/include/asm-arm/irq.h
+++ b/xen/include/asm-arm/irq.h
@@ -34,7 +34,7 @@ struct arch_irq_desc {
  /* This is a spurious interrupt ID which never makes it into the GIC code. */
  #define INVALID_IRQ 1023
  
-extern unsigned int nr_irqs;

+extern const unsigned int nr_irqs;
  #define nr_static_irqs NR_IRQS
  #define arch_hwdom_irqs(domid) NR_IRQS
  



--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 5/8] ARM: VGIC: factor out vgic_connect_hw_irq()

[Julien Grall]

Hi Andre,

On 24/01/18 18:10, Andre Przywara wrote:

At the moment we happily access VGIC internal data structures like
the rank and struct pending_irq in gic.c, which should be VGIC agnostic.

Factor out a new function vgic_connect_hw_irq(), which allows a virtual
IRQ to be connected to a hardware IRQ (using the hw bit in the LR).

This removes said accesses to VGIC data structures and improves abstraction.


You are modifying the locking of the 2 functions. But I don't see how 
this is safe. Can you explain it?




Signed-off-by: Andre Przywara 
Acked-by: Stefano Stabellini 
---
  xen/arch/arm/gic-vgic.c| 31 +++
  xen/arch/arm/gic.c | 42 ++
  xen/include/asm-arm/vgic.h |  2 ++
  3 files changed, 39 insertions(+), 36 deletions(-)

diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
index 0a2958c5db..d44e4dacd3 100644
--- a/xen/arch/arm/gic-vgic.c
+++ b/xen/arch/arm/gic-vgic.c
@@ -411,6 +411,37 @@ void gic_dump_vgic_info(struct vcpu *v)
  printk("Pending irq=%d\n", p->irq);
  }
  
+int vgic_connect_hw_irq(struct domain *d, struct vcpu *v, unsigned int virq,

+struct irq_desc *desc)
+{
+unsigned long flags;
+/* Use vcpu0 to retrieve the pending_irq struct. Given that we only
+ * route SPIs to guests, it doesn't make any difference. */


Can you fix the coding style of the comment?


+struct vcpu *v_target = vgic_get_target_vcpu(d->vcpu[0], virq);
+struct vgic_irq_rank *rank = vgic_rank_irq(v_target, virq);
+struct pending_irq *p = irq_to_pending(v_target, virq);
+int ret = 0;
+
+/* We are taking to rank lock to prevent parallel connections. */
+vgic_lock_rank(v_target, rank, flags);
+
+if ( desc )
+{
+/* The VIRQ should not be already enabled by the guest */
+if ( !p->desc &&
+ !test_bit(GIC_IRQ_GUEST_ENABLED, >status) )
+p->desc = desc;
+else
+ret = -EBUSY;
+}
+else
+p->desc = NULL;
+
+vgic_unlock_rank(v_target, rank, flags);
+
+return ret;
+}
+
  /*
   * Local variables:
   * mode: C
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 4cb74d449e..d46a6d54b3 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -128,27 +128,12 @@ void gic_route_irq_to_xen(struct irq_desc *desc, unsigned 
int priority)
  int gic_route_irq_to_guest(struct domain *d, unsigned int virq,
 struct irq_desc *desc, unsigned int priority)
  {
-unsigned long flags;
-/* Use vcpu0 to retrieve the pending_irq struct. Given that we only
- * route SPIs to guests, it doesn't make any difference. */
-struct vcpu *v_target = vgic_get_target_vcpu(d->vcpu[0], virq);
-struct vgic_irq_rank *rank = vgic_rank_irq(v_target, virq);
-struct pending_irq *p = irq_to_pending(v_target, virq);
-int res = -EBUSY;
-
  ASSERT(spin_is_locked(>lock));
  /* Caller has already checked that the IRQ is an SPI */
  ASSERT(virq >= 32);
  ASSERT(virq < vgic_num_irqs(d));
  ASSERT(!is_lpi(virq));
  
-vgic_lock_rank(v_target, rank, flags);

-
-if ( p->desc ||
- /* The VIRQ should not be already enabled by the guest */
- test_bit(GIC_IRQ_GUEST_ENABLED, >status) )
-goto out;
-
  desc->handler = gic_hw_ops->gic_guest_irq_type;
  set_bit(_IRQ_GUEST, >status);


This looks wrong to me. You don't want to execute any of the code below 
if you are not able to route the pIRQ. For instance because the vIRQ has 
already a desc assigned.


  
@@ -156,31 +141,19 @@ int gic_route_irq_to_guest(struct domain *d, unsigned int virq,

  gic_set_irq_type(desc, desc->arch.type);
  gic_set_irq_priority(desc, priority);
  
-p->desc = desc;

-res = 0;
-
-out:
-vgic_unlock_rank(v_target, rank, flags);
-
-return res;
+return vgic_connect_hw_irq(d, NULL, virq, desc);
  }
  
  /* This function only works with SPIs for now */

  int gic_remove_irq_from_guest(struct domain *d, unsigned int virq,
struct irq_desc *desc)
  {
-struct vcpu *v_target = vgic_get_target_vcpu(d->vcpu[0], virq);
-struct vgic_irq_rank *rank = vgic_rank_irq(v_target, virq);
-struct pending_irq *p = irq_to_pending(v_target, virq);
-unsigned long flags;
+int ret;
  
  ASSERT(spin_is_locked(>lock));

  ASSERT(test_bit(_IRQ_GUEST, >status));
-ASSERT(p->desc == desc);


You dropped this assert but I don't see any replacement in the new code? 
We really want to make sure the caller will not do something dumb here 
(like passing a different desc).



  ASSERT(!is_lpi(virq));
  
-vgic_lock_rank(v_target, rank, flags);

-
  if ( d->is_dying )
  {
  desc->handler->shutdown(desc);
@@ -198,19 +171,16 @@ int gic_remove_irq_from_guest(struct domain *d, unsigned 
int virq,
   */
  if 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  2b8d75e975d6fbe0140969154a67601698b84738
baseline version:
 xen  43cc31b4778ed8313c4324547da1f46037132c52

Last test of basis   118442  2018-01-29 17:01:09 Z0 days
Testing same since   118453  2018-01-30 11:01:16 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Stefano Stabellini 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   43cc31b477..2b8d75e975  2b8d75e975d6fbe0140969154a67601698b84738 -> smoke

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

Re: [Xen-devel] [PATCH 2/4] x86: eliminate most XPTI entry/exit code when it's not in use

[Andrew Cooper]

On 23/01/18 10:37, Jan Beulich wrote:
> Introduce a synthetic feature flag to use alternative instruction
> patching to NOP out all code on entry/exit paths other than those
> involved in NMI/#MC handling (the patching logic can't properly handle
> those paths yet). Having NOPs here is generally better than using
> conditional branches.

Given my other series, I'd prefer to fix the IST paths rather than
introduce yet-more workarounds.

> --- a/xen/arch/x86/x86_64/compat/entry.S
> +++ b/xen/arch/x86/x86_64/compat/entry.S
> @@ -189,7 +189,7 @@ ENTRY(compat_post_handle_exception)
>  
>  /* See lstar_enter for entry register state. */
>  ENTRY(cstar_enter)
> -/* sti could live here when we don't switch page tables below. */
> +ALTERNATIVE nop, sti, X86_FEATURE_NO_XPTI

I do not think the complexity of of altering the position of sti
outweighs the fractional extra delay which would result from
unilaterally having the sti later.  Furthermore, if you really are
concerned about microoptimising this, you don't want a singlebyte nop here.

>  CR4_PV32_RESTORE
>  movq  8(%rsp),%rax /* Restore %rax. */
>  movq  $FLAT_KERNEL_SS,8(%rsp)
> @@ -201,6 +201,7 @@ ENTRY(cstar_enter)
>  SAVE_ALL
>  
>  GET_STACK_END(bx)
> +.Lcstar_cr3_start:
>  mov   STACK_CPUINFO_FIELD(xen_cr3)(%rbx), %rcx
>  neg   %rcx
>  jz.Lcstar_cr3_okay
> @@ -210,6 +211,12 @@ ENTRY(cstar_enter)
>  movq  $0, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
>  .Lcstar_cr3_okay:
>  sti
> +.Lcstar_cr3_end:
> +.pushsection .altinstructions, "a", @progbits
> +altinstruction_entry .Lcstar_cr3_start, .Lcstar_cr3_start, \
> + X86_FEATURE_NO_XPTI, \
> + (.Lcstar_cr3_end - .Lcstar_cr3_start), 0
> +.popsection

It occurs to me that this would be far more legible if we had an alt_nop
wrapper.  Reusing .Lcstar_cr3_start and a length of 0 isn't obvious.

> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -46,7 +47,6 @@ restore_all_guest:
>  movabs $DIRECTMAP_VIRT_START, %rcx
>  mov   %rdi, %rax
>  and   %rsi, %rdi
> -jz.Lrag_keep_cr3

This looks like a functional change?

>  and   %r9, %rsi
>  add   %rcx, %rdi
>  add   %rcx, %rsi
> @@ -473,6 +499,7 @@ ENTRY(dom_crash_sync_extable)
>  ENTRY(common_interrupt)
>  SAVE_ALL CLAC
>  
> +.Lintr_cr3_start:
>  GET_STACK_END(14)
>  mov   STACK_CPUINFO_FIELD(xen_cr3)(%r14), %rcx
>  mov   %rcx, %r15
> @@ -492,9 +519,20 @@ ENTRY(common_interrupt)
>  CR4_PV32_RESTORE
>  movq %rsp,%rdi
>  callq do_IRQ
> +.Lintr_cr3_restore:
>  mov   %r15, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
> +.Lintr_cr3_end:
>  jmp ret_from_intr
>  
> +.pushsection .altinstructions, "a", @progbits
> +altinstruction_entry .Lintr_cr3_restore, .Lintr_cr3_restore, \
> + X86_FEATURE_NO_XPTI, \
> + (.Lintr_cr3_end - .Lintr_cr3_restore), 0
> +altinstruction_entry .Lintr_cr3_start, .Lintr_cr3_start, \
> + X86_FEATURE_NO_XPTI, \
> + (.Lintr_cr3_okay - .Lintr_cr3_start), 0

This is now getting very complicated to follow.  Is it just for IST
safety and liable to disappear?  If not, I think we need a different
way,as this is now saying "sporadic instructions inside this block, but
not all of them, turn into nops".

~Andrew

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

Re: [Xen-devel] [PATCH v3 1/8] ARM: VGIC: drop unneeded gic_restore_pending_irqs()

[Julien Grall]

Hi Andre,

On 24/01/18 18:10, Andre Przywara wrote:

In gic_restore_pending_irqs() we push our pending virtual IRQs into the
list registers. This function is called once from gic_inject(), just
before we return to the guest, but also in gic_restore_state(), when
we context-switch a VCPU. Having a closer look it turns out that the
later call is not needed, since we will always call gic_inject() anyway.
So remove that call (and the forward declaration) to streamline this
interface and make separating the GIC from the VGIC world later.

Signed-off-by: Andre Przywara 


Reviewed-by: Julien Grall 

Cheers,


---
  xen/arch/arm/gic.c | 4 
  1 file changed, 4 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index bac8ada2bb..721a17a9d7 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -36,8 +36,6 @@
  #include 
  #include 
  
-static void gic_restore_pending_irqs(struct vcpu *v);

-
  static DEFINE_PER_CPU(uint64_t, lr_mask);
  
  #define lr_all_full() (this_cpu(lr_mask) == ((1 << gic_hw_ops->info->nr_lrs) - 1))

@@ -91,8 +89,6 @@ void gic_restore_state(struct vcpu *v)
  gic_hw_ops->restore_state(v);
  
  isb();

-
-gic_restore_pending_irqs(v);
  }
  
  /* desc->irq needs to be disabled before calling this function */




--
Julien Grall

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

Re: [Xen-devel] [PATCH 2/5] xen/alternatives: Plumb a 'live' parameter through apply_alternatives()

[Julien Grall]

Hi Andrew,

On 30/01/18 11:24, Andrew Cooper wrote:

On 30/01/18 11:05, Julien Grall wrote:

Hi Andrew,

On 29/01/18 15:38, Andrew Cooper wrote:

On x86, we would like to alter how we patch based on whether there is
any
chance of the code being patched being concurrently executed.

prepare_payload() passes false (as the livepatch definitely isn't
live at this
point), whereas the boot-time alternatives application passes true.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Konrad Rzeszutek Wilk 
CC: Ross Lagerwall 
---
   xen/arch/arm/alternative.c    | 10 ++
   xen/arch/x86/alternative.c    |  5 +++--
   xen/common/livepatch.c    |  2 +-
   xen/include/asm-arm/alternative.h |  6 --
   xen/include/asm-x86/alternative.h |  3 ++-
   5 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index 99112e1..078b259 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -98,7 +98,8 @@ static u32 get_alt_insn(const struct alt_instr *alt,
    * The region patched should be read-write to allow
__apply_alternatives
    * to replacing the instructions when necessary.
    */
-static void __apply_alternatives(const struct alt_region *region)
+static void __apply_alternatives(const struct alt_region *region,
+ bool live)
   {
   const struct alt_instr *alt;
   const u32 *replptr;
@@ -193,7 +194,7 @@ static int __init
__apply_alternatives_multi_stop(void *unused)
   region.begin = (void *)__alt_instructions - (void *)_start
+ xenmap;
   region.end = (void *)__alt_instructions_end - (void
*)_start + xenmap;
   -    __apply_alternatives();
+    __apply_alternatives(, true);
     unregister_virtual_region(_region);
   @@ -224,14 +225,15 @@ void __init apply_alternatives_all(void)
   }
     void apply_alternatives(const struct alt_instr *start,
-    const struct alt_instr *end)
+    const struct alt_instr *end,
+    bool live)


This function is not able to deal with "live" code, so I think at
least need an ASSERT(!live) to prevent mis-usage of the code.


This passes straight through into __apply_alternatives(), just like
__apply_alternatives_multi_stop does, and multi_stop is used on live code.

Either both are unsafe (although all evidence to the contrary), or both
are safe, but I don't think that an assert here is appropriate.


I disagree here. In the commit message you wrote: "On x86, we would like 
to alter how we patch based on whether there is any chance of the code 
being patched being concurrently executed."


I translate this as all the other CPUs may be alive and the code would 
be mapped with read-executable permission (no write permission). It will 
not be easily possible to make the region writable because the processor 
has been configured to forbid it.


__apply_alternatives relies on the region patched to be write accessible 
and the region not executed by any CPUs.


 __apply_alternatives_multi_stop has the logic make the write 
accessible. This is not the case of apply_alternatives.


So the former function is safe while the latter one is unsafe when live 
is true.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 0.5/5] arm/alternatives: Drop the !HAS_ALTERNATIVE infrastructure

[Andrew Cooper]

On 30/01/18 11:29, Julien Grall wrote:
> Hi Andrew,
>
> Thank you for doing the clean-up.
>
> On 30/01/18 11:16, Andrew Cooper wrote:
>> ARM now unconditionally selects HAS_ALTERNATIVE, which has caused the
>> !HAS_ALTERNATIVE code in include/asm-arm/alternative.h to bitrot to
>> the point
>> of failing to compile.
>>
>> Expand all the CONFIG_HAS_ALTERNATIVE references in ARM code.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Stefano Stabellini 
>> CC: Julien Grall 
>> CC: Konrad Rzeszutek Wilk 
>>
>> N.B. Only compile tested
>> ---
>>   xen/arch/arm/xen.lds.S    |  2 --
>>   xen/include/asm-arm/alternative.h | 15 ---
>>   xen/test/livepatch/xen_hello_world_func.c |  2 +-
>
> You forgot on in include/asm-arm/cpuerrata.h :).

Oops - so I did.  Folded this incremental diff.

~Andrew

diff --git a/xen/include/asm-arm/cpuerrata.h
b/xen/include/asm-arm/cpuerrata.h
index 7de6836..4e45b23 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -7,8 +7,6 @@
 void check_local_cpu_errata(void);
 void enable_errata_workarounds(void);
 
-#ifdef CONFIG_HAS_ALTERNATIVE
-
 #define CHECK_WORKAROUND_HELPER(erratum, feature, arch) \
 static inline bool check_workaround_##erratum(void) \
 {   \
@@ -27,19 +25,6 @@ static inline bool
check_workaround_##erratum(void) \
 }   \
 }
 
-#else /* CONFIG_HAS_ALTERNATIVE */
-
-#define CHECK_WORKAROUND_HELPER(erratum, feature, arch) \
-static inline bool check_workaround_##erratum(void) \
-{   \
-    if ( !IS_ENABLED(arch) )    \
-    return false;   \
-    else    \
-    return unlikely(cpus_have_cap(feature));    \
-}
-
-#endif
-
 CHECK_WORKAROUND_HELPER(766422, ARM32_WORKAROUND_766422, CONFIG_ARM_32)
 CHECK_WORKAROUND_HELPER(834220, ARM64_WORKAROUND_834220, CONFIG_ARM_64)
 


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

Re: [Xen-devel] [PATCH 0.5/5] arm/alternatives: Drop the !HAS_ALTERNATIVE infrastructure

[Julien Grall]

Hi Andrew,

Thank you for doing the clean-up.

On 30/01/18 11:16, Andrew Cooper wrote:

ARM now unconditionally selects HAS_ALTERNATIVE, which has caused the
!HAS_ALTERNATIVE code in include/asm-arm/alternative.h to bitrot to the point
of failing to compile.

Expand all the CONFIG_HAS_ALTERNATIVE references in ARM code.

Signed-off-by: Andrew Cooper 
---
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Konrad Rzeszutek Wilk 

N.B. Only compile tested
---
  xen/arch/arm/xen.lds.S|  2 --
  xen/include/asm-arm/alternative.h | 15 ---
  xen/test/livepatch/xen_hello_world_func.c |  2 +-


You forgot on in include/asm-arm/cpuerrata.h :).


  3 files changed, 1 insertion(+), 18 deletions(-)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index c9b9546..b039018 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -154,14 +154,12 @@ SECTIONS
 *(.initcall1.init)
 __initcall_end = .;
  
-#ifdef CONFIG_HAS_ALTERNATIVE

 . = ALIGN(4);
 __alt_instructions = .;
 *(.altinstructions)
 __alt_instructions_end = .;
 . = ALIGN(4);
 *(.altinstr_replacement)
-#endif
  
 *(.init.data)

 *(.init.data.rel)
diff --git a/xen/include/asm-arm/alternative.h 
b/xen/include/asm-arm/alternative.h
index 6cc9d0d..4e33d1c 100644
--- a/xen/include/asm-arm/alternative.h
+++ b/xen/include/asm-arm/alternative.h
@@ -3,8 +3,6 @@
  
  #include 
  
-#ifdef CONFIG_HAS_ALTERNATIVE

-
  #ifndef __ASSEMBLY__
  
  #include 

@@ -152,17 +150,4 @@ int apply_alternatives(const struct alt_instr *start, 
const struct alt_instr *en
  #define ALTERNATIVE(oldinstr, newinstr, ...)   \
_ALTERNATIVE_CFG(oldinstr, newinstr, __VA_ARGS__, 1)
  
-#else /* !CONFIG_HAS_ALTERNATIVE */

-
-static inline void apply_alternatives_all(void)
-{
-}
-
-static inline int apply_alternatives(void *start, size_t length)
-{
-return 0;
-}
-
-#endif
-
  #endif /* __ASM_ALTERNATIVE_H */
diff --git a/xen/test/livepatch/xen_hello_world_func.c 
b/xen/test/livepatch/xen_hello_world_func.c
index 1518f71..b358224 100644
--- a/xen/test/livepatch/xen_hello_world_func.c
+++ b/xen/test/livepatch/xen_hello_world_func.c
@@ -29,7 +29,7 @@ const char *xen_hello_world(void)
  rc = __get_user(tmp, non_canonical_addr);
  BUG_ON(rc != -EFAULT);
  #endif
-#if defined(CONFIG_ARM) && defined(CONFIG_HAS_ALTERNATIVE)
+#if defined(CONFIG_ARM)
  asm(ALTERNATIVE("nop", "nop", LIVEPATCH_FEATURE));
  #endif
  



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 2/5] xen/alternatives: Plumb a 'live' parameter through apply_alternatives()

[Andrew Cooper]

On 30/01/18 11:05, Julien Grall wrote:
> Hi Andrew,
>
> On 29/01/18 15:38, Andrew Cooper wrote:
>> On x86, we would like to alter how we patch based on whether there is
>> any
>> chance of the code being patched being concurrently executed.
>>
>> prepare_payload() passes false (as the livepatch definitely isn't
>> live at this
>> point), whereas the boot-time alternatives application passes true.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Jan Beulich 
>> CC: Stefano Stabellini 
>> CC: Julien Grall 
>> CC: Konrad Rzeszutek Wilk 
>> CC: Ross Lagerwall 
>> ---
>>   xen/arch/arm/alternative.c    | 10 ++
>>   xen/arch/x86/alternative.c    |  5 +++--
>>   xen/common/livepatch.c    |  2 +-
>>   xen/include/asm-arm/alternative.h |  6 --
>>   xen/include/asm-x86/alternative.h |  3 ++-
>>   5 files changed, 16 insertions(+), 10 deletions(-)
>>
>> diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
>> index 99112e1..078b259 100644
>> --- a/xen/arch/arm/alternative.c
>> +++ b/xen/arch/arm/alternative.c
>> @@ -98,7 +98,8 @@ static u32 get_alt_insn(const struct alt_instr *alt,
>>    * The region patched should be read-write to allow
>> __apply_alternatives
>>    * to replacing the instructions when necessary.
>>    */
>> -static void __apply_alternatives(const struct alt_region *region)
>> +static void __apply_alternatives(const struct alt_region *region,
>> + bool live)
>>   {
>>   const struct alt_instr *alt;
>>   const u32 *replptr;
>> @@ -193,7 +194,7 @@ static int __init
>> __apply_alternatives_multi_stop(void *unused)
>>   region.begin = (void *)__alt_instructions - (void *)_start
>> + xenmap;
>>   region.end = (void *)__alt_instructions_end - (void
>> *)_start + xenmap;
>>   -    __apply_alternatives();
>> +    __apply_alternatives(, true);
>>     unregister_virtual_region(_region);
>>   @@ -224,14 +225,15 @@ void __init apply_alternatives_all(void)
>>   }
>>     void apply_alternatives(const struct alt_instr *start,
>> -    const struct alt_instr *end)
>> +    const struct alt_instr *end,
>> +    bool live)
>
> This function is not able to deal with "live" code, so I think at
> least need an ASSERT(!live) to prevent mis-usage of the code.

This passes straight through into __apply_alternatives(), just like
__apply_alternatives_multi_stop does, and multi_stop is used on live code.

Either both are unsafe (although all evidence to the contrary), or both
are safe, but I don't think that an assert here is appropriate.

~Andrew

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

[Xen-devel] [PATCH 0.5/5] arm/alternatives: Drop the !HAS_ALTERNATIVE infrastructure

[Andrew Cooper]

ARM now unconditionally selects HAS_ALTERNATIVE, which has caused the
!HAS_ALTERNATIVE code in include/asm-arm/alternative.h to bitrot to the point
of failing to compile.

Expand all the CONFIG_HAS_ALTERNATIVE references in ARM code.

Signed-off-by: Andrew Cooper 
---
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Konrad Rzeszutek Wilk 

N.B. Only compile tested
---
 xen/arch/arm/xen.lds.S|  2 --
 xen/include/asm-arm/alternative.h | 15 ---
 xen/test/livepatch/xen_hello_world_func.c |  2 +-
 3 files changed, 1 insertion(+), 18 deletions(-)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index c9b9546..b039018 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -154,14 +154,12 @@ SECTIONS
*(.initcall1.init)
__initcall_end = .;
 
-#ifdef CONFIG_HAS_ALTERNATIVE
. = ALIGN(4);
__alt_instructions = .;
*(.altinstructions)
__alt_instructions_end = .;
. = ALIGN(4);
*(.altinstr_replacement)
-#endif
 
*(.init.data)
*(.init.data.rel)
diff --git a/xen/include/asm-arm/alternative.h 
b/xen/include/asm-arm/alternative.h
index 6cc9d0d..4e33d1c 100644
--- a/xen/include/asm-arm/alternative.h
+++ b/xen/include/asm-arm/alternative.h
@@ -3,8 +3,6 @@
 
 #include 
 
-#ifdef CONFIG_HAS_ALTERNATIVE
-
 #ifndef __ASSEMBLY__
 
 #include 
@@ -152,17 +150,4 @@ int apply_alternatives(const struct alt_instr *start, 
const struct alt_instr *en
 #define ALTERNATIVE(oldinstr, newinstr, ...)   \
_ALTERNATIVE_CFG(oldinstr, newinstr, __VA_ARGS__, 1)
 
-#else /* !CONFIG_HAS_ALTERNATIVE */
-
-static inline void apply_alternatives_all(void)
-{
-}
-
-static inline int apply_alternatives(void *start, size_t length)
-{
-return 0;
-}
-
-#endif
-
 #endif /* __ASM_ALTERNATIVE_H */
diff --git a/xen/test/livepatch/xen_hello_world_func.c 
b/xen/test/livepatch/xen_hello_world_func.c
index 1518f71..b358224 100644
--- a/xen/test/livepatch/xen_hello_world_func.c
+++ b/xen/test/livepatch/xen_hello_world_func.c
@@ -29,7 +29,7 @@ const char *xen_hello_world(void)
 rc = __get_user(tmp, non_canonical_addr);
 BUG_ON(rc != -EFAULT);
 #endif
-#if defined(CONFIG_ARM) && defined(CONFIG_HAS_ALTERNATIVE)
+#if defined(CONFIG_ARM)
 asm(ALTERNATIVE("nop", "nop", LIVEPATCH_FEATURE));
 #endif
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] ARM: GICv3: copy Dom0 GICv3 reg property from host DT

[Julien Grall]

Hi Andre,

On 30/01/18 09:35, Andre Przywara wrote:

@@ -1173,27 +1172,21 @@ static int gicv3_make_hwdom_dt_node(const struct domain 
*d,
  if ( res )
  return res;
  
-len = dt_cells_to_size(dt_n_addr_cells(gic) + dt_n_size_cells(gic));

+new_len = dt_cells_to_size(dt_n_addr_cells(gic) + dt_n_size_cells(gic));
  /*
   * GIC has two memory regions: Distributor + rdist regions
   * CPU interface and virtual cpu interfaces accessesed as System registers
   * So cells are created only for Distributor and rdist regions
   */
-len = len * (d->arch.vgic.nr_regions + 1);
-new_cells = xzalloc_bytes(len);
-if ( new_cells == NULL )
-return -FDT_ERR_XEN(ENOMEM);
-
-tmp = new_cells;
-
-dt_set_range(, gic, d->arch.vgic.dbase, SZ_64K);
+new_len = new_len * (d->arch.vgic.nr_regions + 1);
  
-for ( i = 0; i < d->arch.vgic.nr_regions; i++ )

-dt_set_range(, gic, d->arch.vgic.rdist_regions[i].base,
- d->arch.vgic.rdist_regions[i].size);
+hw_reg = dt_get_property(gic, "reg", );
+if ( !hw_reg )
+return -FDT_ERR_XEN(ENOENT);
+if ( new_len > len )
+   return -FDT_ERR_XEN(ERANGE);


The indentation looks wrong here.

With that fixed:

Acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 2/5] xen/alternatives: Plumb a 'live' parameter through apply_alternatives()

[Julien Grall]

Hi Andrew,

On 29/01/18 15:38, Andrew Cooper wrote:

On x86, we would like to alter how we patch based on whether there is any
chance of the code being patched being concurrently executed.

prepare_payload() passes false (as the livepatch definitely isn't live at this
point), whereas the boot-time alternatives application passes true.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Konrad Rzeszutek Wilk 
CC: Ross Lagerwall 
---
  xen/arch/arm/alternative.c| 10 ++
  xen/arch/x86/alternative.c|  5 +++--
  xen/common/livepatch.c|  2 +-
  xen/include/asm-arm/alternative.h |  6 --
  xen/include/asm-x86/alternative.h |  3 ++-
  5 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index 99112e1..078b259 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -98,7 +98,8 @@ static u32 get_alt_insn(const struct alt_instr *alt,
   * The region patched should be read-write to allow __apply_alternatives
   * to replacing the instructions when necessary.
   */
-static void __apply_alternatives(const struct alt_region *region)
+static void __apply_alternatives(const struct alt_region *region,
+ bool live)
  {
  const struct alt_instr *alt;
  const u32 *replptr;
@@ -193,7 +194,7 @@ static int __init __apply_alternatives_multi_stop(void 
*unused)
  region.begin = (void *)__alt_instructions - (void *)_start + xenmap;
  region.end = (void *)__alt_instructions_end - (void *)_start + xenmap;
  
-__apply_alternatives();

+__apply_alternatives(, true);
  
  unregister_virtual_region(_region);
  
@@ -224,14 +225,15 @@ void __init apply_alternatives_all(void)

  }
  
  void apply_alternatives(const struct alt_instr *start,

-const struct alt_instr *end)
+const struct alt_instr *end,
+bool live)


This function is not able to deal with "live" code, so I think at least 
need an ASSERT(!live) to prevent mis-usage of the code.


With that:

Reviewed-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 1/4] x86: remove CR reads from exit-to-guest path

[Andrew Cooper]

On 23/01/18 10:36, Jan Beulich wrote:
> --- a/xen/include/asm-x86/asm_defns.h
> +++ b/xen/include/asm-x86/asm_defns.h
> @@ -206,13 +206,12 @@ void ret_from_intr(void);
>  #define ASM_STAC ASM_AC(STAC)
>  #define ASM_CLAC ASM_AC(CLAC)
>  
> -.macro write_cr3 val:req, tmp1:req, tmp2:req
> -mov   %cr4, %\tmp1
> -mov   %\tmp1, %\tmp2
> -and   $~X86_CR4_PGE, %\tmp1
> -mov   %\tmp1, %cr4
> +.macro write_cr3 val:req, cr4:req, tmp:req
> +mov   %\cr4, %\tmp
> +and   $~X86_CR4_PGE, %\cr4
> +mov   %\cr4, %cr4

This is confusing to read; It took me a while to work out why it
assembled in the first place.  Given that there are only two instances
of write_cr3 now, I'd suggest expanding this in the two sites.  It will
also make it clear which registers have real values and which are
temporary, which isn't clear from the current callsites.

Otherwise, Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 1/5] arm/alternatives: Fix apply_alternatives() API

[Julien Grall]

Hi,

On 29/01/18 20:23, Stefano Stabellini wrote:

On Mon, 29 Jan 2018, Andrew Cooper wrote:

The !HAS_ALTERNATIVE case has bit-rotten and won't even compile.

The x86 side of apply_alternatives() is void, while the ARM side returns int.
However, the functions can't fail and no return values are checked.  Switch
the ARM side to be void as well.

One observation is that __apply_alternatives_multi_stop() is only used at boot
time, so can become __init and its static data can become __initdata

Signed-off-by: Andrew Cooper 


Acked-by: Stefano Stabellini 



---
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Konrad Rzeszutek Wilk 
CC: Ross Lagerwall 

TODO: Drop the !HAS_ALTERNATIVE case on ARM?


Yeah, we could do. Julien, what do you think?


Sounds good. In that case, we should remove all the reference of 
HAS_ALTERNATIVE in the code.


Cheers,


--
Julien Grall

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

Re: [Xen-devel] [bug]xen 4.10 + dom0 4.15 couldn't boot up

[Juergen Gross]

On 30/01/18 01:33, Zhang, Xiong Y wrote:
> The message is really short. Dom0 error happens before the first kernel 
> message:
> 
> ▒ Xen 4.11-unstable
> (XEN) Xen version 4.11-unstable (test@) (gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 
> 5.4.0 20160609) debug=n  Tue Jan 30 02:38:14 CST 2018

Aah, just saw that now: can you please use a hypervisor with debug=y?
This should add some more messages to the log which might give some more
insight.

...

> (XEN) d0v0 Unhandled page fault fault/trap [#14, ec=]
> (XEN) Pagetable walk from 0028:
> (XEN)  L4[0x000] =  
> (XEN) domain_crash_sync called from entry.S: fault at 82d0803530e4 
> x86_64/entry.S#create_bounce_frame+0x135/0x151
> (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> (XEN) [ Xen-4.11-unstable  x86_64  debug=n   Not tainted ]
> (XEN) CPU:0
> (XEN) RIP:e033:[]
> (XEN) RFLAGS: 0292   EM: 1   CONTEXT: pv guest (d0v0)
> (XEN) rax:    rbx: 81e06020   rcx: 
> (XEN) rdx:    rsi: 82403e90   rdi: 82403e8c
> (XEN) rbp: 82403ec8   rsp: 82403e10   r8:  82403f00
> (XEN) r9:     r10: 82403f04   r11: 
> (XEN) r12: 82403e88   r13: 82403e78   r14: 82403e80
> (XEN) r15: 82403e84   cr0: 8005003b   cr4: 003526e0
> (XEN) cr3: 00040eb66000   cr2: 0028
> (XEN) fsb:    gsb:    gss: 
> (XEN) ds:    es:    fs:    gs:    ss: e02b   cs: e033
> (XEN) Guest stack trace from rsp=82403e10:
> (XEN)   8103f78b
> (XEN)0001e030 00010092 82403e58 e02b
> (XEN) 826591e0  
> (XEN)   
> (XEN)  826591e0 82403f04
> (XEN)82403f00 82403efc 82403ef8 82403f40
> (XEN)81040343 82403f14 82403f10 82403f0c
> (XEN)82403f08 3027  8008
> (XEN) 81032100  
> (XEN)  82403ff8 826ac35d

Can you please translate the kernel addresses in this stack dump to
symbol+offset (via disassembly of the kernel) or file+line (via
addr2line utility)?

Juergen

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

Re: [Xen-devel] [PATCH] ARM: GICv3: copy Dom0 GICv3 reg property from host DT

[Amit Tomer]

Hi,

Thanks for the patch.

On Tue, Jan 30, 2018 at 3:05 PM, Andre Przywara  wrote:
> At the moment we re-generate the Dom0 GICv3 DT node, by creating the
> "reg" property from scratch using our previously parsed and
> translated(!) host addresses. However we then write the *absolute*
> addresses into the new node, not considering possible "range" mappings
> in any of the GIC's parent nodes. So whenever one of the parents has a
> non-empty ranges property, Dom0 will wrongly translate the addresses.
> Properly incorporating the ranges properties sounds tedious, so let's
> just copy the first part of the reg property instead (as we do for GICv2),
> since the addresses for Dom0 are identical to those from the hardware.
>
> The mainline kernel DT for the Espressobin board with an Marvell 3720 SoC
> has the GIC in such an translated bus, so this patch allows this board
> to boot properly (after adding support for the SoC's UART).
>
> Signed-off-by: Andre Przywara 
> ---
>  xen/arch/arm/gic-v3.c | 29 +++--
>  1 file changed, 11 insertions(+), 18 deletions(-)
>
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index a0d290b55c..6b17abd0a1 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1147,10 +1147,9 @@ static int gicv3_make_hwdom_dt_node(const struct 
> domain *d,
>  const struct dt_device_node *gic,
>  void *fdt)
>  {
> -const void *compatible = NULL;
> -uint32_t len;
> -__be32 *new_cells, *tmp;
> -int i, res = 0;
> +const void *compatible, *hw_reg;
> +uint32_t len, new_len;
> +int res;
>
>  compatible = dt_get_property(gic, "compatible", );
>  if ( !compatible )
> @@ -1173,27 +1172,21 @@ static int gicv3_make_hwdom_dt_node(const struct 
> domain *d,
>  if ( res )
>  return res;
>
> -len = dt_cells_to_size(dt_n_addr_cells(gic) + dt_n_size_cells(gic));
> +new_len = dt_cells_to_size(dt_n_addr_cells(gic) + dt_n_size_cells(gic));
>  /*
>   * GIC has two memory regions: Distributor + rdist regions
>   * CPU interface and virtual cpu interfaces accessesed as System 
> registers
>   * So cells are created only for Distributor and rdist regions
>   */
> -len = len * (d->arch.vgic.nr_regions + 1);
> -new_cells = xzalloc_bytes(len);
> -if ( new_cells == NULL )
> -return -FDT_ERR_XEN(ENOMEM);
> -
> -tmp = new_cells;
> -
> -dt_set_range(, gic, d->arch.vgic.dbase, SZ_64K);
> +new_len = new_len * (d->arch.vgic.nr_regions + 1);
>
> -for ( i = 0; i < d->arch.vgic.nr_regions; i++ )
> -dt_set_range(, gic, d->arch.vgic.rdist_regions[i].base,
> - d->arch.vgic.rdist_regions[i].size);
> +hw_reg = dt_get_property(gic, "reg", );
> +if ( !hw_reg )
> +return -FDT_ERR_XEN(ENOENT);
> +if ( new_len > len )
> +   return -FDT_ERR_XEN(ERANGE);
>
> -res = fdt_property(fdt, "reg", new_cells, len);
> -xfree(new_cells);
> +res = fdt_property(fdt, "reg", hw_reg, new_len);
>  if ( res )
>  return res;
>
> --
> 2.14.1
>

Tested on Espresso bin:

Tested-by: Amit Singh Tomar 

Thanks
-Amit

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

[Xen-devel] [PATCH] ARM: GICv3: copy Dom0 GICv3 reg property from host DT

[Andre Przywara]

At the moment we re-generate the Dom0 GICv3 DT node, by creating the
"reg" property from scratch using our previously parsed and
translated(!) host addresses. However we then write the *absolute*
addresses into the new node, not considering possible "range" mappings
in any of the GIC's parent nodes. So whenever one of the parents has a
non-empty ranges property, Dom0 will wrongly translate the addresses.
Properly incorporating the ranges properties sounds tedious, so let's
just copy the first part of the reg property instead (as we do for GICv2),
since the addresses for Dom0 are identical to those from the hardware.

The mainline kernel DT for the Espressobin board with an Marvell 3720 SoC
has the GIC in such an translated bus, so this patch allows this board
to boot properly (after adding support for the SoC's UART).

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v3.c | 29 +++--
 1 file changed, 11 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index a0d290b55c..6b17abd0a1 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1147,10 +1147,9 @@ static int gicv3_make_hwdom_dt_node(const struct domain 
*d,
 const struct dt_device_node *gic,
 void *fdt)
 {
-const void *compatible = NULL;
-uint32_t len;
-__be32 *new_cells, *tmp;
-int i, res = 0;
+const void *compatible, *hw_reg;
+uint32_t len, new_len;
+int res;
 
 compatible = dt_get_property(gic, "compatible", );
 if ( !compatible )
@@ -1173,27 +1172,21 @@ static int gicv3_make_hwdom_dt_node(const struct domain 
*d,
 if ( res )
 return res;
 
-len = dt_cells_to_size(dt_n_addr_cells(gic) + dt_n_size_cells(gic));
+new_len = dt_cells_to_size(dt_n_addr_cells(gic) + dt_n_size_cells(gic));
 /*
  * GIC has two memory regions: Distributor + rdist regions
  * CPU interface and virtual cpu interfaces accessesed as System registers
  * So cells are created only for Distributor and rdist regions
  */
-len = len * (d->arch.vgic.nr_regions + 1);
-new_cells = xzalloc_bytes(len);
-if ( new_cells == NULL )
-return -FDT_ERR_XEN(ENOMEM);
-
-tmp = new_cells;
-
-dt_set_range(, gic, d->arch.vgic.dbase, SZ_64K);
+new_len = new_len * (d->arch.vgic.nr_regions + 1);
 
-for ( i = 0; i < d->arch.vgic.nr_regions; i++ )
-dt_set_range(, gic, d->arch.vgic.rdist_regions[i].base,
- d->arch.vgic.rdist_regions[i].size);
+hw_reg = dt_get_property(gic, "reg", );
+if ( !hw_reg )
+return -FDT_ERR_XEN(ENOENT);
+if ( new_len > len )
+   return -FDT_ERR_XEN(ERANGE);
 
-res = fdt_property(fdt, "reg", new_cells, len);
-xfree(new_cells);
+res = fdt_property(fdt, "reg", hw_reg, new_len);
 if ( res )
 return res;
 
-- 
2.14.1


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

Re: [Xen-devel] [PATCH RFC] ocaml: Fix compile with ocaml 4.06, use unsafe strings

[Christian Lindig]

> On 28. Jan 2018, at 23:44, Michael Young  wrote:
> 
>> 
>> I do not know if caml-stubdom uses any of these files, but it seems to use 
>> ocaml-3.11.0?
>> https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=stubdom/configure;h=a7a0c0915440b7b351a7adf4f40c8f9ee8e739ef;hb=refs/heads/staging#l3534
> 
> If we change this should it be the earliest version the code will support 
> (4.02) or the latest (4.06)?

I think this should be 4.02 - especially because the OCaml compiler in versions 
4.05 and 4.06 had some bugs that are now being ironed out.

— Christian


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

Re: [Xen-devel] [PATCH v3 5/5] x86: remove usage of .skip with non-absolute expressions

[Roger Pau Monné]

On Mon, Jan 29, 2018 at 09:50:56AM -0700, Jan Beulich wrote:
> >>> On 29.01.18 at 13:26,  wrote:
> > Clang assembler doesn't support using .skip with non-absolute
> > expressions:
> > 
> > entry.S:109:15: error: expected absolute expression
> > .skip .Lcr4_alt_end - .Lcr4_alt, 0x90
> >   ^
> > 
> > This usage of .skip was to fill code sections with NOPs in order for
> > them to be patched at run time if required by the alternatives
> > framework. Instead of using .skip use the appropriate number of NOPs
> > to match the size of the alternative code.
> 
> NAK - I've voiced a number of times my opposition to Andrew adding
> the various ASM_NOP in his Spectre v2 series, and I'm planning
> to eliminate them in due course (by using - you guess it - .skip). It
> is pretty much unacceptable to me to have to encode the size of
> certain instructions in a second place, risking them to go out of sync
> with what they shadow.
> 
> If ugliness like this is needed to support clang's integrated assembler,
> then I see no way other than avoiding its use.

Right, I agree this is ugly and prone to error. This seems to be fixed
in clang thunk, so I've asked for a backport of the fix to 6.0.

Roger.

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

Re: [Xen-devel] [PATCH V2 1/2] tests/xen-access: disable CR4 write events on application exit

[Razvan Cojocaru]

On 01/30/2018 11:16 AM, Razvan Cojocaru wrote:
> On exit, xen-access did not unsubscribe from CR4 write vm_events,
> potentially leaving the guest stuck.
> 
> Signed-off-by: Razvan Cojocaru 
> ---
>  tools/tests/xen-access/xen-access.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/tools/tests/xen-access/xen-access.c 
> b/tools/tests/xen-access/xen-access.c
> index 9d960e2..c572550 100644
> --- a/tools/tests/xen-access/xen-access.c
> +++ b/tools/tests/xen-access/xen-access.c
> @@ -654,6 +654,8 @@ int main(int argc, char *argv[])
>  rc = xc_monitor_cpuid(xch, domain_id, 0);
>  if ( desc_access )
>  rc = xc_monitor_descriptor_access(xch, domain_id, 0);
> +if ( write_ctrlreg_cr4 )
> +rc = xc_monitor_write_ctrlreg(xch, domain_id, 
> VM_EVENT_X86_CR4, 0, 1, 0, 1);
>  
>  if ( privcall )
>  rc = xc_monitor_privileged_call(xch, domain_id, 0);
> 

Sorry for this, I've obviously used the wrong branch. Please ignore this
patch - only "[PATCH V2 2/2] x86/hvm: fix domain crash when CR3 has the
noflush bit set" is relevant.


Thanks,
Razvan

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

[Xen-devel] [PATCH V2 1/2] tests/xen-access: disable CR4 write events on application exit

[Razvan Cojocaru]

On exit, xen-access did not unsubscribe from CR4 write vm_events,
potentially leaving the guest stuck.

Signed-off-by: Razvan Cojocaru 
---
 tools/tests/xen-access/xen-access.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/tests/xen-access/xen-access.c 
b/tools/tests/xen-access/xen-access.c
index 9d960e2..c572550 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -654,6 +654,8 @@ int main(int argc, char *argv[])
 rc = xc_monitor_cpuid(xch, domain_id, 0);
 if ( desc_access )
 rc = xc_monitor_descriptor_access(xch, domain_id, 0);
+if ( write_ctrlreg_cr4 )
+rc = xc_monitor_write_ctrlreg(xch, domain_id, 
VM_EVENT_X86_CR4, 0, 1, 0, 1);
 
 if ( privcall )
 rc = xc_monitor_privileged_call(xch, domain_id, 0);
-- 
2.7.4


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

[Xen-devel] [PATCH V2 2/2] x86/hvm: fix domain crash when CR3 has the noflush bit set

[Razvan Cojocaru]

The emulation layers of Xen lack PCID support, and as we only offer
PCID to HAP guests, all writes to CR3 are handled by hardware,
except when introspection is involved. Consequently, trying to set
CR3 when the noflush bit is set in hvm_set_cr3() leads to domain
crashes. The workaround is to clear the noflush bit in
hvm_set_cr3(). CR3 values in hvm_monitor_cr() are also sanitized.
Additionally, a bool parameter now propagates to
{svm,vmx}_update_guest_cr(), so that no flushes occur when
the bit was set.

Signed-off-by: Razvan Cojocaru 
Reported-by: Bitweasil 
Suggested-by: Andrew Cooper 

---
Changes since V1:
 - Added the bool noflush parameter and code to propagate it to
   {svm,vmx}_update_guest_cr().
 - Added X86_CR3_NOFLUSH_DISABLE_MASK and X86_CR3_NOFLUSH_DISABLE.
 - No longer sanitizing the old value in hvm_monitor_cr().
---
 xen/arch/x86/hvm/domain.c |  6 +++---
 xen/arch/x86/hvm/hvm.c| 25 -
 xen/arch/x86/hvm/monitor.c|  3 +++
 xen/arch/x86/hvm/svm/nestedsvm.c  |  4 ++--
 xen/arch/x86/hvm/svm/svm.c| 22 ++
 xen/arch/x86/hvm/svm/vmcb.c   |  4 ++--
 xen/arch/x86/hvm/vmx/vmcs.c   |  4 ++--
 xen/arch/x86/hvm/vmx/vmx.c| 16 +---
 xen/arch/x86/mm.c |  2 +-
 xen/arch/x86/mm/hap/hap.c |  6 +++---
 xen/arch/x86/mm/shadow/common.c   |  2 +-
 xen/arch/x86/mm/shadow/multi.c|  6 +++---
 xen/arch/x86/mm/shadow/none.c |  2 +-
 xen/arch/x86/monitor.c|  2 +-
 xen/include/asm-x86/hvm/hvm.h | 10 +++---
 xen/include/asm-x86/hvm/svm/svm.h |  2 +-
 xen/include/asm-x86/paging.h  |  7 ---
 17 files changed, 73 insertions(+), 50 deletions(-)

diff --git a/xen/arch/x86/hvm/domain.c b/xen/arch/x86/hvm/domain.c
index 6047464..9be085e 100644
--- a/xen/arch/x86/hvm/domain.c
+++ b/xen/arch/x86/hvm/domain.c
@@ -287,9 +287,9 @@ int arch_set_info_hvm_guest(struct vcpu *v, const 
vcpu_hvm_context_t *ctx)
 return -EINVAL;
 }
 
-hvm_update_guest_cr(v, 0);
-hvm_update_guest_cr(v, 3);
-hvm_update_guest_cr(v, 4);
+hvm_update_guest_cr(v, 0, false);
+hvm_update_guest_cr(v, 3, false);
+hvm_update_guest_cr(v, 4, false);
 hvm_update_guest_efer(v);
 
 if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) )
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c4287a3..b42fbd1 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2184,7 +2184,7 @@ static void hvm_update_cr(struct vcpu *v, unsigned int 
cr, unsigned long value)
 {
 v->arch.hvm_vcpu.guest_cr[cr] = value;
 nestedhvm_set_cr(v, cr, value);
-hvm_update_guest_cr(v, cr);
+hvm_update_guest_cr(v, cr, false);
 }
 
 int hvm_set_cr0(unsigned long value, bool_t may_defer)
@@ -2310,6 +2310,7 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
 struct vcpu *v = current;
 struct page_info *page;
 unsigned long old = v->arch.hvm_vcpu.guest_cr[3];
+bool noflush = false;
 
 if ( may_defer && unlikely(v->domain->arch.monitor.write_ctrlreg_enabled &
monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3)) )
@@ -2326,6 +2327,12 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
 }
 }
 
+if ( hvm_pcid_enabled(v) ) /* Clear the noflush bit. */
+{
+noflush = !!(value & X86_CR3_NOFLUSH);
+value &= X86_CR3_NOFLUSH_DISABLE_MASK;
+}
+
 if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) &&
  (value != v->arch.hvm_vcpu.guest_cr[3]) )
 {
@@ -2343,7 +2350,7 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
 }
 
 v->arch.hvm_vcpu.guest_cr[3] = value;
-paging_update_cr3(v);
+paging_update_cr3(v, noflush);
 return X86EMUL_OKAY;
 
  bad_cr3:
@@ -3072,7 +3079,7 @@ void hvm_task_switch(
 hvm_set_segment_register(v, x86_seg_tr, );
 
 v->arch.hvm_vcpu.guest_cr[0] |= X86_CR0_TS;
-hvm_update_guest_cr(v, 0);
+hvm_update_guest_cr(v, 0, false);
 
 if ( (taskswitch_reason == TSW_iret ||
   taskswitch_reason == TSW_jmp) && otd_writable )
@@ -3908,16 +3915,16 @@ void hvm_vcpu_reset_state(struct vcpu *v, uint16_t cs, 
uint16_t ip)
 memset(>arch.debugreg, 0, sizeof(v->arch.debugreg));
 
 v->arch.hvm_vcpu.guest_cr[0] = X86_CR0_ET;
-hvm_update_guest_cr(v, 0);
+hvm_update_guest_cr(v, 0, false);
 
 v->arch.hvm_vcpu.guest_cr[2] = 0;
-hvm_update_guest_cr(v, 2);
+hvm_update_guest_cr(v, 2, false);
 
 v->arch.hvm_vcpu.guest_cr[3] = 0;
-hvm_update_guest_cr(v, 3);
+hvm_update_guest_cr(v, 3, false);
 
 v->arch.hvm_vcpu.guest_cr[4] = 0;
-hvm_update_guest_cr(v, 4);
+hvm_update_guest_cr(v, 4, false);
 
 v->arch.hvm_vcpu.guest_efer = 0;
 hvm_update_guest_efer(v);
@@ -4044,7 +4051,7 @@ static int hvmop_flush_tlb_all(void)
 
 /* Flush paging-mode soft state (e.g., va->gfn cache; PAE 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stopfail REGR. vs. 118167

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 118347 
pass in 118438
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 
118347

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail blocked in 
118222
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop  fail in 118347 like 118222
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail in 118347 like 118222
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 118347 
like 118222
 test-amd64-i386-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail in 118347 
like 118222
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 118167
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118167
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 118167
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118222
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118222
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118222
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  a2567d6b54b7b187ecc0165021b6dd07dafaf06a
baseline version:
 xen

Re: [Xen-devel] [PATCH] xen/evtchn: Cleanup for virq_is_global() infrastructure

[Jan Beulich]

>>> On 29.01.18 at 17:16,  wrote:
> Switch it, and the arch infrastructure, to return bool.  Drop the unnecessary
> rc parameter, and remove a redundant assertion from send_global_virq().

s/parameter/variable/?

> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 
with two further remarks:

> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -93,29 +93,23 @@ static uint8_t 
> get_xen_consumer(xen_event_channel_notification_t fn)
>  /* Get the notification function for a given Xen-bound event channel. */
>  #define xen_notification_fn(e) (xen_consumers[(e)->xen_consumer-1])
>  
> -static int virq_is_global(uint32_t virq)
> +static bool virq_is_global(uint32_t virq)

Also make the parameter unsigned int at this occasion?

>  {
> -int rc;
> -
> -ASSERT(virq < NR_VIRQS);
> -
>  switch ( virq )
>  {
>  case VIRQ_TIMER:
>  case VIRQ_DEBUG:
>  case VIRQ_XENOPROF:
>  case VIRQ_XENPMU:
> -rc = 0;
> -break;
> +return false;
> +
>  case VIRQ_ARCH_0 ... VIRQ_ARCH_7:
> -rc = arch_virq_is_global(virq);
> -break;
> +return arch_virq_is_global(virq);
> +
>  default:
> -rc = 1;
> -break;
> +ASSERT(virq < NR_VIRQS);
> +return true;
>  }
> -
> -return rc;
>  }

Could I talk you into dropping the "default:" and instead put
ASSERT() and return outside of the switch()? I generally think that
where this is possible without causing compiler warnings, it results
in a more "normal" look of the overall function (in particular with a
return at the function's end, rather than giving the appearance -
without looking at all the case blocks inside the switch - that the
function returns void).

Jan


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

Re: [Xen-devel] [PATCH] x86/hvm: Drop hvm_set_mode() and associated vmx hooks

[Tian, Kevin]

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, January 30, 2018 12:11 AM
> 
> This is more vestigial rementants of PVHv1.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH RFC v2 07/12] x86: allow per-domain mappings without NX bit or with specific mfn

[Jan Beulich]

>>> On 30.01.18 at 09:02,  wrote:
> On 29/01/18 18:06, Jan Beulich wrote:
> On 22.01.18 at 13:32,  wrote:
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -1568,7 +1568,7 @@ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn,
>>>  
>>>  /* Slot 260: Per-domain mappings (if applicable). */
>>>  l4t[l4_table_offset(PERDOMAIN_VIRT_START)] =
>>> -d ? l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW)
>>> +d ? l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR)
>>>: l4e_empty();
>>>  
>>>  /* Slot 261-: text/data/bss, RW M2P, vmap, frametable, directmap. */
>>> @@ -5269,7 +5269,7 @@ int create_perdomain_mapping(struct domain *d, 
>>> unsigned long va,
>>>  }
>>>  l2tab = __map_domain_page(pg);
>>>  clear_page(l2tab);
>>> -l3tab[l3_table_offset(va)] = l3e_from_page(pg, 
>>> __PAGE_HYPERVISOR_RW);
>>> +l3tab[l3_table_offset(va)] = l3e_from_page(pg, __PAGE_HYPERVISOR);
>>>  }
>>>  else
>>>  l2tab = map_l2t_from_l3e(l3tab[l3_table_offset(va)]);
>>> @@ -5311,7 +5311,7 @@ int create_perdomain_mapping(struct domain *d, 
>>> unsigned long va,
>>>  l1tab = __map_domain_page(pg);
>>>  }
>>>  clear_page(l1tab);
>>> -*pl2e = l2e_from_page(pg, __PAGE_HYPERVISOR_RW);
>>> +*pl2e = l2e_from_page(pg, __PAGE_HYPERVISOR);
>> 
>> These changes (in the absence of the description saying otherwise)
>> leave open whether any of the per-domain mappings now suddenly
>> become executable.
> 
> Are you fine with me adding something like the following to the commit
> message:
> 
> As create_perdomain_mapping() creates L1 mappings with flags being
> __PAGE_HYPERVISOR_RW this won't change any of the current per domain
> mappings to become executable.

That would seem to be sufficient, yes.

Jan


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

Re: [Xen-devel] [PATCH 4/5] x86/alternative: Implement NMI/#MC-safe patching

[Jan Beulich]

>>> On 29.01.18 at 16:38,  wrote:
> +bool init_or_livepatch text_poke_live(const struct cpu_user_regs *regs)
> +{
> +struct live_poke_info *i = _poke_info;
> +
> +if ( unlikely(i->cpu != smp_processor_id()) )
> +{
> +ASSERT(regs);
> +
> +/*
> + * We hit a breakpoint, on a CPU which was not performing the
> + * patching.  This is only expected to be possible for the NMI/#MC
> + * paths, and even then, only if we hit the tiny race window below
> + * while patching in the NMI/#MC handlers.
> + *
> + * We can't safely evaluate whether we hit a transient breakpoint
> + * because i->cpu has likely completed the patch and moved on to the
> + * next patch site.
> + *
> + * Go to sleep for a bit and synchronise the pipeline as we are now 
> in
> + * a cross-modifying scenario.
> + */
> +cpu_relax();
> +cpuid_eax(0);
> +
> +/*
> + * Presume that we hit the transient breakpoint, as we can't confirm
> + * whether we did or not.  We don't expect there to be any other
> + * breakpoints to hit, but if we did hit another one, then in the
> + * worse case we will only livelock until i->cpu has finished all of
> + * its patching.
> + */
> +return true;
> +}
> +
> +/*
> + * We are the CPU performing the patching, and might have ended up here 
> by
> + * hitting a breakpoint.
> + *
> + * Either way, we need to complete particular patch to make forwards
> + * progress.  This logic is safe even if executed recursively in the
> + * breakpoint handler; the worst that will happen when normal execution
> + * resumes is that we will rewrite the same bytes a second time.
> + */
> +
> +/* First, insert a breakpoint to prevent execution of the patch site. */
> +i->addr[0] = 0xcc;
> +smp_wmb();

This is necessary, but not sufficient when replacing more than a
single insn: The other CPU may be executing instructions _after_
the initial one that is being replaced, and ...

> +/* Second, copy the remaining instructions into place. */
> +memcpy(i->addr + 1, i->opcode + 1, i->len - 1);

... this may be altering things underneath its feet.

> @@ -153,7 +231,31 @@ void init_or_livepatch add_nops(void *insns, unsigned 
> int len)
>  void init_or_livepatch noinline
>  text_poke(void *addr, const void *opcode, size_t len, bool live)
>  {
> -memcpy(addr, opcode, len);
> +if ( !live || len == 1 )
> +{
> +/*
> + * If we know *addr can't be executed, or we are patching a single
> + * byte, it is safe to use a straight memcpy().
> + */
> +memcpy(addr, opcode, len);

Is it really worth special casing this? Whether to actually ack
patches 2 and 3 depends on that.

> +}
> +else
> +{
> +/*
> + * If not, arrange safe patching via the use of breakpoints.  
> Ordering
> + * of actions here are between this CPU, and the instruction fetch of
> + * the breakpoint exception handler on any CPU.
> + */
> +live_poke_info = (struct live_poke_info){
> +addr, opcode, len, smp_processor_id()

Better use C99 field initializers here? At which point (together with
the next comment) it may become better not to use a compound
initializer in the first place.

> +};
> +smp_wmb();
> +active_text_patching = true;
> +smp_wmb();
> +text_poke_live(NULL);
> +smp_wmb();
> +active_text_patching = false;

Perhaps better to zap live_poke_info.cpu again here? That could
in fact replace the separate active_text_patching flag.

> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -119,6 +119,8 @@ boolean_param("ler", opt_ler);
>  #define stack_words_per_line 4
>  #define ESP_BEFORE_EXCEPTION(regs) ((unsigned long *)regs->rsp)
>  
> +bool active_text_patching;

Why here rather than in alternative.c?

> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -530,7 +530,10 @@ ENTRY(page_fault)
>  movl  $TRAP_page_fault,4(%rsp)
>  /* No special register assumptions. */
>  GLOBAL(handle_exception)
> -SAVE_ALL CLAC
> +SAVE_ALL
> +
> +handle_exception_gprs_saved:
> +ASM_CLAC

I'm not convinced it is a good idea to defer the CLAC here. I see
no problem doing the CLAC below in the INT3 path before jumping
here.

> @@ -686,9 +689,36 @@ ENTRY(debug)
>  jmp   handle_exception
>  
>  ENTRY(int3)
> +/* For patching-safety, there must not be any alternatives here. */
>  pushq $0
>  movl  $TRAP_int3,4(%rsp)
> -jmp   handle_exception
> +
> +/* If there is no patching active, continue normally.  */
> +cmpb  $1, active_text_patching(%rip)

I think it is better to compare against zero in cases like this. But
then - is this safe? 

Re: [Xen-devel] [PATCH RFC v2 07/12] x86: allow per-domain mappings without NX bit or with specific mfn

[Juergen Gross]

On 29/01/18 18:06, Jan Beulich wrote:
 On 22.01.18 at 13:32,  wrote:
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -1568,7 +1568,7 @@ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn,
>>  
>>  /* Slot 260: Per-domain mappings (if applicable). */
>>  l4t[l4_table_offset(PERDOMAIN_VIRT_START)] =
>> -d ? l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW)
>> +d ? l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR)
>>: l4e_empty();
>>  
>>  /* Slot 261-: text/data/bss, RW M2P, vmap, frametable, directmap. */
>> @@ -5269,7 +5269,7 @@ int create_perdomain_mapping(struct domain *d, 
>> unsigned long va,
>>  }
>>  l2tab = __map_domain_page(pg);
>>  clear_page(l2tab);
>> -l3tab[l3_table_offset(va)] = l3e_from_page(pg, 
>> __PAGE_HYPERVISOR_RW);
>> +l3tab[l3_table_offset(va)] = l3e_from_page(pg, __PAGE_HYPERVISOR);
>>  }
>>  else
>>  l2tab = map_l2t_from_l3e(l3tab[l3_table_offset(va)]);
>> @@ -5311,7 +5311,7 @@ int create_perdomain_mapping(struct domain *d, 
>> unsigned long va,
>>  l1tab = __map_domain_page(pg);
>>  }
>>  clear_page(l1tab);
>> -*pl2e = l2e_from_page(pg, __PAGE_HYPERVISOR_RW);
>> +*pl2e = l2e_from_page(pg, __PAGE_HYPERVISOR);
> 
> These changes (in the absence of the description saying otherwise)
> leave open whether any of the per-domain mappings now suddenly
> become executable.

Are you fine with me adding something like the following to the commit
message:

As create_perdomain_mapping() creates L1 mappings with flags being
__PAGE_HYPERVISOR_RW this won't change any of the current per domain
mappings to become executable.

> 
>> @@ -5401,6 +5401,81 @@ void destroy_perdomain_mapping(struct domain *d, 
>> unsigned long va,
>>  unmap_domain_page(l3tab);
>>  }
>>  
>> +void flipflags_perdomain_mapping(struct domain *d, unsigned long va,
>> + unsigned int flags)
> 
> Flipping flags means the caller has to know (perhaps track) what state
> the flags are in at present. I think it would be better to pass in two
> masks - one for flags to be set, and the other for flags to be cleared.

Okay.

> 
>> +void addmfn_to_perdomain_mapping(struct domain *d, unsigned long va, mfn_t 
>> mfn)
>> +{
>> +const l3_pgentry_t *l3tab, *pl3e;
>> +
>> +ASSERT(va >= PERDOMAIN_VIRT_START &&
>> +   va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS));
>> +
>> +if ( !d->arch.perdomain_l3_pg )
>> +return;
>> +
>> +l3tab = __map_domain_page(d->arch.perdomain_l3_pg);
>> +pl3e = l3tab + l3_table_offset(va);
>> +
>> +if ( l3e_get_flags(*pl3e) & _PAGE_PRESENT )
>> +{
>> +const l2_pgentry_t *l2tab = map_l2t_from_l3e(*pl3e);
>> +const l2_pgentry_t *pl2e = l2tab + l2_table_offset(va);
>> +
>> +if ( l2e_get_flags(*pl2e) & _PAGE_PRESENT )
>> +{
>> +l1_pgentry_t *l1tab = map_l1t_from_l2e(*pl2e);
>> +unsigned int off = l1_table_offset(va);
>> +
>> +if ( (l1e_get_flags(l1tab[off]) & (_PAGE_PRESENT | 
>> _PAGE_AVAIL0)) ==
>> + (_PAGE_PRESENT | _PAGE_AVAIL0) )
>> +free_domheap_page(l1e_get_page(l1tab[off]));
>> +
>> +l1tab[off] = l1e_from_mfn(mfn, __PAGE_HYPERVISOR_RW);
>> +
>> +unmap_domain_page(l1tab);
>> +}
>> +
>> +unmap_domain_page(l2tab);
>> +}
>> +
>> +unmap_domain_page(l3tab);
>> +}
> 
> Here even more than in the flipflags function - what if an
> intermediate page table entry was not present? The caller will
> have no ideal that what was requested wasn't carried out.

I'll add returning -ENOENT for both functions in that case.


Juergen

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