From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55893) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UjOYZ-0005RY-H1 for qemu-devel@nongnu.org; Mon, 03 Jun 2013 02:47:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UjOYY-0005b3-EW for qemu-devel@nongnu.org; Mon, 03 Jun 2013 02:47:51 -0400 Received: from mail-wi0-x230.google.com ([2a00:1450:400c:c05::230]:47908) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UjOYY-0005ax-89 for qemu-devel@nongnu.org; Mon, 03 Jun 2013 02:47:50 -0400 Received: by mail-wi0-f176.google.com with SMTP id hr14so2323375wib.15 for ; Sun, 02 Jun 2013 23:47:49 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <51AC3C09.2010708@redhat.com> Date: Mon, 03 Jun 2013 08:47:37 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1370187812-13191-1-git-send-email-pbonzini@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 00/15] Memory/IOMMU patches part 4: region ownership List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: jan.kiszka@siemens.com, qemu-devel@nongnu.org, Liu Ping Fan Il 02/06/2013 18:12, Peter Maydell ha scritto: > On 2 June 2013 16:43, Paolo Bonzini 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