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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsmbroken
 test-amd64-amd64-xl-qemut-ws16-amd64 broken
 test-amd64-amd64-xl-qemut-ws16-amd64 4 host-install(4) broken REGR. vs. 122580
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 4 host-install(4) broken REGR. 
vs. 122580
 build-armhf-pvops 6 kernel-build fail REGR. vs. 122580

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122580
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122580
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 122580
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 122580
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122580
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122580
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  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-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-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  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  f78c8322850dbe3dbe9cd828ee00767190529100
baseline version:
 xen  0306a1311d02ea52b4a9a9bc339f8bab9354c5e3

Last test of basis   122580  2018-05-03 12:11:46 Z8 days
Failing since122601  2018-05-04 12:54:03 Z7 days4 attempts
Testing same since   122660  2018-05-08 18:43:00 Z3 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Jan Beulich 
  Juergen Gross 
  Olaf Hering 
  Wei Liu 

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

Re: [Xen-devel] domain_crash_sync vs "plain crash"

[Charles Gonçalves]

@Andrew,

Despite SCHED_OP, that I've blacklisted, which one came to mind?


On Mon, May 7, 2018 at 5:13 AM Andrew Cooper 
wrote:

> On 07/05/2018 08:09, Jan Beulich wrote:
>  On 07.05.18 at 03:06,  wrote:
> >> When I'm performing some hypercalls with some "unexpected" parameters
> >> (robustness test) sometimes the guest is explicitly  "killed" by xen
> >> calling the domain_crash(), but sometimes the guest just crash without
> any
> >> explicit message on dmesg or logs.
> >>
> >> Are those "plain crashes" an expected behavior by design on Xen or are
> they
> >> some untreated parameter checking or something else?
> > A silent crash is never supposed to happen, but you always need to first
> > consider whether the crashing component actually has a way to get
> > something out to wherever you monitor its logs. That is, without
> (physical
> > or virtual, depending on component) serial console you're often unlikely
> to
> > actually observe any messages connected to the crash.
> >
> > If you can track down a _truly_ silent crash to its origin, submitting a
> patch
> > to make it non-silent would be appreciated.
>
> Alternatively, if you are fuzzing the hypercalls, which it sounds like
> you are, then you need to ensure that you blacklist operations such as
> SCHEDOP_shutdown and SCHEDOP_poll to avoid the fuzzer hitting legitimate
> hypercalls which shut down or block for indefinite periods of time.
>
> ~Andrew
>
-- 
Atenciosamente,
Charles F.'. Gonçalves
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] domain_crash_sync vs "plain crash"

[Charles Gonçalves]

"That is, without (physical
or virtual, depending on component) serial console you're often unlikely to
actually observe any messages connected to the crash."

I do not have any experience with serial console interaction on linux.
Can you list some examples for both cases (virtual| physical), I'll glad to
fully report any suspicious problem.

Thanks!

-- 
Atenciosamente,
Charles F.'. Gonçalves
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

[Stefano Stabellini]

On Fri, 11 May 2018, Dario Faggioli wrote:
> On Fri, 2018-05-11 at 14:08 +0100, Julien Grall wrote:
> > The whole idea here is we have only one place taking the decision and
> > we 
> > don't spread BUG_ON()/panic/stop_cpu everywhere. The benefit is
> > having 
> > only one place to fix over multiple one because very likely the
> > decision 
> > is the same everywhere.
> > 
> > I agree that today it will end up to crashing the system because of
> > the 
> > BUG_ON. But that's a separate topic.
> > 
> Yes!!! :-D
> 
> I.e., as I've said countless times, I would think that a series which
> introduces a CPU_STARTING notifier that fails, should also deal with
> adjusting the CPU process accordingly.
> 
> *BUT* if you ARM people are ok with arch/arm/ code that does that,
> perhaps with a comment saying something like:
> 
> "This will cause us to hit the BUG_ON() in notify_cpu_starting(). To
> fix that, we need to properly change the CPU bringup code, which will
> happen in a leter series."
> 
> that would also work, I guess. :-)

Yes, I think that returning error with an in-code comment on top is the
best solution.

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

Re: [Xen-devel] [PATCH 5/7] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

[Sameer Goel]

On 5/9/2018 2:58 AM, Julien Grall wrote:
>
>
> On 09/05/2018 09:30, Manish Jaggi wrote:
>>
>>
>> On 04/19/2018 04:24 PM, Manish Jaggi wrote:
>>> Sorry for top posting,
>>>
>>> is someone working on the comments on this patch?
>>>
>>> -Manish
>>>
>> If no one is working this code anymore, I would like to pick it up and 
>> continue maintaining it.
>> Is it fine with all?
>
> Last time I spoke with Sameer he was planning to resend a series. And I would 
> prefer if he continue to lead the series unless stated otherwise.
I am working on addressing the comments in this patch set. Please expect 
something by end of next week.
>
> Cheers,
>
>>
>> -Regards
>> Manish
>>>
>>> On 03/10/2018 11:23 PM, Manish Jaggi wrote:
 Hi Sameer,


 On 02/09/2018 08:40 AM, Sameer Goel wrote:
> This driver follows an approach similar to smmu driver. The intent here
> is to reuse as much Linux code as possible.
> - Glue code has been introduced to bridge the API calls.
> - Called Linux functions from the Xen IOMMU function calls.
> - Xen modifications are preceded by /*Xen: comment */
> - xen/linux_compat: Add a Linux compat header
>    For porting files directly from Linux it is useful to have a function 
> mapping
>    definitions from Linux to Xen. This file adds common API functions and
>    other defines that are needed for porting arm SMMU drivers.
>
> Signed-off-by: Sameer Goel 
> ---
>   xen/arch/arm/p2m.c    |   1 +
>   xen/drivers/Kconfig   |   2 +
>   xen/drivers/passthrough/arm/Kconfig   |   8 +
>   xen/drivers/passthrough/arm/Makefile  |   1 +
>   xen/drivers/passthrough/arm/smmu-v3.c | 892 
> --
>   xen/include/xen/linux_compat.h    |  84 
>   6 files changed, 959 insertions(+), 29 deletions(-)
>   create mode 100644 xen/drivers/passthrough/arm/Kconfig
>   create mode 100644 xen/include/xen/linux_compat.h
>
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 65e8b9c6ea..fef7605fd6 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1460,6 +1460,7 @@ err:
>   static void __init setup_virt_paging_one(void *data)
>   {
>   unsigned long val = (unsigned long)data;
> +    /* SMMUv3 S2 cfg vtcr reuses the following value */
>   WRITE_SYSREG32(val, VTCR_EL2);
>   isb();
>   }
> diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
> index bc3a54f0ea..612655386d 100644
> --- a/xen/drivers/Kconfig
> +++ b/xen/drivers/Kconfig
> @@ -12,4 +12,6 @@ source "drivers/pci/Kconfig"
>     source "drivers/video/Kconfig"
>   +source "drivers/passthrough/arm/Kconfig"
> +
>   endmenu
> diff --git a/xen/drivers/passthrough/arm/Kconfig 
> b/xen/drivers/passthrough/arm/Kconfig
> new file mode 100644
> index 00..cda899f608
> --- /dev/null
> +++ b/xen/drivers/passthrough/arm/Kconfig
> @@ -0,0 +1,8 @@
> +
> +config ARM_SMMU_v3
> +    bool "ARM SMMUv3 Support"
> +    depends on ARM_64
> +    help
> + Support for implementations of the ARM System MMU architecture
> + version 3.
> +
> diff --git a/xen/drivers/passthrough/arm/Makefile 
> b/xen/drivers/passthrough/arm/Makefile
> index f4cd26e15d..e14732b55c 100644
> --- a/xen/drivers/passthrough/arm/Makefile
> +++ b/xen/drivers/passthrough/arm/Makefile
> @@ -1,2 +1,3 @@
>   obj-y += iommu.o
>   obj-y += smmu.o
> +obj-$(CONFIG_ARM_SMMU_v3) += smmu-v3.o
> diff --git a/xen/drivers/passthrough/arm/smmu-v3.c 
> b/xen/drivers/passthrough/arm/smmu-v3.c
> index e67ba6c40f..f43485fe6e 100644
> --- a/xen/drivers/passthrough/arm/smmu-v3.c
> +++ b/xen/drivers/passthrough/arm/smmu-v3.c
> @@ -18,28 +18,414 @@
>    * Author: Will Deacon 
>    *
>    * This driver is powered by bad coffee and bombay mix.
> + *
> + *
> + * Based on Linux drivers/iommu/arm-smmu-v3.c
> + * => commit 7aa8619a66aea52b145e04cbab4f8d6a4e5f3f3b
> + *
> + * Xen modifications:
> + * Sameer Goel 
> + * Copyright (C) 2017, The Linux Foundation, All rights reserved.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Alias to Xen device tree helpers */
> +#define device_node dt_device_node
> +#define of_phandle_args dt_phandle_args
> +#define of_device_id dt_device_match
> +#define of_match_node dt_match_node
> +#define of_property_read_u32(np, pname, out) 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-credit2  12 guest-start  fail REGR. vs. 122512
 test-amd64-amd64-xl  12 guest-start  fail REGR. vs. 122512
 test-amd64-i386-pair 21 guest-start/debian   fail REGR. vs. 122512
 test-amd64-amd64-xl-multivcpu 20 guest-start/debian.repeat fail REGR. vs. 
122512
 test-amd64-amd64-i386-pvgrub 11 guest-start  fail REGR. vs. 122512
 test-armhf-armhf-xl-xsm  12 guest-start  fail REGR. vs. 122512
 test-amd64-amd64-amd64-pvgrub 20 guest-start.2   fail REGR. vs. 122512
 test-amd64-i386-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR. 
vs. 122512
 test-armhf-armhf-xl-arndale  17 guest-start.2fail REGR. vs. 122512
 test-armhf-armhf-xl-multivcpu 17 guest-start.2   fail REGR. vs. 122512
 test-armhf-armhf-xl-credit2  12 guest-start  fail REGR. vs. 122512
 test-armhf-armhf-libvirt-xsm 12 guest-start  fail REGR. vs. 122512
 test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
122512
 test-armhf-armhf-libvirt16 guest-start/debian.repeat fail REGR. vs. 122512
 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
122512
 test-armhf-armhf-xl-cubietruck 16 guest-start/debian.repeat fail REGR. vs. 
122512
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 18 
guest-start/debianhvm.repeat fail REGR. vs. 122512

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail blocked in 
122512
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122417
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 122472
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 122472
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 122472
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail 
like 122512
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 122512
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122512
 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-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-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-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-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  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-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-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-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 

Re: [Xen-devel] [PATCH] viridian: fix cpuid leaf 0x40000003

[Juergen Gross]

On 11/05/18 18:18, Andrew Cooper wrote:
> On 11/05/18 15:48, Paul Durrant wrote:
>> The response to viridian leaf 3 needs to split a 64-bit mask across EAX and
>> EBX, with the low order 32 bits in EAX and the high order 32 bits in EBX.
>> To facilitate this a union of two uint32_t values and the mask (type
>> HV_PARTITION_PRIVILEGE_MASK) is allocated on stack as follows:
>>
>> union {
>> HV_PARTITION_PRIVILEGE_MASK mask;
>> uint32_t lo, hi;
>> } u;
>>
>> This, of course, is incorrect as both lo and hi will alias the low order
>> 32 bits of the mask.
>>
>> This patch wraps lo and hi in an anonmymous struct to achieve the desired
>> effect.
>>
>> NOTE: Fixing this also stops Windows making the HvGetPartitionId hypercall
>>   which was previously considered erroneous behaviour. Thus the
>>   hypercall handler is also modified to stop squashing the
>>   'unimplemented' warning for this hypercall.
>>
>> Signed-off-by: Paul Durrant 
> 
> Acked-by: Andrew Cooper 
> 
> CC Juergen.  This wants backporting, and taking into 4.11

Release-acked-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH v3 1/2] doc: correct livepatch.markdown syntax

[Andrew Cooper]

On 11/05/18 18:56, Konrad Rzeszutek Wilk wrote:
> On Tue, May 08, 2018 at 11:51:47AM +0100, George Dunlap wrote:
>> On 05/08/2018 07:47 AM, Juergen Gross wrote:
>>> "make -C docs all" fails due to incorrect markdown syntax in
>>> livepatch.markdown. Correct it.
>>>
>>> Signed-off-by: Juergen Gross 
>>> Reviewed-by: Konrad Rzeszutek Wilk 
>> Git complains of trailing whitespace:
>>
>> Importing patch "doc-correct-livepatch-markdown" ... :69:
>> trailing whitespace.
>>
>> :72: trailing whitespace.
>>
>> :98: trailing whitespace.
>>
>> :232: trailing whitespace.
>>
>> :238: trailing whitespace.
> That is on purpose. That is you need those two spaces at the end to force
> it to stay in 'code' mode.

Please see my 3.5 which does a load of cleanup.  I've deleted all
trailing whitespace and the end result renders correctly in HTML and PDF.

~Andrew

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

Re: [Xen-devel] [PATCH v3 1/2] doc: correct livepatch.markdown syntax

[Konrad Rzeszutek Wilk]

On Tue, May 08, 2018 at 11:51:47AM +0100, George Dunlap wrote:
> On 05/08/2018 07:47 AM, Juergen Gross wrote:
> > "make -C docs all" fails due to incorrect markdown syntax in
> > livepatch.markdown. Correct it.
> > 
> > Signed-off-by: Juergen Gross 
> > Reviewed-by: Konrad Rzeszutek Wilk 
> 
> Git complains of trailing whitespace:
> 
> Importing patch "doc-correct-livepatch-markdown" ... :69:
> trailing whitespace.
> 
> :72: trailing whitespace.
> 
> :98: trailing whitespace.
> 
> :232: trailing whitespace.
> 
> :238: trailing whitespace.

That is on purpose. That is you need those two spaces at the end to force
it to stay in 'code' mode.

> 
> Checking patch docs/misc/livepatch.markdown...
> Applied patch docs/misc/livepatch.markdown cleanly.
> warning: squelched 13 whitespace errors
> warning: 18 lines add whitespace errors.
> 
> 
> > ---
> >  docs/misc/livepatch.markdown | 590 
> > ---
> >  1 file changed, 273 insertions(+), 317 deletions(-)
> > 
> > diff --git a/docs/misc/livepatch.markdown b/docs/misc/livepatch.markdown
> > index 54a6b850cb..a4de44472a 100644
> > --- a/docs/misc/livepatch.markdown
> > +++ b/docs/misc/livepatch.markdown
> > @@ -89,33 +89,27 @@ As example we will assume the hypervisor does not have 
> > XSA-132 (see
> >  4ff3449f0e9d175ceb9551d3f2aecb59273f639d) and we would like to binary patch
> >  the hypervisor with it. The original code looks as so:
> >  
> > -
> > -   48 89 e0  mov%rsp,%rax  
> > -   48 25 00 80 ff ff and$0x8000,%rax  
> > -
> > +   48 89 e0  mov%rsp,%rax
> > +   48 25 00 80 ff ff and$0x8000,%rax
> >  
> >  while the new patched hypervisor would be:
> >  
> > -
> > -   48 c7 45 b8 00 00 00 00   movq   $0x0,-0x48(%rbp)  
> > -   48 c7 45 c0 00 00 00 00   movq   $0x0,-0x40(%rbp)  
> > -   48 c7 45 c8 00 00 00 00   movq   $0x0,-0x38(%rbp)  
> > -   48 89 e0  mov%rsp,%rax  
> > -   48 25 00 80 ff ff and$0x8000,%rax  
> > -
> > +   48 c7 45 b8 00 00 00 00   movq   $0x0,-0x48(%rbp)
> > +   48 c7 45 c0 00 00 00 00   movq   $0x0,-0x40(%rbp)
> > +   48 c7 45 c8 00 00 00 00   movq   $0x0,-0x38(%rbp)
> > +   48 89 e0  mov%rsp,%rax
> > +   48 25 00 80 ff ff and$0x8000,%rax
> >  
> > -This is inside the arch_do_domctl. This new change adds 21 extra
> > +This is inside the arch\_do\_domctl. This new change adds 21 extra
> 
> It seems like nearly all of these would be better served by making them
> code blocks ( `arch_do_domctl`). It is:
> * easier to read in text format (one of the  main points of markdown),
> * fewer characters to type,
> * looks better rendered into html or pdf, and
> * doesn't require   tags for < and >.
> 
>  -George

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

[Xen-devel] [PATCH for-4.11 v4 1/1] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

[Lars Kurth]

The tool covers step 2 of the following workflow

  Step 1: git format-patch ... -o  ...
  Step 2: ./scripts/add_maintainers.pl -d 
  This overwrites  *.patch files in 
  Step 3: git send-email -to xen-devel@lists.xenproject.org /*.patchxm

I manually tested all options and the most common combinations
on Mac.

Changes since v1:
- Added RAB (indicated by Juergen on IRC that this is OK)
- Remove trailing whitespaces
- Renamed --prefix to --reroll-count
- Cleaned up short options -v, ... to be in line with git
- Added --tags|-t option to add AB, RAB and RB emails to CC list
- Added --insert|-i mode to allow for people adding CCs to commit message
  instead of the e-mail header (the header is the default)
- Moved common code into functions
- Added logic, such that the tool only insert's To: and Cc: statements
  which were not there before, allowing for running the tool multiple times
  on the same 

Changes since v2:
- Deleted --version and related infrastructure
- Added subroutine prototypes
- Removed AT and @lists declaration and used \@ in literals
- Changed usage message and options based on feedback
- Improved error handling
- Removed occurances of index() and replaced with regex
- Removed non-perl idioms
- Moved uniq statements to normalize and added info on what normalize does
- Read L: tags from MAINTAINERS file instead of using heuristic
- Fixed issues related to metacharacters in getmaintainers()
- Allow multiple -a | --arg values (because of this renamed --args)
- Identify tags via regex
- CC's from tags are only inserted in the mail header, never the body
- That is unless the new option --tagscc is used
- Added policy processing which includes reworking insert()
- Replaced -i|--insert with -p|--inspatch and -c|--inscover now using policies
- Added new policies to cover for all user requests
- Rewrote help message to center around usage of policies
- Reordered some code (e.g. help string first to make code more easily readable)

Changes since v3:
- Made help message clearer
- Replaced PROCESSING POLICY with LOCATION
- Renamed --inspatch (top|ccbody|cc---|none) | -p (top|ccbody|cc---|none)
  to --patchcc (header|commit|comment|none) | -p (header|commit|comment|none)
- Renamed --inscover (top|ccend|none) | -c (top|ccend|none)
  to --covercc (header|end|none) | -c (header|end|none)
- Renamed variables and functions in the code to match the options
- Changed $patch_prefix processing
- Changed search expression for identifying cover letters
- Renamed $readmailinglists to $getmailinglists_done
- Use array form of open
- More file error handling (using IO::Handle)
- Fixed buggy AND in if statement
- Removed check whether getmaintainers exists for future proofing
- Add logic to work out --reroll-count

Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Signed-off-by: Lars Kurth 
Release-acked-by: Juergen Gross 
---
 scripts/add_maintainers.pl | 547 +
 1 file changed, 547 insertions(+)
 create mode 100755 scripts/add_maintainers.pl

diff --git a/scripts/add_maintainers.pl b/scripts/add_maintainers.pl
new file mode 100755
index 00..b4134e9be2
--- /dev/null
+++ b/scripts/add_maintainers.pl
@@ -0,0 +1,547 @@
+#!/usr/bin/perl -w
+# (c) 2018, Lars Kurth 
+#
+# Add maintainers to patches generated with git format-patch
+#
+# Usage: perl scripts/add_maintainers.pl [OPTIONS] -patchdir 
+#
+# Prerequisites: Execute
+#git format-patch ... -o  ...
+#
+#./scripts/get_maintainer.pl is present in the tree
+#
+# Licensed under the terms of the GNU GPL License version 2
+
+use strict;
+
+use Getopt::Long qw(:config no_auto_abbrev);
+use File::Basename;
+use List::MoreUtils qw(uniq);
+use IO::Handle;
+
+sub getmaintainers ($$$);
+sub gettagsfrompatch ($$$;$);
+sub normalize ($$);
+sub insert ();
+sub hastag ($$);
+
+# Tool Variables
+my $tool = $0;
+my $usage = <1: v*.patch
+
+  --patchcc (header|commit|comment|none) | -p (header|commit|comment|none)
+
+Insert CC lines into *.patch files in the specified location.
+When `none` is specified, the *.patch files are not changed.
+See LOCATIONS for a definition of the various locations.
+
+The default is `header`.
+
+  --covercc (header|end|none) | -c (header|end|none)
+
+Insert CC lines into cover letter in the specified location. See
+When `none` is 

Re: [Xen-devel] Draft NVDIMM proposal

[Dan Williams]

[ adding linux-nvdimm ]

Great write up! Some comments below...

On Wed, May 9, 2018 at 10:35 AM, George Dunlap  wrote:
> Dan,
>
> I understand that you're the NVDIMM maintainer for Linux.  I've been
> working with your colleagues to try to sort out an architecture to allow
> NVRAM to be passed to guests under the Xen hypervisor.
>
> If you have time, I'd appreciate it if you could skim through at least
> the first section of the document below ("NVIDMM Overview"), concerning
> NVDIMM devices and Linux, to see if I've made any mistakes.
>
> If you're up for it, additional early feedback on the proposed Xen
> architecture, from a Linux perspective, would be awesome as well.
>
> Thanks,
>  -George
>
> On 05/09/2018 06:29 PM, George Dunlap wrote:
>> Below is an initial draft of an NVDIMM proposal.  I'll submit a patch to
>> include it in the tree at some point, but I thought for initial
>> discussion it would be easier if it were copied in-line.
>>
>> I've done a fair amount of investigation, but it's quite likely I've
>> made mistakes.  Please send me corrections where necessary.
>>
>> -George
>>
>> ---
>> % NVDIMMs and Xen
>> % George Dunlap
>> % Revision 0.1
>>
>> # NVDIMM overview
>>
>> It's very difficult, from the various specs, to actually get a
>> complete enough picture if what's going on to make a good design.
>> This section is meant as an overview of the current hardware,
>> firmware, and Linux interfaces sufficient to inform a discussion of
>> the issues in designing a Xen interface for NVDIMMs.
>>
>> ## DIMMs, Namespaces, and access methods
>>
>> An NVDIMM is a DIMM (_dual in-line memory module_) -- a physical form
>> factor) that contains _non-volatile RAM_ (NVRAM).  Individual bytes of
>> memory on a DIMM are specified by a _DIMM physical address_ or DPA.
>> Each DIMM is attached to an NVDIMM controller.
>>
>> Memory on the DIMMs is divided up into _namespaces_.  The word
>> "namespace" is rather misleading though; a namespace in this context
>> is not actually a space of names (contrast, for example "C++
>> namespaces"); rather, it's more like a SCSI LUN, or a volume, or a
>> partition on a drive: a set of data which is meant to be viewed and
>> accessed as a unit.  (The name was apparently carried over from NVMe
>> devices, which were precursors of the NVDIMM spec.)

Unlike NVMe an NVDIMM itself has no concept of namespaces. Some DIMMs
provide a "label area" which is an out-of-band non-volatile memory
area where the OS can store whatever it likes. The UEFI 2.7
specification defines a data format for the definition of namespaces
on top of persistent memory ranges advertised to the OS via the ACPI
NFIT structure.

There is no obligation for an NVDIMM to provide a label area, and as
far as I know all NVDIMMs on the market today do not provide a label
area. That said, QEMU has the ability to associate a virtual label
area with for its virtual NVDIMM representation.

>> The NVDIMM controller allows two ways to access the DIMM.  One is
>> mapped 1-1 in _system physical address space_ (SPA), much like normal
>> RAM.  This method of access is called _PMEM_.  The other method is
>> similar to that of a PCI device: you have a control and status
>> register which control an 8k aperture window into the DIMM.  This
>> method access is called _PBLK_.
>>
>> In the case of PMEM, as in the case of DRAM, addresses from the SPA
>> are interleaved across a set of DIMMs (an _interleave set_) for
>> performance reasons.  A specific PMEM namespace will be a single
>> contiguous DPA range across all DIMMs in its interleave set.  For
>> example, you might have a namespace for DPAs `0-0x5000` on DIMMs 0
>> and 1; and another namespace for DPAs `0x8000-0xa000` on DIMMs
>> 0, 1, 2, and 3.
>>
>> In the case of PBLK, a namespace always resides on a single DIMM.
>> However, that namespace can be made up of multiple discontiguous
>> chunks of space on that DIMM.  For instance, in our example above, we
>> might have a namespace om DIMM 0 consisting of DPAs
>> `0x5000-0x6000`, `0x8000-0x9000`, and
>> `0xa000-0xf000`.
>>
>> The interleaving of PMEM has implications for the speed and
>> reliability of the namespace: Much like RAID 0, it maximizes speed,
>> but it means that if any one DIMM fails, the data from the entire
>> namespace is corrupted.  PBLK makes it slightly less straightforward
>> to access, but it allows OS software to apply RAID-like logic to
>> balance redundancy and speed.
>>
>> Furthermore, PMEM requires one byte of SPA for every byte of NVDIMM;
>> for large systems without 5-level paging, this is actually becoming a
>> limitation.  Using PBLK allows existing 4-level paged systems to
>> access an arbitrary amount of NVDIMM.
>>
>> ## Namespaces, labels, and the label area
>>
>> A namespace is a mapping from the SPA and MMIO space into the DIMM.
>>
>> The firmware and/or operating system can talk to the NVDIMM controller
>> to set up mappings from 

[Xen-devel] [PATCH for-4.11 v4 0/1] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

[Lars Kurth]

This version of this series addresses all comments on the mailing list, as well
as some feedback I got in various personal conversations and/or on IRC. For
the people who asked for specific features/workflows:

Ian Jackson: use ./scripts/add_maintainers.pl -p none [-c header]
Reads CCs from unmodified *.patch files and inserts them into the cover letter

George Dunlap: use ./scripts/add_maintainers.pl -p comment
Tends to add CC blocks after the --- line in *.patches. This option achieves
this behavior

Julien Grall: use ./scripts/add_maintainers.pl -c end
As far as I recall, Julien adds CC blocks into the body of the cover letter.
This option achieves this, but there is no place that always exists other
than before "-- " where the CC block can be insterted.

I made the processing code easily extendable via LOCATION specific functions.
So if there is any missed behavior, the tool can easily be extended.

Also note that git send-email does not automatically add people in *=by:
tags to CC lists (with the exception of Singed-off-by). For this I added
the options -t|--tags and --tagscc.

v2 of this patch contained some cleanup to MAINTAINERS which has been broken
out into a separate series: see
https://lists.xenproject.org/archives/html/xen-devel/2018-05/threads.html#00028

v3 of this patch mainly concerened the user interface.

Lars Kurth (1):
  Add new add_maintainers.pl script to optimise the workflow when using
git format-patch with get_maintainer.pl

 scripts/add_maintainers.pl | 547 +
 1 file changed, 547 insertions(+)
 create mode 100755 scripts/add_maintainers.pl

-- 
2.13.0


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

Re: [Xen-devel] [PATCH] viridian: fix cpuid leaf 0x40000003

[Andrew Cooper]

On 11/05/18 15:48, Paul Durrant wrote:
> The response to viridian leaf 3 needs to split a 64-bit mask across EAX and
> EBX, with the low order 32 bits in EAX and the high order 32 bits in EBX.
> To facilitate this a union of two uint32_t values and the mask (type
> HV_PARTITION_PRIVILEGE_MASK) is allocated on stack as follows:
>
> union {
> HV_PARTITION_PRIVILEGE_MASK mask;
> uint32_t lo, hi;
> } u;
>
> This, of course, is incorrect as both lo and hi will alias the low order
> 32 bits of the mask.
>
> This patch wraps lo and hi in an anonmymous struct to achieve the desired
> effect.
>
> NOTE: Fixing this also stops Windows making the HvGetPartitionId hypercall
>   which was previously considered erroneous behaviour. Thus the
>   hypercall handler is also modified to stop squashing the
>   'unimplemented' warning for this hypercall.
>
> Signed-off-by: Paul Durrant 

Acked-by: Andrew Cooper 

CC Juergen.  This wants backporting, and taking into 4.11

~Andrew

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

Re: [Xen-devel] [PATCH v4 1/2] xen/kbdif: Add string constants for raw pointer

[Juergen Gross]

On 11/05/18 15:38, Konrad Rzeszutek Wilk wrote:
> On Fri, May 11, 2018 at 09:37:57AM -0400, Konrad Rzeszutek Wilk wrote:
>> On Wed, May 02, 2018 at 05:49:18PM +0300, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko 
>>>
>>> Add missing string constants for {feature|request}-raw-pointer
>>> to align with the rest of the interface file.
>>>
>>> Fixes 7868654ff7fe ("kbdif: Define "feature-raw-pointer" and 
>>> "request-raw-pointer")
>>>
>>> Signed-off-by: Oleksandr Andrushchenko 
>>
>>
>> Reviewed-by: Konrad Rzeszutek Wilk 
> 
> Juergen, you OK with an release-ack?

Yes:

Release-acked-by: Juergen Gross 


Juergen

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

[Xen-devel] Xen 4.11 RC4

[Juergen Gross]

Hi all,

Xen 4.11 rc4 is tagged. You can check that out from xen.git:

git://xenbits.xen.org/xen.git 4.11.0-rc4

For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.11.0-rc4/xen-4.11.0-rc4.tar.gz

And the signature is at:
https://downloads.xenproject.org/release/xen/4.11.0-rc4/xen-4.11.0-rc4.tar.gz.sig

Please send bug reports and test reports to xen-devel@lists.xenproject.org.
When sending bug reports, please CC relevant maintainers and me
(jgr...@suse.com).

As a reminder, there will be another Xen Test Day on May 15th.

See instructions on:

https://wiki.xenproject.org/wiki/Xen_4.11_RC_test_instructions


Juergen

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

[Xen-devel] staging-4.6 seems to be broken

[Ian Jackson]

osstest service owner writes ("[xen-4.6-testing test] 122657: regressions - 
FAIL"):
> flight 122657 xen-4.6-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/122657/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-xtf-amd64-amd64-2 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 
> 122461
>  test-amd64-i386-libvirt 18 guest-start/debian.repeat fail REGR. vs. 122461
>  test-amd64-i386-libvirt-xsm 18 guest-start/debian.repeat fail REGR. vs. 
> 122461
>  test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16 
> guest-start/debianhvm.repeat fail REGR. vs. 122461
>  test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10 
> fail REGR. vs. 122461
>  test-amd64-i386-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail 
> REGR. vs. 122461

At least some of these are surely real regressions.

Ian.

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

[Xen-devel] [OSSTEST PATCH] ts-xen-build: run `make build' before `make', by default

[Ian Jackson]

The Xen build system has some quirks.  One of them is that `make' is a
version of `make dist' which is a version of `make install', which
runs `make install' in each subdir - but there are subdirs where `make
install' is a no-op which does not depend on `make build'.  Also,
`make all' does not do `make build'.  Additionally, the default target
differs in the toplevel, compared to subdirectories.  Perhaps this is
all mistaken, but it's not something we can correct in stable
branches.

The result is that we might miss bugs where `make build' fails; and in
particular, bugs where simply `make' may fail in a subdirectory.  Eg,
the recently discovered build failures in the emulator tests, due to
backported changes, which occur with `make -C tools' but not with
`make all' or `make tools'.

Detect these by running `make build' before `make' (unless our caller
has specified some other build arguments).  In the future perhaps we
should do tools and hypervisor builds entirely separately.

Signed-off-by: Ian Jackson 
---
v2: Use `make build' instead of `make all' since the former actually
detects the bug in a buggy unpatched Xen 4.8.  Fix a syntax
error.  Improve the commit message.
---
 ts-xen-build | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/ts-xen-build b/ts-xen-build
index c5d2a1d..4bf2428 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -160,7 +160,13 @@ END
 fi
 END
 
-buildcmd_stamped_logged(9000, 'xen', 'build', '',<

[Xen-devel] [PATCH] viridian: fix cpuid leaf 0x40000003

[Paul Durrant]

The response to viridian leaf 3 needs to split a 64-bit mask across EAX and
EBX, with the low order 32 bits in EAX and the high order 32 bits in EBX.
To facilitate this a union of two uint32_t values and the mask (type
HV_PARTITION_PRIVILEGE_MASK) is allocated on stack as follows:

union {
HV_PARTITION_PRIVILEGE_MASK mask;
uint32_t lo, hi;
} u;

This, of course, is incorrect as both lo and hi will alias the low order
32 bits of the mask.

This patch wraps lo and hi in an anonmymous struct to achieve the desired
effect.

NOTE: Fixing this also stops Windows making the HvGetPartitionId hypercall
  which was previously considered erroneous behaviour. Thus the
  hypercall handler is also modified to stop squashing the
  'unimplemented' warning for this hypercall.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/viridian.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
index d6aa89d..694eae6 100644
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -245,7 +245,7 @@ void cpuid_viridian_leaves(const struct vcpu *v, uint32_t 
leaf,
 };
 union {
 HV_PARTITION_PRIVILEGE_MASK mask;
-uint32_t lo, hi;
+struct { uint32_t lo, hi; };
 } u;
 
 if ( !(viridian_feature_mask(d) & HVMPV_no_freq) )
@@ -964,12 +964,10 @@ int viridian_hypercall(struct cpu_user_regs *regs)
 gprintk(XENLOG_WARNING, "unimplemented hypercall %04x\n",
 input.call_code);
 /* Fallthrough. */
-case HvGetPartitionId:
 case HvExtCallQueryCapabilities:
 /*
- * These hypercalls seem to be erroneously issued by Windows
- * despite neither AccessPartitionId nor EnableExtendedHypercalls
- * being set in CPUID leaf 2.
+ * This hypercall seems to be erroneously issued by Windows
+ * despite EnableExtendedHypercalls not being set in CPUID leaf 2.
  * Given that return a status of 'invalid code' has not so far
  * caused any problems it's not worth logging.
  */
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 01/10] x86/spec_ctrl: Read MSR_ARCH_CAPABILITIES only once

[Konrad Rzeszutek Wilk]

On Fri, May 11, 2018 at 11:38:05AM +0100, Andrew Cooper wrote:
> Make it available from the beginning of init_speculation_mitigations(), and
> pass it into appropriate functions.  Fix an RSBA typo while moving the
> affected comment.
> 
> Signed-off-by: Andrew Cooper 
Reviewed-by: Konrad Rzeszutek Wilk 

Thank you!
> ---
> CC: Jan Beulich 
> CC: Wei Liu 
> CC: Roger Pau Monné 
> CC: Juergen Gross 
> ---
>  xen/arch/x86/spec_ctrl.c | 34 ++
>  1 file changed, 14 insertions(+), 20 deletions(-)
> 
> diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
> index 037e84d..4ab0f50 100644
> --- a/xen/arch/x86/spec_ctrl.c
> +++ b/xen/arch/x86/spec_ctrl.c
> @@ -97,18 +97,15 @@ static int __init parse_bti(const char *s)
>  }
>  custom_param("bti", parse_bti);
>  
> -static void __init print_details(enum ind_thunk thunk)
> +static void __init print_details(enum ind_thunk thunk, uint64_t caps)
>  {
>  unsigned int _7d0 = 0, e8b = 0, tmp;
> -uint64_t caps = 0;
>  
>  /* Collect diagnostics about available mitigations. */
>  if ( boot_cpu_data.cpuid_level >= 7 )
>  cpuid_count(7, 0, , , , &_7d0);
>  if ( boot_cpu_data.extended_cpuid_level >= 0x8008 )
>  cpuid(0x8008, , , , );
> -if ( _7d0 & cpufeat_mask(X86_FEATURE_ARCH_CAPS) )
> -rdmsrl(MSR_ARCH_CAPABILITIES, caps);
>  
>  printk(XENLOG_DEBUG "Speculative mitigation facilities:\n");
>  
> @@ -142,7 +139,7 @@ static void __init print_details(enum ind_thunk thunk)
>  }
>  
>  /* Calculate whether Retpoline is known-safe on this CPU. */
> -static bool __init retpoline_safe(void)
> +static bool __init retpoline_safe(uint64_t caps)
>  {
>  unsigned int ucode_rev = this_cpu(ucode_cpu_info).cpu_sig.rev;
>  
> @@ -153,19 +150,12 @@ static bool __init retpoline_safe(void)
>   boot_cpu_data.x86 != 6 )
>  return false;
>  
> -if ( boot_cpu_has(X86_FEATURE_ARCH_CAPS) )
> -{
> -uint64_t caps;
> -
> -rdmsrl(MSR_ARCH_CAPABILITIES, caps);
> -
> -/*
> - * RBSA may be set by a hypervisor to indicate that we may move to a
> - * processor which isn't retpoline-safe.
> - */
> -if ( caps & ARCH_CAPS_RSBA )
> -return false;
> -}
> +/*
> + * RSBA may be set by a hypervisor to indicate that we may move to a
> + * processor which isn't retpoline-safe.
> + */
> +if ( caps & ARCH_CAPS_RSBA )
> +return false;
>  
>  switch ( boot_cpu_data.x86_model )
>  {
> @@ -299,6 +289,10 @@ void __init init_speculation_mitigations(void)
>  {
>  enum ind_thunk thunk = THUNK_DEFAULT;
>  bool ibrs = false;
> +uint64_t caps = 0;
> +
> +if ( boot_cpu_has(X86_FEATURE_ARCH_CAPS) )
> +rdmsrl(MSR_ARCH_CAPABILITIES, caps);
>  
>  /*
>   * Has the user specified any custom BTI mitigations?  If so, follow 
> their
> @@ -327,7 +321,7 @@ void __init init_speculation_mitigations(void)
>   * On Intel hardware, we'd like to use retpoline in preference to
>   * IBRS, but only if it is safe on this hardware.
>   */
> -else if ( retpoline_safe() )
> +else if ( retpoline_safe(caps) )
>  thunk = THUNK_RETPOLINE;
>  else if ( boot_cpu_has(X86_FEATURE_IBRSB) )
>  ibrs = true;
> @@ -418,7 +412,7 @@ void __init init_speculation_mitigations(void)
>  else
>  setup_clear_cpu_cap(X86_FEATURE_NO_XPTI);
>  
> -print_details(thunk);
> +print_details(thunk, caps);
>  }
>  
>  static void __init __maybe_unused build_assertions(void)
> -- 
> 2.1.4
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

[Dario Faggioli]

On Fri, 2018-05-11 at 15:44 +0200, Mirela Simonovic wrote:
> Hi Dario and Julien,
> 
Err... you've dropped the list and everyone else but me. Re-adding...

> Thanks for the feedback to both. 
>
You're welcome. :-) 

> I think we need to roll back here. I
> believe the root cause of this is an attempt to do errata workarounds
> using notifiers.
> But let me try to enumerate all the options I see as possible
> solutions:
> 
> 1) Don't use notifiers to do errata workaround. Do it before
> CPU_STARTING fires, essentially from start_secondary() before calling
> notify_cpu_starting(). But we need to stop the CPU within
> start_secondary() if enabling errata fails. In start_secondary()
> stop_cpu is already done so I don't see why would an additional call
> be a problem.
> 
I'm no expert of ARM's start_secondary(). Indeed it looks like it can
fail already, so what you say seems to make sense, but really, I better
don't comment on this and leave it to ARM people.

> 2) Still try to use notifiers. We have few options here:
> 2.a) Enabling capability must not fail because a notifier at this
> stage should not fail. This would mean that function to which
> 'enable'
> ptr points (defined in struct arm_cpu_capabilities) has to return
> void
> instead of int. This doesn't seem right to me.
>
It's not.

> 2.b) Change scheduler and whatever else is needed (right place to
> refer to escalation of the scope of series :) in order to make
> CPU_STARTING possible to fail. 
>
Nope, this is just as wrong as 2.a.

> I'm not the person to do that since it
> affects way beyond what I suppose to do. Please note here that I'm
> not
> running away from doing the job. I'm just concerned that this will
> compromise the actual work I suppose to do from the funding/time
> perspective.
> 2.c) Return an error and hit BUG_ON. Add comments as Dario proposed.
> I
> need to state here that I probably won't be the one to implement the
> following series that allows CPU_STARTING to fail.
> 
Yes, this is correct, from the point of view of ARM vs common code
interaction.

Whether or not it is ok to leave this pending, is again up to ARM
people, IMO, as it would be ARM that risks panicing, if the notifier
fails.

> Option 1) or 2.c) sounds like a good compromise to me. What do you
> think?
> 
Well, all I can say is that you should stay away from notifiers
priority --especially of the one of cpu_schedule_callback(). As long as
you do that, I won't be on your way. :-D

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

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

Re: [Xen-devel] [PATCH v4 1/2] xen/kbdif: Add string constants for raw pointer

[Konrad Rzeszutek Wilk]

On Fri, May 11, 2018 at 09:37:57AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, May 02, 2018 at 05:49:18PM +0300, Oleksandr Andrushchenko wrote:
> > From: Oleksandr Andrushchenko 
> > 
> > Add missing string constants for {feature|request}-raw-pointer
> > to align with the rest of the interface file.
> > 
> > Fixes 7868654ff7fe ("kbdif: Define "feature-raw-pointer" and 
> > "request-raw-pointer")
> > 
> > Signed-off-by: Oleksandr Andrushchenko 
> 
> 
> Reviewed-by: Konrad Rzeszutek Wilk 

Juergen, you OK with an release-ack?

> 
> Thank you!
> > ---
> >  xen/include/public/io/kbdif.h | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
> > index 3ce54e9a44c1..daf4bc2063c9 100644
> > --- a/xen/include/public/io/kbdif.h
> > +++ b/xen/include/public/io/kbdif.h
> > @@ -178,8 +178,10 @@
> >  #define XENKBD_DRIVER_NAME "vkbd"
> >  
> >  #define XENKBD_FIELD_FEAT_ABS_POINTER  "feature-abs-pointer"
> > +#define XENKBD_FIELD_FEAT_RAW_POINTER  "feature-raw-pointer"
> >  #define XENKBD_FIELD_FEAT_MTOUCH   "feature-multi-touch"
> >  #define XENKBD_FIELD_REQ_ABS_POINTER   "request-abs-pointer"
> > +#define XENKBD_FIELD_REQ_RAW_POINTER   "request-raw-pointer"
> >  #define XENKBD_FIELD_REQ_MTOUCH"request-multi-touch"
> >  #define XENKBD_FIELD_RING_GREF "page-gref"
> >  #define XENKBD_FIELD_EVT_CHANNEL   "event-channel"
> > -- 
> > 2.17.0
> > 

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

Re: [Xen-devel] [PATCH v4 1/2] xen/kbdif: Add string constants for raw pointer

[Konrad Rzeszutek Wilk]

On Wed, May 02, 2018 at 05:49:18PM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
> 
> Add missing string constants for {feature|request}-raw-pointer
> to align with the rest of the interface file.
> 
> Fixes 7868654ff7fe ("kbdif: Define "feature-raw-pointer" and 
> "request-raw-pointer")
> 
> Signed-off-by: Oleksandr Andrushchenko 


Reviewed-by: Konrad Rzeszutek Wilk 

Thank you!
> ---
>  xen/include/public/io/kbdif.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
> index 3ce54e9a44c1..daf4bc2063c9 100644
> --- a/xen/include/public/io/kbdif.h
> +++ b/xen/include/public/io/kbdif.h
> @@ -178,8 +178,10 @@
>  #define XENKBD_DRIVER_NAME "vkbd"
>  
>  #define XENKBD_FIELD_FEAT_ABS_POINTER  "feature-abs-pointer"
> +#define XENKBD_FIELD_FEAT_RAW_POINTER  "feature-raw-pointer"
>  #define XENKBD_FIELD_FEAT_MTOUCH   "feature-multi-touch"
>  #define XENKBD_FIELD_REQ_ABS_POINTER   "request-abs-pointer"
> +#define XENKBD_FIELD_REQ_RAW_POINTER   "request-raw-pointer"
>  #define XENKBD_FIELD_REQ_MTOUCH"request-multi-touch"
>  #define XENKBD_FIELD_RING_GREF "page-gref"
>  #define XENKBD_FIELD_EVT_CHANNEL   "event-channel"
> -- 
> 2.17.0
> 

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

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

[Dario Faggioli]

On Fri, 2018-05-11 at 14:08 +0100, Julien Grall wrote:
> The whole idea here is we have only one place taking the decision and
> we 
> don't spread BUG_ON()/panic/stop_cpu everywhere. The benefit is
> having 
> only one place to fix over multiple one because very likely the
> decision 
> is the same everywhere.
> 
> I agree that today it will end up to crashing the system because of
> the 
> BUG_ON. But that's a separate topic.
> 
Yes!!! :-D

I.e., as I've said countless times, I would think that a series which
introduces a CPU_STARTING notifier that fails, should also deal with
adjusting the CPU process accordingly.

*BUT* if you ARM people are ok with arch/arm/ code that does that,
perhaps with a comment saying something like:

"This will cause us to hit the BUG_ON() in notify_cpu_starting(). To
fix that, we need to properly change the CPU bringup code, which will
happen in a leter series."

that would also work, I guess. :-)

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

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

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

[Dario Faggioli]

On Fri, 2018-05-11 at 11:54 +0100, Julien Grall wrote:
> On 11/05/18 11:41, Mirela Simonovic wrote:
> "We should really avoid to use panic(...) if this is something the 
> system can survive. In that specific case, it would only affect the 
> current CPU. So it would be better to return an error and let the
> caller 
> decide what to do."
> 
> To summarize:
>   1) Notifiers should only report an error and let the upper
> caller (here 
> notify_cpu_starting()) deciding what to do.
>   2) I am OK with the BUG_ON in notify_cpu_starting() for now.
> 
And, in general, I agree with all this.

However (and I think I'm repeating this concept for, what, the 10th
time now?!?! :-P), in this specific case, the reason why none of the
existing CPU_STARTING callbacks report an error, is that the CPU
bringup process is, AFAICT, built around the assumption that once we
reached CPU_STARTING, things can't fail.

For this very reason, whatever new CPU_STARTING callback is introduced,
in this series or everywhere else, _can't_ fail, and _can't_ return any
error.

If we need to have a CPU_STARTING callback that can fail, we need to
change the CPU bringup process accordingly.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

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

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

[Julien Grall]

On 11/05/18 13:20, Mirela Simonovic wrote:

Hi,

On Fri, May 11, 2018 at 2:07 PM, Mirela Simonovic
 wrote:

On Fri, May 11, 2018 at 12:54 PM, Julien Grall  wrote:

On 11/05/18 11:41, Mirela Simonovic wrote:

On Thu, May 10, 2018 at 6:24 PM, Dario Faggioli 
wrote:

On Thu, 2018-05-10 at 17:49 +0200, Mirela Simonovic wrote:

I am going to repeat the content of my answer to your last e-mail:

I was aware about it since the beginning. The whole point of the
conversation was we should avoid to take the decision at the lower level and
let the upper layer decide what to do.

If the system is failing today then that's fine and still fit what I said in
my first e-mail of that thread. For reminder:

"We should really avoid to use panic(...) if this is something the system
can survive. In that specific case, it would only affect the current CPU. So
it would be better to return an error and let the caller decide what to do."

To summarize:
 1) Notifiers should only report an error and let the upper caller
(here notify_cpu_starting()) deciding what to do.
 2) I am OK with the BUG_ON in notify_cpu_starting() for now.


I agree with BUG_ON in notify_cpu_starting().





Let me just clarify consequence of your proposal according to my
understanding. If instead of stopping the CPU when enabling a
capability fails the notifier returns an error, the error will
propagate to notify_cpu_starting() and BUG_ON will crash the system.
The proposal with stop_cpu() in the enable_nonboot_cpu_caps() instead
of panic that is submitted in this patch would stop only the erroneous
CPU. The rest of the system will continue to work and I though that is
what's the goal since we don't want to panic/BUG_ON.
 From that perspective I believe stop_cpu() in
enable_nonboot_cpu_caps() is better compared to returning an error
from the notifier.

You said above "I would be ok having stop_cpu called here" and I did
so (stop_cpu() in enable_nonboot_cpu_caps() instead of panic that
submitted in this patch).


My thoughts have evolved after Dario's discussion. He expressed 
concerned over your fix to make stop_cpu() working.


As you said I will maintain that code and this solution looks very error 
prone. If Stefano is happy with it, then fine.




If you believe my understanding is not correct, if I missed something
or you have another proposal please let me know.



Also, if you just want to convert panic from this patch into print I
don't believe it's a good approach, but I can do that.


I would prefer to see the notifier reporting the error with a warning 
and returning it.


At the notifier level it does not make sense to take the decision to 
stop the CPU or kill the system. This is a decision that should be taken 
at higher level such as in notify_cpu_starting().


The whole idea here is we have only one place taking the decision and we 
don't spread BUG_ON()/panic/stop_cpu everywhere. The benefit is having 
only one place to fix over multiple one because very likely the decision 
is the same everywhere.


I agree that today it will end up to crashing the system because of the 
BUG_ON. But that's a separate topic.


Cheers,




Thanks,
Mirela


Cheers,

--
Julien Grall


--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

[Dario Faggioli]

On Fri, 2018-05-11 at 12:41 +0200, Mirela Simonovic wrote:
> Hi Dario,
> 
Hi,

> On Thu, May 10, 2018 at 6:24 PM, Dario Faggioli 
> wrote:
> > I may very well be missing or misunderstanding something, but I
> > continue to think that the problem here is that CPU_STARTING can't,
> > right now, fail, while you need it to be able to.
> > 
> > If that is the case, giving different priorities to the notifier,
> > is
> > not a solution.
> > 
> Let me try to clarify. The assumption is that the starting CPU can
> fail. Additional requirement set by Julien is that panic or BUG_ON is
> not acceptable. 
>
So, currently, in Xen, CPU bringup can't fail at the CPU_STARTING
phase. This is the point of the BUG_ON().

It is you that need it to change this, and make it possible for CPU
bringup to fail during CPU_STARTING. This is fine, but require changes,
which, IMO, are not limited to removing the BUG_ON() or trading it with
something else.

> There are 2 ways to deal with this scenario:
> 
> 1) Ignore and report the error, and let the erroneous CPU become
> online.
> This cannot be done without changing the logic in either scheduler or
> notify_cpu_starting(), or I least I don't see how would that be done.
> In previous email when I said "escalating this to who knows where" I
> did not refer to error escalation but the escalation of the scope of
> this series.
> 
How can that be an option? If CPU bringup failed, how is it possible to
let it go online?

To me, it's not that "we can't let a CPU for which bringup failed
continue without changing the scheduler or notify_cpu_starting()". It's
rather "we must not a CPU for which bringup faile continue. Period.".

Which is to say, you need to change things (in common code!) in such a
way that CPU bringup can fail during the CPU_STARTING phase.

> 2) Stop the erroneous CPU.
> Taking this approach requires setting the priority for the notifier.
>
No! Stop the CPU if the bringup fails duting the CPU_STARTING phase
does not require setting the priorities of the CPU_STARTING notifier. 

It requires to changing things (in common code) in such a way that CPU
bringup can fail during the CPU_STARTING phase. (Did I say that
already? :-) )

I understand that, if you set the priority, your series work. But that
does not mean that it is a proper solution to the problem. It means
that it is an hack that...well... makes your series work. :-)

> The key point is that notify_cpu_starting() and scheduler do not have
> to be changed. If errata notifier has higher priority than
> scheduler's
> notifier in the case of an error the CPU will not return into
> notify_cpu_starting() and it will never execute BUG_ON because it
> will
> be stopped. The rest of the system will continue to function without
> that CPU.
> 
Right. But now we have and architecture (ARM) for which CPU bringup can
fail at the CPU_STARTING phase. And yet, looking at common code, we see
that the CPU_STARTING notifier has a BUG_ON() if it ever fails. How
would people looking at this in 2 years time from now make sense of
this?

No, I don't think there really is a sensible workaround here. If you
need the CPU_STARTING phase of CPU bringup to be able to fail, you need
to make all the changes required to make that happen properly.

Which does involve changing common code, and which should therefore be
discussed with the other arches and core hypervisor maintainers.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

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

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

[Mirela Simonovic]

Hi,

On Fri, May 11, 2018 at 2:07 PM, Mirela Simonovic
 wrote:
> Hi Julien,
>
> On Fri, May 11, 2018 at 12:54 PM, Julien Grall  wrote:
>>
>>
>> On 11/05/18 11:41, Mirela Simonovic wrote:
>>>
>>> Hi Dario,
>>>
>>> On Thu, May 10, 2018 at 6:24 PM, Dario Faggioli 
>>> wrote:

 On Thu, 2018-05-10 at 17:49 +0200, Mirela Simonovic wrote:
>
> Regardless of the fact that the notifier returns an error or not, I
> believe it would be good and safe to set priority and document that
> priority zero would cause racing issue in the scenario I debugged
> today. I'm pretty sure that this discussion would be forgotten soon
> and it really should be documented in code/comment.
>
 I may very well be missing or misunderstanding something, but I
 continue to think that the problem here is that CPU_STARTING can't,
 right now, fail, while you need it to be able to.

 If that is the case, giving different priorities to the notifier, is
 not a solution.

>>>
>>> Let me try to clarify. The assumption is that the starting CPU can
>>> fail. Additional requirement set by Julien is that panic or BUG_ON is
>>> not acceptable.
>>
>>
>> Please don't twist my word. I never said it was not acceptable to have the
>> BUG_ON in notify_cpu_starting().
>
> I didn't say that either. You referenced notify_cpu_starting() here, not me.
> BTW, if you get the impression that I'm twisting words then we have a
> misunderstanding and your approach is not the best way toward
> clarifying it. Please have that in mind next time, because I do not
> have such an intent and I never will.
>
> I referred to panic/BUG_ON in this scenario regardless of the place
> from which it would be invoked. My understanding from your previous
> answers is that you think the system should not panic/BUG_ON in this
> scenario, because this kind of error the system should be able to
> survive.
>
>>
>> I am going to repeat the content of my answer to your last e-mail:
>>
>> I was aware about it since the beginning. The whole point of the
>> conversation was we should avoid to take the decision at the lower level and
>> let the upper layer decide what to do.
>>
>> If the system is failing today then that's fine and still fit what I said in
>> my first e-mail of that thread. For reminder:
>>
>> "We should really avoid to use panic(...) if this is something the system
>> can survive. In that specific case, it would only affect the current CPU. So
>> it would be better to return an error and let the caller decide what to do."
>>
>> To summarize:
>> 1) Notifiers should only report an error and let the upper caller
>> (here notify_cpu_starting()) deciding what to do.
>> 2) I am OK with the BUG_ON in notify_cpu_starting() for now.
>
> I agree with BUG_ON in notify_cpu_starting().
>
>>
>
> Let me just clarify consequence of your proposal according to my
> understanding. If instead of stopping the CPU when enabling a
> capability fails the notifier returns an error, the error will
> propagate to notify_cpu_starting() and BUG_ON will crash the system.
> The proposal with stop_cpu() in the enable_nonboot_cpu_caps() instead
> of panic that is submitted in this patch would stop only the erroneous
> CPU. The rest of the system will continue to work and I though that is
> what's the goal since we don't want to panic/BUG_ON.
> From that perspective I believe stop_cpu() in
> enable_nonboot_cpu_caps() is better compared to returning an error
> from the notifier.
>
> You said above "I would be ok having stop_cpu called here" and I did
> so (stop_cpu() in enable_nonboot_cpu_caps() instead of panic that
> submitted in this patch).
>
> If you believe my understanding is not correct, if I missed something
> or you have another proposal please let me know.
>

Also, if you just want to convert panic from this patch into print I
don't believe it's a good approach, but I can do that.

> Thanks,
> Mirela
>
>> Cheers,
>>
>> --
>> Julien Grall

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

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

[Mirela Simonovic]

Hi Julien,

On Fri, May 11, 2018 at 12:54 PM, Julien Grall  wrote:
>
>
> On 11/05/18 11:41, Mirela Simonovic wrote:
>>
>> Hi Dario,
>>
>> On Thu, May 10, 2018 at 6:24 PM, Dario Faggioli 
>> wrote:
>>>
>>> On Thu, 2018-05-10 at 17:49 +0200, Mirela Simonovic wrote:

 Regardless of the fact that the notifier returns an error or not, I
 believe it would be good and safe to set priority and document that
 priority zero would cause racing issue in the scenario I debugged
 today. I'm pretty sure that this discussion would be forgotten soon
 and it really should be documented in code/comment.

>>> I may very well be missing or misunderstanding something, but I
>>> continue to think that the problem here is that CPU_STARTING can't,
>>> right now, fail, while you need it to be able to.
>>>
>>> If that is the case, giving different priorities to the notifier, is
>>> not a solution.
>>>
>>
>> Let me try to clarify. The assumption is that the starting CPU can
>> fail. Additional requirement set by Julien is that panic or BUG_ON is
>> not acceptable.
>
>
> Please don't twist my word. I never said it was not acceptable to have the
> BUG_ON in notify_cpu_starting().

I didn't say that either. You referenced notify_cpu_starting() here, not me.
BTW, if you get the impression that I'm twisting words then we have a
misunderstanding and your approach is not the best way toward
clarifying it. Please have that in mind next time, because I do not
have such an intent and I never will.

I referred to panic/BUG_ON in this scenario regardless of the place
from which it would be invoked. My understanding from your previous
answers is that you think the system should not panic/BUG_ON in this
scenario, because this kind of error the system should be able to
survive.

>
> I am going to repeat the content of my answer to your last e-mail:
>
> I was aware about it since the beginning. The whole point of the
> conversation was we should avoid to take the decision at the lower level and
> let the upper layer decide what to do.
>
> If the system is failing today then that's fine and still fit what I said in
> my first e-mail of that thread. For reminder:
>
> "We should really avoid to use panic(...) if this is something the system
> can survive. In that specific case, it would only affect the current CPU. So
> it would be better to return an error and let the caller decide what to do."
>
> To summarize:
> 1) Notifiers should only report an error and let the upper caller
> (here notify_cpu_starting()) deciding what to do.
> 2) I am OK with the BUG_ON in notify_cpu_starting() for now.

I agree with BUG_ON in notify_cpu_starting().

>

Let me just clarify consequence of your proposal according to my
understanding. If instead of stopping the CPU when enabling a
capability fails the notifier returns an error, the error will
propagate to notify_cpu_starting() and BUG_ON will crash the system.
The proposal with stop_cpu() in the enable_nonboot_cpu_caps() instead
of panic that is submitted in this patch would stop only the erroneous
CPU. The rest of the system will continue to work and I though that is
what's the goal since we don't want to panic/BUG_ON.
From that perspective I believe stop_cpu() in
enable_nonboot_cpu_caps() is better compared to returning an error
from the notifier.

You said above "I would be ok having stop_cpu called here" and I did
so (stop_cpu() in enable_nonboot_cpu_caps() instead of panic that
submitted in this patch).

If you believe my understanding is not correct, if I missed something
or you have another proposal please let me know.

Thanks,
Mirela

> Cheers,
>
> --
> Julien Grall

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

[Xen-devel] [PATCH v1 1/2] x86/mm: Add mem access rights to NPT

[Alexandru Isaila]

From: Isaila Alexandru 

This patch adds access rights for the NPT pages. The access rights are
saved in bits 59:56 of pte that are manipulated through p2m_set_access()
and p2m_get_access() functions.
The patch follows the ept logic.

Note: It was tested with xen-access write

Signed-off-by: Alexandru Isaila 
---
 xen/arch/x86/mm/mem_access.c  |  4 +-
 xen/arch/x86/mm/p2m-pt.c  | 85 ---
 xen/include/asm-x86/mem_access.h  |  2 +-
 xen/include/asm-x86/x86_64/page.h |  9 +
 4 files changed, 84 insertions(+), 16 deletions(-)

diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
index c0cd017..6fb7809 100644
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -221,7 +221,9 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
 {
 req->u.mem_access.flags |= MEM_ACCESS_GLA_VALID;
 req->u.mem_access.gla = gla;
-
+}
+if ( npfec.gla_valid || cpu_has_svm )
+{
 if ( npfec.kind == npfec_kind_with_gla )
 req->u.mem_access.flags |= MEM_ACCESS_FAULT_WITH_GLA;
 else if ( npfec.kind == npfec_kind_in_gpt )
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index b8c5d2e..28e6718 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -68,7 +68,8 @@
 static unsigned long p2m_type_to_flags(const struct p2m_domain *p2m,
p2m_type_t t,
mfn_t mfn,
-   unsigned int level)
+   unsigned int level,
+   p2m_access_t access)
 {
 unsigned long flags;
 /*
@@ -87,23 +88,28 @@ static unsigned long p2m_type_to_flags(const struct 
p2m_domain *p2m,
 case p2m_ram_paged:
 case p2m_ram_paging_in:
 default:
-return flags | _PAGE_NX_BIT;
+flags |= _PAGE_NX_BIT;
+break;
 case p2m_grant_map_ro:
-return flags | P2M_BASE_FLAGS | _PAGE_NX_BIT;
+flags |= P2M_BASE_FLAGS | _PAGE_NX_BIT;
+break;
 case p2m_ioreq_server:
 flags |= P2M_BASE_FLAGS | _PAGE_RW | _PAGE_NX_BIT;
 if ( p2m->ioreq.flags & XEN_DMOP_IOREQ_MEM_ACCESS_WRITE )
-return flags & ~_PAGE_RW;
-return flags;
+flags &= ~_PAGE_RW;
+break;
 case p2m_ram_ro:
 case p2m_ram_logdirty:
 case p2m_ram_shared:
-return flags | P2M_BASE_FLAGS;
+flags |= P2M_BASE_FLAGS;
+break;
 case p2m_ram_rw:
-return flags | P2M_BASE_FLAGS | _PAGE_RW;
+flags |= P2M_BASE_FLAGS | _PAGE_RW;
+break;
 case p2m_grant_map_rw:
 case p2m_map_foreign:
-return flags | P2M_BASE_FLAGS | _PAGE_RW | _PAGE_NX_BIT;
+flags |= P2M_BASE_FLAGS | _PAGE_RW | _PAGE_NX_BIT;
+break;
 case p2m_mmio_direct:
 if ( !rangeset_contains_singleton(mmio_ro_ranges, mfn_x(mfn)) )
 flags |= _PAGE_RW;
@@ -112,8 +118,38 @@ static unsigned long p2m_type_to_flags(const struct 
p2m_domain *p2m,
 flags |= _PAGE_PWT;
 ASSERT(!level);
 }
-return flags | P2M_BASE_FLAGS | _PAGE_PCD;
+flags |= P2M_BASE_FLAGS | _PAGE_PCD;
+break;
 }
+
+switch (access)
+{
+case p2m_access_r:
+case p2m_access_w:
+flags |= _PAGE_NX_BIT;
+flags &= ~_PAGE_RW;
+break;
+case p2m_access_rw:
+flags |= _PAGE_NX_BIT;
+break;
+case p2m_access_n:
+case p2m_access_n2rwx:
+flags |= _PAGE_NX_BIT;
+flags &= ~_PAGE_RW;
+break;
+case p2m_access_rx:
+case p2m_access_wx:
+case p2m_access_rx2rw:
+flags &= ~(_PAGE_NX_BIT | _PAGE_RW);
+break;
+case p2m_access_x:
+flags &= ~_PAGE_RW;
+break;
+case p2m_access_rwx:
+default:
+break;
+}
+return flags;
 }
 
 
@@ -174,6 +210,17 @@ static void p2m_add_iommu_flags(l1_pgentry_t *p2m_entry,
 l1e_add_flags(*p2m_entry, iommu_nlevel_to_flags(nlevel, flags));
 }
 
+void p2m_set_access(intpte_t *entry, p2m_access_t access)
+{
+*entry = (*entry & ~PAGE_ACCESS_BITFIELD_MASK) |
+((access & PAGE_ACCESS_MASK) << PAGE_ACCESS_START);
+}
+
+p2m_access_t p2m_get_access(intpte_t entry)
+{
+return (p2m_access_t)((entry >> PAGE_ACCESS_START) & PAGE_ACCESS_MASK);
+}
+
 /* Returns: 0 for success, -errno for failure */
 static int
 p2m_next_level(struct p2m_domain *p2m, void **table,
@@ -201,6 +248,7 @@ p2m_next_level(struct p2m_domain *p2m, void **table,
 new_entry = l1e_from_mfn(mfn, P2M_BASE_FLAGS | _PAGE_RW);
 
 p2m_add_iommu_flags(_entry, level, 
IOMMUF_readable|IOMMUF_writable);
+p2m_set_access(_entry.l1, 

[Xen-devel] [PATCH v1 2/2] hvm/svm: Enable EMUL_UNIMPLEMENTED events on svm

[Alexandru Isaila]

Signed-off-by: Alexandru Isaila 
---
 xen/include/asm-x86/monitor.h | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index c5a86d1..7ef2aa2 100644
--- a/xen/include/asm-x86/monitor.h
+++ b/xen/include/asm-x86/monitor.h
@@ -83,16 +83,13 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
domain *d)
 (1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT) |
 (1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
 (1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
-(1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG));
+(1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
+(1U << XEN_DOMCTL_MONITOR_EVENT_EMUL_UNIMPLEMENTED));
 
-if ( cpu_has_vmx )
-{
-capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_EMUL_UNIMPLEMENTED);
 
-/* Since we know this is on VMX, we can just call the hvm func */
-if ( hvm_is_singlestep_supported() )
-capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP);
-}
+ /* Check if we are on VMX and then we can just call the hvm func */
+if ( cpu_has_vmx && hvm_is_singlestep_supported() )
+capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP);
 
 if ( hvm_funcs.set_descriptor_access_exiting )
 capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_DESC_ACCESS);
-- 
2.7.4


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

[Xen-devel] [PATCH 10/10] x86/spec_ctrl: Elide MSR_SPEC_CTRL handling in idle context when possible

[Andrew Cooper]

If Xen is virtualising MSR_SPEC_CTRL handling for guests, but using 0 as its
own MSR_SPEC_CTRL value, spec_ctrl_{enter,exit}_idle() need not write to the
MSR.

Requested-by: Jan Beulich 
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Juergen Gross 
---
 xen/arch/x86/spec_ctrl.c  | 4 
 xen/include/asm-x86/cpufeatures.h | 1 +
 xen/include/asm-x86/spec_ctrl.h   | 8 ++--
 3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index a2328bd..f4a3165 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -526,6 +526,10 @@ void __init init_speculation_mitigations(void)
 /* (Re)init BSP state now that default_spec_ctrl_flags has been 
calculated. */
 init_shadow_spec_ctrl_state();
 
+/* If Xen is using any MSR_SPEC_CTRL settings, adjust the idle path. */
+if ( default_xen_spec_ctrl )
+setup_force_cpu_cap(X86_FEATURE_SC_MSR_IDLE);
+
 xpti_init_default(false);
 if ( opt_xpti == 0 )
 setup_force_cpu_cap(X86_FEATURE_NO_XPTI);
diff --git a/xen/include/asm-x86/cpufeatures.h 
b/xen/include/asm-x86/cpufeatures.h
index 9d5d81e..b90aa2d 100644
--- a/xen/include/asm-x86/cpufeatures.h
+++ b/xen/include/asm-x86/cpufeatures.h
@@ -31,3 +31,4 @@ XEN_CPUFEATURE(SC_MSR_HVM,  (FSCAPINTS+0)*32+17) /* 
MSR_SPEC_CTRL used by Xe
 XEN_CPUFEATURE(SC_RSB_PV,   (FSCAPINTS+0)*32+18) /* RSB overwrite needed 
for PV */
 XEN_CPUFEATURE(SC_RSB_HVM,  (FSCAPINTS+0)*32+19) /* RSB overwrite needed 
for HVM */
 XEN_CPUFEATURE(NO_XPTI, (FSCAPINTS+0)*32+20) /* XPTI mitigation not in 
use */
+XEN_CPUFEATURE(SC_MSR_IDLE, (FSCAPINTS+0)*32+21) /* (SC_MSR_PV || 
SC_MSR_HVM) && default_xen_spec_ctrl */
diff --git a/xen/include/asm-x86/spec_ctrl.h b/xen/include/asm-x86/spec_ctrl.h
index bb4e7b2..993b958 100644
--- a/xen/include/asm-x86/spec_ctrl.h
+++ b/xen/include/asm-x86/spec_ctrl.h
@@ -58,9 +58,7 @@ static always_inline void spec_ctrl_enter_idle(struct 
cpu_info *info)
 barrier();
 info->spec_ctrl_flags |= SCF_use_shadow;
 barrier();
-asm volatile ( ALTERNATIVE_2(ASM_NOP3,
- "wrmsr", X86_FEATURE_SC_MSR_PV,
- "wrmsr", X86_FEATURE_SC_MSR_HVM)
+asm volatile ( ALTERNATIVE(ASM_NOP3, "wrmsr", X86_FEATURE_SC_MSR_IDLE)
:: "a" (val), "c" (MSR_SPEC_CTRL), "d" (0) : "memory" );
 }
 
@@ -75,9 +73,7 @@ static always_inline void spec_ctrl_exit_idle(struct cpu_info 
*info)
  */
 info->spec_ctrl_flags &= ~SCF_use_shadow;
 barrier();
-asm volatile ( ALTERNATIVE_2(ASM_NOP3,
- "wrmsr", X86_FEATURE_SC_MSR_PV,
- "wrmsr", X86_FEATURE_SC_MSR_HVM)
+asm volatile ( ALTERNATIVE(ASM_NOP3, "wrmsr", X86_FEATURE_SC_MSR_IDLE)
:: "a" (val), "c" (MSR_SPEC_CTRL), "d" (0) : "memory" );
 }
 
-- 
2.1.4


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

[Xen-devel] [GIT PULL] xen: fix for 4.17-rc5

[Juergen Gross]

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git 
for-linus-4.17-rc5-tag

xen: fix for 4.17-rc5

It contains one fix for the kernel running as a fully virtualized
guest using PV drivers on old Xen hypervisor versions.


Thanks.

Juergen

 arch/x86/xen/enlighten_hvm.c | 13 +
 1 file changed, 13 insertions(+)

Juergen Gross (1):
  Merge tag 'for-linus-4.17-rc5-tag' of 
gitolite.kernel.org:pub/scm/linux/kernel/git/xen/tip into 
__for-linus-4.17-rc5-tag

van der Linden, Frank (1):
  x86/xen: Reset VCPU0 info pointer after shared_info remap

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

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

[Julien Grall]

On 11/05/18 11:41, Mirela Simonovic wrote:

Hi Dario,

On Thu, May 10, 2018 at 6:24 PM, Dario Faggioli  wrote:

On Thu, 2018-05-10 at 17:49 +0200, Mirela Simonovic wrote:

Regardless of the fact that the notifier returns an error or not, I
believe it would be good and safe to set priority and document that
priority zero would cause racing issue in the scenario I debugged
today. I'm pretty sure that this discussion would be forgotten soon
and it really should be documented in code/comment.


I may very well be missing or misunderstanding something, but I
continue to think that the problem here is that CPU_STARTING can't,
right now, fail, while you need it to be able to.

If that is the case, giving different priorities to the notifier, is
not a solution.



Let me try to clarify. The assumption is that the starting CPU can
fail. Additional requirement set by Julien is that panic or BUG_ON is
not acceptable.


Please don't twist my word. I never said it was not acceptable to have 
the BUG_ON in notify_cpu_starting().


I am going to repeat the content of my answer to your last e-mail:

I was aware about it since the beginning. The whole point of the 
conversation was we should avoid to take the decision at the lower level 
and let the upper layer decide what to do.


If the system is failing today then that's fine and still fit what I 
said in my first e-mail of that thread. For reminder:


"We should really avoid to use panic(...) if this is something the 
system can survive. In that specific case, it would only affect the 
current CPU. So it would be better to return an error and let the caller 
decide what to do."


To summarize:
	1) Notifiers should only report an error and let the upper caller (here 
notify_cpu_starting()) deciding what to do.

2) I am OK with the BUG_ON in notify_cpu_starting() for now.

Cheers,

--
Julien Grall

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

[Xen-devel] [xen-4.6-testing test] 122657: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-2 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 122461
 test-amd64-i386-libvirt 18 guest-start/debian.repeat fail REGR. vs. 122461
 test-amd64-i386-libvirt-xsm 18 guest-start/debian.repeat fail REGR. vs. 122461
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16 
guest-start/debianhvm.repeat fail REGR. vs. 122461
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10 fail 
REGR. vs. 122461
 test-amd64-i386-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail REGR. 
vs. 122461
 test-armhf-armhf-xl  12 guest-start  fail REGR. vs. 122461
 test-armhf-armhf-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 122461
 test-armhf-armhf-libvirt16 guest-start/debian.repeat fail REGR. vs. 122461

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-4  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 122413
 test-xtf-amd64-amd64-1  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 122461
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10 
fail like 122461
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122461
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 122461
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122461
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 122461
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 122461
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122461
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 122461
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 122461
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 122461
 test-xtf-amd64-amd64-1   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-1   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-5   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-2   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-4   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-2   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-5   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-2   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-4   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-3   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-3   52 xtf/test-hvm64-memop-seg fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-3   76 xtf/test-pv32pae-xsa-194 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-xsm  13 migrate-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-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-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-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-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

[Mirela Simonovic]

Hi Dario,

On Thu, May 10, 2018 at 6:24 PM, Dario Faggioli  wrote:
> On Thu, 2018-05-10 at 17:49 +0200, Mirela Simonovic wrote:
>> Regardless of the fact that the notifier returns an error or not, I
>> believe it would be good and safe to set priority and document that
>> priority zero would cause racing issue in the scenario I debugged
>> today. I'm pretty sure that this discussion would be forgotten soon
>> and it really should be documented in code/comment.
>>
> I may very well be missing or misunderstanding something, but I
> continue to think that the problem here is that CPU_STARTING can't,
> right now, fail, while you need it to be able to.
>
> If that is the case, giving different priorities to the notifier, is
> not a solution.
>

Let me try to clarify. The assumption is that the starting CPU can
fail. Additional requirement set by Julien is that panic or BUG_ON is
not acceptable. There are 2 ways to deal with this scenario:

1) Ignore and report the error, and let the erroneous CPU become online.
This cannot be done without changing the logic in either scheduler or
notify_cpu_starting(), or I least I don't see how would that be done.
In previous email when I said "escalating this to who knows where" I
did not refer to error escalation but the escalation of the scope of
this series.

2) Stop the erroneous CPU.
Taking this approach requires setting the priority for the notifier.
The key point is that notify_cpu_starting() and scheduler do not have
to be changed. If errata notifier has higher priority than scheduler's
notifier in the case of an error the CPU will not return into
notify_cpu_starting() and it will never execute BUG_ON because it will
be stopped. The rest of the system will continue to function without
that CPU.

> Regards,
> Dario
> --
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Software Engineer @ SUSE https://www.suse.com/

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

[Xen-devel] [PATCH 07/10] x86/spec_ctrl: Explicitly set Xen's default MSR_SPEC_CTRL value

[Andrew Cooper]

With the impending ability to disable MSR_SPEC_CTRL handling on a
per-guest-type basis, the first exit-from-guest may not have the side effect
of loading Xen's choice of value.  Explicitly set Xen's default during the BSP
and AP boot paths.

For the BSP however, delay setting a non-zero MSR_SPEC_CTRL default until
after dom0 has been constructed when safe to do so.  Oracle report that this
speeds up boots of some hardware by 50s.

Reported-by: Zhenzhong Duan 
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Zhenzhong Duan 
CC: Konrad Rzeszutek Wilk 
CC: Boris Ostrovsky 
CC: Juergen Gross 
---
 xen/arch/x86/setup.c|  7 +++
 xen/arch/x86/smpboot.c  |  8 
 xen/arch/x86/spec_ctrl.c| 28 
 xen/include/asm-x86/spec_ctrl.h |  2 ++
 4 files changed, 45 insertions(+)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 164c42c..a3172ca 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1743,6 +1743,13 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 
 setup_io_bitmap(dom0);
 
+if ( bsp_delay_spec_ctrl )
+{
+get_cpu_info()->spec_ctrl_flags &= ~SCF_use_shadow;
+barrier();
+wrmsrl(MSR_SPEC_CTRL, default_xen_spec_ctrl);
+}
+
 /* Jump to the 1:1 virtual mappings of cpu0_stack. */
 asm volatile ("mov %[stk], %%rsp; jmp %c[fn]" ::
   [stk] "g" (__va(__pa(get_stack_bottom(,
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 86fa410..fd9050e 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -358,6 +358,14 @@ void start_secondary(void *unused)
 else
 microcode_resume_cpu(cpu);
 
+/*
+ * If MSR_SPEC_CTRL is available, apply Xen's default setting and discard
+ * any firmware settings.  Note: MSR_SPEC_CTRL may only become available
+ * after loading microcode.
+ */
+if ( boot_cpu_has(X86_FEATURE_IBRSB) )
+wrmsrl(MSR_SPEC_CTRL, default_xen_spec_ctrl);
+
 if ( xen_guest )
 hypervisor_ap_setup();
 
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 0404962..de8b35f 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -38,6 +38,8 @@ static int8_t __initdata opt_ibrs = -1;
 static bool __initdata opt_rsb_pv = true;
 static bool __initdata opt_rsb_hvm = true;
 bool __read_mostly opt_ibpb = true;
+
+bool __initdata bsp_delay_spec_ctrl;
 uint8_t __read_mostly default_xen_spec_ctrl;
 uint8_t __read_mostly default_spec_ctrl_flags;
 
@@ -417,6 +419,32 @@ void __init init_speculation_mitigations(void)
 setup_clear_cpu_cap(X86_FEATURE_NO_XPTI);
 
 print_details(thunk, caps);
+
+/*
+ * If MSR_SPEC_CTRL is available, apply Xen's default setting and discard
+ * any firmware settings.  For performance reasons on native hardware, we
+ * delay applying non-zero settings until after dom0 has been constructed.
+ */
+if ( boot_cpu_has(X86_FEATURE_IBRSB) )
+{
+bsp_delay_spec_ctrl = !cpu_has_hypervisor && default_xen_spec_ctrl;
+
+/*
+ * If delaying MSR_SPEC_CTRL setup, use the same mechanism as
+ * spec_ctrl_enter_idle(), by using a shadow value of zero.
+ */
+if ( bsp_delay_spec_ctrl )
+{
+struct cpu_info *info = get_cpu_info();
+
+info->shadow_spec_ctrl = 0;
+barrier();
+info->spec_ctrl_flags |= SCF_use_shadow;
+barrier();
+}
+
+wrmsrl(MSR_SPEC_CTRL, bsp_delay_spec_ctrl ? 0 : default_xen_spec_ctrl);
+}
 }
 
 static void __init __maybe_unused build_assertions(void)
diff --git a/xen/include/asm-x86/spec_ctrl.h b/xen/include/asm-x86/spec_ctrl.h
index 9880e19..bb4e7b2 100644
--- a/xen/include/asm-x86/spec_ctrl.h
+++ b/xen/include/asm-x86/spec_ctrl.h
@@ -27,6 +27,8 @@
 void init_speculation_mitigations(void);
 
 extern bool opt_ibpb;
+
+extern bool bsp_delay_spec_ctrl;
 extern uint8_t default_xen_spec_ctrl;
 extern uint8_t default_spec_ctrl_flags;
 
-- 
2.1.4


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

[Xen-devel] [PATCH 09/10] x86/spec_ctrl: Introduce a new `spec-ctrl=` command line argument to replace `bti=`

[Andrew Cooper]

In hindsight, the options for `bti=` aren't as flexible or useful as expected
(including several options which don't appear to behave as intended).
Changing the behaviour of an existing option is problematic for compatibility,
so introduce a new `spec-ctrl=` in the hopes that we can do better.

One common way of deploying Xen is with a single PV dom0 and all domUs being
HVM domains.  In such a setup, an administrator who has weighed up the risks
may wish to forgo protection against malicious PV domains, to reduce the
overall performance hit.  To cater for this usecase, `spec-ctrl=no-pv` will
disable all speculative protection for PV domains, while leaving all
speculative protection for HVM domains intact.

For coding clarity as much as anything else, the suboptions are grouped by
logical area; those which affect the alternatives blocks, and those which
affect Xen's in-hypervisor settings.  See the xen-command-line.markdown for
full details of the new options.

While changing the command line options, take the time to change how the data
is reported to the user.  The three DEBUG printks are upgraded to unilateral,
as they are all relevant pieces of information, and the old "mitigations:"
line is split in the two logical areas described above.

Sample output from booting with `spec-ctrl=no-pv` looks like:

  (XEN) Speculative mitigation facilities:
  (XEN)   Hardware features: IBRS/IBPB STIBP IBPB
  (XEN)   Compiled-in support: INDIRECT_THUNK
  (XEN)   Xen settings: BTI-Thunk RETPOLINE, SPEC_CTRL: IBRS-, Other: IBPB
  (XEN)   Support for VMs: PV: None, HVM: MSR_SPEC_CTRL RSB
  (XEN)   XPTI (64-bit PV only): Dom0 enabled, DomU enabled

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Juergen Gross 
---
 docs/misc/xen-command-line.markdown |  49 +++
 xen/arch/x86/spec_ctrl.c| 164 ++--
 2 files changed, 188 insertions(+), 25 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 5b6571a..b6b1530 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -248,6 +248,9 @@ the NMI watchdog is also enabled.
 ### bti (x86)
 > `= List of [ , thunk=retpoline|lfence|jmp, ibrs=, ibpb=, 
 > rsb=, rsb_{vmexit,native}= ]`
 
+**WARNING: This command line option is deprecated, and superseded by
+_spec-ctrl=_ - using both options in combination is undefined.**
+
 Branch Target Injection controls.  By default, Xen will pick the most
 appropriate BTI mitigations based on compiled in support, loaded microcode,
 and hardware details.
@@ -1752,6 +1755,52 @@ enforces the maximum theoretically necessary timeout of 
670ms. Any number
 is being interpreted as a custom timeout in milliseconds. Zero or boolean
 false disable the quirk workaround, which is also the default.
 
+### spec-ctrl (x86)
+> `= List of [ , xen=, {pv,hvm,msr-sc,rsb}=,
+>  bti-thunk=retpoline|lfence|jmp, {ibrs,ibpb}= ]`
+
+Controls for speculative execution sidechannel mitigations.  By default, Xen
+will pick the most appropriate mitigations based on compiled in support,
+loaded microcode, and hardware details, and will virtualise appropriate
+mitigations for guests to use.
+
+**WARNING: Any use of this option may interfere with heuristics.  Use with
+extreme care.**
+
+An overall boolean value, `spec-ctrl=no`, can be specified to turn off all
+mitigations, including pieces of infrastructure used to virtualise certain
+mitigation features for guests.  Alternatively, a slightly more restricted
+`spec-ctrl=no-xen` can be used to turn off all of Xen's mitigations, while
+leaving the virtualisation support in place for guests to use.  Use of a
+positive boolean value for either of these options is invalid.
+
+The booleans `pv=`, `hvm=`, `msr-sc=` and `rsb=` offer fine grained control
+over the alternative blocks used by Xen.  These impact Xen's ability to
+protect itself, and Xen's ability to virtualise support for guests to use.
+
+* `pv=` and `hvm=` offer control over all suboptions for PV and HVM guests
+  respectively.
+* `msr-sc=` offers control over Xen's support for manipulating MSR\_SPEC\_CTRL
+  on entry and exit.  These blocks are necessary to virtualise support for
+  guests and if disabled, guests will be unable to use IBRS/STIBP/etc.
+* `rsb=` offers control over whether to overwrite the Return Stack Buffer /
+  Return Address Stack on entry to Xen.
+
+If Xen was compiled with INDIRECT\_THUNK support, `bti-thunk=` can be used to
+select which of the thunks gets patched into the `__x86_indirect_thunk_%reg`
+locations.  The default thunk is `retpoline` (generally preferred for Intel
+hardware), with the alternatives being `jmp` (a `jmp *%reg` gadget, minimal
+overhead), and `lfence` (an `lfence; jmp *%reg` gadget, preferred for AMD).
+
+On hardware supporting IBRS 

[Xen-devel] [PATCH 08/10] x86/cpuid: Improvements to guest policies for speculative sidechannel features

[Andrew Cooper]

If Xen isn't virtualising MSR_SPEC_CTRL for guests, IBRSB shouldn't be
advertised.  It is not currently possible to express this via the existing
command line options, but such an ability will be introduced.

Another useful option in some usecases is to offer IBPB without IBRS.  When a
guest kernel is known to be compatible (uses retpoline and knows about the AMD
IBPB feature bit), an administrator with pre-Skylake hardware may wish to hide
IBRS.  This allows the VM to have full protection, without Xen or the VM
needing to touch MSR_SPEC_CTRL, which can reduce the overhead of Spectre
mitigations.

Break the logic common to both PV and HVM CPUID calculations into a common
helper, to avoid duplication.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Juergen Gross 
---
 xen/arch/x86/cpuid.c | 60 
 1 file changed, 37 insertions(+), 23 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index cff1a26..827b6c5 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -368,6 +368,28 @@ static void __init calculate_host_policy(void)
 }
 }
 
+static void __init guest_common_feature_adjustments(uint32_t *fs)
+{
+/* Unconditionally claim to be able to set the hypervisor bit. */
+__set_bit(X86_FEATURE_HYPERVISOR, fs);
+
+/*
+ * If IBRS is offered to the guest, unconditionally offer STIBP.  It is a
+ * nop on non-HT hardware, and has this behaviour to make heterogeneous
+ * setups easier to manage.
+ */
+if ( test_bit(X86_FEATURE_IBRSB, fs) )
+__set_bit(X86_FEATURE_STIBP, fs);
+
+/*
+ * On hardware which supports IBRS/IBPB, we can offer IBPB independently
+ * of IBRS by using the AMD feature bit.  An administrator may wish for
+ * performance reasons to offer IBPB without IBRS.
+ */
+if ( host_cpuid_policy.feat.ibrsb )
+__set_bit(X86_FEATURE_IBPB, fs);
+}
+
 static void __init calculate_pv_max_policy(void)
 {
 struct cpuid_policy *p = _max_cpuid_policy;
@@ -380,18 +402,14 @@ static void __init calculate_pv_max_policy(void)
 for ( i = 0; i < ARRAY_SIZE(pv_featureset); ++i )
 pv_featureset[i] &= pv_featuremask[i];
 
-/* Unconditionally claim to be able to set the hypervisor bit. */
-__set_bit(X86_FEATURE_HYPERVISOR, pv_featureset);
-
-/* On hardware with IBRS/IBPB support, there are further adjustments. */
-if ( test_bit(X86_FEATURE_IBRSB, pv_featureset) )
-{
-/* Offer STIBP unconditionally.  It is a nop on non-HT hardware. */
-__set_bit(X86_FEATURE_STIBP, pv_featureset);
+/*
+ * If Xen isn't virtualising MSR_SPEC_CTRL for PV guests because of
+ * administrator choice, hide the feature.
+ */
+if ( !boot_cpu_has(X86_FEATURE_SC_MSR_PV) )
+__clear_bit(X86_FEATURE_IBRSB, pv_featureset);
 
-/* AMD's IBPB is a subset of IBRS/IBPB. */
-__set_bit(X86_FEATURE_IBPB, pv_featureset);
-}
+guest_common_feature_adjustments(pv_featureset);
 
 sanitise_featureset(pv_featureset);
 cpuid_featureset_to_policy(pv_featureset, p);
@@ -419,9 +437,6 @@ static void __init calculate_hvm_max_policy(void)
 for ( i = 0; i < ARRAY_SIZE(hvm_featureset); ++i )
 hvm_featureset[i] &= hvm_featuremask[i];
 
-/* Unconditionally claim to be able to set the hypervisor bit. */
-__set_bit(X86_FEATURE_HYPERVISOR, hvm_featureset);
-
 /*
  * Xen can provide an APIC emulation to HVM guests even if the host's APIC
  * isn't enabled.
@@ -438,6 +453,13 @@ static void __init calculate_hvm_max_policy(void)
 __set_bit(X86_FEATURE_SEP, hvm_featureset);
 
 /*
+ * If Xen isn't virtualising MSR_SPEC_CTRL for HVM guests because of
+ * administrator choice, hide the feature.
+ */
+if ( !boot_cpu_has(X86_FEATURE_SC_MSR_HVM) )
+__clear_bit(X86_FEATURE_IBRSB, hvm_featureset);
+
+/*
  * With VT-x, some features are only supported by Xen if dedicated
  * hardware support is also available.
  */
@@ -450,15 +472,7 @@ static void __init calculate_hvm_max_policy(void)
 __clear_bit(X86_FEATURE_XSAVES, hvm_featureset);
 }
 
-/* On hardware with IBRS/IBPB support, there are further adjustments. */
-if ( test_bit(X86_FEATURE_IBRSB, hvm_featureset) )
-{
-/* Offer STIBP unconditionally.  It is a nop on non-HT hardware. */
-__set_bit(X86_FEATURE_STIBP, hvm_featureset);
-
-/* AMD's IBPB is a subset of IBRS/IBPB. */
-__set_bit(X86_FEATURE_IBPB, hvm_featureset);
-}
+guest_common_feature_adjustments(hvm_featureset);
 
 sanitise_featureset(hvm_featureset);
 cpuid_featureset_to_policy(hvm_featureset, p);
-- 
2.1.4


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

[Xen-devel] [PATCH 02/10] x86/spec_ctrl: Express Xen's choice of MSR_SPEC_CTRL value as a variable

[Andrew Cooper]

At the moment, we have two different encodings of Xen's MSR_SPEC_CTRL value,
which is a side effect of how the Spectre series developed.  One encoding is
via an alias with the bottom bit of bti_ist_info, and can encode IBRS or not,
but not other configuraitons such as STIBP.

Break Xen's value out into a separate variable (in the top of stack block for
XPTI reasons) and use this instead of bti_ist_info in the IST path.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Juergen Gross 
---
 xen/arch/x86/spec_ctrl.c| 8 +---
 xen/arch/x86/x86_64/asm-offsets.c   | 1 +
 xen/include/asm-x86/current.h   | 1 +
 xen/include/asm-x86/spec_ctrl.h | 2 ++
 xen/include/asm-x86/spec_ctrl_asm.h | 8 ++--
 5 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 4ab0f50..6633c64 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -38,6 +38,7 @@ static int8_t __initdata opt_ibrs = -1;
 static bool __initdata opt_rsb_native = true;
 static bool __initdata opt_rsb_vmexit = true;
 bool __read_mostly opt_ibpb = true;
+uint8_t __read_mostly default_xen_spec_ctrl;
 uint8_t __read_mostly default_bti_ist_info;
 
 static int __init parse_bti(const char *s)
@@ -366,11 +367,14 @@ void __init init_speculation_mitigations(void)
  * guests.
  */
 if ( ibrs )
+{
+default_xen_spec_ctrl |= SPEC_CTRL_IBRS;
 setup_force_cpu_cap(X86_FEATURE_XEN_IBRS_SET);
+}
 else
 setup_force_cpu_cap(X86_FEATURE_XEN_IBRS_CLEAR);
 
-default_bti_ist_info |= BTI_IST_WRMSR | ibrs;
+default_bti_ist_info |= BTI_IST_WRMSR;
 }
 
 /*
@@ -417,8 +421,6 @@ void __init init_speculation_mitigations(void)
 
 static void __init __maybe_unused build_assertions(void)
 {
-/* The optimised assembly relies on this alias. */
-BUILD_BUG_ON(BTI_IST_IBRS != SPEC_CTRL_IBRS);
 }
 
 /*
diff --git a/xen/arch/x86/x86_64/asm-offsets.c 
b/xen/arch/x86/x86_64/asm-offsets.c
index 06028fe..f80d3b7 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -134,6 +134,7 @@ void __dummy__(void)
 OFFSET(CPUINFO_xen_cr3, struct cpu_info, xen_cr3);
 OFFSET(CPUINFO_pv_cr3, struct cpu_info, pv_cr3);
 OFFSET(CPUINFO_shadow_spec_ctrl, struct cpu_info, shadow_spec_ctrl);
+OFFSET(CPUINFO_xen_spec_ctrl, struct cpu_info, xen_spec_ctrl);
 OFFSET(CPUINFO_use_shadow_spec_ctrl, struct cpu_info, 
use_shadow_spec_ctrl);
 OFFSET(CPUINFO_bti_ist_info, struct cpu_info, bti_ist_info);
 OFFSET(CPUINFO_root_pgt_changed, struct cpu_info, root_pgt_changed);
diff --git a/xen/include/asm-x86/current.h b/xen/include/asm-x86/current.h
index 43bdec1..200e935 100644
--- a/xen/include/asm-x86/current.h
+++ b/xen/include/asm-x86/current.h
@@ -54,6 +54,7 @@ struct cpu_info {
 
 /* See asm-x86/spec_ctrl_asm.h for usage. */
 unsigned int shadow_spec_ctrl;
+uint8_t  xen_spec_ctrl;
 bool use_shadow_spec_ctrl;
 uint8_t  bti_ist_info;
 
diff --git a/xen/include/asm-x86/spec_ctrl.h b/xen/include/asm-x86/spec_ctrl.h
index b4fa432..0c7663a 100644
--- a/xen/include/asm-x86/spec_ctrl.h
+++ b/xen/include/asm-x86/spec_ctrl.h
@@ -27,6 +27,7 @@
 void init_speculation_mitigations(void);
 
 extern bool opt_ibpb;
+extern uint8_t default_xen_spec_ctrl;
 extern uint8_t default_bti_ist_info;
 
 extern uint8_t opt_xpti;
@@ -38,6 +39,7 @@ static inline void init_shadow_spec_ctrl_state(void)
 struct cpu_info *info = get_cpu_info();
 
 info->shadow_spec_ctrl = info->use_shadow_spec_ctrl = 0;
+info->xen_spec_ctrl = default_xen_spec_ctrl;
 info->bti_ist_info = default_bti_ist_info;
 }
 
diff --git a/xen/include/asm-x86/spec_ctrl_asm.h 
b/xen/include/asm-x86/spec_ctrl_asm.h
index 1623fc0..e8e8f9a 100644
--- a/xen/include/asm-x86/spec_ctrl_asm.h
+++ b/xen/include/asm-x86/spec_ctrl_asm.h
@@ -21,7 +21,6 @@
 #define __X86_SPEC_CTRL_ASM_H__
 
 /* Encoding of the bottom bits in cpuinfo.bti_ist_info */
-#define BTI_IST_IBRS  (1 << 0)
 #define BTI_IST_WRMSR (1 << 1)
 #define BTI_IST_RSB   (1 << 2)
 
@@ -283,12 +282,9 @@
 setz %dl
 and %dl, STACK_CPUINFO_FIELD(use_shadow_spec_ctrl)(%r14)
 
-/*
- * Load Xen's intended value.  SPEC_CTRL_IBRS vs 0 is encoded in the
- * bottom bit of bti_ist_info, via a deliberate alias with BTI_IST_IBRS.
- */
+/* Load Xen's intended value. */
 mov $MSR_SPEC_CTRL, %ecx
-and $BTI_IST_IBRS, %eax
+movzbl STACK_CPUINFO_FIELD(xen_spec_ctrl)(%r14), %eax
 xor %edx, %edx
 wrmsr
 
-- 
2.1.4


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

[Xen-devel] [PATCH 01/10] x86/spec_ctrl: Read MSR_ARCH_CAPABILITIES only once

[Andrew Cooper]

Make it available from the beginning of init_speculation_mitigations(), and
pass it into appropriate functions.  Fix an RSBA typo while moving the
affected comment.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Juergen Gross 
---
 xen/arch/x86/spec_ctrl.c | 34 ++
 1 file changed, 14 insertions(+), 20 deletions(-)

diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 037e84d..4ab0f50 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -97,18 +97,15 @@ static int __init parse_bti(const char *s)
 }
 custom_param("bti", parse_bti);
 
-static void __init print_details(enum ind_thunk thunk)
+static void __init print_details(enum ind_thunk thunk, uint64_t caps)
 {
 unsigned int _7d0 = 0, e8b = 0, tmp;
-uint64_t caps = 0;
 
 /* Collect diagnostics about available mitigations. */
 if ( boot_cpu_data.cpuid_level >= 7 )
 cpuid_count(7, 0, , , , &_7d0);
 if ( boot_cpu_data.extended_cpuid_level >= 0x8008 )
 cpuid(0x8008, , , , );
-if ( _7d0 & cpufeat_mask(X86_FEATURE_ARCH_CAPS) )
-rdmsrl(MSR_ARCH_CAPABILITIES, caps);
 
 printk(XENLOG_DEBUG "Speculative mitigation facilities:\n");
 
@@ -142,7 +139,7 @@ static void __init print_details(enum ind_thunk thunk)
 }
 
 /* Calculate whether Retpoline is known-safe on this CPU. */
-static bool __init retpoline_safe(void)
+static bool __init retpoline_safe(uint64_t caps)
 {
 unsigned int ucode_rev = this_cpu(ucode_cpu_info).cpu_sig.rev;
 
@@ -153,19 +150,12 @@ static bool __init retpoline_safe(void)
  boot_cpu_data.x86 != 6 )
 return false;
 
-if ( boot_cpu_has(X86_FEATURE_ARCH_CAPS) )
-{
-uint64_t caps;
-
-rdmsrl(MSR_ARCH_CAPABILITIES, caps);
-
-/*
- * RBSA may be set by a hypervisor to indicate that we may move to a
- * processor which isn't retpoline-safe.
- */
-if ( caps & ARCH_CAPS_RSBA )
-return false;
-}
+/*
+ * RSBA may be set by a hypervisor to indicate that we may move to a
+ * processor which isn't retpoline-safe.
+ */
+if ( caps & ARCH_CAPS_RSBA )
+return false;
 
 switch ( boot_cpu_data.x86_model )
 {
@@ -299,6 +289,10 @@ void __init init_speculation_mitigations(void)
 {
 enum ind_thunk thunk = THUNK_DEFAULT;
 bool ibrs = false;
+uint64_t caps = 0;
+
+if ( boot_cpu_has(X86_FEATURE_ARCH_CAPS) )
+rdmsrl(MSR_ARCH_CAPABILITIES, caps);
 
 /*
  * Has the user specified any custom BTI mitigations?  If so, follow their
@@ -327,7 +321,7 @@ void __init init_speculation_mitigations(void)
  * On Intel hardware, we'd like to use retpoline in preference to
  * IBRS, but only if it is safe on this hardware.
  */
-else if ( retpoline_safe() )
+else if ( retpoline_safe(caps) )
 thunk = THUNK_RETPOLINE;
 else if ( boot_cpu_has(X86_FEATURE_IBRSB) )
 ibrs = true;
@@ -418,7 +412,7 @@ void __init init_speculation_mitigations(void)
 else
 setup_clear_cpu_cap(X86_FEATURE_NO_XPTI);
 
-print_details(thunk);
+print_details(thunk, caps);
 }
 
 static void __init __maybe_unused build_assertions(void)
-- 
2.1.4


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

[Xen-devel] [PATCH 06/10] x86/spec_ctrl: Split X86_FEATURE_SC_MSR into PV and HVM variants

[Andrew Cooper]

In order to separately control whether MSR_SPEC_CTRL is virtualised for PV and
HVM guests, split the feature used to control runtime alternatives into two.
Xen will use MSR_SPEC_CTRL itself if either of these features are active.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Juergen Gross 
---
 xen/arch/x86/spec_ctrl.c|  6 --
 xen/include/asm-x86/cpufeatures.h   |  3 ++-
 xen/include/asm-x86/spec_ctrl.h |  8 ++--
 xen/include/asm-x86/spec_ctrl_asm.h | 12 ++--
 4 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index f489f79..0404962 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -128,7 +128,8 @@ static void __init print_details(enum ind_thunk thunk, 
uint64_t caps)
thunk == THUNK_RETPOLINE ? "RETPOLINE" :
thunk == THUNK_LFENCE? "LFENCE" :
thunk == THUNK_JMP   ? "JMP" : "?",
-   boot_cpu_has(X86_FEATURE_SC_MSR) ?
+   (boot_cpu_has(X86_FEATURE_SC_MSR_PV) ||
+boot_cpu_has(X86_FEATURE_SC_MSR_HVM)) ?
default_xen_spec_ctrl & SPEC_CTRL_IBRS? " IBRS+" :
" IBRS-"  : "",
opt_ibpb  ? " IBPB"   : "",
@@ -367,7 +368,8 @@ void __init init_speculation_mitigations(void)
  * need the IBRS entry/exit logic to virtualise IBRS support for
  * guests.
  */
-setup_force_cpu_cap(X86_FEATURE_SC_MSR);
+setup_force_cpu_cap(X86_FEATURE_SC_MSR_PV);
+setup_force_cpu_cap(X86_FEATURE_SC_MSR_HVM);
 
 if ( ibrs )
 default_xen_spec_ctrl |= SPEC_CTRL_IBRS;
diff --git a/xen/include/asm-x86/cpufeatures.h 
b/xen/include/asm-x86/cpufeatures.h
index f9aa5d7..9d5d81e 100644
--- a/xen/include/asm-x86/cpufeatures.h
+++ b/xen/include/asm-x86/cpufeatures.h
@@ -26,7 +26,8 @@ XEN_CPUFEATURE(LFENCE_DISPATCH, (FSCAPINTS+0)*32+12) /* 
lfence set as Dispatch S
 XEN_CPUFEATURE(IND_THUNK_LFENCE,(FSCAPINTS+0)*32+13) /* Use IND_THUNK_LFENCE */
 XEN_CPUFEATURE(IND_THUNK_JMP,   (FSCAPINTS+0)*32+14) /* Use IND_THUNK_JMP */
 XEN_CPUFEATURE(XEN_IBPB,(FSCAPINTS+0)*32+15) /* IBRSB || IBPB */
-XEN_CPUFEATURE(SC_MSR,  (FSCAPINTS+0)*32+16) /* MSR_SPEC_CTRL used by 
Xen */
+XEN_CPUFEATURE(SC_MSR_PV,   (FSCAPINTS+0)*32+16) /* MSR_SPEC_CTRL used by 
Xen for PV */
+XEN_CPUFEATURE(SC_MSR_HVM,  (FSCAPINTS+0)*32+17) /* MSR_SPEC_CTRL used by 
Xen for HVM */
 XEN_CPUFEATURE(SC_RSB_PV,   (FSCAPINTS+0)*32+18) /* RSB overwrite needed 
for PV */
 XEN_CPUFEATURE(SC_RSB_HVM,  (FSCAPINTS+0)*32+19) /* RSB overwrite needed 
for HVM */
 XEN_CPUFEATURE(NO_XPTI, (FSCAPINTS+0)*32+20) /* XPTI mitigation not in 
use */
diff --git a/xen/include/asm-x86/spec_ctrl.h b/xen/include/asm-x86/spec_ctrl.h
index 86a3dfe..9880e19 100644
--- a/xen/include/asm-x86/spec_ctrl.h
+++ b/xen/include/asm-x86/spec_ctrl.h
@@ -56,7 +56,9 @@ static always_inline void spec_ctrl_enter_idle(struct 
cpu_info *info)
 barrier();
 info->spec_ctrl_flags |= SCF_use_shadow;
 barrier();
-asm volatile ( ALTERNATIVE(ASM_NOP3, "wrmsr", X86_FEATURE_SC_MSR)
+asm volatile ( ALTERNATIVE_2(ASM_NOP3,
+ "wrmsr", X86_FEATURE_SC_MSR_PV,
+ "wrmsr", X86_FEATURE_SC_MSR_HVM)
:: "a" (val), "c" (MSR_SPEC_CTRL), "d" (0) : "memory" );
 }
 
@@ -71,7 +73,9 @@ static always_inline void spec_ctrl_exit_idle(struct cpu_info 
*info)
  */
 info->spec_ctrl_flags &= ~SCF_use_shadow;
 barrier();
-asm volatile ( ALTERNATIVE(ASM_NOP3, "wrmsr", X86_FEATURE_SC_MSR)
+asm volatile ( ALTERNATIVE_2(ASM_NOP3,
+ "wrmsr", X86_FEATURE_SC_MSR_PV,
+ "wrmsr", X86_FEATURE_SC_MSR_HVM)
:: "a" (val), "c" (MSR_SPEC_CTRL), "d" (0) : "memory" );
 }
 
diff --git a/xen/include/asm-x86/spec_ctrl_asm.h 
b/xen/include/asm-x86/spec_ctrl_asm.h
index bf36b5a..edace2a 100644
--- a/xen/include/asm-x86/spec_ctrl_asm.h
+++ b/xen/include/asm-x86/spec_ctrl_asm.h
@@ -223,34 +223,34 @@
 #define SPEC_CTRL_ENTRY_FROM_HVM\
 ALTERNATIVE "", DO_OVERWRITE_RSB, X86_FEATURE_SC_RSB_HVM;   \
 ALTERNATIVE "", DO_SPEC_CTRL_ENTRY_FROM_HVM,\
-X86_FEATURE_SC_MSR
+X86_FEATURE_SC_MSR_HVM
 
 /* Use after an entry from PV context (syscall/sysenter/int80/int82/etc). */
 #define SPEC_CTRL_ENTRY_FROM_PV \
 ALTERNATIVE "", DO_OVERWRITE_RSB, X86_FEATURE_SC_RSB_PV;\
 ALTERNATIVE "", __stringify(DO_SPEC_CTRL_ENTRY maybexen=0), \
-X86_FEATURE_SC_MSR
+X86_FEATURE_SC_MSR_PV
 
 

[Xen-devel] [PATCH for-4.11 00/10] x86: Improvements and fixes to Spectre handling

[Andrew Cooper]

In hindsight, the end result of the Spectre mitigations aren't as great as I'd
hoped, and have several inefficiencies.  Also, the `bti=` command line option
isn't as flexible as intended.

This series does four things:

  1) Some internal cleanup, for clarity and to help the other features
  2) Introduce `spec-ctrl=no-pv` mode.  XenServer's performance measurements
 see a 10% net/disk performance improvement in some production scenarios.
  3) Introduce the ability to use IBPB-only mode for guests.  This was
 discussed by Amazon during the Spectre work, but I don't have any
 performance numbers to hand.
  4) Avoid imposing IBRS mode while dom0 is booting.  This was reported by
 Oracle on the list, and speeds up boot time on some servers by 50s.

I know this series is rather late for 4.11, but seeing as I've managed to
complete it before 4.12 opens, it should be considered at this point, as all
of the Spectre code is new in 4.11.

Andrew Cooper (10):
  x86/spec_ctrl: Read MSR_ARCH_CAPABILITIES only once
  x86/spec_ctrl: Express Xen's choice of MSR_SPEC_CTRL value as a variable
  x86/spec_ctrl: Merge bti_ist_info and use_shadow_spec_ctrl into 
spec_ctrl_flags
  x86/spec_ctrl: Fold the XEN_IBRS_{SET,CLEAR} ALTERNATIVES together
  x86/spec_ctrl: Rename bits of infrastructure to avoid NATIVE and VMEXIT
  x86/spec_ctrl: Split X86_FEATURE_SC_MSR into PV and HVM variants
  x86/spec_ctrl: Explicitly set Xen's default MSR_SPEC_CTRL value
  x86/cpuid: Improvements to guest policies for speculative sidechannel features
  x86/spec_ctrl: Introduce a new `spec-ctrl=` command line argument to replace 
`bti=`
  x86/spec_ctrl: Elide MSR_SPEC_CTRL handling in idle context when possible

 docs/misc/xen-command-line.markdown |  49 +++
 xen/arch/x86/acpi/power.c   |   4 +-
 xen/arch/x86/cpuid.c|  60 +
 xen/arch/x86/hvm/svm/entry.S|   4 +-
 xen/arch/x86/hvm/vmx/entry.S|   4 +-
 xen/arch/x86/setup.c|   7 +
 xen/arch/x86/smpboot.c  |   8 ++
 xen/arch/x86/spec_ctrl.c| 258 
 xen/arch/x86/x86_64/asm-offsets.c   |   4 +-
 xen/arch/x86/x86_64/compat/entry.S  |   2 +-
 xen/arch/x86/x86_64/entry.S |   2 +-
 xen/include/asm-x86/cpufeatures.h   |   9 +-
 xen/include/asm-x86/current.h   |   4 +-
 xen/include/asm-x86/spec_ctrl.h |  20 +--
 xen/include/asm-x86/spec_ctrl_asm.h | 131 +-
 15 files changed, 396 insertions(+), 170 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH 04/10] x86/spec_ctrl: Fold the XEN_IBRS_{SET, CLEAR} ALTERNATIVES together

[Andrew Cooper]

Currently, the SPEC_CTRL_{ENTRY,EXIT}_* macros encode Xen's choice of
MSR_SPEC_CTRL as an immediate constant, and chooses between IBRS or not by
doubling up the entire alternative block.

There is now a variable holding Xen's choice of value, so use that and
simplify the alternatives.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Juergen Gross 
---
 xen/arch/x86/spec_ctrl.c| 12 +-
 xen/include/asm-x86/cpufeatures.h   |  3 +--
 xen/include/asm-x86/spec_ctrl.h |  6 ++---
 xen/include/asm-x86/spec_ctrl_asm.h | 45 +
 4 files changed, 24 insertions(+), 42 deletions(-)

diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 1ad3ff5..13e426c 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -128,8 +128,9 @@ static void __init print_details(enum ind_thunk thunk, 
uint64_t caps)
thunk == THUNK_RETPOLINE ? "RETPOLINE" :
thunk == THUNK_LFENCE? "LFENCE" :
thunk == THUNK_JMP   ? "JMP" : "?",
-   boot_cpu_has(X86_FEATURE_XEN_IBRS_SET)? " IBRS+" :
-   boot_cpu_has(X86_FEATURE_XEN_IBRS_CLEAR)  ? " IBRS-"  : "",
+   boot_cpu_has(X86_FEATURE_SC_MSR) ?
+   default_xen_spec_ctrl & SPEC_CTRL_IBRS? " IBRS+" :
+   " IBRS-"  : "",
opt_ibpb  ? " IBPB"   : "",
boot_cpu_has(X86_FEATURE_RSB_NATIVE)  ? " RSB_NATIVE" : "",
boot_cpu_has(X86_FEATURE_RSB_VMEXIT)  ? " RSB_VMEXIT" : "");
@@ -366,13 +367,10 @@ void __init init_speculation_mitigations(void)
  * need the IBRS entry/exit logic to virtualise IBRS support for
  * guests.
  */
+setup_force_cpu_cap(X86_FEATURE_SC_MSR);
+
 if ( ibrs )
-{
 default_xen_spec_ctrl |= SPEC_CTRL_IBRS;
-setup_force_cpu_cap(X86_FEATURE_XEN_IBRS_SET);
-}
-else
-setup_force_cpu_cap(X86_FEATURE_XEN_IBRS_CLEAR);
 
 default_spec_ctrl_flags |= SCF_ist_wrmsr;
 }
diff --git a/xen/include/asm-x86/cpufeatures.h 
b/xen/include/asm-x86/cpufeatures.h
index c9b1a48..ca58b0e 100644
--- a/xen/include/asm-x86/cpufeatures.h
+++ b/xen/include/asm-x86/cpufeatures.h
@@ -26,8 +26,7 @@ XEN_CPUFEATURE(LFENCE_DISPATCH, (FSCAPINTS+0)*32+12) /* 
lfence set as Dispatch S
 XEN_CPUFEATURE(IND_THUNK_LFENCE,(FSCAPINTS+0)*32+13) /* Use IND_THUNK_LFENCE */
 XEN_CPUFEATURE(IND_THUNK_JMP,   (FSCAPINTS+0)*32+14) /* Use IND_THUNK_JMP */
 XEN_CPUFEATURE(XEN_IBPB,(FSCAPINTS+0)*32+15) /* IBRSB || IBPB */
-XEN_CPUFEATURE(XEN_IBRS_SET,(FSCAPINTS+0)*32+16) /* IBRSB && IRBS set in 
Xen */
-XEN_CPUFEATURE(XEN_IBRS_CLEAR,  (FSCAPINTS+0)*32+17) /* IBRSB && IBRS clear in 
Xen */
+XEN_CPUFEATURE(SC_MSR,  (FSCAPINTS+0)*32+16) /* MSR_SPEC_CTRL used by 
Xen */
 XEN_CPUFEATURE(RSB_NATIVE,  (FSCAPINTS+0)*32+18) /* RSB overwrite needed 
for native */
 XEN_CPUFEATURE(RSB_VMEXIT,  (FSCAPINTS+0)*32+19) /* RSB overwrite needed 
for vmexit */
 XEN_CPUFEATURE(NO_XPTI, (FSCAPINTS+0)*32+20) /* XPTI mitigation not in 
use */
diff --git a/xen/include/asm-x86/spec_ctrl.h b/xen/include/asm-x86/spec_ctrl.h
index d5bd4df..86a3dfe 100644
--- a/xen/include/asm-x86/spec_ctrl.h
+++ b/xen/include/asm-x86/spec_ctrl.h
@@ -56,14 +56,14 @@ static always_inline void spec_ctrl_enter_idle(struct 
cpu_info *info)
 barrier();
 info->spec_ctrl_flags |= SCF_use_shadow;
 barrier();
-asm volatile ( ALTERNATIVE(ASM_NOP3, "wrmsr", X86_FEATURE_XEN_IBRS_SET)
+asm volatile ( ALTERNATIVE(ASM_NOP3, "wrmsr", X86_FEATURE_SC_MSR)
:: "a" (val), "c" (MSR_SPEC_CTRL), "d" (0) : "memory" );
 }
 
 /* WARNING! `ret`, `call *`, `jmp *` not safe before this call. */
 static always_inline void spec_ctrl_exit_idle(struct cpu_info *info)
 {
-uint32_t val = SPEC_CTRL_IBRS;
+uint32_t val = info->xen_spec_ctrl;
 
 /*
  * Disable shadowing before updating the MSR.  There are no SMP issues
@@ -71,7 +71,7 @@ static always_inline void spec_ctrl_exit_idle(struct cpu_info 
*info)
  */
 info->spec_ctrl_flags &= ~SCF_use_shadow;
 barrier();
-asm volatile ( ALTERNATIVE(ASM_NOP3, "wrmsr", X86_FEATURE_XEN_IBRS_SET)
+asm volatile ( ALTERNATIVE(ASM_NOP3, "wrmsr", X86_FEATURE_SC_MSR)
:: "a" (val), "c" (MSR_SPEC_CTRL), "d" (0) : "memory" );
 }
 
diff --git a/xen/include/asm-x86/spec_ctrl_asm.h 
b/xen/include/asm-x86/spec_ctrl_asm.h
index 97da08b..730c998 100644
--- a/xen/include/asm-x86/spec_ctrl_asm.h
+++ b/xen/include/asm-x86/spec_ctrl_asm.h
@@ -117,7 +117,7 @@
 mov %\tmp, %rsp /* Restore old %rsp */
 .endm
 
-.macro DO_SPEC_CTRL_ENTRY_FROM_VMEXIT ibrs_val:req
+.macro DO_SPEC_CTRL_ENTRY_FROM_VMEXIT
 /*
  * 

[Xen-devel] [PATCH 05/10] x86/spec_ctrl: Rename bits of infrastructure to avoid NATIVE and VMEXIT

[Andrew Cooper]

In hindsight, using NATIVE and VMEXIT as naming terminology was not clever.
A future change wants to split SPEC_CTRL_EXIT_TO_GUEST into PV and HVM
specific implementations, and using VMEXIT as a term is completely wrong.

Take the opportunity to fix some stale documentation in spec_ctrl_asm.h.  The
IST helpers were missing from the large comment block, and since
SPEC_CTRL_ENTRY_FROM_INTR_IST was introduced, we've gained a new piece of
functionality which currently depends on the fine grain control, which exists
in lieu of livepatching.  Note this in the comment.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Juergen Gross 
---
 xen/arch/x86/hvm/svm/entry.S|  4 ++--
 xen/arch/x86/hvm/vmx/entry.S|  4 ++--
 xen/arch/x86/spec_ctrl.c| 28 ++--
 xen/arch/x86/x86_64/compat/entry.S  |  2 +-
 xen/arch/x86/x86_64/entry.S |  2 +-
 xen/include/asm-x86/cpufeatures.h   |  4 ++--
 xen/include/asm-x86/spec_ctrl_asm.h | 36 +---
 7 files changed, 47 insertions(+), 33 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/entry.S b/xen/arch/x86/hvm/svm/entry.S
index 0fa5501..2d540f9 100644
--- a/xen/arch/x86/hvm/svm/entry.S
+++ b/xen/arch/x86/hvm/svm/entry.S
@@ -68,7 +68,7 @@ __UNLIKELY_END(nsvm_hap)
 mov VCPUMSR_spec_ctrl_raw(%rax), %eax
 
 /* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */
-SPEC_CTRL_EXIT_TO_GUEST /* Req: a=spec_ctrl %rsp=regs/cpuinfo, Clob: 
cd */
+SPEC_CTRL_EXIT_TO_HVM   /* Req: a=spec_ctrl %rsp=regs/cpuinfo, Clob: 
cd */
 
 pop  %r15
 pop  %r14
@@ -93,7 +93,7 @@ __UNLIKELY_END(nsvm_hap)
 
 GET_CURRENT(bx)
 
-SPEC_CTRL_ENTRY_FROM_VMEXIT /* Req: b=curr %rsp=regs/cpuinfo, Clob: 
acd */
+SPEC_CTRL_ENTRY_FROM_HVM/* Req: b=curr %rsp=regs/cpuinfo, Clob: 
acd */
 /* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */
 
 STGI
diff --git a/xen/arch/x86/hvm/vmx/entry.S b/xen/arch/x86/hvm/vmx/entry.S
index e750544..aa2f103 100644
--- a/xen/arch/x86/hvm/vmx/entry.S
+++ b/xen/arch/x86/hvm/vmx/entry.S
@@ -38,7 +38,7 @@ ENTRY(vmx_asm_vmexit_handler)
 movb $1,VCPU_vmx_launched(%rbx)
 mov  %rax,VCPU_hvm_guest_cr2(%rbx)
 
-SPEC_CTRL_ENTRY_FROM_VMEXIT /* Req: b=curr %rsp=regs/cpuinfo, Clob: 
acd */
+SPEC_CTRL_ENTRY_FROM_HVM/* Req: b=curr %rsp=regs/cpuinfo, Clob: 
acd */
 /* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */
 
 mov  %rsp,%rdi
@@ -76,7 +76,7 @@ UNLIKELY_END(realmode)
 mov VCPUMSR_spec_ctrl_raw(%rax), %eax
 
 /* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */
-SPEC_CTRL_EXIT_TO_GUEST /* Req: a=spec_ctrl %rsp=regs/cpuinfo, Clob: 
cd */
+SPEC_CTRL_EXIT_TO_HVM   /* Req: a=spec_ctrl %rsp=regs/cpuinfo, Clob: 
cd */
 
 mov  VCPU_hvm_guest_cr2(%rbx),%rax
 
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 13e426c..f489f79 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -35,8 +35,8 @@ static enum ind_thunk {
 THUNK_JMP,
 } opt_thunk __initdata = THUNK_DEFAULT;
 static int8_t __initdata opt_ibrs = -1;
-static bool __initdata opt_rsb_native = true;
-static bool __initdata opt_rsb_vmexit = true;
+static bool __initdata opt_rsb_pv = true;
+static bool __initdata opt_rsb_hvm = true;
 bool __read_mostly opt_ibpb = true;
 uint8_t __read_mostly default_xen_spec_ctrl;
 uint8_t __read_mostly default_spec_ctrl_flags;
@@ -57,8 +57,8 @@ static int __init parse_bti(const char *s)
 opt_thunk = THUNK_JMP;
 opt_ibrs = 0;
 opt_ibpb = false;
-opt_rsb_native = false;
-opt_rsb_vmexit = false;
+opt_rsb_pv = false;
+opt_rsb_hvm = false;
 }
 else if ( val > 0 )
 rc = -EINVAL;
@@ -80,13 +80,13 @@ static int __init parse_bti(const char *s)
 else if ( (val = parse_boolean("ibpb", s, ss)) >= 0 )
 opt_ibpb = val;
 else if ( (val = parse_boolean("rsb_native", s, ss)) >= 0 )
-opt_rsb_native = val;
+opt_rsb_pv = val;
 else if ( (val = parse_boolean("rsb_vmexit", s, ss)) >= 0 )
-opt_rsb_vmexit = val;
+opt_rsb_hvm = val;
 else if ( (val = parse_boolean("rsb", s, ss)) >= 0 )
 {
-opt_rsb_native = val;
-opt_rsb_vmexit = val;
+opt_rsb_pv = val;
+opt_rsb_hvm = val;
 }
 else
 rc = -EINVAL;
@@ -132,8 +132,8 @@ static void __init print_details(enum ind_thunk thunk, 
uint64_t caps)
default_xen_spec_ctrl & SPEC_CTRL_IBRS? " IBRS+" :
" IBRS-"  : "",

[Xen-devel] [PATCH 03/10] x86/spec_ctrl: Merge bti_ist_info and use_shadow_spec_ctrl into spec_ctrl_flags

[Andrew Cooper]

All 3 bits of information here are control flags for the entry/exit code
behaviour.  Treat them as such, rather than having two different variables.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Juergen Gross 
---
 xen/arch/x86/acpi/power.c   |  4 ++--
 xen/arch/x86/spec_ctrl.c| 10 
 xen/arch/x86/x86_64/asm-offsets.c   |  3 +--
 xen/include/asm-x86/current.h   |  3 +--
 xen/include/asm-x86/spec_ctrl.h | 10 
 xen/include/asm-x86/spec_ctrl_asm.h | 46 -
 6 files changed, 40 insertions(+), 36 deletions(-)

diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index bb0d095..a704c7c 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -215,7 +215,7 @@ static int enter_state(u32 state)
 ci = get_cpu_info();
 spec_ctrl_enter_idle(ci);
 /* Avoid NMI/#MC using MSR_SPEC_CTRL until we've reloaded microcode. */
-ci->bti_ist_info = 0;
+ci->spec_ctrl_flags &= ~SCF_ist_wrmsr;
 
 ACPI_FLUSH_CPU_CACHE();
 
@@ -259,7 +259,7 @@ static int enter_state(u32 state)
 panic("Missing previously available feature(s).");
 
 /* Re-enabled default NMI/#MC use of MSR_SPEC_CTRL. */
-ci->bti_ist_info = default_bti_ist_info;
+ci->spec_ctrl_flags |= (default_spec_ctrl_flags & SCF_ist_wrmsr);
 spec_ctrl_exit_idle(ci);
 
  done:
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 6633c64..1ad3ff5 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -39,7 +39,7 @@ static bool __initdata opt_rsb_native = true;
 static bool __initdata opt_rsb_vmexit = true;
 bool __read_mostly opt_ibpb = true;
 uint8_t __read_mostly default_xen_spec_ctrl;
-uint8_t __read_mostly default_bti_ist_info;
+uint8_t __read_mostly default_spec_ctrl_flags;
 
 static int __init parse_bti(const char *s)
 {
@@ -374,7 +374,7 @@ void __init init_speculation_mitigations(void)
 else
 setup_force_cpu_cap(X86_FEATURE_XEN_IBRS_CLEAR);
 
-default_bti_ist_info |= BTI_IST_WRMSR;
+default_spec_ctrl_flags |= SCF_ist_wrmsr;
 }
 
 /*
@@ -393,7 +393,7 @@ void __init init_speculation_mitigations(void)
 if ( opt_rsb_native )
 {
 setup_force_cpu_cap(X86_FEATURE_RSB_NATIVE);
-default_bti_ist_info |= BTI_IST_RSB;
+default_spec_ctrl_flags |= SCF_ist_rsb;
 }
 
 /*
@@ -407,7 +407,7 @@ void __init init_speculation_mitigations(void)
 if ( !boot_cpu_has(X86_FEATURE_IBRSB) && !boot_cpu_has(X86_FEATURE_IBPB) )
 opt_ibpb = false;
 
-/* (Re)init BSP state now that default_bti_ist_info has been calculated. */
+/* (Re)init BSP state now that default_spec_ctrl_flags has been 
calculated. */
 init_shadow_spec_ctrl_state();
 
 xpti_init_default(false);
@@ -421,6 +421,8 @@ void __init init_speculation_mitigations(void)
 
 static void __init __maybe_unused build_assertions(void)
 {
+/* The optimised assembly relies on this alias. */
+BUILD_BUG_ON(SCF_use_shadow != 1);
 }
 
 /*
diff --git a/xen/arch/x86/x86_64/asm-offsets.c 
b/xen/arch/x86/x86_64/asm-offsets.c
index f80d3b7..5957c76 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -135,8 +135,7 @@ void __dummy__(void)
 OFFSET(CPUINFO_pv_cr3, struct cpu_info, pv_cr3);
 OFFSET(CPUINFO_shadow_spec_ctrl, struct cpu_info, shadow_spec_ctrl);
 OFFSET(CPUINFO_xen_spec_ctrl, struct cpu_info, xen_spec_ctrl);
-OFFSET(CPUINFO_use_shadow_spec_ctrl, struct cpu_info, 
use_shadow_spec_ctrl);
-OFFSET(CPUINFO_bti_ist_info, struct cpu_info, bti_ist_info);
+OFFSET(CPUINFO_spec_ctrl_flags, struct cpu_info, spec_ctrl_flags);
 OFFSET(CPUINFO_root_pgt_changed, struct cpu_info, root_pgt_changed);
 OFFSET(CPUINFO_use_pv_cr3, struct cpu_info, use_pv_cr3);
 DEFINE(CPUINFO_sizeof, sizeof(struct cpu_info));
diff --git a/xen/include/asm-x86/current.h b/xen/include/asm-x86/current.h
index 200e935..5bd64b2 100644
--- a/xen/include/asm-x86/current.h
+++ b/xen/include/asm-x86/current.h
@@ -55,8 +55,7 @@ struct cpu_info {
 /* See asm-x86/spec_ctrl_asm.h for usage. */
 unsigned int shadow_spec_ctrl;
 uint8_t  xen_spec_ctrl;
-bool use_shadow_spec_ctrl;
-uint8_t  bti_ist_info;
+uint8_t  spec_ctrl_flags;
 
 /*
  * The following field controls copying of the L4 page table of 64-bit
diff --git a/xen/include/asm-x86/spec_ctrl.h b/xen/include/asm-x86/spec_ctrl.h
index 0c7663a..d5bd4df 100644
--- a/xen/include/asm-x86/spec_ctrl.h
+++ b/xen/include/asm-x86/spec_ctrl.h
@@ -28,7 +28,7 @@ void init_speculation_mitigations(void);
 
 extern bool opt_ibpb;
 extern uint8_t default_xen_spec_ctrl;
-extern uint8_t default_bti_ist_info;
+extern uint8_t default_spec_ctrl_flags;
 
 extern uint8_t opt_xpti;
 #define OPT_XPTI_DOM0  

[Xen-devel] Xen Security Advisory 262 (CVE-2018-10981) - qemu may drive Xen into unbounded loop

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2018-10981 / XSA-262
  version 3

qemu may drive Xen into unbounded loop

UPDATES IN VERSION 3


CVE assigned.

ISSUE DESCRIPTION
=

When Xen sends requests to a device model, the next expected action
inside Xen is tracked using a state field.  The requests themselves
are placed in a memory page shared with the device model, so that the
device model can communicate to Xen its progress on the request.  The
state field is in the request itself, where the device model may write
to it.  Xen correctly rejects invalid state values, but failed to reject
invalid transitions between states.  As a result, a device model which
switches a request between two states at the right times can drive Xen
into an unbounded loop.

IMPACT
==

A malicious unprivileged device model can cause a Denial of Service
(DoS) affecting the entire host.  Specifically, it may prevent use of a
physical CPU for an indeterminate period of time.

VULNERABLE SYSTEMS
==

All Xen versions are vulnerable.

Only x86 systems are affected.  ARM systems are not affected.

Only HVM guests can expose this vulnerability.  PV and PVH guests cannot
expose this vulnerability, but note that the domains being able to
leverage the vulnerability are PV or PVH ones, running the device model.

This vulnerability is only applicable to Xen systems using stub domains.

MITIGATION
==

Running only PV or PVH guests will avoid this issue.

(The security of a Xen system using stub domains is still better than
with a qemu-dm running as an unrestricted dom0 process.  Therefore
users with these configurations should not switch to an unrestricted
dom0 qemu-dm.)

CREDITS
===

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa262.patch   xen-unstable
xsa262-4.10.patch  Xen 4.10.x
xsa262-4.9.patch   Xen 4.9.x, Xen 4.8.x, Xen 4.7.x
xsa262-4.6.patch   Xen 4.6.x

$ sha256sum xsa262*
a5a3458c5efdad282bd769fcab2b94ebfe0a979befae3b4703201fcbf0970cc7  xsa262.meta
5aa73753d3eec8ae391b1364c430df7517bf4bdb3e65a8e6e8431898348f4ad9  xsa262.patch
7196b468b916bf956f8dc0cab20a5c29f8a1bfa4de4e4fa982b7b9c8494e4c0d  
xsa262-4.6.patch
ec2b6ba9ed1d5e97fed4b54767160a75fe19d67e4519f716739bebdb78816191  
xsa262-4.9.patch
91d3b329131b6d434b268c0c55fd4900033fce8b2582bd9278ae967efc980fb0  
xsa262-4.10.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJa9Wy3AAoJEIP+FMlX6CvZh44IAK64kxWtVcMGLiTWU7NgsXub
Y2+Hku8lXyVwqQ5smkIVPjG0AanXpgbB/c6uhtf53l8F2YjauEt/nG0QBkvLExmw
DmusWb0Utmn4wIjBtBBv6holEHAxYZxL9qKrux2rnJXY8Yxf9hFsOWQsgx4RxsUR
TAf9MVjzOWV5P7t1pvLfEA41cUQNWCML+Kog+bBptGvvuZ2AO5jS9qBmUAMCSQRH
WUD4uZKI5xLtbYTDftqRqi6baEo4TIL6MrUHd8DAW7qR11gaRupDXG4w4W1mX9LM
GMLrJJkk7U5jZ1as1WfJza2YA0zKaVJtScYdjYb/+g4XwbHrxAbqWOUOLAf9YrE=
=ASkj
-END PGP SIGNATURE-


xsa262.meta
Description: Binary data


xsa262.patch
Description: Binary data


xsa262-4.6.patch
Description: Binary data


xsa262-4.9.patch
Description: Binary data


xsa262-4.10.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Xen Security Advisory 261 (CVE-2018-10982) - x86 vHPET interrupt injection errors

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2018-10982 / XSA-261
  version 3

 x86 vHPET interrupt injection errors

UPDATES IN VERSION 3


CVE assigned.

ISSUE DESCRIPTION
=

The High Precision Event Timer (HPET) can be configured to deliver
interrupts in one of three different modes - through legacy interrupts;
through the IO-APIC; or optionally via a method similar to PCI MSI.  The
last mode is optional and not implemented by Xen.  However, of the first
two modes, only the legacy variant was properly implemented.

If a guest set up an HPET timer in IO-APIC mode, Xen would still
handle this using the code for the legacy mode.  Unfortunately, the
available IO-APIC mode interrupt numbers are higher than legacy mode
interrupts.  The result was array overruns.

IMPACT
==

A malicious or buggy HVM guest may cause a hypervisor crash, resulting
in a Denial of Service (DoS) affecting the entire host.  Privilege
escalation, or information leaks, cannot be excluded.

VULNERABLE SYSTEMS
==

Xen versions 3.4 and later are vulnerable.

Only x86 systems are vulnerable.  ARM systems are not vulnerable.

Only x86 HVM guests can exploit the vulnerability.  x86 PV and PVH
guests cannot exploit the vulnerability.

Only x86 HVM guests provided with hypervisor-side HPET emulation can
exploit the vulnerability.  That is the default configuration.  x86
HVM guests whose configuration explicitly disables this emulation (via
"hpet=0") cannot exploit the vulnerability.

MITIGATION
==

Running only PV or PVH guests avoids the vulnerability.

Not exposing the hypervisor based HPET emulation to HVM guests, by
adding "hpet=0" to the guest configuration, also avoids the
vulnerability.

CREDITS
===

This issue was discovered by Roger Pau Monné of Citrix.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa261.patch   xen-unstable, Xen 4.10.x
xsa261-4.9.patch   Xen 4.9.x
xsa261-4.8.patch   Xen 4.8.x
xsa261-4.7.patch   Xen 4.7.x, Xen 4.6.x

$ sha256sum xsa261*
7b7bbf0fb497491911816e522902f72d3b41355ba71455ab82ebf980160d1a1f  xsa261.meta
175501977204db84d08a6fd81d9fd4b69f97f70cbf6f65e6ce0abfeab03eae95  xsa261.patch
98fb28bac871aae7c2f897a5506a2b03f340bf122a3a7f65aa65f3b3c9a525b4  
xsa261-4.7.patch
503f1476813e6572dc37b5a0df65b5390567230d9cc006752bf72bf57bbd754d  
xsa261-4.8.patch
f1aac841327d3b5b1e2007b4ebe56223de488e1eb2fa636653725d7d7cd5f82a  
xsa261-4.9.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches described above (or others which are
substantially similar) and the PV/PVH guest mitigation are permitted
during the embargo, even on public-facing systems with untrusted guest
users and administrators.

HOWEVER deployment of the "hpet=0" guest config mitigation described
above is NOT permitted (except where all the affected systems and VMs
are administered and used only by organisations which are members of
the Xen Project Security Issues Predisclosure List).  Specifically,
deployment on public cloud systems is NOT permitted.

This is because in that case the configuration change is visible to the
guest, which could lead to the rediscovery of the vulnerability.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJa9Wy1AAoJEIP+FMlX6CvZaxkIALwHLRw4JlORTplsS9bwnioh
kuNausNp1pU9IqfcUKEI17n5+HekiXfLNennHEWYgYfdpNlWAbjUW5GaczII0KmS
IJa8UvptnYydhg73Q8WWlYOx3i8nS15+ioIH8RIa1Vtvv0p7vbHf8C9BmjmYf1oa
5WH9Ut4Sx5wwALuCh/gO71ja5vgAAIpgQTf5R4KL0x9sJiCLTw2A4yxVmVd24bES
1fNoH3/qdbjgMjl7sLPCdsXLOqg9Xi77i5f5XnJMZgWQRQyh0XLeo5itiDIuMF/k
tEMuEpKQ5+t4GNg92B67dFVWxeX1VIRrQ9a18WfXcwttM3xLFNcqt3BpSV9K8Tg=
=KeNf
-END PGP SIGNATURE-


xsa261.meta
Description: Binary data


xsa261.patch
Description: Binary data


xsa261-4.7.patch
Description: Binary data


xsa261-4.8.patch
Description: Binary data


xsa261-4.9.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-credit2  12 guest-start  fail REGR. vs. 118324
 test-armhf-armhf-xl-arndale  12 guest-start  fail REGR. vs. 118324
 test-amd64-i386-libvirt  19 guest-start.2fail REGR. vs. 118324
 test-amd64-amd64-xl-multivcpu 20 guest-start/debian.repeat fail REGR. vs. 
118324
 test-amd64-amd64-xl-qemut-debianhvm-amd64 21 leak-check/check fail REGR. vs. 
118324
 test-armhf-armhf-libvirt 12 guest-start  fail REGR. vs. 118324
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 118324
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 18 
guest-start/debianhvm.repeat fail REGR. vs. 118324
 test-armhf-armhf-xl-credit2  10 debian-install   fail REGR. vs. 118324
 test-armhf-armhf-xl-multivcpu 10 debian-install  fail REGR. vs. 118324
 test-armhf-armhf-libvirt-xsm 10 debian-install   fail REGR. vs. 118324
 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
118324
 test-armhf-armhf-xl  10 debian-install   fail REGR. vs. 118324
 test-armhf-armhf-xl-xsm  10 debian-install   fail REGR. vs. 118324

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

version targeted for testing:
 linuxf142f08bf7ecc41c3e71e05b765ea654047cf0c0
baseline version:
 linux5b7d27967dabfb17c21b0d98b29153b9e3ee71e5

Last test of basis   118324  2018-01-25 07:31:24 Z  106 days
Failing since118362  2018-01-26 16:56:17 Z  104 days   82 attempts
Testing same since   122647  2018-05-08 10:16:55 Z2 days1 attempts


3439 people touched revisions under test,
not listing them all

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

[Xen-devel] [distros-debian-jessie test] 74707: tolerable FAIL

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail like 
74672

baseline version:
 flight   74672

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-jessie-netboot-pvgrub pass
 test-amd64-i386-i386-jessie-netboot-pvgrub   pass
 test-amd64-i386-amd64-jessie-netboot-pygrub  pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub fail
 test-amd64-amd64-i386-jessie-netboot-pygrub  pass



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH v2 2/3] xen/store: do not store local values in xen_start_info

[Juergen Gross]

On 09/05/18 12:21, Roger Pau Monne wrote:
> There's no need to store the xenstore page or event channel in
> xen_start_info if they are locally initialized.
> 
> This also fixes PVH local xenstore initialization due to the lack of
> xen_start_info in that case.
> 
> Signed-off-by: Boris Ostrovsky 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH v2 1/3] xen/pvh: enable and set default MTRR type

[Juergen Gross]

On 09/05/18 17:11, Roger Pau Monné wrote:
> On Wed, May 09, 2018 at 12:30:16PM +0100, Roger Pau Monné wrote:
>> On Wed, May 09, 2018 at 11:56:40AM +0100, Andrew Cooper wrote:
>>> On 09/05/18 11:21, Roger Pau Monne wrote:
>>> I'm not sure that setting the default MTRR type is going to be a
>>> clever idea in hindsight when we come to doing PCI Passthrough support.
>>
>> Setting the default type to WB is also set by hvmloader, it's just
>> that hvmloader also sets some of the fixed and variable ranges to UC
>> in order to cover the iomem areas.
>>
>> The expectations when doing pci-passthrough is that the guest will
>> always use paging and PAT in order to set the appropriate cache
>> attributes, or else the guest itself will have to program the UC MTRR
>> ranges, I admit that's not very nice however.
>>
>> What about enabling the default MTRR type and setting it to WB in the
>> toolstack for PVH? IMO doing it Xen itself would be wrong.
> 
> I have the following patch to set the default MTRR type, but I think
> if we go down this road then we will also have to set UC MTRRs for
> MMIO areas, which again seems fine to me.

I like this route much better.


Juergen

> 
> ---8<---
> diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
> index e33a28847d..3cb1a1720f 100644
> --- a/tools/libxc/xc_dom_x86.c
> +++ b/tools/libxc/xc_dom_x86.c
> @@ -938,6 +938,8 @@ static int vcpu_hvm(struct xc_dom_image *dom)
>  HVM_SAVE_TYPE(HEADER) header;
>  struct hvm_save_descriptor cpu_d;
>  HVM_SAVE_TYPE(CPU) cpu;
> +struct hvm_save_descriptor mtrr_d;
> +HVM_SAVE_TYPE(MTRR) mtrr;
>  struct hvm_save_descriptor end_d;
>  HVM_SAVE_TYPE(END) end;
>  } bsp_ctx;
> @@ -1014,6 +1016,15 @@ static int vcpu_hvm(struct xc_dom_image *dom)
>  if ( dom->start_info_seg.pfn )
>  bsp_ctx.cpu.rbx = dom->start_info_seg.pfn << PAGE_SHIFT;
>  
> +/* Set the MTRR. */
> +bsp_ctx.mtrr_d.typecode = HVM_SAVE_CODE(MTRR);
> +bsp_ctx.mtrr_d.instance = 0;
> +bsp_ctx.mtrr_d.length = HVM_SAVE_LENGTH(MTRR);
> +/* XXX: maybe this should be a firmware option instead? */
> +if ( !dom->device_model )
> +/* Enable MTRR (bit 11) and set the default type to WB (6). */
> +bsp_ctx.mtrr.msr_mtrr_def_type = (1u << 11) | 6;
> +
>  /* Set the end descriptor. */
>  bsp_ctx.end_d.typecode = HVM_SAVE_CODE(END);
>  bsp_ctx.end_d.instance = 0;
> 
> 


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