Re: [Qemu-devel] [PATCH v4 14/18] target-i386: Add "migratable" property to "host" CPU model

[Andreas Färber]

Am 16.05.2014 18:13, schrieb Eduardo Habkost:
> On Fri, May 16, 2014 at 12:12:18AM +0200, Andreas Färber wrote:
>> Am 15.05.2014 22:26, schrieb Eduardo Habkost:
>>> On Thu, May 15, 2014 at 09:44:49PM +0200, Andreas Färber wrote:
>>>> Am 30.04.2014 18:48, schrieb Eduardo Habkost:
>>>>> This flag will allow the user to choose between two modes:
>>>>>  * All flags that can be enabled on the host, even if unmigratable
>>>>>    (migratable=no);
>>>>>  * All flags that can be enabled on the host, known to QEMU,
>>>>>    and migratable (migratable=yes).
>>>>>
>>>>> The default is still migratable=false, to keep current behavior, but
>>>>> this will be changed to migratable=true by another patch.
>>>>>
>>>>> My plan was to support the "migratable" flag on all CPU classes, but
>>>>> have the default to "false" on all CPU models except "host". However,
>>>>> DeviceClass has no mechanism to allow a child class to have a different
>>>>> property default from the parent class yet, so by now only the "host"
>>>>> CPU model will support the "migratable" flag.
>>>>
>>>> Just set the new default in the derived type's instance_init?
>>>
>>> That would work. I am still assuming that one day we will allow
>>> management to query for class property defaults without instantiating
>>> objects. But even if we do it, "host" is already an exception (because
>>> the defaults depend on KVM initialization), so in this case it will be
>>> OK.
>>>
>>> So, this patch can be dropped because it will be replaced. I will also
>>> implement the other changes you requested for this patch.
>>
>> Before you make yourself too much work, have a peek at qom-cpu. :)
>> I should have all except 15 and 18, with some cleanups TBD.
> 
> Thsnk! But I see two problems on current qom-cpu:
> 
>  * The "migratable" flag is now not affecting the results of "-cpu host"
>    (host_x86_cpu_initfn()), which was the whole point of adding the
>    property.

Where did I break that? Renaming the variable and reordering it with a
comment shouldn't be a functional change... Note that some patches
needed to be applied with patch -p1 due to rebased qom-next, so maybe
there's a mismerge somewhere?

OTOH maybe we should start writing qtests for the CPU? I've been meaning
to write one for cpu-add but didn't get to it yet.

Andreas

>  * Without setting migratable=yes by default, we are going to break
>    existing setups after applying 'support "invariant tsc" flag' and
>    "block migration and savevm if invariant tsc is exposed" (See
>    http://marc.info/?l=qemu-devel&m=139838802220184&w=2 ).

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg