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@redhat.com> 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