From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50327) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJNYw-0004e6-MR for qemu-devel@nongnu.org; Tue, 10 Sep 2013 09:01:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VJNYn-0004GP-V8 for qemu-devel@nongnu.org; Tue, 10 Sep 2013 09:00:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12039) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJNYn-0004GI-Ne for qemu-devel@nongnu.org; Tue, 10 Sep 2013 09:00:49 -0400 Date: Tue, 10 Sep 2013 16:02:29 +0300 From: "Michael S. Tsirkin" Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Peter Maydell Cc: Paolo Bonzini , Anthony Liguori , Jan Kiszka , QEMU Developers , Marcel Apfelbaum 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? > >> then you will get in your callback a pointer to the > >> device which caused the abort. You can then have your > >> callback call a method defined on PCIDevice which we > >> implement: > >> * as do-nothing in the PCI device base class > >> * as set-the-master-abort bit in the PCI host bridge > >> class > >> (and anybody who wants to get fancy about handling aborts > >> can override it in their own device implementation) > >> > >> That seems achievable without really requiring new > >> infrastructure. Have I missed something that wouldn't > >> work if we did this? > > > Actually, I think a base class would have to set received master abort > > bit in the status register. > > And it's not even that simple: memory writes are completed by a P2P > > bridge so I think it has to set a bit in the primary status register for > > the bridge and not for the device (though I'm speaking from memory, > > need to check the spec). > > Yes, I didn't really work through how bridges might > need to be handled. Hopefully we can come up with > a neat trick for those too :-) > > -- PMM