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 <ehabkost@xxxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list