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

[Q (Igor Mammedov)]

On Fri, Jun 8, 2012 at 2:52 PM, Jan Kiszka <address@hidden> wrote:
> 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).
>
then there is little merit in playing in-place game since allocation
of containing
object  may fail as well resulting in abort just a bit earlier.

> Jan
>
> --
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux