On Mon, Jan 17, 2022 at 12:57 PM Jim Mattson <jmattson@xxxxxxxxxx> wrote: > > On Sun, Jan 16, 2022 at 8:26 PM Like Xu <like.xu.linux@xxxxxxxxx> wrote: > ... > > It's easy for KVM to clear the reserved bit PERF_CTL2[43] > > for only (AMD Family 19h Models 00h-0Fh) guests. > > KVM is currently *way* too aggressive about synthesizing #GP for > "reserved" bits on AMD hardware. Note that "reserved" generally has a > much weaker definition in AMD documentation than in Intel > documentation. When Intel says that an MSR bit is "reserved," it means > that an attempt to set the bit will raise #GP. When AMD says that an > MSR bit is "reserved," it does not necessarily mean the same thing. > (Usually, AMD will write MBZ to indicate that the bit must be zero.) > > On my Zen3 CPU, I can write 0xffffffffffffffff to MSR 0xc0010204, > without getting a #GP. Hence, KVM should not synthesize a #GP for any > writes to this MSR. > > Note that the value I get back from rdmsr is 0x30fffdfffff, so there > appears to be no storage behind bit 43. If KVM allows this bit to be > set, it should ensure that reads of this bit always return 0, as they > do on hardware. Bit 19 (Intel's old Pin Control bit) seems to have storage behind it. It is interesting that in Figure 13-7 "Core Performance Event-Select Register (PerfEvtSeln)" of the APM volume 2, this "reserved" bit is not marked in grey. The remaining "reserved" bits (which are marked in grey), should probably be annotated with "RAZ."
