Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor

[Andreas Färber]

Am 11.06.2012 09:59, schrieb Paolo Bonzini:
> Il 11/06/2012 09:56, Andreas Färber ha scritto:
>>>> I thought that was just a convenience choice, not a necessity.  The
>>>> children objects could just as well be heap-allocated.
>> In that case we'd need to change the instance_init signature. As far as
>> I've understood from our discussions with Anthony, realize must not
>> allocate new objects because that may collide with the recursive realize
>> model, and instance_init is not supposed to fail.
> 
> But qemu_malloc is also not supposed to fail.  It will exit QEMU if it
> fails.

(s/qemu_malloc/g_malloc/g)

...which is not always desired.

void *objp = g_try_malloc(sizeof(MyState)); /* may fail without abort */
if (objp != NULL) {
    object_initialize(objp, TYPE_MY); /* may not fail */
} else {
    /* report error to caller */
}

This becomes more important the more objects we allocate at runtime in
response to users' QMP commands.

When we talk about QEMU startup then we are in violent agreement that it
can abort. When influenced by user-tunable options like -m then it
starts to become less clear, there seemed agreement that it shouldn't
abort but fail with a nice error message (seems not followed up with a
patch though?).
But as I've seen in v0.15.x bug reports and reported last fall for
v1.0-rcX, allocations can fail while the guest is running (even without
active user interaction: network? block? memory usage varied HIGHly
according to simpletrace analyzed) and also being far from the hard
physical limit depending on ulimit settings (e.g., 41G'ish on a 64 GB
RAM system with default soft virtual limit of 80%).

Examples I have in mind where user interaction shouldn't crash the guest
is hotplugging an x86 CPU with its APIC or hotplugging a ppc CPU with
its large'ish opcode table. About a 5-char g_strdup() I'm not as worried. ;)

So from my view, the solution is to have basic versions such as
qdev_create() abort and to also provide advanced versions like
qdev_try_create() to handle more sophisticated enterprise use cases. QOM
does not provide a double API in the same way qdev did, but the above
snippet shows that if proper QOM modelling is used - the topic of this
thread - it can be compensated with GLib. Either way it requires
knowledge about struct sizes so they need to be exposed somehow.

What I started playing with a few weeks ago is reporting OOM via Error;
that's a bit trickier since allocating a new object might fail as well,
so it needs to be preallocated and there was some reference-counting
iirc that didn't play nicely with a never-to-be-freed object. Use cases
might include adding properties - which is and must be done in
instance_init - and retrieving string properties.
Not the highest priority for me at the moment, but something we
shouldn't make impossible by Bad Design.

I have deriving a public BNC# for this on my TODO list, to preserve my
graphs and analysis tools...

Regards,
Andreas

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