From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScxwO-0007QK-K9 for qemu-devel@nongnu.org; Fri, 08 Jun 2012 08:05:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ScxwJ-0007aL-1m for qemu-devel@nongnu.org; Fri, 08 Jun 2012 08:05:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33412) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScxwI-0007aD-Qh for qemu-devel@nongnu.org; Fri, 08 Jun 2012 08:05:14 -0400 Date: Fri, 8 Jun 2012 14:05:08 +0200 From: Igor Mammedov Message-ID: <20120608120508.GC22512@thinkpad.mammed.net> References: <1337742502-28565-1-git-send-email-afaerber@suse.de> <1337742502-28565-5-git-send-email-afaerber@suse.de> <20120608082006.GA22512@thinkpad.mammed.net> <4FD1C1AF.2020208@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <4FD1C1AF.2020208@suse.de> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH qom-next 04/59] pc: Add CPU as /machine/cpu[n] List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?iso-8859-1?Q?F=E4rber?= Cc: Jan Kiszka , Anthony Liguori , qemu-devel@nongnu.org, Igor Mammedov , Paolo Bonzini On Fri, Jun 08, 2012 at 11:11:11AM +0200, Andreas F=E4rber wrote: > Am 08.06.2012 10:20, schrieb Igor Mammedov: > > On Wed, May 23, 2012 at 05:07:27AM +0200, Andreas F=E4rber wrote: >=20 > This is touching on a core QOM question: Can we link<> during initfn? > That's what you're trying to do for the APIC and why this may be too > late in your case. I believe the answer to that question must be no. Yep, it's more of general question. Potentially any property could be set in initfn to intialize defaults and a property setter could create a link causing chicken/egg conflict. If making link<> to object is not permited till its initfn is done then when it is permited to be made? Maybe object_new() should take parent as parameter or maybe due to limita= tion we should revise purpose of link<>s /if they are replacement of ptr prope= rties/? [...]=20 > Another factor that is making this slightly difficult is that there are > three APIC subclasses. Currently they all have an instance_size of > sizeof(APICCommonState) so it could be created in-place if it actually > is a part (child<>) of the CPU wrt hot-plug. Creating objects with > object_new() in QOM instance_init is forbidden. Any particular reason why object_new() in intifn is not acceptable? >=20 [...] >=20 > Maybe this CPU hot-plug business would be a good topic for a KVM call? It's more that I'm unhappy about wrong cpu creation order in pc_new_cpu() at the present code. For hotplug qdev_device_add makes new object as=20 a child<> when it's created and it just needs to be placed before other properties are set. >=20 > Regards, > Andreas >=20 > --=20 > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrn= berg >=20