Would it make sense to add an EXAMPLES section that shows how to define a proper TOPCOLOR?

Implement pmap_is_valid_memattr(9) for all arches (tinderbox is just started).
Stop pretending that uint64_t solves the void * marshalling for compat32, it does not for big-endian machines. Provide real compat32.

That was my 'set textwidth=80' config in neovim. ^^

FYI, I am going to make the pmap change for all arches and want to commit the ioctl(2) + pciconf(8) ASAP.

Remove (bailed)s

I agree, the (bailed) can be removed.

This port is required by several others -- can you check that none of them expect fping6 to be present?

In D15927#338138, @pi wrote:

Yes, please add sections on how to use both tools, and reference the ports (sysutils/intel-qcu and
sysutils/intel-nvmupdate).

I've looked up 'bailed' on dict.leo.org but did not find a valid translation. What are those 'bailed' devices ?

Yes, please add sections on how to use both tools, and reference the ports (sysutils/intel-qcu and
sysutils/intel-nvmupdate).

Should I add a section about the QCU and nvmupdate utilities? They have ports, but I don't think they have manpages, so I don't know how to properly reference them.

Add acronym expansions and info on qualified module check.

Updated following discussion on IRC with Ian:

In D15910#338114, @alc wrote:

In D15910#338113, @alc wrote:

In D15910#338097, @markj wrote:

Isn't this invalid if both the old and new mappings are wired? Or should it not be possible

... for that situation to arise when the mappings are to different physical pages?

To be clear, I'm assuming that the problem that Kostik is worried about is having "spurious" faults on mlock()ed memory. However, when we wire mappings (and the underlying physical pages) during mlock(), we simulate the COW faults. So, in the normal case of mlock(), I assert that there is not a problem. I speculate that setting a breakpoint in the code of an mlockall()ed application might be the one scenario where a temporarily zeroed PTE could occur. Do I need to argue that a spurious page fault in that scenario isn't really of concern. :-)

And for completeness, in the case of a fork of an mlockall()ed application, we preemptively copy all writeable data. (During the fork, other threads are paused from executing, right?)

I've tested the patch itself, and read through the man page. I found VF, without explaination. It stands for
'virtual functions'. Would it be possible to expand it at the first occurance ?

In D15910#338113, @alc wrote:

In D15910#338097, @markj wrote:

Isn't this invalid if both the old and new mappings are wired? Or should it not be possible

... for that situation to arise when the mappings are to different physical pages?

To be clear, I'm assuming that the problem that Kostik is worried about is having "spurious" faults on mlock()ed memory. However, when we wire mappings (and the underlying physical pages) during mlock(), we simulate the COW faults. So, in the normal case of mlock(), I assert that there is not a problem. I speculate that setting a breakpoint in the code of an mlockall()ed application might be the one scenario where a temporarily zeroed PTE could occur. Do I need to argue that a spurious page fault in that scenario isn't really of concern. :-)

In D15910#338097, @markj wrote:

Isn't this invalid if both the old and new mappings are wired? Or should it not be possible

... for that situation to arise when the mappings are to different physical pages?

In D15910#338067, @alc wrote:

In D15910#337632, @kib wrote:

In D15910#337582, @alc wrote:

1. In regards to pmap_enter(), we should aim to kill two birds with one stone. Recall the copy-on-write mapping bug that Kostik worked around in vm_fault(). I say worked around because the root cause is here in pmap_enter(). When the physical page mapped at va is changing, pmap_enter() should destroy the old mapping before creating the new one. Once pmap_enter() is restructured in this way, you can simply recycle the old mapping's PV entry.

Can you elaborate more, please ? What do you mean by destroying the old mapping ? In particular, do you mean installing the pte with clear PG_V into the changing PTE ?

Yes, I mean destroying the PTE, including TLB shootdown. In effect, briefly the PTE will be 0. Then, installing the new PTE is just a pte_store(). All of the stuff that we currently perform under "if ((origpte & PG_V) != 0) {" will already have been performed when we destroyed the PTE.

In D15927#338098, @erj wrote:

In D15927#337633, @pi wrote:

Please expand LOM to 'onboard interfaces (LAN on Motherboard, LOM)', if possible. I'm a 30-years user of ethernet, but I've never heard that abbreviation.

I don't think it's that rare of an abbreviation, but I can add the expansion.

verified working ok in r335524 which includes the name change applied to spigen ( https://reviews.freebsd.org/rS335506 ) on RPi 1 B.

In D15927#337633, @pi wrote:

Please expand LOM to 'onboard interfaces (LAN on Motherboard, LOM)', if possible. I'm a 30-years user of ethernet, but I've never heard that abbreviation.

I don't think it's that rare of an abbreviation, but I can add the expansion.

If an admin can see if an interface is external or LOM, by whatever magic, can you write about it in the man page ?

I looked into this yesterday, and there may not be a 100% accurate way to do this in the driver. I can add something and maybe identify exceptions.

Isn't this invalid if both the old and new mappings are wired? Or should it not be possible

Changes as suggested in the inline comments

In D15910#338067, @alc wrote:

In D15910#337632, @kib wrote:

In D15910#337582, @alc wrote:

1. In regards to pmap_enter(), we should aim to kill two birds with one stone. Recall the copy-on-write mapping bug that Kostik worked around in vm_fault(). I say worked around because the root cause is here in pmap_enter(). When the physical page mapped at va is changing, pmap_enter() should destroy the old mapping before creating the new one. Once pmap_enter() is restructured in this way, you can simply recycle the old mapping's PV entry.

Can you elaborate more, please ? What do you mean by destroying the old mapping ? In particular, do you mean installing the pte with clear PG_V into the changing PTE ?

Yes, I mean destroying the PTE, including TLB shootdown. In effect, briefly the PTE will be 0. Then, installing the new PTE is just a pte_store(). All of the stuff that we currently perform under "if ((origpte & PG_V) != 0) {" will already have been performed when we destroyed the PTE.

cd to the VCS topdir before invoking git diff

Hrm, this only works if git diff is run at the top level dir; needs further investigation.

In D15560#337979, @markj wrote:

Apologies for the delay. Would anyone with a Ryzen or TR be able to test a microcode update with the updated patch applied?

In D15910#337632, @kib wrote:

In D15910#337582, @alc wrote:

1. In regards to pmap_enter(), we should aim to kill two birds with one stone. Recall the copy-on-write mapping bug that Kostik worked around in vm_fault(). I say worked around because the root cause is here in pmap_enter(). When the physical page mapped at va is changing, pmap_enter() should destroy the old mapping before creating the new one. Once pmap_enter() is restructured in this way, you can simply recycle the old mapping's PV entry.

Can you elaborate more, please ? What do you mean by destroying the old mapping ? In particular, do you mean installing the pte with clear PG_V into the changing PTE ?

Add test for successful invocation of setlogin(2)

Do these complete the IPC set?

Had to bring localbase:ldflags back, something related with the i3 module needs some patches. I just fail to understand how it was building perfectly fine a few days ago.

In D15907#337950, @tobik wrote:

In D15907#337807, @mat wrote:

Mmmm, what commands did you run that generated a bad distinfo file?

In my case it was submitted with a bad format, so I'm not sure. Some contributors refuse or don't know how to use make makesum for some reason and write their own tooling. Usually this is easy to spot when TIMESTAMP is missing in distinfo, but this variant was new.