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.) Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list