[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] x86/svm: Intercept and terminate RDPRU with #UD
On 09.09.2021 13:34, Andrew Cooper wrote: > On 09/09/2021 10:57, Jan Beulich wrote: >> On 08.09.2021 18:19, Andrew Cooper wrote: >>> --- a/xen/arch/x86/hvm/svm/vmcb.c >>> +++ b/xen/arch/x86/hvm/svm/vmcb.c >>> @@ -70,7 +70,8 @@ static int construct_vmcb(struct vcpu *v) >>> GENERAL2_INTERCEPT_STGI | GENERAL2_INTERCEPT_CLGI | >>> GENERAL2_INTERCEPT_SKINIT | GENERAL2_INTERCEPT_MWAIT | >>> GENERAL2_INTERCEPT_WBINVD | GENERAL2_INTERCEPT_MONITOR | >>> - GENERAL2_INTERCEPT_XSETBV | GENERAL2_INTERCEPT_ICEBP; >>> + GENERAL2_INTERCEPT_XSETBV | GENERAL2_INTERCEPT_ICEBP | >>> + GENERAL2_INTERCEPT_RDPRU; >> Some of the other intercepts here suggest it is okay to enable ones >> in the absence of support in the underlying hardware, but I thought >> I'd double check. I couldn't find any statement either way in the PM. >> Assuming this is fine > > They're just bits in memory. Older CPUs will ignore them, and indeed - > pre-RDPRU hardware is fine running with this intercept bit set. > > Honestly, I've got half a mind to default the intercepts to ~0 rather > than 0. For running older Xen on new hardware, it will lead to fewer > unexpected surprises. I, too, was considering this, but then we have default: unexpected_exit_type: gprintk(XENLOG_ERR, "Unexpected vmexit: reason %#"PRIx64", " "exitinfo1 %#"PRIx64", exitinfo2 %#"PRIx64"\n", exit_reason, vmcb->exitinfo1, vmcb->exitinfo2); crash_or_fault: svm_crash_or_fault(v); break; } at the bottom of the switch() statement handling the exit codes. Getting crashed (or crashing because of an unexpected fault) is surely a surprise as well (to a guest). Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |