Re: [Qemu-devel] [PATCH v2 0/3] target-i386: Don't trigger CPUID warnings by default in KVM mode (in most hosts)

[Eduardo Habkost]

On Tue, Nov 03, 2015 at 09:22:30PM +0100, Paolo Bonzini wrote:
> On 03/11/2015 20:58, Eduardo Habkost wrote:
> > The x86 change to make "check" mode be enabled by default made QEMU print
> > warnings in the default case if running in an Intel host:
> > 
> >   $ qemu-system-x86_64 -machine pc,accel=kvm
> >   warning: host doesn't support requested feature: 
> > CPUID.80000001H:ECX.sse4a [bit 6]
> > 
> > There's also a warning when about missing the ABM feature if running on a 
> > Sandy
> > Bridge or older host.
> > 
> > ABM is not available on Sandy Bridge and older, SSE4a is not available in 
> > any
> > Intel host. We want to make the default CPU runnable in most hosts, so those
> > features won't be enabled by default in KVM mode.
> > 
> > We should eventually have all features supported by TCG enabled by default 
> > in
> > TCG mode, but as we don't have a good mechanism today to ensure we have
> > different defaults in KVM and TCG mode, disable ABM and SSE4a in the qemu64 
> > CPU
> > model entirely.
> > 
> > Also, as we can't change the guest ABI in pc-*-2.4, disable "check" mode by
> > default in pc-*-2.4 and older so we don't print spurious warnings.
> > 
> > Note that with this change, the qemu64 CPU model still requires a host
> > supporting POPCNT (Nehalem or newer, and Opteron_G3 or newer).
> 
> Do we want to remove that one as well?

Probably, yes. libvirt even has these commented out in their cpu_map.xml:

    <model name='qemu64'>
      <model name='kvm64'/>
      <!-- These are supported only by TCG.  KVM supports them only if the
           host does.  So we leave them out:

           <feature name='popcnt'/>
           <feature name='lahf_lm'/>
           <feature name='sse4a'/>
           <feature name='abm'/>
      -->
      <feature name='svm'/>
    </model>

(libvirt must stop making assumptions about the CPU model feature sets so
all <feature> elements in cpu_map.xml should go away. But at least the
current cpu_map.xml is a good reference to what it expects today.)

-- 
Eduardo