On Wed, Feb 2, 2022 at 4:33 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> On Wed, Feb 02, 2022, Jim Mattson wrote:
> > On Wed, Feb 2, 2022 at 3:04 PM Oliver Upton <oupton@xxxxxxxxxx> wrote:
> > >
> > > Ultimately, it is the responsibility of userspace to configure an
> > > appropriate MSR value for the CPUID it provides its guest. However,
> > > there are a few bits in VMX capability MSRs where KVM intervenes. The
> > > "load IA32_PERF_GLOBAL_CTRL", "load IA32_BNDCFGS", and "clear
> > > IA32_BNDCFGS" bits in the VMX VM-{Entry,Exit} control capability MSRs
> > > are updated every time userspace sets the guest's CPUID. In so doing,
> > > there is an imposed ordering between ioctls, that userspace must set MSR
> > > values *after* setting the guest's CPUID.
> >
> > Do you mean *before*?
>
> No, after, otherwise the CPUID updates will override the MSR updates.
>
> MSR_IA32_FEAT_CTL has this same issue. But that mess also highlights an issue
> with this series: if userspace relies on KVM to do the updates, it will break the
> existing ABI, e.g. I'm pretty sure older versions of QEMU rely on KVM to adjust
> the MSRs.
I realize I failed to add a note about exactly this in the cover
letter. It seems, based on the commit 5f76f6f5ff96 ("KVM: nVMX: Do not
expose MPX VMX controls when guest MPX disabled") we opted to handle
the VMX capability MSR in-kernel rather than expecting userspace to
pick a sane value that matches the set CPUID. So what really has
become ABI here? It seems as though one could broadly state that KVM
owns VMX VM-{Entry,Exit} control MSRs without opt-in, or narrowly
assert that only the bits in this series are in fact ABI.
Regardless, since we must uphold this misbehavior as ABI, we have a
regression since KVM doesn't override the MSR write if it comes after
the CPUID write.
> I agree that KVM should keep its nose out of this stuff, especially since most
> VMX controls are technically not architecturally tied to CPUID. But we probably
> need an opt-in from userspace to stop mucking with the MSRs.
Bleh, I wanted to avoid the age-old problem of naming, but alas...
--
Thanks,
Oliver
