From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37662) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Scyrb-00017r-VI for qemu-devel@nongnu.org; Fri, 08 Jun 2012 09:04:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ScyrR-00034E-Vg for qemu-devel@nongnu.org; Fri, 08 Jun 2012 09:04:27 -0400 Received: from cantor2.suse.de ([195.135.220.15]:44848 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScyrR-000341-M0 for qemu-devel@nongnu.org; Fri, 08 Jun 2012 09:04:17 -0400 Message-ID: <4FD1F84D.9050206@suse.de> Date: Fri, 08 Jun 2012 15:04:13 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <4FD1F576.6020601@siemens.com> In-Reply-To: <4FD1F576.6020601@siemens.com> Content-Type: text/plain; charset=UTF-8 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: Jan Kiszka Cc: Igor Mammedov , Anthony Liguori , Paolo Bonzini , "qemu-devel@nongnu.org" , Igor Mammedov 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 /mach= ine/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 wrote= : >>>>>> 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 gracefull= y >> or simply abort on OOM. >=20 > QEMU's policy on OOM is abort (that's what glib already does for us > theses days). Nah, that's not the whole truth. (More on that when I've finished fixing my series.) Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg