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

[Eduardo Habkost]

On Thu, Jun 05, 2014 at 07:39:42PM +0200, Paolo Bonzini wrote:
> Il 05/06/2014 19:19, Eduardo Habkost ha scritto:
> >On Thu, Jun 05, 2014 at 06:57:57PM +0200, Paolo Bonzini wrote:
> >>Il 05/06/2014 18:54, Alexander Graf ha scritto:
> >>>>
> >>>>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
> >>>
> >>>How about we remove the emulated=yes from this list? Then I'm happy :).
> >>
> >>So:
> >>
> >>- "-cpu foo" doesn't enable any emulated feature
> >
> >What if "foo" already has movbe in the CPU model definition?
> 
> It will be disabled.

I don't disagree with that. But not that if it will be disabled, that
means "-cpu foo,enforce" will abort.

But note that if you use "-cpu foo" without enforce, that means you can
suddenly get movbe enabled once it gets included on GET_SUPPORTED_CPUID.

So, if you care about predictable CPUID results and you want to enable
an emulated/experimental feature, you have to do two things:

 1) Make sure your setup works with "enforce", so you know you will
    never get any feature suddenly and silently enabled.
 2) Add "+feature,allow-emulation=yes" to the command-line, keep
    "enforce" and you will _not_ get any other experimental feature
    suddenly enabled (because now you are using "enforce").

> 
> >>
> >>- "-cpu foo,+movbe" does
> >
> >What if I want movbe enabled if and only if it is _not_ emulated?
> 
> Pick a CPU model that has it.
> 
> >The whole point here is to never ever ever enable an emulated feature
> >unless it was explicitly what the user wanted.
> 
> "+foo" could be enough.

We shouldn't do that, or we risk enabling features by accident and
defeating the whole purpose of GET_EMULATED_CPUID.

The current semantics of "+foo" is "I want FOO, but only if it's on
GET_SUPPORTED_CPUID". We shouldn't break it.

> 
> >"nice and descriptive message" needs to be better specified. Messages on
> >stderr are useless for management software.
> 
> I'm not sure this feature is for management software users.

True. I am just worried about breaking current semantics that is used by
management software.

-- 
Eduardo