Another option would be to pick a random virtual address for anon_loc at execve() time, and never update it. So, all virtual address allocations would be performed using an address-ordered, first-fit policy, just like we do when ASLR is turned off.

The riscv pmap names this macro PTE_TO_PHYS, and I will argue for using the same name both here and there. Whether that happens by renaming it here, or there, I don't care. I just don't want them to use different names for doing similar things.

I am in the middle of making up a final exam for my class. I will take a final look at this on Wednesday.

Overall, I think that this is okay.

I assume that you did not modify pmap_pti_pcid_invlpg and pmap_pti_pcid_invlrng in support.S because the broken do not require PTI. Is that correct?

Do you have any guess as to how long we might be stuck with this workaround? If the need for it persists, then we may want to have a wrapper to optimize the range operations to avoid repeating INVPCID_CTXGLOB.

Add @dougm

Update comment.

As an aside, in a few weeks, I may eliminate the requirement that PG_A/ATTR_AF is set, add a call to pmap_promote_{pde,l2}() from pmap_enter_quick_locked(), and change pmap_advise(MADV_FREE) to simply write protect one 4KB mapping after demotion (rather than destroying it).

In D36685#838132, @jhb wrote:

In D36685#838118, @alc wrote:

Everything in _pv_entry.h except for the notion of there being a struct pv_entry with at least a virtual address and TAILQ is original to peter@. I don't see a reason for a Regents copyright.

Mmmm, ok. I can drop the UCB copyright, but @peter would have to be the one to change it to a 2 clause license.

Everything in _pv_entry.h except for the notion of there being a struct pv_entry with at least a virtual address and TAILQ is original to peter@. I don't see a reason for a Regents copyright.

See D36801 for changes to the amd64 and arm64 pmaps to avoid the unnecessary pmap_enter_quick_locked() calls. I recommend merging those changes to riscv.

You might ask @dougm to take a look at this.

In D36563#832162, @markj wrote:

pmap_enter_object() is used only to prefault mappings [of a single VM object], so it is allowed to do nothing. I'm not sure if that was the intent behind the interface when it was first introduced, since the name doesn't suggest that it is advisory.

Shouldn't the same change be made on arm64?

Shouldn't the same change be made on arm64?

vm/pmap.h has always included machine/pmap.h, so there is no need for both includes.

Otherwise, I'm fine with this change.

Otherwise, I think that this is ready to commit.

Please go ahead and commit the changes to tree.3.