[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Mon, Nov 15, 2021 at 07:09:45PM +0000, Julien Grall wrote:
> On 15/11/2021 10:13, Jan Beulich wrote:
> > On 12.11.2021 17:02, Julien Grall wrote:
> >> On 12/11/2021 15:44, Elliott Mitchell wrote:
> >>>
> >>> Julien Grall and Stefano Stabellini had been proposing doing ACPI table
> >>> parsing in a stub domain, but I'm unaware of the status.  Not finding
> >>> much suggests it hasn't gone very far yet.
> >>
> >> This was a very early proposal in case we needed to parse the DSDT in
> >> Xen. This hasn't been needed so far, hence why this is not implemented
> >> and no-one worked on it.
> >>
> >> I am not very familiar how the framebuffer is detected in ACPI. Can you
> >> provide more details on what exactly you want to parse?
> > 
> > I don't think there's any ACPI support involved there. Instead UEFI data
> > needs propagating to Dom0, as that can't access EFI boot services itself.
> > At least this is all that's needed on the x86 side (and all the needed
> > code is there, just presumably not [fully] wired up on Arm).
> 
> Thanks for the feedback. At the moment, we don't enable EFI runtime 
> services nor propagate it to Dom0. So this needs to be wired up.
> 
> 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.
> 
> Do you have similar problem on x86? If so, how do you deal with it?

Is it just me or has anyone else commented you seem to have become
obsessed with DMA?  Otherwise are detail-oriented tendencies getting out
of control?

You keep bringing up DMA, but once the initial teething troubles (DMA
addresses versus memory addresses) were over there hadn't been any
issues attributed to DMA.  While bounce buffers are suboptimal, they are
good enough for most cases.

For DMA what most concerns me is the design of the allocate_memory_11().
The approach strongly favors *large* allocations.  Notably it requires a
chunk of 128MB or larger, if Domain 0 has been allocated at least 128MB.
If allocate_memory_11() finds a 128MB chunk it then prefers to enlarge
that chunk, rather than emphasizing allocating low addresses.

It has been a while since I last tried the Tianocore build, but there are
two crucial observations.  I don't recall the actual size, but Tianocore
was giving the framebuffer/GPU either 16MB or 64MB, and this was placed
below 512MB.  Combine this with the behavior of allocate_memory_11() and
guess what Xen/ARM/ACPI allocated to Domain 0.

I recall the lowest memory address being given to Domain 0 being above
the 512MB line.  I think it was at 768MB, but this is from my memory.
The rest of the memory allocated to Domain 0 was at higher addresses.

I would suggest allocate_memory_11()'s behavior needs to be adjusted
roughly as follows.  If a Domain 0 is allocated more than 256MB,
allocate_memory_11() should try for DMA-capable memory for at least half
of Domain 0's allocation (I'm unsure whether there should be 128MB of
non-DMA memory, versus only half).  I would emphasize lower addresses
over size for the DMA-capable memory.


I'm unsure how ACPI/UEFI/Tianocore were expressing the framebuffer
memory.  I've got the impression that memory allocation is marked
distinctly from the rest of main memory.

I don't know what was happening, but I suspect Xen had been leaving that
memory blank and never touching it (display never showed any output,
even pixel dust).  I'm suspecting Xen/ARM's ACPI implementation was
handling the specially marked memory by dropping it on the floor.
Instead of handing it to Domain 0 as a specialized region.


Could also be the complete lack of EFI runtime services was the problem.


Julien Grall might I inquire as to your general location/situation?  I
suspect giving you a Raspberry PI 4B could be *highly* valuable to the
Xen Project.  You would suddenly have a Xen-capable system with ACPI and
framebuffer.

A Raspberry PI 4B is cheap enough to need minimal expense justification.
I suspect you've got a spare TTL-serial on hand.  Only issue might be the
mini-HDMI.

I wouldn't dare send one without a SD Card, out of fear it might end up
being used with device-trees instead of Tianocore...


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





 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.