qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] i386: Allow cpuid bit override


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH] i386: Allow cpuid bit override
Date: Thu, 30 Mar 2017 11:25:50 -0300
User-agent: Mutt/1.7.1 (2016-10-04)

On Thu, Mar 30, 2017 at 04:23:34PM +0200, Alexander Graf wrote:
> On 03/30/2017 04:22 PM, Eduardo Habkost wrote:
> > On Tue, Mar 28, 2017 at 02:35:57PM +0200, Alexander Graf wrote:
> > > On 03/28/2017 02:31 PM, Eduardo Habkost wrote:
> > > > On Tue, Mar 28, 2017 at 01:26:04PM +0200, Alexander Graf wrote:
> > [...]
> > > > > Putting it into a special enum sounds much more fragile than the 
> > > > > current
> > > > > solution to me. We need to bool fallback either way, so I fail to see 
> > > > > any
> > > > > benefit from having the enum.
> > > > I don't see why the enum would be more fragile. With the QAPI
> > > > enum, we:
> > > > * Have a meaningful value for the QOM property 'type' field,
> > > >     and have some hope to make type information for QOM properties
> > > >     really useful one day;
> > > > * Have the possible values for the property well-documented in
> > > >     the QAPI schema;
> > > > * Have the string<->enum translation code automatically generated
> > > >     for us;
> > > > * Can easily add other values later (I have been planning to
> > > >     support "feat=host" so "-cpu host/max" aren't special cases in
> > > >     the code.
> > > > 
> > > Ok, can you create the boilerplate for an OnOff enum type for me and I'll
> > > plug =force into that? All that visitor stuff scares me :).
> > I can do it, if you don't mind waiting for a few days. :)
> 
> 
> As long as we still manage to hit 2.9 with this I'm all happy :).

We won't, as this is not a bug fix and we are past hard freeze. :(

-- 
Eduardo



reply via email to

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