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
