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

["Daney, David" <David.Daney@xxxxxxxxxxxxxxxxxx>]

I apologize for the top post, but for the record;

The Thunder Linux implementation will be obtaining the PCI requester id from 
the OF device tree, or ACPI IORT table.  It will *not* be derived from any 
hardware address.

It may make sense to use the same technique to get the PCI requester id in the 
XEN environment too.

David Daney.
________________________________________
From: Julien Grall <julien.grall@xxxxxxxxxx>
Sent: Saturday, September 19, 2015 1:48:43 PM
To: Jaggi, Manish; Jaggi, Manish; Xen Devel
Cc: Konrad Rzeszutek Wilk; ★ Stefano Stabellini; Ian Campbell; Daney, David; 
Prasun.kapoor@xxxxxxxxxx; Kumar, Vijaya
Subject: Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4

Hi Manish,

On 19/09/2015 21:24, Manish Jaggi wrote:
> 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.

There is no place for "I guess". Any approximation here would lead to
add more hypercalls because we design the first one on speculation.

> Each Ecam has a cfg_addr in Thunder, which is mentioned in the pci node
> in device tree.

IIUC what you said, you suggest to retrieve the ECAM based on the
cfg_addr in Xen, right?

If so, this is the wrong way to go we should avoid to have platform
specific code in Xen as much as possible and get everything either via
the firmware table (ACPI or DT) or via hypercall.

> For thunder I think we don't need to pass requester-ID in the phydevop.

May I remind you that this design doc is not about Thunder-X but PCI
passthrough in general. If your platform already requires specific code
in Xen to get the requester ID, what prevents other to not do the same?

So it looks like to me that adding the base requester-ID in the
PHYSDEVOP_pci_host_bridge_add is the right way to go.

Regards,

--
Julien Grall

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