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