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

[Espen Skoglund <espen.skoglund@xxxxxxxxxxxxx>]

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