On Thu, Aug 29, 2024 at 09:42:40PM -0700, Sean Christopherson wrote:
Ah, sorry, if the platform+kernel supports the feature, not just raw CPU.
Yeah, that's not always trivial, as I'm sure you know. Especially if it is a complicated feature like, SNP, for example, which needs fw and platform to be configured properly and so on.
And because that utility is not available by default on most targets I care about, and having to build and copy over a binary is annoying (though this is a minor gripe).
I'm keeping that thing as simple as possible on purpose. So if you wanna make it available on such targets, I'm all ears.
That said, what I really want in most cases is to know if _KVM_ supports a feature. I'll think more on this, I have a few vague ideas for getting a pile of information out of KVM without needing to add more uABI.
That's exactly my pet peeve - making it a uABI and then supporting it foreva.
We have tried to explain what cpuinfo should be:
Documentation/arch/x86/cpuinfo.rst
The gist of it is:
"So, the current use of /proc/cpuinfo is to show features which the kernel has *enabled* and *supports*. As in: the CPUID feature flag is there, there's an additional setup which the kernel has done while booting and the functionality is ready to use. A perfect example for that is "user_shstk" where additional code enablement is present in the kernel to support shadow stack for user programs."
So if it is something that has been enabled and is actively supported, then sure, ofc. What I don't want to have there is a partial mirror of every possible CPUID flag which is going to be a senseless and useless madness.
Dunno, I guess if we had a
"virt: ..."
line in /proc/cpuinfo which has flags of what the hypervisor has enabled as a feature, it might not be such a wrong idea... with the above caveats, ofc. I don't think you want a flurry of patches setting all possible flags just because.
Or maybe somewhere else where you can query it conveniently...