Re: [PATCH] KVM: x86: Ignore MSR_AMD64_BU_CFG access

[Sean Christopherson <seanjc@google.com>]

On Thu, Oct 05, 2023, Maciej S. Szmigiero wrote:
> On 5.10.2023 02:10, Sean Christopherson wrote:
> > 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.
> > > > > 
> > > > > 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:
> > > > > 
> > > > >     MSRC001_1023 [Table Walker Configuration] (Core::X86::Msr::TW_CFG)
> > > > >     Read-write. Reset: 0000_0000_0000_0000h.
> > > > >     _lthree0_core[3,1]; MSRC001_1023
> > > > > 
> > > > >     Bits   Description
> > > > >     63:50  Reserved.
> > > > >     49     TwCfgCombineCr0Cd: combine CR0_CD for both threads of a core. Read-write. Reset: 0. Init: BIOS,1.
> > > > >            1=The host Cr0_Cd values from the two threads are OR'd together and used by both threads.
> > > > >     48:0   Reserved.
> > > > > 
> > > > > Though that still doesn't explain bit 8...  Perhaps a chicken-bit related to yet
> > > > > another speculation bug?
> > > > > 
> > > > > Boris or Tom, any idea what Windows is doing?  I doubt it changes our options in
> > > > > terms of "fixing" this in KVM, but having a somewhat accurate/helpful changelog
> > > > > would be nice.
> > > > 
> > > > It's definitely not related to a speculation bug, but I'm unsure what was
> > > > told to Microsoft that has them performing that WRMSR. The patch does the
> > > > proper thing, though, as a guest shouldn't be updating that setting.
> > > > 
> > > > And TW_CFG is the proper name of that MSR for Zen.
> > > 
> > > 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 this
> > 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.
> 
> We already do similar ignoring in KVM for MSR_AMD64_BU_CFG2, MSR_AMD64_DC_CFG
> and MSR_F15H_EX_CFG, so doing this {BU_CFG2,TW_CFG} MSR filtering in QEMU would
> be inconsistent with these.

Not if QEMU filters those too. :-)

The MSR filter mechanism wasn't a thing back when KVM added "support" for those
MSR, so I don't feel that punting to userspace would be inconsistent.  It's more
along the lines of asking/requiring userspace to utilize a new tool to solve a
problem that is best solved in userspace, with a few outliers that got
grandfathered in.

Anyways, yeah, let's get Paolo's feedback.