On 09.11.19 17:07, Peter Maydell wrote:
On Fri, 8 Nov 2019 at 19:11, Eduardo Habkost <ehabk...@redhat.com> wrote:
On Fri, Nov 08, 2019 at 01:02:28PM +0000, Peter Maydell wrote:
On Fri, 8 Nov 2019 at 12:46, David Hildenbrand <da...@redhat.com> wrote:
There is a small but important difference between "max"/"host" and
"best". Max really means "all features", including deprecated ones.
"best", however, can disable experimental or deprecated features. Or any
other features we don't want to be enabled when somebody selects a model
manually.
On x86, this is implemented by "host". "max" gives you the full
set of features that can be enabled by the user. "host" gives
you a reasonable set of features you will want to see enabled by
default when the user says "use the host CPU".
How does "host" work for TCG on x86?
I think just like on s390x, host is limited to KVM only.
Hmm. I see the distinction, but is it one that's sufficiently
worth making that we want to expose it to our users, possibly
try to add it to the other architectures, etc ? How bad is it
if the CPU provides some legacy deprecated feature that the
guest just doesn't use ?
"max" isn't something we want to expose to end users. It is
something we need to expose to other software components.
We seem to have a disagreement here about what 'max' is intended
for and what its semantics for. That seems unfortunate...
For Arm, "max" is absolutely something we want to expose to
end users. It's the easiest way for a user to say "give me
something that's going to work". "host" doesn't work on TCG,
only with KVM.
t460s: ~/git/qemu master $ s390x-softmmu/qemu-system-s390x -cpu help |
grep max
s390 max Enables all features supported by the accelerator
in the current host
t460s: ~/git/qemu master $ x86_64-softmmu/qemu-system-x86_64 -cpu help |
grep max
x86 max Enables all features supported by the
accelerator in the current host
x86 and s390x interpret the "all features supported" as "possible in
this configuration", not "supported" like in a support statement.
When not passing a "-cpu", you will automatically get the default model
assigned (e.g., host vs. qemu model on s390x). "max" does no mimic that!
'max' already shouldn't include experimental features, at least
for Arm -- those should be off by default, because they're
experimental and you only want users to get them if they
explicitly opt in via '-cpu something,+x-my-feature'.
The whole point of "max" is to tell management software which
features are valid to be enabled in a host. If "+x-my-feature"
works, "x-my-feature" must be included in "max".
No, definitely not. Experimental features should never be
enabled by default -- the user must explicitly opt into them
so they are aware that they're using something that might
change behaviour or go away in a future QEMU version.
Also, from my point of view "max" is not for the benefit
of management software in particular. It's a convenience
for users primarily (and also for management software if
it doesn't want to care whether it's running KVM or TCG).
If management software wants a way to ask "what features
might be valid" we should provide them with one which
doesn't require those features to be enabled-by-default
in the 'max' CPU.
thanks
-- PMM
My personal opinion: "max" really means "all features". If we want an
automatic way to specify something you requested ("give me something
that's going to work") we either have to change the definition of the
max model for alla rchitectures or introduce something that really
matches the "no -cpu specified" - e.g., "best".
--
Thanks,
David / dhildenb
