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
