Re: [PATCH] KVM: VMX: introduce module parameter to disable CET

[Paolo Bonzini <pbonzini@redhat.com>]

On 5/13/26 01:55, Sean Christopherson wrote:
> On Tue, May 12, 2026, Paolo Bonzini wrote:
>> There have been reports of host hangs caused by CET virtualization.
>> Until these are analyzed further, introduce a module parameter that
>> makes it possible to easily disable it.
>>
>> Link: https://lore.kernel.org/all/85548beb-1486-40f9-beb4-632c78e3360b@proxmox.com/
>> Cc: David Riley <d.riley@proxmox.com>
>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>> ---
>>   arch/x86/kvm/vmx/capabilities.h |  1 +
>>   arch/x86/kvm/vmx/vmcs12.c       |  2 +-
>>   arch/x86/kvm/vmx/vmx.c          | 17 +++++++++++++++--
>>   3 files changed, 17 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/kvm/vmx/capabilities.h b/arch/x86/kvm/vmx/capabilities.h
>> index 56cacc06225e..31568274d8bb 100644
>> --- a/arch/x86/kvm/vmx/capabilities.h
>> +++ b/arch/x86/kvm/vmx/capabilities.h
>> @@ -14,6 +14,7 @@ extern bool __read_mostly flexpriority_enabled;
>>   extern bool __read_mostly enable_ept;
>>   extern bool __read_mostly enable_unrestricted_guest;
>>   extern bool __read_mostly enable_ept_ad_bits;
>> +extern bool __read_mostly enable_cet;
>>   extern bool __read_mostly enable_pml;
>>   extern int __read_mostly pt_mode;
>>   
>> diff --git a/arch/x86/kvm/vmx/vmcs12.c b/arch/x86/kvm/vmx/vmcs12.c
>> index 1ebe67c384ad..9f96e21dc1b9 100644
>> --- a/arch/x86/kvm/vmx/vmcs12.c
>> +++ b/arch/x86/kvm/vmx/vmcs12.c
>> @@ -202,7 +202,7 @@ static __init bool cpu_has_vmcs12_field(unsigned int idx)
>>   	case HOST_S_CET:
>>   	case HOST_SSP:
>>   	case HOST_INTR_SSP_TABLE:
>> -		return cpu_has_load_cet_ctrl();
>> +		return enable_cet;
> 
> As implemented, cpu_has_vmcs12_field() checks raw CPU support, not what KVM is
> using.  E.g. EPT_POINTER checks cpu_has_vmx_ept(), not enable_ept.  Whether or
> not that's ideal/desirable, dunno.  But I think we should at least be consistent.
> 
> An alternative approach would be to squash the controls themselves.  Though again,
> I'd probably only want to do that if we plan on taking that approach for all such
> module params.

Yes, that was my first idea but it's not great to do it inconsistently. 
I'll remove the cpu_has_vmcs12_field() hunk though.

Paolo