From: Sean Christopherson <seanjc@google.com>
To: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Cc: 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>,
Peter Zijlstra <peterz@infradead.org>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Andy Lutomirski <luto@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
Paolo Bonzini <pbonzini@redhat.com>,
tony.luck@intel.com, ak@linux.intel.com,
tim.c.chen@linux.intel.com,
Andrew Cooper <andrew.cooper3@citrix.com>,
Nikolay Borisov <nik.borisov@suse.com>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
kvm@vger.kernel.org,
Alyssa Milburn <alyssa.milburn@linux.intel.com>,
Daniel Sneddon <daniel.sneddon@linux.intel.com>,
antonio.gomez.iglesias@linux.intel.com
Subject: Re: [PATCH v5 6/6] KVM: VMX: Move VERW closer to VMentry for MDS mitigation
Date: Thu, 11 Jan 2024 08:45:13 -0800 [thread overview]
Message-ID: <ZaAbGWFEfUt1PX66@google.com> (raw)
In-Reply-To: <20240111-delay-verw-v5-6-a3b234933ea6@linux.intel.com>
On Thu, Jan 11, 2024, Pawan Gupta wrote:
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index bdcf2c041e0c..8defba8e417b 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -387,6 +387,17 @@ static __always_inline void vmx_enable_fb_clear(struct vcpu_vmx *vmx)
>
> static void vmx_update_fb_clear_dis(struct kvm_vcpu *vcpu, struct vcpu_vmx *vmx)
> {
> + /*
> + * FB_CLEAR_CTRL is to optimize VERW latency in guests when host is
> + * affected by MMIO Stale Data, but not by MDS/TAA. When
> + * X86_FEATURE_CLEAR_CPU_BUF is enabled, system is likely affected by
> + * MDS/TAA. Skip the optimization for such a case.
This is unnecessary speculation (ha!), and it'll also be confusing for many readers
as the code below explicitly checks for MDS/TAA. We have no idea why the host
admin forced the mitigation to be enabled, and it doesn't matter. The important
thing to capture is that the intent is to keep the mitigation enabled when it
was forcefully enabled, that should be self-explanatory and doesn't require
speculating on _why_ the mitigation was forced on.
> + */
> + if (cpu_feature_enabled(X86_FEATURE_CLEAR_CPU_BUF)) {
> + vmx->disable_fb_clear = false;
> + return;
> + }
> +
> vmx->disable_fb_clear = (host_arch_capabilities & ARCH_CAP_FB_CLEAR_CTRL) &&
> !boot_cpu_has_bug(X86_BUG_MDS) &&
> !boot_cpu_has_bug(X86_BUG_TAA);
I would rather include the X86_FEATURE_CLEAR_CPU_BUF check along with all the
other checks, and then add a common early return. E.g.
/*
* Disable VERW's behavior of clearing CPU buffers for the guest if the
* CPU isn't affected MDS/TAA, and the host hasn't forcefully enabled
* the mitigation. Disabing the clearing provides a performance boost
* for guests that aren't aware that manually clearing CPU buffers is
* unnecessary, at the cost of MSR accesses on VM-Entry and VM-Exit.
*/
vmx->disable_fb_clear = !cpu_feature_enabled(X86_FEATURE_CLEAR_CPU_BUF) &&
(host_arch_capabilities & ARCH_CAP_FB_CLEAR_CTRL) &&
!boot_cpu_has_bug(X86_BUG_MDS) &&
!boot_cpu_has_bug(X86_BUG_TAA);
if (!vmx->disable_fb_clear)
return;
next prev parent reply other threads:[~2024-01-11 16:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-11 8:56 [PATCH v5 0/6] Delay VERW Pawan Gupta
2024-01-11 8:56 ` [PATCH v5 1/6] x86/bugs: Add asm helpers for executing VERW Pawan Gupta
2024-01-11 8:56 ` [PATCH v5 2/6] x86/entry_64: Add VERW just before userspace transition Pawan Gupta
2024-01-11 8:56 ` [PATCH v5 3/6] x86/entry_32: " Pawan Gupta
2024-01-11 8:56 ` [PATCH v5 4/6] x86/bugs: Use ALTERNATIVE() instead of mds_user_clear static key Pawan Gupta
2024-01-11 8:56 ` [PATCH v5 5/6] KVM: VMX: Use BT+JNC, i.e. EFLAGS.CF to select VMRESUME vs. VMLAUNCH Pawan Gupta
2024-01-11 8:56 ` [PATCH v5 6/6] KVM: VMX: Move VERW closer to VMentry for MDS mitigation Pawan Gupta
2024-01-11 16:45 ` Sean Christopherson [this message]
2024-01-12 0:02 ` Pawan Gupta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZaAbGWFEfUt1PX66@google.com \
--to=seanjc@google.com \
--cc=ak@linux.intel.com \
--cc=alyssa.milburn@linux.intel.com \
--cc=andrew.cooper3@citrix.com \
--cc=antonio.gomez.iglesias@linux.intel.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=daniel.sneddon@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jpoimboe@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=nik.borisov@suse.com \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.com \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox