[PATCH] Support PCIe Alternative RID Interpretation (ARI)

[Konstantin Belousov]

On Sun, Mar 30, 2014 at 03:43:23PM -0400, Ryan Stone wrote:
> On Sun, Mar 30, 2014 at 10:29 AM, Konstantin Belousov
> <kostikbel at gmail.com> wrote:
> >> http://people.freebsd.org/~rstone/patches/ari/0002-Re-implement-the-DMAR-I-O-MMU-code-in-terms-of-PCI-R.patch
> >
> > I like this patch.
> >
> > One, trivial note, you do not need () there:
> > +       ctxp += (ctx->rid & 0xff);
> >
> 
> Done.
> 
> Unfortunately I had to re-write it a bit to account for the changes in
> r263306.  Mostly it was trivial, but there's one thing that I wasn't
> sure how best to handle.  busdma_dmar.c currently calls
> dmar_bus_dma_is_dev_disabled with the bus/slot/function provided by
> dmar_get_requestor.  That no longer works now that I've made the code
> be based on RIDs.  What the patch currently does is use the
> bus/slot/function from the requester device.  I think that's a little
> cleaner anyway because in one case the current code fakes up a slot
> and function.  Using those values in the UI for forcing DMAR off for a
> device feels wrong to me (and difficult to document).  However, my
> behaviour of forcing users to manually walk up the PCI tree to find
> the PCIe-PCI bridge is not really all that much better.  If you have
> ideas here please let me know.
I think that the current behaviour is just a bug, and your change is for
better.  When you need to disable specific device from using non-identity
mapping, it means that you are already very much down the hole.  The VT-d
busdma is not enabled by default, only people who experimenting with it
are potentially affected, so I see no problem.

> 
> The current version of the patch is in the same location.
Fine with me.
-------------- 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/20140401/2af04aa8/attachment.sig>