Sorry for following the discussion backwards, but I see now that you started with a proposal that would cover both cases (the one you care about, and the one I care about), make both of us happy, but it was lost in favour of other suggestions I disagreed with: On Thu, Jun 05, 2014 at 06:24:22PM +0200, Alexander Graf wrote: > > On 05.06.14 18:12, Eduardo Habkost wrote: > >This implements GET_SUPPORTED_CPUID support using an explicit option for it: > >"allow-emulation". We don't want any emulated feature to be enabled by accident, > >so they will be enabled only if the user explicitly wants to allow them. > > So is this an all-or-nothing approach? I would really prefer to > override individual bits. It is not an all-or-nothing approach if you use "enforce", but now I see that you care about use cases of people that are _not_ using "enforce" (which I strongly recommend against, but we can try to cover those use cases, as well). > > Also, I don't think the line "emulated" is the right one to draw. We > "emulate" SVM or VMX too, but still enable them by default as soon as > we think they're ready enough. Agreed. Let's call it "experimental". > > So could we add a new flag specifier instead? Today we have -flag and > +flag. How about *flag to "force enable if the kernel can handle it, > but doesn't do so by default"? Having an _additional_ way to allow emulation of specific flags, without changing the semantics of "+flag" would make both of us happy. But I believe we should look for a syntax that won't require special symbols, but just plain option names. Because the "-cpu" command-line options are simply translated to object_property_set() calls. "+flag" is legacy format, and we should move to use "flag=on" instead. So, what about, instead of "*foo", having "experimental-foo=on" or "force-foo=on"? I was going to suggest "foo=force", but that would require changing the data type of the properties from bool to string. -- 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
