[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 22.09.17 at 12:32, <sergey.dyasli@xxxxxxxxxx> wrote: > 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. I'm of the opposite opinion, as doing what you suggest would make the backport more difficult. >> @@ -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? My mistake not carrying backwards what I had figured when doing the VMX side change. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |