In D20348#441376, @jhb wrote:

I think a better approach if we want to honor the EFI map on both x86 and arm is to check the memory map when creating the direct map itself so that we set the right attributes on the entire range (e.g. the entire MMIO range at once) allowing use of large pages instead of breaking them down into small pages when a device first requests a resource and the only re-promoting if the entire MMIO range is claimed by devices. I would still like to have pmap_mapbios never set an explicit attr but just use whatever is configured as well.

In D20448#441421, @cem wrote:

In D20448#441414, @rgrimes wrote:

I would even be fine with "If the function has no local variables",

I would be fine with that too, but I think that might be more contentious than this weaker change. If the consensus favors permitting leaving out a blank line entirely, I'm happy to make that change.

Can someone explain why we have this special case at all?

It dates back to phk's initial adaption of BSD 4.4-Lite2 src/admin/style/style in r12823. I did not dig back into the CSRG repo.

So you can commit with both mentor' approvals after testing.

Unwrap one more CTR format string.

Handle feedback.

Fix language in the comment.

Handle Alan' comments. Adjust the output of the diagnostic version of the checker even more.

In D20361#440984, @markj wrote:

In D20361#440566, @kib wrote:

So I wonder is it possible that your patched code would see non-traced process which is not yet safe to reparent. Or rather, I do not see anything that prevents this situation.

What exactly makes it unsafe? The procdesc close may race with a PT_DETACH, but PT_DETACH should not modify the process tree when p_oppid and p_ptr refer to the same process.

May be Doug with his experience with efficient data structures can suggest.

In D20380#440728, @alc wrote:

Everything here looks good to me.

In D20412#440673, @dougm wrote:

No testing on an actual arm machine has been performed.

__clzdi2() and other functions are indeed libgcc symbols implementing the builtins, so at least gcc cannot properly inline the operation.

In D20411#440658, @tijl wrote:

In D20411#440580, @mjg wrote:

I think arbitrary mkdir/rmdir is a can of worms, perfectly avoidable for the stated purpose.

Arbitrary symlinks are already supported. Why would mkdir be any different?

So why not do this for all architectures ? Is the problem that old gcc on ppc/sparc64/mips does not support __builtins required ?

In D20266#440649, @pho wrote:

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

In D20380#440642, @alc wrote:

In D20380#440609, @kib wrote:

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

Are you asking about this snippet?

if (*firstaddr < round_2mpage(KERNend))
        *firstaddr = round_2mpage(KERNend);

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.

How did you tested this ? I am curious if you tried massively-parallel mkdir/rmdir for the same name. Perhaps try to ask Peter Holm to test this.

P_TRACED is always set or cleared with proctree_lock exclusively locked, except at the process exit. After that, the process lock in exit1() is dropped and we acquire the proctree_lock. PRS_ZOMBIE is set much later on the process.

In D20390#440386, @tmunro wrote:

Implemented using a callback. Vnodes are still a special case though, because they have different locking requirements (don't want to do that stuff while holding the vmobject lock).

Better?

In fact, not. Look at the struct vm_object change. You are adding 16 bytes to it. vm_object_t is allocated for each once-opened vnode in the system, and e.g. on my low-end 16G router I have 1M vnodes. So the change, if applied, takes 16M away for almost never used memory.

PMAP_LARGEMAP_MAX_ADDRESS()
PG_PS_PDP_FRAME

Split large comment.
_fault() -> _abort().

LARGEMAP_RT_MAX_ADDRESS

Clip at KERNend.

Leave only refactoring of the demotion in this review.

Use symbolic name for 1G superpage frame mask.
Fix upper boundary check for large map.

I dislike the idea of allocating and keeping the string around as long as the object is alive. The string is almost never used, also it is always a duplicate of some other string that kernel already has allocated.

Remove KERNend.

wait(2) and pdfork(2)

Fix VM_MAXUSER_ADDRESS spelling.
Remember the last initialized page table page for insertion into the pmap radix.

Use PG_PROMOTED == 0 as a predicate for the pmap_pt_fill() call.

Other than the note about if()s, this looks fine.

In D20348#438886, @manu wrote:

In D20348#438878, @kib wrote:

I think this change should be somewhat improved by taking the most strong attr mode between pair of what is reported by UEFI memory map, and what is requested by a caller. For instance, if caller requests uncacheable, while UEFI reports write-combining, uncacheable should win.

I don't really understand, the caller of pmap_mapbios never request the mapping attr.

In D20327#438582, @jhb wrote:

In D20327#438513, @kib wrote:

In D20327#438503, @jhb wrote:

What happens on the laptops today is that it calls AcpiOsMapMemory for the MCFG region which uses pmap_mapbios and switches the mapping in the direct map from UC to WB and flushes the cache which then hangs. What patch is changing is making AcpiOsMapMemory just leave the direct map as-is and if the requested address has been marked UC prior to the use of AcpiOsMapMemory, it just leaves it alone instead of changing it to WB. I am actually inclined to do this for all the pmap_mapbios calls by having them always honor existing attributes which was my first question above. A further question at that point is if we'd rather just use the new name always since 'mapbios' is kind of a crummy name. Originally 'mapbios' meant 'map a table provided by the BIOS', but given that AML is free to map whatever random thing it chooses, 'mapphys' is probably a better name (and more generic for platforms that don't have BIOS).

Yes, I both do not like that pmap_mapbios() does not change the attributes for random requests ( I believe that GPU apertures are mapped by pmap_mapbios()), and that it could be done more explicit, snce we actually care about MFCG. Let me provide more or less accurate sketch of what I mean. The code duplication can be optimized out, I am more about the approach.

Hmm, I guess I'd just rather avoid hardcoding this just for MCFG. In theory there can be multiple MCFG address ranges for example. But what I'm really paranoid about is some future bit of AML code that uses SystemMemory to read a register in a BAR. I wouldn't want that to remap the BAR to be WB instead of UC either. I really feel like AcpiOsMapMemory() should not be forcing WB, just using that as the default if a new mapping needs to be created. In the case of GPU apertures, are you saying that pmap_mapbios is being used to force GPU apertures to use WB that were previously mapped using something else? I don't see that in the current calls to pmap_mapbios:

amd64/acpica/acpi_machdep.c:    rsdp = pmap_mapbios(rsdp_ptr, sizeof(ACPI_TABLE_RSDP));
arm64/acpica/acpi_machdep.c:    header = pmap_mapbios(pa, sizeof(ACPI_TABLE_HEADER));
arm64/acpica/acpi_machdep.c:    table = pmap_mapbios(pa, length);
arm64/acpica/acpi_machdep.c:    table = pmap_mapbios(address, sizeof(ACPI_TABLE_HEADER));
arm64/acpica/acpi_machdep.c:    rsdp = pmap_mapbios(rsdp_ptr, sizeof(ACPI_TABLE_RSDP));
compat/x86bios/x86bios.c:       x86bios_ivt = pmap_mapbios(X86BIOS_IVT_BASE, X86BIOS_IVT_SIZE);
dev/acpica/acpi_pxm.c:  cpus = (struct cpu_info *)pmap_mapbios(addr, size);
dev/acpica/Osd/OsdMemory.c:    return (pmap_mapbios((vm_offset_t)PhysicalAddress, Length));
dev/ipmi/ipmi_smbios.c: header = pmap_mapbios(addr, sizeof(struct smbios_eps));
dev/ipmi/ipmi_smbios.c: table = pmap_mapbios(addr, header->length);
dev/ipmi/ipmi_smbios.c: table = pmap_mapbios(header->structure_table_address,
dev/pci/vga_pci.c:              return (pmap_mapbios(VGA_PCI_BIOS_SHADOW_ADDR, *size));
i386/acpica/acpi_machdep.c:     va = pmap_mapbios(0xffff0, 16);
i386/acpica/acpi_machdep.c:     rsdp = pmap_mapbios(rsdp_ptr, sizeof(ACPI_TABLE_RSDP));
x86/acpica/madt.c:      madt = pmap_mapbios(madt_physaddr, madt_length);

Of those, combat/x86/x86bios.c is mapping the real-mode IDT, dev/pci/vga_pci.c is mapping the VGA BIOS ROM at 0xc0000, and the rest are all mapping BIOS tables (smbios, ACPI, etc.) except for OsdMemory.c which is mapping anything AML asks for. I don't see any of these mapping GPU apertures?

Can you do the same for amd64 ?

r341689 was already merged, so mentioning it in the commit message is not quite useful.