[vm] mismatched cache attribute aliases of the same physical memory

[travisg]

Raised independently by PR #265 (vishals4gh) and PR #351 (chintanpandya89), both being closed in favour of this issue.

Most LK platforms map all of DRAM cached at boot. Nothing then stops vmm_alloc_physical() from creating a second mapping of the same physical page with different memory attributes — typically uncached or Device, for a DMA buffer. On ARM that is an architecturally mismatched alias, and the two views are not guaranteed to be coherent. It is not theoretical: PR #351 reported stability problems from exactly this on gem5, and this tree hit the same class of bug recently under KVM, where Device-mapped shared buffers break on pre-v8.4 ARM hosts. That is what 04c490a3 (virtqueue mapped cached), e44365d6 (9p PDU buffers) and 941b94ae (e1000 descriptor rings mapped cached plus the missing barriers) were fixing, and 78199747 records where AHCI still makes the old assumption.

The two PRs attacked it from opposite ends:

• Memory mapping issues in ARM64 #351 added a check in arm64's arch_mmu_map() that walks mmu_initial_mappings and refuses a mapping whose cacheability contradicts the boot mapping of that physical range. Cheap, arm64-only, and detection rather than prevention — it rejects the alias at creation instead of making a correct one possible.
• WIP: lk: Address memory aliasing issue #265 restructured allocation instead: arenas that are deliberately not mapped into the kernel aspace at boot, with malloc drawing from the pre-mapped arenas and vmm_alloc* drawing from the unmapped ones, plus a cache clean on vmm_free_region so a page can be safely re-mapped with different attributes. This actually prevents the alias, at the cost of paddr_to_kvaddr() no longer working for vmm_alloc* memory. It was posted explicitly as an RFC asking whether the problem was worth solving and whether the approach was acceptable; it never got an answer, which is why it stalled.

The question to settle first is which of those LK wants — reject mismatched aliases, or make unmapped-by-default arenas the normal way to get DMA memory. #265's approach is the more complete fix and the more invasive one; #351's is a guard rail that could land on its own. Note #351's check as written only consults mmu_initial_mappings, so it would not catch two vmm_alloc* mappings that disagree with each other.