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.

In D25672#817019, @kib wrote:

In D25672#816160, @alc wrote:

Do you want to resume work on this, and finish some pieces and commit them?

I hope so, but I am not sure I can do anything that large ATM. Do you have specific proposals about already useful pieces?

Since callers to iommu_gas_map_region() provide the entry, assert that the entry was actually allocated for the domain in which the mapping is about to be created.

Add comments.

Do you want to resume work on this, and finish some pieces and commit them?

Add a couple comments.

Fix arm64. I previously added the new parameter to the wrong function.