qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/3] target-i386: Don't trigger "check" warnings


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH 0/3] target-i386: Don't trigger "check" warnings by default in KVM mode
Date: Tue, 3 Nov 2015 14:41:29 -0200
User-agent: Mutt/1.5.23 (2014-03-12)

On Mon, Nov 02, 2015 at 12:37:24PM +0100, Paolo Bonzini wrote:
> 
> 
> On 30/10/2015 20:13, Eduardo Habkost wrote:
> > On Fri, Oct 30, 2015 at 05:00:57PM -0200, Eduardo Habkost wrote:
> >> The x86 change to make "check" mode be enabled by default made QEMU print a
> >> warning 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]
> >>
> >> Fix this by not enabling sse4a in qemu64 when in KVM mode.
> >>
> >> The long term solution will probably involve creating separate "tcg64" and
> >> "kvm64" CPU models as defaults, so we can finally choose completely 
> >> diffferent
> >> defaults in the KVM- and TCG-specific models without making the
> >> kvm_default_props list grow too mcuh.
> > 
> > Note that we can have a much simpler solution to this: disabling SSE4A
> > on qemu64 completely, even on TCG. This way we can use PC_COMPAT_2_4
> > instead of the kvm_default_props compat hack.
> > 
> > We can reenable SSE4A for TCG later (more exactly, we could enable
> > everything from TCG_*_FEATURES) when we implement the kvm64/tcg64
> > solution.
> > 
> > What do you think?
> 
> I would prefer that to this series.
> 
> Another possibility (even more of a hack, but perhaps acceptable) is to
> disable SSE4A in x86_cpu_load_def if kvm_enabled() and the host vendor
> is not AMD.  This is effectively what was already happening in 2.4 and
> earlier.

This was happening in 2.4 and earlier only if "check" or "enforce" was
not enabled by the user.

Also, that would make the resulting feature set of "-cpu <model>" be
different depending on the host CPU vendor, in addition to being
different depending on the accelerator. I would like to avoid that,
unless there's no other way.

-- 
Eduardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]