From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Xiaoyao Li <xiaoyao.li@intel.com>,
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 13:04:24 -0800 [thread overview]
Message-ID: <20200131210424.GG18946@linux.intel.com> (raw)
In-Reply-To: <5CD544A4-291A-47A1-80D1-F77FE0444925@amacapital.net>
On Fri, Jan 31, 2020 at 12:57:51PM -0800, Andy Lutomirski wrote:
>
> > On Jan 31, 2020, at 12:18 PM, Sean Christopherson <sean.j.christopherson@intel.com> wrote:
> >
> > 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.
>
> How about covering the actual sensible case: host is set to fatal? In this
> mode, the guest gets split lock detection whether it wants it or not. How do
> we communicate this to the guest?
KVM doesn't advertise split-lock #AC to the guest and returns -EFAULT to the
userspace VMM if the guest triggers a split-lock #AC.
Effectively the same behavior as any other userspace process, just that KVM
explicitly returns -EFAULT instead of the process getting a SIGBUS.
next prev parent reply other threads:[~2020-01-31 21:04 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
2020-01-31 20:57 ` Andy Lutomirski
2020-01-31 21:04 ` Sean Christopherson [this message]
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=20200131210424.GG18946@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 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.