qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" st


From: Paolo Bonzini
Subject: Re: [Qemu-ppc] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table
Date: Tue, 26 May 2015 11:16:48 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0


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



reply via email to

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