[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 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 handling
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
suggestion.
Ian we have also to consider for NUMA / multi node where there are two
or more its nodes.
pci0{

msi-parent = <&its0>;
}

pci1{

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.

What about ACPI case? Does everything necessary live in static table?

Regards,



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


 


Rackspace

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