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

[Nathan Whitehorn]

On 01/15/18 09:53, Konstantin Belousov wrote:
> 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.
>

Fair enough. Here's a patch with a new flag (DIRECT_MAP_AVAILABLE). I've 
also retooled the sfbuf code to use this rather than its own flags that 
mean the same things. The sparc64 part of the patch is untested.
-Nathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmap_api.diff
Type: text/x-patch
Size: 6355 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20180115/1b4bc7e3/attachment.bin>