I removed SOCDEV_VA because it's too difficult to know where the kernel will be loaded so we don't know a good virtual address at compile time.

Does it apply after 6270ee0b6726?

I've tested the normal boot and with SOCDEV_PA set (but not used). I haven't tested any of the LINUX_BOOT_ABI paths.

This is untested, I just moved the code to a new function as a proof of concept.

How about something like D27621?

You might want to change the commit message to say you're removing the DMAP check from pmap_kextract as it wass only correct when the DMAP region is contiguous which is no longer true.

Yes, I think the fix for D27528 is to remove the DMAP check from pmap_kextract. You can then use it here in mem.c to see if the mapping is valid & fall through to uiomove_fromphys if not.

We already have a PHYS_IN_DMAP check. It could be extended to also check the return value of pmap_kextract(PHYS_TO_DMAP(v)).

All mappings that point to the same physical address need to be the same memory type. Because of this we will demote memory in the DMAP if needed to make this possible, e.g. when marking a page as uncached the DMAP page pointing at the same memory will also be marked as uncached, including a demotion if it's currently part of a larger block.

pmap_kextract, although we will need to remove the DMAP check as it was added before we had a sparse DMAP region.

I would prefer we don't map memory marked as noalloc in the DMAP. If we need to read it in /dev/mem then mem.c should handle unmapped memory within the DMAP region.

What will happen if we try to access a DMAP page during the break-before-make sequence while it is being demoted?

• Use the correct ID in cpu_init_fdt
• Copy a comment explaining why we don't increment the CPU ID to teh FDT code
• Fix a typo in said comment

Simplify by only iterating once with CPU 0 being reserved

I think we can just check for the existence of the ACPI tables, i.e. by checking if AcpiOsGetRootPointer returns a non-zero value.

Based on my reading of the ACPI tables I expect this will work on eMAG and the Huawei Taishan, however I don't have access to either to test.

Committed in rS367754

I'm going to commit this as it allows the device to start attaching. There is a second issue where the HW you have described the interrupt controller in a different way. I have a change in progress that should fix this second issue.

Load the free list in pmap_release

The GIC-500 TRM has the following note against GICD_ISENABLER0: "Writes to bits corresponding to the SGIs are ignored."

We already enable the SGIs on the non-boot CPUs in arm_gic_init_secondary and PIC_ENABLE_INTR will only be called when mp_ncpus != 1 so will be in a multicore system.

Would it make sense to move these to subr_bus_dma.c in the non-IOMMU case?

I'd like to use some of the iommu functions in device code, e.g. non-pci devices on arm64 can be behind an iommu. I'd prefer to not have to teach these devices about PCI just to configure the iommu.

Remove debugging

Remove debugging

• Use might_bounce/must_bounce in bounce_bus_dma_id_mapped
• Always create the bounce zone in bounce_bus_dmamap_create

Store the allocated alignment separate from the requested alignment

Remove DMAMAP_COULD_BOUNCE as it's unneeded

Add more calls to might_bounce/must_bounce