[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 00/15] Memory/IOMMU patches part 4: region owner
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH 00/15] Memory/IOMMU patches part 4: region ownership |
Date: |
Mon, 03 Jun 2013 13:05:21 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 |
Il 03/06/2013 12:25, Peter Maydell ha scritto:
> On 3 June 2013 11:12, Paolo Bonzini <address@hidden> wrote:
>> 1) I could set the owner to NULL before calling the sysbus_init_mmio;
>>
>> 2) I could add a variant of sysbus_init_mmio that doesn't set the owner;
>>
>> 3) I could skip setting the owner for sysbus altogether, since it is
>> only strictly required for unpluggable devices.
>
> 4) you could set the owner at the right place, ie when the
> memory region is created.
>
>> However, I think there is worth in preserving the chain through either
>> containment or aliasing. From the nesting point of view,
>> realview_mpcore is exposing the region. From the implementor point of
>> view, arm_gic is implementing the region (and arm_gic is the one that
>> would be ref/unref'd at execution time). In either case,
>> arm11mpcore_priv is not what you want to see. Its presence is just an
>> implementation detail of realview_mpcore.
>
> I agree that the owner of the MR in this case should be
> arm_gic.
The owner of the I/O region is arm_gic. It is set when arm_gic does
sysbus_init_mmio. But container regions have an owner too. Here the
owner is set initially to arm11mpcore_priv, and then it bombs when
realview_mpcore tries to change it to itself.
Make each level wrap the region with a container makes sense to me. But
actually sysbus_pass_mmio would match nicely sysbus_pass_irq as an API,
so (2) above would be a good choice too.
What I'm definitely not going to do, is go through 800 calls and add
owners to all of them.
> For aliasing, surely you need to actually reference
> both devices? If the device that owns the container goes
> away then your MR* is toast anyway, and if the device doing
> the actual implementation goes away your MR* is also now
> invalid. So they have to both hang around long enough for
> you to finish whatever you were doing.
Container and alias regions are "virtual", they are eliminated while
creating the flat memory map; I/O goes straight to the contained/aliased
region. Hence, containers and aliases in principle need no owner; it is
still nice to have one, for symmetry and ease of debugging.
A reference to the aliased region is added when:
(1) the region is added to the flat memory map;
(2) the alias is created.
Both are done in patch 3.
Paolo
- Re: [Qemu-devel] [PATCH 14/15] memory: return MemoryRegion from qemu_ram_addr_from_host, (continued)
[Qemu-devel] [PATCH 15/15] memory: ref/unref memory across address_space_map/unmap, Paolo Bonzini, 2013/06/02
Re: [Qemu-devel] [PATCH 00/15] Memory/IOMMU patches part 4: region ownership, Peter Maydell, 2013/06/02
- Re: [Qemu-devel] [PATCH 00/15] Memory/IOMMU patches part 4: region ownership, Paolo Bonzini, 2013/06/03
- Re: [Qemu-devel] [PATCH 00/15] Memory/IOMMU patches part 4: region ownership, Peter Maydell, 2013/06/03
- Re: [Qemu-devel] [PATCH 00/15] Memory/IOMMU patches part 4: region ownership, Paolo Bonzini, 2013/06/03
- Re: [Qemu-devel] [PATCH 00/15] Memory/IOMMU patches part 4: region ownership, Peter Maydell, 2013/06/03
- Re: [Qemu-devel] [PATCH 00/15] Memory/IOMMU patches part 4: region ownership, Paolo Bonzini, 2013/06/03
- Re: [Qemu-devel] [PATCH 00/15] Memory/IOMMU patches part 4: region ownership, Peter Maydell, 2013/06/03
- Re: [Qemu-devel] [PATCH 00/15] Memory/IOMMU patches part 4: region ownership,
Paolo Bonzini <=