On Tue, Jun 11, 2024, Chao Gao wrote: > On Tue, Jun 11, 2024 at 06:34:49AM -0700, Sean Christopherson wrote: > >> As said, this requires some tweaks to KVM_CAP_FORCE_SPEC_CTRL, such as making > >> the mask and shadow values adjustable and applicable on a per-vCPU basis. The > >> tweaks are not necessarily for Intel-defined virtual MSRs; if there were other > >> preferable interfaces, they could also benefit from these changes. > >> > >> Any objections to these tweaks to KVM_CAP_FORCE_SPEC_CTRL? > > > >Why does KVM_CAP_FORCE_SPEC_CTRL need to be per-vCPU? Won't the CPU bugs and > >mitigations be system-wide / VM-wide? > > Because spec_ctrl is per-vCPU and Intel-defined virtual MSRs are also per-vCPU. I figured that was the answer, but part of me was hopeful :-) > i.e., a guest __can__ configure different values to virtual MSRs on different > vCPUs even though a sane guest won't do this. If KVM doesn't want to rule out > the possibility of supporting Intel-defined virtual MSRs in userspace or any > other per-vCPU interfaces, KVM_CAP_FORCE_SPEC_CTRL needs to be per-vCPU. > > implementation-wise, being per-vCPU is simpler because, otherwise, once userspace > adjusts the hardware mitigations to enforce, KVM needs to kick all vCPUs. This > will add more complexity. +1, I even typed up as much before reading this paragraph. > And IMO, requiring guests to deploy same mitigations on vCPUs is an unnecessary > limitation. Yeah, I can see how it would make things weird for no good reason. So yeah, if the only thing stopping us from letting userspace deal with the virtual MSRs is converting to a vCPU-scoped ioctl(), then by all means, lets do that.
