[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addres
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses |
Date: |
Mon, 9 Sep 2013 17:01:25 +0300 |
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 <address@hidden> 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
>
- Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses, (continued)
- Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses, Marcel Apfelbaum, 2013/09/09
- Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses, Peter Maydell, 2013/09/09
- Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses, Marcel Apfelbaum, 2013/09/09
- Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses, Michael S. Tsirkin, 2013/09/10
- Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses, Peter Maydell, 2013/09/10
- Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses, Michael S. Tsirkin, 2013/09/10
- Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses, Peter Maydell, 2013/09/10
- Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses, Michael S. Tsirkin, 2013/09/10
- Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses, Michael S. Tsirkin, 2013/09/15
- Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses, Marcel Apfelbaum, 2013/09/15
- Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses,
Michael S. Tsirkin <=
- Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses, Michael S. Tsirkin, 2013/09/09
- Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses, Marcel Apfelbaum, 2013/09/09