Fix some nits in 1G page handling.

[markj]

Summary

• Move assertions out of the main loop. This makes the assertion condition simpler and makes the code easier to follow IMO.
• Fix va_next updates. In some cases we were not doing the wraparound check before continuing the loop.
• Use the right va_next. In pmap_advise() and pmap_copy() we would step through 1G pages 2M at a time.
• Write "non-transparent" instead of "non-transient" in the assertion message. I believe this was the original intent.

[alc]

sys/amd64/amd64/pmap.c

5946 ↗

(On Diff #77139)

Shouldn't this really say something like, "partial removal of non-transparent 1G mapping "? The key word being "partial".

5951 ↗

(On Diff #77139)

There is an extra space here.

6237 ↗

(On Diff #77139)

Ditto.

7381 ↗

(On Diff #77139)

Ditto.

7509 ↗

(On Diff #77139)

Why aren't we copying the mapping here?

8568 ↗

(On Diff #77139)

Ditto.

[markj]

sys/amd64/amd64/pmap.c

5946 ↗

(On Diff #77139)

I changed it to "partial update of non-transparent 1G mapping" in all places.

7509 ↗

(On Diff #77139)

I don't think there is any reason not to do it.

[markj]

Implement handling for 1G pages in pmap_copy().

[markj]

Drop a test printf().

[kib]

Hm, unless I miss something, does pmap_copy() break MINHERIT_ZERO ?

[markj]

In D26463#589164, @kib wrote:

Hm, unless I miss something, does pmap_copy() break MINHERIT_ZERO ?

From my reading, pmap_copy() is only used for VM_INHERIT_COPY and _SHARED.

[kib]

In D26463#589165, @markj wrote:

In D26463#589164, @kib wrote:

Hm, unless I miss something, does pmap_copy() break MINHERIT_ZERO ?

From my reading, pmap_copy() is only used for VM_INHERIT_COPY and _SHARED.

Right, pmap_copy() is only called per map entry.

[alc]

head/sys/amd64/amd64/pmap.c

6504

Can't pmap_pml4e() now return NULL under LA57?

6528

I don't understand why we do this unconditionally. We don't use mp except in the then clause of the below if statement.

6536

Using PG_FRAME here will include X86_PG_PDE_PAT in the compared bits.

6566

Ditto.

6572

Ditto.

6582

I find it curious that the resident count is handled one way and the wired count another way.

[alc]

head/sys/amd64/amd64/pmap.c

6221

Can't pmap_pml4e() now return NULL under LA57?

[kib]

head/sys/amd64/amd64/pmap.c

6221

Yes this is systematic error. D26492.

[markj]

head/sys/amd64/amd64/pmap.c

6536

I believe we can actually make this assertion stronger and write

KASSERT((origpte & PG_V) == 0 || ((origpte ^ pten) & ~(PG_W | PG_M)) == 0, (...));

[kib]

head/sys/amd64/amd64/pmap.c

6536

Why PG_RW or PG_NX cannot change ? And I am not sure about PAT.