Re: [PATCH v4 8/9] target/i386/mshv: filter out CET bits in cpuid

[Magnus Kulke <magnuskulke@linux.microsoft.com>]

On Wed, Apr 15, 2026 at 04:30:10PM +0200, Mohamed Mediouni wrote:
> Is CPUID performance such a problem?
> 
> What I have from WHPX on this - where for now CPUID vmexits are used 
> instead of this fancy interface* - although that might change in the future:
> 
> Those have been seen to vary dynamically for a vCPU:
> 
> CPUID[1:EDX].APIC
> CPUID_7_0_EDX_CET_IBT
> CPUID_7_0_ECX_CET_SHSTK
> CPUID_7_0_ECX_OSPKE
> CPUID_EXT_OSXSAVE
> The whole 0xD leave
> 
> I used the default result to override with the Hyper-V stock response for those bits,
> although masking as provided by the new interface would work too.
> 
> * not using it yet because Windows 10 Hyper-V didn’t have it, and the perf impact for CPUIDs
>  didn’t sound like an actual problem so trapped as much leaves as it could make sense
> 

Hey Mohamed. yeah, it's arguable.

I would prefer not to introduce a VM exit. You are probably right that
it doesn't matter much, however I can imagine that there are workloads
that perform feature detection in a hot path (e.g. right before some
AVX computation) and trapping it to the vmm would impact perf for those.

But yeah, if it turns out that the static responses and the mask do not
work, we have to consider this.

best,

magnus