Re: [Qemu-devel] [PATCH v2 0/6] target-i386: Make most CPU models work with "enforce" out of the box

[Eduardo Habkost]

On Wed, Aug 27, 2014 at 05:58:49PM +0200, Andreas Färber wrote:
> Am 27.08.2014 17:42, schrieb Eduardo Habkost:
> > On Wed, Aug 27, 2014 at 04:33:54PM +0200, Paolo Bonzini wrote:
> >> Il 27/08/2014 16:05, Eduardo Habkost ha scritto:
> >>> On Wed, Aug 27, 2014 at 03:36:51PM +0200, Paolo Bonzini wrote:
> >>>> Il 26/08/2014 20:01, Eduardo Habkost ha scritto:
> >>>>> So maybe that's good news, as things can be simpler if we make both TCG
> >>>>> and KVM have similar behavior:
> >>>>>
> >>>>> * qemu64: a conservative default that should work out of the box on
> >>>>>   most systems, for both TCG and KVM. That's already the current status,
> >>>>>   we just need to document it.
> >>>>>
> >>>>> * -cpu host: for people who want every possible feature to be enabled
> >>>>>   (but without cross-version live-migration support). We can easily add
> >>>>>   support for "-cpu host" to TCG, too.
> >>>>
> >>>> This means that "-cpu host" has different meanings in KVM and TCG.  Is
> >>>> that an advantage or a disadvantage?
> >>>
> >>> It is the same meaning to me: "enable everything that's possible,
> >>> considering what's provided by the underlying accelerator". The "host"
> >>> name is misleading, though, because on KVM it is close to the host CPU,
> >>> but on TCG it depends solely on TCG's capabilities.
> >>
> >> True.  It's not very intuitive, but it is the same concept for processor
> >> capabilities.
> >>
> >> Though for some leaves that do not correspond to processor capabilities,
> >> "-cpu host" does set them to the host values.  This is not just the
> >> cache model, but also the family/model/stepping/vendor.
> >>
> >> For the TCG case, when running on a Nehalem it would be weird to see a
> >> Nehalem guest with SMAP or ADOX support...  I'm not sure it would even
> >> work to have SVM with an Intel vendor. :)
> > 
> > In that case, the best family/model/stepping/vendor choice depends on
> > TCG capabilities (defined at compile time), not on the host CPU.
> > 
> > ...and that proves your point: if we aren't even using the host CPU
> > family/model/stepping, calling it "-cpu host" doesn't make much sense.
> > If it is so different from the host model, we can call it "qemu64" (and
> > do as you suggests below).
> 
> Might that be an opportunity to reconsider a -cpu best or so,
> independent of its implementation, to avoid "host"?

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".

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.

(If we didn't have existing libvirt code assuming "qemu64" is always the
default in QEMU, we could simply get rid of "qemu64" and use better
names. We may get rid of "qemu64" later, but we need to provide a way
for libvirt to stop using it, first.)

-- 
Eduardo