On Tue, Feb 25, 2025, Xin Li wrote: > On 2/25/2025 8:22 AM, Sean Christopherson wrote: > > On Mon, Sep 30, 2024, Xin Li (Intel) wrote: > > > Add a prerequisite to existence of VMCS fields as some of them exist > > > only on processors that support certain CPU features. > > > > > > This is required to fix KVM unit test VMX_VMCS_ENUM.MAX_INDEX. > > > > If making the KVM-Unit-Test pass is the driving force for this code, then NAK. > > We looked at this in detail a few years back, and came to the conclusion that > > trying to precisely track which fields are/aren't supported would likely do more > > harm than good. > > I have to agree, it's no fun to track a VMCS field is added by which > feature(s), and worst part is that one VMCS field could depend on 2+ totally > irrelevant features, e.g., the secondary VM exit controls field exits on CPU > that supports: > > 1) FRED > 2) Prematurely busy shadow stack > > Thanks for making the ground rule clear. > > BTW, why don't we just remove this VMX_VMCS_ENUM.MAX_INDEX test? Because it's still a valid test, albeit with caveats. KVM's (undocumented?) erratum is that vmcs12 fields that are supported by KVM are always readable, but that's mostly an orthogonal issuue to VMX_VMCS_ENUM.MAX_INDEX. I.e. KVM can and does report a correct VMX_VMCS_ENUM.MAX_INDEX based on which VMCS fields KVM emulates. The big caveat is that VMX_VMCS_ENUM.MAX_INDEX will be wrong if a VM is migrated to a newer KVM and/or to a host with a superset of functionality. With those caveats in mind, it's still nice to sanity check that KVM isn't advertising complete garbage.
