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 <marce...@redhat.com> 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 >