On Sat, Jan 13, 2018 at 08:31:40PM -0800, Nathan Whitehorn wrote: > > > On 01/13/18 15:28, Nathan Whitehorn wrote: > > > > > > On 01/13/18 15:24, Konstantin Belousov wrote: > >> On Sat, Jan 13, 2018 at 11:14:53PM +0000, Nathan Whitehorn wrote: > >>> +/* > >>> + * We (usually) have a direct map of all physical memory. All > >>> + * uses of this macro must be gated by a check on hw_direct_map! > >>> + * The location of the direct map may not be 1:1 in future, so use > >>> + * of the macro is recommended; it may also grow an assert that > >>> hw_direct_map > >>> + * is set. > >>> + */ > >>> +#define PHYS_TO_DMAP(x) x > >>> +#define DMAP_TO_PHYS(x) x > >> Take a look at the sys/vm/vm_page.c:vm_page_free_prep() function. > >> > > > > I think the checks in there should work as designed, unless I'm > > missing something. Am I? > > -Nathan > > > > Actually, wait, this is broken if hw_direct_map is not set. I can do an > #ifdef __powerpc__ hack, but do you have opinions for a better MI flag > for "yes, the macro is defined but, no, the direct map may not be > available"?
Exactly. You explicitly noted the need to check for the hw_direct_map in the comment, so I did not see a need to explain further. We intended that PHYS_TO_DMAP/DMAP_TO_PHYS become MI KPI. If the symbols are present, their semantic is the unconditional presence and usability of the direct map. sf bufs were rototiled with things like SFBUF_OPTIONAL_DIRECT_MAP, but I dislike it and hope that PHYS_TO_DMAP would be not damaged this way. _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
