[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200131210424.GG18946@linux.intel.com>
Date: Fri, 31 Jan 2020 13:04:24 -0800
From: Sean Christopherson <sean.j.christopherson@...el.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: Xiaoyao Li <xiaoyao.li@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>,
Paolo Bonzini <pbonzini@...hat.com>, x86@...nel.org,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH 2/2] KVM: VMX: Extend VMX's #AC handding
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@...el.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.
Powered by blists - more mailing lists