[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 for-4.11] x86/pv: Hide more EFER bits from PV guests



On 07/05/18 11:43, Jan Beulich wrote:
>>>> On 07.05.18 at 12:00, <andrew.cooper3@xxxxxxxxxx> wrote:
>> --- a/xen/arch/x86/pv/emul-priv-op.c
>> +++ b/xen/arch/x86/pv/emul-priv-op.c
>> @@ -867,9 +867,16 @@ static int read_msr(unsigned int reg, uint64_t *val,
>>          return X86EMUL_OKAY;
>>  
>>      case MSR_EFER:
>> -        *val = read_efer();
>> +        /* Hide unknown bits, and unconditionally hide SVME from guests. */
>> +        *val = read_efer() & EFER_KNOWN_MASK & ~EFER_SVME;
>> +        /*
>> +         * Hide the 64-bit features from 32-bit guests.  SCE has
>> +         * vendor-dependent behaviour.
>> +         */
>>          if ( is_pv_32bit_domain(currd) )
>> -            *val &= ~(EFER_LME | EFER_LMA | EFER_LMSLE);
>> +            *val &= ~(EFER_LME | EFER_LMA | EFER_LMSLE |
>> +                      (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL
>> +                       ? EFER_SCE : 0));
>>          return X86EMUL_OKAY;
> Ideally this would check the domain's x86_vendor, but that would require
> wiring up emulation afaict, so fwiw
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Yes - we'd have to hook SYSCALL/SYSRET off the #UD handler, and teach
x86_emulate() to understand PV's idea of guest kernel mode.  That is a
complete can of worms.

If someone feels like making cross-vendor PV work then great, but I
don't think we can plausibly claim that it might work atm.  (Same for
HVM, despite the code we actually have.)

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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