[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.