Re: [Xen-devel] [PATCH v2] docs: note default for timer_mode in xl.cfg man

[Roger Pau Monné]

On Mon, Jan 15, 2018 at 08:45:51AM -0600, Doug Goldstein wrote:
> There was no default documented but the header at
> xen/include/public/hvm/params.h stated which the default was, so add it
> to the docs.

While looking at libxl code I've found the following (it's at the end
of libxl__domain_build_info_setdefault):

/* Configuration fields shared between PVH and HVM. */
if (b_info->type != LIBXL_DOMAIN_TYPE_PV) {
if (libxl__timer_mode_is_default(_info->timer_mode))
b_info->timer_mode = LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
...

Which means that in libxl the default timer mode is
no_delay_for_missed_ticks instead of delay_for_missed_ticks, so I'm
afraid you will have to fixup the xl.cfg change below.

Thanks, Roger.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   6 libvirt-buildfail REGR. vs. 117772
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 117772
 build-arm64-libvirt   6 libvirt-buildfail REGR. vs. 117772
 build-armhf-libvirt   6 libvirt-buildfail REGR. vs. 117772

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a

version targeted for testing:
 libvirt  44601840ddb233d9ce9ec72d67bdab74d208f32d
baseline version:
 libvirt  335ea94e311fdd3fd590677e11ff2248fd116f2b

Last test of basis   117772  2018-01-10 11:26:35 Z5 days
Failing since117889  2018-01-12 00:26:05 Z3 days4 attempts
Testing same since   117939  2018-01-13 12:02:55 Z2 days3 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Bjoern Walk 
  Jiri Denemark 
  John Ferlan 
  Michal Privoznik 
  Scott Garfinkle 

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  fail
 build-arm64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-libvirt-xsm blocked 
 test-arm64-arm64-libvirt-xsm blocked 
 test-armhf-armhf-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  blocked 
 test-amd64-amd64-libvirt blocked 
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-libvirt-pairblocked 
 test-amd64-i386-libvirt-pair blocked 
 test-arm64-arm64-libvirt-qcow2   blocked 
 test-armhf-armhf-libvirt-raw blocked 
 test-amd64-amd64-libvirt-vhd blocked 



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

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

Explanation of these reports, and of osstest in general, is at

Re: [Xen-devel] [PATCH v8 10/17] x86/hvm: Permit guests direct access to MSR_{SPEC_CTRL, PRED_CMD}

[Boris Ostrovsky]

On 01/15/2018 06:11 AM, Jan Beulich wrote:

On 12.01.18 at 19:01,  wrote:

For performance reasons, HVM guests should have direct access to these MSRs
when possible.

Signed-off-by: Andrew Cooper 


Reviewed-by: Jan Beulich 
with one spelling fix (see below)

As these are non-trivial changes to VMX and SVM code I think you
should have Cc-ed the maintainers (now added, and leaving the
full patch in context for them.



Reviewed-by: Boris Ostrovsky 

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

[Xen-devel] [linux-linus test] 117996: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 117945
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 117945
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 117945
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 117945
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 117945
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 117945
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 117945
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 117945
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 117945
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-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-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  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-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-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-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-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-libvirt-raw 12 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-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  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-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linuxa8750ddca918032d6349adbf9a4b6555e7db20da
baseline version:
 linuxc92a9a461dff6140c539c61e457aa97df29517d6

Last test of basis   117945  2018-01-13 15:55:40 Z1 days
Testing same since   117996  2018-01-15 00:47:18 Z0 days1 attempts


People who touched revisions under test:
  =?UTF-8?q?Christian=20K=C3=B6nig?= 
  Alan Stern 
  Andi Kleen 
  Andrea Arcangeli 
  Andrew Morton 
  Andy Lutomirski 
  Arjan van de Ven 
  Baoquan He 
  Ben Seri 
  

Re: [Xen-devel] [PATCH] x86: Meltdown band-aid against malicious 64-bit PV guests

[Rich Persaud]

On Jan 12, 2018, at 05:19, Jan Beulich  wrote:
> 
> This is a very simplistic change limiting the amount of memory a running
> 64-bit PV guest has mapped (and hence available for attacking): Only the
> mappings of stack, IDT, and TSS are being cloned from the direct map
> into per-CPU page tables. Guest controlled parts of the page tables are
> being copied into those per-CPU page tables upon entry into the guest.
> Cross-vCPU synchronization of top level page table entry changes is
> being effected by forcing other active vCPU-s of the guest into the
> hypervisor.
> 
> The change to context_switch() isn't strictly necessary, but there's no
> reason to keep switching page tables once a PV guest is being scheduled
> out.
> 
> There is certainly much room for improvement, especially of performance,
> here - first and foremost suppressing all the negative effects on AMD
> systems. But in the interest of backportability (including to really old
> hypervisors, which may not even have alternative patching) any such is
> being left out here.

Thanks for releasing this patch to support use cases not covered by the 
previous mitigations.  Is there a name or acronym we can use to reference this 
patch in the FAQ, XSA and other support documents?

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

[Xen-devel] [PATCH v2] docs: note default for timer_mode in xl.cfg man

[Doug Goldstein]

There was no default documented but the header at
xen/include/public/hvm/params.h stated which the default was, so add it
to the docs.

Signed-off-by: Doug Goldstein 
---
CC: Wei Liu 
CC: Ian Jackson 
CC: Roger Pau Monné 
# George for the 4.8 and 4.9 backport
CC: George Dunlap 

change from v1:
- added same docs addition to HVM
---
 docs/man/xl.cfg.pod.5.in | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index b7b91d8627..b6812a4033 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -1883,7 +1883,8 @@ Specifies the mode for Virtual Timers. The valid values 
are as follows:
 Delay for missed ticks. Do not advance a vCPU's time beyond the
 correct delivery time for interrupts that have been missed due to
 preemption. Deliver missed interrupts when the vCPU is rescheduled and
-advance the vCPU's virtual time stepwise for each one.
+advance the vCPU's virtual time stepwise for each one. This is the
+default.
 
 =item B
 
@@ -2348,7 +2349,8 @@ Specifies the mode for Virtual Timers. The valid values 
are as follows:
 Delay for missed ticks. Do not advance a vCPU's time beyond the
 correct delivery time for interrupts that have been missed due to
 preemption. Deliver missed interrupts when the vCPU is rescheduled and
-advance the vCPU's virtual time stepwise for each one.
+advance the vCPU's virtual time stepwise for each one. This is the
+default.
 
 =item B
 
-- 
2.13.6


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

[Xen-devel] [xen-unstable test] 118003: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 117311
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 117311
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 117311
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 117311
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 117311
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 117311
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 117311
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 117311
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 117311
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 117311
 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-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-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-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  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-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-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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-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:
 xen  2d70b54e055635ff60526b6949156504b6194b7c
baseline version:
 xen  ec320542e4f4de12305551ef5e3cd4d2ced85771

Last test of basis   117311  2017-12-19 02:35:18 Z   27 days
Failing since117365  2017-12-20 07:31:12 Z   26 days   12 attempts
Testing same since   117951  2018-01-13 19:55:59 Z1 days2 attempts


People who touched revisions under test:
  Adrian Hunter 
  Alexandru Isaila 
  Andrew Cooper 
  Andrew 

Re: [Xen-devel] Clarification regarding Meltdown and 64-bit PV guests

[Stefano Stabellini]

On Sun, 14 Jan 2018, Hans van Kranenburg wrote:
> On 14/01/2018 15:00, Dongli Zhang wrote:
> > Hi Hans,
> > 
> > On 01/13/2018 07:12 PM, Hans van Kranenburg wrote:
> >> On 01/13/2018 11:08 AM, Andy Smith wrote:
> >>> Hi Hans,
> >>>
> >>> On Sat, Jan 13, 2018 at 10:43:03AM +0100, Hans van Kranenburg wrote:
>  By injecting a copy of a hypervisor between the outer level hypervisor
>  (that's called L0 right?) (in HVM or PVH mode) and the guest, having it
>  just run 1 guest, that (64-bit PV) guest cannot attack its own kernel,
>  but it can attack the intermediate hypervisor which results in reading
>  it's own memory from the fake intermediate "host memory".
> >>>
> >>> So are you saying that, considering only SP3/Variant 3/Meltdown, it
> >>> works out like this:
> >>>
> >>> == 64-bit PV mode guest ==
> >>>
> >>> - Can't use SP3/Variant 3/Meltdown directly on its own kernel.
> >>>
> >>> - Can use SP3/Variant 3/Meltdown on the hypervisor to read data from
> >>>   hypervisor so effectively everything including other kernels and
> >>>   its own kernel.
> >>>
> >>> - Can't be mitigated by KPTI in the guest.
> >>>
> >>> == PV-in-Comet and PV-in-Vixen ==
> >>>
> >>> - Can't use SP3/Variant 3/Meltdown directly on its own kernel
> >>>
> >>> - Can't use SP3/Variant 3/Meltdown on the real hypervisor.
> >>>
> >>> - Can still use SP3/Variant 3/Meltdown on the shim hypervisor to
> >>>   still gain access to data from itself.
> >>>
> >>> - Can't be mitigated by KPTI in the guest.
> >>>
> >>> == HVM and PVHv2 ==
> >>>
> >>> - Can use SP3/Variant 3/Meltdown directly on its own kernel.
> >>>
> >>> - Can't use SP3/Variant 3/Meltdown on the hypervisor.
> >>>
> >>> - Can be mitigated by KPTI in the guest (becomes not a Xen issue).
> >>>
> >>> ?
> >>
> >> Exactly.
> > 
> > Does this indicate that there is no solution to prevent a malicious user 
> > space
> > program (running on 64-bit PV domU) from reading the memory of domU kernel 
> > space
> > (via meltdown), no matter whether comet/vixen is enabled or not?
> > 
> > Therefore, comet/vixen is only used to prevent the cross-VM meltdown attack.
> 
> Yes.

Keep an eye on this series, and future follow-ups:

https://marc.info/?l=xen-devel=151601415717228

It mitigates Meltdown/SP3 for Xen without introducing an intermediate
hypervisor. Thus, it protects Xen while retaining the property that the
guest kernel is already protected from the guest userspace because it
runs in a KPTI-like mode.

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

Re: [Xen-devel] [PATCH] remove dead code in allocate_memory

[Julien Grall]

Hi Stefano,

On 01/13/2018 12:29 AM, Stefano Stabellini wrote:

lowmem is unchanged until after this loop, there is no point in testing
for its value. Moreover, Coverity complains about dead code.

Remove the lowmem test in the first loop.


While I understand Coverity complains about dead code, in that 
particular case I don't think removing this test is the right thing to do.


It is very easy to toggle lowmen to false in the declaration as this was 
done before ab5b00a "xen/arm: domain_build: allocate lowmem for dom0 as 
much as possible". One example would be keep low memory free for other 
purpose.


Cheers,



CID: 1381832
Signed-off-by: Stefano Stabellini 

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 155c952..fa58906 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -277,7 +277,7 @@ static void allocate_memory(struct domain *d, struct 
kernel_info *kinfo)
   */
  while ( order >= min_low_order )
  {
-for ( bits = order ; bits <= (lowmem ? 32 : PADDR_BITS); bits++ )
+for ( bits = order ; bits <= 32; bits++ )
  {
  pg = alloc_domheap_pages(d, order, MEMF_bits(bits));
  if ( pg != NULL )



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

Re: [Xen-devel] [PATCH v2] docs: note default for timer_mode in xl.cfg man

[Doug Goldstein]

On 1/15/18 9:59 AM, Roger Pau Monné wrote:
> On Mon, Jan 15, 2018 at 08:45:51AM -0600, Doug Goldstein wrote:
>> There was no default documented but the header at
>> xen/include/public/hvm/params.h stated which the default was, so add it
>> to the docs.
> 
> While looking at libxl code I've found the following (it's at the end
> of libxl__domain_build_info_setdefault):
> 
> /* Configuration fields shared between PVH and HVM. */
> if (b_info->type != LIBXL_DOMAIN_TYPE_PV) {
> if (libxl__timer_mode_is_default(_info->timer_mode))
> b_info->timer_mode = LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
> ...
> 
> Which means that in libxl the default timer mode is
> no_delay_for_missed_ticks instead of delay_for_missed_ticks, so I'm
> afraid you will have to fixup the xl.cfg change below.
> 
> Thanks, Roger.
> 

Well thank you for verifying this in the code instead of the headers
like I did. Follow up coming where I'll fix the header and the docs to
match the code.

-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH] don't pass r12/x16 as reference

[Stefano Stabellini]

On Sat, 13 Jan 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 01/13/2018 12:07 AM, Stefano Stabellini wrote:
> > r12 and x16 are of different sizes; when passing r12 as a reference to
> > do_trap_hypercall on arm64, we end up dereferencing it as a pointer to a
> > 64bit value, but actually it isn't.
> > 
> > Instead, pass r12/x16 as values and explicitly overwrite them when
> > necessary, using the pointer name.
> > 
> > CID: 1457708
> > Signed-off-by: Stefano Stabellini 
> > 
> > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > index 013c160..3b31917 100644
> > --- a/xen/arch/arm/traps.c
> > +++ b/xen/arch/arm/traps.c
> > @@ -1453,6 +1453,7 @@ static void do_debug_trap(struct cpu_user_regs *regs,
> > unsigned int code)
> > #ifdef CONFIG_ARM_64
> >   #define HYPERCALL_RESULT_REG(r) (r)->x0
> > +#define HYPERCALL_NR(r) (r)->x16
> >   #define HYPERCALL_ARG1(r) (r)->x0
> >   #define HYPERCALL_ARG2(r) (r)->x1
> >   #define HYPERCALL_ARG3(r) (r)->x2
> > @@ -1461,6 +1462,7 @@ static void do_debug_trap(struct cpu_user_regs *regs,
> > unsigned int code)
> >   #define HYPERCALL_ARGS(r) (r)->x0, (r)->x1, (r)->x2, (r)->x3, (r)->x4
> >   #else
> >   #define HYPERCALL_RESULT_REG(r) (r)->r0
> > +#define HYPERCALL_NR(r) (r)->r12
> >   #define HYPERCALL_ARG1(r) (r)->r0
> >   #define HYPERCALL_ARG2(r) (r)->r1
> >   #define HYPERCALL_ARG3(r) (r)->r2
> > @@ -1469,7 +1471,7 @@ static void do_debug_trap(struct cpu_user_regs *regs,
> > unsigned int code)
> >   #define HYPERCALL_ARGS(r) (r)->r0, (r)->r1, (r)->r2, (r)->r3, (r)->r4
> >   #endif
> >   -static void do_trap_hypercall(struct cpu_user_regs *regs, register_t *nr,
> > +static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned int nr,
> > unsigned long iss)
> >   {
> >   arm_hypercall_fn_t call = NULL;
> > @@ -1479,7 +1481,7 @@ static void do_trap_hypercall(struct cpu_user_regs
> > *regs, register_t *nr,
> >   if ( iss != XEN_HYPERCALL_TAG )
> >   domain_crash_synchronous();
> >   -if ( *nr >= ARRAY_SIZE(arm_hypercall_table) )
> > +if ( nr >= ARRAY_SIZE(arm_hypercall_table) )
> >   {
> >   perfc_incr(invalid_hypercalls);
> >   HYPERCALL_RESULT_REG(regs) = -ENOSYS;
> > @@ -1488,8 +1490,8 @@ static void do_trap_hypercall(struct cpu_user_regs
> > *regs, register_t *nr,
> > current->hcall_preempted = false;
> >   -perfc_incra(hypercalls, *nr);
> > -call = arm_hypercall_table[*nr].fn;
> > +perfc_incra(hypercalls, nr);
> > +call = arm_hypercall_table[nr].fn;
> >   if ( call == NULL )
> >   {
> >   HYPERCALL_RESULT_REG(regs) = -ENOSYS;
> > @@ -1502,7 +1504,7 @@ static void do_trap_hypercall(struct cpu_user_regs
> > *regs, register_t *nr,
> >   if ( !current->hcall_preempted )
> >   {
> >   /* Deliberately corrupt parameter regs used by this hypercall. */
> > -switch ( arm_hypercall_table[*nr].nr_args ) {
> > +switch ( arm_hypercall_table[nr].nr_args ) {
> >   case 5: HYPERCALL_ARG5(regs) = 0xDEADBEEF;
> >   case 4: HYPERCALL_ARG4(regs) = 0xDEADBEEF;
> >   case 3: HYPERCALL_ARG3(regs) = 0xDEADBEEF;
> > @@ -1511,7 +1513,7 @@ static void do_trap_hypercall(struct cpu_user_regs
> > *regs, register_t *nr,
> >   break;
> >   default: BUG();
> >   }
> > -*nr = 0xDEADBEEF;
> > +HYPERCALL_NR(regs) = 0xDEADBEEF;
> 
> This change is not correct. You don't take into account the fact that on
> 32-bit domain, the result register will be r12 and 64-bit domain x16.

I defined HYPERCALL_NR differently depending on CONFIG_ARM_64, but you
are right, that's not right, because it will misbehave for 32-bit guests
on a 64-bit hypervisor.


> >   }
> >   #endif
> >   @@ -2131,7 +2133,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, (register_t *)>r12, hsr.iss);
> > +do_trap_hypercall(regs, regs->r12, hsr.iss);
> 
> IHMO it would be better to avoid modify do_trap_hypercall and just save r12 in
> a temporary variable, use that variable as 2 second argument and write-back
> the variable in r12.
> 
> This would make do_trap_hypercall future proof.

Sounds good.


> >   break;
> >   #ifdef CONFIG_ARM_64
> >   case HSR_EC_HVC64:
> > @@ -2143,7 +2145,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, regs->x16, hsr.iss);
> >   break;
> >   case HSR_EC_SMC64:
> >   /*
> > 
> 
> Cheers,
> 

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

Re: [Xen-devel] [PATCH v2 1/2] x86: Meltdown band-aid against malicious 64-bit PV guests

[Andrew Cooper]

On 15/01/18 11:06, Jan Beulich wrote:
> This is a very simplistic change limiting the amount of memory a running
> 64-bit PV guest has mapped (and hence available for attacking): Only the
> mappings of stack, IDT, and TSS are being cloned from the direct map
> into per-CPU page tables. Guest controlled parts of the page tables are
> being copied into those per-CPU page tables upon entry into the guest.
> Cross-vCPU synchronization of top level page table entry changes is
> being effected by forcing other active vCPU-s of the guest into the
> hypervisor.
>
> The change to context_switch() isn't strictly necessary, but there's no
> reason to keep switching page tables once a PV guest is being scheduled
> out.
>
> There is certainly much room for improvement, especially of performance,
> here - first and foremost suppressing all the negative effects on AMD
> systems. But in the interest of backportability (including to really old
> hypervisors, which may not even have alternative patching) any such is
> being left out here.
>
> Signed-off-by: Jan Beulich 
> ---
> v2: Use sensible numbers for the register classification constants also
> for the low 8 registers. Insert 'r' into their names to make their
> purpose more clear. Use "sub" instead of "add" when adding an
> immediate of 128. Defer sync IPI in do_mmu_update() until the end of
> the main loop. Use flush IPI there instead event check one. Make
> setup functions return a proper error code. Use better suited local
> variables in clone_mapping(). Add comment to new struct cpu_info
> fields.
> ---
> This also wants Andrew's "[PATCH RFC 11/44] x86/pt-shadow: Always set
> _PAGE_ACCESSED on L4e updates".

I've cleaned this patch up and committed it in preparation.

http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=bd61fe94bee0556bc2f64999a4a8315b93f90f21

> ---
> Backporting notes:
> - This needs f9eb74789a ("x86/entry: Remove support for partial
>   cpu_user_regs frames") as a prereq, due to the uses of %r14 and %r15.
>   But that's intended to be backported anyway (for Spectre/SP2).
> - The use of "root" instead of "l4" here is mainly to not make 5-level
>   page table additions any harder. In backports "l4" should probably be
>   preferred.
> ---
> Follow-up notes:
> - use alternatives patching for fully suppressing performance effects
>   when disabled
> - check whether running globally with CR4.PGE clear helps overall
>   performance
>
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -1511,6 +1511,9 @@ void paravirt_ctxt_switch_to(struct vcpu
>  {
>  unsigned long cr4;
>  
> +this_cpu(root_pgt)[root_table_offset(PERDOMAIN_VIRT_START)] =
> +l4e_from_page(v->domain->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW);
> +
>  cr4 = pv_guest_cr4_to_real_cr4(v);
>  if ( unlikely(cr4 != read_cr4()) )
>  write_cr4(cr4);
> @@ -1682,6 +1685,8 @@ void context_switch(struct vcpu *prev, s
>  
>  ASSERT(local_irq_is_enabled());
>  
> +get_cpu_info()->xen_cr3 = 0;
> +
>  cpumask_copy(_mask, next->vcpu_dirty_cpumask);
>  /* Allow at most one CPU at a time to be dirty. */
>  ASSERT(cpumask_weight(_mask) <= 1);
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -3520,6 +3520,7 @@ long do_mmu_update(
>  struct vcpu *curr = current, *v = curr;
>  struct domain *d = v->domain, *pt_owner = d, *pg_owner;
>  mfn_t map_mfn = INVALID_MFN;
> +bool sync_guest = false;
>  uint32_t xsm_needed = 0;
>  uint32_t xsm_checked = 0;
>  int rc = put_old_guest_table(curr);
> @@ -3683,6 +3684,8 @@ long do_mmu_update(
>  break;
>  rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn,
>cmd == MMU_PT_UPDATE_PRESERVE_AD, v);
> +if ( !rc )
> +sync_guest = true;
>  break;
>  
>  case PGT_writable_page:
> @@ -3787,6 +3790,24 @@ long do_mmu_update(
>  if ( va )
>  unmap_domain_page(va);
>  
> +if ( sync_guest )
> +{
> +/*
> + * Force other vCPU-s of the affected guest to pick up L4 entry
> + * changes (if any). Issue a flush IPI with empty operation mask to
> + * facilitate this (including ourselves waiting for the IPI to
> + * actually have arrived). Utilize the fact that FLUSH_VA_VALID is
> + * meaningless without FLUSH_CACHE, but will allow to pass the no-op
> + * check in flush_area_mask().
> + */
> +unsigned int cpu = smp_processor_id();
> +cpumask_t *mask = per_cpu(scratch_cpumask, cpu);
> +
> +cpumask_andnot(mask, pt_owner->domain_dirty_cpumask, 
> cpumask_of(cpu));
> +if ( !cpumask_empty(mask) )
> +flush_area_mask(mask, ZERO_BLOCK_PTR, FLUSH_VA_VALID);
> +}
> +
>  perfc_add(num_page_updates, i);
>  
>   out:
> --- a/xen/arch/x86/smpboot.c
> +++ 

[Xen-devel] [PATCH v2] -xen-attach is needed for pvh boot with qemu-xen

[Michael Young]

Currently the boot of a pvh guest using the qemu-xen device model fails
with the error
xen emulation not implemented (yet)
in the qemu-dm log file. This patch adds the missing -xen-attach
argument.

V2: Use  b_info->type != LIBXL_DOMAIN_TYPE_HVMinstead of
(b_info->type == LIBXL_DOMAIN_TYPE_PV) ||
(b_info->type == LIBXL_DOMAIN_TYPE_PVH)
as recommended by Roger Pau Monné.

Signed-off-by: Michael Young 
Reviewed-by: Roger Pau Monné 

---
 tools/libxl/libxl_dm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index a2ea95a9be..a3cddce8b7 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1021,7 +1021,7 @@ static int libxl__build_device_model_args_new(libxl__gc 
*gc,
  */
 flexarray_append(dm_args, "-no-user-config");

-if (b_info->type == LIBXL_DOMAIN_TYPE_PV) {
+if (b_info->type != LIBXL_DOMAIN_TYPE_HVM) {
 flexarray_append(dm_args, "-xen-attach");
 }

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

Re: [Xen-devel] [PATCH v8 15/17] x86/ctxt: Issue a speculation barrier between vcpu contexts

[David Woodhouse]

On Mon, 2018-01-15 at 14:23 +0100, David Woodhouse wrote:
> 
> > > 
> > > Also... if you're doing that in context_switch() does it do the right
> > > thing with idle? If a CPU switches to the idle domain and then back
> > > again to the same vCPU, does that do the IBPB twice?
> >
> > Context switches to idle will skip the IBPB because it isn't needed, but
> > any switch to non-idle need it.  In your example, we should execute just
> > a single IBPB.
> 
> In my example I think we should not execute IBPB at all. We come from a
> given VMCS, sleep for a while, and go back to it. No need for any
> flushing whatsoever.

msw points out that in my example we *don't* execute IBPB at all, I
think.

In both switching to idle, and back to the vCPU, we should hit this
case and not the 'else' case that does the IBPB:

1710 if ( (per_cpu(curr_vcpu, cpu) == next) ||
1711  (is_idle_domain(nextd) && cpu_online(cpu)) )
1712 {
1713 local_irq_enable();
1714 }


smime.p7s
Description: S/MIME cryptographic signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Unexpected behavior: Xen creating domains on startup

[Bruno Alvisio]

Hello all,

I am doing some testing with Xen. After some of the guest domains I am
testing crashed, I decided to add some logging to Xen and the tools. After
rebuilding, reinstalling and rebooting the system, Xen seems to create
guest domains (the ones created before reboot) on startup (with no 'xl
create' command issued by me). The domains are deleted a few seconds after
startup and when I create the first domain, the domain number is not 1 but
3 or 4. Below is an example of dmesg logs right after startup: (int this
case a domain 2 was launched, xl list shows no domain few seconds later):

(XEN) Dom0 has maximum 8 VCPUs

(XEN) ELF: phdr 0 at 0x8100 -> 0x81aca000

(XEN) ELF: phdr 1 at 0x81c0 -> 0x81d1e000

(XEN) ELF: phdr 2 at 0x81d1e000 -> 0x81d37418

(XEN) ELF: phdr 3 at 0x81d38000 -> 0x81e82000

(XEN) Initial low memory virq threshold set at 0x4000 pages.

(XEN) Scrubbing Free RAM on 1 nodes using 4 CPUs

(XEN) ..done.

(XEN) Std. Loglevel: All

(XEN) Guest Loglevel: All

(XEN) Xen is relinquishing VGA console.

(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input
to Xen)

(XEN) Freed 456kB init memory

(XEN) PCI add device :00:00.0

(XEN) PCI add device :00:01.0

(XEN) PCI add device :00:16.0

(XEN) PCI add device :00:16.1

(XEN) PCI add device :00:1a.0

(XEN) PCI add device :00:1d.0

(XEN) PCI add device :00:1e.0

(XEN) PCI add device :00:1f.0

(XEN) PCI add device :00:1f.2

(XEN) PCI add device :00:1f.3

(XEN) PCI add device :01:00.0

(XEN) PCI add device :01:00.1

(XEN) PCI add device :02:03.0

(XEN) PCI: Using MCFG for segment  bus 00-ff

(XEN) d0: Forcing read-only access to MFN fed00

(XEN) traps.c:1540: GPF (): 82d080363383
[emul-priv-op.c#read_msr+0x370/0x45c] -> 82d08036d9b2

(XEN) traps.c:1540: GPF (): 82d080363383
[emul-priv-op.c#read_msr+0x370/0x45c] -> 82d08036d9b2

(XEN) traps.c:1540: GPF (): 82d080363383
[emul-priv-op.c#read_msr+0x370/0x45c] -> 82d08036d9b2

(XEN) grant_table.c:1688:d0v1 Expanding d1 grant table from 0 to 1 frames

(XEN) HVM1 restore: CPU 0

(XEN) HVM1 restore: CPU 1

(XEN) HVM1 restore: PIC 0

(XEN) HVM1 restore: PIC 1

(XEN) HVM1 restore: IOAPIC 0

(XEN) HVM1 restore: LAPIC 0

(XEN) HVM1 restore: LAPIC 1

(XEN) HVM1 restore: LAPIC_REGS 0

(XEN) HVM1 restore: LAPIC_REGS 1

(XEN) HVM1 restore: PCI_IRQ 0

(XEN) HVM1 restore: ISA_IRQ 0

(XEN) HVM1 restore: PCI_LINK 0

(XEN) HVM1 restore: PIT 0

(XEN) HVM1 restore: RTC 0

(XEN) HVM1 restore: HPET 0

(XEN) HVM1 restore: PMTIMER 0

(XEN) HVM1 restore: MTRR 0

(XEN) HVM1 restore: MTRR 1

(XEN) HVM1 restore: CPU_XSAVE 0

(XEN) HVM1 restore: CPU_XSAVE 1

(XEN) HVM1 restore: VMCE_VCPU 0

(XEN) HVM1 restore: VMCE_VCPU 1

(XEN) HVM1 restore: TSC_ADJUST 0

(XEN) HVM1 restore: TSC_ADJUST 1

(XEN) grant_table.c:1688:d0v6 Expanding d2 grant table from 0 to 1 frames

(d2) Bootstrapping...

(d2) Xen Minimal OS (pv)!

(d2)   start_info: 0x574000(VA)

(d2) nr_pages: 0x2000
(d2)   shared_inf: 0x06182000(MA)


Any explanation/idea on what could be occurring would be appreciated.

Cheers,

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

[Xen-devel] Xen on RCarH3 Starter Kit

[Ganesh H]

Hi,

Does Xen support RCarH3 Starter Kit -  https://elinux.org/R-Car/Boards/H3SK

I followed the build procedures explained in this link for Salvator X - 
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X

But the Yocto build instructions given in the link is for RcarH3 Starter kit.So 
I am unable to find Image-r8a7795-salvator-x-xen.dtb and xen-salvator-x.uImage 
which is mentioned in the tutorial.
Can anyone explain what can be the issue and the fix for it. Does the Xen dtb 
and uImage for salvator will work on RCarH3 starter kit.

Best Regards
Ganesh.H


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

[Xen-devel] [xen-4.8-testing test] 118036: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale  17 guest-start.2fail in 117980 pass in 118036
 test-armhf-armhf-xl-rtds 12 guest-start  fail in 117980 pass in 118036
 test-xtf-amd64-amd64-4 49 xtf/test-hvm64-lbr-tsx-vmentry fail in 117980 pass 
in 118036
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail pass in 117980
 test-armhf-armhf-libvirt-raw 16 guest-start.2  fail pass in 117980

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-3 49 xtf/test-hvm64-lbr-tsx-vmentry fail in 117980 like 
117697
 test-xtf-amd64-amd64-2  49 xtf/test-hvm64-lbr-tsx-vmentry fail like 117586
 test-xtf-amd64-amd64-1  49 xtf/test-hvm64-lbr-tsx-vmentry fail like 117697
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 117697
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 117697
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 117697
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 117697
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 117697
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 117697
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 117697
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 117697
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 117697
 build-i386-prev   7 xen-build/dist-test  fail   never pass
 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-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-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  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-libvirt-xsm 14 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-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-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  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-libvirt 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-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail 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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-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-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install  

Re: [Xen-devel] [PATCH v2 1/2] x86: Meltdown band-aid against malicious 64-bit PV guests

[Jan Beulich]

>>> On 15.01.18 at 19:23,  wrote:
> On 15/01/18 11:06, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_64/compat/entry.S
>> +++ b/xen/arch/x86/x86_64/compat/entry.S
>> @@ -199,6 +199,17 @@ ENTRY(cstar_enter)
>>  pushq $0
>>  movl  $TRAP_syscall, 4(%rsp)
>>  SAVE_ALL
>> +
>> +GET_STACK_END(bx)
>> +mov   STACK_CPUINFO_FIELD(xen_cr3)(%rbx), %rcx
>> +neg   %rcx
>> +UNLIKELY_START(nz, cstar_cr3)
>> +mov   %rcx, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
>> +neg   %rcx
>> +write_cr3 rcx, rdi, rsi
>> +movq  $0, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
>> +UNLIKELY_END(cstar_cr3)
> 
> These UNLIKELY()s aren't correct.  It will depend on hardware and
> command line setting as to whether we expect to update cr3.

Why are they not correct? What 64-bit kernels do you know that
use the CSTAR entry method in PV mode? Afaik this was in
existence for a range of kernel versions only in our forward port.
The INT80 path is perhaps indeed more questionable in this regard.

> Furthermore, they will complicate splitting the early entry code away
> from the main .text section for a full isolation implementation.
> 
> For now, I'd drop them and have a simple jz .Lskip.

I will replace them (on the entry paths; I think the one on the exit-
to-Xen path is valid) to please you and in the interest of forward
progress; maybe this will even slightly help backporting to really old
Xen versions, where the UNLIKELY* constructs don't exist yet.

> Also, can we collect these together into macros, rather than
> opencoding?  We seem to have 3 distinct variations.

I had considered that (following the model you use in the SP2
series), but decided against it not the least because of the
dependent but placement-wise separated code additions to
restore original values. Plus again this might be a hindrance of
backporting to really old Xen (which then typically will also be
built on really old tool chains) - as you certainly recall old gas
had quite a few issues with macro handling.

>> --- a/xen/arch/x86/x86_64/entry.S
>> +++ b/xen/arch/x86/x86_64/entry.S
>> @@ -37,6 +37,32 @@ ENTRY(switch_to_kernel)
>>  /* %rbx: struct vcpu, interrupts disabled */
>>  restore_all_guest:
>>  ASSERT_INTERRUPTS_DISABLED
>> +
>> +/* Copy guest mappings and switch to per-CPU root page table. */
>> +mov   %cr3, %r9
>> +GET_STACK_END(dx)
>> +mov   STACK_CPUINFO_FIELD(pv_cr3)(%rdx), %rdi
>> +movabs $PADDR_MASK & PAGE_MASK, %rsi
>> +movabs $DIRECTMAP_VIRT_START, %rcx
>> +mov   %rdi, %rax
>> +and   %rsi, %rdi
>> +and   %r9, %rsi
>> +add   %rcx, %rdi
>> +add   %rcx, %rsi
>> +mov   $ROOT_PAGETABLE_FIRST_XEN_SLOT, %ecx
>> +mov   root_table_offset(SH_LINEAR_PT_VIRT_START)*8(%rsi), %r8
>> +mov   %r8, root_table_offset(SH_LINEAR_PT_VIRT_START)*8(%rdi)
>> +rep movsq
>> +mov   $ROOT_PAGETABLE_ENTRIES - \
>> +   ROOT_PAGETABLE_LAST_XEN_SLOT - 1, %ecx
>> +sub   $(ROOT_PAGETABLE_FIRST_XEN_SLOT - \
>> +ROOT_PAGETABLE_LAST_XEN_SLOT - 1) * 8, %rsi
>> +sub   $(ROOT_PAGETABLE_FIRST_XEN_SLOT - \
>> +ROOT_PAGETABLE_LAST_XEN_SLOT - 1) * 8, %rdi
>> +rep movsq
>> +mov   %r9, STACK_CPUINFO_FIELD(xen_cr3)(%rdx)
>> +write_cr3 rax, rdi, rsi
>> +
> 
> Can we possibly move this up into C?  For this simplistic algorithm it
> is ok in ASM, but if we want to do any optimisations to avoid the 4k
> memcpy (generation count hidden somewhere in page_info?), ASM is going
> quickly become unwieldy.

I'd prefer to move it into C when it really becomes necessary. Also
you don't properly qualify "this" - for example, I'd rather not move
the write_cr3 invocation into C, yet the placement of your comment
suggests to do so.

> Another optimisation I found made a massive difference for the KAISER
> series was to have an MRU cache of 4 pagetables, so in-guest syscalls
> don't result in any copying as we pass in and out of Xen.

As said elsewhere - optimization can come later. Plus - is avoiding the
copying at _any_ time actually correct, considering possible racing
L4 entry updates on another vCPU?

>> @@ -71,6 +97,18 @@ iret_exit_to_guest:
>>  ALIGN
>>  /* No special register assumptions. */
>>  restore_all_xen:
>> +/*
>> + * Check whether we need to switch to the per-CPU page tables, in
>> + * case we return to late PV exit code (from an NMI or #MC).
>> + */
>> +GET_STACK_END(ax)
>> +mov   STACK_CPUINFO_FIELD(xen_cr3)(%rax), %rdx
>> +mov   STACK_CPUINFO_FIELD(pv_cr3)(%rax), %rax
>> +test  %rdx, %rdx
>> +UNLIKELY_START(g, exit_cr3)
> 
> cmp or ne ?

"ne" (or really "nz" when used with "test") is outright wrong - we
want to skip the restore when the value is zero _or_ negative.
What's wrong with "jg" and "test" in combination? There simply 

Re: [Xen-devel] [PATCH V5] pci: removed the is_express field since a uniform interface was inserted

[Michael S. Tsirkin]

On Mon, Dec 18, 2017 at 05:21:40PM +0200, Yoni Bettan wrote:
> according to Eduardo Habkost's commit fd3b02c889 all PCIEs now implement
> INTERFACE_PCIE_DEVICE so we don't need is_express field anymore.
> 
> Devices that implements only INTERFACE_PCIE_DEVICE (is_express == 1)
> or
> devices that implements only INTERFACE_CONVENTIONAL_PCI_DEVICE (is_express == 
> 0)
> where not affected by the change.
> 
> The only devices that were affected are those that are hybrid and also
> had (is_express == 1) - therefor only:
>   - hw/vfio/pci.c
>   - hw/usb/hcd-xhci.c
>   - hw/xen/xen_pt.c
> 
> For those 3 I made sure that QEMU_PCI_CAP_EXPRESS is on in instance_init()
> 
> Signed-off-by: Yoni Bettan 


Thanks!
Could you pls rebase this on top of the latest pci branch?
There's been some conflicting changes so this no longer
applies cleanly.


> ---
>  docs/pcie_pci_bridge.txt   | 2 +-
>  hw/block/nvme.c| 1 -
>  hw/net/e1000e.c| 1 -
>  hw/pci-bridge/pcie_pci_bridge.c| 1 -
>  hw/pci-bridge/pcie_root_port.c | 1 -
>  hw/pci-bridge/xio3130_downstream.c | 1 -
>  hw/pci-bridge/xio3130_upstream.c   | 1 -
>  hw/pci-host/xilinx-pcie.c  | 1 -
>  hw/pci/pci.c   | 8 ++--
>  hw/scsi/megasas.c  | 4 
>  hw/usb/hcd-xhci.c  | 9 -
>  hw/vfio/pci.c  | 5 -
>  hw/xen/xen_pt.c| 9 -
>  include/hw/pci/pci.h   | 3 ---
>  14 files changed, 27 insertions(+), 20 deletions(-)
> 
> diff --git a/docs/pcie_pci_bridge.txt b/docs/pcie_pci_bridge.txt
> index 5a4203f97c..ab35ebf3ca 100644
> --- a/docs/pcie_pci_bridge.txt
> +++ b/docs/pcie_pci_bridge.txt
> @@ -110,5 +110,5 @@ To enable device hot-plug into the bridge on Linux 
> there're 3 ways:
>  Implementation
>  ==
>  The PCIE-PCI bridge is based on PCI-PCI bridge, but also accumulates PCI 
> Express
> -features as a PCI Express device (is_express=1).
> +features as a PCI Express device.
>  
> diff --git a/hw/block/nvme.c b/hw/block/nvme.c
> index 441e21ed1f..9325bc0911 100644
> --- a/hw/block/nvme.c
> +++ b/hw/block/nvme.c
> @@ -1087,7 +1087,6 @@ static void nvme_class_init(ObjectClass *oc, void *data)
>  pc->vendor_id = PCI_VENDOR_ID_INTEL;
>  pc->device_id = 0x5845;
>  pc->revision = 2;
> -pc->is_express = 1;
>  
>  set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
>  dc->desc = "Non-Volatile Memory Express";
> diff --git a/hw/net/e1000e.c b/hw/net/e1000e.c
> index f1af279e8d..c360f0d8c9 100644
> --- a/hw/net/e1000e.c
> +++ b/hw/net/e1000e.c
> @@ -675,7 +675,6 @@ static void e1000e_class_init(ObjectClass *class, void 
> *data)
>  c->revision = 0;
>  c->romfile = "efi-e1000e.rom";
>  c->class_id = PCI_CLASS_NETWORK_ETHERNET;
> -c->is_express = 1;
>  
>  dc->desc = "Intel 82574L GbE Controller";
>  dc->reset = e1000e_qdev_reset;
> diff --git a/hw/pci-bridge/pcie_pci_bridge.c b/hw/pci-bridge/pcie_pci_bridge.c
> index a4d827c99d..b7d9ebbec2 100644
> --- a/hw/pci-bridge/pcie_pci_bridge.c
> +++ b/hw/pci-bridge/pcie_pci_bridge.c
> @@ -169,7 +169,6 @@ static void pcie_pci_bridge_class_init(ObjectClass 
> *klass, void *data)
>  DeviceClass *dc = DEVICE_CLASS(klass);
>  HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(klass);
>  
> -k->is_express = 1;
>  k->is_bridge = 1;
>  k->vendor_id = PCI_VENDOR_ID_REDHAT;
>  k->device_id = PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE;
> diff --git a/hw/pci-bridge/pcie_root_port.c b/hw/pci-bridge/pcie_root_port.c
> index 9b6e4ce512..45f9e8cd4a 100644
> --- a/hw/pci-bridge/pcie_root_port.c
> +++ b/hw/pci-bridge/pcie_root_port.c
> @@ -145,7 +145,6 @@ static void rp_class_init(ObjectClass *klass, void *data)
>  DeviceClass *dc = DEVICE_CLASS(klass);
>  PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
>  
> -k->is_express = 1;
>  k->is_bridge = 1;
>  k->config_write = rp_write_config;
>  k->realize = rp_realize;
> diff --git a/hw/pci-bridge/xio3130_downstream.c 
> b/hw/pci-bridge/xio3130_downstream.c
> index 1e09d2afb7..613a0d6bb7 100644
> --- a/hw/pci-bridge/xio3130_downstream.c
> +++ b/hw/pci-bridge/xio3130_downstream.c
> @@ -177,7 +177,6 @@ static void xio3130_downstream_class_init(ObjectClass 
> *klass, void *data)
>  DeviceClass *dc = DEVICE_CLASS(klass);
>  PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
>  
> -k->is_express = 1;
>  k->is_bridge = 1;
>  k->config_write = xio3130_downstream_write_config;
>  k->realize = xio3130_downstream_realize;
> diff --git a/hw/pci-bridge/xio3130_upstream.c 
> b/hw/pci-bridge/xio3130_upstream.c
> index 227997ce46..d4645bddee 100644
> --- a/hw/pci-bridge/xio3130_upstream.c
> +++ b/hw/pci-bridge/xio3130_upstream.c
> @@ -148,7 +148,6 @@ static void xio3130_upstream_class_init(ObjectClass 
> *klass, void *data)
>  DeviceClass *dc = DEVICE_CLASS(klass);
>  PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
>  

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 117930
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 117930
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 117930
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 117930
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 117930
 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-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  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-xl-xsm  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-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-amd64-amd64-libvirt-vhd 12 migrate-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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 14 saverestore-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-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-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-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-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 qemuuc7947342d7dda87eeeb4a04b6e467f81385014ce
baseline version:
 qemuu7398166ddf7c6dbbc9cae6ac69bb2feda14b40ac

Last test of basis   117930  2018-01-12 23:48:34 Z3 days
Testing same since   118034  2018-01-15 10:18:58 Z0 days1 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  Frediano Ziglio 
  Gerd Hoffmann 
  Jindrich Makovicka 
  linzhecheng 
  Peter Maydell 

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

[Xen-devel] [libvirt bisection] complete build-armhf-libvirt

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job build-armhf-libvirt
testid libvirt-build

Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  libvirt git://libvirt.org/libvirt.git
  Bug introduced:  a0e1ada63c0afdc2af3b9405cbf637d8bd28700c
  Bug not present: cc005fe5a896aa28865f76457bebee90be7a549e
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/118090/


  commit a0e1ada63c0afdc2af3b9405cbf637d8bd28700c
  Author: Michal Privoznik 
  Date:   Wed Nov 1 15:34:14 2017 +0100
  
  vsh: Introduce complete command
  
  This command is going to be called from bash completion script in
  the following form:
  
virsh complete -- start --domain
  
  Its only purpose is to return list of possible strings for
  completion. Note that this is a 'hidden', unlisted command and
  therefore there's no documentation to it.
  
  Signed-off-by: Michal Privoznik 


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/libvirt/build-armhf-libvirt.libvirt-build 
--summary-out=tmp/118090.bisection-summary --basis-template=117772 
--blessings=real,real-bisect libvirt build-armhf-libvirt libvirt-build
Searching for failure / basis pass:
 118006 fail [host=arndale-metrocentre] / 117772 [host=cubietruck-picasso] 
117737 ok.
Failure / basis pass flights: 118006 / 117737
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 44601840ddb233d9ce9ec72d67bdab74d208f32d 
7e7c5c7952b7de1e33c8eba891cc425d5d8d7803 
267157b96c62b5445de9cddd21de42fcd943ffe6 
2b033e396f4fa0981bae1213cdacd15775655a97 
ec320542e4f4de12305551ef5e3cd4d2ced85771
Basis pass e3088bfd8efe0ec4a3875788aad6d69f48509c2d 
7e7c5c7952b7de1e33c8eba891cc425d5d8d7803 
267157b96c62b5445de9cddd21de42fcd943ffe6 
b79708a8ed1b3d18bee67baeaf33b3fa529493e2 
ec320542e4f4de12305551ef5e3cd4d2ced85771
Generating revisions with ./adhoc-revtuple-generator  
git://libvirt.org/libvirt.git#e3088bfd8efe0ec4a3875788aad6d69f48509c2d-44601840ddb233d9ce9ec72d67bdab74d208f32d
 
git://git.sv.gnu.org/gnulib.git#7e7c5c7952b7de1e33c8eba891cc425d5d8d7803-7e7c5c7952b7de1e33c8eba891cc425d5d8d7803
 
https://gitlab.com/keycodemap/keycodemapdb.git#267157b96c62b5445de9cddd21de42fcd943ffe6-267157b96c62b5445de9cddd21de42fcd943ffe6
 
git://xenbits.xen.org/qemu-xen.git#b79708a8ed1b3d18bee67baeaf33b3fa529493e2-2b033e396f4fa0981bae1213cdacd15775655a97
 
git://xenbits.xen.org/xen.git#ec320542e4f4de12305551ef5e3cd4d2ced85771-ec320542e4f4de12305551ef5e3cd4d2ced85771
Loaded 3906 nodes in revision graph
Searching for test results:
 117772 [host=cubietruck-picasso]
 117737 pass e3088bfd8efe0ec4a3875788aad6d69f48509c2d 
7e7c5c7952b7de1e33c8eba891cc425d5d8d7803 
267157b96c62b5445de9cddd21de42fcd943ffe6 
b79708a8ed1b3d18bee67baeaf33b3fa529493e2 
ec320542e4f4de12305551ef5e3cd4d2ced85771
 117889 [host=arndale-westfield]
 117995 [host=arndale-westfield]
 117939 [host=arndale-westfield]
 117998 [host=arndale-westfield]
 118006 fail 44601840ddb233d9ce9ec72d67bdab74d208f32d 
7e7c5c7952b7de1e33c8eba891cc425d5d8d7803 
267157b96c62b5445de9cddd21de42fcd943ffe6 
2b033e396f4fa0981bae1213cdacd15775655a97 
ec320542e4f4de12305551ef5e3cd4d2ced85771
 117997 [host=arndale-westfield]
 117983 [host=arndale-westfield]
 117999 [host=arndale-westfield]
 118000 [host=arndale-westfield]
 118009 [host=arndale-westfield]
 118087 pass cc005fe5a896aa28865f76457bebee90be7a549e 
7e7c5c7952b7de1e33c8eba891cc425d5d8d7803 
267157b96c62b5445de9cddd21de42fcd943ffe6 
2b033e396f4fa0981bae1213cdacd15775655a97 
ec320542e4f4de12305551ef5e3cd4d2ced85771
 118013 [host=arndale-westfield]
 118016 [host=arndale-westfield]
 118079 pass 449bfcd5761f38af5c39f219e5b6b9df219f2fb4 
7e7c5c7952b7de1e33c8eba891cc425d5d8d7803 
267157b96c62b5445de9cddd21de42fcd943ffe6 
2b033e396f4fa0981bae1213cdacd15775655a97 
ec320542e4f4de12305551ef5e3cd4d2ced85771
 118019 [host=arndale-westfield]
 118080 pass cc005fe5a896aa28865f76457bebee90be7a549e 
7e7c5c7952b7de1e33c8eba891cc425d5d8d7803 
267157b96c62b5445de9cddd21de42fcd943ffe6 
2b033e396f4fa0981bae1213cdacd15775655a97 
ec320542e4f4de12305551ef5e3cd4d2ced85771
 118029 [host=arndale-westfield]
 118081 fail 72ac507f42664f6eb26c623c48495e3ef681975d 
7e7c5c7952b7de1e33c8eba891cc425d5d8d7803 

[Xen-devel] [linux-next test] 118031: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 117945
 test-amd64-amd64-xl-credit2   7 xen-boot fail REGR. vs. 117945
 test-amd64-amd64-xl-xsm   7 xen-boot fail REGR. vs. 117945
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 117945
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 117945
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
117945
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 117945
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 117945
 test-amd64-amd64-xl-qemut-win10-i386  7 xen-boot fail REGR. vs. 117945
 test-amd64-amd64-xl-qemut-win7-amd64  7 xen-boot fail REGR. vs. 117945
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 117945
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 117945
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 117945
 test-amd64-amd64-xl-qemuu-ws16-amd64  7 xen-boot fail REGR. vs. 117945
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 117945
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  7 xen-bootfail REGR. vs. 117945
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 117945
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 117945
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
117945
 test-amd64-amd64-libvirt-xsm  7 xen-boot fail REGR. vs. 117945
 test-amd64-amd64-xl-multivcpu  7 xen-bootfail REGR. vs. 117945
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
117945
 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 117945
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 117945
 test-amd64-amd64-xl-qemut-ws16-amd64  7 xen-boot fail REGR. vs. 117945
 test-amd64-amd64-xl-pvhv2-amd  7 xen-bootfail REGR. vs. 117945
 test-amd64-amd64-xl-qemut-debianhvm-amd64  7 xen-bootfail REGR. vs. 117945
 test-amd64-amd64-qemuu-nested-amd  7 xen-bootfail REGR. vs. 117945
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 117945
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 117945
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 117945
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 117945
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 117945
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 117945
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 117945
 test-amd64-amd64-libvirt  7 xen-boot fail REGR. vs. 117945
 test-amd64-amd64-xl-pvhv2-intel  7 xen-boot  fail REGR. vs. 117945
 test-amd64-amd64-libvirt-vhd  7 xen-boot fail REGR. vs. 117945
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 117945
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 117945
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 117945
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 117945
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail REGR. vs. 117945
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 117945
 test-amd64-amd64-xl-qemuu-win10-i386  7 xen-boot fail REGR. vs. 117945
 test-amd64-amd64-rumprun-amd64  7 xen-boot   fail REGR. vs. 117945
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 117945
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 117945
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 117945
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 117945
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 117945
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 117945
 test-amd64-amd64-xl   7 xen-boot fail REGR. vs. 117945
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 117945
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 117945
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 117945
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 117945
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 117945
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 117945
 test-amd64-amd64-xl-qemuu-win7-amd64  7 xen-boot

[Xen-devel] [PATCH RESEND v1 2/7] x86: configure vmcs for Intel processor trace virtualization

[Luwei Kang]

This patch configure VMCS to make Intel PT output address can be
treat as guest physical address and translated by EPT when
intel_pt option is true.
There have some constraint condition on VMCS configuration,
otherwise will cause VM entry failed.

1. If the “Guest PT uses Guest Physical Addresses” execution
   control is 1, the “Clear IA32_RTIT_CTL on exit” exit
   control and the “Load IA32_RTIT_CTL on entry” entry
   control must also be 1.
2. If the “Guest PT uses Guest Physical Addresses” execution
   control is 1, the "enable EPT" execution control must
   also be 1.

Signed-off-by: Luwei Kang 
---
 xen/arch/x86/hvm/vmx/vmcs.c| 36 +++-
 xen/include/asm-x86/hvm/vmx/vmcs.h |  7 +++
 2 files changed, 38 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index e7818ca..8d49a6b 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static bool_t __read_mostly opt_vpid_enabled = 1;
 boolean_param("vpid", opt_vpid_enabled);
@@ -242,6 +243,9 @@ static int vmx_init_vmcs_config(void)
 rdmsrl(MSR_IA32_VMX_MISC, _vmx_misc_cap);
 if ( _vmx_misc_cap & VMX_MISC_VMWRITE_ALL )
 opt |= SECONDARY_EXEC_ENABLE_VMCS_SHADOWING;
+if ( _vmx_misc_cap & VMX_MISC_PT_ENABLE )
+opt |= SECONDARY_EXEC_PT_USE_GPA |
+   SECONDARY_EXEC_CONCEAL_PT_PIP;
 if ( opt_vpid_enabled )
 opt |= SECONDARY_EXEC_ENABLE_VPID;
 if ( opt_unrestricted_guest_enabled )
@@ -343,7 +347,8 @@ static int vmx_init_vmcs_config(void)
 
 min = VM_EXIT_ACK_INTR_ON_EXIT;
 opt = VM_EXIT_SAVE_GUEST_PAT | VM_EXIT_LOAD_HOST_PAT |
-  VM_EXIT_CLEAR_BNDCFGS;
+  VM_EXIT_CLEAR_BNDCFGS | VM_EXIT_CONCEAL_PT_PIP |
+  VM_EXIT_CLEAR_IA32_RTIT_CTL;
 min |= VM_EXIT_IA32E_MODE;
 _vmx_vmexit_control = adjust_vmx_controls(
 "VMExit Control", min, opt, MSR_IA32_VMX_EXIT_CTLS, );
@@ -383,13 +388,28 @@ static int vmx_init_vmcs_config(void)
 _vmx_secondary_exec_control &= ~SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS;
 
 min = 0;
-opt = VM_ENTRY_LOAD_GUEST_PAT | VM_ENTRY_LOAD_BNDCFGS;
+opt = VM_ENTRY_LOAD_GUEST_PAT | VM_ENTRY_LOAD_BNDCFGS |
+  VM_ENTRY_CONCEAL_PT_PIP | VM_ENTRY_LOAD_IA32_RTIT_CTL;
 _vmx_vmentry_control = adjust_vmx_controls(
 "VMEntry Control", min, opt, MSR_IA32_VMX_ENTRY_CTLS, );
 
 if ( mismatch )
 return -EINVAL;
 
+if ( !(_vmx_secondary_exec_control & SECONDARY_EXEC_ENABLE_EPT) ||
+ !(_vmx_secondary_exec_control & SECONDARY_EXEC_PT_USE_GPA) ||
+ !(_vmx_vmexit_control & VM_EXIT_CLEAR_IA32_RTIT_CTL) ||
+ !(_vmx_vmentry_control & VM_ENTRY_LOAD_IA32_RTIT_CTL) )
+{
+_vmx_secondary_exec_control &= ~(SECONDARY_EXEC_PT_USE_GPA |
+ SECONDARY_EXEC_CONCEAL_PT_PIP);
+_vmx_vmexit_control &= ~(VM_EXIT_CONCEAL_PT_PIP |
+ VM_EXIT_CLEAR_IA32_RTIT_CTL);
+_vmx_vmentry_control &= ~(VM_ENTRY_CONCEAL_PT_PIP |
+  VM_ENTRY_LOAD_IA32_RTIT_CTL);
+opt_intel_pt = 0;
+}
+
 if ( !vmx_pin_based_exec_control )
 {
 /* First time through. */
@@ -1029,10 +1049,16 @@ static int construct_vmcs(struct vcpu *v)
 v->arch.hvm_vmx.secondary_exec_control &= 
 ~(SECONDARY_EXEC_ENABLE_EPT | 
   SECONDARY_EXEC_UNRESTRICTED_GUEST |
-  SECONDARY_EXEC_ENABLE_INVPCID);
+  SECONDARY_EXEC_ENABLE_INVPCID |
+  SECONDARY_EXEC_PT_USE_GPA |
+  SECONDARY_EXEC_CONCEAL_PT_PIP);
 vmexit_ctl &= ~(VM_EXIT_SAVE_GUEST_PAT |
-VM_EXIT_LOAD_HOST_PAT);
-vmentry_ctl &= ~VM_ENTRY_LOAD_GUEST_PAT;
+VM_EXIT_LOAD_HOST_PAT |
+VM_EXIT_CONCEAL_PT_PIP |
+VM_EXIT_CLEAR_IA32_RTIT_CTL);
+vmentry_ctl &= ~(VM_ENTRY_LOAD_GUEST_PAT |
+ VM_ENTRY_CONCEAL_PT_PIP |
+ VM_ENTRY_LOAD_IA32_RTIT_CTL);
 }
 
 /* Disable Virtualize x2APIC mode by default. */
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h 
b/xen/include/asm-x86/hvm/vmx/vmcs.h
index 8fb9e3c..bd8a128 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -220,6 +220,8 @@ extern u32 vmx_pin_based_exec_control;
 #define VM_EXIT_LOAD_HOST_EFER  0x0020
 #define VM_EXIT_SAVE_PREEMPT_TIMER  0x0040
 #define VM_EXIT_CLEAR_BNDCFGS   0x0080
+#define VM_EXIT_CONCEAL_PT_PIP  0x0100
+#define VM_EXIT_CLEAR_IA32_RTIT_CTL 0x0200
 extern u32 vmx_vmexit_control;
 
 #define VM_ENTRY_IA32E_MODE 0x0200
@@ -229,6 +231,8 @@ extern u32 vmx_vmexit_control;
 #define VM_ENTRY_LOAD_GUEST_PAT 

[Xen-devel] [PATCH RESEND v1 6/7] x86: Implement Intel Processor Trace MSRs read/write

[Luwei Kang]

Intel PT MSRs read/write will not be intercepted when guest enabled
Intel PT. IA32_RTIT_CTL read/write will always cause a VM-Exit.

Signed-off-by: Luwei Kang 
---
 xen/arch/x86/cpu/intel_pt.c| 101 +
 xen/arch/x86/hvm/vmx/vmx.c |  18 
 xen/include/asm-x86/intel_pt.h |   4 ++
 3 files changed, 123 insertions(+)

diff --git a/xen/arch/x86/cpu/intel_pt.c b/xen/arch/x86/cpu/intel_pt.c
index c0e9e68..d530e57 100644
--- a/xen/arch/x86/cpu/intel_pt.c
+++ b/xen/arch/x86/cpu/intel_pt.c
@@ -28,6 +28,107 @@
 bool_t __read_mostly opt_intel_pt = 1;
 boolean_param("intel_pt", opt_intel_pt);
 
+
+static void intel_pt_disable_intercept_for_msr(u32 addr_num)
+{
+struct vcpu *v = current;
+int i;
+
+vmx_clear_msr_intercept(v, MSR_IA32_RTIT_STATUS, VMX_MSR_RW);
+vmx_clear_msr_intercept(v, MSR_IA32_RTIT_OUTPUT_BASE, VMX_MSR_RW);
+vmx_clear_msr_intercept(v, MSR_IA32_RTIT_OUTPUT_MASK, VMX_MSR_RW);
+vmx_clear_msr_intercept(v, MSR_IA32_RTIT_CR3_MATCH, VMX_MSR_RW);
+for ( i = 0; i < addr_num; i++ )
+vmx_clear_msr_intercept(v, MSR_IA32_RTIT_ADDR0_A + i, VMX_MSR_RW);
+}
+
+static void intel_pt_enable_intercept_for_msr(u32 addr_num)
+{
+struct vcpu *v = current;
+int i;
+
+vmx_set_msr_intercept(v, MSR_IA32_RTIT_STATUS, VMX_MSR_RW);
+vmx_set_msr_intercept(v, MSR_IA32_RTIT_OUTPUT_BASE, VMX_MSR_RW);
+vmx_set_msr_intercept(v, MSR_IA32_RTIT_OUTPUT_MASK, VMX_MSR_RW);
+vmx_set_msr_intercept(v, MSR_IA32_RTIT_CR3_MATCH, VMX_MSR_RW);
+for ( i = 0; i < addr_num; i++ )
+vmx_set_msr_intercept(v, MSR_IA32_RTIT_ADDR0_A + i, VMX_MSR_RW);
+}
+
+void pt_set_rtit_ctl(struct pt_desc *pt_desc, uint64_t msr_content)
+{
+if (msr_content & MSR_IA32_RTIT_CTL_TRACEEN)
+intel_pt_disable_intercept_for_msr(pt_desc->addr_num);
+else
+intel_pt_enable_intercept_for_msr(pt_desc->addr_num);
+
+pt_desc->guest_pt_ctx.ctl = msr_content;
+
+vmx_vmcs_enter(current);
+__vmwrite(GUEST_IA32_RTIT_CTL, msr_content);
+vmx_vmcs_exit(current);
+}
+
+int pt_do_rdmsr(unsigned int msr, uint64_t *msr_content)
+{
+struct pt_desc *pt_desc = >arch.hvm_vmx.pt_desc;
+
+if ( !opt_intel_pt )
+return 1;
+
+switch ( msr ) {
+case MSR_IA32_RTIT_CTL:
+*msr_content = pt_desc->guest_pt_ctx.ctl;
+break;
+case MSR_IA32_RTIT_STATUS:
+*msr_content = pt_desc->guest_pt_ctx.status;
+break;
+case MSR_IA32_RTIT_OUTPUT_BASE:
+*msr_content = pt_desc->guest_pt_ctx.output_base;
+break;
+case MSR_IA32_RTIT_OUTPUT_MASK:
+*msr_content = pt_desc->guest_pt_ctx.output_mask;
+break;
+case MSR_IA32_RTIT_CR3_MATCH:
+*msr_content = pt_desc->guest_pt_ctx.cr3_match;
+break;
+default:
+*msr_content = pt_desc->guest_pt_ctx.addr[msr - MSR_IA32_RTIT_ADDR0_A];
+}
+
+return 0;
+}
+
+int pt_do_wrmsr(unsigned int msr, uint64_t msr_content)
+{
+struct pt_desc *pt_desc = >arch.hvm_vmx.pt_desc;
+
+if ( !opt_intel_pt )
+return 1;
+
+switch ( msr ) {
+case MSR_IA32_RTIT_CTL:
+pt_set_rtit_ctl(pt_desc, msr_content);
+break;
+case MSR_IA32_RTIT_STATUS:
+pt_desc->guest_pt_ctx.status = msr_content;
+break;
+case MSR_IA32_RTIT_OUTPUT_BASE:
+pt_desc->guest_pt_ctx.output_base = msr_content;
+break;
+case MSR_IA32_RTIT_OUTPUT_MASK:
+pt_desc->guest_pt_ctx.output_mask = msr_content | 0x7F;
+break;
+case MSR_IA32_RTIT_CR3_MATCH:
+pt_desc->guest_pt_ctx.cr3_match = msr_content;
+break;
+default:
+pt_desc->guest_pt_ctx.addr[msr - MSR_IA32_RTIT_ADDR0_A] = msr_content;
+}
+
+return 0;
+}
+
 static inline void pt_load_msr(struct pt_ctx *ctx, u32 addr_num)
 {
 u32 i;
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index f386933..e6713fd 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2929,6 +2929,15 @@ static int vmx_msr_read_intercept(unsigned int msr, 
uint64_t *msr_content)
 if ( vpmu_do_rdmsr(msr, msr_content) )
 goto gp_fault;
 break;
+case MSR_IA32_RTIT_CTL:
+case MSR_IA32_RTIT_STATUS:
+case MSR_IA32_RTIT_OUTPUT_BASE:
+case MSR_IA32_RTIT_OUTPUT_MASK:
+case MSR_IA32_RTIT_CR3_MATCH:
+case MSR_IA32_RTIT_ADDR0_A ... MSR_IA32_RTIT_ADDR3_B:
+if ( pt_do_rdmsr(msr, msr_content) )
+goto gp_fault;
+break;
 
 default:
 if ( passive_domain_do_rdmsr(msr, msr_content) )
@@ -3149,6 +3158,15 @@ static int vmx_msr_write_intercept(unsigned int msr, 
uint64_t msr_content)
  if ( vpmu_do_wrmsr(msr, msr_content, 0) )
 goto gp_fault;
 break;
+case MSR_IA32_RTIT_CTL:
+case MSR_IA32_RTIT_STATUS:
+case MSR_IA32_RTIT_OUTPUT_BASE:
+case MSR_IA32_RTIT_OUTPUT_MASK:
+case MSR_IA32_RTIT_CR3_MATCH:
+case 

[Xen-devel] [PATCH RESEND v1 3/7] x86: add intel proecessor trace support for cpuid

[Luwei Kang]

This patch add Intel processor trace support
for cpuid handling.

Signed-off-by: Luwei Kang 
---
 tools/libxc/xc_cpuid_x86.c  | 12 ++--
 xen/arch/x86/cpuid.c| 22 ++
 xen/arch/x86/domctl.c   |  4 
 xen/include/asm-x86/cpufeature.h|  1 +
 xen/include/asm-x86/cpuid.h | 12 +++-
 xen/include/public/arch-x86/cpufeatureset.h |  1 +
 6 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 25b922e..c39a9cf 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -38,7 +38,7 @@ enum {
 #define clear_feature(idx, dst) ((dst) &= ~bitmaskof(idx))
 #define set_feature(idx, dst)   ((dst) |=  bitmaskof(idx))
 
-#define DEF_MAX_BASE 0x000du
+#define DEF_MAX_BASE 0x0014u
 #define DEF_MAX_INTELEXT  0x8008u
 #define DEF_MAX_AMDEXT0x801cu
 
@@ -471,6 +471,7 @@ static void xc_cpuid_hvm_policy(xc_interface *xch,
 case 0x0002: /* Intel cache info (dumped by AMD policy) */
 case 0x0004: /* Intel cache info (dumped by AMD policy) */
 case 0x000a: /* Architectural Performance Monitor Features */
+case 0x0014: /* Intel Processor Trace Features */
 case 0x8002: /* Processor name string */
 case 0x8003: /* ... continued */
 case 0x8004: /* ... continued */
@@ -757,12 +758,19 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t 
domid,
 continue;
 }
 
+if ( input[0] == 0x14 )
+{
+input[1]++;
+if ( input[1] == 1 )
+continue;
+}
+
 input[0]++;
 if ( !(input[0] & 0x8000u) && (input[0] > base_max ) )
 input[0] = 0x8000u;
 
 input[1] = XEN_CPUID_INPUT_UNUSED;
-if ( (input[0] == 4) || (input[0] == 7) )
+if ( (input[0] == 4) || (input[0] == 7) || (input[0] == 0x14) )
 input[1] = 0;
 else if ( input[0] == 0xd )
 input[1] = 1; /* Xen automatically calculates almost everything. */
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 5ee82d3..c3d56fd 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 const uint32_t known_features[] = INIT_KNOWN_FEATURES;
 const uint32_t special_features[] = INIT_SPECIAL_FEATURES;
@@ -487,7 +488,19 @@ void recalculate_cpuid_policy(struct domain *d)
 __clear_bit(X86_FEATURE_VMX, max_fs);
 __clear_bit(X86_FEATURE_SVM, max_fs);
 }
+
+/*
+ * Hide Intel Processor trace feature when hardware not support
+ * PT-VMX or intel_pt option is disabled.
+ */
+if ( !opt_intel_pt )
+{
+__clear_bit(X86_FEATURE_INTEL_PT, max_fs);
+zero_leaves(p->intel_pt.raw, 0, ARRAY_SIZE(p->intel_pt.raw) - 1);
+}
 }
+else
+zero_leaves(p->intel_pt.raw, 0, ARRAY_SIZE(p->intel_pt.raw) - 1);
 
 /*
  * Allow the toolstack to set HTT, X2APIC and CMP_LEGACY.  These bits
@@ -634,6 +647,15 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
 *res = p->feat.raw[subleaf];
 break;
 
+case 0x14:
+ASSERT(p->intel_pt.max_subleaf < ARRAY_SIZE(p->intel_pt.raw));
+if ( subleaf > min_t(uint32_t, p->intel_pt.max_subleaf,
+ ARRAY_SIZE(p->intel_pt.raw) - 1) )
+return;
+
+*res = p->intel_pt.raw[subleaf];
+break;
+
 case XSTATE_CPUID:
 if ( !p->basic.xsave || subleaf >= ARRAY_SIZE(p->xstate.raw) )
 return;
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 5973d9f..493cca4 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -101,6 +101,10 @@ static int update_domain_cpuid_info(struct domain *d,
 p->feat.raw[ctl->input[1]] = leaf;
 break;
 
+case 0x14:
+p->intel_pt.raw[ctl->input[1]] = leaf;
+break;
+
 case XSTATE_CPUID:
 p->xstate.raw[ctl->input[1]] = leaf;
 break;
diff --git a/xen/include/asm-x86/cpufeature.h b/xen/include/asm-x86/cpufeature.h
index 84cc51d..8956667 100644
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -95,6 +95,7 @@
 #define cpu_has_mpx boot_cpu_has(X86_FEATURE_MPX)
 #define cpu_has_rdseed  boot_cpu_has(X86_FEATURE_RDSEED)
 #define cpu_has_smapboot_cpu_has(X86_FEATURE_SMAP)
+#define cpu_has_intel_ptboot_cpu_has(X86_FEATURE_INTEL_PT)
 #define cpu_has_sha boot_cpu_has(X86_FEATURE_SHA)
 
 /* CPUID level 0x8007.edx */
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index d2dd841..39f06aa 100644
--- a/xen/include/asm-x86/cpuid.h
+++ 

[Xen-devel] [PATCH RESEND v1 5/7] x86: Implement Intel Processor Trace context switch

[Luwei Kang]

Load/Store Intel processor trace register in context switch.
MSR IA32_RTIT_CTL is loaded/stored automatically from VMCS.
When Intel PT is supported in guest, we need load/restore
PT MSRs only when PT is enabled in guest.

Signed-off-by: Luwei Kang 
---
 xen/arch/x86/cpu/intel_pt.c| 69 ++
 xen/arch/x86/hvm/vmx/vmx.c |  4 +++
 xen/include/asm-x86/hvm/vmx/vmcs.h |  2 ++
 xen/include/asm-x86/intel_pt.h |  4 +++
 4 files changed, 79 insertions(+)

diff --git a/xen/arch/x86/cpu/intel_pt.c b/xen/arch/x86/cpu/intel_pt.c
index 520e0ca..c0e9e68 100644
--- a/xen/arch/x86/cpu/intel_pt.c
+++ b/xen/arch/x86/cpu/intel_pt.c
@@ -21,7 +21,76 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /* intel_pt: Flag to enable Intel Processor Trace (default on). */
 bool_t __read_mostly opt_intel_pt = 1;
 boolean_param("intel_pt", opt_intel_pt);
+
+static inline void pt_load_msr(struct pt_ctx *ctx, u32 addr_num)
+{
+u32 i;
+wrmsrl(MSR_IA32_RTIT_STATUS, ctx->status);
+wrmsrl(MSR_IA32_RTIT_OUTPUT_BASE, ctx->output_base);
+wrmsrl(MSR_IA32_RTIT_OUTPUT_MASK, ctx->output_mask);
+wrmsrl(MSR_IA32_RTIT_CR3_MATCH, ctx->cr3_match);
+for ( i = 0; i < addr_num; i++ )
+wrmsrl(MSR_IA32_RTIT_ADDR0_A + i, ctx->addr[i]);
+}
+
+static inline void pt_save_msr(struct pt_ctx *ctx, u32 addr_num)
+{
+u32 i;
+rdmsrl(MSR_IA32_RTIT_STATUS, ctx->status);
+rdmsrl(MSR_IA32_RTIT_OUTPUT_BASE, ctx->output_base);
+rdmsrl(MSR_IA32_RTIT_OUTPUT_MASK, ctx->output_mask);
+rdmsrl(MSR_IA32_RTIT_CR3_MATCH, ctx->cr3_match);
+for ( i = 0; i < addr_num; i++ )
+rdmsrl(MSR_IA32_RTIT_ADDR0_A + i, ctx->addr[i]);
+}
+
+void pt_guest_enter(struct vcpu *v)
+{
+struct pt_desc *pt = >arch.hvm_vmx.pt_desc;
+
+if ( pt->intel_pt_enabled &&
+   (pt->guest_pt_ctx.ctl & MSR_IA32_RTIT_CTL_TRACEEN) )
+pt_load_msr(>guest_pt_ctx, pt->addr_num);
+}
+
+void pt_guest_exit(struct vcpu *v)
+{
+struct pt_desc *pt = >arch.hvm_vmx.pt_desc;
+
+if ( pt->intel_pt_enabled &&
+   (pt->guest_pt_ctx.ctl & MSR_IA32_RTIT_CTL_TRACEEN) )
+pt_save_msr(>guest_pt_ctx, pt->addr_num);
+}
+
+void pt_vcpu_init(struct vcpu *v)
+{
+struct pt_desc *pt = >arch.hvm_vmx.pt_desc;
+unsigned int eax, ebx, ecx, edx;
+
+memset(pt, 0, sizeof(struct pt_desc));
+pt->intel_pt_enabled = false;
+
+if ( !cpu_has_intel_pt || !opt_intel_pt ||
+ !(v->arch.hvm_vmx.secondary_exec_control & SECONDARY_EXEC_PT_USE_GPA) 
)
+return;
+
+/* get the number of address ranges */
+if ( cpuid_eax(0x14) == 1 )
+cpuid_count(0x14, 1, , , , );
+else
+return;
+
+pt->addr_num = eax & 0x7;
+pt->guest_pt_ctx.output_mask = 0x7F;
+pt->intel_pt_enabled = true;
+
+vmx_vmcs_enter(v);
+__vmwrite(GUEST_IA32_RTIT_CTL, 0);
+vmx_vmcs_exit(v);
+}
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index e036303..f386933 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -467,6 +467,8 @@ static int vmx_vcpu_initialise(struct vcpu *v)
 if ( v->vcpu_id == 0 )
 v->arch.user_regs.rax = 1;
 
+pt_vcpu_init(v);
+
 return 0;
 }
 
@@ -3513,6 +3515,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
 __vmread(GUEST_RSP,>rsp);
 __vmread(GUEST_RFLAGS, >rflags);
 
+pt_guest_exit(v);
 hvm_invalidate_regs_fields(regs);
 
 if ( paging_mode_hap(v->domain) )
@@ -4281,6 +4284,7 @@ bool vmx_vmenter_helper(const struct cpu_user_regs *regs)
 }
 }
 
+pt_guest_enter(curr);
  out:
 if ( unlikely(curr->arch.hvm_vmx.lbr_fixup_enabled) )
 lbr_fixup();
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h 
b/xen/include/asm-x86/hvm/vmx/vmcs.h
index 33ec3e6..46c386f 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -421,6 +421,8 @@ enum vmcs_field {
 GUEST_PDPTE0= 0x280a,
 #define GUEST_PDPTE(n) (GUEST_PDPTE0 + (n) * 2) /* n = 0...3 */
 GUEST_BNDCFGS   = 0x2812,
+GUEST_IA32_RTIT_CTL = 0x2814,
+GUEST_IA32_RTIT_CTL_HIGH= 0x2815,
 HOST_PAT= 0x2c00,
 HOST_EFER   = 0x2c02,
 HOST_PERF_GLOBAL_CTRL   = 0x2c04,
diff --git a/xen/include/asm-x86/intel_pt.h b/xen/include/asm-x86/intel_pt.h
index 909e22f..9505c8f 100644
--- a/xen/include/asm-x86/intel_pt.h
+++ b/xen/include/asm-x86/intel_pt.h
@@ -40,4 +40,8 @@ struct pt_desc {
 
 extern bool_t opt_intel_pt;
 
+void pt_vcpu_init(struct vcpu *v);
+void pt_guest_enter(struct vcpu *v);
+void pt_guest_exit(struct vcpu *v);
+
 #endif /* __ASM_X86_HVM_INTEL_PT_H_ */
-- 
1.8.3.1


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

[Xen-devel] [PATCH RESEND v1 7/7] x86: Disable Intel Processor Trace when VMXON in L1 guest

[Luwei Kang]

Disable intel Processor Trace VMX operation(IA32_VMX_MISC[bit 14] is 0)
in L1 guest. As mentioned in SDM, on these type of processors, execution
of the VMXON instruction will  clears IA32_RTIT_CTL.TraceEn and any
attempt to write IA32_RTIT_CTL causes a general-protection xception (#GP).

Signed-off-by: Luwei Kang 
---
 xen/arch/x86/hvm/vmx/vvmx.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 885eab3..86ccfda 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -1516,6 +1516,9 @@ int nvmx_handle_vmxon(struct cpu_user_regs *regs)
 v->arch.hvm_vmx.launched = 0;
 vmsucceed(regs);
 
+if ( v->arch.hvm_vmx.pt_desc.intel_pt_enabled )
+pt_set_rtit_ctl(>arch.hvm_vmx.pt_desc, 0);
+
 return X86EMUL_OKAY;
 }
 
@@ -2140,8 +2143,8 @@ int nvmx_msr_read_intercept(unsigned int msr, u64 
*msr_content)
 data = hvm_cr4_guest_valid_bits(v, 0);
 break;
 case MSR_IA32_VMX_MISC:
-/* Do not support CR3-target feature now */
-data = host_data & ~VMX_MISC_CR3_TARGET;
+/* Do not support CR3-target and PT VMX feature now */
+data = host_data & ~(VMX_MISC_CR3_TARGET | VMX_MISC_PT_ENABLE);
 break;
 case MSR_IA32_VMX_EPT_VPID_CAP:
 data = nept_get_ept_vpid_cap();
-- 
1.8.3.1


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

Re: [Xen-devel] [PATCH] fix potential null dereference

[Jan Beulich]

>>> On 15.01.18 at 19:51,  wrote:
> On Mon, 15 Jan 2018, Jan Beulich wrote:
>> >>> On 13.01.18 at 07:21,  wrote:
>> > On 01/12/2018 11:40 PM, Stefano Stabellini wrote:
>> >> handles can theoretically be NULL, check for it explicitly before
>> >> dereferencing it.
>> > 
>> > I doubt handles could be NULL if LocateHandle succeed. This seems to be 
>> > confirmed by the spec (Page 208 in UEFI spec 2.7).
>> > 
>> > So I am not entirely convince we should add yet another check in the 
>> > code. An ASSERT might be better.
>> 
>> Indeed if there is a platform where NULL is coming back in the
>> success case, that platform should be named as a justification
>> in the commit message. Otherwise I don't see the value of this
>> change.
> 
> Truthfully, it is mostly to silence Coverity. We can all appreciate when
> static analysts cannot find defects in the code.

So what does Coverity dislike here (the more that this is on a
boot path, i.e. not exploitable by guests at all in the first place)?
Merely the NULL pointer? What if the interface gave back a
pointer with a value of 0x123456789abcdef?

Jan


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

[Xen-devel] [PATCH RESEND v1 0/7] Intel Processor Trace virtulization enabling

[Luwei Kang]

Hi All,

Here is a patch-series which adding Processor Trace enabling in XEN guest. You 
can get It's software developer manuals from:
https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
In Chapter 5 INTEL PROCESSOR TRACE: VMX IMPROVEMENTS.

Introduction:
Intel Processor Trace (Intel PT) is an extension of Intel Architecture that 
captures information about software execution using dedicated hardware 
facilities that cause only minimal performance perturbation to the software 
being traced. Details on the Intel PT infrastructure and trace capabilities can 
be found in the Intel 64 and IA-32 Architectures Software Developer’s Manual, 
Volume 3C.

The suite of architecture changes serve to simplify the process of virtualizing 
Intel PT for use by a guest software. There are two primary elements to this 
new architecture support for VMX support improvements made for Intel PT.
1. Addition of a new guest IA32_RTIT_CTL value field to the VMCS.
  — This serves to speed and simplify the process of disabling trace on VM 
exit, and restoring it on VM entry.
2. Enabling use of EPT to redirect PT output.
  — This enables the VMM to elect to virtualize the PT output buffer using EPT. 
In this mode, the CPU will treat PT output addresses as Guest Physical 
Addresses (GPAs) and translate them using EPT. This means that Intel PT output 
reads (of the ToPA table) and writes (of trace output) can cause EPT 
violations, and other output events.

===
Do some optimization in context switch compared with the first sent:
1. disable intercept only when PT is enabled in guest;
2. disable Intel PT and enable intercept MSRs when L1 guest VMXON;


Luwei Kang (7):
  x86: add a flag to enable Intel processor trace
  x86: configure vmcs for Intel processor trace virtualization
  x86: add intel proecessor trace support for cpuid
  x86: add intel processor trace context
  x86: Implement Intel Processor Trace context switch
  x86: Implement Intel Processor Trace MSRs read/write
  x86: Disable Intel Processor Trace when VMXON in L1 guest

 docs/misc/xen-command-line.markdown |   7 +
 tools/libxc/xc_cpuid_x86.c  |  12 +-
 xen/arch/x86/cpu/Makefile   |   1 +
 xen/arch/x86/cpu/intel_pt.c | 197 
 xen/arch/x86/cpuid.c|  22 
 xen/arch/x86/domctl.c   |   4 +
 xen/arch/x86/hvm/vmx/vmcs.c |  36 -
 xen/arch/x86/hvm/vmx/vmx.c  |  22 
 xen/arch/x86/hvm/vmx/vvmx.c |   7 +-
 xen/include/asm-x86/cpufeature.h|   1 +
 xen/include/asm-x86/cpuid.h |  12 +-
 xen/include/asm-x86/hvm/vmx/vmcs.h  |  12 ++
 xen/include/asm-x86/intel_pt.h  |  51 +++
 xen/include/asm-x86/msr-index.h |  20 +++
 xen/include/public/arch-x86/cpufeatureset.h |   1 +
 15 files changed, 395 insertions(+), 10 deletions(-)
 create mode 100644 xen/arch/x86/cpu/intel_pt.c
 create mode 100644 xen/include/asm-x86/intel_pt.h

-- 
1.8.3.1


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

[Xen-devel] [PATCH RESEND v1 1/7] x86: add a flag to enable Intel processor trace

[Luwei Kang]

This patch add a flag to enable Intel PT (Intel processor trace).
Default value is 1 (enabled).

Signed-off-by: Luwei Kang 
---
 docs/misc/xen-command-line.markdown |  7 +++
 xen/arch/x86/cpu/Makefile   |  1 +
 xen/arch/x86/cpu/intel_pt.c | 27 +++
 xen/include/asm-x86/intel_pt.h  | 26 ++
 4 files changed, 61 insertions(+)
 create mode 100644 xen/arch/x86/cpu/intel_pt.c
 create mode 100644 xen/include/asm-x86/intel_pt.h

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 781110d..95411cf 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1009,6 +1009,13 @@ debug hypervisor only).
 ### idle\_latency\_factor
 > `= `
 
+### intel\_pt
+> `= `
+
+> Default: `true`
+
+Flag to enable Intel Processor Trace.
+
 ### ioapic\_ack
 > `= old | new`
 
diff --git a/xen/arch/x86/cpu/Makefile b/xen/arch/x86/cpu/Makefile
index 74f23ae..33d7a74 100644
--- a/xen/arch/x86/cpu/Makefile
+++ b/xen/arch/x86/cpu/Makefile
@@ -8,3 +8,4 @@ obj-y += intel.o
 obj-y += intel_cacheinfo.o
 obj-y += mwait-idle.o
 obj-y += vpmu.o vpmu_amd.o vpmu_intel.o
+obj-y += intel_pt.o
diff --git a/xen/arch/x86/cpu/intel_pt.c b/xen/arch/x86/cpu/intel_pt.c
new file mode 100644
index 000..520e0ca
--- /dev/null
+++ b/xen/arch/x86/cpu/intel_pt.c
@@ -0,0 +1,27 @@
+/*
+ * intel_pt.c: Support Intel Processor Trace Virtualization.
+ *
+ * Copyright (c) 2018, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; If not, see .
+ *
+ * Author: Luwei Kang 
+ */
+
+#include 
+#include 
+#include 
+
+/* intel_pt: Flag to enable Intel Processor Trace (default on). */
+bool_t __read_mostly opt_intel_pt = 1;
+boolean_param("intel_pt", opt_intel_pt);
diff --git a/xen/include/asm-x86/intel_pt.h b/xen/include/asm-x86/intel_pt.h
new file mode 100644
index 000..2a8b579
--- /dev/null
+++ b/xen/include/asm-x86/intel_pt.h
@@ -0,0 +1,26 @@
+/*
+ * intel_pt.h: Intel Processor Trace virtualization for HVM domain.
+ *
+ * Copyright (c) 2018, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; If not, see .
+ *
+ * Author: Luwei Kang 
+ */
+
+#ifndef __ASM_X86_HVM_INTEL_PT_H_
+#define __ASM_X86_HVM_INTEL_PT_H_
+
+extern bool_t opt_intel_pt;
+
+#endif /* __ASM_X86_HVM_INTEL_PT_H_ */
-- 
1.8.3.1


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

Re: [Xen-devel] [PATCH v8 10/17] x86/hvm: Permit guests direct access to MSR_{SPEC_CTRL, PRED_CMD}

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, January 15, 2018 7:11 PM
> 
> >>> On 12.01.18 at 19:01,  wrote:
> > For performance reasons, HVM guests should have direct access to these
> MSRs
> > when possible.
> >
> > Signed-off-by: Andrew Cooper 
> 
> Reviewed-by: Jan Beulich 
> with one spelling fix (see below)
> 
> As these are non-trivial changes to VMX and SVM code I think you
> should have Cc-ed the maintainers (now added, and leaving the
> full patch in context for them.
> 

Reviewed-by: Kevin Tian , with other
two spelling fixes.

> > ---
> > v7:
> >  * Drop excess brackets
> > ---
> >  xen/arch/x86/domctl.c  | 19 +++
> >  xen/arch/x86/hvm/svm/svm.c |  5 +
> >  xen/arch/x86/hvm/vmx/vmx.c | 18 ++
> >  xen/arch/x86/msr.c |  3 ++-
> >  xen/include/asm-x86/msr.h  |  5 -
> >  5 files changed, 48 insertions(+), 2 deletions(-)
> >
> > diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
> > index 72b4489..e5fdde7 100644
> > --- a/xen/arch/x86/domctl.c
> > +++ b/xen/arch/x86/domctl.c
> > @@ -53,6 +53,7 @@ static int update_domain_cpuid_info(struct domain
> *d,
> >  struct cpuid_policy *p = d->arch.cpuid;
> >  const struct cpuid_leaf leaf = { ctl->eax, ctl->ebx, ctl->ecx, 
> > ctl->edx };
> >  int old_vendor = p->x86_vendor;
> > +unsigned int old_7d0 = p->feat.raw[0].d, old_e8b = p->extd.raw[8].b;
> >  bool call_policy_changed = false; /* Avoid for_each_vcpu()
> unnecessarily */
> >
> >  /*
> > @@ -218,6 +219,14 @@ static int update_domain_cpuid_info(struct
> domain *d,
> >
> >  d->arch.pv_domain.cpuidmasks->_7ab0 = mask;
> >  }
> > +
> > +/*
> > + * If the IBSRB/STIBP policy has changed, we need to recalculate 
> > the

IBRSB

> > + * MSR interception bitmaps and STIBP protection default.
> > + */
> > +call_policy_changed = ((old_7d0 ^ p->feat.raw[0].d) &
> > +   (cpufeat_mask(X86_FEATURE_IBRSB) |
> > +cpufeat_mask(X86_FEATURE_STIBP)));
> >  break;
> >
> >  case 0xa:
> > @@ -292,6 +301,16 @@ static int update_domain_cpuid_info(struct
> domain *d,
> >  d->arch.pv_domain.cpuidmasks->e1cd = mask;
> >  }
> >  break;
> > +
> > +case 0x8008:
> > +/*
> > + * If the IBRB policy has changed, we need to recalculate the MSR

IBPB

> > + * interception bitmaps.
> > + */
> > +call_policy_changed = (is_hvm_domain(d) &&
> > +   ((old_e8b ^ p->extd.raw[8].b) &
> > +cpufeat_mask(X86_FEATURE_IBPB)));
> > +break;
> >  }
> >
> >  if ( call_policy_changed )
> > diff --git a/xen/arch/x86/hvm/svm/svm.c
> b/xen/arch/x86/hvm/svm/svm.c
> > index c48fdfa..ee47508 100644
> > --- a/xen/arch/x86/hvm/svm/svm.c
> > +++ b/xen/arch/x86/hvm/svm/svm.c
> > @@ -617,6 +617,7 @@ static void svm_cpuid_policy_changed(struct vcpu
> *v)
> >  {
> >  struct arch_svm_struct *arch_svm = >arch.hvm_svm;
> >  struct vmcb_struct *vmcb = arch_svm->vmcb;
> > +const struct cpuid_policy *cp = v->domain->arch.cpuid;
> >  u32 bitmap = vmcb_get_exception_intercepts(vmcb);
> >
> >  if ( opt_hvm_fep ||
> > @@ -626,6 +627,10 @@ static void svm_cpuid_policy_changed(struct
> vcpu *v)
> >  bitmap &= ~(1U << TRAP_invalid_op);
> >
> >  vmcb_set_exception_intercepts(vmcb, bitmap);
> > +
> > +/* Give access to MSR_PRED_CMD if the guest has been told about it.
> */
> > +svm_intercept_msr(v, MSR_PRED_CMD,
> > +  cp->extd.ibpb ? MSR_INTERCEPT_NONE :
> MSR_INTERCEPT_RW);
> >  }
> >
> >  static void svm_sync_vmcb(struct vcpu *v)
> > diff --git a/xen/arch/x86/hvm/vmx/vmx.c
> b/xen/arch/x86/hvm/vmx/vmx.c
> > index e036303..8609de3 100644
> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > @@ -656,6 +656,8 @@ void vmx_update_exception_bitmap(struct vcpu
> *v)
> >
> >  static void vmx_cpuid_policy_changed(struct vcpu *v)
> >  {
> > +const struct cpuid_policy *cp = v->domain->arch.cpuid;
> > +
> >  if ( opt_hvm_fep ||
> >   (v->domain->arch.cpuid->x86_vendor !=
> boot_cpu_data.x86_vendor) )
> >  v->arch.hvm_vmx.exception_bitmap |= (1U << TRAP_invalid_op);
> > @@ -665,6 +667,22 @@ static void vmx_cpuid_policy_changed(struct
> vcpu *v)
> >  vmx_vmcs_enter(v);
> >  vmx_update_exception_bitmap(v);
> >  vmx_vmcs_exit(v);
> > +
> > +/*
> > + * We can only pass though MSR_SPEC_CTRL if the guest knows about
> all bits
> 
> "through"
> 
> Jan
> 
> > + * in it.  Otherwise, Xen may be fixing up in the background.
> > + */
> > +v->arch.msr->spec_ctrl.direct_access = cp->feat.ibrsb && cp-
> >feat.stibp;
> > +if ( v->arch.msr->spec_ctrl.direct_access )
> > +

[Xen-devel] [seabios test] 118041: regressions - FAIL

[osstest service owner]

flight 118041 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118041/

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115539
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539
 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-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 seabios  844b86464a5cbfffb62b87808632018ca250d867
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z   73 days
Failing since115733  2017-11-10 17:19:59 Z   66 days   76 attempts
Testing same since   117014  2017-12-08 19:11:23 Z   38 days   31 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Paul Menzel 
  Stefan Berger 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass



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

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

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

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


Not pushing.


commit 844b86464a5cbfffb62b87808632018ca250d867
Author: Paul Menzel 
Date:   Mon Oct 2 08:13:13 2017 +0200

docs/Download: Use more secure HTTPS URLs where possible

Signed-off-by: Paul Menzel 

commit df46d10c8a7b88eb82f3ceb2aa31782dee15593d
Author: Stefan Berger 
Date:   Tue Nov 14 15:03:47 2017 -0500

tpm: Add support for TPM2 ACPI table

Add support for the TPM2 ACPI table. If we find it and its
of the appropriate size, we can get the log_area_start_address
and log_area_minimum_size from it.

The latest version of the spec can be found here:

https://trustedcomputinggroup.org/tcg-acpi-specification/

Signed-off-by: Stefan Berger 

commit 0541f2f0f246e77d7c726926976920e8072d1119
Author: Kevin O'Connor 
Date:   Fri Nov 10 12:20:35 2017 -0500

paravirt: Only enable sercon in NOGRAPHIC mode if no other console specified

[Xen-devel] [qemu-upstream-4.10-testing test] 118021: tolerable FAIL - PUSHED

[osstest service owner]

flight 118021 qemu-upstream-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118021/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 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-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-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  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-amd64-xl-pvhv2-amd 12 guest-start  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-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   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-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop 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-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-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-armhf-armhf-libvirt 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-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail 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-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail 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-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 qemuubb019fb2cbbe23e2419e07bf347f45415360677d
baseline version:
 qemuua4166a0a50dda967f30c9d85fa8aa2ea2539798e

Last test of basis   117345  2017-12-19 18:48:50 Z   27 days
Testing same since   117730  2018-01-08 17:14:22 Z7 days6 attempts


People who touched revisions under test:
  Alex Williamson 
  Alexey Kardashevskiy 
  Anthony PERARD 
  Daniel Henrique Barboza 
  Daniel P. Berrange 
  David Gibson 
  Eric Auger 
  Eric Blake 
  Gerd Hoffmann 
  Greg Kurz 
  Jason Wang 
  Jens Freimann 
  Jim Somerville 
  Kevin Wolf 
  Laurent Vivier 
  Max Reitz 
  Maxime Coquelin 

[Xen-devel] [PATCH v3 1/2] public/hvm/params.h: fix comment for timer_mode default

[Doug Goldstein]

In libxl__domain_build_info_setdefault() in
tools/libxl/libxl_create.c the default for timer_mode for HVM
and PVH is LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS so adjust the
comments in the header to reflect this.
---
CC: Wei Liu 
CC: Ian Jackson 
CC: Roger Pau Monné 
CC: George Dunlap 
CC: Andrew Cooper 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 

change from v2:
- Roger noted that the code differed from the
  header that I used as the source of truth
  so that has created this patch
---
 xen/include/public/hvm/params.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h
index 2ec2e7c80f..ce6748e4a8 100644
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -152,12 +152,12 @@
 
 /*
  * Set mode for virtual timers (currently x86 only):
- *  delay_for_missed_ticks (default):
+ *  delay_for_missed_ticks:
  *   Do not advance a vcpu's time beyond the correct delivery time for
  *   interrupts that have been missed due to preemption. Deliver missed
  *   interrupts when the vcpu is rescheduled and advance the vcpu's virtual
  *   time stepwise for each one.
- *  no_delay_for_missed_ticks:
+ *  no_delay_for_missed_ticks (default):
  *   As above, missed interrupts are delivered, but guest time always tracks
  *   wallclock (i.e., real) time while doing so.
  *  no_missed_ticks_pending:
-- 
2.13.6


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

Re: [Xen-devel] [PATCH v8 15/17] x86/ctxt: Issue a speculation barrier between vcpu contexts

[David Woodhouse]

On Mon, 2018-01-15 at 13:02 +, Andrew Cooper wrote:
> On 15/01/18 12:54, David Woodhouse wrote:
> > 
> > On Fri, 2018-01-12 at 18:01 +, Andrew Cooper wrote:
> > > 
> > > @@ -1736,6 +1736,9 @@ void context_switch(struct vcpu *prev, struct
> > > vcpu *next)
> > >  }
> > >  
> > >  ctxt_switch_levelling(next);
> > > +
> > > +    if ( opt_ibpb )
> > > +    wrmsrl(MSR_PRED_CMD, PRED_CMD_IBPB);
> > >  }
> > > 
> > If you're doing that without an 'else lfence' don't you need to include
> > a comment with your proof that it's safe to do so, and the CPU can't
> > speculate a taken conditional branch and all the way to a problematic
> > instruction?
>
> What would that gain?  A malicious guest could speculate around it, but
> speculation will catch up (at the very latest) when we return to guest,
> which is a serialising event.

There's your proof. I'd just be happier with a blanket policy of
*including* that proof in all cases where we do this kind of runtime
conditional branch around setting IBRS or IBPB. Because if we're in the
habit of doing the 'if (foo) wrmsrl()' without it, we *might* miss a
case where it's not actually OK.

(Aside: Is VMLAUNCH actually architecturally guaranteed to be
serialising? That doesn't seem consistent with a long-term goal of
designing hardware to make VMs go faster. Or have we merely extracted a
promise from Intel that *current* hardware will stop speculative
execution when it hits a VMLAUNCH?)
 
> > 
> > Also... if you're doing that in context_switch() does it do the right
> > thing with idle? If a CPU switches to the idle domain and then back
> > again to the same vCPU, does that do the IBPB twice?
>
> Context switches to idle will skip the IBPB because it isn't needed, but
> any switch to non-idle need it.  In your example, we should execute just
> a single IBPB.

In my example I think we should not execute IBPB at all. We come from a
given VMCS, sleep for a while, and go back to it. No need for any
flushing whatsoever.

> > 
> > For vmx we only really need IBPB when we do VMPTRLD, right?
>
> That is part of IBRS_ATT is it not?

It doesn't go away with IBRS_ALL (as it's now called), but it's the
same for the existing IBRS *and* retpoline. Doing it on VMPTRLD is what
Linux is doing.

(cf. https://lkml.org/lkml/2018/1/13/40 and
     https://lkml.org/lkml/2018/1/15/146 and note the AMD SVM caveat.)




smime.p7s
Description: S/MIME cryptographic signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 6/6] x86/domctl: Remove XEN_DOMCTL_pin_mem_cacheattr

[Paul Durrant]

> -Original Message-
> From: Ross Lagerwall [mailto:ross.lagerw...@citrix.com]
> Sent: 12 January 2018 12:45
> To: xen-de...@lists.xen.org
> Cc: Ross Lagerwall ; Paul Durrant
> ; Daniel De Graaf ; Ian
> Jackson ; Wei Liu ; Andrew
> Cooper ; George Dunlap
> ; Jan Beulich ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> ; Tim (Xen.org) 
> Subject: [PATCH v3 6/6] x86/domctl: Remove
> XEN_DOMCTL_pin_mem_cacheattr
> 
> Remove the implementation of XEN_DOMCTL_pin_mem_cacheattr since it
> has
> been replaced by a dmop. Change xc_domain_pin_memory_cacheattr() so
> that it is only defined when XC_WANT_COMPAT_DEVICEMODEL_API is set
> and
> have it call the new dmop.  Leave the definitions of
> XEN_DOMCTL_MEM_CACHEATTR_* since they are still used by QEMU.
> 
> Signed-off-by: Ross Lagerwall 

Reviewed-by: Paul Durrant 

> ---
> 
> New in v3.
> 
>  tools/flask/policy/modules/xen.if   |  4 ++--
>  tools/libs/devicemodel/include/xendevicemodel.h |  2 +-
>  tools/libxc/include/xenctrl.h   |  6 --
>  tools/libxc/include/xenctrl_compat.h|  3 +++
>  tools/libxc/xc_devicemodel_compat.c |  8 
>  tools/libxc/xc_domain.c | 15 ---
>  xen/arch/x86/domctl.c   |  8 
>  xen/include/public/domctl.h |  7 +--
>  xen/include/public/hvm/dm_op.h  | 10 +-
>  xen/xsm/flask/hooks.c   |  3 ---
>  xen/xsm/flask/policy/access_vectors |  2 --
>  11 files changed, 24 insertions(+), 44 deletions(-)
> 
> diff --git a/tools/flask/policy/modules/xen.if
> b/tools/flask/policy/modules/xen.if
> index cb48a6c..459880b 100644
> --- a/tools/flask/policy/modules/xen.if
> +++ b/tools/flask/policy/modules/xen.if
> @@ -57,7 +57,7 @@ define(`create_domain_common', `
>   allow $1 $2:shadow enable;
>   allow $1 $2:mmu { map_read map_write adjust memorymap
> physmap pinpage mmuext_op updatemp };
>   allow $1 $2:grant setup;
> - allow $1 $2:hvm { cacheattr getparam hvmctl sethvmc
> + allow $1 $2:hvm { getparam hvmctl sethvmc
>   setparam nested altp2mhvm altp2mhvm_op dm };
>  ')
> 
> @@ -151,7 +151,7 @@ define(`device_model', `
> 
>   allow $1 $2_target:domain { getdomaininfo shutdown };
>   allow $1 $2_target:mmu { map_read map_write adjust physmap
> target_hack };
> - allow $1 $2_target:hvm { getparam setparam hvmctl cacheattr dm };
> + allow $1 $2_target:hvm { getparam setparam hvmctl dm };
>  ')
> 
>  # make_device_model(priv, dm_dom, hvm_dom)
> diff --git a/tools/libs/devicemodel/include/xendevicemodel.h
> b/tools/libs/devicemodel/include/xendevicemodel.h
> index 9e60288..892e770 100644
> --- a/tools/libs/devicemodel/include/xendevicemodel.h
> +++ b/tools/libs/devicemodel/include/xendevicemodel.h
> @@ -347,7 +347,7 @@ int xendevicemodel_add_to_physmap(
>   * @parm domid the domain id to be serviced
>   * @parm start Start gfn
>   * @parm end End gfn
> - * @parm type XEN_DOMCTL_MEM_CACHEATTR_*
> + * @parm type XEN_DMOP_MEM_CACHEATTR_*
>   * @return 0 on success, -1 on failure.
>   */
>  int xendevicemodel_pin_memory_cacheattr(
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 09e1363..aa9472d 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1472,12 +1472,6 @@ int xc_domain_iomem_permission(xc_interface
> *xch,
> unsigned long nr_mfns,
> uint8_t allow_access);
> 
> -int xc_domain_pin_memory_cacheattr(xc_interface *xch,
> -   uint32_t domid,
> -   uint64_t start,
> -   uint64_t end,
> -   uint32_t type);
> -
>  unsigned long xc_make_page_below_4G(xc_interface *xch, uint32_t
> domid,
>  unsigned long mfn);
> 
> diff --git a/tools/libxc/include/xenctrl_compat.h
> b/tools/libxc/include/xenctrl_compat.h
> index a655e47..464f645 100644
> --- a/tools/libxc/include/xenctrl_compat.h
> +++ b/tools/libxc/include/xenctrl_compat.h
> @@ -164,6 +164,9 @@ int xc_hvm_set_mem_type(
>  int xc_hvm_inject_trap(
>  xc_interface *xch, uint32_t domid, int vcpu, uint8_t vector,
>  uint8_t type, uint32_t error_code, uint8_t insn_len, uint64_t cr2);
> +int xc_domain_pin_memory_cacheattr(
> +xc_interface *xch, uint32_t domid, uint64_t start, uint64_t end,
> +uint32_t type);
> 
>  #endif /* XC_WANT_COMPAT_DEVICEMODEL_API */
> 
> diff --git a/tools/libxc/xc_devicemodel_compat.c
> 

Re: [Xen-devel] [PATCH] docs: note default for timer_mode in xl.cfg man

[Roger Pau Monné]

On Sun, Jan 14, 2018 at 11:28:15PM -0600, Doug Goldstein wrote:
> There was no default documented but the header at
> xen/include/public/hvm/params.h stated which the default was, so add it
> to the docs.
> 
> Signed-off-by: Doug Goldstein 
> ---
> CC: Wei Liu 
> CC: Ian Jackson 
> # George for the 4.8 and 4.9 backport
> CC: George Dunlap 
> ---
>  docs/man/xl.cfg.pod.5.in | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
> index b7b91d8627..358a378e1e 100644
> --- a/docs/man/xl.cfg.pod.5.in
> +++ b/docs/man/xl.cfg.pod.5.in
> @@ -2348,7 +2348,8 @@ Specifies the mode for Virtual Timers. The valid values 
> are as follows:
>  Delay for missed ticks. Do not advance a vCPU's time beyond the
>  correct delivery time for interrupts that have been missed due to
>  preemption. Deliver missed interrupts when the vCPU is rescheduled and
> -advance the vCPU's virtual time stepwise for each one.
> +advance the vCPU's virtual time stepwise for each one. This is the
> +default.

This AFAICT also needs to be fixed for HVM guests, around line ~1921
in the same doc.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH] -xen-attach is needed for pvh boot with qemu-xen

[Roger Pau Monné]

On Sun, Jan 14, 2018 at 09:12:51PM +, Michael Young wrote:
> Currently the boot of a pvh guest using the qemu-xen device model fails
> with the error
> xen emulation not implemented (yet)
> in the qemu-dm log file. This patch adds the missing -xen-attach
> argument.
> 
> Signed-off-by: Michael Young 
> ---
>  tools/libxl/libxl_dm.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index a2ea95a9be..3a839d5c1e 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -1021,7 +1021,8 @@ static int libxl__build_device_model_args_new(libxl__gc 
> *gc,
>   */
>  flexarray_append(dm_args, "-no-user-config");
> 
> -if (b_info->type == LIBXL_DOMAIN_TYPE_PV) {
> +if ((b_info->type == LIBXL_DOMAIN_TYPE_PV) ||
> +(b_info->type == LIBXL_DOMAIN_TYPE_PVH)) {

Better write this as b_info->type != LIBXL_DOMAIN_TYPE_HVM.

With that fixed:

Reviewed-by: Roger Pau Monné 

And sorry for that, I could bet I've tried that.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v8 12/17] x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point

[Jan Beulich]

>>> On 12.01.18 at 19:01,  wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -668,6 +668,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  set_processor_id(0);
>  set_current(INVALID_VCPU); /* debug sanity. */
>  idle_vcpu[0] = current;
> +init_shadow_spec_ctrl_state();

Considering the strict need to fill struct cpu_info fields early on (also
in my SP3 band-aid) I wonder whether we wouldn't be better off
uniformly memset()-ing the whole structure first thing here and in
start_secondary(). But this is just a remark, not necessarily
something to be done in this patch.

> @@ -586,6 +611,10 @@ ENTRY(double_fault)
>  movl  $TRAP_double_fault,4(%rsp)
>  /* Set AC to reduce chance of further SMAP faults */
>  SAVE_ALL STAC
> +
> +SPEC_CTRL_ENTRY_FROM_INTR /* Req: %rsp=regs Clob: acd */
> +/* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */

Is it actually useful to do _anything_ in the double fault handler?

> +.macro DO_SPEC_CTRL_ENTRY maybexen:req ibrs_val:req
> +/*
> + * Requires %rsp=regs (also cpuinfo if !maybexen)
> + * Clobbers %rax, %rcx, %rdx
> + *
> + * PV guests can't update MSR_SPEC_CTRL behind Xen's back, so no need to read
> + * it back.  Entries from guest context need to clear SPEC_CTRL shadowing,
> + * while entries from Xen must leave shadowing in its current state.
> + */
> +mov $MSR_SPEC_CTRL, %ecx
> +
> +.if \maybexen
> +cmpw $__HYPERVISOR_CS, UREGS_cs(%rsp)

I see you've changed to cmpw here. To eliminate your length-
changing-prefix concern, how about using testb instead to
just evaluate RPL or the selector, as I'm doing in the SP3
band-aid?

Jan


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

Re: [Xen-devel] [PATCH v8 15/17] x86/ctxt: Issue a speculation barrier between vcpu contexts

[David Woodhouse]

On Fri, 2018-01-12 at 18:01 +, Andrew Cooper wrote:
> 
> @@ -1736,6 +1736,9 @@ void context_switch(struct vcpu *prev, struct
> vcpu *next)
>  }
>  
>  ctxt_switch_levelling(next);
> +
> +    if ( opt_ibpb )
> +    wrmsrl(MSR_PRED_CMD, PRED_CMD_IBPB);
>  }
> 

If you're doing that without an 'else lfence' don't you need to include
a comment with your proof that it's safe to do so, and the CPU can't
speculate a taken conditional branch and all the way to a problematic
instruction?

Also... if you're doing that in context_switch() does it do the right
thing with idle? If a CPU switches to the idle domain and then back
again to the same vCPU, does that do the IBPB twice?

For vmx we only really need IBPB when we do VMPTRLD, right?

smime.p7s
Description: S/MIME cryptographic signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v8 15/17] x86/ctxt: Issue a speculation barrier between vcpu contexts

[Andrew Cooper]

On 15/01/18 12:54, David Woodhouse wrote:
> On Fri, 2018-01-12 at 18:01 +, Andrew Cooper wrote:
>> @@ -1736,6 +1736,9 @@ void context_switch(struct vcpu *prev, struct
>> vcpu *next)
>>  }
>>  
>>  ctxt_switch_levelling(next);
>> +
>> +    if ( opt_ibpb )
>> +    wrmsrl(MSR_PRED_CMD, PRED_CMD_IBPB);
>>  }
>>
> If you're doing that without an 'else lfence' don't you need to include
> a comment with your proof that it's safe to do so, and the CPU can't
> speculate a taken conditional branch and all the way to a problematic
> instruction?

What would that gain?  A malicious guest could speculate around it, but
speculation will catch up (at the very latest) when we return to guest,
which is a serialising event.

There is nothing a guest can usefully achieve by attacking this branch,
because it can't prevent the WRMSR from happening before we leave
hypervisor context.

> Also... if you're doing that in context_switch() does it do the right
> thing with idle? If a CPU switches to the idle domain and then back
> again to the same vCPU, does that do the IBPB twice?

Context switches to idle will skip the IBPB because it isn't needed, but
any switch to non-idle need it.  In your example, we should execute just
a single IBPB.

> For vmx we only really need IBPB when we do VMPTRLD, right?

That is part of IBRS_ATT is it not?

At which point it pertains to reuse of a VMCS for a new security
context, but that should be covered by the context switch IBPB.

~Andrew

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

[Xen-devel] [distros-debian-sid test] 74460: trouble: blocked/broken

[Platform Team regression test user]

flight 74460 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74460/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvopsbroken
 build-i386   broken
 build-amd64-pvopsbroken
 build-armhf  broken
 build-amd64  broken
 build-i386-pvops broken
 build-armhf-pvops 3 syslog-serverrunning
 build-armhf   3 syslog-serverrunning

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-i386-sid-netboot-pygrub  1 build-check(1) blocked n/a
 test-amd64-i386-i386-sid-netboot-pvgrub  1 build-check(1)  blocked n/a
 test-armhf-armhf-armhf-sid-netboot-pygrub  1 build-check(1)blocked n/a
 test-amd64-i386-amd64-sid-netboot-pygrub  1 build-check(1) blocked n/a
 test-amd64-amd64-amd64-sid-netboot-pvgrub  1 build-check(1)blocked n/a
 build-armhf-pvops 4 host-install(4)  broken like 74086
 build-armhf   4 host-install(4)  broken like 74086
 build-armhf   5 capture-logs broken like 74086
 build-armhf-pvops 5 capture-logs broken like 74086
 build-amd64   4 host-install(4)  broken like 74086
 build-amd64-pvops 4 host-install(4)  broken like 74086
 build-i3864 host-install(4)  broken like 74086
 build-i386-pvops  4 host-install(4)  broken like 74086

baseline version:
 flight   74086

jobs:
 build-amd64  broken  
 build-armhf  broken  
 build-i386   broken  
 build-amd64-pvopsbroken  
 build-armhf-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-amd64-sid-netboot-pvgrubblocked 
 test-amd64-i386-i386-sid-netboot-pvgrub  blocked 
 test-amd64-i386-amd64-sid-netboot-pygrub blocked 
 test-armhf-armhf-armhf-sid-netboot-pygrubblocked 
 test-amd64-amd64-i386-sid-netboot-pygrub blocked 



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH] fix potential null dereference

[Jan Beulich]

>>> On 13.01.18 at 07:21,  wrote:
> On 01/12/2018 11:40 PM, Stefano Stabellini wrote:
>> handles can theoretically be NULL, check for it explicitly before
>> dereferencing it.
> 
> I doubt handles could be NULL if LocateHandle succeed. This seems to be 
> confirmed by the spec (Page 208 in UEFI spec 2.7).
> 
> So I am not entirely convince we should add yet another check in the 
> code. An ASSERT might be better.

Indeed if there is a platform where NULL is coming back in the
success case, that platform should be named as a justification
in the commit message. Otherwise I don't see the value of this
change.

Jan


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

Re: [Xen-devel] [PATCH] don't pass r12/x16 as reference

[Julien Grall]

Hi Stefano,

On 01/13/2018 12:07 AM, Stefano Stabellini wrote:

r12 and x16 are of different sizes; when passing r12 as a reference to
do_trap_hypercall on arm64, we end up dereferencing it as a pointer to a
64bit value, but actually it isn't.

Instead, pass r12/x16 as values and explicitly overwrite them when
necessary, using the pointer name.

CID: 1457708
Signed-off-by: Stefano Stabellini 

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 013c160..3b31917 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1453,6 +1453,7 @@ static void do_debug_trap(struct cpu_user_regs *regs, 
unsigned int code)
  
  #ifdef CONFIG_ARM_64

  #define HYPERCALL_RESULT_REG(r) (r)->x0
+#define HYPERCALL_NR(r) (r)->x16
  #define HYPERCALL_ARG1(r) (r)->x0
  #define HYPERCALL_ARG2(r) (r)->x1
  #define HYPERCALL_ARG3(r) (r)->x2
@@ -1461,6 +1462,7 @@ static void do_debug_trap(struct cpu_user_regs *regs, 
unsigned int code)
  #define HYPERCALL_ARGS(r) (r)->x0, (r)->x1, (r)->x2, (r)->x3, (r)->x4
  #else
  #define HYPERCALL_RESULT_REG(r) (r)->r0
+#define HYPERCALL_NR(r) (r)->r12
  #define HYPERCALL_ARG1(r) (r)->r0
  #define HYPERCALL_ARG2(r) (r)->r1
  #define HYPERCALL_ARG3(r) (r)->r2
@@ -1469,7 +1471,7 @@ static void do_debug_trap(struct cpu_user_regs *regs, 
unsigned int code)
  #define HYPERCALL_ARGS(r) (r)->r0, (r)->r1, (r)->r2, (r)->r3, (r)->r4
  #endif
  
-static void do_trap_hypercall(struct cpu_user_regs *regs, register_t *nr,

+static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned int nr,
unsigned long iss)
  {
  arm_hypercall_fn_t call = NULL;
@@ -1479,7 +1481,7 @@ static void do_trap_hypercall(struct cpu_user_regs *regs, 
register_t *nr,
  if ( iss != XEN_HYPERCALL_TAG )
  domain_crash_synchronous();
  
-if ( *nr >= ARRAY_SIZE(arm_hypercall_table) )

+if ( nr >= ARRAY_SIZE(arm_hypercall_table) )
  {
  perfc_incr(invalid_hypercalls);
  HYPERCALL_RESULT_REG(regs) = -ENOSYS;
@@ -1488,8 +1490,8 @@ static void do_trap_hypercall(struct cpu_user_regs *regs, 
register_t *nr,
  
  current->hcall_preempted = false;
  
-perfc_incra(hypercalls, *nr);

-call = arm_hypercall_table[*nr].fn;
+perfc_incra(hypercalls, nr);
+call = arm_hypercall_table[nr].fn;
  if ( call == NULL )
  {
  HYPERCALL_RESULT_REG(regs) = -ENOSYS;
@@ -1502,7 +1504,7 @@ static void do_trap_hypercall(struct cpu_user_regs *regs, 
register_t *nr,
  if ( !current->hcall_preempted )
  {
  /* Deliberately corrupt parameter regs used by this hypercall. */
-switch ( arm_hypercall_table[*nr].nr_args ) {
+switch ( arm_hypercall_table[nr].nr_args ) {
  case 5: HYPERCALL_ARG5(regs) = 0xDEADBEEF;
  case 4: HYPERCALL_ARG4(regs) = 0xDEADBEEF;
  case 3: HYPERCALL_ARG3(regs) = 0xDEADBEEF;
@@ -1511,7 +1513,7 @@ static void do_trap_hypercall(struct cpu_user_regs *regs, 
register_t *nr,
  break;
  default: BUG();
  }
-*nr = 0xDEADBEEF;
+HYPERCALL_NR(regs) = 0xDEADBEEF;


This change is not correct. You don't take into account the fact that on 
32-bit domain, the result register will be r12 and 64-bit domain x16.



  }
  #endif
  
@@ -2131,7 +2133,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, (register_t *)>r12, hsr.iss);
+do_trap_hypercall(regs, regs->r12, hsr.iss);


IHMO it would be better to avoid modify do_trap_hypercall and just save 
r12 in a temporary variable, use that variable as 2 second argument and 
write-back the variable in r12.


This would make do_trap_hypercall future proof.


  break;
  #ifdef CONFIG_ARM_64
  case HSR_EC_HVC64:
@@ -2143,7 +2145,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, regs->x16, hsr.iss);
  break;
  case HSR_EC_SMC64:
  /*



Cheers,

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

Re: [Xen-devel] [PATCH] x86: Meltdown band-aid against malicious 64-bit PV guests

[Jan Beulich]

>>> On 13.01.18 at 18:48,  wrote:
> On 12/01/18 10:19, Jan Beulich wrote:
>> This is a very simplistic change limiting the amount of memory a running
>> 64-bit PV guest has mapped (and hence available for attacking): Only the
>> mappings of stack, IDT, and TSS are being cloned from the direct map
>> into per-CPU page tables. Guest controlled parts of the page tables are
>> being copied into those per-CPU page tables upon entry into the guest.
>> Cross-vCPU synchronization of top level page table entry changes is
>> being effected by forcing other active vCPU-s of the guest into the
>> hypervisor.
>>
>> The change to context_switch() isn't strictly necessary, but there's no
>> reason to keep switching page tables once a PV guest is being scheduled
>> out.
>>
>> There is certainly much room for improvement, especially of performance,
>> here - first and foremost suppressing all the negative effects on AMD
>> systems. But in the interest of backportability (including to really old
>> hypervisors, which may not even have alternative patching) any such is
>> being left out here.
>>
>> Signed-off-by: Jan Beulich 
> 
> I would do with the answer to my question at the end before completing a
> review.  In the meantime, some observations.
> 
>> ---
>> TBD: Is forcing an event check interrupt for synchronization purposes
>> enough? It may be necessary to actually wait for remote vCPU-s to have
>> touched into the hypervisor, in which case a function-call-IPI should be
>> sent, with an empty handler (a flush-IPI with zero operation mask would
>> also do). Otoh, if the vCPU isn't already in hypervisor context,
>> delivery of the IPI should be almost instantly (as interrupts are always
>> enabled while in guest mode).
> 
> From a vcpu consistency point of view, once the hypercall making this
> change returns, no other vcpus should have executed an instruction with
> a stale view of the L4.
> 
> Therefore, I think you need to wait until the IPI has at least called
> into hypervisor context before releasing the current vcpu, safe in the
> knowledge that the update will be picked up on the way back out.

Okay, I'll switch to an empty-mask flush IPI then, unless you strongly
think the call-func one would be better.

>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -3683,6 +3683,20 @@ long do_mmu_update(
>>  break;
>>  rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn,
>>cmd == MMU_PT_UPDATE_PRESERVE_AD, v);
>> +if ( !rc )
> 
> Perhaps && (d->max_vcpus > 1) ?

Could do, but the removal of the CPU we're running on (below) will
take care of avoiding the IPI anyway. I would prefer to not put in
redundant conditions, but if you strongly feel about this, I can add
it.

>> +{
>> +/*
>> + * Force other vCPU-s of the affected guest to pick 
>> up
>> + * the change (if any).
>> + */
>> +unsigned int cpu = smp_processor_id();
>> +cpumask_t *mask = per_cpu(scratch_cpumask, cpu);
>> +
>> +cpumask_andnot(mask, pt_owner->domain_dirty_cpumask,
>> +   cpumask_of(cpu));
> 
> cpumask_copy() and __clear_bit(, cpu) is probably faster?

I'm not sure, and hence I'd prefer to keep it this way. But again,
if you feel strongly, I can make the change.

>> +if ( !cpumask_empty(mask) )
>> +smp_send_event_check_mask(mask);
>> +}
> 
> In terms of performance, if this shadowing/sync algorithm is correct,
> then it would be better to defer the IPI until after the update loop. 
> We only need force other vcpus once per mmu_update hypercall if there is
> an L4 update, rather than for each L4 update in the batch.

Oh, that's a very good point. Let me do that right away (together
with switching the IPI kind).

>> @@ -633,6 +636,181 @@ void cpu_exit_clear(unsigned int cpu)
>>  set_cpu_state(CPU_STATE_DEAD);
>>  }
>>  
>> +static bool clone_mapping(const void *ptr, root_pgentry_t *rpt)
> 
> Could we introduce these functions with ints and use -ENOMEM?

No problem.

>> +{
>> +unsigned long linear = (unsigned long)ptr, pfn;
>> +unsigned int flags;
>> +l3_pgentry_t *l3t = 
>> l4e_to_l3e(idle_pg_table[root_table_offset(linear)]);
>> +l2_pgentry_t *l2t;
>> +l1_pgentry_t *l1t;
>> +
>> +if ( linear < DIRECTMAP_VIRT_START )
>> +return true;
>> +
>> +flags = l3e_get_flags(l3t[l3_table_offset(linear)]);
>> +ASSERT(flags & _PAGE_PRESENT);
>> +if ( flags & _PAGE_PSE )
>> +{
>> +pfn = (l3e_get_pfn(l3t[l3_table_offset(linear)]) &
>> +   ~((1UL << (2 * PAGETABLE_ORDER)) - 1)) |
>> +  (PFN_DOWN(linear) & ((1UL << (2 * PAGETABLE_ORDER)) - 1));

Re: [Xen-devel] [PATCH v8 01/17] x86: Support compiling with indirect branch thunks

[Jan Beulich]

>>> On 15.01.18 at 11:40,  wrote:
> On 15/01/18 10:14, Jan Beulich wrote:
> On 12.01.18 at 19:00,  wrote:
>>> --- a/xen/arch/x86/Rules.mk
>>> +++ b/xen/arch/x86/Rules.mk
>>> @@ -30,3 +30,10 @@ CFLAGS += -fno-asynchronous-unwind-tables
>>>  ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n)
>>>  CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE
>>>  endif
>>> +
>>> +# Compile with thunk-extern, indirect-branch-register if avaiable.
>>> +ifneq ($(call cc-option,$(CC),-mindirect-branch-register,n),n)
>>> +CFLAGS += -mindirect-branch=thunk-extern -mindirect-branch-register
>>> +CFLAGS += -DCONFIG_INDIRECT_THUNK
>>> +export CONFIG_INDIRECT_THUNK=y
>>> +endif
>> Still not a proper config option?
> 
> No, for backportability.
> 
> I'm preparing a post-SP2 series with some cleanup for staging.
> 
>>
>>> --- /dev/null
>>> +++ b/xen/arch/x86/indirect-thunk.S
>>> @@ -0,0 +1,38 @@
>>> +/*
>>> + * Implement __x86_indirect_thunk_* symbols for use with compatbile 
> compilers
>>> + * and the -mindirect-branch=thunk-extern -mindirect-branch-register 
> options.
>>> + *
>>> + * Copyright (c) 2017-2018 Citrix Systems Ltd.
>>> + *
>>> + * This source code is licensed under the GNU General Public License,
>>> + * Version 2.  See the file COPYING for more details.
>>> + */
>>> +.file __FILE__
>>> +
>>> +#include 
>>> +
>>> +.macro IND_THUNK_RETPOLINE reg:req
>>> +call 2f
>>> +1:
>>> +lfence
>>> +jmp 1b
>>> +2:
>> As noted in a couple of other places, I'd prefer if numeric labels
>> weren't used in macros (and especially new ones), in favor of
>> .L ones utilizing \@.
> 
> For macros in header files, I can see this rational.
> 
> However, this is a local macro which only gets expanded in this file,
> and isn't likely to move elsewhere.  I don't see the value in reducing
> the readability.
> 
>>
>>> +mov %\reg, (%rsp)
>>> +ret
>>> +.endm
>>> +
>>> +/*
>>> + * Build the __x86_indirect_thunk_* symbols.  Currently implement the
>>> + * retpoline thunk only.
>>> + */
>>> +.macro GEN_INDIRECT_THUNK reg:req
>>> +.section .text.__x86_indirect_thunk_\reg, "ax", @progbits
>>> +
>>> +ENTRY(__x86_indirect_thunk_\reg)
>>> +IND_THUNK_RETPOLINE \reg
>>> +.endm
>> Still unnecessary leading underscores in the section name?
> 
> Having the section names different to the symbols in them is far worse
> than using double underscores.

Well, okay then:
Acked-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH v8 02/17] x86: Support indirect thunks from assembly code

[Jan Beulich]

>>> On 12.01.18 at 19:00,  wrote:
> Introduce INDIRECT_CALL and INDIRECT_JMP which either degrade to a normal
> indirect branch, or dispatch to the __x86_indirect_thunk_* symbols.
> 
> Update all the manual indirect branches in to use the new thunks.  The
> indirect branches in the early boot and kexec path are left intact as we 
> can't
> use the compiled-in thunks at those points.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 
with a couple of cosmetic remarks:

> --- a/xen/arch/x86/pv/emul-priv-op.c
> +++ b/xen/arch/x86/pv/emul-priv-op.c
> @@ -73,46 +73,63 @@ void (*pv_post_outb_hook)(unsigned int port, u8 value);
>  
>  typedef void io_emul_stub_t(struct cpu_user_regs *);
>  
> +void __x86_indirect_thunk_rcx(void);
> +
>  static io_emul_stub_t *io_emul_stub_setup(struct priv_op_ctxt *ctxt, u8 
> opcode,
>unsigned int port, unsigned int 
> bytes)
>  {
> +struct stubs *this_stubs = _cpu(stubs);
> +unsigned long stub_va = this_stubs->addr + STUB_BUF_SIZE / 2;
>  bool use_quirk_stub = false;
>  
>  if ( !ctxt->io_emul_stub )
> -ctxt->io_emul_stub = map_domain_page(_mfn(this_cpu(stubs.mfn))) +
> - (this_cpu(stubs.addr) &
> -  ~PAGE_MASK) +
> - STUB_BUF_SIZE / 2;
> +ctxt->io_emul_stub =
> +map_domain_page(_mfn(this_stubs->mfn)) + (stub_va & ~PAGE_MASK);
>  
>  /* movq $host_to_guest_gpr_switch,%rcx */
>  ctxt->io_emul_stub[0] = 0x48;
>  ctxt->io_emul_stub[1] = 0xb9;
>  *(void **)>io_emul_stub[2] = (void *)host_to_guest_gpr_switch;
> +
> +#ifdef CONFIG_INDIRECT_THUNK
> +/* callq __x86_indirect_thunk_rcx */
> +ctxt->io_emul_stub[10] = 0xe8;
> +*(int32_t *)>io_emul_stub[11] =
> +(unsigned long)__x86_indirect_thunk_rcx - (stub_va + 11 + 4);

Given the context I think a cast to signed long would be more
appropriate here.

> +
> +#else
>  /* callq *%rcx */

Given the rest of the conditional you add, please either remove
the blank line above or add three more immediately inside the
preprocessor directives.

>  ctxt->io_emul_stub[10] = 0xff;
>  ctxt->io_emul_stub[11] = 0xd1;
>  
> +/*
> + * 3 bytes of P6_NOPS.
> + * TODO: untangle ideal_nops from init/livepatch Kconfig options.
> + */
> +memcpy(>io_emul_stub[12], "\x0f\x1f\x00", 3);

Perhaps better "P6_NOP3" in the comment? And perhaps
__stringify(P6_NOP3) in the memcpy() invocation, which may then
make unnecessary that part of the comment?

Jan


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

Re: [Xen-devel] [xen-unstable test] 117920: regressions - FAIL

[Roger Pau Monné]

On Sat, Jan 13, 2018 at 07:52:08PM +, osstest service owner wrote:
> flight 117920 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/117920/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64-xsm   6 xen-buildfail REGR. vs. 
> 117311

This failure is quite weird:

2018-01-12 16:36:28 Z host host: selected godello1 54:9f:35:05:fd:88 
172.16.144.37 - shared build-jessie-amd64 
ce0425073e009236459639b0982a44048bee4adf ready 3 
2018-01-12 16:36:28 Z executing ssh ... osstest@172.16.144.37 mkdir -p 
/home/osstest/build.117920.build-amd64-xsm 
Warning: Permanently added '172.16.144.37' (ECDSA) to the list of known hosts.
Permission denied (publickey,password).
2018-01-12 16:36:29 Z command nonzero waitstatus 65280: timeout 90 ssh -o 
StrictHostKeyChecking=no -o BatchMode=yes -o ConnectTimeout=100 -o 
ServerAliveInterval=100 -o PasswordAuthentication=no -o 
ChallengeResponseAuthentication=no -o 
UserKnownHostsFile=tmp/t.known_hosts_117920.build-amd64-xsm 
osstest@172.16.144.37 mkdir -p /home/osstest/build.117920.build-amd64-xsm 

Wrong ssh id files?

Roger.

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

Re: [Xen-devel] [PATCH v8 05/17] x86: Introduce alternative indirect thunks

[Jan Beulich]

>>> On 12.01.18 at 19:00,  wrote:
> Depending on hardware and microcode availability, we will want to replace
> IND_THUNK_REPOLINE with other implementations.
> 
> For AMD hardware, choose IND_THUNK_LFENCE in preference to retpoline if lfence
> is known to be (or was successfully made) dispatch serialising.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH v8 01/17] x86: Support compiling with indirect branch thunks

[Andrew Cooper]

On 15/01/18 10:14, Jan Beulich wrote:
 On 12.01.18 at 19:00,  wrote:
>> --- a/xen/arch/x86/Rules.mk
>> +++ b/xen/arch/x86/Rules.mk
>> @@ -30,3 +30,10 @@ CFLAGS += -fno-asynchronous-unwind-tables
>>  ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n)
>>  CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE
>>  endif
>> +
>> +# Compile with thunk-extern, indirect-branch-register if avaiable.
>> +ifneq ($(call cc-option,$(CC),-mindirect-branch-register,n),n)
>> +CFLAGS += -mindirect-branch=thunk-extern -mindirect-branch-register
>> +CFLAGS += -DCONFIG_INDIRECT_THUNK
>> +export CONFIG_INDIRECT_THUNK=y
>> +endif
> Still not a proper config option?

No, for backportability.

I'm preparing a post-SP2 series with some cleanup for staging.

>
>> --- /dev/null
>> +++ b/xen/arch/x86/indirect-thunk.S
>> @@ -0,0 +1,38 @@
>> +/*
>> + * Implement __x86_indirect_thunk_* symbols for use with compatbile 
>> compilers
>> + * and the -mindirect-branch=thunk-extern -mindirect-branch-register 
>> options.
>> + *
>> + * Copyright (c) 2017-2018 Citrix Systems Ltd.
>> + *
>> + * This source code is licensed under the GNU General Public License,
>> + * Version 2.  See the file COPYING for more details.
>> + */
>> +.file __FILE__
>> +
>> +#include 
>> +
>> +.macro IND_THUNK_RETPOLINE reg:req
>> +call 2f
>> +1:
>> +lfence
>> +jmp 1b
>> +2:
> As noted in a couple of other places, I'd prefer if numeric labels
> weren't used in macros (and especially new ones), in favor of
> .L ones utilizing \@.

For macros in header files, I can see this rational.

However, this is a local macro which only gets expanded in this file,
and isn't likely to move elsewhere.  I don't see the value in reducing
the readability.

>
>> +mov %\reg, (%rsp)
>> +ret
>> +.endm
>> +
>> +/*
>> + * Build the __x86_indirect_thunk_* symbols.  Currently implement the
>> + * retpoline thunk only.
>> + */
>> +.macro GEN_INDIRECT_THUNK reg:req
>> +.section .text.__x86_indirect_thunk_\reg, "ax", @progbits
>> +
>> +ENTRY(__x86_indirect_thunk_\reg)
>> +IND_THUNK_RETPOLINE \reg
>> +.endm
> Still unnecessary leading underscores in the section name?

Having the section names different to the symbols in them is far worse
than using double underscores.

~Andrew

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

Re: [Xen-devel] [PATCH v8 11/17] x86: Protect unaware domains from meddling hyperthreads

[Jan Beulich]

>>> On 12.01.18 at 19:01,  wrote:
> --- a/xen/include/asm-x86/spec_ctrl.h
> +++ b/xen/include/asm-x86/spec_ctrl.h
> @@ -20,8 +20,29 @@
>  #ifndef __X86_SPEC_CTRL_H__
>  #define __X86_SPEC_CTRL_H__
>  
> +#include 
> +
>  void init_speculation_mitigations(void);
>  
> +/*
> + * For guests which know about IBRS but are not told about STIBP running on
> + * hardware supporting hyperthreading, the guest doesn't know to protect
> + * itself fully.  (Such a guest won't be permitted direct access to the MSR.)
> + * Have Xen fill in the gaps, so an unaware guest can't be interfered with by
> + * a meddling guest on an adjacent hyperthread.
> + */
> +static inline unsigned int spec_ctrl_host_val(const struct domain *d,
> +  unsigned int guest_val)
> +{
> +const struct cpuid_policy *cp = d->arch.cpuid;
> +
> +if ( !cp->feat.stibp && cpu_has_stibp &&
> + !(guest_val & (SPEC_CTRL_IBRS | SPEC_CTRL_STIBP)) )
> +return SPEC_CTRL_STIBP;
> +else
> +return guest_val;
> +}

The comment's "won't be permitted direct access" can be verified
by looking at patch 10, but where's the HT dependency here (or
in another patch)? For now it looks to me as if you enabled this
behind-the-back protection even in the non-HT case.

Jan


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