On Thu, Dec 12, 2019 at 08:04:19PM +0200, Liran Alon wrote:
On 12 Dec 2019, at 19:57, Jim Mattson jmattson@google.com wrote:
On Thu, Dec 12, 2019 at 9:53 AM Liran Alon liran.alon@oracle.com wrote:
Why should CPU VMX features be treated differently than standard CPUID deduced features?
Do we have the right Intel people on the recipient list to answer this question? Presumably, Intel felt that this information should be available in supervisor mode only.
Sean?
Good question. Probably because it just makes sense that Ring3 will never need to use this info as all VMX instructions are privileged. i.e. Can only be executed in Ring0.
I highly doubt ring0 vs. ring3 was a motivating factor. I suspect the MSR interface is primarily driven by VMX's allowed-0 vs. allowed-1 behavior, which would be awkward to encode in CPUID. Reporting via MSR also likely provided more flexibility for updating/fixing CPU behavior, e.g. patching the RDMSR hook is likely far easier than patching CPUID.
Even if the architects intended the information to be supervisor-only, that's just their opinion, no?
De-facto in KVM we have discovered this assumption to be problematic BTW, as KVM created an interface to query VMX MSRs values to properly define the requested vCPU model. :P (See kvm_get_msr_feature())