Date: Sun, 16 Mar 2014 11:05:16 -0400 From: Ryan Stone <rysto32@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: [PATCH] Support PCIe Alternative RID Interpretation (ARI) Message-ID: <CAFMmRNwormaaPXk6rJ-JJGePS6fDNFsdKAfmmW2jGLNRscf1Pw@mail.gmail.com> In-Reply-To: <20140316141216.GA21331@kib.kiev.ua> References: <CAFMmRNzL3uBZ-djWgpnKi3XDQdq4c1ODAL_8E-Vpy-dPLa-hog@mail.gmail.com> <20140316141216.GA21331@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Mar 16, 2014 at 10:12 AM, Konstantin Belousov <kostikbel@gmail.com> wrote: > This is expected, but it would break VT-d busdma, I think. > > This is not said in the VT-d spec about ARI, but I believe that > DMAR would split the function number by 7-3/2-0 bits, same as for > the non-ARI devices. Then the transactions will be translated by > the wrong context. Ah, good catch. I took a quick look at the spec and the code, and I believe that I see the problem. I think that the proper solution is to add a new method, pcib_get_rid(), that returns (bus << 8) | (slot << 5) | func for non-ARI devices and (bus << 8) | func for ARI devices. Then we could add a pci_get_rid() that just calls the pcib method, and the DMAR code could be changed to work in terms of the RID instead of bus/slot/function. My reading of the spec is that VT-d is really implemented in terms of the RID anyway, but the spec authors took pains to give examples in terms of bus/slot/function because that's how the software developers understand things. Do you know if bhyve's pci passthrough code uses the same code to add DMAR entries as the busdma code? If not I'll have to track down how bhyve does it because it would likely have the same problem. > From other minor notes, having additional line for "ARI enabled" > message under bootverbose would make already excessive PCI config > dump even more problematic. I can remove it. At the time I wanted some kind of indication that ARI was being used, but pciconf can tell you that now so it's not really necessary.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFMmRNwormaaPXk6rJ-JJGePS6fDNFsdKAfmmW2jGLNRscf1Pw>