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 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.
