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

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



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.


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