I ran tests on D20266.57868.diff for 24 hours without seeing any problems.

In D18593#440598, @jah wrote:

In D18593#440526, @jmallett wrote:

But it also looks like, on all MIPS configurations, we're reserving TLB entry 0 for KSTACK_TLB_ENTRY. But I don't see any evidence that we're using that TLB slot currently: there's no call to tlb_insert_wired() on that slot that I can find. It also seems like a single TLB entry might not be sufficient for that, depending on the combination of PAGE_SIZE and KSTACK_PAGES.
Can that TLB entry be repurposed, or are we still using it somewhere I've missed?

In D20380#440609, @kib wrote:

In D20380#440605, @alc wrote:

I _think_ that what you mean is that we should connect all preallocated page tables to directories, but only pre-promote to the rounded KERNend, and store in radix only page tables pages which were shadowed by the manual promotion.

Yes, except that the way that the loop is written, we don't need to round KERNend for correctness. I would only round it if you think that doing so makes it less likely that someone will misinterpret the code. Here are all of the changes that I would make.

I do not think that the check needs changing.
Also I see that indeed page table pages do not need non-zero initialization after we switched to PG_PROMOTED test.

I am not sure why do check that KERNend != round_2mpage() before rounding, IMO it simply less lines to not do that.

@rgrimes If you want to commandeer this review and put an updated diff, that would be great.

Rebase.

Wire the page during an optimized copy-on-write fault. This ensures
that a thread concurrently unwiring the page will not attempt to
free it while it is temporarily removed from its object. Since this
also prevents the page daemon from scanning the page, we no longer
need to dequeue the page. (See r331128 and r331131.)

alc' version of the patch, with one minor style fix.
Testing this properly almost certainly requires D20266.

In D20380#440605, @alc wrote:

I _think_ that what you mean is that we should connect all preallocated page tables to directories, but only pre-promote to the rounded KERNend, and store in radix only page tables pages which were shadowed by the manual promotion.

Yes, except that the way that the loop is written, we don't need to round KERNend for correctness. I would only round it if you think that doing so makes it less likely that someone will misinterpret the code. Here are all of the changes that I would make.

I do not think that the check needs changing.
Also I see that indeed page table pages do not need non-zero initialization after we switched to PG_PROMOTED test.

I _think_ that what you mean is that we should connect all preallocated page tables to directories, but only pre-promote to the rounded KERNend, and store in radix only page tables pages which were shadowed by the manual promotion.

Yes, except that the way that the loop is written, we don't need to round KERNend for correctness. I would only round it if you think that doing so makes it less likely that someone will misinterpret the code. Here are all of the changes that I would make.

Index: amd64/amd64/pmap.c
===================================================================
--- amd64/amd64/pmap.c  (revision 348267)
+++ amd64/amd64/pmap.c  (working copy)
@@ -1338,7 +1338,6 @@ static void
 create_pagetables(vm_paddr_t *firstaddr)
 {
        int i, j, ndm1g, nkpdpe, nkdmpde;
-       pt_entry_t *pt_p;
        pd_entry_t *pd_p;
        pdp_entry_t *pdp_p;
        pml4_entry_t *p4_p;
@@ -1399,20 +1398,21 @@ create_pagetables(vm_paddr_t *firstaddr)
        KPTphys = allocpages(firstaddr, nkpt);
        KPDphys = allocpages(firstaddr, nkpdpe);

In D20406#440587, @markj wrote:

Looks ok to me, but I don't understand the tradeoffs involved in sharing the pnpinfo format among multiple bus types. Is it theoretically possible for there to be a collision, e.g., where two different drivers, one for mmio and one for pci, match on the same string?

In D18593#440526, @jmallett wrote:

I don't have any exceptionally helpful comments; the code looks fine, but I haven't given it the review it deserves.

1. I don't think very much about 32-bit MIPS, unfortunately.
2. If you're interested in MALTA, why not use MALTA64? If there's an actual hardware platform you care about, it'd be useful to know which one that is.
3. The general approach of a reusable mapping for this kind of bounce buffering is a good one. Really, you could have a per-thread reusable mapping wired into the TLB for this use, and just update the wiring. That way the update path would be quicker, no TLBL/TLBS/TLBRefill. I never understood the sysmap_lmem code very well because (see point 1 above), but that's how I'd approach it.
4. I would encourage allocating pairs of virtual pages even if you end up wasting one or more, to avoid even possibly splitting the TLB entry for one of these with something else.
5. I agree we should get rid of 32-bit SMP on MIPS barring something really disruptive entering the marketplace. (This seems vanishingly unlikely, much as MIPS seems to be vanishing. People who would have accidentally used MIPS are all using ARM, and people who would have intentionally sought out MIPS are using RISC-V instead.)
6. It's almost 110% certain that the cache handling is not totally right. I don't think very much these days about how to make it right, and it's a subject that requires nontrivial thought given VIVT vs. VIPT. If you're deep into reading about this stuff and have all of it paged in, I'd encourage taking a swing at auditing all of mips/mips for places that caching could be made correct, and giving it a try. You're unlikely to make it worse :)

Thanks for doing this, this is stuff that needs to be happen and looks to be good work!

Rework comment wording describing the change.

Looks ok to me, but I don't understand the tradeoffs involved in sharing the pnpinfo format among multiple bus types. Is it theoretically possible for there to be a collision, e.g., where two different drivers, one for mmio and one for pci, match on the same string?

Using more idiomatic caph_limit_stderr(3) and caph_limit_stdout(3) in this instance instead of calls to caph_rights_limit(3).

I think arbitrary mkdir/rmdir is a can of worms, perfectly avoidable for the stated purpose. lindevfs module could be created to extend devfs mount points with whatever is necessary. Preferably this would be a completely separate fs, but that's probably too problematic. i.e. currently the module would make_dev("shm") on it's own. the func can create directories and if it insists on getting a device, a separate variant can be added.