[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86: avoid #GP for PV guest MSR accesses
On Fri, 2017-09-22 at 03:06 -0600, Jan Beulich wrote: > Halfway recent Linux kernels probe MISC_FEATURES_ENABLES on all CPUs, > leading to ugly recovered #GP fault messages with debug builds on older > systems. We can do better, so introduce synthetic feature flags for > both this and PLATFORM_INFO to avoid the rdmsr_safe() altogether. > > The rdmsr_safe() uses for MISC_ENABLE are left in place as benign - it > exists for all 64-bit capable Intel CPUs (see e.g. early_init_intel()). > > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> The intent of this patch (and the related "VMX: PLATFORM_INFO MSR is r/o") is somewhat intersects with my series "Generic MSR policy: infrastructure + cpuid_faulting". IMHO it's better to fix MSR-related issues in the scope of the MSR policy work. Also, I have one question below. > > --- a/xen/arch/x86/cpu/intel.c > +++ b/xen/arch/x86/cpu/intel.c > @@ -21,10 +21,19 @@ static bool __init probe_intel_cpuid_fau > { > uint64_t x; > > - if (rdmsr_safe(MSR_INTEL_PLATFORM_INFO, x) || > - !(x & MSR_PLATFORM_INFO_CPUID_FAULTING)) > + if (rdmsr_safe(MSR_INTEL_PLATFORM_INFO, x)) > return 0; > > + setup_force_cpu_cap(X86_FEATURE_MSR_PLATFORM_INFO); > + > + if (!(x & MSR_PLATFORM_INFO_CPUID_FAULTING)) { > + if (!rdmsr_safe(MSR_INTEL_MISC_FEATURES_ENABLES, x)) > + setup_force_cpu_cap(X86_FEATURE_MSR_MISC_FEATURES); > + return 0; > + } > + > + setup_force_cpu_cap(X86_FEATURE_MSR_MISC_FEATURES); > + > expected_levelling_cap |= LCAP_faulting; > levelling_caps |= LCAP_faulting; > setup_force_cpu_cap(X86_FEATURE_CPUID_FAULTING); > --- a/xen/arch/x86/pv/emul-priv-op.c > +++ b/xen/arch/x86/pv/emul-priv-op.c > @@ -941,8 +941,7 @@ static int read_msr(unsigned int reg, ui > return X86EMUL_OKAY; > > case MSR_INTEL_PLATFORM_INFO: > - if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL || > - rdmsr_safe(MSR_INTEL_PLATFORM_INFO, *val) ) > + if ( !boot_cpu_has(X86_FEATURE_MSR_PLATFORM_INFO) ) > break; > *val = 0; > if ( this_cpu(cpuid_faulting_enabled) ) > @@ -950,8 +949,7 @@ static int read_msr(unsigned int reg, ui > return X86EMUL_OKAY; > > case MSR_INTEL_MISC_FEATURES_ENABLES: > - if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL || > - rdmsr_safe(MSR_INTEL_MISC_FEATURES_ENABLES, *val) ) > + if ( !boot_cpu_has(X86_FEATURE_MSR_MISC_FEATURES) ) > break; > *val = 0; > if ( curr->arch.cpuid_faulting ) > @@ -1147,15 +1145,13 @@ static int write_msr(unsigned int reg, u > return X86EMUL_OKAY; > > case MSR_INTEL_PLATFORM_INFO: > - if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL || > - val || rdmsr_safe(MSR_INTEL_PLATFORM_INFO, val) ) > + if ( !boot_cpu_has(X86_FEATURE_MSR_PLATFORM_INFO) || val ) > break; > return X86EMUL_OKAY; Why writes to MSR_INTEL_PLATFORM_INFO shouldn't produce #GP faults for PV guests? > > case MSR_INTEL_MISC_FEATURES_ENABLES: > - if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL || > - (val & ~MSR_MISC_FEATURES_CPUID_FAULTING) || > - rdmsr_safe(MSR_INTEL_MISC_FEATURES_ENABLES, temp) ) > + if ( !boot_cpu_has(X86_FEATURE_MSR_MISC_FEATURES) || > + (val & ~MSR_MISC_FEATURES_CPUID_FAULTING) ) > break; > if ( (val & MSR_MISC_FEATURES_CPUID_FAULTING) && > !this_cpu(cpuid_faulting_enabled) ) > --- a/xen/include/asm-x86/cpufeatures.h > +++ b/xen/include/asm-x86/cpufeatures.h > @@ -22,3 +22,5 @@ XEN_CPUFEATURE(APERFMPERF, (FSCAPIN > XEN_CPUFEATURE(MFENCE_RDTSC, (FSCAPINTS+0)*32+ 9) /* MFENCE synchronizes > RDTSC */ > XEN_CPUFEATURE(XEN_SMEP, (FSCAPINTS+0)*32+10) /* SMEP gets used by > Xen itself */ > XEN_CPUFEATURE(XEN_SMAP, (FSCAPINTS+0)*32+11) /* SMAP gets used by > Xen itself */ > +XEN_CPUFEATURE(MSR_PLATFORM_INFO, (FSCAPINTS+0)*32+12) /* PLATFORM_INFO MSR > present */ > +XEN_CPUFEATURE(MSR_MISC_FEATURES, (FSCAPINTS+0)*32+13) /* > MISC_FEATURES_ENABLES MSR present */ > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxx > https://lists.xen.org/xen-devel -- Thanks, Sergey _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |