From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52690) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJNkx-0000CN-Ng for qemu-devel@nongnu.org; Tue, 10 Sep 2013 09:13:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VJNkr-00083x-NS for qemu-devel@nongnu.org; Tue, 10 Sep 2013 09:13:23 -0400 Received: from mail-la0-f44.google.com ([209.85.215.44]:36639) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJNkr-00083t-H1 for qemu-devel@nongnu.org; Tue, 10 Sep 2013 09:13:17 -0400 Received: by mail-la0-f44.google.com with SMTP id eo20so6280658lab.3 for ; Tue, 10 Sep 2013 06:13:16 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20130910130229.GB2121@redhat.com> References: <1378725114-13197-3-git-send-email-marcel.a@redhat.com> <20130909114029.GB31476@redhat.com> <1378728715.3072.14.camel@localhost.localdomain> <20130909122307.GB583@redhat.com> <1378730629.3072.32.camel@localhost.localdomain> <1378732073.3072.42.camel@localhost.localdomain> <20130910123917.GA1800@redhat.com> <20130910130229.GB2121@redhat.com> From: Peter Maydell Date: Tue, 10 Sep 2013 14:12:56 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Paolo Bonzini , Anthony Liguori , Jan Kiszka , QEMU Developers , Marcel Apfelbaum On 10 September 2013 14:02, Michael S. Tsirkin wrote: > On Tue, Sep 10, 2013 at 01:50:47PM +0100, Peter Maydell wrote: >> On 10 September 2013 13:39, Michael S. Tsirkin wrote: >> > On Mon, Sep 09, 2013 at 02:16:41PM +0100, Peter Maydell wrote: >> >> memory_region_init_alias(&pci_dev->bus_master_enable_region, >> >> OBJECT(pci_dev), "bus master", >> >> dma_as->root, 0, >> >> memory_region_size(dma_as->root)); >> >> >> >> If instead of using this alias directly as the >> >> bus_master_enable region you instead: >> >> * create a container region >> >> * create a 'background' region at negative priority >> >> (ie one per device, and you can make the 'opaque' pointer >> >> point to the device, not the bus) >> >> * put the alias and the background region into the container >> >> * use the container as the bus_master_enable region >> > >> > Interesting. There's one thing I don't understand here: >> > as far as I can see bus_master_enable_region covers the >> > whole 64 bit memory address space. >> > >> > It looks like it will always override the background >> > region in the same container. What did I miss? >> >> That should be itself a container, >> so assuming it doesn't >> itself have any kind of background region the "holes" >> inside it will still be present when we put it in >> our new container. (Basically putting a container, >> or an alias to one, inside a region is just saying >> "put everything in that container inside this region >> at the appropriate place"). > > Confused. "That" and "it" here refers to what exactly? Well, I was a bit confused by your talking about the properties of "bus_master_enable_region" when my suggestion is effectively that we change what that is. So let's start again: * create a container region This is 64 bits wide, but totally empty * create a 'background' region at negative priority 64 bits wide * put the alias and the background region into the container The alias is 64 bits wide too, but it is an alias of dma_as->root, which is a container with no background region. * use the container as the bus_master_enable region -- all you see in this container is the background region and anyhing that was in dma_as->root. So when I said "that" and "it" I meant dma_as->root. Hope that is a little less opaque. -- PMM