Re: accessing a PCIe register from userspace through kmem or other ways ?

On Friday, April 01, 2016 08:04:58 PM Konstantin Belousov wrote:
> On Fri, Apr 01, 2016 at 12:48:24PM -0400, Ryan Stone wrote:
> > That is actually a really good question.  I know that with some recent
> > BIOSes if I enabled allocating 64-bit addresses to BARs, the BAR would
> > actually be mapped outside of the range of /dev/mem.  From a quick glance
> > at libpciaccess, I don't think that it handles this case.  A specific
> > mechanism for allowing mmaping of BARs would be useful, I think.
> 
> I am not sure what do you mean by 'outside of the range of /dev/mem'.
> IMO /dev/mem (not kmem) handles every possible physical address both
> for mmap(2) and for read(2)/write(2).  For io interface there were
> some bugs, but they are believed to be fixed.  I mean amd64.

I suspect Ryan might be referring to BARs outside of the DMAP which we
only populate to Maxmem IIRC.  /dev/mem should work for those.

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.

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

-- 
John Baldwin