Received-SPF: pass (google.com: domain of linux-kernel+bounces-209972-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Tue, 11 Jun 2024 06:34:49 -0700
In-Reply-To: <ZmgrkMLuComwPl1X@chao-email>
Precedence: bulk
Mime-Version: 1.0
References: <20240410143446.797262-1-chao.gao@intel.com> <20240410143446.797262-10-chao.gao@intel.com>
 <ZmepkZfLIvj_st5W@google.com> <ZmgrkMLuComwPl1X@chao-email>
Message-ID: <ZmhSeZpyoYxACs-n@google.com>
Subject: Re: [RFC PATCH v3 09/10] KVM: VMX: Advertise MITI_CTRL_BHB_CLEAR_SEQ_S_SUPPORT
From: Sean Christopherson <seanjc@google.com>
To: Chao Gao <chao.gao@intel.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, 
	daniel.sneddon@linux.intel.com, pawan.kumar.gupta@linux.intel.com, 
	Zhang Chen <chen.zhang@intel.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, 
	"H. Peter Anvin" <hpa@zytor.com>
Content-Type: text/plain; charset="us-ascii"

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?