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.
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to