From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60604) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXYbP-00038H-Pl for qemu-devel@nongnu.org; Thu, 24 May 2012 10:01:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SXYbK-0002M8-Qz for qemu-devel@nongnu.org; Thu, 24 May 2012 10:01:19 -0400 Received: from cantor2.suse.de ([195.135.220.15]:50141 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXYbK-0002LY-I8 for qemu-devel@nongnu.org; Thu, 24 May 2012 10:01:14 -0400 Message-ID: <4FBE3F24.9010301@suse.de> Date: Thu, 24 May 2012 16:01:08 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1337859784-24097-1-git-send-email-armbru@redhat.com> <1337859784-24097-3-git-send-email-armbru@redhat.com> <4FBE31CD.1080101@codemonkey.ws> <4FBE3C38.8040401@redhat.com> In-Reply-To: <4FBE3C38.8040401@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH RFC 2/2] qmp: New command qom-new List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: pbonzini@redhat.com, Markus Armbruster , Anthony Liguori , qemu-devel@nongnu.org Am 24.05.2012 15:48, schrieb Igor Mammedov: > On 05/24/2012 03:04 PM, Anthony Liguori wrote: >> >> I'm not sure how I feel about this. I never intended for a user to be >> able to create objects that were arbitrary children of other objects. >> >> In some ways, I think this is almost too powerful of an interface to >> expose to users. I like things like device_add() better that only >> creates objects >> of TYPE_DEVICE that are always in /peripherial. >> >> For block, we'd have a similar interface that always created objects >> of TYPE_BLOCK_DRIVER and put them in /block. >=20 > Will we have a special cases for every incompatible device types that i= s > going to be hot-plugged via device_add monitor command? >=20 > For CPUs my thoughts were moving in opposite direction, like: > - make possible to create and initialize CPU as a regular QOM object > - hack qdev_device_add() to allow not only TYPE_DEVICE to be created t= here >=20 > There are patches out there that make cpu a child of /machine at board > level. > But for hot-added objects parent could be specified as a property > or knowledge about parent hard-coded inside of object itself or > hard-coded in device_add(). > Which one of them likely to be adopted? For system emulation I am working towards making the CPU a device so that we can reuse common device infrastructure: https://github.com/afaerber/qemu-cpu/commits/qom-cpu-dev That's independent of what QMP commands we provide to the user though. If we created a TYPE_X86_CPU with -device, we would not get an APIC attached currently. If however we created a container object as suggested by Peter and others before, then we cannot as easily modify properties of the child objects (family, vendor, etc. of CPU) via command line. Same issue as with SoCs (the sh7750 realize discussion). Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg