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

[Eduardo Habkost]

On Tue, Nov 03, 2015 at 06:21:57PM +0100, Paolo Bonzini wrote:
> 
> 
> On 03/11/2015 17:41, Eduardo Habkost wrote:
> > 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.
> 
> IIUC the machine would not have started at all (in the "enforce" case)
> or would have had sse4a masked anyway (in the "check" case).  So there
> would be no guest ABI change.
> 
> > 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.
> 
> It already was in the past versions, and we would have to keep the
> "feature" to maintain guest ABI for past machine types, wouldn't we?
> Features that KVM doesn't support are masked by x86_cpu_filter_features.

Yes, it would be encoding the previous host-CPU-dependent behavior in
the code, permanently. But I would prefer to simply trigger warnings
when using "-machine pc-2.4", than having to maintain the hack in the
code forever.

(As you said, there's no ABI change, so we don't have to keep the hack
there to maintain guest ABI, but just to avoid warnings when using
pc-2.4).

BTW, we have the same problem with ABM (see my previous message) and in
that case we can't just implement a hack to disable it depending on the
host CPU.

-- 
Eduardo