From: Eduardo Habkost <ehabkost@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Andreas Färber" <afaerber@suse.de>,
qemu-devel@nongnu.org, kvm@vger.kernel.org,
"Aurelien Jarno" <aurelien@aurel32.net>
Subject: Re: [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 [thread overview]
Message-ID: <20140827163413.GL32084@thinpad.lan.raisama.net> (raw)
In-Reply-To: <53FE04C5.2070307@redhat.com>
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
prev parent reply other threads:[~2014-08-27 16:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-25 20:45 [PATCH v2 0/6] target-i386: Make most CPU models work with "enforce" out of the box Eduardo Habkost
2014-08-25 20:45 ` [PATCH v2 1/6] pc: Create pc_compat_2_1() functions Eduardo Habkost
2014-08-25 20:45 ` [PATCH v2 2/6] target-i386: Rename KVM auto-feature-enable compat function Eduardo Habkost
2014-08-25 20:45 ` [PATCH v2 3/6] target-i386: Disable CPUID_ACPI by default on KVM mode Eduardo Habkost
2014-08-25 20:45 ` [PATCH v2 4/6] target-i386: Remove unsupported bits from all CPU models Eduardo Habkost
2014-08-25 20:45 ` [PATCH v2 5/6] target-i386: Don't enable nested VMX by default Eduardo Habkost
2014-08-25 20:45 ` [PATCH v2 6/6] target-i386: Disable SVM by default in KVM mode Eduardo Habkost
2014-08-26 12:56 ` [PATCH v2 0/6] target-i386: Make most CPU models work with "enforce" out of the box Paolo Bonzini
2014-08-26 18:01 ` Eduardo Habkost
2014-08-27 13:36 ` Paolo Bonzini
2014-08-27 14:05 ` Eduardo Habkost
2014-08-27 14:33 ` Paolo Bonzini
2014-08-27 15:42 ` Eduardo Habkost
2014-08-27 15:58 ` Andreas Färber
2014-08-27 16:08 ` Eduardo Habkost
2014-08-27 16:14 ` Andreas Färber
2014-08-27 16:18 ` Paolo Bonzini
2014-08-27 16:34 ` Eduardo Habkost [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140827163413.GL32084@thinpad.lan.raisama.net \
--to=ehabkost@redhat.com \
--cc=afaerber@suse.de \
--cc=aurelien@aurel32.net \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox