qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] qom: Introduce object_realize_nofail()


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH v2] qom: Introduce object_realize_nofail()
Date: Fri, 13 Apr 2012 16:51:18 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0

Am 13.04.2012 16:25, schrieb Paolo Bonzini:
> Il 13/04/2012 16:21, Andreas Färber ha scritto:
>> Am 13.04.2012 16:08, schrieb Paolo Bonzini:
>>> Il 13/04/2012 16:06, Andreas Färber ha scritto:
>>>> I'm still talking about the (pretty clear to me) graph that I posted.
>>>> There, object A's init function creates a new qdev object - . Creating
>>>> an object can fail - fatally or non-fatally.
>>>>
>>>> And yes, exactly my point, currently initfn (first stage) cannot fail,
>>>> only the second stage (DeviceClass::init). Which is why I've been saying
>>>> we'll need to refactor those "fake composition" usages first before we
>>>> declare that we can defer qdev initialization to vl.c.
>>>
>>> But why should they fail?  This is what I also asked.  If instance-init
>>> is deterministic, it will either always or never fail (besides cases
>>> like memory allocation which cannot really be handled correctly).
>>
>> Indeed I am thinking of trivial memory allocation for starters, yes.
>> This is not just a theoretical issue as I have two such reports in my
>> Bugzilla already.
> 
> Are they public?

No. But the issue is that creating the machine worked fine, customer
installs SLES, qemu-kvm crashes at runtime.

>  Haven't we long agreed that exit(1) is the right thing
> to do on OOM?

There seemed to be agreement that

(i) for creating objects at startup exit(1) or abort() is acceptable,

(ii) abort() were not acceptable for user-supplied -m values (but still
no patch),

(iii) runtime memory usage should not be as dynamic as shown in my trace
graph causing OOM (search your inbox for "gnuplot", mentioned the thread
name on IRC recently too).

There's also a related recent thread to which I haven't replied yet.

I already fixed one QOM bug where qdev_try_create() or so would abort()
if the type doesn't exist simply because qom/object.c has assert()s all
over it and is lacking some non-asserting versions.
This also affects my currently-deferred -cpu subclassing series, for
which I had to inline some class existence checks before object_new() so
that cpu_init() can return NULL as currently expected.

Andreas

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]