On Tue, Dec 20, 2022, Chao Gao wrote: > On Mon, Dec 19, 2022 at 05:14:00PM +0000, Sean Christopherson wrote: > >On Mon, Dec 19, 2022, Chao Gao wrote: > >> On Wed, Dec 14, 2022 at 08:18:17PM +0000, Sean Christopherson wrote: > >> > To me, this looks like Intel is foisting a paravirt interface on KVM and other > >> > hypervisors without collaborating with said hypervisors' developers and maintainers. > >> > > >> >I get that some of the mitigations are vendor specific, but things like RETPOLINE > >> >aren't vendor specific. I haven't followed all of the mitigation stuff very > >> >closely, but I wouldn't be surprised if there are mitigations now or in the future > >> >that are common across architectures, e.g. arm64 and x86-64. Intel doing its own > >> >thing means AMD and arm64 will likely follow suit, and suddenly KVM is supporting > >> >multiple paravirt interfaces for very similar things, without having any control > >> >over the APIs. That's all kinds of backwards. > >> > >> But if the interface is defined by KVM rather than Intel, it will likely end up > >> with different interfaces for different VMMs, then Linux guest needs to support > >> all of them. And KVM needs to implement Hyper-V's and Xen's interface to support > >> Hyper-V enlightened and Xen enlightened guest. This is a _real_ problem and > >> complicates KVM/Linux in a similar way as multiple paravirt interfaces. > > > >I never said the PV interfaces should be defined by KVM. I 100% agree that any > >one hypervisor defining its own interface will suffer the same problem. > > I am thinking there are only two options: > > 1. Intel defines the interface. > 2. Every VMM defines its own interface. > > Any middle ground between the two options? Work with other x86 hardware vendors to define a common interface? Ask hypervisor developers to define a common, extensible interface? Maybe it turns out that it's impossible to abstract anything away and everything ends up being vendor-specific anyways, but not even trying to provide a common interace is extremely frustrating, especially since all this mitigation stuff has been going on for ~5 years. There's been plenty of time to establish relationships and points of contact. > >I think having a PV interface for coordinating mitigations between host and guest > >is a great idea. What I don't like is tying the interface to "hardware" and defining > > Do you think something below is better than the intel-defined interface? No, KVM doing its own thing would only exacerbate the issue. > add a new KVM_CAP_* and a KVM_FEATURE_* in hypervisor CPUID leaf to enumerate > the interface. And add a new virtual MSR 0x4b564dxx for guest to report in-use > software mitigations and assign one bit for each software mitigation. On MSR > write emulation, call into vmx code to enable some hardware mitigations if > the corresponding software mitigations are not effective on host. > > I am afraid it is late to switch to above approach because e.g., if Hyper-V > decides to support the intel-defined interface, KVM probably needs to support it > for Hyper-V guests. Hence my frustration.
