WIP: lk: Address memory aliasing issue

[vishals4gh]

By default most of the platforms map all the DRAM
at boot time causing scenarios where same physical
address initially mapped with cacheable attributes
maybe allowed to get mapped with non-cacheable
attributes via different VM range. This is discouraged
in architectures like ARM and gets tedious to ensure
the coherent view of DRAM with other masters.

This change ensures following for qemu-arm platform:

1. Add support of Arenas which might not be mapped
   in kernel space initially after platform is setup.
2. All the malloc calls use the pages
   from the arenas which are already mapped to kernel
   space.
3. vmm_alloc* APIs use the arenas which are not already
   mapped to any virtual address range.
4. vmm_free_region for memory allocated via vmm_alloc*
   APIS using cacheable memory mappings will clean caches
   for reuse by the next vmm_alloc* API call that can map memory
   with different attributes.
5. Memory for unmapped arena is initially allowed to be mapped
   and then unmapped later during platform initialization.

This avoids remapping of the same physical memory to
different virtual address ranges with different memory
attributes. This effectively ensures that at any given
memory from the vmm_arena can be owned by singal entity
with a particular memory attributes.

Caveats:

1. paddr_to_kvaddr API will not work for Physical addresses
   allocated using vmm_alloc* APIs

ToDo:

1. Address the shortfalls of the current implementation
2. Update other platforms to allow unmapped ram arenas if
   this implementation is ok to pursue.

Signed-off-by: vannapurve vannapurve@google.com

[vishals4gh]

Rather than a merge request, this is more of review request to seek more feedback about whether:

1. This issue is something that should be addressed
2. The approach I tried to pursue is fine to proceed with
   This patch is still WIP.

Thanks,
Vishal

[travisg]

Closing this in favour of #529, which captures the problem and both proposed approaches so the design question stays open even though the branch doesn't.

You posted this as an RFC asking two things — whether the issue was worth addressing, and whether the approach was acceptable — and never got an answer. The answer to the first is yes, unambiguously: this tree hit the same class of bug recently under KVM, where Device-mapped shared buffers break on pre-v8.4 ARM hosts. 04c490a3, e44365d6 and 941b94ae moved the virtio virtqueue, the 9p PDU buffers and the e1000 descriptor rings to cached mappings with explicit barriers because of it, and 78199747 records where AHCI still makes the old assumption. Your 2020 RFC was describing that failure mode before it bit us.

The second question is still genuinely open, which is why it's an issue rather than a merge. Unmapped-by-default arenas are the more complete fix and the more invasive one; the paddr_to_kvaddr() caveat you flagged is the part that needs a decision. Five years of VM churn means the branch itself won't rebase, but the reasoning is preserved in #529.

Sorry you had to ask twice and got nothing back.