qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC 0/2] GET_EMULATED_CPUID support with "allow-emulat


From: Alexander Graf
Subject: Re: [Qemu-devel] [RFC 0/2] GET_EMULATED_CPUID support with "allow-emulation" option
Date: Fri, 06 Jun 2014 00:24:26 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0


On 05.06.14 19:48, Eduardo Habkost wrote:
On Thu, Jun 05, 2014 at 06:58:17PM +0200, Alexander Graf wrote:
On 05.06.14 18:52, Paolo Bonzini wrote:
Il 05/06/2014 18:45, Alexander Graf ha scritto:
Only if you were using "-cpu somethingThatHasAVX", though, no?
Yes. The same argument goes the other way around. I want to use AVX
emulation, do "allow-emulation" and suddenly I get MONITOR/MWAIT
emulation.
What about:

- letting "-cpu foo,+emulatedfeature" just work

- adding emulated=yes that blindly enables all emulated features

- making "-cpu ...,check" prints a warning for emulated features
unless emulated=yes
So:

   -cpu foo,+emulatedFeature just works
The problem with this is:

  * -cpu foo,+emulatedFeature,enforce MUST fail. We don't want to enable
    emulated/experimental features by accident, even if they appear in
    the command-line expliclty.
  * -cpu foo,+emulatedFeature (no "enforce" flag) MUST remove remove the
    feature and report it on the "filtered-features" property, because
    that's the only API available for management to check if a feature is
    not available on GET_SUPPORTED_CPUID.

That's why I suggest that the only way to enable emulatedFeature be
using "allow-emulation=yes" explicitly on the command-line IN ADDITION
to already having the feature included in the CPU model definition or in
explicitly in the command-line.

(or "allow-experimental-features", or whatever name we choose)

   -cpu foo,+notEmulatedFeature still sets the CPUID bit for that feature
That's OK, but (I assume) you mean notEmulatedFeature is on
GET_SUPPORTED_CPUID.

Detailing the requirements:

  * "-cpu foo,+SomeFeature" MUST NOT enable SomeFeature unless it is
    present on GET_SUPPORTED_CPUID.
  * "-cpu foo,+SomeFeature,enforce" MUST abort if the feature is not
    present on GET_SUPPORTED_CPUID.
  * "-cpu foo,+SomeFeature" MUST report SomeFeature on
    "filtered-features", so management knows the feature is not set on
    GET_SUPPORTED_CPUID.

The items above are already part of the semantics of "-cpu" and if we
change it, we risk defeating the whole purpose of GET_EMULATED_CPUID in
the first place.

   -cpu foo,check prints warnings for all cpuid bits not in the
"allowed" bitmap. It prints different warnings depending on whether
the bit is in "emulated" or not
That part makes sense. And we may also report GET_EMULATED_CPUID
features on an "emulated-features" property, so management can get that
information in a machine-friendly way.

I personally like the feature=force way of specifying forcefully enabled cpuid bits. Whether it's in GET_EMULATED_CPUID doesn't matter really. Only "check" should ever care about that bitmap.

But can we drop the EMULATED name somehow? Can we rename [1] the ioctl to say GET_UNSUPPORTED_CPUID or something along those lines? The name is just a really really bad pick.


Alex

[1] rename obviously means "introduce a new name with the same ioctl number and keep the old name around for legacy compatibility reasons"



reply via email to

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