[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |