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

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





On Tuesday 14 July 2015 11:31 PM, Stefano Stabellini wrote:
On Tue, 14 Jul 2015, Julien Grall wrote:
Hi Stefano,

On 14/07/2015 18:46, Stefano Stabellini wrote:
Linux provides a function (pci_for_each_dma_alias) which will return a
requester ID for a given PCI device. It appears that the BDF (the 's' of
sBDF
is only internal to Linux and not part of the hardware) is equal to the
requester ID on your platform but we can't assume it for anyone else.
The PCI Express Base Specification states that the requester ID is "The
combination of a Requester's Bus Number, Device Number, and Function
Number that uniquely identifies the Requester."

I think it is safe to assume BDF = requester ID on all platforms.
With the catch that in case of ARI devices
(http://pcisig.com/sites/default/files/specification_documents/ECN-alt-rid-interpretation-070604.pdf),
BDF is actually BF because the device number is always 0 and the
function number is 8 bits.
And some other problem such as broken PCI device...
Both Xen x86 (domain_context_mapping in drivers/passthrough/vtd/iommu.c) and
Linux (pci_dma_for_each_alias) use a code more complex than requesterID = BDF.

So I don't think we can use requesterID = BDF in physdev op unless we are
*stricly* sure this is valid.
The spec is quite clear about it, but I guess there might be hardware quirks.
Can we keep this open and for now till there is agreement make requesterid = bdf.
If you are ok, I will update and send Draft 3.


Although, based on the x86 code, Xen should be able to translate the BDF into
the requester ID...
Yes, that is a good point.


_______________________________________________
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®.