Date: Mon, 15 Jan 2018 19:53:35 +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: <20180115175335.GK1684@kib.kiev.ua> In-Reply-To: <9e5554d7-6a0c-5910-8cb6-74f98259536f@freebsd.org> References: <20180114170502.GB1684@kib.kiev.ua> <184ba3ee-a9f7-01ed-bb02-1bcba9acc041@freebsd.org> <20180114175211.GD1684@kib.kiev.ua> <b2b1bf30-177b-af30-54ce-f484224bb2ad@freebsd.org> <f4b44b69-7b06-6b5a-c17c-31bd46ca1af0@freebsd.org> <e04bc7a6-fa77-9ca0-2aff-dc29c543c9a1@freebsd.org> <20180115111812.GF1684@kib.kiev.ua> <f6350c61-55d1-9bf7-c4b3-e10fb329a42a@freebsd.org> <20180115170603.GJ1684@kib.kiev.ua> <9e5554d7-6a0c-5910-8cb6-74f98259536f@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 15, 2018 at 09:32:56AM -0800, Nathan Whitehorn wrote: > That seems fine to me. I don't think a less-clumsy way that does not > involve extra indirection is possible. The PHYS_TO_DMAP() returning NULL > is about the best thing I can come up with from a clumsiness standpoint > since plenty of code checks for null pointers already, but doesn't > cleanly handle the rarer case where you want to test for the existence > of direct maps in general without testing some potemkin address. > > My one reservation about PMAP_HAS_DMAP or the like as a selector is that > it does not encode the full shape of the problem: one could imagine > having a direct map that only covers a limited range of RAM (I am not > sure whether the existence of dmaplimit on amd64 implies this can happen > with non-device memory in real life), for example. These cases are > currently covered by an assert() in PHYS_TO_DMAP(), whereas having > PHYS_TO_DMAP() return NULL allows a more flexible signalling and the > potential for the calling code to do something reasonable to handle the > error. A single global flag can't convey information at this kind of > granularity. Is this a reasonable concern? Or am I overthinking things? IMO it is overreaction. amd64 assumes that all normal memory is covered by DMAP. It must never fail. See, for instance, the implementation of the sf bufs for it. If device memory not covered by DMAP can exists, it is the driver problem. For instance, for NVDIMMs I wrote specific mapping code which establishes kernel mapping for it, when not covered by EFI memory map and correspondingly not included into DMAP.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180115175335.GK1684>