From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50550) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJ1C9-000397-Ru for qemu-devel@nongnu.org; Mon, 09 Sep 2013 09:08:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VJ1C3-0002nF-Rw for qemu-devel@nongnu.org; Mon, 09 Sep 2013 09:07:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32068) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJ1C3-0002n4-IP for qemu-devel@nongnu.org; Mon, 09 Sep 2013 09:07:51 -0400 Message-ID: <1378732073.3072.42.camel@localhost.localdomain> From: Marcel Apfelbaum Date: Mon, 09 Sep 2013 16:07:53 +0300 In-Reply-To: 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> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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 , "Michael S. Tsirkin" On Mon, 2013-09-09 at 13:52 +0100, Peter Maydell wrote: > On 9 September 2013 13:43, Marcel Apfelbaum wrote: > > The scenario is covered only for the primary bus and not for buses > > behind the PCI bridge (the later being handled differently.) > > In this case, isn't the Host Bridge always device 00.0? > > No. For instance the host controller may pass a nonzero > value of devfn_min to pci_bus_new/pci_register_bus (in > which case the host bridge will end up there; example > hw/pci-host/versatile.c) or it might just pass a nonzero > devfn to pci_create_simple when it creates the host controller > PCI device on the bus (I don't think we have anything that > does it that way, though). If my assumption is not generally true, I will not use it Thanks! > > > If not, can we find a way to scan all bus devices and find > > the host bridge so we will not have to manually add it to each > > host bridge? > > It would be conceptually nicer not to treat host bridges as > a special case but instead to just report the abort back > to whatever the PCI master was (which might be a device > doing DMA). That might be a lot of effort though. 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. However, if we don't want the master device far all accesses (including DMA) but only for accesses to pci address space, in this specific case we can appoint the HostBridge (explicitly/implicitly) as the master device because most devices do not access pci address space of other devices. As a conclusion, should we call the API pci_set_master_for_master_abort_on_pci_space ? Marcel > > -- PMM