qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 0/6] target-i386: Make most CPU models work w


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH v2 0/6] target-i386: Make most CPU models work with "enforce" out of the box
Date: Wed, 27 Aug 2014 13:34:13 -0300
User-agent: Mutt/1.5.23 (2014-03-12)

On Wed, Aug 27, 2014 at 06:18:13PM +0200, Paolo Bonzini wrote:
> Il 27/08/2014 18:08, Eduardo Habkost ha scritto:
> > > Might that be an opportunity to reconsider a -cpu best or so,
> > > independent of its implementation, to avoid "host"?
> 
> Nowadays we have CPU models added way before silicon is available, and
> "-cpu host" in practice should be migratable (the big exception being
> nested VMX and, when running on KVM, nested SVM).  What would "-cpu
> best" be useful for?
> 
> > It depends on what you expect "-cpu best" to mean. I have seen different
> > meanings being proposed for it.
> > 
> > IIRC, "best" was proposed to mean "choose the best one from the existing
> > (predefined) CPU models", not "enable everything possible, not even
> > looking at the CPU model table".
> 
> How do you define "best"?  You could have a model that lacks feature F1
> and a model that lacks feature F2.

That's one reason we never implemented it. :)

In other words: deciding what's really "best" is not something that can
be decided by QEMU alone.

> 
> Adding features on top of an existing model is what libvirt's <cpu
> mode='host-model'/> element does, and it's broken.  It's broken because
> some features do not work unless you also bump the level (for example
> xsave, my favorite example for CPUID bugs, requires leaf 0xD to be present).

I want to fix that. We have existing code to bump level when features on
leaf 0x7 are present, and there's no reason we can't generalize that to
all features that need a specific leaf to be present. We just need to be
careful to keep backwards compatibility.

> 
> > Anyway, it makes sense to have a name for the "enable everything" mode
> > (whatever it is), and simply make "qemu64" an alias to it when in TCG
> > mode.
> 
> Or conversely, say "qemu64" is { baseline for KVM, enable-everything for
> TCG }.  Then "-cpu best" and "-cpu qemu64" would effectively be synonyms
> on TCG.

This is another way to see it. But I prefer to treat it as just a
(temporary?) alias to a meaningful model name, because the only reason
we are keeping the "qemu64" name (instead of simply making "-cpu
best/maximum/whatever" the default on TCG and "-cpu kvm64" the default
on KVM) is for compatibility with existing management code.

-- 
Eduardo



reply via email to

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