[PATCH] Support PCIe Alternative RID Interpretation (ARI)

[Konstantin Belousov]

On Mon, Mar 24, 2014 at 03:34:21PM -0400, Ryan Stone wrote:
> On Wed, Mar 19, 2014 at 10:02 AM, Konstantin Belousov
> <kostikbel at gmail.com> wrote:
> > I do not like this, in fact.  Not the general idea, but the implementation.
> > I think that what is needed is method which would return combined
> > slot/function number (or just function number for ARI-enabled device).
> > Then, existing pci_get_bus() and this new method are enough for proper
> > construction of the translating structures.
> 
> I disagree with this approach.  I think that the interface that you
> envision is too specific to the needs of the DMAR code.  This idea of
> a "half RID" really only exists in the VT-d spec.  I have some more
> work forthcoming (for which ARI is a requirement) where I need to
> access the full RID: when PCI SR-IOV is used to instantiate virtual
> PCI functions(VFs), the VFs appear on the PCI tree at a specified
> offset from the RID of the parent physical device.  That offset is
> definitely not guaranteed to be < 255 (in other words, the VFs might
> appear at a different bus number from the parent).  The current code
> that I have to deal with this knows way too much about the details of
> how to decode RIDs, including the possibility of ARI.  Writing it in
> terms of an interface like pci_get_rid() should simplify it nicely and
> help localize the knowledge of ARI to the pcib driver.
Well, either the interface I described is provided by pci core, or
iommu has to de-facto implement it itself.  IMO it is clearer to have
it in pci, but I do not want to block your work on this.

> 
> > Again, I do not like this.  IMO the patch is too conservative.
> > Almost all occurences of the s/f in the IOMMU code must be removed,
> > and replaced by the half-rid returned by the new method from above.
> > In particular, context must be stripped of s/f at all.
> 
> Originally I was going to remove all references to slot and function
> in the DMAR code.  However what I found was that there are a number of
> places that want to print the pci bus/slot/func for debugging
> purposes.  In those places printing out the RID is a lot less user
> friendly, so I left the slot and func members in the context for this
> purpose.  I wasn't entirely happy with this either to be honest.
I mean, that slot and func should be obtained using pci accessors where
needed.  It is definitely not perf-critical, and I dislike having both
bsf and rid in the context structure more, then using accessors.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20140325/89d42236/attachment.sig>