I'd estimate that this change increases the achieved bandwidth by netperf TCP_MAERTS from about 3500-3550Mbps to 3650-3700MBps.

In D35487#804780, @br wrote:

The idea of these wrappers was to abstract function names, i.e. make them looking generic by removing name "gas". I'm not sure what "gas" stands for, but there is no such thing on arm64.

For posterity, in other words, anyone who looks at this review, this change together with the last two changes to this same file have reduced iommu page table page usage by a netperf TCP_MAERTS test from ~181 to ~151.

Please explain why this change is needed in the summary.

In D35424#803847, @andrew wrote:

Do we need the offset? We just need a mapping for the physical page the vm_page_t points to.

Andrew, can you please explain the arguments being passed to iommu_map_msi() in gicv3_iommu_init()? The "offset" argument should really be a value that is less than the page size. Right now, it is 0x10040.

In D35424#803735, @kib wrote:

Please ask Peter to check this.

In D33947#786095, @markj wrote:

vm_phys_alloc_seg_contig() will ignore runs of pages that aren't contained in the range [seg->start, seg->end], so doesn't this change potentially cause us to skip over eligible runs?

Peter, can you please test this?

I do, however, think that this deserves explanation in the form of a comment.

Andrew, I'll give this patch a final look over the weekend.

Hmm. At first this didn't make sense to me. The "assertions" were written this way so that systm.h wouldn't have to be included, but the prototype for panic() is provided by systm.h. So, this code might as well have used KASSERT all along.

I'm quite surprised to see this feature supported by the Graviton 2. I would only have expected to see this feature on micro-architectures that implement SMT/hyperthreading. In fact, the last paragraph of https://developer.arm.com/documentation/101811/0101/Address-spaces-in-AArch64 essentially says so. I wonder if it's simply a NOP on Graviton 2.

I'll take a look at this tomorrow.

Here is the start of pmap_qenter(). Note the right shift followed by left shift:

As an aside, I just verified that arm64 is already setting the equivalent bits.

@andrew didn't you have a patch for implementing CnP support? If so, could you please post it?

Add comments at the head of pmap_invalidate_{all,page,range}(). In particular, document pmap_invalidate_all() as always invalidating all intermediate-level entries.

Implement Mark's suggested optimization plus a related optimization to handling a singleton valid range as the last mapping in the PTP. Please check the logic carefully.

In D33705#761849, @kib wrote:

Does arm64 use recursive mapping?