[Top][All Lists]

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

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

From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table
Date: Tue, 26 May 2015 11:01:22 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

On 26.05.15 10:58, Paolo Bonzini wrote:
> Hash: SHA256
> On 26/05/2015 04:46, David Gibson wrote:
>> On Tue, May 26, 2015 at 01:05:56AM +1000, Alexey Kardashevskiy 
>> wrote:
>>> Hi Paolo,
>>> I have had a conversation with Mike and it turns out I am not 
>>> allowed to create/remove memory regions dynamically 
>>> (docs/memory.txt:101); otherwise "destroying regions during
>>> reset causes assertion in RCU thread during PHB/IOMMU
>>> unplug/unparent". Is it because patch just missing some
>>> unref()/unparent() call or it is totally wrong and I have to
>>> implement subregions (on a PCI bus address space) myself if I
>>> want dynamic DMA windows? Thanks!
> I'm blind, can you explain the path where that happens?
>> 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?

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.


reply via email to

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