On Fri, Nov 22, 2019 at 07:36:41PM +0100, Borislav Petkov wrote: > On Thu, Nov 21, 2019 at 01:50:17PM -0800, Sean Christopherson wrote: > > As for why I want to keep these out of cpu_has()... VMX has a concept of > > features being fixed "on", e.g. early CPUs don't allow disabling off CR3 > > interception. A cpu_has() approach doesn't work well since it loses the > > information regarding which bits are fixed-1. KVM also has several module > > params that can be used to disable use of features, i.e. we don't want > > cpu_has() for VMX features because the KVM-specific variables need to be > > the canonical reference. > > Well, you can use the cpu_has() machinery for stuff like that too - we > can clear bits there too: clear_cpu_cap() - and since clearing those > bits are only for /proc/cpuinfo reporting, it's not like anything would > break if that flag is gone. Just saying, in case you want to use the > machinery for that. It doesn't fit the KVM use case very well. There is an obnoxious amount of legacy KVM code that exists only to support old processors (10+ years old), but that we can't get rid of because people are still actively running KVM on old hardware. KVM provides module params so that we can easily test those flows on modern hardware, e.g. for certain changes I'll reload and retest KVM 2-3 times with different settings. In theory we could do something like recompute VMX_FEATURE_* when KVM is loaded, but that'd be a bit ugly and there are also tenative plans to move the relevant module params under an ioctl() so that they can be toggled on a per-VM basis to help automate testing, and IIRC for customers running certain legacy workloads alongside normal VMs > And that would avoid some of the duplication of having KVM-specific > variables *and* VMX_FEATURE_* flags, where latter are not really > toggleable but only for /proc/cpuinfo. Especially if you wanna enforce > "developers to define a VMX_FEATURE flag when adding support for a new > hardware feature."
