Re: [Qemu-devel] [PATCH v3 6/7] cpu: add device_add foo-x86_64-cpu support

[Chen Fan <chen.fan.fnst@cn.fujitsu.com>]

On 01/30/2015 12:39 AM, Andreas Färber wrote:
> Am 29.01.2015 um 17:01 schrieb Eduardo Habkost:
>> On Thu, Jan 29, 2015 at 03:46:03PM +0100, Igor Mammedov wrote:
>> [...]
>>>> @@ -2742,7 +2776,14 @@ static void x86_cpu_apic_create(X86CPU *cpu, Error **errp)
>>>>   
>>>>       object_property_add_child(OBJECT(cpu), "apic",
>>>>                                 OBJECT(cpu->apic_state), NULL);
>>>> -    qdev_prop_set_uint8(cpu->apic_state, "id", env->cpuid_apic_id);
>>>> +
>>>> +    apic_id = object_property_get_int(OBJECT(cpu), "apic-id", NULL);
>>>> +    if (apic_id == APIC_ID_NOT_SET) {
>>> Do we have in QOM a way to check if property was ever set?
>> I don't believe the QOM property model has any abstraction for unset
>> properties.
> Correct. The only way I can think of is turning it into a custom
> "dynamic" property, which lets you set some flag in the setter. Using a
> custom implementation for a static property might also be an option.
>
> But as a general reminder, this series does not seem to address some of
> the modeling considerations I had brought up, so I am again prioritizing
> work on an RFC for a cross-target QOM topology abstraction (me and
> Eduardo each had some early x86 patches to that effect iirc) and am
> still considering this v3 more of an RFC destined at testing hot-unplug
> on top, which will then be rebased on whatever structure we agree on.
Hi all,

For migration and arbitrary CPU add/rm, I have an idea to transmit
the source topology to dest for migration. for that we don't need to
care the topology problem on destination. we can add structure to
describe topology when parse smp. the topology show the cpu
details present:

                                  topology
                                         |
    |                                    |                         |
socket0                      socket1              socket2
    |  |                                ...                      ...
    |  core_sibling
core0
    |  |
    |  thread_sibling
thread0
    |
cpu_present

1) each time we create one CPU we update the cpu_present, and
when remove cpu, we clean the present bit.

2) when migration, we pass the cpu_present to destination via a
new vmsd. then from the tree hierarchy we would be aware of the
existed apic-id. so on destination loading the new calculated
apic-id to cpu object. one thing need to do I think is that we must
rebuild the srat table for preboot cpus before resume all cpu
on destination.

Thanks,
Chen


>
> Regards,
> Andreas
>