diff mbox

[v2,17/30] x86/cpu: Common infrastructure for levelling context switching

Message ID 1454679743-18133-18-git-send-email-andrew.cooper3@citrix.com (mailing list archive)
State New, archived
Headers show

Commit Message

Andrew Cooper Feb. 5, 2016, 1:42 p.m. UTC
This change is purely scaffolding to reduce the complexity of the following
three patches.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>

v2: s/cpumasks/cpuidmasks/
---
 xen/arch/x86/cpu/common.c        |  6 ++++++
 xen/include/asm-x86/cpufeature.h |  1 +
 xen/include/asm-x86/processor.h  | 28 ++++++++++++++++++++++++++++
 3 files changed, 35 insertions(+)

Comments

Jan Beulich Feb. 16, 2016, 2:15 p.m. UTC | #1
>>> On 05.02.16 at 14:42, <andrew.cooper3@citrix.com> wrote:
> --- a/xen/include/asm-x86/processor.h
> +++ b/xen/include/asm-x86/processor.h
> @@ -574,6 +574,34 @@ void microcode_set_module(unsigned int);
>  int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void), unsigned long len);
>  int microcode_resume_cpu(unsigned int cpu);
>  
> +#define LCAP_faulting (1U << 0)
> +#define LCAP_1cd      (3U << 1)
> +#define LCAP_e1cd     (3U << 3)
> +#define LCAP_Da1      (1U << 5)
> +#define LCAP_6c       (1U << 6)
> +#define LCAP_7ab0     (3U << 7)

I guess the cases where the mask has two set bits is when two
CPUID output registers are being controlled, but I don't see
what use that pairing is going to be. But with the patch
supposedly going to make sense only in the context of the
following ones, I'll see (and I'd presumably be able to ack this
one then also only when having seen the others).

Jan
Jan Beulich Feb. 17, 2016, 8:15 a.m. UTC | #2
>>> On 16.02.16 at 15:15, <JBeulich@suse.com> wrote:
>>>> On 05.02.16 at 14:42, <andrew.cooper3@citrix.com> wrote:
>> --- a/xen/include/asm-x86/processor.h
>> +++ b/xen/include/asm-x86/processor.h
>> @@ -574,6 +574,34 @@ void microcode_set_module(unsigned int);
>>  int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void), unsigned long len);
>>  int microcode_resume_cpu(unsigned int cpu);
>>  
>> +#define LCAP_faulting (1U << 0)
>> +#define LCAP_1cd      (3U << 1)
>> +#define LCAP_e1cd     (3U << 3)
>> +#define LCAP_Da1      (1U << 5)
>> +#define LCAP_6c       (1U << 6)
>> +#define LCAP_7ab0     (3U << 7)
> 
> I guess the cases where the mask has two set bits is when two
> CPUID output registers are being controlled, but I don't see
> what use that pairing is going to be. But with the patch
> supposedly going to make sense only in the context of the
> following ones, I'll see (and I'd presumably be able to ack this
> one then also only when having seen the others).

Having seen patches up to and including 21, I still don't see the
point of using 2-bit masks here.

Jan
Andrew Cooper Feb. 17, 2016, 10:46 a.m. UTC | #3
On 17/02/16 08:15, Jan Beulich wrote:
>>>> On 16.02.16 at 15:15, <JBeulich@suse.com> wrote:
>>>>> On 05.02.16 at 14:42, <andrew.cooper3@citrix.com> wrote:
>>> --- a/xen/include/asm-x86/processor.h
>>> +++ b/xen/include/asm-x86/processor.h
>>> @@ -574,6 +574,34 @@ void microcode_set_module(unsigned int);
>>>  int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void), unsigned long len);
>>>  int microcode_resume_cpu(unsigned int cpu);
>>>  
>>> +#define LCAP_faulting (1U << 0)
>>> +#define LCAP_1cd      (3U << 1)
>>> +#define LCAP_e1cd     (3U << 3)
>>> +#define LCAP_Da1      (1U << 5)
>>> +#define LCAP_6c       (1U << 6)
>>> +#define LCAP_7ab0     (3U << 7)
>> I guess the cases where the mask has two set bits is when two
>> CPUID output registers are being controlled, but I don't see
>> what use that pairing is going to be. But with the patch
>> supposedly going to make sense only in the context of the
>> following ones, I'll see (and I'd presumably be able to ack this
>> one then also only when having seen the others).
> Having seen patches up to and including 21, I still don't see the
> point of using 2-bit masks here.

The previous sysctl interface had individual bits.  I suppose that now I
have dropped that, these could return to single bits.

~Andrew
Konrad Rzeszutek Wilk Feb. 17, 2016, 7:06 p.m. UTC | #4
On Fri, Feb 05, 2016 at 01:42:10PM +0000, Andrew Cooper wrote:
> This change is purely scaffolding to reduce the complexity of the following
> three patches.

Keep in mind that the patches may not be applied right after this.

It would be easier to jus spell out the three patches.
diff mbox

Patch

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 46d93a6..3fdae96 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -36,6 +36,12 @@  integer_param("cpuid_mask_ext_ecx", opt_cpuid_mask_ext_ecx);
 unsigned int opt_cpuid_mask_ext_edx = ~0u;
 integer_param("cpuid_mask_ext_edx", opt_cpuid_mask_ext_edx);
 
+unsigned int __initdata expected_levelling_cap;
+unsigned int __read_mostly levelling_caps;
+
+DEFINE_PER_CPU(struct cpuidmasks, cpuidmasks);
+struct cpuidmasks __read_mostly cpuidmask_defaults;
+
 const struct cpu_dev *__read_mostly cpu_devs[X86_VENDOR_NUM] = {};
 
 unsigned int paddr_bits __read_mostly = 36;
diff --git a/xen/include/asm-x86/cpufeature.h b/xen/include/asm-x86/cpufeature.h
index f228fa2..8ac6b56 100644
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -95,6 +95,7 @@ 
 #define cpu_has_xsavec		boot_cpu_has(X86_FEATURE_XSAVEC)
 #define cpu_has_xgetbv1		boot_cpu_has(X86_FEATURE_XGETBV1)
 #define cpu_has_xsaves		boot_cpu_has(X86_FEATURE_XSAVES)
+#define cpu_has_hypervisor	boot_cpu_has(X86_FEATURE_HYPERVISOR)
 
 enum _cache_type {
     CACHE_TYPE_NULL = 0,
diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
index 271340e..09e82d8 100644
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -574,6 +574,34 @@  void microcode_set_module(unsigned int);
 int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void), unsigned long len);
 int microcode_resume_cpu(unsigned int cpu);
 
+#define LCAP_faulting (1U << 0)
+#define LCAP_1cd      (3U << 1)
+#define LCAP_e1cd     (3U << 3)
+#define LCAP_Da1      (1U << 5)
+#define LCAP_6c       (1U << 6)
+#define LCAP_7ab0     (3U << 7)
+
+/*
+ * Expected levelling capabilities (given cpuid vendor/family information),
+ * and levelling capabilities actually available (given MSR probing).
+ */
+extern unsigned int expected_levelling_cap, levelling_caps;
+
+struct cpuidmasks
+{
+    uint64_t _1cd;
+    uint64_t e1cd;
+    uint64_t Da1;
+    uint64_t _6c;
+    uint64_t _7ab0;
+};
+
+/* Per CPU shadows of masking MSR values, for lazy context switching. */
+DECLARE_PER_CPU(struct cpuidmasks, cpuidmasks);
+
+/* Default masking MSR values, calculated at boot. */
+extern struct cpuidmasks cpuidmask_defaults;
+
 enum get_cpu_vendor {
    gcv_host_early,
    gcv_host_late,