Re: [PATCH v4] x86/nSVM: Check injected event consistency

[Jan Beulich <jbeulich@xxxxxxxx>]

On 21.09.2026 17:50, Abdelkareem Abdelsaamad wrote:
> On 07.09.2026 08:50, Jan Beulich wrote:
>> On 06.09.2026 15:11, Abdelkareem Abdelsaamad wrote:
>>> On 26.08.2026 15:33, Jan Beulich wrote:
>>>> On 23.08.2026 18:11, Abdelkareem Abdelsaamad wrote:
>>>>> +    case X86_EXC_OF:
>>>>> +    case X86_EXC_BR:
>>>>> +        return !(vmcb_get_efer(vmcb) & EFER_LMA) || !vmcb->cs.l;
>>>>> +
>>>>> +    case X86_EXC_VC:
>>>>> +        return vmcb_get_sev_es(vmcb);
>>>>> +
>>>>> +    case X86_EXC_CP:
>>>>> +        return vmcb_get_cr4(vmcb) & X86_CR4_CET;
>>>>
>>>> ... e.g. here. That is, if a CR4 (or other) check is needed here, but not
>>>> for #XM (or #SX), that's surely worth (briefly) commenting upon. The more
>>>> that, afaics, none of this is spelled out in the PM.
>>> In my testing, the hardware behavior differs across the generations support 
>>> for
>>> the Control-flow Enforcement Technology (CET):
>>>  - Naples (No hardware support): Injecting the event when the feature is
>>>    completely unsupported by the CPU results in VMEXIT_INVALID. The VMCB's 
>>> CR4
>>>    bit is not set as it is expected.
>>>  - Genoa (Hardware support exists): If the CPU supports the feature but the
>>>    guest has not enabled it in CR4 (not opted-in), injecting the event
>>>    results in a triple fault. I am accordingly checking for the CPU feature 
>>> and
>>>    report it as invalid.
>>
>> A guest triple fault, I assume?
> Yes, that is correct. I meant a guest triple fault.
>> I'm not entirely convinced this is a sufficient
>> indication of injection being permitted, even though I agree it very much 
>> looks
>> so. Then again, like above, I'm also unconvinced this is actually intended
>> behavior. Guests unaware of a feature (and hence not enabling it) should 
>> never
>> observe exceptions related to only that feature.
> The testing, I performed shows the following behavior across the CPU
> generations:
>  - On CPUU generations that support the feature (e.g., Genoa supporting 
>    Control-flow Enforcement Technology / CET), the injection results in
>    a guest triple fault. If the the guest did not opt-in for the CET feature.
>    No VMEXIT_INVALID results by the injection.
>  - On older hardware generations that completely lack the feature (e.g., 
> Naples), 
>    the injection immediately results in a VMEXIT_INVALID.
> 
> The current hardware behavior seems to depend on whether the underlying
> physical CPU understands the feature, rather than whether the guest has opted
> into it via CR4. The patch expands this to consider the injection will result
> in VMEXIT_INVALID if the guest did not opt into the feature.
> 
> Are you suggesting to reather explicitly check the CPU model/generation 
> instead
> of checking X86_CR4_CET? For example, allowing the injection on Genoa 
> platforms
> regardless of whether the guest has enabled the CET capability? I am 
> concerned 
> that handling this via CPU model checks might introduce architectural edge
> cases and/or add maintenance complication—what are your thoughts on that
> approach?

No, I'm not suggesting to go by CPU model. That would be wrong in certain
migration scenarios, afaict.

Jan