Re: [Xen-devel] [PATCH 5/5] xen: arm: handle PCI DT node ranges and interrupt-map properties

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2015-02-17 at 17:33 +0000, Julien Grall wrote:
> Hi Ian,
> 
> On 24/10/14 10:58, Ian Campbell wrote:
> > These properties are defined in ePAPR and the OpenFirmware PCI Bus Binding
> > Specification (IEEE Std 1275-1994).
> > 
> > This replaces the xgene specific mapping. Tested on Mustang and on a model 
> > with
> > a PCI virtio controller.
> 
> I'm wondering why you choose to map everything at Xen boot time rather
> than implementing PHYSDEVOP_pci_device_add to do the job?

Does pci_device_add contain sufficient information to do so?

The regions which are being mapped are essentially the PCI host
controllers MMIO, IO and CFG "windows" which are then consumed by the
various bars of the devices on the bus.

So mapping based on pci_device_add would require us to go from the SBDF
to a set of BARS which need mapping, which is a whole lot more complex
than just mapping all of the resources owned by the root complex through
to the h/w domain.

Or perhaps I've misunderstood what you were suggesting?

> This would allow us to re-use most of the interrupts/mmio decoding
> provided in the device tree library. It would also avoid missing support
> of cascade ranges/interrupt-map.

I *think* (if I'm remembering right) I decided we don't need to worry
about cascades of these things because the second level resources are
all fully contained within the first (top level) one and so with the
approach I've taken here are all fully mapped already. That's why I made
this patch stop descending into children when such a "bus node" is
found.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel