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? > > - "-cpu foo,+movbe" does What if I want movbe enabled if and only if it is _not_ emulated? The whole point here is to never ever ever enable an emulated feature unless it was explicitly what the user wanted. > > - "-cpu foo,check" and "-cpu foo,enforce" print a nice and > descriptive message if the feature is not available but could be > enabled as emulated "nice and descriptive message" needs to be better specified. Messages on stderr are useless for management software. Maybe a "emulated-features" property in addition to the existing "filtered-features" would be useful. But any of the above changes the fact that this series does not change the semantics of any "-cpu" option combination, except when not using the "enforce" flag (which everybody who cares about CPUID data stability should be already using). -- 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
