Date: Mon, 17 Mar 2014 14:20:00 -0700 From: Neel Natu <neelnatu@gmail.com> To: Ryan Stone <rysto32@gmail.com> Cc: Konstantin Belousov <kostikbel@gmail.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: [PATCH] Support PCIe Alternative RID Interpretation (ARI) Message-ID: <CAFgRE9F632zLseG7MobxgV5CdvD0KyMn28CBSwYqVtZKuLBwRw@mail.gmail.com> In-Reply-To: <CAFMmRNwormaaPXk6rJ-JJGePS6fDNFsdKAfmmW2jGLNRscf1Pw@mail.gmail.com> References: <CAFMmRNzL3uBZ-djWgpnKi3XDQdq4c1ODAL_8E-Vpy-dPLa-hog@mail.gmail.com> <20140316141216.GA21331@kib.kiev.ua> <CAFMmRNwormaaPXk6rJ-JJGePS6fDNFsdKAfmmW2jGLNRscf1Pw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Ryan, On Sun, Mar 16, 2014 at 8:05 AM, Ryan Stone <rysto32@gmail.com> wrote: > 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. > bhyve has a different implementation of the VT-d driver although transitioning to x86/iommu is long overdue. In any case it seems that the VT-d implementation in bhyve will work fine with ARI enabled devices. best Neel >> 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. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFgRE9F632zLseG7MobxgV5CdvD0KyMn28CBSwYqVtZKuLBwRw>