Re: Xen on RP4

[Elliott Mitchell <ehem+xen@xxxxxxx>]

On Thu, Oct 29, 2020 at 12:57:58PM -0700, Stefano Stabellini wrote:
> On Thu, 29 Oct 2020, J??rgen Gro?? wrote:
> > What about having a small domain parsing the ACPI booting first and use
> > that information for booting dom0?
> > 
> > That dom would be part of the Xen build and the hypervisor wouldn't need
> > to gain all the ACPI AML logic.
> 
> That could work, but in practice we don't have such a domain today --
> the infrastructure is missing. I wonder whether the bootloader (uboot or
> grub) would know about the platform and might be able to pass that
> information to Xen somehow.

How long would such likely take to implement?  This reads like a
complicated project, and likely to take a while...


Then would be the issue of efifb.



I've been pondering allocate_memory_11() and coming up with a rather
complicated potential problem.  ACPI appears to potentially allow for
non-power of 2 DMA ranges; I'm unaware of any such device, but the code
should allow for such.

I can imagine a device which has multiple DMA ranges.  The ranges could
be fully contained within each other, the ranges could partially overlap,
or the ranges could be disjoint.

Someone might wish to allocate all DMA-capable memory to domain 0,
someone might wish to allocate less.  Additionally if all DMA-capable
memory is allocated to domain 0, some non-DMA-capable memory could be
desired.

Ideally Xen would move to non-DMA memory.  This would protect Xen against
a malicious domain 0 and allow allocating more DMA-capable memory to
domain 0.

This interacts with ballooning.  If memory is removed from domain 0,
non-DMA memory should be removed first.  If domain 0 is allocated more
memory, DMA memory should be added first (if any isn't allocated to
domain 0).

Then again I may be severely overthinking things.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@xxxxxxx  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445