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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 14 Jul 2015, Stefano Stabellini wrote:
> On Thu, 9 Jul 2015, Julien Grall wrote:
> > Hi Manish,
> > 
> > On 09/07/2015 08:13, Manish Jaggi wrote:
> > > > 
> > > > If this was a domctl there might be scope for accepting an
> > > > implementation which made assumptions such as sbdf == deviceid. However
> > > > I'd still like to see this topic given proper treatment in the design
> > > > and not just glossed over with "this is how ThunderX does things".
> > > I got your point.
> > > > Or maybe the solution is simple and we should just do it now -- i.e. can
> > > > we add a new field to the PHYSDEVOP_pci_host_bridge_add argument struct
> > > > which contains the base deviceid for that bridge
> > > deviceId would be same as sbdf. As we dont have a way to translate sbdf
> > > to deviceID.
> > 
> > I think we have to be clear in this design document about the different
> > meaning.
> > 
> > When the Device Tree is used, it's assumed that the deviceID will be equal 
> > to
> > the requester ID and not the sbdf.
> > 
> > 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.

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