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

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

 



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




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux