WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] PCIe 2.0, VT-d and Intel 82576 enhancement for Xen SR-IO

Why put all this logic into Xen itself?  Finding the matching DRHD
unit will often "just work" anyway by the way the DHRD scope matching
is performed.

That said, yes, I get it that it might sometimes be better to actually
map the VFs and ARI functions back to the PF before matching.
However, why not extend the current device_add function and hypercall
with a master BDF pointing back to the BDF "owning" the function?
This leaves all of the matching up logic out of the hypervisor.  A
zero or -1 master BDF could indicate that there is no owner (i.e., it
owns itself).

        eSk



[Yu Zhao]
> PCIe Alternative Routing-ID Interpretation (ARI) ECN defines the Extended
> Function -- a function whose function number is greater than 7 within an
> ARI Device. Intel VT-d spec 1.2 section 8.3.2 specifies that the Extended
> Function is under the scope of the same remapping unit as the traditional
> function. The hypervisor needs to know if a function is Extended Function
> so it can find proper DMAR for it.

> And section 8.3.3 specifies that the SR-IOV Virtual Function is under the
> scope of the same remapping unit as the Physical Function. The hypervisor
> also needs to know if a function is the Virtual Function and which Physical
> Function it's associated with for same reason.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel