On Tue, Jun 11, 2024, Chao Gao wrote: > >I continue find all of this unpalatable. The guest tells KVM what software > >mitigations the guest is using, and then KVM is supposed to translate that into > >some hardware functionality? And merge that with userspace's own overrides? > > Yes. It is ugly. I will drop all Intel-defined stuff from KVM. Actually, I > wanted to punt to userspace ... > > > > >Blech. > > > >With KVM_CAP_FORCE_SPEC_CTRL, I don't see any reason for KVM to support the > >Intel-defined virtual MSRs. If the userspace VMM wants to play nice with the > >Intel-defined stuff, then userspace can advertise the MSRs and use an MSR filter > >to intercept and "emulate" the MSRs. They should be set-and-forget MSRs, so > >there's no need for KVM to handle them for performance reasons. > > ... I had this idea of implementing policy-related stuff in userspace, and I wrote > in the cover-letter: > > """ > 1. the KVM<->userspace ABI defined in patch 1 > > I am wondering if we can allow the userspace to configure the mask > and the shadow value during guest's lifetime and do it on a vCPU basis. > this way, in conjunction with "virtual MSRs" or any other interfaces, > the usespace can adjust hardware mitigations applied to the guest during > guest's lifetime e.g., for the best performance. > """ Gah, sorry, I speed read the cover letter and didn't take the time to process that. > 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?
