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: Paolo Bonzini
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 18:18:13 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0

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.

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

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

Paolo



reply via email to

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