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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux