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@xxxxxxxxxx/ > Hi Sean, do you have any suggestions for this patch? Thanks!
