From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44981) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWTwU-0001xo-CN for qemu-devel@nongnu.org; Mon, 21 May 2012 10:50:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWTwL-0001p9-NI for qemu-devel@nongnu.org; Mon, 21 May 2012 10:50:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4031) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWTwL-0001oX-FU for qemu-devel@nongnu.org; Mon, 21 May 2012 10:50:29 -0400 Message-ID: <4FBA562E.2020407@redhat.com> Date: Mon, 21 May 2012 16:50:22 +0200 From: Igor Mammedov MIME-Version: 1.0 References: <72a3d008-2d67-47e8-b5f2-927ff5cf2166@zmail16.collab.prod.int.phx2.redhat.com> <4FAAFA99.7000902@suse.de> In-Reply-To: <4FAAFA99.7000902@suse.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH RFC 6/6] target-i386: make cpus childs of /machine List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Cc: jan kiszka , aliguori@us.ibm.com, qemu-devel@nongnu.org, Paolo Bonzini On 05/10/2012 01:15 AM, Andreas F=C3=A4rber wrote: > Am 17.04.2012 12:28, schrieb Igor Mammedov: >> ----- Original Message ----- >>> From: "Andreas F=C3=A4rber" ... >>>> I think the right name would be /machine/cpu[%d]/cpu. The local >>>> APIC >>>> for example should reside under /machine/cpu[%d]/apic. >>> >>> Depends on how we model the CPU, I was kinda waiting for feedback on >>> that. >>> >>> I would prefer /machine/cpu[%d], with the APIC being a child >>> .../apic, >>> if possible. That however depends on how the device'ification of the >>> CPU >> Ok, I'll change /machine/cpu%d to /machine/cpu[%d]. > > Note that I needed a similar patch recently in my quest to move fields > from CPU_COMMON into CPUState: > https://github.com/afaerber/qemu-cpu/commits/qom-cpu (WIP) > > current state: > https://github.com/afaerber/qemu-cpu/commit/1318ad13cda52e694caea5cc722= 93c5879db3f9f > > I chose to do it in pc.c instead because for other architectures the > placement will be a machine-specific decision. I'm trying to re-base your commit on top of this series and doing it at b= oard level might be a problem if you think about doing hotplug in generalized way: 1. create new obj instance for cpu 2. set properties 'might include setting apic with its creation' 3. realize obj instance would it better to split name and cpu creation into 2 stages: - at board level: create links for all possible cpus - in target-XXX/cpu.c:XXX_cpu_initfn set appropriate link to itself (1) and than any property that might need canonical path could be set in gene= ral way (2)? Of cause this scheme is screwed up by the fact that there isn't canonical path for links (cpu[xxx]). Any thoughts how to deal with it? - Can we use object_property_add_child at runtime to add new cpu to /ma= chine, instead of link? > I've used cpu_index, but it seems cpuid_apic_id is assigned only once, > from cpu_index, so it should be identical. What's the difference? Once Jan voiced that user visible cpu id, should be apic_id in context of= cpu hotplug (i.e. when doing: device_add xxx_cpu,id=3D12345,...) "Jan, please correct me if I've got you wrong." So QOM tree probably should reflect this id and not cpu_index. However cpu_index and apic_id are the same now and bios assumes it as wel= l. What are possible benefits of using cpuid_apic_id !=3D cpu_index for qemu= ? --=20 ----- Igor