Re: [PATCH] i386/cpu: ARCH_CAPABILITIES should not be advertised on AMD

[Zhao Liu <zhao1.liu@intel.com>]

> > > > 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".