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. _______________________________________________ email@example.com mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"