Limit the DMAP memory to available RAM
ClosedPublic
Actions

Authored by andrew on Apr 13 2016, 12:40 PM.

Details

Reviewers

Commits

rS297958: Set the upper limit of the DMAP region to the limit of RAM as was found in

Summary

Set the upper limit of the DMAP region to the limit of RAM as was found in
the physmap. This will reduce the likelihood of an issue where we have
device memory mapped in the DMAP. This can only happen if it is within the
same 1G block of normal memory.

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

andrew updated this revision to Diff 15158.Apr 13 2016, 12:40 PM

andrew retitled this revision from to Limit the DMAP memory to available RAM.

andrew updated this object.

andrew edited the test plan for this revision. (Show Details)

andrew added a reviewer: kib.

andrew added a subscriber: emaste.

Herald added a subscriber: imp. · View Herald TranscriptApr 13 2016, 12:40 PM

This only stops DMAP at L1 block granularity, right ? It still would be good to fine split the mapping of tail of DMAP region.

sys/arm64/arm64/pmap.c
563 ↗	(On Diff #15158)	You can rewrite the loop condition as va < DMAP_MAX_ADDRESS && pa < max_pa. At least for me, it is cleaner when unneeded breaks do not hide loop conditions.

This revision is now accepted and ready to land.Apr 13 2016, 8:06 PM

In D5938#126678, @kib wrote:

This only stops DMAP at L1 block granularity, right ? It still would be good to fine split the mapping of tail of DMAP region.

Correct. I think it would be unlikely for an SoC to put device memory this close to the end of RAM, however we could add a warning when we map device data under INVARIANTS to check for this.

Closed by commit rS297958: Set the upper limit of the DMAP region to the limit of RAM as was found in (authored by andrew). · Explain WhyApr 14 2016, 10:43 AM

This revision was automatically updated to reflect the committed changes.