From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47082) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXa3G-0001aC-6g for qemu-devel@nongnu.org; Thu, 24 May 2012 11:34:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SXa3A-0002Lv-8K for qemu-devel@nongnu.org; Thu, 24 May 2012 11:34:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10527) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXa3A-0002L2-0e for qemu-devel@nongnu.org; Thu, 24 May 2012 11:34:04 -0400 Message-ID: <4FBE54E6.2060107@redhat.com> Date: Thu, 24 May 2012 17:33:58 +0200 From: Igor Mammedov 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> <4FBE3F24.9010301@suse.de> In-Reply-To: <4FBE3F24.9010301@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: =?ISO-8859-1?Q?Andreas_F=E4rber?= Cc: pbonzini@redhat.com, Markus Armbruster , Anthony Liguori , qemu-devel@nongnu.org On 05/24/2012 04:01 PM, Andreas F=E4rber wrote: > 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. >> >> Will we have a special cases for every incompatible device types that = is >> going to be hot-plugged via device_add monitor command? >> >> 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= there >> >> 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. Thanks for the link and job you've done on cpus. It looks much smaller/cl= eaner than when I've attempted to do it several months ago, that was big and ug= ly hack. > If we created a TYPE_X86_CPU with -device, we would not get an APIC > attached currently. That is why I'm adding intermediate cpu_model property for now, so that it would possible to create TYPE_X86_CPU and set cpu_model property which would create APIC if cpu advertises it. Then when cpu subclasses implemented and possibly cpu features are conver= ted to properties, we could move APIC creation to a more appropriate place an= d drop cpu_model property. > 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 Yep, that would complicate things. I don't like it for x86 because container device would be just dumb chip packaging if we try to match it with a real hardware and as you say it would be difficult to use it. > with SoCs (the sh7750 realize discussion). could > > Andreas > --=20 ----- Igor