Date: Tue, 5 Apr 2016 09:14:31 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-current@freebsd.org, Ryan Stone <rysto32@gmail.com> Subject: Re: accessing a PCIe register from userspace through kmem or other ways ? Message-ID: <20160405061431.GF1741@kib.kiev.ua> In-Reply-To: <9376230.YZMFsgSvTf@ralph.baldwin.cx> References: <CA%2BhQ2%2BiU4odjhaNicFA4QjvSZR2OZOOy%2BFu4LTqsibdoK4M8zg@mail.gmail.com> <CAFMmRNxJDuQoC-YuwbaWkj7MGVw9UgPEANOX6bN=i8%2Bp_9vm5w@mail.gmail.com> <20160401170458.GV1741@kib.kiev.ua> <9376230.YZMFsgSvTf@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 04, 2016 at 03:45:07PM -0700, John Baldwin wrote: > However, another question is how to deal with systems that do bus address > translation (like the arm64 ThunderX boxes) where the values in the PCI > BAR are not CPU physical addresses. To do this properly we may need some > sort of bus method akin to my bus_map_resource() WIP but one that instead > returns a suitable 'struct sglist' for a given 'struct resource *' that > can be used with OBJT_SG to build a VM object to use for the mapping. Is there any documentation on the ThunderX PCI access mechanisms ? > > (At some point I do think I would like a variant of OBJT_SG that used > managed pages so that mappings could be revoked when whatever is backing > the sglist is disabled (e.g. the device is ejected or the BAR is > relocated, etc.).) Why cannot you use MGTDEVICE pager already ? Driver would need to maintain its private list of pages, and from this PoV, a convenience wrapper around MGTDEVICE which unifies operations on sg lists could be useful. Still, it could be that the wrapper appear to be single-purpose.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160405061431.GF1741>