On 10/4/23 09:58, Borislav Petkov wrote:
On Tue, Oct 03, 2023 at 07:44:51PM -0700, Jim Mattson wrote:
The business of declaring breaking changes to the architectural
specification in a CPUID bit has never made much sense to me.
How else should they be expressed then?
In some flaky PDF which changes URLs whenever the new corporate CMS gets
installed?
Or we should do f/m/s matching which doesn't make any sense for VMs?
Nothing *needs* to be done other than documenting this retroactive
change to what constitutes architectural behavior. It's not a CPUID
that can be queried to change behavior; the user can use CPUID to
diagnose that something has broken, but the broken program cannot know
in the first place that the CPUID bit exists.
I agree with Jim that it would be nice to have some bits from Intel, and
some bits from AMD, that current processors always return as 1. Future
processors can change those to 0 as desired.
Intel did something similar with VMX. They have a bunch of bits for
which we don't know the meaning, but we know it is something that "right
now always causes vmexits". Even if in the future you might be able to
disable it, the polarity of the bit is the same as for all other vmexit
controls.
Paolo
