> -----Original Message----- > From: Sean Christopherson <seanjc@xxxxxxxxxx> > Sent: Friday, December 23, 2022 2:32 AM > To: Gao, Chao <chao.gao@xxxxxxxxx> > Cc: Zhang, Chen <chen.zhang@xxxxxxxxx>; x86@xxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx; Pawan Gupta > <pawan.kumar.gupta@xxxxxxxxxxxxxxx>; Paolo Bonzini > <pbonzini@xxxxxxxxxx>; H. Peter Anvin <hpa@xxxxxxxxx>; Dave Hansen > <dave.hansen@xxxxxxxxxxxxxxx>; Borislav Petkov <bp@xxxxxxxxx>; Ingo > Molnar <mingo@xxxxxxxxxx>; Thomas Gleixner <tglx@xxxxxxxxxxxxx> > Subject: Re: [RFC PATCH 5/9] x86/bugs: Use Virtual MSRs to request hardware > mitigations > > 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. Hi Sean, Rethink about it and synced with Chao, we didn't think of a better solution than Intel-defined interface. If you have no more suggestions/comments here, please review the rest of patches from this series when you have time. I will try to address comments and push this series to RFC V2. Thanks Chen > > > 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.
