Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6;
Date:   Wed, 4 Oct 2023 17:10:31 -0700
In-Reply-To: <e8993457-9e28-434a-b4e8-25ffcbee6517@maciej.szmigiero.name>
Mime-Version: 1.0
References: <0ffde769702c6cdf6b6c18e1dcb28b25309af7f7.1695659717.git.maciej.szmigiero@oracle.com>
 <ZRHRsgjhOmIrxo0W@google.com> <8c6a1fc8-2ac5-4767-8b02-9ef56434724e@maciej.szmigiero.name>
 <ZRHckCMwOv3jfSs7@google.com> <ac402dd4-8bf3-87a8-7ade-50d62997ce97@amd.com> <e8993457-9e28-434a-b4e8-25ffcbee6517@maciej.szmigiero.name>
Message-ID: <ZR3-90IQqb3mSV-b@google.com>
Subject: Re: [PATCH] KVM: x86: Ignore MSR_AMD64_BU_CFG access
From:   Sean Christopherson <seanjc@google.com>
To:     "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>
Cc:     Paolo Bonzini <pbonzini@redhat.com>,
        Borislav Petkov <bp@alien8.de>, kvm@vger.kernel.org,
        x86@kernel.org, linux-kernel@vger.kernel.org,
        Tom Lendacky <thomas.lendacky@amd.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Oct 02, 2023, Maciej S. Szmigiero wrote:
> On 26.09.2023 00:25, Tom Lendacky wrote:
> > > > It's partially documented in various AMD BKDGs, however I couldn't =
find
> > > > any definition for this particular bit (8) - other than that it is =
reserved.
> > >=20
> > > I found it as MSR_AMD64_BU_CFG for Model 16h, but that's Jaguar/Puma,=
 not Zen1.
> > > My guess is that Windows is trying to write this thing:
> > >=20
> > > =C2=A0=C2=A0 MSRC001_1023 [Table Walker Configuration] (Core::X86::Ms=
r::TW_CFG)
> > > =C2=A0=C2=A0 Read-write. Reset: 0000_0000_0000_0000h.
> > > =C2=A0=C2=A0 _lthree0_core[3,1]; MSRC001_1023
> > >=20
> > > =C2=A0=C2=A0 Bits=C2=A0=C2=A0 Description
> > > =C2=A0=C2=A0 63:50=C2=A0 Reserved.
> > > =C2=A0=C2=A0 49=C2=A0=C2=A0=C2=A0=C2=A0 TwCfgCombineCr0Cd: combine CR=
0_CD for both threads of a core. Read-write. Reset: 0. Init: BIOS,1.
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1=3DThe host C=
r0_Cd values from the two threads are OR'd together and used by both thread=
s.
> > > =C2=A0=C2=A0 48:0=C2=A0=C2=A0 Reserved.
> > >=20
> > > Though that still doesn't explain bit 8...=C2=A0 Perhaps a chicken-bi=
t related to yet
> > > another speculation bug?
> > >=20
> > > Boris or Tom, any idea what Windows is doing?=C2=A0 I doubt it change=
s our options in
> > > terms of "fixing" this in KVM, but having a somewhat accurate/helpful=
 changelog
> > > would be nice.
> >=20
> > It's definitely not related to a speculation bug, but I'm unsure what w=
as
> > told to Microsoft that has them performing that WRMSR. The patch does t=
he
> > proper thing, though, as a guest shouldn't be updating that setting.
> >=20
> > And TW_CFG is the proper name of that MSR for Zen.
>=20
> So, should I prepare v2 with MSR_AMD64_BU_CFG -> MSR_AMD64_TW_CFG change?

If we can get Paolo's attention, I'd like to get his thoughts on punting th=
is
to QEMU/userspace.  I'm worried that "handling" uarch specific MSRs in KVM =
is
going to paint us into a corner and force KVM to check guest F/M/S someday,=
 which
I want to avoid at pretty much all costs.