qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 6/7] qdev: Protect device-list-properties aga


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v3 6/7] qdev: Protect device-list-properties against broken devices
Date: Mon, 28 Sep 2015 10:37:15 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0


On 28/09/2015 10:11, Markus Armbruster wrote:
> 
> For most of the devices my patch marks, we have a pretty good idea on
> what's wrong with them.  spapr-rng is among the exceptions.  You believe
> it's actually "the macio object".  Which one?  "macio" is abstract...
> 
> You report introspecting "spapr-rng" crashes "while trying to go through
> the macio object".  I wonder how omitting introspection of macio objects
> (that's what marking them does to this test) could affect the object
> we're going through when we crash.
> 
>> > Or maybe we could get this also fixed? The problem could be the
>> > memory_region_init(&s->bar, NULL, "macio", 0x80000) in
>> > macio_instance_init() ... is this ok here? Or does this rather have to
>> > go to the realize() function instead?
> Hmm, does creating and destroying a macio object leave the memory region
> behind?
> 
> Paolo, is calling memory_region_init() in an instance_init() method
> okay?

Yes, but it has to have a non-NULL owner.

The reason why this particular call has a NULL owner is that the
(non-qdevified) DBDMA_init object inside it is also passing a NULL
owner.  DBDMA_init object is also doing a few more non-idempotent things
such as a malloc, a vmstate_register and a qemu_register_reset.

The full solution would be to qdev-ify DBDMA.  A simpler but also valid
solution would be to move DBDMA_init to macio_common_realize, in
addition to setting the owner of s->bar.

Paolo



reply via email to

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