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.
