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

[Julien Grall <julien@xxxxxxx>]

Hi,

On 12/11/2021 16:52, Elliott Mitchell wrote:
> On Fri, Nov 12, 2021 at 04:02:36PM +0000, Julien Grall wrote:
> > Hi Elliott,
> >
> > On 12/11/2021 15:44, Elliott Mitchell wrote:
> > > On Fri, Nov 12, 2021 at 05:54:08AM +0000, Henry Wang wrote:
> > > > > -----Original Message-----
> > > > > From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of
> > > > > Elliott Mitchell
> > > > >
> > > > > I've been busy with another part of this project, so I've lost track of
> > > > > progress on ACPI/UEFI support on ARM.
> > > > >
> > > > > Last I'd read full support for ACPI/UEFI seemed a ways off.  Using a stub
> > > > > domain to constrain ACPI table parsing seemed the favored approach.  I
> > > > > was under the impression that would take some time.
> > > > >
> > > > > What is the status?  Do the Xen/ARM leads have any guesses for when full
> > > > > ACPI/UEFI support might reach completion?
> > > > I am doing some development based on the Xen UEFI/ACPI on AArch64 using
> > > > the Arm FVP_Base platform. Using edk2 and master branch of Xen with
> > > > `CONFIG_ACPI=y`, it seems everything can work properly.
> > > >
> > > > Here are some of my logs:
> > > > Shell> FS2:EFI\XEN\xen.efi
> > > > Xen 4.16-rc (c/s Fri Nov 12 02:34:01 2021 +0000 git:323b47ffd9-dirty) EFI loader
> > > > ...
> > > > (XEN) PFN compression on bits 20...22
> > > > (XEN) ACPI: RSDP F5E30018, 0024 (r2 LINARO)
> > > > (XEN) ACPI: XSDT F5E3FE98, 005C (r1 LINARO RTSMVEV8        2       1000013)
> > > > (XEN) ACPI: FACP F5E3FA98, 0114 (r6 LINARO RTSMVEV8        2 LNRO        2)
> > > > (XEN) ACPI: DSDT F5E3ED98, 02AB (r2 LINARO RTSMVEV8        4 INTL 20200925)
> > > > (XEN) ACPI: GTDT F5E3FC18, 00E0 (r2 LINARO RTSMVEV8        2 LNRO        2)
> > > > (XEN) ACPI: APIC F5E3E998, 02D4 (r4 LINARO RTSMVEV8        2 LNRO        2)
> > > > (XEN) ACPI: SPCR F5E3FF98, 0050 (r2 LINARO RTSMVEV8        2 LNRO        2)
> > > > (XEN) Domain heap initialised
> > > > ...
> > > > [    0.000000] ACPI: SPCR 0x00000000F5E3FF98 000050 (v02 LINARO RTSMVEV8 
> > > > 00000002 LNRO 00000002)
> > > > [    0.000000] ACPI: SPCR: console: pl011,mmio32,0x1c090000,115200
> > > > ...
> > > >
> > > > Hopefully this answers your question. :)
> > > Thanks for the attempt at answering, but the SPCR entry tells me there is
> > > a substantial portion of ACPI/UEFI functionality you're not testing.  I'm
> > > specifically looking for framebuffer console support and SPCR says you're
> > > using serial console.  While serial console is appropriate for true
> > > servers, for some use cases it is inadequate.
> > We don't have any support for framebuffer in Xen on Arm (even for
> > Device-Tree). I would be happy to consider any patches if you are plan
> > to post some.
> Xen on ARM doesn't need a framebuffer itself, but it can be valuable to
> have Domain 0 able to access a framebuffer.
Right, that's a completely different story (see below).

> > > 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?
> >
> > Alternatively, UEFI is meant to provide an API to access the
> > framebuffer. Would that be suitable for you?
> Last time I tried booting on UEFI, Domain 0 (Linux) was unable to access
> the framebuffer on this device.  Whereas the same kernel directly on top
> of UEFI/ACPI was fully able to access the framebuffer (and graphics
> chip).
Do you have any log or pointer to any previous discussion about the issue?

> I had been left with the impression the DSDT parsing was going to be
> needed for Domain 0 to access the framebuffer.  This was found
> unnecessary for framebuffer access for Domain 0?
I thought you were asking for using framebuffer in Xen. There is no need 
for Xen to parse the DSDT if the framebuffer is solely used by Dom0.
Your problem with the framebuffer is likely not related to the DSDT. But 
I can't really provide a lot of input until I see the logs.
Cheers,

--
Julien Grall