svn commit: r327950 - in head/sys/powerpc: aim include powerpc ps3

[Konstantin Belousov]

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.