Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 14 Jan 2018 19:05:02 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Nathan Whitehorn <nwhitehorn@freebsd.org>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r327950 - in head/sys/powerpc: aim include powerpc ps3
Message-ID:  <20180114170502.GB1684@kib.kiev.ua>
In-Reply-To: <ede06fc6-7c34-100c-8a7a-6346cd8cd363@freebsd.org>
References:  <201801132314.w0DNEra5002692@repo.freebsd.org> <20180113232441.GV1684@kib.kiev.ua> <010d0153-8931-a3c2-db21-dfcbaf848fc0@freebsd.org> <f33e9b1a-28bd-e6cf-4bdb-ec0097c0787d@freebsd.org> <20180114083036.GX1684@kib.kiev.ua> <ede06fc6-7c34-100c-8a7a-6346cd8cd363@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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).



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180114170502.GB1684>