pmap_change_attr: Only fixup DMAP for DMAPed ranges

[cem]

Summary

pmap_change_attr must change the memory type of both the requested KVA
and the corresponding DMAP mappings (if such mappings exist), to satisfy
an Intel requirement that two or more mappings to the same physical
pages must have the same memory type.

However, not all kernel mapped pages have corresponding DMAP mappings --
for example, 64-bit BARs. Skip fixing up the DMAP for out-of-bounds
addresses.

Submitted by: Steve Wahl <[e-mail]>
Sponsored by: Dell Compellent

Test Plan

I re-enabled the pmap_change_attr() of a non-DMAP 64-bit BAR in the ntb_hw(4)
driver. The call succeeds without error and without crashing.

[jhb]

alc@ also approved this in e-mail, so he can be listed in Reviewed by as well.

[vangyzen]

head/sys/amd64/amd64/pmap.c

6546

I don't claim to fully understand this code, but should this PG_PS_FRAME be PG_FRAME instead?

I noticed this while merging from FreeBSD into our tree. Ours has PG_FRAME here.

[cem]

head/sys/amd64/amd64/pmap.c

6546

Yeah, I think you're right. This is the !PG_PS case and the code below references PG_FRAME. The constants are similar, but not identical, so this check is ignoring some valid PTEs below, but near to, the dmaplimit.

[kib]

head/sys/amd64/amd64/pmap.c

6546

I think that fix to replace PG_PS_FRAME with PG_FRAME is valid.

Note that the current code does not ignore, but erronously processes some ptes which are for pages after dmaplimit, if ever this range becomes demoted. This should result in assertion from PHYS_TO_DMAP(), at least.

Please commit the fix. Also, I think that pa_end == (*pde & PG_PS_FRAME) case might be wrong as well, after the fix.

[alc]

Yes, PG_PS_FRAME should be replaced by PG_FRAME here. Please commit that change.

Kostik, I didn't understand your last comment. Can you please elaborate?

[kib]

In D4030#222841, @alc wrote:

Kostik, I didn't understand your last comment. Can you please elaborate?

I looked at the wrong if() branch in my editor, sorry.