Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4

[Manish Jaggi <mjaggi@xxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel