On Thu, Oct 5, 2023 at 9:35 AM Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > > On 10/5/23 09:22, Jim Mattson wrote: > > On Wed, Oct 4, 2023 at 12:59 AM Borislav Petkov <bp@xxxxxxxxx> 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? > >> > >> When you think about it, CPUID is the best thing we have. > > Every time a new defeature bit is introduced, it breaks existing > > hypervisors, because no one can predict ahead of time that these bits > > have to be passed through. > > > > I wonder if we could convince x86 CPU vendors to put all defeature > > bits under a single leaf, so that we can just set the entire leaf to > > all 1's in KVM_GET_SUPPORTED_CPUID. > > I hope I'm not throwing stones from a glass house here... > > But I'm struggling to think of cases where Intel has read-only > "defeature bits" like this one. There are certainly things like > MSR_IA32_MISC_ENABLE_FAST_STRING that can be toggled, but read-only > indicators of a departure from established architecture seems ... > suboptimal. > > It's arguable that TDX changed a bunch of architecture like causing > exceptions on CPUID and MSRs that never caused exceptions before and > _that_ constitutes a defeature. But that's the least of the problems > for a TDX VM. :) > > (Seriously, I'm not trying to shame Intel's x86 fellow travelers here, > just trying to make sure I'm not missing something). Intel's defeature bits that I know of are: CPUID.(EAX=7,ECX=0):EBX[bit 13] (Haswell) - "Deprecates FPU CS and FPU DS values if 1." CPUID.(EAX=7,ECX=0):EBX[bit 6] (Skylake) - "FDP_EXCPTN_ONLY. x87 FPU Data Pointer updated only on x87 exceptions if 1."
