Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Andy Lutomirski <luto@amacapital.net>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH 2/2] KVM: VMX: Extend VMX's #AC handding
Date:   Fri, 31 Jan 2020 12:57:51 -0800
Message-Id: <5CD544A4-291A-47A1-80D1-F77FE0444925@amacapital.net>
References: <20200131201743.GE18946@linux.intel.com>
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
In-Reply-To: <20200131201743.GE18946@linux.intel.com>
To:     Sean Christopherson <sean.j.christopherson@intel.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Jan 31, 2020, at 12:18 PM, Sean Christopherson <sean.j.christopherson@i=
ntel.com> wrote:
>=20
> =EF=BB=BFOn Sat, Feb 01, 2020 at 01:47:10AM +0800, Xiaoyao Li wrote:
>>> On 1/31/2020 11:37 PM, Andy Lutomirski wrote:
>>>=20
>>>> On Jan 30, 2020, at 11:22 PM, Xiaoyao Li <xiaoyao.li@intel.com> wrote:
>>>>=20
>>>> On 1/31/2020 1:16 AM, Andy Lutomirski wrote:
>=20
> ...
>=20
>>>>> Can we get a credible description of how this would work? I suggest: I=
ntel
>>>>> adds and documents a new CPUID bit or core capability bit that means
>>>>> =E2=80=9Csplit lock detection is forced on=E2=80=9D.  If this bit is s=
et, the MSR bit
>>>>> controlling split lock detection is still writable, but split lock
>>>>> detection is on regardless of the value.  Operating systems are expect=
ed
>>>>> 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 futu=
re
>>>>> CPUs that don=E2=80=99t implement split locks.
>>>>=20
>>>> It sounds a PV solution for virtualization that it doesn't need to be
>>>> defined in Intel-SDM but in KVM document.
>>>>=20
>>>> As you suggested, we can define new bit in KVM_CPUID_FEATURES (0x400000=
01)
>>>> as KVM_FEATURE_SLD_FORCED and reuse MSR_TEST_CTL or use a new virtualiz=
ed
>>>> MSR for guest to tell hypervisor it understand split lock detection is
>>>> forced on.
>>>=20
>>> Of course KVM can do this. But this missed the point. Intel added a new C=
PU
>>> feature, complete with an enumeration mechanism, that cannot be correctl=
y
>>> used if a hypervisor is present.
>>=20
>> Why it cannot be correctly used if a hypervisor is present? Because it ne=
eds
>> to disable split lock detection when running a vcpu for guest as this pat=
ch
>> wants to do?
>=20
> 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.
>=20
>>> As it stands, without specific hypervisor and guest support of a non-Int=
el
>>> interface, it is *impossible* to give architecturally correct behavior t=
o a
>>> guest. If KVM implements your suggestion, *Windows* guests will still
>>> malfunction on Linux.
>>=20
>> Actually, KVM don't need to implement my suggestion. It can just virtuali=
ze
>> 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.
>=20
> This is essentially what I proposed a while back.  KVM would allow enablin=
g
> split-lock #AC in the guest if and only if SMT is disabled or the enable b=
it
> 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 tha=
t
> it is pinning vCPUs.

How about covering the actual sensible case: host is set to fatal?  In this m=
ode, the guest gets split lock detection whether it wants it or not. How do w=
e communicate this to the guest?=