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.