Re: ACPI/UEFI support for Xen/ARM status?

[Elliott Mitchell <ehem+xen@xxxxxxx>]

On Tue, Nov 16, 2021 at 08:18:26AM +0100, Jan Beulich wrote:
> On 15.11.2021 20:09, Julien Grall wrote:
> > 
> > However, for Elliott's case, I am not sure this is going to sufficient. 
> > The Raspberry PI has some devices that can only DMA into the first 1GB 
> > of the RAM (the GPU seems to be one). So we need to make sure Xen is 
> > allocating enough memory for Dom0 below that limit.
> 
> Urgh.
> 
> > Do you have similar problem on x86? If so, how do you deal with it?
> 
> No, we don't have any such restrictions that I would be aware of.

x86 had *many* devices which were limited to the low 4GB, go back futher
and there might have been other devices with lower limits.  The oddity
here being devices with a 1GB limit on a board with aarch64 processors.

This simply needs effort to keep Xen out of low addresses (which has the
additional advantage of protection from DMA) and allocate more low
addresses to Domain 0.  Could also see value in preferring to load
Domain 0's kernel at higher addresses.

Last year I had been left with the impression full ACPI table support
was really a WIP and I should leave things alone.  Letting others push
the ACPI support forward, while I put effort into the piece which nobody
was putting significant effort into.

Yet again what has been typed leaves the impression full ACPI table
support on ARM is highly desired and likely very high value.  Just at the
incremental effort for per-device device-trees isn't that high, while the
full table support will initially be expensive.  Yet once that is done I
suspect there will be far lower per-device effort.

We seem to need a corporate entity to aggregate all the funding to get
ACPI into proper shape.  Then we could enjoy many more devices with much
lower per-device effort.


-- 
(\___(\___(\______          --=> 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