> > > > Could you please tell me what the Windows's wrong code is? And what's > > > > wrong when someone is following the hardware spec? > > > > > > the reason is that it's reserved on AMD hence software shouldn't even try > > > to use it or make any decisions based on that. > > > > > > > > > PS: > > > on contrary, doing such ad-hoc 'cleanups' for the sake of misbehaving > > > guest would actually complicate QEMU for no big reason. > > > > The guest is not misbehaving. It is following the spec. > > (That's my thinking, and please feel free to correct me.) > > I had the same thought. Windows guys could also say they didn't access > the reserved MSR unconditionally, and they followed the CPUID feature > bit to access that MSR. When CPUID is set, it indicates that feature is > implemented. > > At least I think it makes sense to rely on the CPUID to access the MSR. > Just as an example, it's unlikely that after the software finds a CPUID > of 1, it still need to download the latest spec version to confirm > whether the feature is actually implemented or reserved.
If the encountered feature bit is indeed not expected (truly reserved), the processor would be considered faulty and may be fixed in a new stepping. This is similar to the debate over whether software should adhere to the spec or whether hardware (emulation) should comply. > Based on the above point, this CPUID feature bit is set to 1 in KVM and > KVM also adds emulation (as a fix) specifically for this MSR. This means > that Guest is considered to have valid access to this feature MSR, > except that if Guest doesn't get what it wants, then it is reasonable > for Guest to assume that the current (v)CPU lacks hardware support and > mark it as "unsupported processor".
