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 11:05:35 -0300
User-agent: Mutt/1.5.23 (2014-03-12)

On Wed, Aug 27, 2014 at 03:36:51PM +0200, Paolo Bonzini wrote:
> Il 26/08/2014 20:01, Eduardo Habkost ha scritto:
> > On Tue, Aug 26, 2014 at 02:56:21PM +0200, Paolo Bonzini wrote:
> >> Il 25/08/2014 22:45, Eduardo Habkost ha scritto:
> >>>
> >>> TCG users expect the default CPU model to contain most TCG-supported 
> >>> features
> >>> (and it makes sense). See, for example, commit
> >>> f1e00a9cf326acc1f2386a72525af8859852e1df.
> >>
> >> It doesn't though (SMAP is the most egregious omission, and probably the
> >> main reason why people use QEMU TCG these days), and it raises the
> >> question of backwards-compatibility of qemu64---should we disable TCG
> >> features in old machine types?  Probably yes, but we've never done that.
> > 
> > Had we changed qemu64, any changes to the feature set of qemu64 would
> > probably require compatibility code on old machine-types for KVM,
> > anyway. But the last time qemu64 was changed was in 2009 (commit
> > f1e00a9cf326acc1f2386a72525af8859852e1df), it looks like everybody was
> > afraid of touching "qemu64" because its purpose was not very clear.
> > 
> > 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.

> 
> If I have to choose blindly, I'd rather give different (but sane)
> meanings to "-cpu qemu64" and the same meanings to "-cpu host"...
> Basically "-cpu qemu32/64" on KVM would be changed automatically to
> kvm32/64.

This (different meanings to qemu64) is what I was proposing first,
except for the "same meaning to -cpu host" part. What exactly would you
expect "-cpu host" to mean on TCG?

-- 
Eduardo



reply via email to

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