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(a)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