On Mon, Mar 06, 2023, Borislav Petkov wrote: > On Mon, Mar 06, 2023 at 10:47:18PM +0100, Paolo Bonzini wrote: > > It's very rare that KVM can provide a CPUID feature if the kernel has > > masked it, > > I'm talking about pure hw feature bits which don't need any enablement. > Like AVX512 insns subset support or something else which the hw does > without the need for the kernel. > > Those should be KVM-only if baremetal doesn't use them. I don't see what such a rule buys us beyond complexity and, IMO, unnecessary maintenance burden. As Paolo pointed out, when there's an existing word, the only "cost" is the existence of the #define. The bit is still present in the capabilities, and KVM relies on this! And as mentioned in the tangent about reworking cpufeatures[*], I get a _lot_ of value out of cpufeatures.h being fully populated for known bits (in defined words). Forcing KVM to #define bits in reverse_cpuid.h just because the kernel doesn't need the macro will inevitably lead to confusion for KVM developers, both when writing new code and when reading existing code. [*] https://lore.kernel.org/all/Y8nhtjFcsB63UsmQ@xxxxxxxxxx
