* [PATCH v2 01/14] x86/cpufeatures: Expose self-snoop to all guests
2017-01-23 14:39 [PATCH v2 00/14] x86/cpuid: Handling of simple leaves in guest_cpuid() Andrew Cooper
@ 2017-01-23 14:39 ` Andrew Cooper
2017-01-24 11:08 ` Jan Beulich
2017-01-24 11:28 ` Roger Pau Monné
2017-01-23 14:39 ` [PATCH v2 02/14] x86/cpuid: Handle leaf 0x80000000 in guest_cpuid() Andrew Cooper
` (12 subsequent siblings)
13 siblings, 2 replies; 42+ messages in thread
From: Andrew Cooper @ 2017-01-23 14:39 UTC (permalink / raw)
To: Xen-devel; +Cc: Andrew Cooper, Jan Beulich, Roger Pau Monné
Self-snoop describes a property of the CPU cache behaviour, which FreeBSD uses
to optimise its cache flushing algorithm.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
v2:
* New
---
xen/include/public/arch-x86/cpufeatureset.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h
index 306200b..70f1e30 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -114,6 +114,7 @@ XEN_CPUFEATURE(MMX, 0*32+23) /*A Multimedia Extensions */
XEN_CPUFEATURE(FXSR, 0*32+24) /*A FXSAVE and FXRSTOR instructions */
XEN_CPUFEATURE(SSE, 0*32+25) /*A Streaming SIMD Extensions */
XEN_CPUFEATURE(SSE2, 0*32+26) /*A Streaming SIMD Extensions-2 */
+XEN_CPUFEATURE(SS, 0*32+27) /*A CPU self snoop */
XEN_CPUFEATURE(HTT, 0*32+28) /*!A Hyper-Threading Technology */
XEN_CPUFEATURE(TM1, 0*32+29) /* Thermal Monitor 1 */
XEN_CPUFEATURE(PBE, 0*32+31) /* Pending Break Enable */
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 42+ messages in thread* Re: [PATCH v2 01/14] x86/cpufeatures: Expose self-snoop to all guests
2017-01-23 14:39 ` [PATCH v2 01/14] x86/cpufeatures: Expose self-snoop to all guests Andrew Cooper
@ 2017-01-24 11:08 ` Jan Beulich
2017-01-24 11:28 ` Roger Pau Monné
1 sibling, 0 replies; 42+ messages in thread
From: Jan Beulich @ 2017-01-24 11:08 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Xen-devel, roger.pau
>>> On 23.01.17 at 15:39, <andrew.cooper3@citrix.com> wrote:
> Self-snoop describes a property of the CPU cache behaviour, which FreeBSD uses
> to optimise its cache flushing algorithm.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 01/14] x86/cpufeatures: Expose self-snoop to all guests
2017-01-23 14:39 ` [PATCH v2 01/14] x86/cpufeatures: Expose self-snoop to all guests Andrew Cooper
2017-01-24 11:08 ` Jan Beulich
@ 2017-01-24 11:28 ` Roger Pau Monné
1 sibling, 0 replies; 42+ messages in thread
From: Roger Pau Monné @ 2017-01-24 11:28 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Jan Beulich, Xen-devel
On Mon, Jan 23, 2017 at 02:39:04PM +0000, Andrew Cooper wrote:
> Self-snoop describes a property of the CPU cache behaviour, which FreeBSD uses
> to optimise its cache flushing algorithm.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tested-by: Roger Pau Monné <roger.pau@citrix.com>
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH v2 02/14] x86/cpuid: Handle leaf 0x80000000 in guest_cpuid()
2017-01-23 14:39 [PATCH v2 00/14] x86/cpuid: Handling of simple leaves in guest_cpuid() Andrew Cooper
2017-01-23 14:39 ` [PATCH v2 01/14] x86/cpufeatures: Expose self-snoop to all guests Andrew Cooper
@ 2017-01-23 14:39 ` Andrew Cooper
2017-01-23 14:39 ` [PATCH v2 03/14] x86/cpuid: Only recalculate the shared feature bits once Andrew Cooper
` (11 subsequent siblings)
13 siblings, 0 replies; 42+ messages in thread
From: Andrew Cooper @ 2017-01-23 14:39 UTC (permalink / raw)
To: Xen-devel; +Cc: Andrew Cooper
The calculations for p->extd.max_leaf are reworked to force a value of at
least 0x80000000, and to take the domains chosen vendor into account when
clamping maximum value.
The high short vendor information is clobbered or duplicated according to the
chosen vendor.
As a side effect of handing out an audited max_leaf value, the 0x8000001e case
can be dropped from pv_cpuid(), as it outside of the visible range.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
Reviewed-by: Jan Beulich <JBeulich@suse.com>
---
v2:
* Drop 0x8000001e from pv_cpuid()
* s/recalculate_common/recalculate_misc/
---
xen/arch/x86/cpuid.c | 53 +++++++++++++++++++++++++++++++++++++++------
xen/include/asm-x86/cpuid.h | 6 ++---
2 files changed, 49 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 85c829d..3f398b5 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -163,6 +163,28 @@ static void recalculate_xstate(struct cpuid_policy *p)
}
}
+/*
+ * Misc adjustments to the policy. Mostly clobbering reserved fields and
+ * duplicating shared fields.
+ */
+static void recalculate_misc(struct cpuid_policy *p)
+{
+ switch ( p->x86_vendor )
+ {
+ case X86_VENDOR_INTEL:
+ p->extd.vendor_ebx = 0;
+ p->extd.vendor_ecx = 0;
+ p->extd.vendor_edx = 0;
+ break;
+
+ case X86_VENDOR_AMD:
+ p->extd.vendor_ebx = p->basic.vendor_ebx;
+ p->extd.vendor_ecx = p->basic.vendor_ecx;
+ p->extd.vendor_edx = p->basic.vendor_edx;
+ break;
+ }
+}
+
static void __init calculate_raw_policy(void)
{
struct cpuid_policy *p = &raw_policy;
@@ -227,12 +249,12 @@ static void __init calculate_host_policy(void)
min_t(uint32_t, p->basic.max_leaf, ARRAY_SIZE(p->basic.raw) - 1);
p->feat.max_subleaf =
min_t(uint32_t, p->feat.max_subleaf, ARRAY_SIZE(p->feat.raw) - 1);
- p->extd.max_leaf =
- min_t(uint32_t, p->extd.max_leaf,
- 0x80000000u + ARRAY_SIZE(p->extd.raw) - 1);
+ p->extd.max_leaf = 0x80000000 | min_t(uint32_t, p->extd.max_leaf & 0xffff,
+ ARRAY_SIZE(p->extd.raw) - 1);
cpuid_featureset_to_policy(boot_cpu_data.x86_capability, p);
recalculate_xstate(p);
+ recalculate_misc(p);
}
static void __init calculate_pv_max_policy(void)
@@ -360,7 +382,10 @@ void recalculate_cpuid_policy(struct domain *d)
p->basic.max_leaf = min(p->basic.max_leaf, max->basic.max_leaf);
p->feat.max_subleaf = min(p->feat.max_subleaf, max->feat.max_subleaf);
- p->extd.max_leaf = min(p->extd.max_leaf, max->extd.max_leaf);
+ p->extd.max_leaf = 0x80000000 | min(p->extd.max_leaf & 0xffff,
+ (p->x86_vendor == X86_VENDOR_AMD
+ ? CPUID_GUEST_NR_EXTD_AMD
+ : CPUID_GUEST_NR_EXTD_INTEL) - 1);
cpuid_policy_to_featureset(p, fs);
cpuid_policy_to_featureset(max, max_fs);
@@ -428,6 +453,7 @@ void recalculate_cpuid_policy(struct domain *d)
cpuid_featureset_to_policy(fs, p);
recalculate_xstate(p);
+ recalculate_misc(p);
}
int init_domain_cpuid_policy(struct domain *d)
@@ -675,7 +701,6 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x8000000a: /* SVM revision and features */
case 0x8000001b: /* Instruction Based Sampling */
case 0x8000001c: /* Light Weight Profiling */
- case 0x8000001e: /* Extended topology reporting */
unsupported:
*res = EMPTY_LEAF;
break;
@@ -683,6 +708,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x0:
case 0x7:
case XSTATE_CPUID:
+ case 0x80000000:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -832,6 +858,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x0:
case 0x7:
case XSTATE_CPUID:
+ case 0x80000000:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -901,9 +928,21 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
return cpuid_hypervisor_leaves(v, leaf, subleaf, res);
case 0x80000000 ... 0x80000000 + CPUID_GUEST_NR_EXTD - 1:
- if ( leaf > p->extd.max_leaf )
+ ASSERT((p->extd.max_leaf & 0xffff) < ARRAY_SIZE(p->extd.raw));
+ if ( (leaf & 0xffff) > min_t(uint32_t, p->extd.max_leaf & 0xffff,
+ ARRAY_SIZE(p->extd.raw) - 1) )
return;
- goto legacy;
+
+ switch ( leaf )
+ {
+ default:
+ goto legacy;
+
+ case 0x80000000:
+ *res = p->extd.raw[leaf & 0xffff];
+ break;
+ }
+ break;
default:
return;
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index 299a026..4712b73 100644
--- a/xen/include/asm-x86/cpuid.h
+++ b/xen/include/asm-x86/cpuid.h
@@ -81,7 +81,7 @@ struct cpuid_policy
* - All of the feat and xstate unions
* - max_{,sub}leaf
* - All FEATURESET_* words
- * - Low short vendor infomation
+ * - Short vendor infomation
*
* Per-domain objects:
*
@@ -89,7 +89,7 @@ struct cpuid_policy
* - All of the feat and xstate unions
* - max_{,sub}leaf
* - All FEATURESET_* words
- * - Low short vendor infomation
+ * - Short vendor infomation
*
* Everything else should be considered inaccurate, and not necesserily 0.
*/
@@ -168,7 +168,7 @@ struct cpuid_policy
struct cpuid_leaf raw[CPUID_GUEST_NR_EXTD];
struct {
/* Leaf 0x80000000 - Max and vendor. */
- uint32_t max_leaf, /* b */:32, /* c */:32, /* d */:32;
+ uint32_t max_leaf, vendor_ebx, vendor_ecx, vendor_edx;
/* Leaf 0x80000001 - Family/model/stepping and features. */
uint32_t /* a */:32, /* b */:32;
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 42+ messages in thread* [PATCH v2 03/14] x86/cpuid: Only recalculate the shared feature bits once
2017-01-23 14:39 [PATCH v2 00/14] x86/cpuid: Handling of simple leaves in guest_cpuid() Andrew Cooper
2017-01-23 14:39 ` [PATCH v2 01/14] x86/cpufeatures: Expose self-snoop to all guests Andrew Cooper
2017-01-23 14:39 ` [PATCH v2 02/14] x86/cpuid: Handle leaf 0x80000000 in guest_cpuid() Andrew Cooper
@ 2017-01-23 14:39 ` Andrew Cooper
2017-01-23 14:39 ` [PATCH v2 04/14] x86/cpuid: Handle more simple Intel leaves in guest_cpuid() Andrew Cooper
` (10 subsequent siblings)
13 siblings, 0 replies; 42+ messages in thread
From: Andrew Cooper @ 2017-01-23 14:39 UTC (permalink / raw)
To: Xen-devel; +Cc: Andrew Cooper
With accurate vendor information available, the shared bits can be sorted out
during recalculation, rather than at query time in the legacy cpuid path.
This means that:
* Duplication can be dropped from the automatically generated cpuid data.
* The toolstack need not worry about setting them appropriately.
* They can be dropped from the system maximum featuresets.
While editing gen-cpuid.py, reflow some comments which exceeded the expected
line length.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
tools/libxc/xc_cpuid_x86.c | 19 -------------------
xen/arch/x86/cpuid.c | 25 +++++--------------------
xen/tools/gen-cpuid.py | 29 ++++++++++-------------------
3 files changed, 15 insertions(+), 58 deletions(-)
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 96d6025..918590f 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -41,7 +41,6 @@ enum {
#define DEF_MAX_BASE 0x0000000du
#define DEF_MAX_INTELEXT 0x80000008u
#define DEF_MAX_AMDEXT 0x8000001cu
-#define COMMON_1D CPUID_COMMON_1D_FEATURES
int xc_get_cpu_levelling_caps(xc_interface *xch, uint32_t *caps)
{
@@ -712,24 +711,6 @@ static void sanitise_featureset(struct cpuid_domain_info *info)
disabled_features[i] &= ~dfs[i];
}
}
-
- switch ( info->vendor )
- {
- case VENDOR_INTEL:
- /* Intel clears the common bits in e1d. */
- info->featureset[featureword_of(X86_FEATURE_SYSCALL)] &= ~COMMON_1D;
- break;
-
- case VENDOR_AMD:
- /* AMD duplicates the common bits between 1d and e1d. */
- info->featureset[featureword_of(X86_FEATURE_SYSCALL)] =
- ((info->featureset[featureword_of(X86_FEATURE_FPU)] & COMMON_1D) |
- (info->featureset[featureword_of(X86_FEATURE_SYSCALL)] & ~COMMON_1D));
- break;
-
- default:
- break;
- }
}
int xc_cpuid_apply_policy(xc_interface *xch, domid_t domid,
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 3f398b5..87ec02f 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -67,18 +67,6 @@ static void sanitise_featureset(uint32_t *fs)
disabled_features[j] &= ~dfs[j];
}
}
-
- /*
- * Sort out shared bits. We are constructing a featureset which needs to
- * be applicable to a cross-vendor case. Intel strictly clears the common
- * bits in e1d, while AMD strictly duplicates them.
- *
- * We duplicate them here to be compatible with AMD while on Intel, and
- * rely on logic closer to the guest to make the featureset stricter if
- * emulating Intel.
- */
- fs[FEATURESET_e1d] = ((fs[FEATURESET_1d] & CPUID_COMMON_1D_FEATURES) |
- (fs[FEATURESET_e1d] & ~CPUID_COMMON_1D_FEATURES));
}
static void recalculate_xstate(struct cpuid_policy *p)
@@ -169,6 +157,8 @@ static void recalculate_xstate(struct cpuid_policy *p)
*/
static void recalculate_misc(struct cpuid_policy *p)
{
+ p->extd.e1d &= ~CPUID_COMMON_1D_FEATURES;
+
switch ( p->x86_vendor )
{
case X86_VENDOR_INTEL:
@@ -181,6 +171,8 @@ static void recalculate_misc(struct cpuid_policy *p)
p->extd.vendor_ebx = p->basic.vendor_ebx;
p->extd.vendor_ecx = p->basic.vendor_ecx;
p->extd.vendor_edx = p->basic.vendor_edx;
+
+ p->extd.e1d |= p->basic._1d & CPUID_COMMON_1D_FEATURES;
break;
}
}
@@ -669,10 +661,6 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
res->c = p->extd.e1c;
res->d = p->extd.e1d;
- /* If not emulating AMD, clear the duplicated features in e1d. */
- if ( p->x86_vendor != X86_VENDOR_AMD )
- res->d &= ~CPUID_COMMON_1D_FEATURES;
-
/*
* MTRR used to unconditionally leak into PV guests. They cannot MTRR
* infrastructure at all, and shouldn't be able to see the feature.
@@ -792,11 +780,8 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
res->c = p->extd.e1c;
res->d = p->extd.e1d;
- /* If not emulating AMD, clear the duplicated features in e1d. */
- if ( p->x86_vendor != X86_VENDOR_AMD )
- res->d &= ~CPUID_COMMON_1D_FEATURES;
/* fast-forward MSR_APIC_BASE.EN if it hasn't already been clobbered. */
- else if ( vlapic_hw_disabled(vcpu_vlapic(v)) )
+ if ( vlapic_hw_disabled(vcpu_vlapic(v)) )
res->d &= ~cpufeat_bit(X86_FEATURE_APIC);
/*
diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py
index 6212e4f..5cab6db 100755
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -129,16 +129,7 @@ def crunch_numbers(state):
common_1d = (FPU, VME, DE, PSE, TSC, MSR, PAE, MCE, CX8, APIC,
MTRR, PGE, MCA, CMOV, PAT, PSE36, MMX, FXSR)
- # All known features. Duplicate the common features in e1d
- e1d_base = SYSCALL & ~31
- state.known = featureset_to_uint32s(
- state.names.keys() + [ e1d_base + (x % 32) for x in common_1d ],
- nr_entries)
-
- # Fold common back into names
- for f in common_1d:
- state.names[e1d_base + (f % 32)] = "E1D_" + state.names[f]
-
+ state.known = featureset_to_uint32s(state.names.keys(), nr_entries)
state.common_1d = featureset_to_uint32s(common_1d, 1)[0]
state.special = featureset_to_uint32s(state.raw_special, nr_entries)
state.pv = featureset_to_uint32s(state.raw_pv, nr_entries)
@@ -248,13 +239,14 @@ def crunch_numbers(state):
# standard 3DNow in the earlier K6 processors.
_3DNOW: [_3DNOWEXT],
- # This is just the dependency between AVX512 and AVX2 of XSTATE feature flags.
- # If want to use AVX512, AVX2 must be supported and enabled.
+ # This is just the dependency between AVX512 and AVX2 of XSTATE
+ # feature flags. If want to use AVX512, AVX2 must be supported and
+ # enabled.
AVX2: [AVX512F],
- # AVX512F is taken to mean hardware support for EVEX encoded instructions,
- # 512bit registers, and the instructions themselves. All further AVX512 features
- # are built on top of AVX512F
+ # AVX512F is taken to mean hardware support for EVEX encoded
+ # instructions, 512bit registers, and the instructions themselves. All
+ # further AVX512 features are built on top of AVX512F
AVX512F: [AVX512DQ, AVX512IFMA, AVX512PF, AVX512ER, AVX512CD,
AVX512BW, AVX512VL, AVX512VBMI, AVX512_4VNNIW,
AVX512_4FMAPS, AVX512_VPOPCNTDQ],
@@ -305,10 +297,9 @@ def crunch_numbers(state):
if name and name[0] in "0123456789":
name = "_" + name
- # Don't generate names for the duplicate features, or ones
- # fast-forwarded from other state
- if (name.startswith("E1D_") or
- name in ("APIC", "OSXSAVE", "OSPKE")):
+ # Don't generate names for features fast-forwarded from other
+ # state
+ if name in ("APIC", "OSXSAVE", "OSPKE"):
name = ""
names.append(name.lower())
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 42+ messages in thread* [PATCH v2 04/14] x86/cpuid: Handle more simple Intel leaves in guest_cpuid()
2017-01-23 14:39 [PATCH v2 00/14] x86/cpuid: Handling of simple leaves in guest_cpuid() Andrew Cooper
` (2 preceding siblings ...)
2017-01-23 14:39 ` [PATCH v2 03/14] x86/cpuid: Only recalculate the shared feature bits once Andrew Cooper
@ 2017-01-23 14:39 ` Andrew Cooper
2017-01-24 11:20 ` Jan Beulich
2017-01-23 14:39 ` [PATCH v2 05/14] x86/cpuid: Handle leaf 0x80000001 " Andrew Cooper
` (9 subsequent siblings)
13 siblings, 1 reply; 42+ messages in thread
From: Andrew Cooper @ 2017-01-23 14:39 UTC (permalink / raw)
To: Xen-devel; +Cc: Andrew Cooper, Jan Beulich
Intel now document leaf 2 as a plain leaf, with %al always containing the
value 0x01. Collect this leaf normally in calculate_raw_policy() and expose
it to guests. The leaf is reserved by AMD.
Intel leaves 3 and 9 (PSN and DCA respectively) are not exposed to guests at
all. They are reserved by AMD.
Leaves 8 and 0xc are reserved by both vendors.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
v2:
* New
---
xen/arch/x86/cpuid.c | 32 ++++++++++++++++++++++++++------
xen/include/asm-x86/cpuid.h | 3 +++
2 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 87ec02f..7af5900 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -17,6 +17,11 @@ static const uint32_t hvm_hap_featuremask[] = INIT_HVM_HAP_FEATURES;
static const uint32_t deep_features[] = INIT_DEEP_FEATURES;
#define EMPTY_LEAF ((struct cpuid_leaf){})
+static void zero_leaves(struct cpuid_leaf *l,
+ unsigned int first, unsigned int last)
+{
+ memset(&l[first], 0, sizeof(*l) * (last - first + 1));
+}
struct cpuid_policy __read_mostly raw_policy,
__read_mostly host_policy,
@@ -153,21 +158,31 @@ static void recalculate_xstate(struct cpuid_policy *p)
/*
* Misc adjustments to the policy. Mostly clobbering reserved fields and
- * duplicating shared fields.
+ * duplicating shared fields. Intentionally hidden fields are annotated.
*/
static void recalculate_misc(struct cpuid_policy *p)
{
+ p->basic.raw[0x8] = EMPTY_LEAF;
+ p->basic.raw[0xc] = EMPTY_LEAF;
+
p->extd.e1d &= ~CPUID_COMMON_1D_FEATURES;
switch ( p->x86_vendor )
{
case X86_VENDOR_INTEL:
+ p->basic.l2_nr_queries = 1; /* Fixed to 1 query. */
+ p->basic.raw[0x3] = EMPTY_LEAF; /* PSN - always hidden. */
+ p->basic.raw[0x9] = EMPTY_LEAF; /* DCA - always hidden. */
+
p->extd.vendor_ebx = 0;
p->extd.vendor_ecx = 0;
p->extd.vendor_edx = 0;
break;
case X86_VENDOR_AMD:
+ zero_leaves(p->basic.raw, 0x2, 0x3);
+ p->basic.raw[0x9] = EMPTY_LEAF;
+
p->extd.vendor_ebx = p->basic.vendor_ebx;
p->extd.vendor_ecx = p->basic.vendor_ecx;
p->extd.vendor_edx = p->basic.vendor_edx;
@@ -188,7 +203,7 @@ static void __init calculate_raw_policy(void)
{
switch ( i )
{
- case 0x2: case 0x4: case 0x7: case 0xd:
+ case 0x4: case 0x7: case 0xd:
/* Multi-invocation leaves. Deferred. */
continue;
}
@@ -694,8 +709,9 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
break;
case 0x0:
- case 0x7:
- case XSTATE_CPUID:
+ case 0x2 ... 0x3:
+ case 0x7 ... 0x9:
+ case 0xc ... XSTATE_CPUID:
case 0x80000000:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
@@ -841,8 +857,9 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
break;
case 0x0:
- case 0x7:
- case XSTATE_CPUID:
+ case 0x2 ... 0x3:
+ case 0x7 ... 0x9:
+ case 0xc ... XSTATE_CPUID:
case 0x80000000:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
@@ -894,6 +911,9 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
goto legacy;
case 0x0:
+ case 0x2 ... 0x3:
+ case 0x8 ... 0x9:
+ case 0xc:
*res = p->basic.raw[leaf];
break;
}
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index 4712b73..a15270a 100644
--- a/xen/include/asm-x86/cpuid.h
+++ b/xen/include/asm-x86/cpuid.h
@@ -115,6 +115,9 @@ struct cpuid_policy
uint32_t _1d;
struct { DECL_BITFIELD(1d); };
};
+
+ /* Leaf 0x2 - TLB/Cache/Prefetch. */
+ uint8_t l2_nr_queries; /* Documented as fixed to 1. */
};
} basic;
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 42+ messages in thread* Re: [PATCH v2 04/14] x86/cpuid: Handle more simple Intel leaves in guest_cpuid()
2017-01-23 14:39 ` [PATCH v2 04/14] x86/cpuid: Handle more simple Intel leaves in guest_cpuid() Andrew Cooper
@ 2017-01-24 11:20 ` Jan Beulich
2017-01-24 11:35 ` Andrew Cooper
0 siblings, 1 reply; 42+ messages in thread
From: Jan Beulich @ 2017-01-24 11:20 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Xen-devel
>>> On 23.01.17 at 15:39, <andrew.cooper3@citrix.com> wrote:
> @@ -153,21 +158,31 @@ static void recalculate_xstate(struct cpuid_policy *p)
>
> /*
> * Misc adjustments to the policy. Mostly clobbering reserved fields and
> - * duplicating shared fields.
> + * duplicating shared fields. Intentionally hidden fields are annotated.
> */
> static void recalculate_misc(struct cpuid_policy *p)
> {
> + p->basic.raw[0x8] = EMPTY_LEAF;
> + p->basic.raw[0xc] = EMPTY_LEAF;
> +
> p->extd.e1d &= ~CPUID_COMMON_1D_FEATURES;
>
> switch ( p->x86_vendor )
> {
> case X86_VENDOR_INTEL:
> + p->basic.l2_nr_queries = 1; /* Fixed to 1 query. */
> + p->basic.raw[0x3] = EMPTY_LEAF; /* PSN - always hidden. */
> + p->basic.raw[0x9] = EMPTY_LEAF; /* DCA - always hidden. */
Hmm, for one this isn't very useful without also faking zero output
for the respective MSR read. And then I think this might still be
useful for pinned domains, so I'd view this as temporary state only
(same for the un-exposed CPUID bit), yet the comment makes me
assume this is intended to be permanent.
> @@ -694,8 +709,9 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
> break;
>
> case 0x0:
> - case 0x7:
> - case XSTATE_CPUID:
> + case 0x2 ... 0x3:
> + case 0x7 ... 0x9:
> + case 0xc ... XSTATE_CPUID:
I can see how using a mix of literal numbers and constants ends up
ugly here. I think we have two options: Either use only numbers,
but then preferably include the constant(s) covered in a comment.
Or only use ranges both ends of which are literal numbers.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: [PATCH v2 04/14] x86/cpuid: Handle more simple Intel leaves in guest_cpuid()
2017-01-24 11:20 ` Jan Beulich
@ 2017-01-24 11:35 ` Andrew Cooper
2017-01-24 11:44 ` Jan Beulich
0 siblings, 1 reply; 42+ messages in thread
From: Andrew Cooper @ 2017-01-24 11:35 UTC (permalink / raw)
To: Jan Beulich; +Cc: Xen-devel
On 24/01/17 11:20, Jan Beulich wrote:
>>>> On 23.01.17 at 15:39, <andrew.cooper3@citrix.com> wrote:
>> @@ -153,21 +158,31 @@ static void recalculate_xstate(struct cpuid_policy *p)
>>
>> /*
>> * Misc adjustments to the policy. Mostly clobbering reserved fields and
>> - * duplicating shared fields.
>> + * duplicating shared fields. Intentionally hidden fields are annotated.
>> */
>> static void recalculate_misc(struct cpuid_policy *p)
>> {
>> + p->basic.raw[0x8] = EMPTY_LEAF;
>> + p->basic.raw[0xc] = EMPTY_LEAF;
>> +
>> p->extd.e1d &= ~CPUID_COMMON_1D_FEATURES;
>>
>> switch ( p->x86_vendor )
>> {
>> case X86_VENDOR_INTEL:
>> + p->basic.l2_nr_queries = 1; /* Fixed to 1 query. */
>> + p->basic.raw[0x3] = EMPTY_LEAF; /* PSN - always hidden. */
>> + p->basic.raw[0x9] = EMPTY_LEAF; /* DCA - always hidden. */
> Hmm, for one this isn't very useful without also faking zero output
> for the respective MSR read. And then I think this might still be
> useful for pinned domains, so I'd view this as temporary state only
> (same for the un-exposed CPUID bit), yet the comment makes me
> assume this is intended to be permanent.
Well, thus far the toolstack has always explicitly zeroed this leaf.
From that point of view, it is no change.
The MSR side of things is a separate can of worms which is following
this cpuid work on my todo list.
As for potential exposure, it should be fine to expose to
non-migrateable domains, but I'd consider that a new feature (and far
easier to implement once the default vs max cpuid_policy infrastructure
is in place).
>
>> @@ -694,8 +709,9 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
>> break;
>>
>> case 0x0:
>> - case 0x7:
>> - case XSTATE_CPUID:
>> + case 0x2 ... 0x3:
>> + case 0x7 ... 0x9:
>> + case 0xc ... XSTATE_CPUID:
> I can see how using a mix of literal numbers and constants ends up
> ugly here. I think we have two options: Either use only numbers,
> but then preferably include the constant(s) covered in a comment.
> Or only use ranges both ends of which are literal numbers.
These lists are just temporary (and this one specifically is only to
check I don't have duplicate case statements). When the legacy path
disappears (i.e. I fill in all the holes in that numbering),
{pv,hvm}_cpuid() will disappear, and the similar list in guest_cpuid()
will be dropped and become the default case.
I don't mind them staying as they are. They won't be around for long.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: [PATCH v2 04/14] x86/cpuid: Handle more simple Intel leaves in guest_cpuid()
2017-01-24 11:35 ` Andrew Cooper
@ 2017-01-24 11:44 ` Jan Beulich
0 siblings, 0 replies; 42+ messages in thread
From: Jan Beulich @ 2017-01-24 11:44 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Xen-devel
>>> On 24.01.17 at 12:35, <andrew.cooper3@citrix.com> wrote:
> On 24/01/17 11:20, Jan Beulich wrote:
>>>>> On 23.01.17 at 15:39, <andrew.cooper3@citrix.com> wrote:
>>> @@ -153,21 +158,31 @@ static void recalculate_xstate(struct cpuid_policy *p)
>>>
>>> /*
>>> * Misc adjustments to the policy. Mostly clobbering reserved fields and
>>> - * duplicating shared fields.
>>> + * duplicating shared fields. Intentionally hidden fields are annotated.
>>> */
>>> static void recalculate_misc(struct cpuid_policy *p)
>>> {
>>> + p->basic.raw[0x8] = EMPTY_LEAF;
>>> + p->basic.raw[0xc] = EMPTY_LEAF;
>>> +
>>> p->extd.e1d &= ~CPUID_COMMON_1D_FEATURES;
>>>
>>> switch ( p->x86_vendor )
>>> {
>>> case X86_VENDOR_INTEL:
>>> + p->basic.l2_nr_queries = 1; /* Fixed to 1 query. */
>>> + p->basic.raw[0x3] = EMPTY_LEAF; /* PSN - always hidden. */
>>> + p->basic.raw[0x9] = EMPTY_LEAF; /* DCA - always hidden. */
>> Hmm, for one this isn't very useful without also faking zero output
>> for the respective MSR read. And then I think this might still be
>> useful for pinned domains, so I'd view this as temporary state only
>> (same for the un-exposed CPUID bit), yet the comment makes me
>> assume this is intended to be permanent.
>
> Well, thus far the toolstack has always explicitly zeroed this leaf.
> From that point of view, it is no change.
>
> The MSR side of things is a separate can of worms which is following
> this cpuid work on my todo list.
>
> As for potential exposure, it should be fine to expose to
> non-migrateable domains, but I'd consider that a new feature (and far
> easier to implement once the default vs max cpuid_policy infrastructure
> is in place).
>
>>
>>> @@ -694,8 +709,9 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
>>> break;
>>>
>>> case 0x0:
>>> - case 0x7:
>>> - case XSTATE_CPUID:
>>> + case 0x2 ... 0x3:
>>> + case 0x7 ... 0x9:
>>> + case 0xc ... XSTATE_CPUID:
>> I can see how using a mix of literal numbers and constants ends up
>> ugly here. I think we have two options: Either use only numbers,
>> but then preferably include the constant(s) covered in a comment.
>> Or only use ranges both ends of which are literal numbers.
>
> These lists are just temporary (and this one specifically is only to
> check I don't have duplicate case statements). When the legacy path
> disappears (i.e. I fill in all the holes in that numbering),
> {pv,hvm}_cpuid() will disappear, and the similar list in guest_cpuid()
> will be dropped and become the default case.
>
> I don't mind them staying as they are. They won't be around for long.
Okay then.
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH v2 05/14] x86/cpuid: Handle leaf 0x80000001 in guest_cpuid()
2017-01-23 14:39 [PATCH v2 00/14] x86/cpuid: Handling of simple leaves in guest_cpuid() Andrew Cooper
` (3 preceding siblings ...)
2017-01-23 14:39 ` [PATCH v2 04/14] x86/cpuid: Handle more simple Intel leaves in guest_cpuid() Andrew Cooper
@ 2017-01-23 14:39 ` Andrew Cooper
2017-01-24 11:51 ` Jan Beulich
2017-01-23 14:39 ` [PATCH v2 06/14] x86/cpuid: Handle the long vendor string " Andrew Cooper
` (8 subsequent siblings)
13 siblings, 1 reply; 42+ messages in thread
From: Andrew Cooper @ 2017-01-23 14:39 UTC (permalink / raw)
To: Xen-devel; +Cc: Andrew Cooper, Jan Beulich
Intel reserve eax and ebx, while AMD duplicates eax from the low
family/model/stepping leaf. For AMD, ebx contains further brand/package
information which is left as the toolstack chooses (other than bits 27:16
which are reserved).
While moving the dynamic adjustments from the legacy path, simplify the shadow
PSE36 adjustment. PAE paging is a prerequisite for enabling long mode, making
the long mode check redundant; the case where it doesn't get short circuited
is the case where it is architecturally 0. Make the same adjustment to the
leaf 1 legacy path.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
v2:
* New
---
xen/arch/x86/cpuid.c | 107 ++++++++++++++++++++++----------------------
xen/include/asm-x86/cpuid.h | 2 +-
2 files changed, 55 insertions(+), 54 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 7af5900..c06b5a6 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -177,6 +177,8 @@ static void recalculate_misc(struct cpuid_policy *p)
p->extd.vendor_ebx = 0;
p->extd.vendor_ecx = 0;
p->extd.vendor_edx = 0;
+
+ p->extd.raw[0x1].a = p->extd.raw[0x1].b = 0;
break;
case X86_VENDOR_AMD:
@@ -187,6 +189,8 @@ static void recalculate_misc(struct cpuid_policy *p)
p->extd.vendor_ecx = p->basic.vendor_ecx;
p->extd.vendor_edx = p->basic.vendor_edx;
+ p->extd.raw_fms = p->basic.raw_fms;
+ p->extd.raw[0x1].b &= 0xff00ffff;
p->extd.e1d |= p->basic._1d & CPUID_COMMON_1D_FEATURES;
break;
}
@@ -672,24 +676,6 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
res->a = (res->a & ~0xff) | 3;
break;
- case 0x80000001:
- res->c = p->extd.e1c;
- res->d = p->extd.e1d;
-
- /*
- * MTRR used to unconditionally leak into PV guests. They cannot MTRR
- * infrastructure at all, and shouldn't be able to see the feature.
- *
- * Modern PVOPS Linux self-clobbers the MTRR feature, to avoid trying
- * to use the associated MSRs. Xenolinux-based PV dom0's however use
- * the MTRR feature as an indication of the presence of the
- * XENPF_{add,del,read}_memtype hypercalls.
- */
- if ( is_hardware_domain(currd) && cpu_has_mtrr &&
- guest_kernel_mode(curr, guest_cpu_user_regs()) )
- res->d |= cpufeat_mask(X86_FEATURE_MTRR);
- break;
-
case 0x80000007:
res->d = p->extd.e7d;
break;
@@ -712,7 +698,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
- case 0x80000000:
+ case 0x80000000 ... 0x80000001:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -760,7 +746,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
* a 32bit guest doesn't get the impression that it could try to use
* PSE36 paging.
*/
- if ( !hap_enabled(d) && !(hvm_pae_enabled(v) || hvm_long_mode_enabled(v)) )
+ if ( !hap_enabled(d) && !hvm_pae_enabled(v) )
res->d &= ~cpufeat_mask(X86_FEATURE_PSE36);
if ( vpmu_enabled(v) &&
@@ -792,37 +778,6 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
res->a = (res->a & ~0xff) | 3;
break;
- case 0x80000001:
- res->c = p->extd.e1c;
- res->d = p->extd.e1d;
-
- /* fast-forward MSR_APIC_BASE.EN if it hasn't already been clobbered. */
- if ( vlapic_hw_disabled(vcpu_vlapic(v)) )
- res->d &= ~cpufeat_bit(X86_FEATURE_APIC);
-
- /*
- * PSE36 is not supported in shadow mode. This bit should be
- * unilaterally cleared.
- *
- * However, an unspecified version of Hyper-V from 2011 refuses
- * to start as the "cpu does not provide required hw features" if
- * it can't see PSE36.
- *
- * As a workaround, leak the toolstack-provided PSE36 value into a
- * shadow guest if the guest is already using PAE paging (and won't
- * care about reverting back to PSE paging). Otherwise, knoble it, so
- * a 32bit guest doesn't get the impression that it could try to use
- * PSE36 paging.
- */
- if ( !hap_enabled(d) && !(hvm_pae_enabled(v) || hvm_long_mode_enabled(v)) )
- res->d &= ~cpufeat_mask(X86_FEATURE_PSE36);
-
- /* SYSCALL is hidden outside of long mode on Intel. */
- if ( p->x86_vendor == X86_VENDOR_INTEL && !hvm_long_mode_enabled(v) )
- res->d &= ~cpufeat_mask(X86_FEATURE_SYSCALL);
-
- break;
-
case 0x80000007:
res->d = p->extd.e7d;
break;
@@ -860,7 +815,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
- case 0x80000000:
+ case 0x80000000 ... 0x80000001:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -943,7 +898,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
default:
goto legacy;
- case 0x80000000:
+ case 0x80000000 ... 0x80000001:
*res = p->extd.raw[leaf & 0xffff];
break;
}
@@ -1007,6 +962,52 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
break;
}
break;
+
+ case 0x80000001:
+ if ( has_hvm_container_domain(d) )
+ {
+ /* Fast-forward MSR_APIC_BASE.EN. */
+ if ( vlapic_hw_disabled(vcpu_vlapic(v)) )
+ res->d &= ~cpufeat_bit(X86_FEATURE_APIC);
+
+ /*
+ * PSE36 is not supported in shadow mode. This bit should be
+ * clear in hvm_shadow_featuremask[].
+ *
+ * However, an unspecified version of Hyper-V from 2011 refuses to
+ * start as the "cpu does not provide required hw features" if it
+ * can't see PSE36.
+ *
+ * As a workaround, leak the toolstack-provided PSE36 value into a
+ * shadow guest if the guest is already using PAE paging (and
+ * won't care about reverting back to PSE paging). Otherwise,
+ * knoble it, so a 32bit guest doesn't get the impression that it
+ * could try to use PSE36 paging.
+ */
+ if ( !hap_enabled(d) && !hvm_pae_enabled(v) )
+ res->d &= ~cpufeat_mask(X86_FEATURE_PSE36);
+
+ /* SYSCALL is hidden outside of long mode on Intel. */
+ if ( p->x86_vendor == X86_VENDOR_INTEL && !hvm_long_mode_enabled(v) )
+ res->d &= ~cpufeat_mask(X86_FEATURE_SYSCALL);
+ }
+ else /* PV domain */
+ {
+ /*
+ * MTRR used to unconditionally leak into PV guests. They cannot
+ * MTRR infrastructure at all, and shouldn't be able to see the
+ * feature.
+ *
+ * Modern PVOPS Linux self-clobbers the MTRR feature, to avoid
+ * trying to use the associated MSRs. Xenolinux-based PV dom0's
+ * however use the MTRR feature as an indication of the presence
+ * of the XENPF_{add,del,read}_memtype hypercalls.
+ */
+ if ( is_hardware_domain(d) && cpu_has_mtrr &&
+ guest_kernel_mode(v, guest_cpu_user_regs()) )
+ res->d |= cpufeat_mask(X86_FEATURE_MTRR);
+ }
+ break;
}
/* Done. */
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index a15270a..be76ed4 100644
--- a/xen/include/asm-x86/cpuid.h
+++ b/xen/include/asm-x86/cpuid.h
@@ -174,7 +174,7 @@ struct cpuid_policy
uint32_t max_leaf, vendor_ebx, vendor_ecx, vendor_edx;
/* Leaf 0x80000001 - Family/model/stepping and features. */
- uint32_t /* a */:32, /* b */:32;
+ uint32_t raw_fms, /* b */:32;
union {
uint32_t e1c;
struct { DECL_BITFIELD(e1c); };
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 42+ messages in thread* Re: [PATCH v2 05/14] x86/cpuid: Handle leaf 0x80000001 in guest_cpuid()
2017-01-23 14:39 ` [PATCH v2 05/14] x86/cpuid: Handle leaf 0x80000001 " Andrew Cooper
@ 2017-01-24 11:51 ` Jan Beulich
0 siblings, 0 replies; 42+ messages in thread
From: Jan Beulich @ 2017-01-24 11:51 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Xen-devel
>>> On 23.01.17 at 15:39, <andrew.cooper3@citrix.com> wrote:
> Intel reserve eax and ebx, while AMD duplicates eax from the low
> family/model/stepping leaf. For AMD, ebx contains further brand/package
> information which is left as the toolstack chooses (other than bits 27:16
> which are reserved).
>
> While moving the dynamic adjustments from the legacy path, simplify the shadow
> PSE36 adjustment. PAE paging is a prerequisite for enabling long mode, making
> the long mode check redundant; the case where it doesn't get short circuited
> is the case where it is architecturally 0. Make the same adjustment to the
> leaf 1 legacy path.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH v2 06/14] x86/cpuid: Handle the long vendor string in guest_cpuid()
2017-01-23 14:39 [PATCH v2 00/14] x86/cpuid: Handling of simple leaves in guest_cpuid() Andrew Cooper
` (4 preceding siblings ...)
2017-01-23 14:39 ` [PATCH v2 05/14] x86/cpuid: Handle leaf 0x80000001 " Andrew Cooper
@ 2017-01-23 14:39 ` Andrew Cooper
2017-01-23 14:39 ` [PATCH v2 07/14] x86/cpuid: Handle leaves 0x80000005-7 " Andrew Cooper
` (7 subsequent siblings)
13 siblings, 0 replies; 42+ messages in thread
From: Andrew Cooper @ 2017-01-23 14:39 UTC (permalink / raw)
To: Xen-devel; +Cc: Andrew Cooper
Leaves 0x80000002 through 0x80000004 are plain ASCII text, and are left
exactly as the toolstack chooses.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
v2:
* Rebased, but no significant changes
---
xen/arch/x86/cpuid.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index c06b5a6..9cea13c 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -698,7 +698,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
- case 0x80000000 ... 0x80000001:
+ case 0x80000000 ... 0x80000004:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -815,7 +815,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
- case 0x80000000 ... 0x80000001:
+ case 0x80000000 ... 0x80000004:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -898,7 +898,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
default:
goto legacy;
- case 0x80000000 ... 0x80000001:
+ case 0x80000000 ... 0x80000004:
*res = p->extd.raw[leaf & 0xffff];
break;
}
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 42+ messages in thread* [PATCH v2 07/14] x86/cpuid: Handle leaves 0x80000005-7 in guest_cpuid()
2017-01-23 14:39 [PATCH v2 00/14] x86/cpuid: Handling of simple leaves in guest_cpuid() Andrew Cooper
` (5 preceding siblings ...)
2017-01-23 14:39 ` [PATCH v2 06/14] x86/cpuid: Handle the long vendor string " Andrew Cooper
@ 2017-01-23 14:39 ` Andrew Cooper
2017-01-24 11:59 ` Jan Beulich
2017-01-23 14:39 ` [PATCH v2 08/14] x86/cpuid: Handle leaf 0x80000008 " Andrew Cooper
` (6 subsequent siblings)
13 siblings, 1 reply; 42+ messages in thread
From: Andrew Cooper @ 2017-01-23 14:39 UTC (permalink / raw)
To: Xen-devel; +Cc: Andrew Cooper, Jan Beulich
Leaf 0x80000005 contains L1 cache/TLB information, 0x80000006 L2 & L3
cache/TLB information, and 0x80000007 Power management information.
Intel reserves all of this information other than the L2 cache information,
and the ITSC bit from the power management leaf.
AMD passes all of the cache/TLB information through to the guest, while most
of of the power management information is explicitly clobbered by the
toolstack.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
v2:
* New
---
xen/arch/x86/cpuid.c | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 9cea13c..3338045 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -167,6 +167,9 @@ static void recalculate_misc(struct cpuid_policy *p)
p->extd.e1d &= ~CPUID_COMMON_1D_FEATURES;
+ /* Most of Power/RAS hidden from guests. */
+ p->extd.raw[0x7].a = p->extd.raw[0x7].b = p->extd.raw[0x7].c = 0;
+
switch ( p->x86_vendor )
{
case X86_VENDOR_INTEL:
@@ -179,6 +182,9 @@ static void recalculate_misc(struct cpuid_policy *p)
p->extd.vendor_edx = 0;
p->extd.raw[0x1].a = p->extd.raw[0x1].b = 0;
+
+ p->extd.raw[0x5] = EMPTY_LEAF;
+ p->extd.raw[0x6].a = p->extd.raw[0x6].b = p->extd.raw[0x6].d = 0;
break;
case X86_VENDOR_AMD:
@@ -676,10 +682,6 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
res->a = (res->a & ~0xff) | 3;
break;
- case 0x80000007:
- res->d = p->extd.e7d;
- break;
-
case 0x80000008:
res->a = paddr_bits | (vaddr_bits << 8);
res->b = p->extd.e8b;
@@ -698,7 +700,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
- case 0x80000000 ... 0x80000004:
+ case 0x80000000 ... 0x80000007:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -778,10 +780,6 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
res->a = (res->a & ~0xff) | 3;
break;
- case 0x80000007:
- res->d = p->extd.e7d;
- break;
-
case 0x80000008:
res->a &= 0xff;
tmp = d->arch.paging.gfn_bits + PAGE_SHIFT;
@@ -815,7 +813,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
- case 0x80000000 ... 0x80000004:
+ case 0x80000000 ... 0x80000007:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -898,7 +896,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
default:
goto legacy;
- case 0x80000000 ... 0x80000004:
+ case 0x80000000 ... 0x80000007:
*res = p->extd.raw[leaf & 0xffff];
break;
}
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 42+ messages in thread* Re: [PATCH v2 07/14] x86/cpuid: Handle leaves 0x80000005-7 in guest_cpuid()
2017-01-23 14:39 ` [PATCH v2 07/14] x86/cpuid: Handle leaves 0x80000005-7 " Andrew Cooper
@ 2017-01-24 11:59 ` Jan Beulich
2017-01-24 14:48 ` Andrew Cooper
0 siblings, 1 reply; 42+ messages in thread
From: Jan Beulich @ 2017-01-24 11:59 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Xen-devel
>>> On 23.01.17 at 15:39, <andrew.cooper3@citrix.com> wrote:
> Intel reserves all of this information other than the L2 cache information,
> and the ITSC bit from the power management leaf.
>
> AMD passes all of the cache/TLB information through to the guest, while most
> of of the power management information is explicitly clobbered by the
> toolstack.
Both of these look to not be fully in line with ...
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -167,6 +167,9 @@ static void recalculate_misc(struct cpuid_policy *p)
>
> p->extd.e1d &= ~CPUID_COMMON_1D_FEATURES;
>
> + /* Most of Power/RAS hidden from guests. */
> + p->extd.raw[0x7].a = p->extd.raw[0x7].b = p->extd.raw[0x7].c = 0;
... you leaving .d completely untouched. Can you clarify this please?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 07/14] x86/cpuid: Handle leaves 0x80000005-7 in guest_cpuid()
2017-01-24 11:59 ` Jan Beulich
@ 2017-01-24 14:48 ` Andrew Cooper
2017-01-24 15:05 ` Jan Beulich
0 siblings, 1 reply; 42+ messages in thread
From: Andrew Cooper @ 2017-01-24 14:48 UTC (permalink / raw)
To: Jan Beulich; +Cc: Xen-devel
On 24/01/17 11:59, Jan Beulich wrote:
>>>> On 23.01.17 at 15:39, <andrew.cooper3@citrix.com> wrote:
>> Intel reserves all of this information other than the L2 cache information,
>> and the ITSC bit from the power management leaf.
>>
>> AMD passes all of the cache/TLB information through to the guest, while most
>> of of the power management information is explicitly clobbered by the
>> toolstack.
> Both of these look to not be fully in line with ...
>
>> --- a/xen/arch/x86/cpuid.c
>> +++ b/xen/arch/x86/cpuid.c
>> @@ -167,6 +167,9 @@ static void recalculate_misc(struct cpuid_policy *p)
>>
>> p->extd.e1d &= ~CPUID_COMMON_1D_FEATURES;
>>
>> + /* Most of Power/RAS hidden from guests. */
>> + p->extd.raw[0x7].a = p->extd.raw[0x7].b = p->extd.raw[0x7].c = 0;
> ... you leaving .d completely untouched. Can you clarify this please?
e7d is covered by the featureset bitmap, because it contains the ITSC
feature.
It is therefore covered by the main body of recalculate_domain_policy().
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 07/14] x86/cpuid: Handle leaves 0x80000005-7 in guest_cpuid()
2017-01-24 14:48 ` Andrew Cooper
@ 2017-01-24 15:05 ` Jan Beulich
2017-01-24 15:32 ` Andrew Cooper
0 siblings, 1 reply; 42+ messages in thread
From: Jan Beulich @ 2017-01-24 15:05 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Xen-devel
>>> On 24.01.17 at 15:48, <andrew.cooper3@citrix.com> wrote:
> On 24/01/17 11:59, Jan Beulich wrote:
>>>>> On 23.01.17 at 15:39, <andrew.cooper3@citrix.com> wrote:
>>> Intel reserves all of this information other than the L2 cache information,
>>> and the ITSC bit from the power management leaf.
>>>
>>> AMD passes all of the cache/TLB information through to the guest, while most
>>> of of the power management information is explicitly clobbered by the
>>> toolstack.
>> Both of these look to not be fully in line with ...
>>
>>> --- a/xen/arch/x86/cpuid.c
>>> +++ b/xen/arch/x86/cpuid.c
>>> @@ -167,6 +167,9 @@ static void recalculate_misc(struct cpuid_policy *p)
>>>
>>> p->extd.e1d &= ~CPUID_COMMON_1D_FEATURES;
>>>
>>> + /* Most of Power/RAS hidden from guests. */
>>> + p->extd.raw[0x7].a = p->extd.raw[0x7].b = p->extd.raw[0x7].c = 0;
>> ... you leaving .d completely untouched. Can you clarify this please?
>
> e7d is covered by the featureset bitmap, because it contains the ITSC
> feature.
>
> It is therefore covered by the main body of recalculate_domain_policy().
Oh, of course.
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 07/14] x86/cpuid: Handle leaves 0x80000005-7 in guest_cpuid()
2017-01-24 15:05 ` Jan Beulich
@ 2017-01-24 15:32 ` Andrew Cooper
0 siblings, 0 replies; 42+ messages in thread
From: Andrew Cooper @ 2017-01-24 15:32 UTC (permalink / raw)
To: Jan Beulich; +Cc: Xen-devel
On 24/01/17 15:05, Jan Beulich wrote:
>>>> On 24.01.17 at 15:48, <andrew.cooper3@citrix.com> wrote:
>> On 24/01/17 11:59, Jan Beulich wrote:
>>>>>> On 23.01.17 at 15:39, <andrew.cooper3@citrix.com> wrote:
>>>> Intel reserves all of this information other than the L2 cache information,
>>>> and the ITSC bit from the power management leaf.
>>>>
>>>> AMD passes all of the cache/TLB information through to the guest, while most
>>>> of of the power management information is explicitly clobbered by the
>>>> toolstack.
>>> Both of these look to not be fully in line with ...
>>>
>>>> --- a/xen/arch/x86/cpuid.c
>>>> +++ b/xen/arch/x86/cpuid.c
>>>> @@ -167,6 +167,9 @@ static void recalculate_misc(struct cpuid_policy *p)
>>>>
>>>> p->extd.e1d &= ~CPUID_COMMON_1D_FEATURES;
>>>>
>>>> + /* Most of Power/RAS hidden from guests. */
>>>> + p->extd.raw[0x7].a = p->extd.raw[0x7].b = p->extd.raw[0x7].c = 0;
>>> ... you leaving .d completely untouched. Can you clarify this please?
>> e7d is covered by the featureset bitmap, because it contains the ITSC
>> feature.
>>
>> It is therefore covered by the main body of recalculate_domain_policy().
> Oh, of course.
>
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Thanks. I will tweak the commit message to make this clearer.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH v2 08/14] x86/cpuid: Handle leaf 0x80000008 in guest_cpuid()
2017-01-23 14:39 [PATCH v2 00/14] x86/cpuid: Handling of simple leaves in guest_cpuid() Andrew Cooper
` (6 preceding siblings ...)
2017-01-23 14:39 ` [PATCH v2 07/14] x86/cpuid: Handle leaves 0x80000005-7 " Andrew Cooper
@ 2017-01-23 14:39 ` Andrew Cooper
2017-01-24 12:16 ` Jan Beulich
2017-01-24 16:30 ` [PATCH v3 " Andrew Cooper
2017-01-23 14:39 ` [PATCH v2 09/14] x86/cpuid: Handle leaf 0x80000009 " Andrew Cooper
` (5 subsequent siblings)
13 siblings, 2 replies; 42+ messages in thread
From: Andrew Cooper @ 2017-01-23 14:39 UTC (permalink / raw)
To: Xen-devel; +Cc: Andrew Cooper, Jan Beulich
The entirety of edx is reserved.
Intel only defines the lower 16 bits of eax, although ebx is covered by the
featureset ABI, so left unclobbered.
AMD uses 24 bits in eax, although nothing thus far has ever exposed a non-zero
guest maxphysaddr to HVM guests. ecx contains some reserved bits, and several
pieces of static topology information, which are left as the toolstack
chooses.
A side effect of the common recalculation of maxlinaddr is that 32bit PV
guests see a maximum linear address of 32, which is consistent with the hiding
of other long mode information from them.
Finally, the call to guest_cpuid() in mtrr_var_range_msr_set() (introduced in
c/s fff8160a) can be dropped, now that maxphysaddr can be read straight out of
the cpuid_policy block.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
v2:
* New
---
xen/arch/x86/cpuid.c | 45 ++++++++++++++++++++-------------------------
xen/arch/x86/hvm/mtrr.c | 7 +------
xen/include/asm-x86/cpuid.h | 2 +-
3 files changed, 22 insertions(+), 32 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 3338045..4d48552 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -170,6 +170,8 @@ static void recalculate_misc(struct cpuid_policy *p)
/* Most of Power/RAS hidden from guests. */
p->extd.raw[0x7].a = p->extd.raw[0x7].b = p->extd.raw[0x7].c = 0;
+ p->extd.raw[0x8].d = 0;
+
switch ( p->x86_vendor )
{
case X86_VENDOR_INTEL:
@@ -185,6 +187,9 @@ static void recalculate_misc(struct cpuid_policy *p)
p->extd.raw[0x5] = EMPTY_LEAF;
p->extd.raw[0x6].a = p->extd.raw[0x6].b = p->extd.raw[0x6].d = 0;
+
+ p->extd.raw[0x8].a &= 0x0000ffff;
+ p->extd.raw[0x8].c = 0;
break;
case X86_VENDOR_AMD:
@@ -198,6 +203,9 @@ static void recalculate_misc(struct cpuid_policy *p)
p->extd.raw_fms = p->basic.raw_fms;
p->extd.raw[0x1].b &= 0xff00ffff;
p->extd.e1d |= p->basic._1d & CPUID_COMMON_1D_FEATURES;
+
+ p->extd.raw[0x8].a &= 0x00ffffff;
+ p->extd.raw[0x8].c &= 0x0003f0ff;
break;
}
}
@@ -469,6 +477,15 @@ void recalculate_cpuid_policy(struct domain *d)
special_features[FEATURESET_7b0]);
cpuid_featureset_to_policy(fs, p);
+
+ p->extd.maxphysaddr = min(p->extd.maxphysaddr, max->extd.maxphysaddr);
+ p->extd.maxphysaddr = min_t(uint8_t, p->extd.maxphysaddr,
+ d->arch.paging.gfn_bits + PAGE_SHIFT);
+ p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr,
+ (p->basic.pae || p->basic.pse36) ? 36 : 32);
+
+ p->extd.maxlinaddr = p->extd.lm ? 48 : 32;
+
recalculate_xstate(p);
recalculate_misc(p);
}
@@ -682,11 +699,6 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
res->a = (res->a & ~0xff) | 3;
break;
- case 0x80000008:
- res->a = paddr_bits | (vaddr_bits << 8);
- res->b = p->extd.e8b;
- break;
-
case 0x00000005: /* MONITOR/MWAIT */
case 0x0000000b: /* Extended Topology Enumeration */
case 0x8000000a: /* SVM revision and features */
@@ -700,7 +712,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
- case 0x80000000 ... 0x80000007:
+ case 0x80000000 ... 0x80000008:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -716,8 +728,6 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
switch ( leaf )
{
- unsigned int tmp;
-
case 0x1:
/* Fix up VLAPIC details. */
res->b &= 0x00FFFFFFu;
@@ -780,21 +790,6 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
res->a = (res->a & ~0xff) | 3;
break;
- case 0x80000008:
- res->a &= 0xff;
- tmp = d->arch.paging.gfn_bits + PAGE_SHIFT;
- if ( res->a > tmp )
- res->a = tmp;
-
- tmp = (p->basic.pae || p->basic.pse36) ? 36 : 32;
- if ( res->a < tmp )
- res->a = tmp;
-
- res->a |= (p->extd.lm ? vaddr_bits : 32) << 8;
-
- res->b = p->extd.e8b;
- break;
-
case 0x8000001c:
if ( !cpu_has_svm )
{
@@ -813,7 +808,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
- case 0x80000000 ... 0x80000007:
+ case 0x80000000 ... 0x80000008:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -896,7 +891,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
default:
goto legacy;
- case 0x80000000 ... 0x80000007:
+ case 0x80000000 ... 0x80000008:
*res = p->extd.raw[leaf & 0xffff];
break;
}
diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index 709759c..9ea1fdc 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -452,12 +452,7 @@ bool_t mtrr_var_range_msr_set(
return 0;
if ( d == current->domain )
- {
- struct cpuid_leaf res;
-
- guest_cpuid(current, 0x80000008, 0, &res);
- phys_addr = (uint8_t)res.a ?: 36;
- }
+ phys_addr = d->arch.cpuid->extd.maxphysaddr;
else
phys_addr = paddr_bits;
msr_mask = ~((((uint64_t)1) << phys_addr) - 1);
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index be76ed4..6cc23aa 100644
--- a/xen/include/asm-x86/cpuid.h
+++ b/xen/include/asm-x86/cpuid.h
@@ -198,7 +198,7 @@ struct cpuid_policy
};
/* Leaf 0x80000008 - Misc addr/feature info. */
- uint32_t /* a */:32;
+ uint8_t maxphysaddr, maxlinaddr, :8, :8;
union {
uint32_t e8b;
struct { DECL_BITFIELD(e8b); };
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 42+ messages in thread* Re: [PATCH v2 08/14] x86/cpuid: Handle leaf 0x80000008 in guest_cpuid()
2017-01-23 14:39 ` [PATCH v2 08/14] x86/cpuid: Handle leaf 0x80000008 " Andrew Cooper
@ 2017-01-24 12:16 ` Jan Beulich
2017-01-24 15:31 ` Andrew Cooper
2017-01-24 16:30 ` [PATCH v3 " Andrew Cooper
1 sibling, 1 reply; 42+ messages in thread
From: Jan Beulich @ 2017-01-24 12:16 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Xen-devel
>>> On 23.01.17 at 15:39, <andrew.cooper3@citrix.com> wrote:
> AMD uses 24 bits in eax, although nothing thus far has ever exposed a non-zero
> guest maxphysaddr to HVM guests.
I think exposing bits 16...23 should be limited to guests with nested
virt enabled, and should also be subject to bounds checking just
like is done for maxphysaddr.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 08/14] x86/cpuid: Handle leaf 0x80000008 in guest_cpuid()
2017-01-24 12:16 ` Jan Beulich
@ 2017-01-24 15:31 ` Andrew Cooper
2017-01-24 15:50 ` Jan Beulich
0 siblings, 1 reply; 42+ messages in thread
From: Andrew Cooper @ 2017-01-24 15:31 UTC (permalink / raw)
To: Jan Beulich; +Cc: Xen-devel
On 24/01/17 12:16, Jan Beulich wrote:
>>>> On 23.01.17 at 15:39, <andrew.cooper3@citrix.com> wrote:
>> AMD uses 24 bits in eax, although nothing thus far has ever exposed a non-zero
>> guest maxphysaddr to HVM guests.
> I think exposing bits 16...23 should be limited to guests with nested
> virt enabled, and should also be subject to bounds checking just
> like is done for maxphysaddr.
I am not actually sure what the purpose of this field is. It is zero
when read by Xen, even on HAP-capable processors, and the AMD manuals
make no reference to it. (The CPUID section refers to the entirety of
the SVM section, but the field isn't actually mentioned anywhere, even
in the nested paging subsection.)
I think it is intended to be filled in by the hypervisor for hap guests,
but I can't think of a situation where it would be useful to tell a
guest its HAP maxphysaddr differently to regular maxphysaddr.
Furthermore the field is explicitly documented as "if 0, refer to plain
maxphysaddr". At the moment, nothing ever fill in a value other than 0.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 08/14] x86/cpuid: Handle leaf 0x80000008 in guest_cpuid()
2017-01-24 15:31 ` Andrew Cooper
@ 2017-01-24 15:50 ` Jan Beulich
2017-01-24 15:58 ` Andrew Cooper
0 siblings, 1 reply; 42+ messages in thread
From: Jan Beulich @ 2017-01-24 15:50 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Xen-devel
>>> On 24.01.17 at 16:31, <andrew.cooper3@citrix.com> wrote:
> On 24/01/17 12:16, Jan Beulich wrote:
>>>>> On 23.01.17 at 15:39, <andrew.cooper3@citrix.com> wrote:
>>> AMD uses 24 bits in eax, although nothing thus far has ever exposed a
> non-zero
>>> guest maxphysaddr to HVM guests.
>> I think exposing bits 16...23 should be limited to guests with nested
>> virt enabled, and should also be subject to bounds checking just
>> like is done for maxphysaddr.
>
> I am not actually sure what the purpose of this field is. It is zero
> when read by Xen, even on HAP-capable processors, and the AMD manuals
> make no reference to it. (The CPUID section refers to the entirety of
> the SVM section, but the field isn't actually mentioned anywhere, even
> in the nested paging subsection.)
Very helpful indeed.
> I think it is intended to be filled in by the hypervisor for hap guests,
> but I can't think of a situation where it would be useful to tell a
> guest its HAP maxphysaddr differently to regular maxphysaddr.
>
> Furthermore the field is explicitly documented as "if 0, refer to plain
> maxphysaddr". At the moment, nothing ever fill in a value other than 0.
Considering all this, wouldn't we be better off not handing the
field through to guests (i.e. reducing the mask to 0x0000ffff) until
we understand its semantics?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 08/14] x86/cpuid: Handle leaf 0x80000008 in guest_cpuid()
2017-01-24 15:50 ` Jan Beulich
@ 2017-01-24 15:58 ` Andrew Cooper
0 siblings, 0 replies; 42+ messages in thread
From: Andrew Cooper @ 2017-01-24 15:58 UTC (permalink / raw)
To: Jan Beulich; +Cc: Xen-devel
On 24/01/17 15:50, Jan Beulich wrote:
>>>> On 24.01.17 at 16:31, <andrew.cooper3@citrix.com> wrote:
>> On 24/01/17 12:16, Jan Beulich wrote:
>>>>>> On 23.01.17 at 15:39, <andrew.cooper3@citrix.com> wrote:
>>>> AMD uses 24 bits in eax, although nothing thus far has ever exposed a
>> non-zero
>>>> guest maxphysaddr to HVM guests.
>>> I think exposing bits 16...23 should be limited to guests with nested
>>> virt enabled, and should also be subject to bounds checking just
>>> like is done for maxphysaddr.
>> I am not actually sure what the purpose of this field is. It is zero
>> when read by Xen, even on HAP-capable processors, and the AMD manuals
>> make no reference to it. (The CPUID section refers to the entirety of
>> the SVM section, but the field isn't actually mentioned anywhere, even
>> in the nested paging subsection.)
> Very helpful indeed.
>
>> I think it is intended to be filled in by the hypervisor for hap guests,
>> but I can't think of a situation where it would be useful to tell a
>> guest its HAP maxphysaddr differently to regular maxphysaddr.
>>
>> Furthermore the field is explicitly documented as "if 0, refer to plain
>> maxphysaddr". At the moment, nothing ever fill in a value other than 0.
> Considering all this, wouldn't we be better off not handing the
> field through to guests (i.e. reducing the mask to 0x0000ffff) until
> we understand its semantics?
Yes. (I'd already started doing this.)
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH v3 08/14] x86/cpuid: Handle leaf 0x80000008 in guest_cpuid()
2017-01-23 14:39 ` [PATCH v2 08/14] x86/cpuid: Handle leaf 0x80000008 " Andrew Cooper
2017-01-24 12:16 ` Jan Beulich
@ 2017-01-24 16:30 ` Andrew Cooper
2017-01-25 9:22 ` Jan Beulich
1 sibling, 1 reply; 42+ messages in thread
From: Andrew Cooper @ 2017-01-24 16:30 UTC (permalink / raw)
To: Xen-devel; +Cc: Andrew Cooper, Jan Beulich
The entirety of edx is reserved.
Intel only defines the lower 16 bits of eax, although ebx is covered by the
featureset ABI, so left unclobbered.
AMD uses 24 bits in eax, although nothing thus far has ever exposed a non-zero
guest maxphysaddr to HVM guests. Its semantics are not clearly expressed, so
it is explicitly clobbered. ecx contains some reserved bits, and several
pieces of static topology information, which are left as the toolstack
chooses.
A side effect of the common recalculation of maxlinaddr is that 32bit PV
guests see a maximum linear address of 32, which is consistent with the hiding
of other long mode information from them.
Finally, the call to guest_cpuid() in mtrr_var_range_msr_set() (introduced in
c/s fff8160a) can be dropped, now that maxphysaddr can be read straight out of
the cpuid_policy block.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
v2:
* New
v3:
* Clobber GuestMaxPhysAddr until its semantics are understood.
---
xen/arch/x86/cpuid.c | 45 ++++++++++++++++++++-------------------------
xen/arch/x86/hvm/mtrr.c | 7 +------
xen/include/asm-x86/cpuid.h | 2 +-
3 files changed, 22 insertions(+), 32 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 3338045..b806cc5 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -170,6 +170,8 @@ static void recalculate_misc(struct cpuid_policy *p)
/* Most of Power/RAS hidden from guests. */
p->extd.raw[0x7].a = p->extd.raw[0x7].b = p->extd.raw[0x7].c = 0;
+ p->extd.raw[0x8].d = 0;
+
switch ( p->x86_vendor )
{
case X86_VENDOR_INTEL:
@@ -185,6 +187,9 @@ static void recalculate_misc(struct cpuid_policy *p)
p->extd.raw[0x5] = EMPTY_LEAF;
p->extd.raw[0x6].a = p->extd.raw[0x6].b = p->extd.raw[0x6].d = 0;
+
+ p->extd.raw[0x8].a &= 0x0000ffff;
+ p->extd.raw[0x8].c = 0;
break;
case X86_VENDOR_AMD:
@@ -198,6 +203,9 @@ static void recalculate_misc(struct cpuid_policy *p)
p->extd.raw_fms = p->basic.raw_fms;
p->extd.raw[0x1].b &= 0xff00ffff;
p->extd.e1d |= p->basic._1d & CPUID_COMMON_1D_FEATURES;
+
+ p->extd.raw[0x8].a &= 0x0000ffff; /* GuestMaxPhysAddr hidden. */
+ p->extd.raw[0x8].c &= 0x0003f0ff;
break;
}
}
@@ -469,6 +477,15 @@ void recalculate_cpuid_policy(struct domain *d)
special_features[FEATURESET_7b0]);
cpuid_featureset_to_policy(fs, p);
+
+ p->extd.maxphysaddr = min(p->extd.maxphysaddr, max->extd.maxphysaddr);
+ p->extd.maxphysaddr = min_t(uint8_t, p->extd.maxphysaddr,
+ d->arch.paging.gfn_bits + PAGE_SHIFT);
+ p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr,
+ (p->basic.pae || p->basic.pse36) ? 36 : 32);
+
+ p->extd.maxlinaddr = p->extd.lm ? 48 : 32;
+
recalculate_xstate(p);
recalculate_misc(p);
}
@@ -682,11 +699,6 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
res->a = (res->a & ~0xff) | 3;
break;
- case 0x80000008:
- res->a = paddr_bits | (vaddr_bits << 8);
- res->b = p->extd.e8b;
- break;
-
case 0x00000005: /* MONITOR/MWAIT */
case 0x0000000b: /* Extended Topology Enumeration */
case 0x8000000a: /* SVM revision and features */
@@ -700,7 +712,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
- case 0x80000000 ... 0x80000007:
+ case 0x80000000 ... 0x80000008:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -716,8 +728,6 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
switch ( leaf )
{
- unsigned int tmp;
-
case 0x1:
/* Fix up VLAPIC details. */
res->b &= 0x00FFFFFFu;
@@ -780,21 +790,6 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
res->a = (res->a & ~0xff) | 3;
break;
- case 0x80000008:
- res->a &= 0xff;
- tmp = d->arch.paging.gfn_bits + PAGE_SHIFT;
- if ( res->a > tmp )
- res->a = tmp;
-
- tmp = (p->basic.pae || p->basic.pse36) ? 36 : 32;
- if ( res->a < tmp )
- res->a = tmp;
-
- res->a |= (p->extd.lm ? vaddr_bits : 32) << 8;
-
- res->b = p->extd.e8b;
- break;
-
case 0x8000001c:
if ( !cpu_has_svm )
{
@@ -813,7 +808,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
- case 0x80000000 ... 0x80000007:
+ case 0x80000000 ... 0x80000008:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -896,7 +891,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
default:
goto legacy;
- case 0x80000000 ... 0x80000007:
+ case 0x80000000 ... 0x80000008:
*res = p->extd.raw[leaf & 0xffff];
break;
}
diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index 709759c..9ea1fdc 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -452,12 +452,7 @@ bool_t mtrr_var_range_msr_set(
return 0;
if ( d == current->domain )
- {
- struct cpuid_leaf res;
-
- guest_cpuid(current, 0x80000008, 0, &res);
- phys_addr = (uint8_t)res.a ?: 36;
- }
+ phys_addr = d->arch.cpuid->extd.maxphysaddr;
else
phys_addr = paddr_bits;
msr_mask = ~((((uint64_t)1) << phys_addr) - 1);
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index be76ed4..6cc23aa 100644
--- a/xen/include/asm-x86/cpuid.h
+++ b/xen/include/asm-x86/cpuid.h
@@ -198,7 +198,7 @@ struct cpuid_policy
};
/* Leaf 0x80000008 - Misc addr/feature info. */
- uint32_t /* a */:32;
+ uint8_t maxphysaddr, maxlinaddr, :8, :8;
union {
uint32_t e8b;
struct { DECL_BITFIELD(e8b); };
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 42+ messages in thread* Re: [PATCH v3 08/14] x86/cpuid: Handle leaf 0x80000008 in guest_cpuid()
2017-01-24 16:30 ` [PATCH v3 " Andrew Cooper
@ 2017-01-25 9:22 ` Jan Beulich
0 siblings, 0 replies; 42+ messages in thread
From: Jan Beulich @ 2017-01-25 9:22 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Xen-devel
>>> On 24.01.17 at 17:30, <andrew.cooper3@citrix.com> wrote:
> The entirety of edx is reserved.
>
> Intel only defines the lower 16 bits of eax, although ebx is covered by the
> featureset ABI, so left unclobbered.
>
> AMD uses 24 bits in eax, although nothing thus far has ever exposed a non-zero
> guest maxphysaddr to HVM guests. Its semantics are not clearly expressed, so
> it is explicitly clobbered. ecx contains some reserved bits, and several
> pieces of static topology information, which are left as the toolstack
> chooses.
>
> A side effect of the common recalculation of maxlinaddr is that 32bit PV
> guests see a maximum linear address of 32, which is consistent with the hiding
> of other long mode information from them.
>
> Finally, the call to guest_cpuid() in mtrr_var_range_msr_set() (introduced in
> c/s fff8160a) can be dropped, now that maxphysaddr can be read straight out of
> the cpuid_policy block.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH v2 09/14] x86/cpuid: Handle leaf 0x80000009 in guest_cpuid()
2017-01-23 14:39 [PATCH v2 00/14] x86/cpuid: Handling of simple leaves in guest_cpuid() Andrew Cooper
` (7 preceding siblings ...)
2017-01-23 14:39 ` [PATCH v2 08/14] x86/cpuid: Handle leaf 0x80000008 " Andrew Cooper
@ 2017-01-23 14:39 ` Andrew Cooper
2017-01-24 12:16 ` Jan Beulich
2017-01-23 14:39 ` [PATCH v2 10/14] x86/cpuid: Handle leaf 0x8000000a " Andrew Cooper
` (4 subsequent siblings)
13 siblings, 1 reply; 42+ messages in thread
From: Andrew Cooper @ 2017-01-23 14:39 UTC (permalink / raw)
To: Xen-devel; +Cc: Andrew Cooper, Jan Beulich
Leaf 0x80000009 is reserved.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
v2:
* New
---
xen/arch/x86/cpuid.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 4d48552..a8dce40 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -206,6 +206,8 @@ static void recalculate_misc(struct cpuid_policy *p)
p->extd.raw[0x8].a &= 0x00ffffff;
p->extd.raw[0x8].c &= 0x0003f0ff;
+
+ p->extd.raw[0x9] = EMPTY_LEAF;
break;
}
}
@@ -712,7 +714,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
- case 0x80000000 ... 0x80000008:
+ case 0x80000000 ... 0x80000009:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -808,7 +810,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
- case 0x80000000 ... 0x80000008:
+ case 0x80000000 ... 0x80000009:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -891,7 +893,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
default:
goto legacy;
- case 0x80000000 ... 0x80000008:
+ case 0x80000000 ... 0x80000009:
*res = p->extd.raw[leaf & 0xffff];
break;
}
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 42+ messages in thread* [PATCH v2 10/14] x86/cpuid: Handle leaf 0x8000000a in guest_cpuid()
2017-01-23 14:39 [PATCH v2 00/14] x86/cpuid: Handling of simple leaves in guest_cpuid() Andrew Cooper
` (8 preceding siblings ...)
2017-01-23 14:39 ` [PATCH v2 09/14] x86/cpuid: Handle leaf 0x80000009 " Andrew Cooper
@ 2017-01-23 14:39 ` Andrew Cooper
2017-01-24 12:20 ` Jan Beulich
2017-01-23 14:39 ` [PATCH v2 11/14] x86/cpuid: Handle leaves 0x8000000b-1a " Andrew Cooper
` (3 subsequent siblings)
13 siblings, 1 reply; 42+ messages in thread
From: Andrew Cooper @ 2017-01-23 14:39 UTC (permalink / raw)
To: Xen-devel; +Cc: Andrew Cooper, Jan Beulich
Leaf 0x8000000a contains SVM information. The feature choices are borrowed
straight from the libxc policy code.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
v2:
* New
---
xen/arch/x86/cpuid.c | 26 ++++++++++++++++++++++----
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index a8dce40..17738c8 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -4,6 +4,7 @@
#include <asm/cpuid.h>
#include <asm/hvm/hvm.h>
#include <asm/hvm/nestedhvm.h>
+#include <asm/hvm/svm/svm.h>
#include <asm/hvm/vmx/vmcs.h>
#include <asm/processor.h>
#include <asm/xstate.h>
@@ -282,6 +283,19 @@ static void __init calculate_host_policy(void)
cpuid_featureset_to_policy(boot_cpu_data.x86_capability, p);
recalculate_xstate(p);
recalculate_misc(p);
+
+ if ( p->extd.svm )
+ {
+ /* Clamp to implemented features which require hardware support. */
+ p->extd.raw[0xa].d &= ((1u << SVM_FEATURE_NPT) |
+ (1u << SVM_FEATURE_LBRV) |
+ (1u << SVM_FEATURE_NRIPS) |
+ (1u << SVM_FEATURE_PAUSEFILTER) |
+ (1u << SVM_FEATURE_DECODEASSISTS));
+ /* Enable features which are always emulated. */
+ p->extd.raw[0xa].d |= ((1u << SVM_FEATURE_VMCBCLEAN) |
+ (1u << SVM_FEATURE_TSCRATEMSR));
+ }
}
static void __init calculate_pv_max_policy(void)
@@ -302,6 +316,8 @@ static void __init calculate_pv_max_policy(void)
sanitise_featureset(pv_featureset);
cpuid_featureset_to_policy(pv_featureset, p);
recalculate_xstate(p);
+
+ p->extd.raw[0xa] = EMPTY_LEAF; /* No SVM for PV guests. */
}
static void __init calculate_hvm_max_policy(void)
@@ -490,6 +506,9 @@ void recalculate_cpuid_policy(struct domain *d)
recalculate_xstate(p);
recalculate_misc(p);
+
+ if ( !p->extd.svm )
+ p->extd.raw[0xa] = EMPTY_LEAF;
}
int init_domain_cpuid_policy(struct domain *d)
@@ -703,7 +722,6 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x00000005: /* MONITOR/MWAIT */
case 0x0000000b: /* Extended Topology Enumeration */
- case 0x8000000a: /* SVM revision and features */
case 0x8000001b: /* Instruction Based Sampling */
case 0x8000001c: /* Light Weight Profiling */
unsupported:
@@ -714,7 +732,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
- case 0x80000000 ... 0x80000009:
+ case 0x80000000 ... 0x8000000a:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -810,7 +828,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
- case 0x80000000 ... 0x80000009:
+ case 0x80000000 ... 0x8000000a:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -893,7 +911,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
default:
goto legacy;
- case 0x80000000 ... 0x80000009:
+ case 0x80000000 ... 0x8000000a:
*res = p->extd.raw[leaf & 0xffff];
break;
}
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 42+ messages in thread* [PATCH v2 11/14] x86/cpuid: Handle leaves 0x8000000b-1a in guest_cpuid()
2017-01-23 14:39 [PATCH v2 00/14] x86/cpuid: Handling of simple leaves in guest_cpuid() Andrew Cooper
` (9 preceding siblings ...)
2017-01-23 14:39 ` [PATCH v2 10/14] x86/cpuid: Handle leaf 0x8000000a " Andrew Cooper
@ 2017-01-23 14:39 ` Andrew Cooper
2017-01-23 14:47 ` Wei Liu
` (2 more replies)
2017-01-23 14:39 ` [PATCH v2 12/14] x86/cpufeatures: Hide Instruction Based Sampling from guests Andrew Cooper
` (2 subsequent siblings)
13 siblings, 3 replies; 42+ messages in thread
From: Andrew Cooper @ 2017-01-23 14:39 UTC (permalink / raw)
To: Xen-devel; +Cc: Andrew Cooper, Ian Jackson, Wei Liu, Jan Beulich
Leaves 8000000b-18 are reserved. Leaf 80000019 is 1G TLB information and leaf
0x8000001a is performance hints. These leaves have previously been hidden
from guests, but are perfectly safe to expose.
Update libxc to also expose these leaves.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
v2:
* New
---
tools/libxc/xc_cpuid_x86.c | 2 ++
xen/arch/x86/cpuid.c | 8 +++++---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 918590f..73a2ded 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -479,6 +479,8 @@ static void xc_cpuid_hvm_policy(xc_interface *xch,
case 0x80000005: /* AMD L1 cache/TLB info (dumped by Intel policy) */
case 0x80000006: /* AMD L2/3 cache/TLB info ; Intel L2 cache features */
case 0x8000000a: /* AMD SVM feature bits */
+ case 0x80000019: /* AMD 1G TLB */
+ case 0x8000001a: /* AMD perf hints */
case 0x8000001c: /* AMD lightweight profiling */
break;
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 17738c8..c75ba31 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -209,6 +209,8 @@ static void recalculate_misc(struct cpuid_policy *p)
p->extd.raw[0x8].c &= 0x0003f0ff;
p->extd.raw[0x9] = EMPTY_LEAF;
+
+ zero_leaves(p->extd.raw, 0xb, 0x18);
break;
}
}
@@ -732,7 +734,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
- case 0x80000000 ... 0x8000000a:
+ case 0x80000000 ... 0x8000001a:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -828,7 +830,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
- case 0x80000000 ... 0x8000000a:
+ case 0x80000000 ... 0x8000001a:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -911,7 +913,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
default:
goto legacy;
- case 0x80000000 ... 0x8000000a:
+ case 0x80000000 ... 0x8000001a:
*res = p->extd.raw[leaf & 0xffff];
break;
}
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 42+ messages in thread* Re: [PATCH v2 11/14] x86/cpuid: Handle leaves 0x8000000b-1a in guest_cpuid()
2017-01-23 14:39 ` [PATCH v2 11/14] x86/cpuid: Handle leaves 0x8000000b-1a " Andrew Cooper
@ 2017-01-23 14:47 ` Wei Liu
2017-01-24 12:26 ` Jan Beulich
2017-01-24 16:31 ` [PATCH v3 " Andrew Cooper
2 siblings, 0 replies; 42+ messages in thread
From: Wei Liu @ 2017-01-23 14:47 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Wei Liu, Ian Jackson, Jan Beulich, Xen-devel
On Mon, Jan 23, 2017 at 02:39:14PM +0000, Andrew Cooper wrote:
> Leaves 8000000b-18 are reserved. Leaf 80000019 is 1G TLB information and leaf
> 0x8000001a is performance hints. These leaves have previously been hidden
> from guests, but are perfectly safe to expose.
>
> Update libxc to also expose these leaves.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>
>
> v2:
> * New
> ---
> tools/libxc/xc_cpuid_x86.c | 2 ++
> xen/arch/x86/cpuid.c | 8 +++++---
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
> index 918590f..73a2ded 100644
> --- a/tools/libxc/xc_cpuid_x86.c
> +++ b/tools/libxc/xc_cpuid_x86.c
> @@ -479,6 +479,8 @@ static void xc_cpuid_hvm_policy(xc_interface *xch,
> case 0x80000005: /* AMD L1 cache/TLB info (dumped by Intel policy) */
> case 0x80000006: /* AMD L2/3 cache/TLB info ; Intel L2 cache features */
> case 0x8000000a: /* AMD SVM feature bits */
> + case 0x80000019: /* AMD 1G TLB */
> + case 0x8000001a: /* AMD perf hints */
Acked-by: Wei Liu <wei.liu2@citrix.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 11/14] x86/cpuid: Handle leaves 0x8000000b-1a in guest_cpuid()
2017-01-23 14:39 ` [PATCH v2 11/14] x86/cpuid: Handle leaves 0x8000000b-1a " Andrew Cooper
2017-01-23 14:47 ` Wei Liu
@ 2017-01-24 12:26 ` Jan Beulich
2017-01-24 16:00 ` Andrew Cooper
2017-01-24 16:31 ` [PATCH v3 " Andrew Cooper
2 siblings, 1 reply; 42+ messages in thread
From: Jan Beulich @ 2017-01-24 12:26 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Ian Jackson, Wei Liu, Xen-devel
>>> On 23.01.17 at 15:39, <andrew.cooper3@citrix.com> wrote:
> Leaves 8000000b-18 are reserved. Leaf 80000019 is 1G TLB information and leaf
> 0x8000001a is performance hints. These leaves have previously been hidden
> from guests, but are perfectly safe to expose.
I think 1G TLB info should be exposed only for guests seeing the 1G
page capability (i.e. namely neither shadow nor PV guests).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 11/14] x86/cpuid: Handle leaves 0x8000000b-1a in guest_cpuid()
2017-01-24 12:26 ` Jan Beulich
@ 2017-01-24 16:00 ` Andrew Cooper
0 siblings, 0 replies; 42+ messages in thread
From: Andrew Cooper @ 2017-01-24 16:00 UTC (permalink / raw)
To: Jan Beulich; +Cc: Ian Jackson, Wei Liu, Xen-devel
On 24/01/17 12:26, Jan Beulich wrote:
>>>> On 23.01.17 at 15:39, <andrew.cooper3@citrix.com> wrote:
>> Leaves 8000000b-18 are reserved. Leaf 80000019 is 1G TLB information and leaf
>> 0x8000001a is performance hints. These leaves have previously been hidden
>> from guests, but are perfectly safe to expose.
> I think 1G TLB info should be exposed only for guests seeing the 1G
> page capability (i.e. namely neither shadow nor PV guests).
Good point. Will adjust.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH v3 11/14] x86/cpuid: Handle leaves 0x8000000b-1a in guest_cpuid()
2017-01-23 14:39 ` [PATCH v2 11/14] x86/cpuid: Handle leaves 0x8000000b-1a " Andrew Cooper
2017-01-23 14:47 ` Wei Liu
2017-01-24 12:26 ` Jan Beulich
@ 2017-01-24 16:31 ` Andrew Cooper
2017-01-25 9:22 ` Jan Beulich
2 siblings, 1 reply; 42+ messages in thread
From: Andrew Cooper @ 2017-01-24 16:31 UTC (permalink / raw)
To: Xen-devel; +Cc: Andrew Cooper, Jan Beulich
Leaves 8000000b-18 are reserved. Leaf 80000019 is 1G TLB information and leaf
0x8000001a is performance hints. These leaves have previously been hidden
from guests, but are perfectly safe to expose when appicable.
Update libxc to also expose these leaves.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
v2:
* New
v3:
* Hide 1G TLB if a guest lacks page1gb.
---
tools/libxc/xc_cpuid_x86.c | 2 ++
xen/arch/x86/cpuid.c | 11 ++++++++---
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 918590f..73a2ded 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -479,6 +479,8 @@ static void xc_cpuid_hvm_policy(xc_interface *xch,
case 0x80000005: /* AMD L1 cache/TLB info (dumped by Intel policy) */
case 0x80000006: /* AMD L2/3 cache/TLB info ; Intel L2 cache features */
case 0x8000000a: /* AMD SVM feature bits */
+ case 0x80000019: /* AMD 1G TLB */
+ case 0x8000001a: /* AMD perf hints */
case 0x8000001c: /* AMD lightweight profiling */
break;
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 61a1f19..69dc39b 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -209,6 +209,8 @@ static void recalculate_misc(struct cpuid_policy *p)
p->extd.raw[0x8].c &= 0x0003f0ff;
p->extd.raw[0x9] = EMPTY_LEAF;
+
+ zero_leaves(p->extd.raw, 0xb, 0x18);
break;
}
}
@@ -509,6 +511,9 @@ void recalculate_cpuid_policy(struct domain *d)
if ( !p->extd.svm )
p->extd.raw[0xa] = EMPTY_LEAF;
+
+ if ( !p->extd.page1gb )
+ p->extd.raw[0x19] = EMPTY_LEAF;
}
int init_domain_cpuid_policy(struct domain *d)
@@ -732,7 +737,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
- case 0x80000000 ... 0x8000000a:
+ case 0x80000000 ... 0x8000001a:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -828,7 +833,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
- case 0x80000000 ... 0x8000000a:
+ case 0x80000000 ... 0x8000001a:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -911,7 +916,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
default:
goto legacy;
- case 0x80000000 ... 0x8000000a:
+ case 0x80000000 ... 0x8000001a:
*res = p->extd.raw[leaf & 0xffff];
break;
}
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 42+ messages in thread* Re: [PATCH v3 11/14] x86/cpuid: Handle leaves 0x8000000b-1a in guest_cpuid()
2017-01-24 16:31 ` [PATCH v3 " Andrew Cooper
@ 2017-01-25 9:22 ` Jan Beulich
0 siblings, 0 replies; 42+ messages in thread
From: Jan Beulich @ 2017-01-25 9:22 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Xen-devel
>>> On 24.01.17 at 17:31, <andrew.cooper3@citrix.com> wrote:
> Leaves 8000000b-18 are reserved. Leaf 80000019 is 1G TLB information and leaf
> 0x8000001a is performance hints. These leaves have previously been hidden
> from guests, but are perfectly safe to expose when appicable.
>
> Update libxc to also expose these leaves.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Acked-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH v2 12/14] x86/cpufeatures: Hide Instruction Based Sampling from guests
2017-01-23 14:39 [PATCH v2 00/14] x86/cpuid: Handling of simple leaves in guest_cpuid() Andrew Cooper
` (10 preceding siblings ...)
2017-01-23 14:39 ` [PATCH v2 11/14] x86/cpuid: Handle leaves 0x8000000b-1a " Andrew Cooper
@ 2017-01-23 14:39 ` Andrew Cooper
2017-01-24 12:43 ` Jan Beulich
2017-01-23 14:39 ` [PATCH v2 13/14] x86/cpuid: Handle leaf 0x8000001c in guest_cpuid() Andrew Cooper
2017-01-23 14:39 ` [PATCH v2 14/14] x86/cpuid: Remove the legacy path handling extd leaves Andrew Cooper
13 siblings, 1 reply; 42+ messages in thread
From: Andrew Cooper @ 2017-01-23 14:39 UTC (permalink / raw)
To: Xen-devel; +Cc: Andrew Cooper, Jan Beulich
Xen advertises the IBS feature flag to guests on capable AMD hardware.
However, the PV path in Xen, and both the PV and HVM paths in libxc
deliberately clobber the IBS CPUID leaf.
Furthermore, Xen has nothing providing an implementation of the IBS MSRs, so
guests can't actually use the feature at all.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
v2:
* New
---
xen/arch/x86/cpuid.c | 9 +++++----
xen/include/public/arch-x86/cpufeatureset.h | 2 +-
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index c75ba31..b9dcc71 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -211,6 +211,8 @@ static void recalculate_misc(struct cpuid_policy *p)
p->extd.raw[0x9] = EMPTY_LEAF;
zero_leaves(p->extd.raw, 0xb, 0x18);
+
+ p->extd.raw[0x1b] = EMPTY_LEAF; /* IBS - not supported. */
break;
}
}
@@ -724,7 +726,6 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x00000005: /* MONITOR/MWAIT */
case 0x0000000b: /* Extended Topology Enumeration */
- case 0x8000001b: /* Instruction Based Sampling */
case 0x8000001c: /* Light Weight Profiling */
unsupported:
*res = EMPTY_LEAF;
@@ -734,7 +735,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
- case 0x80000000 ... 0x8000001a:
+ case 0x80000000 ... 0x8000001b:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -830,7 +831,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
- case 0x80000000 ... 0x8000001a:
+ case 0x80000000 ... 0x8000001b:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -913,7 +914,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
default:
goto legacy;
- case 0x80000000 ... 0x8000001a:
+ case 0x80000000 ... 0x8000001b:
*res = p->extd.raw[leaf & 0xffff];
break;
}
diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h
index 70f1e30..97dd353 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -172,7 +172,7 @@ XEN_CPUFEATURE(SSE4A, 3*32+ 6) /*A SSE-4A */
XEN_CPUFEATURE(MISALIGNSSE, 3*32+ 7) /*A Misaligned SSE mode */
XEN_CPUFEATURE(3DNOWPREFETCH, 3*32+ 8) /*A 3DNow prefetch instructions */
XEN_CPUFEATURE(OSVW, 3*32+ 9) /* OS Visible Workaround */
-XEN_CPUFEATURE(IBS, 3*32+10) /*S Instruction Based Sampling */
+XEN_CPUFEATURE(IBS, 3*32+10) /* Instruction Based Sampling */
XEN_CPUFEATURE(XOP, 3*32+11) /*A extended AVX instructions */
XEN_CPUFEATURE(SKINIT, 3*32+12) /* SKINIT/STGI instructions */
XEN_CPUFEATURE(WDT, 3*32+13) /* Watchdog timer */
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 42+ messages in thread* [PATCH v2 13/14] x86/cpuid: Handle leaf 0x8000001c in guest_cpuid()
2017-01-23 14:39 [PATCH v2 00/14] x86/cpuid: Handling of simple leaves in guest_cpuid() Andrew Cooper
` (11 preceding siblings ...)
2017-01-23 14:39 ` [PATCH v2 12/14] x86/cpufeatures: Hide Instruction Based Sampling from guests Andrew Cooper
@ 2017-01-23 14:39 ` Andrew Cooper
2017-01-23 18:50 ` Boris Ostrovsky
2017-01-24 16:20 ` Jan Beulich
2017-01-23 14:39 ` [PATCH v2 14/14] x86/cpuid: Remove the legacy path handling extd leaves Andrew Cooper
13 siblings, 2 replies; 42+ messages in thread
From: Andrew Cooper @ 2017-01-23 14:39 UTC (permalink / raw)
To: Xen-devel
Cc: Andrew Cooper, Boris Ostrovsky, Suravee Suthikulpanit, Jan Beulich
Leaf 0x8000001c contains LWP information. edx contains hardware supported
features (and is clamped against the maximum), while ecx and ebx contain
various properties of the implementation. eax is entirely dynamic, depending
on xcr0 and MSR_LWP_CFG.
The call to guest_cpuid() in svm_update_lwp_cfg() can now be replaced by
reading the data straight out of the cpuid_policy block.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Boris Ostrovsky <boris.ostrovsky@oracle.com>
CC: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
---
xen/arch/x86/cpuid.c | 34 ++++++++++++++++------------------
xen/arch/x86/hvm/svm/svm.c | 5 +----
2 files changed, 17 insertions(+), 22 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index b9dcc71..78cd287 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -213,6 +213,8 @@ static void recalculate_misc(struct cpuid_policy *p)
zero_leaves(p->extd.raw, 0xb, 0x18);
p->extd.raw[0x1b] = EMPTY_LEAF; /* IBS - not supported. */
+
+ p->extd.raw[0x1c].a = 0; /* LWP.a entirely dynamic. */
break;
}
}
@@ -513,6 +515,11 @@ void recalculate_cpuid_policy(struct domain *d)
if ( !p->extd.svm )
p->extd.raw[0xa] = EMPTY_LEAF;
+
+ if ( p->extd.lwp )
+ p->extd.raw[0x1c].d &= max->extd.raw[0x1c].d;
+ else
+ p->extd.raw[0x1c] = EMPTY_LEAF;
}
int init_domain_cpuid_policy(struct domain *d)
@@ -726,7 +733,6 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x00000005: /* MONITOR/MWAIT */
case 0x0000000b: /* Extended Topology Enumeration */
- case 0x8000001c: /* Light Weight Profiling */
unsupported:
*res = EMPTY_LEAF;
break;
@@ -735,7 +741,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
- case 0x80000000 ... 0x8000001b:
+ case 0x80000000 ... 0x8000001c:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -813,25 +819,11 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
res->a = (res->a & ~0xff) | 3;
break;
- case 0x8000001c:
- if ( !cpu_has_svm )
- {
- *res = EMPTY_LEAF;
- break;
- }
-
- if ( cpu_has_lwp && (v->arch.xcr0 & XSTATE_LWP) )
- /* Turn on available bit and other features specified in lwp_cfg. */
- res->a = (res->d & v->arch.hvm_svm.guest_lwp_cfg) | 1;
- else
- res->a = 0;
- break;
-
case 0x0:
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
- case 0x80000000 ... 0x8000001b:
+ case 0x80000000 ... 0x8000001c:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -914,7 +906,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
default:
goto legacy;
- case 0x80000000 ... 0x8000001b:
+ case 0x80000000 ... 0x8000001c:
*res = p->extd.raw[leaf & 0xffff];
break;
}
@@ -1024,6 +1016,12 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
res->d |= cpufeat_mask(X86_FEATURE_MTRR);
}
break;
+
+ case 0x8000001c:
+ if ( (v->arch.xcr0 & XSTATE_LWP) && cpu_has_svm )
+ /* Turn on available bit and other features specified in lwp_cfg. */
+ res->a = (res->d & v->arch.hvm_svm.guest_lwp_cfg) | 1;
+ break;
}
/* Done. */
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index e8ef88d..01c7b58 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -931,13 +931,10 @@ static int svm_update_lwp_cfg(struct vcpu *v, uint64_t msr_content)
if ( xsave_enabled(v) && cpu_has_lwp )
{
- struct cpuid_leaf res;
-
- guest_cpuid(v, 0x8000001c, 0, &res);
msr_low = (uint32_t)msr_content;
/* generate #GP if guest tries to turn on unsupported features. */
- if ( msr_low & ~res.d)
+ if ( msr_low & ~v->domain->arch.cpuid->extd.raw[0x1c].d )
return -1;
v->arch.hvm_svm.guest_lwp_cfg = msr_content;
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 42+ messages in thread* Re: [PATCH v2 13/14] x86/cpuid: Handle leaf 0x8000001c in guest_cpuid()
2017-01-23 14:39 ` [PATCH v2 13/14] x86/cpuid: Handle leaf 0x8000001c in guest_cpuid() Andrew Cooper
@ 2017-01-23 18:50 ` Boris Ostrovsky
2017-01-24 16:20 ` Jan Beulich
1 sibling, 0 replies; 42+ messages in thread
From: Boris Ostrovsky @ 2017-01-23 18:50 UTC (permalink / raw)
To: Andrew Cooper, Xen-devel; +Cc: Suravee Suthikulpanit, Jan Beulich
On 01/23/2017 09:39 AM, Andrew Cooper wrote:
> Leaf 0x8000001c contains LWP information. edx contains hardware supported
> features (and is clamped against the maximum), while ecx and ebx contain
> various properties of the implementation. eax is entirely dynamic, depending
> on xcr0 and MSR_LWP_CFG.
>
> The call to guest_cpuid() in svm_update_lwp_cfg() can now be replaced by
> reading the data straight out of the cpuid_policy block.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 13/14] x86/cpuid: Handle leaf 0x8000001c in guest_cpuid()
2017-01-23 14:39 ` [PATCH v2 13/14] x86/cpuid: Handle leaf 0x8000001c in guest_cpuid() Andrew Cooper
2017-01-23 18:50 ` Boris Ostrovsky
@ 2017-01-24 16:20 ` Jan Beulich
1 sibling, 0 replies; 42+ messages in thread
From: Jan Beulich @ 2017-01-24 16:20 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Boris Ostrovsky, SuraveeSuthikulpanit, Xen-devel
>>> On 23.01.17 at 15:39, <andrew.cooper3@citrix.com> wrote:
> Leaf 0x8000001c contains LWP information. edx contains hardware supported
> features (and is clamped against the maximum), while ecx and ebx contain
> various properties of the implementation. eax is entirely dynamic, depending
> on xcr0 and MSR_LWP_CFG.
>
> The call to guest_cpuid() in svm_update_lwp_cfg() can now be replaced by
> reading the data straight out of the cpuid_policy block.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH v2 14/14] x86/cpuid: Remove the legacy path handling extd leaves
2017-01-23 14:39 [PATCH v2 00/14] x86/cpuid: Handling of simple leaves in guest_cpuid() Andrew Cooper
` (12 preceding siblings ...)
2017-01-23 14:39 ` [PATCH v2 13/14] x86/cpuid: Handle leaf 0x8000001c in guest_cpuid() Andrew Cooper
@ 2017-01-23 14:39 ` Andrew Cooper
2017-01-24 16:29 ` Jan Beulich
13 siblings, 1 reply; 42+ messages in thread
From: Andrew Cooper @ 2017-01-23 14:39 UTC (permalink / raw)
To: Xen-devel; +Cc: Andrew Cooper, Jan Beulich
All leaves in the extd union are handled in guest_cpuid() now, so remove
legacy handling.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
---
xen/arch/x86/cpuid.c | 14 +++-----------
xen/include/asm-x86/cpuid.h | 4 ++--
2 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 78cd287..d28735a 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -741,7 +741,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
- case 0x80000000 ... 0x8000001c:
+ case 0x80000000 ... 0xffffffff:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -823,7 +823,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
- case 0x80000000 ... 0x8000001c:
+ case 0x80000000 ... 0xffffffff:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -901,15 +901,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
ARRAY_SIZE(p->extd.raw) - 1) )
return;
- switch ( leaf )
- {
- default:
- goto legacy;
-
- case 0x80000000 ... 0x8000001c:
- *res = p->extd.raw[leaf & 0xffff];
- break;
- }
+ *res = p->extd.raw[leaf & 0xffff];
break;
default:
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index 6cc23aa..bc3fc7c 100644
--- a/xen/include/asm-x86/cpuid.h
+++ b/xen/include/asm-x86/cpuid.h
@@ -78,7 +78,7 @@ struct cpuid_policy
* Global *_policy objects:
*
* - Guest accurate:
- * - All of the feat and xstate unions
+ * - All of the feat, xstate and extd unions
* - max_{,sub}leaf
* - All FEATURESET_* words
* - Short vendor infomation
@@ -86,7 +86,7 @@ struct cpuid_policy
* Per-domain objects:
*
* - Guest accurate:
- * - All of the feat and xstate unions
+ * - All of the feat, xstate and extd unions
* - max_{,sub}leaf
* - All FEATURESET_* words
* - Short vendor infomation
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 42+ messages in thread