qemu-devel
[Top][All Lists]
Advanced

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

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


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [RFC 0/2] GET_EMULATED_CPUID support with "allow-emulation" option
Date: Thu, 5 Jun 2014 15:11:06 -0300
User-agent: Mutt/1.5.21 (2010-09-15)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]