From: Paolo Bonzini <pbonzini@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: jan.kiszka@siemens.com, qemu-devel@nongnu.org,
Liu Ping Fan <qemulist@gmail.com>
Subject: Re: [Qemu-devel] [PATCH 00/15] Memory/IOMMU patches part 4: region ownership
Date: Mon, 03 Jun 2013 08:47:37 +0200 [thread overview]
Message-ID: <51AC3C09.2010708@redhat.com> (raw)
In-Reply-To: <CAFEAcA_pWMS1Xc3QizyNZYiELvs=t8_=OKFV7+8Psb79Pc_HPw@mail.gmail.com>
Il 02/06/2013 18:12, Peter Maydell ha scritto:
> On 2 June 2013 16:43, Paolo Bonzini <pbonzini@redhat.com> 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
next prev parent reply other threads:[~2013-06-03 6:47 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-02 15:43 [Qemu-devel] [PATCH 00/15] Memory/IOMMU patches part 4: region ownership Paolo Bonzini
2013-06-02 15:43 ` [Qemu-devel] [PATCH 01/15] memory: add getter/setter for owner Paolo Bonzini
2013-06-02 15:43 ` [Qemu-devel] [PATCH 02/15] memory: add ref/unref Paolo Bonzini
2013-06-02 15:58 ` Peter Maydell
2013-06-03 6:49 ` Paolo Bonzini
2013-06-02 15:43 ` [Qemu-devel] [PATCH 03/15] memory: add ref/unref calls Paolo Bonzini
2013-06-02 15:43 ` [Qemu-devel] [PATCH 04/15] exec: add a reference to the region returned by address_space_translate Paolo Bonzini
2013-06-02 15:43 ` [Qemu-devel] [PATCH 05/15] pci: set owner for BARs Paolo Bonzini
2013-06-02 15:43 ` [Qemu-devel] [PATCH 06/15] sysbus: set owner for MMIO regions Paolo Bonzini
2013-06-02 15:43 ` [Qemu-devel] [PATCH 07/15] acpi: add memory_region_set_owner calls Paolo Bonzini
2013-06-02 15:43 ` [Qemu-devel] [PATCH 08/15] misc: " Paolo Bonzini
2013-06-02 15:43 ` [Qemu-devel] [PATCH 09/15] isa/portio: allow setting an owner Paolo Bonzini
2013-06-02 15:43 ` [Qemu-devel] [PATCH 10/15] vga: add memory_region_set_owner calls Paolo Bonzini
2013-06-02 15:43 ` [Qemu-devel] [PATCH 11/15] pci-assign: " Paolo Bonzini
2013-06-02 15:43 ` [Qemu-devel] [PATCH 12/15] vfio: " Paolo Bonzini
2013-06-02 15:43 ` [Qemu-devel] [PATCH 13/15] exec: check MRU in qemu_ram_addr_from_host Paolo Bonzini
2013-06-02 15:43 ` [Qemu-devel] [PATCH 14/15] memory: return MemoryRegion from qemu_ram_addr_from_host Paolo Bonzini
2013-06-02 16:04 ` Peter Maydell
2013-06-03 6:40 ` Paolo Bonzini
2013-06-03 10:51 ` Paolo Bonzini
2013-06-02 15:43 ` [Qemu-devel] [PATCH 15/15] memory: ref/unref memory across address_space_map/unmap Paolo Bonzini
2013-06-02 16:12 ` [Qemu-devel] [PATCH 00/15] Memory/IOMMU patches part 4: region ownership Peter Maydell
2013-06-03 6:47 ` Paolo Bonzini [this message]
2013-06-03 9:22 ` Peter Maydell
2013-06-03 9:40 ` Paolo Bonzini
2013-06-03 9:58 ` Peter Maydell
2013-06-03 10:12 ` Paolo Bonzini
2013-06-03 10:25 ` Peter Maydell
2013-06-03 11:05 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51AC3C09.2010708@redhat.com \
--to=pbonzini@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemulist@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.