On Wed, Jul 7, 2021 at 10:08 AM Eduardo Habkost <ehabkost@xxxxxxxxxx> wrote: > > On Wed, Jul 7, 2021 at 12:42 PM Jim Mattson <jmattson@xxxxxxxxxx> wrote: > > > > On Wed, Jul 7, 2021 at 8:09 AM Eduardo Habkost <ehabkost@xxxxxxxxxx> wrote: > > > > > > CCing libvir-list, Jiri Denemark, Michal Privoznik, so they are aware > > > that the definition of "supported CPU features" will probably become a > > > bit more complex in the future. > > > > Has there ever been a clear definition? Family, model, and stepping, > > for instance: are these the only values supported? That would make > > cross-platform migration impossible. What about the vendor string? Is > > that the only value supported? That would make cross-vendor migration > > impossible. For the maximum input value for basic CPUID information > > (CPUID.0H:EAX), is that the only value supported, or is it the maximum > > value supported? On the various individual feature bits, does a '1' > > imply that '0' is also supported, or is '1' the only value supported? > > What about the feature bits with reversed polarity (e.g. > > CPUID.(EAX=07H,ECX=0):EBX.FDP_EXCPTN_ONLY[bit 6])? > > > > This API has never made sense to me. I have no idea how to interpret > > what it is telling me. > > Is this about GET_SUPPORTED_CPUID, QEMU's query-cpu-model-expansion & > related commands, or the libvirt CPU APIs? This is my ongoing rant about KVM_GET_SUPPORTED_CPUID.
