On Sun, Jan 14, 2018 at 08:06:19AM -0800, Nathan Whitehorn wrote: > > > On 01/14/18 00:30, Konstantin Belousov wrote: > > 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. > > > > That's unfortunate. Is there any reason you need this to be certain at > compile time? That seems to be quite restrictive and not to add a huge > amount of performance. We tend to start using PHYS_TO_DMAP in MI code. Both amd64 and arm64 do not need a qualification.
> Given the exciting variety of MMU modes on > PowerPC, there is not any way to guarantee the presence of a direct map > at compile time, so the alternative is to invent a whole new kernel > signalling mechanism for "direct map is almost certainly available, but > might not be", which seems strictly worse, or to have a standard API > that PowerPC can't use, which also seems worse. Why not use a slight variation of the symbol name, to not confuse MI code ? E.g. PPC_PHYS_TO_DMAP (only as an example, it is not hard to construct a better name). _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"