On Wednesday 16 September 2015 06:28 PM, Julien Grall wrote:
On 15/09/15 19:58, Jaggi, Manish wrote:
I can see 2 different solutions:
1) Let DOM0 pass the first requester ID when registering the bus
Pros:
* Less per-platform code in Xen
Cons:
* Assume that the requester ID are contiguous. (Is it really a
cons?)
* Still require quirk for buggy device (i.e requester ID not
correct)
2) Do it in Xen
Pros:
* We are not relying on DOM0 giving the requester ID
=> Not assuming contiguous requester ID
Cons:
* Per PCI bridge code to handle the mapping
We can have (3) that when PHYSDEVOP_pci_add_device is called the sbdf
and requesterID both are passed in hypercall.
The name of the physdev operation is PHYSDEVOP_pci_device_add and not
PHYSDEVOP_pci_add_device. Please rename it all the usage in the design doc.
Although, we can't modify PHYSDEVOP_pci_device_add because it's part of
the ABI which is stable.
Based on David's mail, the requester ID of a given device can be found
using base + devfn where base is the first requesterID of the bus.
IIRC, this is also match the IORT ACPI spec.
So for now, I would extend the physdev you've introduced to add an host
bridge (PHYSDEV_pci_host_bridge_add) to pass the base requesterID.
The requester-ID is derived from the Node# and ECAM# as per David. I
guess the ECAM and Node# can be derived from
the cfg_addr.
Each Ecam has a cfg_addr in Thunder, which is mentioned in the pci node
in device tree.
For thunder I think we don't need to pass requester-ID in the phydevop.
We can think later to introduce a new physdev op to add PCI if we ever
require unique requesterID (i.e non-contiguous under the same bridge).
Regards,
---
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel