Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Mar 2014 15:34:21 -0400
From:      Ryan Stone <rysto32@gmail.com>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Neel Natu <neelnatu@gmail.com>
Subject:   Re: [PATCH] Support PCIe Alternative RID Interpretation (ARI)
Message-ID:  <CAFMmRNxM1E2aNtZV588V3BGkz1aOaGgAXGbgktYrmzT9M3EyVw@mail.gmail.com>
In-Reply-To: <20140319140236.GM21331@kib.kiev.ua>
References:  <CAFMmRNzL3uBZ-djWgpnKi3XDQdq4c1ODAL_8E-Vpy-dPLa-hog@mail.gmail.com> <20140316141216.GA21331@kib.kiev.ua> <CAFMmRNwormaaPXk6rJ-JJGePS6fDNFsdKAfmmW2jGLNRscf1Pw@mail.gmail.com> <CAFgRE9F632zLseG7MobxgV5CdvD0KyMn28CBSwYqVtZKuLBwRw@mail.gmail.com> <CAFMmRNwCGVhyn5cU29YpsVq44Q5i51C38GVsz33xGeqNyemx0Q@mail.gmail.com> <20140319140236.GM21331@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 19, 2014 at 10:02 AM, Konstantin Belousov
<kostikbel@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.

> 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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFMmRNxM1E2aNtZV588V3BGkz1aOaGgAXGbgktYrmzT9M3EyVw>