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