Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses

[Marcel Apfelbaum <marcel.a@redhat.com>]

On Mon, 2013-09-09 at 13:52 +0100, Peter Maydell wrote:
> On 9 September 2013 13:43, Marcel Apfelbaum <marcel.a@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




> 
> -- PMM