From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Xiaoyao Li <xiaoyao.li@intel.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Paolo Bonzini <pbonzini@redhat.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org
Subject: Re: [PATCH 2/2] KVM: VMX: Extend VMX's #AC handding
Date: Fri, 31 Jan 2020 12:17:43 -0800 [thread overview]
Message-ID: <20200131201743.GE18946@linux.intel.com> (raw)
In-Reply-To: <df8f7580-9e7d-bc49-30c0-eca517f8db44@intel.com>
On Sat, Feb 01, 2020 at 01:47:10AM +0800, Xiaoyao Li wrote:
> On 1/31/2020 11:37 PM, Andy Lutomirski wrote:
> >
> >>On Jan 30, 2020, at 11:22 PM, Xiaoyao Li <xiaoyao.li@intel.com> wrote:
> >>
> >> On 1/31/2020 1:16 AM, Andy Lutomirski wrote:
...
> >>>Can we get a credible description of how this would work? I suggest: Intel
> >>>adds and documents a new CPUID bit or core capability bit that means
> >>>“split lock detection is forced on”. If this bit is set, the MSR bit
> >>>controlling split lock detection is still writable, but split lock
> >>>detection is on regardless of the value. Operating systems are expected
> >>>to set the bit to 1 to indicate to a hypervisor, if present, that they
> >>>understand that split lock detection is on. This would be an SDM-only
> >>>change, but it would also be a commitment to certain behavior for future
> >>>CPUs that don’t implement split locks.
> >>
> >>It sounds a PV solution for virtualization that it doesn't need to be
> >>defined in Intel-SDM but in KVM document.
> >>
> >>As you suggested, we can define new bit in KVM_CPUID_FEATURES (0x40000001)
> >>as KVM_FEATURE_SLD_FORCED and reuse MSR_TEST_CTL or use a new virtualized
> >>MSR for guest to tell hypervisor it understand split lock detection is
> >>forced on.
> >
> >Of course KVM can do this. But this missed the point. Intel added a new CPU
> >feature, complete with an enumeration mechanism, that cannot be correctly
> >used if a hypervisor is present.
>
> Why it cannot be correctly used if a hypervisor is present? Because it needs
> to disable split lock detection when running a vcpu for guest as this patch
> wants to do?
Because SMT. Unless vCPUs are pinned 1:1 with pCPUs, and the guest is
given an accurate topology, disabling/enabling split-lock #AC may (or may
not) also disable/enable split-lock #AC on a random vCPU in the guest.
> >As it stands, without specific hypervisor and guest support of a non-Intel
> >interface, it is *impossible* to give architecturally correct behavior to a
> >guest. If KVM implements your suggestion, *Windows* guests will still
> >malfunction on Linux.
>
> Actually, KVM don't need to implement my suggestion. It can just virtualize
> and expose this feature (MSR_IA32_CORE_CAPABILITIES and MSR_TEST_CTRL) to
> guest, (but it may have some requirement that HT is disabled and host is
> sld_off) then guest can use it architecturally.
This is essentially what I proposed a while back. KVM would allow enabling
split-lock #AC in the guest if and only if SMT is disabled or the enable bit
is per-thread, *or* the host is in "warn" mode (can live with split-lock #AC
being randomly disabled/enabled) and userspace has communicated to KVM that
it is pinning vCPUs.
next prev parent reply other threads:[~2020-01-31 20:18 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-30 12:19 [PATCH 0/2] kvm: split_lock: Fix emulator and extend #AC handler Xiaoyao Li
2020-01-30 12:19 ` [PATCH 1/2] KVM: x86: Emulate split-lock access as a write Xiaoyao Li
2020-01-30 12:31 ` David Laight
2020-01-30 15:16 ` Andy Lutomirski
2020-01-31 20:01 ` Sean Christopherson
2020-02-04 14:47 ` Vitaly Kuznetsov
2020-02-10 21:59 ` Sean Christopherson
2020-01-30 12:19 ` [PATCH 2/2] KVM: VMX: Extend VMX's #AC handding Xiaoyao Li
2020-01-30 15:18 ` Andy Lutomirski
2020-01-30 16:29 ` Xiaoyao Li
2020-01-30 17:16 ` Andy Lutomirski
2020-01-31 7:22 ` Xiaoyao Li
2020-01-31 15:37 ` Andy Lutomirski
2020-01-31 17:47 ` Xiaoyao Li
2020-01-31 20:17 ` Sean Christopherson [this message]
2020-01-31 20:57 ` Andy Lutomirski
2020-01-31 21:04 ` Sean Christopherson
2020-01-31 21:33 ` Andy Lutomirski
2020-02-01 16:58 ` Xiaoyao Li
2020-02-01 17:56 ` Andy Lutomirski
2020-02-02 4:33 ` Xiaoyao Li
2020-02-03 18:49 ` Andy Lutomirski
2020-02-04 6:03 ` Sean Christopherson
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=20200131201743.GE18946@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=xiaoyao.li@intel.com \
/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;
as well as URLs for NNTP newsgroup(s).