Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 22 Dec 2022 18:31:59 +0000
From:   Sean Christopherson <seanjc@google.com>
To:     Chao Gao <chao.gao@intel.com>
Cc:     Zhang Chen <chen.zhang@intel.com>, x86@kernel.org,
        linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
        Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC PATCH 5/9] x86/bugs: Use Virtual MSRs to request hardware
 mitigations
Message-ID: <Y6Sin1bmLN10yvMw@google.com>
References: <20221210160046.2608762-1-chen.zhang@intel.com>
 <20221210160046.2608762-6-chen.zhang@intel.com>
 <Y5oviY0471JytWPo@google.com>
 <Y6BtcutjgcgE8dsv@gao-cwp>
 <Y6Cb2OrkQ8X3IvW5@google.com>
 <Y6G77CTIk8CvtTLn@gao-cwp>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y6G77CTIk8CvtTLn@gao-cwp>
Precedence: bulk

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.