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


> 
> >> 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,
> 
> Good.
> 
> > except for the "same meaning to -cpu host" part. What exactly would you
> > expect "-cpu host" to mean on TCG?
> 
> Emulate (as much as possible of) a SandyBridge if I'm running on a
> SandyBridge, etc.
> 
> "-cpu qemu64" would be the best CPU that TCG can do, with a standard
> family/model/stepping/vendor slapped on top.

Makes sense to me.

-- 
Eduardo