Re: [Qemu-devel] [PATCH qom-next 04/59] pc: Add CPU as /machine/cpu[n]

[Andreas Färber]

Am 08.06.2012 14:52, schrieb Jan Kiszka:
> On 2012-06-08 14:47, Igor Mammedov wrote:
>> ----- Original Message -----
>>> From: "Jan Kiszka" <address@hidden>
>>> To: "Andreas Färber" <address@hidden>
>>> Cc: "Igor Mammedov" <address@hidden>, "Anthony Liguori" <address@hidden>, 
>>> address@hidden, "Igor
>>> Mammedov" <address@hidden>, "Paolo Bonzini" <address@hidden>
>>> Sent: Friday, June 8, 2012 2:36:53 PM
>>> Subject: Re: [Qemu-devel] [PATCH qom-next 04/59] pc: Add CPU as     
>>> /machine/cpu[n]
>>>
>>> On 2012-06-08 14:34, Andreas Färber wrote:
>>>> Am 08.06.2012 14:05, schrieb Igor Mammedov:
>>>>> On Fri, Jun 08, 2012 at 11:11:11AM +0200, Andreas Färber 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 gracefully
>> 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.

(More on that when I've finished fixing my series.)

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg