From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43142) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJbZL-0007N7-82 for qemu-devel@nongnu.org; Fri, 06 Feb 2015 00:35:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJbZH-00027D-6p for qemu-devel@nongnu.org; Fri, 06 Feb 2015 00:35:07 -0500 Received: from [59.151.112.132] (port=23884 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJbZG-0001wj-Ij for qemu-devel@nongnu.org; Fri, 06 Feb 2015 00:35:03 -0500 Message-ID: <54D450D4.2090300@cn.fujitsu.com> Date: Fri, 6 Feb 2015 13:27:48 +0800 From: Chen Fan MIME-Version: 1.0 References: <54b41fb0134597f3a1bba41febdbe59acc268fa5.1421214155.git.zhugh.fnst@cn.fujitsu.com> <20150129154603.7cbfffcb@nial.brq.redhat.com> <20150129160139.GD30651@thinpad.lan.raisama.net> <54CA6250.1010402@suse.de> In-Reply-To: <54CA6250.1010402@suse.de> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v3 6/7] cpu: add device_add foo-x86_64-cpu support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , Eduardo Habkost , Igor Mammedov Cc: Zhu Guihua , Andrew Jones , qemu-devel@nongnu.org, tangchen@cn.fujitsu.com, isimatu.yasuaki@jp.fujitsu.com, Paolo Bonzini , guz.fnst@cn.fujitsu.com, anshul.makkar@profitbricks.com On 01/30/2015 12:39 AM, Andreas F=C3=A4rber 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, Er= ror **errp) >>>> =20 >>>> 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 =3D object_property_get_int(OBJECT(cpu), "apic-id", NULL)= ; >>>> + if (apic_id =3D=3D 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 >