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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
