qemu-devel
[Top][All Lists]
Advanced

[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 08:47:37 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6

Il 02/06/2013 18:12, Peter Maydell ha scritto:
> On 2 June 2013 16:43, Paolo Bonzini <address@hidden> wrote:
>> Reference counting the region piggybacks on reference counting of a QOM
>> object, the "owner" of the region.  The owner API is designed so that
>> it will be called as little as possible.  Unowned subregions will get a
>> region if memory_region_set_owner is called after the subregion is added.
>> This is in general the common case already; often setting the owner can
>> be delegated to a bus-specific API that already takes a DeviceState
>> (for example pci_register_bar or sysbus_init_mmio).
> 
> This feels a bit fragile to me -- there doesn't seem to be
> a clear rule for who has to set the owner of a region or
> when they have to do it, or for ensuring that it doesn't
> get forgotten altogether.

The best rule would be "who creates it".  This would touch half the
files in hw/, which I am trying to avoid.

So I'm settling for:

* in general, the bus sets the owner for regions that are managed by the
bus (patches 5/6/9);

* if the device plays directly with address_space_memory/io (shouldn't
happen except in very special cases, such as patch 7) or if regions are
added/deleted dynamically to a container (patches 8/10/11/12), then the
device must set the owner itself.

All stuff that should be in a comment, I guess...

> What happens if I take a MemoryRegion* that another device
> has exposed to me as a sysbus mmio region (and so claimed
> ownership of) and pass it to pci_register_bar()?

You get an assertion failure.

> Who owns it at that point? [That's a legitimate thing to do, I think,
> though I don't suppose anybody does it at the moment.
> Sysbus MMIOs aren't only for mapping in the system address
> space, they're a general way for one device to expose a
> MemoryRegion * for use by another device.]

I don't think it is legitimate, MMIO regions are just for use via
sysbus_map_mmio.  But the same scenario could apply without sysbus MMIO
in the future (e.g. via QOM properties), so it is a good question.

The right thing to do is to use a container or alias region, and put the
1st region inside it.  Then the 1st region keeps its owner, and the
container/alias gets a new one.

Paolo



reply via email to

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