Re: [PATCH 07/54] KVM: x86: Alert userspace that KVM_SET_CPUID{,2} after KVM_RUN is broken

[Jim Mattson]

On Wed, Jun 23, 2021 at 11:49 AM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
>
> On 23/06/21 20:11, Jim Mattson wrote:
> > On Wed, Jun 23, 2021 at 10:11 AM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
> >> Nah, that's not the philosophy.  The philosophy is that covering all
> >> possible ways for userspace to shoot itself in the foot is impossible.
> >>
> >> However, here we're talking about 2 lines of code (thanks also to your
> >> patches that add last_vmentry_cpu for completely unrelated reasons) to
> >> remove a whole set of bullet/foot encounters.
> >
> > What about the problems that arise when we have different CPUID tables
> > for different vCPUs in the same VM? Can we just replace this
> > hole-in-foot inducing ioctl with a KVM_VM_SET_CPUID ioctl on the VM
> > level that has to be called before any vCPUs are created?
>
> Are there any KVM bugs that this can fix?  The problem is that, unlike
> this case, it would be effectively impossible to deprecate
> KVM_SET_CPUID2 as a vcpu ioctl, so it would be hard to reap any benefits
> in KVM.
>
> BTW, there is actually a theoretical usecase for KVM_SET_CPUID2 after
> KVM_RUN, which is to test OSes against microcode updates that hide,
> totally random example, the RTM bit.  But it's still not worth keeping
> it given 1) the bugs and complications in KVM, 2) if you really wanted
> that kind of testing so hard, the fact that you can just create a new
> vcpu file descriptor from scratch, possibly in cooperation with
> userspace MSR filtering 3) AFAIK no one has done that anyway in 15 years.

Though such a usecase may exist, I don't think it actually works
today. For example, kvm_vcpu_after_set_cpuid() potentially changes the
value of the guest IA32_PERF_GLOBAL_CTRL MSR.