[PATCH v2 0/2] x86: HW vulnerability mitigation logging improvements

[PATCH v2 0/2] x86: HW vulnerability mitigation logging improvements

[Jan Beulich]

1: x86: report use of PCID together with reporting XPTI status
2: x86/spec-ctrl: split reporting for PV and HVM guests

Jan



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

[PATCH v2 1/2] x86: report use of PCID together with reporting XPTI status

[Jan Beulich]

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Add CONFIG_PV conditional.

--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -288,6 +288,12 @@ int pv_domain_initialise(struct domain *
     return rc;
 }
 
+bool __init xpti_pcid_enabled(void)
+{
+    return use_invpcid && cpu_has_pcid &&
+           (opt_pcid == PCID_ALL || opt_pcid == PCID_XPTI);
+}
+
 static void _toggle_guest_pt(struct vcpu *v)
 {
     const struct domain *d = v->domain;
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -256,9 +256,12 @@ static void __init print_details(enum in
            boot_cpu_has(X86_FEATURE_SC_RSB_HVM)      ? " RSB"           : "",
            opt_eager_fpu                             ? " EAGER_FPU"     : "");
 
-    printk("  XPTI (64-bit PV only): Dom0 %s, DomU %s\n",
+#ifdef CONFIG_PV
+    printk("  XPTI (64-bit PV only): Dom0 %s, DomU %s (with%s PCID)\n",
            opt_xpti & OPT_XPTI_DOM0 ? "enabled" : "disabled",
-           opt_xpti & OPT_XPTI_DOMU ? "enabled" : "disabled");
+           opt_xpti & OPT_XPTI_DOMU ? "enabled" : "disabled",
+           xpti_pcid_enabled() ? "" : "out");
+#endif
 }
 
 /* Calculate whether Retpoline is known-safe on this CPU. */
--- a/xen/include/asm-x86/spec_ctrl.h
+++ b/xen/include/asm-x86/spec_ctrl.h
@@ -38,6 +38,8 @@ extern uint8_t opt_xpti;
 #define OPT_XPTI_DOM0  0x01
 #define OPT_XPTI_DOMU  0x02
 
+bool xpti_pcid_enabled(void);
+
 static inline void init_shadow_spec_ctrl_state(void)
 {
     struct cpu_info *info = get_cpu_info();





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

[PATCH v2 2/2] x86/spec-ctrl: split reporting for PV and HVM guests

[Jan Beulich]

Putting them on separate lines was suggested before, and is going to
become necessary eventually anyway as things get added here. Split them
now, and put the respective pieces in CONFIG_* conditionals at the same
time.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: New.

--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -242,13 +242,8 @@ static void __init print_details(enum in
      * Alternatives blocks for protecting against and/or virtualising
      * mitigation support for guests.
      */
-    printk("  Support for VMs: PV:%s%s%s%s, HVM:%s%s%s%s\n",
-           (boot_cpu_has(X86_FEATURE_SC_MSR_PV) ||
-            boot_cpu_has(X86_FEATURE_SC_RSB_PV) ||
-            opt_eager_fpu)                           ? ""               : " None",
-           boot_cpu_has(X86_FEATURE_SC_MSR_PV)       ? " MSR_SPEC_CTRL" : "",
-           boot_cpu_has(X86_FEATURE_SC_RSB_PV)       ? " RSB"           : "",
-           opt_eager_fpu                             ? " EAGER_FPU"     : "",
+#ifdef CONFIG_HVM
+    printk("  Support for HVM VMs:%s%s%s%s\n",
            (boot_cpu_has(X86_FEATURE_SC_MSR_HVM) ||
             boot_cpu_has(X86_FEATURE_SC_RSB_HVM) ||
             opt_eager_fpu)                           ? ""               : " None",
@@ -256,7 +251,16 @@ static void __init print_details(enum in
            boot_cpu_has(X86_FEATURE_SC_RSB_HVM)      ? " RSB"           : "",
            opt_eager_fpu                             ? " EAGER_FPU"     : "");
 
+#endif
 #ifdef CONFIG_PV
+    printk("  Support for PV VMs:%s%s%s%s\n",
+           (boot_cpu_has(X86_FEATURE_SC_MSR_PV) ||
+            boot_cpu_has(X86_FEATURE_SC_RSB_PV) ||
+            opt_eager_fpu)                           ? ""               : " None",
+           boot_cpu_has(X86_FEATURE_SC_MSR_PV)       ? " MSR_SPEC_CTRL" : "",
+           boot_cpu_has(X86_FEATURE_SC_RSB_PV)       ? " RSB"           : "",
+           opt_eager_fpu                             ? " EAGER_FPU"     : "");
+
     printk("  XPTI (64-bit PV only): Dom0 %s, DomU %s (with%s PCID)\n",
            opt_xpti & OPT_XPTI_DOM0 ? "enabled" : "disabled",
            opt_xpti & OPT_XPTI_DOMU ? "enabled" : "disabled",





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

Re: [PATCH v2 1/2] x86: report use of PCID together with reporting XPTI status

[Andrew Cooper]

On 18/07/2018 09:33, Jan Beulich wrote:
> --- a/xen/include/asm-x86/spec_ctrl.h
> +++ b/xen/include/asm-x86/spec_ctrl.h
> @@ -38,6 +38,8 @@ extern uint8_t opt_xpti;
>  #define OPT_XPTI_DOM0  0x01
>  #define OPT_XPTI_DOMU  0x02
>  
> +bool xpti_pcid_enabled(void);

This still should be inside an CONFIG_PV to avoid scenarios which will
compile correctly but fail to link.  It should live in pv/domain.h at
which point everything should be fine.

With that, Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

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

Re: [PATCH v2 2/2] x86/spec-ctrl: split reporting for PV and HVM guests

[Andrew Cooper]

On 18/07/2018 09:33, Jan Beulich wrote:
> Putting them on separate lines was suggested before, and is going to
> become necessary eventually anyway as things get added here. Split them
> now, and put the respective pieces in CONFIG_* conditionals at the same
> time.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

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

Re: [PATCH v2 1/2] x86: report use of PCID together with reporting XPTI status

[Roger Pau Monné]

On Wed, Jul 18, 2018 at 02:33:02AM -0600, Jan Beulich wrote:
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

> v2: Add CONFIG_PV conditional.
> 
> --- a/xen/arch/x86/pv/domain.c
> +++ b/xen/arch/x86/pv/domain.c
> @@ -288,6 +288,12 @@ int pv_domain_initialise(struct domain *
>      return rc;
>  }
>  
> +bool __init xpti_pcid_enabled(void)
> +{
> +    return use_invpcid && cpu_has_pcid &&
> +           (opt_pcid == PCID_ALL || opt_pcid == PCID_XPTI);
> +}
> +
>  static void _toggle_guest_pt(struct vcpu *v)
>  {
>      const struct domain *d = v->domain;
> --- a/xen/arch/x86/spec_ctrl.c
> +++ b/xen/arch/x86/spec_ctrl.c
> @@ -256,9 +256,12 @@ static void __init print_details(enum in
>             boot_cpu_has(X86_FEATURE_SC_RSB_HVM)      ? " RSB"           : "",
>             opt_eager_fpu                             ? " EAGER_FPU"     : "");
>  
> -    printk("  XPTI (64-bit PV only): Dom0 %s, DomU %s\n",
> +#ifdef CONFIG_PV
> +    printk("  XPTI (64-bit PV only): Dom0 %s, DomU %s (with%s PCID)\n",
>             opt_xpti & OPT_XPTI_DOM0 ? "enabled" : "disabled",
> -           opt_xpti & OPT_XPTI_DOMU ? "enabled" : "disabled");
> +           opt_xpti & OPT_XPTI_DOMU ? "enabled" : "disabled",
> +           xpti_pcid_enabled() ? "" : "out");
> +#endif
>  }
>  
>  /* Calculate whether Retpoline is known-safe on this CPU. */
> --- a/xen/include/asm-x86/spec_ctrl.h
> +++ b/xen/include/asm-x86/spec_ctrl.h
> @@ -38,6 +38,8 @@ extern uint8_t opt_xpti;
>  #define OPT_XPTI_DOM0  0x01
>  #define OPT_XPTI_DOMU  0x02
>  
> +bool xpti_pcid_enabled(void);
> +

I would have placed the prototype in pv/domain.h instead if the
function is defined in pv/domain.c.

Thanks, Roger.

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

Re: [PATCH v2 2/2] x86/spec-ctrl: split reporting for PV and HVM guests

[Roger Pau Monné]

On Wed, Jul 18, 2018 at 02:33:31AM -0600, Jan Beulich wrote:
> Putting them on separate lines was suggested before, and is going to
> become necessary eventually anyway as things get added here. Split them
> now, and put the respective pieces in CONFIG_* conditionals at the same
> time.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks, Roger.

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

Re: [PATCH v2 1/2] x86: report use of PCID together with reporting XPTI status

[Jan Beulich]

>>> On 18.07.18 at 10:46, <andrew.cooper3@citrix.com> wrote:
> On 18/07/2018 09:33, Jan Beulich wrote:
>> --- a/xen/include/asm-x86/spec_ctrl.h
>> +++ b/xen/include/asm-x86/spec_ctrl.h
>> @@ -38,6 +38,8 @@ extern uint8_t opt_xpti;
>>  #define OPT_XPTI_DOM0  0x01
>>  #define OPT_XPTI_DOMU  0x02
>>  
>> +bool xpti_pcid_enabled(void);
> 
> This still should be inside an CONFIG_PV to avoid scenarios which will
> compile correctly but fail to link.  It should live in pv/domain.h at
> which point everything should be fine.

It was intentional that I didn't move the declaration: Whether the build
fails at the compile or link stage is irrelevant imo. All we need is that it
fail at all. I would have moved it if its current placement wasn't again
very intentional, next to the other XPTI pieces.

> With that, Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

Please clarify whether you can live with the above.

Jan



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

Re: [PATCH v2 1/2] x86: report use of PCID together with reporting XPTI status

[Andrew Cooper]

On 18/07/18 10:19, Jan Beulich wrote:
>>>> On 18.07.18 at 10:46, <andrew.cooper3@citrix.com> wrote:
>> On 18/07/2018 09:33, Jan Beulich wrote:
>>> --- a/xen/include/asm-x86/spec_ctrl.h
>>> +++ b/xen/include/asm-x86/spec_ctrl.h
>>> @@ -38,6 +38,8 @@ extern uint8_t opt_xpti;
>>>  #define OPT_XPTI_DOM0  0x01
>>>  #define OPT_XPTI_DOMU  0x02
>>>  
>>> +bool xpti_pcid_enabled(void);
>> This still should be inside an CONFIG_PV to avoid scenarios which will
>> compile correctly but fail to link.  It should live in pv/domain.h at
>> which point everything should be fine.
> It was intentional that I didn't move the declaration: Whether the build
> fails at the compile or link stage is irrelevant imo.

It is extremely relevant.

A compiler error points to the file/line here something is wrong, while
a linker error says "something somewhere went wrong", and grepping for
the symbol identified in the error won't be helpful for tracking down
the problem.

Furthermore, with CONFIG_PV not being a usable option yet, there is a
good chance of an error slipping in and going unnoticed until CONFIG_PV
can actually turned off.

>  All we need is that it
> fail at all. I would have moved it if its current placement wasn't again
> very intentional, next to the other XPTI pieces.

You provided a reasonable justification for why the body of this
function should be in pv/domain.c  Therefore, its declaration lives in
pv/domain.h

>
>> With that, Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Please clarify whether you can live with the above.

I'm not happy living with a linker error.

~Andrew

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

Re: [PATCH v2 1/2] x86: report use of PCID together with reporting XPTI status

[Jan Beulich]

>>> On 18.07.18 at 16:47, <andrew.cooper3@citrix.com> wrote:
> On 18/07/18 10:19, Jan Beulich wrote:
>>>>> On 18.07.18 at 10:46, <andrew.cooper3@citrix.com> wrote:
>>> On 18/07/2018 09:33, Jan Beulich wrote:
>>>> --- a/xen/include/asm-x86/spec_ctrl.h
>>>> +++ b/xen/include/asm-x86/spec_ctrl.h
>>>> @@ -38,6 +38,8 @@ extern uint8_t opt_xpti;
>>>>  #define OPT_XPTI_DOM0  0x01
>>>>  #define OPT_XPTI_DOMU  0x02
>>>>  
>>>> +bool xpti_pcid_enabled(void);
>>> This still should be inside an CONFIG_PV to avoid scenarios which will
>>> compile correctly but fail to link.  It should live in pv/domain.h at
>>> which point everything should be fine.
>> It was intentional that I didn't move the declaration: Whether the build
>> fails at the compile or link stage is irrelevant imo.
> 
> It is extremely relevant.
> 
> A compiler error points to the file/line here something is wrong, while
> a linker error says "something somewhere went wrong", and grepping for
> the symbol identified in the error won't be helpful for tracking down
> the problem.

I think you didn't run into linker errors in the last so many years - ld
has become quite good at pointing at the place the reference comes
from. Or maybe this is functionality that can be configured off, but
then I'd say it's a quality issue of your binutils.

>>  All we need is that it
>> fail at all. I would have moved it if its current placement wasn't again
>> very intentional, next to the other XPTI pieces.
> 
> You provided a reasonable justification for why the body of this
> function should be in pv/domain.c  Therefore, its declaration lives in
> pv/domain.h

Then the other XPTI stuff should move there too.

Jan



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

[PATCH v3 0/2] x86: HW vulnerability mitigation logging improvements

[Jan Beulich]

I'm not really convinced of the change done in v3, even less so with
x86'es pv/domain.h not really having been suitable for inclusion in
spec-ctrl.c (needed an extra, seemingly unrelated adjustment), but
in the interest of getting this done, here you go.

1: x86: report use of PCID together with reporting XPTI status
2: x86/spec-ctrl: split reporting for PV and HVM guests

Jan



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

[PATCH v3 1/2] x86: report use of PCID together with reporting XPTI status

[Jan Beulich]

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
---
v3: Move declaration to pv/domain.h. Re-base.
v2: Add CONFIG_PV conditional.

--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -289,6 +289,12 @@ int pv_domain_initialise(struct domain *
     return rc;
 }
 
+bool __init xpti_pcid_enabled(void)
+{
+    return use_invpcid && cpu_has_pcid &&
+           (opt_pcid == PCID_ALL || opt_pcid == PCID_XPTI);
+}
+
 static void _toggle_guest_pt(struct vcpu *v)
 {
     const struct domain *d = v->domain;
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -24,6 +24,7 @@
 #include <asm/microcode.h>
 #include <asm/msr.h>
 #include <asm/processor.h>
+#include <asm/pv/domain.h>
 #include <asm/pv/shim.h>
 #include <asm/setup.h>
 #include <asm/spec_ctrl.h>
@@ -342,13 +343,16 @@ static void __init print_details(enum in
            boot_cpu_has(X86_FEATURE_SC_RSB_HVM)      ? " RSB"           : "",
            opt_eager_fpu                             ? " EAGER_FPU"     : "");
 
-    printk("  XPTI (64-bit PV only): Dom0 %s, DomU %s\n",
+#ifdef CONFIG_PV
+    printk("  XPTI (64-bit PV only): Dom0 %s, DomU %s (with%s PCID)\n",
            opt_xpti & OPT_XPTI_DOM0 ? "enabled" : "disabled",
-           opt_xpti & OPT_XPTI_DOMU ? "enabled" : "disabled");
+           opt_xpti & OPT_XPTI_DOMU ? "enabled" : "disabled",
+           xpti_pcid_enabled() ? "" : "out");
 
     printk("  PV L1TF shadowing: Dom0 %s, DomU %s\n",
            opt_pv_l1tf & OPT_PV_L1TF_DOM0  ? "enabled"  : "disabled",
            opt_pv_l1tf & OPT_PV_L1TF_DOMU  ? "enabled"  : "disabled");
+#endif
 }
 
 /* Calculate whether Retpoline is known-safe on this CPU. */
--- a/xen/include/asm-x86/pv/domain.h
+++ b/xen/include/asm-x86/pv/domain.h
@@ -21,6 +21,8 @@
 #ifndef __X86_PV_DOMAIN_H__
 #define __X86_PV_DOMAIN_H__
 
+#include <xen/sched.h>
+
 /*
  * PCID values for the address spaces of 64-bit pv domains:
  *
@@ -59,6 +61,8 @@ int pv_vcpu_initialise(struct vcpu *v);
 void pv_domain_destroy(struct domain *d);
 int pv_domain_initialise(struct domain *d);
 
+bool xpti_pcid_enabled(void);
+
 #else  /* !CONFIG_PV */
 
 #include <xen/errno.h>




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

[PATCH v3 2/2] x86/spec-ctrl: split reporting for PV and HVM guests

[Jan Beulich]

Putting them on separate lines was suggested before, and is going to
become necessary eventually anyway as things get added here. Split them
now, and put the respective pieces in CONFIG_* conditionals at the same
time.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
---
v2: New.

--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -329,13 +329,8 @@ static void __init print_details(enum in
      * Alternatives blocks for protecting against and/or virtualising
      * mitigation support for guests.
      */
-    printk("  Support for VMs: PV:%s%s%s%s, HVM:%s%s%s%s\n",
-           (boot_cpu_has(X86_FEATURE_SC_MSR_PV) ||
-            boot_cpu_has(X86_FEATURE_SC_RSB_PV) ||
-            opt_eager_fpu)                           ? ""               : " None",
-           boot_cpu_has(X86_FEATURE_SC_MSR_PV)       ? " MSR_SPEC_CTRL" : "",
-           boot_cpu_has(X86_FEATURE_SC_RSB_PV)       ? " RSB"           : "",
-           opt_eager_fpu                             ? " EAGER_FPU"     : "",
+#ifdef CONFIG_HVM
+    printk("  Support for HVM VMs:%s%s%s%s\n",
            (boot_cpu_has(X86_FEATURE_SC_MSR_HVM) ||
             boot_cpu_has(X86_FEATURE_SC_RSB_HVM) ||
             opt_eager_fpu)                           ? ""               : " None",
@@ -343,7 +338,16 @@ static void __init print_details(enum in
            boot_cpu_has(X86_FEATURE_SC_RSB_HVM)      ? " RSB"           : "",
            opt_eager_fpu                             ? " EAGER_FPU"     : "");
 
+#endif
 #ifdef CONFIG_PV
+    printk("  Support for PV VMs:%s%s%s%s\n",
+           (boot_cpu_has(X86_FEATURE_SC_MSR_PV) ||
+            boot_cpu_has(X86_FEATURE_SC_RSB_PV) ||
+            opt_eager_fpu)                           ? ""               : " None",
+           boot_cpu_has(X86_FEATURE_SC_MSR_PV)       ? " MSR_SPEC_CTRL" : "",
+           boot_cpu_has(X86_FEATURE_SC_RSB_PV)       ? " RSB"           : "",
+           opt_eager_fpu                             ? " EAGER_FPU"     : "");
+
     printk("  XPTI (64-bit PV only): Dom0 %s, DomU %s (with%s PCID)\n",
            opt_xpti & OPT_XPTI_DOM0 ? "enabled" : "disabled",
            opt_xpti & OPT_XPTI_DOMU ? "enabled" : "disabled",




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

Ping: [PATCH v3 0/2] x86: HW vulnerability mitigation logging improvements

[Jan Beulich]

>>> On 17.08.18 at 08:45,  wrote:
> I'm not really convinced of the change done in v3, even less so with
> x86'es pv/domain.h not really having been suitable for inclusion in
> spec-ctrl.c (needed an extra, seemingly unrelated adjustment), but
> in the interest of getting this done, here you go.
> 
> 1: x86: report use of PCID together with reporting XPTI status
> 2: x86/spec-ctrl: split reporting for PV and HVM guests
> 
> Jan
> 
> 





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

Re: [PATCH v3 1/2] x86: report use of PCID together with reporting XPTI status

[Andrew Cooper]

On 17/08/18 08:04, Jan Beulich wrote:
> --- a/xen/include/asm-x86/pv/domain.h
> +++ b/xen/include/asm-x86/pv/domain.h
> @@ -21,6 +21,8 @@
>  #ifndef __X86_PV_DOMAIN_H__
>  #define __X86_PV_DOMAIN_H__
>  
> +#include <xen/sched.h>

Just types?  Its all you need.

~Andrew

> +
>  /*
>   * PCID values for the address spaces of 64-bit pv domains:
>   *
> @@ -59,6 +61,8 @@ int pv_vcpu_initialise(struct vcpu *v);
>  void pv_domain_destroy(struct domain *d);
>  int pv_domain_initialise(struct domain *d);
>  
> +bool xpti_pcid_enabled(void);
> +
>  #else  /* !CONFIG_PV */
>  
>  #include <xen/errno.h>
>
>
>


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

Re: [PATCH v3 1/2] x86: report use of PCID together with reporting XPTI status

[Jan Beulich]

>>> On 29.08.18 at 14:41, <andrew.cooper3@citrix.com> wrote:
> On 17/08/18 08:04, Jan Beulich wrote:
>> --- a/xen/include/asm-x86/pv/domain.h
>> +++ b/xen/include/asm-x86/pv/domain.h
>> @@ -21,6 +21,8 @@
>>  #ifndef __X86_PV_DOMAIN_H__
>>  #define __X86_PV_DOMAIN_H__
>>  
>> +#include <xen/sched.h>
> 
> Just types?  Its all you need.

That's all I need for my addition, but prior to this the header wasn't
usable without first having included some other headers.
get_pcid_bits() de-references struct vcpu, so sched.h _is_ needed
(and should have been there before).

Jan



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

Re: [PATCH v3 1/2] x86: report use of PCID together with reporting XPTI status

[Andrew Cooper]

On 29/08/18 13:53, Jan Beulich wrote:
>>>> On 29.08.18 at 14:41, <andrew.cooper3@citrix.com> wrote:
>> On 17/08/18 08:04, Jan Beulich wrote:
>>> --- a/xen/include/asm-x86/pv/domain.h
>>> +++ b/xen/include/asm-x86/pv/domain.h
>>> @@ -21,6 +21,8 @@
>>>  #ifndef __X86_PV_DOMAIN_H__
>>>  #define __X86_PV_DOMAIN_H__
>>>  
>>> +#include <xen/sched.h>
>> Just types?  Its all you need.
> That's all I need for my addition, but prior to this the header wasn't
> usable without first having included some other headers.
> get_pcid_bits() de-references struct vcpu, so sched.h _is_ needed
> (and should have been there before).

Ok.  Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

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