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