From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35625) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJ1zz-0005oW-VB for qemu-devel@nongnu.org; Mon, 09 Sep 2013 09:59:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VJ1zt-0001fx-VB for qemu-devel@nongnu.org; Mon, 09 Sep 2013 09:59:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60573) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJ1zt-0001fs-LR for qemu-devel@nongnu.org; Mon, 09 Sep 2013 09:59:21 -0400 Date: Mon, 9 Sep 2013 17:01:25 +0300 From: "Michael S. Tsirkin" Message-ID: <20130909140125.GD1052@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: <1378732073.3072.42.camel@localhost.localdomain> 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: Marcel Apfelbaum Cc: Peter Maydell , Anthony Liguori , Jan Kiszka , QEMU Developers , Paolo Bonzini On Mon, Sep 09, 2013 at 04:07:53PM +0300, Marcel Apfelbaum wrote: > 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 I like Peter's idea of detecting a host bridge implictly using device type. With a big FIXME explaining that we shouldn't need to do this. > > > > > > > -- PMM >