All of
 help / color / mirror / Atom feed
From: Sean Christopherson <>
To: Andy Lutomirski <>
Cc: Xiaoyao Li <>,
	Paolo Bonzini <>,
	Thomas Gleixner <>,
	kvm list <>,
	LKML <>, X86 ML <>,
	Ingo Molnar <>, Borislav Petkov <>,
	"H. Peter Anvin" <>,
	Peter Zijlstra <>,
	Arvind Sankar <>,
	Tony Luck <>,
	Fenghua Yu <>
Subject: Re: [PATCH v9 3/8] x86/split_lock: Introduce flag X86_FEATURE_SLD_FATAL and drop sld_state
Date: Mon, 11 May 2020 11:17:44 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Sat, May 09, 2020 at 10:14:02PM -0700, Andy Lutomirski wrote:
> On Fri, May 8, 2020 at 8:03 PM Xiaoyao Li <> wrote:
> >
> > Introduce a synthetic feature flag X86_FEATURE_SLD_FATAL, which means
> > kernel is in sld_fatal mode if set.
> >
> > Now sld_state is not needed any more that the state of SLD can be
> Is it too much to ask for Intel to actually allocate and define a
> CPUID bit that means "this CPU *always* sends #AC on a split lock"?
> This would be a pure documentation change, but it would make this
> architectural rather than something that each hypervisor needs to hack
> up.

The original plan was to request a bit in MSR_TEST_CTRL be documented as
such.  Then we discovered that defining IA32_CORE_CAPABILITIES enumeration
as architectural was an SDM bug[*].  At that point, enumerating SLD to a
KVM guest through a KVM CPUID leaf is the least awful option.  Emulating the
model specific behavior doesn't provide userspace with a sane way to disable
SLD for a guest, and emulating IA32_CORE_CAPABILITIES behavior would be
tantamount to emulating model specific behavior.

Once paravirt is required for basic SLD enumeration, tacking on the "fatal"
indicator is a minor blip.

I agree that having to reinvent the wheel for every hypervisor is completely
ridiculous, but it provides well defined and controllable behavior.  We
could try to get two CPUID bits defined in the SDM, but pushing through all
the bureaucracy that gates SDM changes means we wouldn't have a resolution
for at least multiple months, assuming the proposal was even accepted.

> Meanwhile, I don't see why adding a cpufeature flag is worthwhile to
> avoid a less bizarre global variable.  There's no performance issue
> here, and the old code looked a lot more comprehensible than the new
> code.

The flag has two main advantages:

  - Automatically available to modules, i.e. KVM.
  - Visible to userspace in /proc/cpuinfo.

Making the global variable available to KVM is ugly because it either
requires exporting the variable and the enums (which gets especially nasty
because kvm_intel can be built with CONFIG_CPU_SUP_INTEL=n), or requires
adding a dedicated is_sld_fatal() wrapper and thus more exported crud.

And IMO, the feature flag is the less bizarre option once it's "public"
knowledge, e.g. more in line with features that enumerate both basic support
and sub-features via CPUID bits.

  reply	other threads:[~2020-05-11 18:17 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-09 11:05 [PATCH v9 0/8] KVM: Add virtualization support of split lock detection Xiaoyao Li
2020-05-09 11:05 ` [PATCH v9 1/8] x86/split_lock: Rename TIF_SLD to TIF_SLD_DISABLED Xiaoyao Li
2020-05-09 11:05 ` [PATCH v9 2/8] x86/split_lock: Remove bogus case in handle_guest_split_lock() Xiaoyao Li
2020-05-09 11:05 ` [PATCH v9 3/8] x86/split_lock: Introduce flag X86_FEATURE_SLD_FATAL and drop sld_state Xiaoyao Li
2020-05-10  5:14   ` Andy Lutomirski
2020-05-11 18:17     ` Sean Christopherson [this message]
2020-05-09 11:05 ` [PATCH v9 4/8] x86/split_lock: Introduce split_lock_virt_switch() and two wrappers Xiaoyao Li
2020-05-09 11:05 ` [PATCH v9 5/8] x86/kvm: Introduce paravirt split lock detection enumeration Xiaoyao Li
2020-05-09 11:05 ` [PATCH v9 6/8] KVM: VMX: Enable MSR TEST_CTRL for guest Xiaoyao Li
2020-05-09 11:05 ` [PATCH v9 7/8] KVM: VMX: virtualize split lock detection Xiaoyao Li
2020-05-09 11:05 ` [PATCH v9 8/8] x86/split_lock: Enable split lock detection initialization when running as an guest on KVM Xiaoyao Li
2020-05-10  5:15   ` Andy Lutomirski
2020-05-11  1:11     ` Xiaoyao Li
2020-05-18  1:27 ` [PATCH v9 0/8] KVM: Add virtualization support of split lock detection Xiaoyao Li
2020-05-26  6:19   ` Xiaoyao Li
2020-07-01  2:46 ` Xiaoyao Li

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.