On 09/09/2021 12:47, Jan Beulich wrote: > 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).
It is less bad than the alternative, which was failing to intercept e.g. XSETBV. Something's going to crash or malfunction either way. Intercepting everything makes it far more obvious, and limits the damage to only the offending guest. And yes - this is once again why we really need a credible support statement for CPUs. ~Andrew
