From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45678) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJNC4-0008FU-83 for qemu-devel@nongnu.org; Tue, 10 Sep 2013 08:37:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VJNBy-0005VO-8W for qemu-devel@nongnu.org; Tue, 10 Sep 2013 08:37:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10150) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJNBy-0005VK-1F for qemu-devel@nongnu.org; Tue, 10 Sep 2013 08:37:14 -0400 Date: Tue, 10 Sep 2013 15:39:17 +0300 From: "Michael S. Tsirkin" Message-ID: <20130910123917.GA1800@redhat.com> References: <1378725114-13197-1-git-send-email-marcel.a@redhat.com> <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> 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 Mon, Sep 09, 2013 at 02:16:41PM +0100, Peter Maydell wrote: > On 9 September 2013 14:07, Marcel Apfelbaum wrote: > > This is exactly my point. ALL device on the bus can be masters > > of a DMA transaction. So adding an interface as suggested by > > Michael: pci_set_master_for_master_abort(PCIBus *, PCIDevice *) > > for the general case (a device doing DMA) it is too far from reality. > > Actually I don't think it would be too painful. > At the moment in do_pci_register_device() we do this to > create the memory region used by a device for its bus > master transactions: > > 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? > 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? > > thanks > -- PMM 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). -- MST