[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI

On 23/02/15 8:45 pm, Julien Grall wrote:
On 23/02/15 11:50, Manish Jaggi wrote:
On 23/02/15 4:44 pm, Julien Grall wrote:

On 23/02/2015 10:59, Manish Jaggi wrote:
On 20/02/15 8:09 pm, Ian Campbell wrote:
On Fri, 2015-02-20 at 19:44 +0530, Manish Jaggi wrote:
Another option might be a new hypercall (assuming one doesn't already
exist) to register a PCI bus which would take e.g. the PCI CFG base
address and return a new u16 segment id to be used for all subsequent
PCI related calls. This would require the dom0 OS to hook its
pci_bus_add function, which might be doable (more doable than
xen_segment_id DT properties I think).
This seems ok, i will try it out.
I recommend you let this subthread (e.g. the conversation with Jan)
settle upon a preferred course of action before implementing any one
Ian we have also to consider for NUMA / multi node where there are two
or more its nodes.

msi-parent = <&its0>;


msi-parent = <&its1>;

This requires parsing pci nodes in xen and create a mapping between pci
nodes and its. Xe would need to be aware of PCI nodes in device tree
prior to dom0 sending a hypercall. Adding a property to pci node in
device tree should be a good approach.
Why do you need it early? Wouldn't be sufficient to retrieve those
information when the hypercall pci_device_add is called?

The dom0/U device tree should have one 1 its node, xen should map to
specific its when trapped.
The DOM0 device tree should expose the same layout as the hardware. By
exposing only one ITS you make your life more complicate.
in what way?

PHYSDEVOP_pci_device_add should be called before any initialization is
done. Therefore ITS should be configured for this PCI after Xen is aware
of the PCI.
That is for a device, I believe all devices on a host bridge are serviced by a single ITS

IHMO, any ITS trap before this is wrong.
AFAIK guest always sees a virtual ITS, could you please explain what is wrong in trapping.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.