Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table

[Paolo Bonzini <pbonzini@redhat.com>]

On 26/05/2015 11:01, Alexander Graf wrote:
>>> So, the sentences after that one note an exception for alias and 
>>> >> container regions.  I think iommu regions should behave similarly
>>> >> - in a sense they're just a procedurally generated collection of 
>>> >> alias regions.
>> > 
>> > The difference is that containers and aliases are resolved at the time
>> > the memory region tree is flattened, while IOMMU regions are resolved
>> > at run time.
> Can you please go into more detail here? What part exactly gets resolved
> at run time? We don't flatten the memory regions for IOMMU accesses?

The IOMMU is a single huge region in the FlatView, which then is
forwarded to another AddressSpace.

> But even if we walk the regions rather than the flattened tree, I don't
> see how we could end up with races when removing a device.

The problem is that there is no guarantee that the MemoryRegion dies
immediately after object_unparent.  In fact it will wait at least one
RCU grace period, because the (RCU-protected) FlatViews hold a reference
to the device via memory_region_ref.

There is a very simple (in theory) solution: create the memory region
via object_new instead of object_initialize, using a MemoryRegion*
instead of embedding the MemoryRegion directly.  But I'm not sure how to
do that without duplicating the whole memory_region_init set of APIs.

Perhaps Andreas has an idea of how to improve the QOM object creation API?

Paolo