Re: [PATCH v2] KVM: x86: Advertise AVX10.1 CPUID to userspace

[Tao Su <tao1.su@linux.intel.com>]

On Mon, Jun 03, 2024 at 02:40:02PM +0800, Tao Su wrote:
> Advertise AVX10.1 related CPUIDs, i.e. report AVX10 support bit via
> CPUID.(EAX=07H, ECX=01H):EDX[bit 19] and new CPUID leaf 0x24H so that
> guest OS and applications can query the AVX10.1 CPUIDs directly. Intel
> AVX10 represents the first major new vector ISA since the introduction of
> Intel AVX512, which will establish a common, converged vector instruction
> set across all Intel architectures[1].
> 
> AVX10.1 is an early version of AVX10, that enumerates the Intel AVX512
> instruction set at 128, 256, and 512 bits which is enabled on
> Granite Rapids. I.e., AVX10.1 is only a new CPUID enumeration with no
> VMX capability, Embedded rounding and Suppress All Exceptions (SAE),
> which will be introduced in AVX10.2.
> 
> Advertising AVX10.1 is safe because kernel doesn't enable AVX10.1 which is
> on KVM-only leaf now, just the CPUID checking is changed when using AVX512
> related instructions, e.g. if using one AVX512 instruction needs to check
> (AVX512 AND AVX512DQ), it can check ((AVX512 AND AVX512DQ) OR AVX10.1)
> after checking XCR0[7:5].
> 
> The versions of AVX10 are expected to be inclusive, e.g. version N+1 is
> a superset of version N. Per the spec, the version can never be 0, just
> advertise AVX10.1 if it's supported in hardware.
> 
> As more and more AVX related CPUIDs are added (it would have resulted in
> around 40-50 CPUID flags when developing AVX10), the versioning approach
> is introduced. But incrementing version numbers are bad for virtualization.
> E.g. if AVX10.2 has a feature that shouldn't be enumerated to guests for
> whatever reason, then KVM can't enumerate any "later" features either,
> because the only way to hide the problematic AVX10.2 feature is to set the
> version to AVX10.1 or lower[2]. But most AVX features are just passed
> through and don’t have virtualization controls, so AVX10 should not be
> problematic in practice.
> 
> [1] https://cdrdv2.intel.com/v1/dl/getContent/784267
> [2] https://lore.kernel.org/all/Zkz5Ak0PQlAN8DxK@google.com/
> 

Hi Sean, do you have any suggestions for this patch? Thanks!