[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: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [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
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, David Gibson, 2015/05/05
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, Alexey Kardashevskiy, 2015/05/25
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, David Gibson, 2015/05/25
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, Alexey Kardashevskiy, 2015/05/26
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, Paolo Bonzini, 2015/05/26
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, Alexey Kardashevskiy, 2015/05/26
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, Paolo Bonzini, 2015/05/26
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, Alexey Kardashevskiy, 2015/05/26
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, Paolo Bonzini, 2015/05/26
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, Alexey Kardashevskiy, 2015/05/26
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, Paolo Bonzini, 2015/05/26
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, Alexey Kardashevskiy, 2015/05/26
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, Paolo Bonzini, 2015/05/26