qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [QEMU PATCH 0/3] versioned CPU models / per-machine-typ


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [QEMU PATCH 0/3] versioned CPU models / per-machine-type aliases
Date: Thu, 26 Jul 2012 10:29:00 -0400
User-agent: Mutt/1.5.20 (2009-12-10)

On Thu, Jul 26, 2012 at 04:06:03PM +0200, Andreas Färber wrote:
> Am 26.07.2012 15:53, schrieb Eduardo Habkost:
> > On Wed, Jul 25, 2012 at 06:43:25PM -0500, Anthony Liguori wrote:
> >> Eduardo Habkost <address@hidden> writes:
> >>
> >>> Hi,
> >>>
> >>> This is the first try at a simple system to make the CPU model definitions
> >>> versioned (to allow them to get bug fixes while allowing migration from 
> >>> older
> >>> versions and keeping command-line compatibility), and per- machine-type 
> >>> aliases
> >>> for compatibility.
> >>>
> >>> The lack of CPU model versioning is blocking multiple bug fixes that are
> >>> necessary on CPU model definitions, but can't be included today because 
> >>> they
> >>> would break migration.
> >>>
> >>> Later, after this gets in (or at least gets some feedback), I plan to 
> >>> send a
> >>> proposal for a machine-friendly CPU feature / CPU model probing interface 
> >>> that
> >>> libvirt could use.
> >>
> >> This isn't the right approach.  The CPU properties should be exposed as
> >> QOM properties which then allows the machine type globals to be used to
> >> control stuff like this.
> > 
> > I would like to use global properties for this, but the obstacles I have
> > found were:
> > 
> > - As far as I can see in the code, global properties are usable only by
> >   qdev objects, and CPUs were not qdevfied yet
> 
> After Hackweek I plan to put together some compromise or even multiple
> alternatives. We definitely need this for multiple open issues.
> 
> > - The per-machine-type properties I need to set are for CPU models, not
> >   CPUs.
> >   - For example: if we fix the Nehalem CPU model by changing the "level"
> >     field, we need to make the pc-1.1 and lower machine-types to keep
> >     the old "level" value, but only on the Nehalem CPU model
> 
> Is that part crying for CPU subclasses? Or what is the problem there?
> (Still have a mail about -cpudef in my drafts folder, need to post RFC.)

Maybe, yes.

If we have the subclasses, then the only problem I see is that global
properties currently require qdev. Maybe having a simple interface
non-qdev objects can use to query for global properties would solve
that?

-- 
Eduardo



reply via email to

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