lkml.org 
[lkml]   [2021]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 07/54] KVM: x86: Alert userspace that KVM_SET_CPUID{,2} after KVM_RUN is broken
From
Date
On 23/06/21 20:11, Jim Mattson wrote:
> On Wed, Jun 23, 2021 at 10:11 AM Paolo Bonzini <pbonzini@redhat.com> 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

\
 
 \ /
  Last update: 2021-06-23 20:50    [W:0.145 / U:0.896 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site