From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51558) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmLjt-0008Px-Sk for qemu-devel@nongnu.org; Wed, 04 Jul 2012 05:19:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SmLjn-0001M9-EO for qemu-devel@nongnu.org; Wed, 04 Jul 2012 05:19:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26275) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmLjj-0001K8-5e for qemu-devel@nongnu.org; Wed, 04 Jul 2012 05:19:03 -0400 Message-ID: <4FF40A81.5050002@redhat.com> Date: Wed, 04 Jul 2012 11:18:57 +0200 From: Igor Mammedov MIME-Version: 1.0 References: <4FD1F576.6020601@siemens.com> <4FD1F84D.9050206@suse.de> In-Reply-To: <4FD1F84D.9050206@suse.de> Content-Type: text/plain; charset=UTF-8; format=flowed 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: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Cc: Jan Kiszka , Anthony Liguori , Paolo Bonzini , "qemu-devel@nongnu.org" , Igor Mammedov On 06/08/2012 03:04 PM, Andreas F=C3=A4rber wrote: > Am 08.06.2012 14:52, schrieb Jan Kiszka: >> On 2012-06-08 14:47, Igor Mammedov wrote: >>> ----- Original Message ----- >>>> From: "Jan Kiszka" >>>> To: "Andreas F=C3=A4rber" >>>> Cc: "Igor Mammedov" , "Anthony Liguori" , qemu-devel@nongnu.org, "Igor >>>> Mammedov" , "Paolo Bonzini" >>>> Sent: Friday, June 8, 2012 2:36:53 PM >>>> Subject: Re: [Qemu-devel] [PATCH qom-next 04/59] pc: Add CPU as /mac= hine/cpu[n] >>>> >>>> On 2012-06-08 14:34, Andreas F=C3=A4rber wrote: >>>>> Am 08.06.2012 14:05, schrieb Igor Mammedov: >>>>>> On Fri, Jun 08, 2012 at 11:11:11AM +0200, Andreas F=C3=A4rber wrot= e: >>>>>>> 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? >>>>> >>>>> It allocates memory, which may fail. The initfn must not fail, the >>>>> realizefn may return an Error object. >>>> >>>> Since when do we fail gracefully on OOM again? >>> Maybe Andreas means that we cannot report error to caller? >>> If it's a case then lets pass error to object_new() and fail graceful= ly >>> or simply abort on OOM. >> >> QEMU's policy on OOM is abort (that's what glib already does for us >> theses days). > > Nah, that's not the whole truth. Could you elaborate more on subj? I've looked at different initfns, many of them call object_property_add()= which may cause OOM as well. So if object_property_add() is permitted then why not object= _new()? > > (More on that when I've finished fixing my series.) > > Andreas > --=20 ----- Igor