lkml.org 
[lkml]   [2021]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 4/4] x86/tsx: Add cmdline tsx=fake to not clear CPUID bits RTM and HLE
    On Wed, Jul 7, 2021 at 10:08 AM Eduardo Habkost <ehabkost@redhat.com> wrote:
    >
    > On Wed, Jul 7, 2021 at 12:42 PM Jim Mattson <jmattson@google.com> wrote:
    > >
    > > On Wed, Jul 7, 2021 at 8:09 AM Eduardo Habkost <ehabkost@redhat.com> 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.

    \
     
     \ /
      Last update: 2021-07-07 19:19    [W:2.951 / U:0.448 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site