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

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.