ACPI/UEFI support for Xen/ARM status?

ACPI/UEFI support for Xen/ARM status?

[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 noticed Linux made full ACPI/UEFI support mandatory for ARM64 before
3.19, so Xen's seems far behind the curve here.

While incidents of garbled ACPI tables are notorious, those are notable
due to being rare.  Whereas I've had terrible luck with device-trees.
The instances of any given OS *not* breaking device-trees with even
patch-level changes are rare.


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

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

[Henry Wang]

Hi Elliott,

> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of
> Elliott Mitchell
> Sent: Friday, November 12, 2021 12:28 PM
> To: Stefano Stabellini <sstabellini@kernel.org>; Julien Grall <julien@xen.org>
> Cc: xen-devel@lists.xenproject.org
> Subject: ACPI/UEFI support for Xen/ARM status?
> 
> 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
(XEN) Booting using ACPI
...
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd0f0]
[    0.000000] Linux version 5.14.0-rc1+ (henry@xxxx) (gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #19 SMP Wed Oct 13 05:18:13 EDT 2021
[    0.000000] Xen XEN_VERSION.XEN_SUBVERSION support found
[    0.000000] efi: EFI v2.50 by Xen
[    0.000000] efi: ACPI 2.0=0xf56f02a0
[    0.000000] ACPI: Early table checksum verification disabled
[    0.000000] ACPI: RSDP 0x00000000F56F02A0 000024 (v02 LINARO)
[    0.000000] ACPI: XSDT 0x00000000F56F0238 000064 (v01 LINARO RTSMVEV8 00000002      01000013)
[    0.000000] ACPI: FACP 0x00000000F56F0000 000114 (v06 LINARO RTSMVEV8 00000002 LNRO 00000002)
[    0.000000] ACPI: DSDT 0x00000000F5E3ED98 0002AB (v02 LINARO RTSMVEV8 00000004 INTL 20200925)
[    0.000000] ACPI: GTDT 0x00000000F5E3FC18 0000E0 (v02 LINARO RTSMVEV8 00000002 LNRO 00000002)
[    0.000000] ACPI: APIC 0x00000000F56F0118 0000F4 (v04 LINARO RTSMVEV8 00000002 LNRO 00000002)
[    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. :)

> 
> I noticed Linux made full ACPI/UEFI support mandatory for ARM64 before
> 3.19, so Xen's seems far behind the curve here.
> 
> While incidents of garbled ACPI tables are notorious, those are notable
> due to being rare.  Whereas I've had terrible luck with device-trees.
> The instances of any given OS *not* breaking device-trees with even
> patch-level changes are rare.
> 
> 
> --
> (\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
>  \BS (    |         ehem+sigmsg@m5p.com  PGP 87145445         |    )   /
>   \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
> 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0
> 8714\_|_/___/5445
> 
> 

Kind regards,

Henry

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

[Elliott Mitchell]

On Fri, Nov 12, 2021 at 05:54:08AM +0000, Henry Wang wrote:
> 
> > -----Original Message-----
> > From: Xen-devel <xen-devel-bounces@lists.xenproject.org> 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.

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.


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

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

[Julien Grall]

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@lists.xenproject.org> 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.

> 
> 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?

Cheers,

-- 
Julien Grall

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

[Elliott Mitchell]

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@lists.xenproject.org> 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.


> > 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).

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?

(Raspberry PI 4B with the Tianocore/EDK2 image)


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

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

[Julien Grall]

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@lists.xenproject.org> 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

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

[Elliott Mitchell]

On Fri, Nov 12, 2021 at 05:38:02PM +0000, Julien Grall wrote:
> 
> On 12/11/2021 16:52, Elliott Mitchell wrote:
> > On Fri, Nov 12, 2021 at 04:02:36PM +0000, 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?
> >>
> >> 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?

https://lists.xenproject.org/archives/html/xen-devel/2020-10/
https://lists.xenproject.org/archives/html/xen-devel/2020-11/

My thread was "Xen on RP4", pretty sure there have been others.  I see
several approaches suggested, but none overtly agreed on.  Seems like the
end sort of amounts to "We really should have ACPI/UEFI support", but no
specific plans.


> > 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.

https://lists.xenproject.org/archives/html/xen-devel/2020-10/msg01841.html

That is more or less a statement of handling of DSDT is the Right(tm)
solution for Domain 0 to have framebuffer on such a platform.  Though
there are plenty of short-term hacks for the issue.


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

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

[Julien Grall]

Hi Elliott,

On Fri, 12 Nov 2021 at 21:15, Elliott Mitchell <ehem+xen@m5p.com> wrote:
> > > 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.
>
> https://lists.xenproject.org/archives/html/xen-devel/2020-10/msg01841.html
>
> That is more or less a statement of handling of DSDT is the Right(tm)
> solution for Domain 0 to have framebuffer on such a platform.

Reading through the thread, I agree this is the correct theoretical thing to do.
However, as already pointed out back then, the effort seems quite big for the
benefit of a single board (AFAIK none of the other SoC we support
requires this).

My preference is to introduce a per-platform quirk (I believe Stefano was happy
with this). The advantage is we could get ACPI support for your board hopefully
merged quicker.

I would be happy to review any patches you send.

Cheers,

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

[Elliott Mitchell]

On Fri, Nov 12, 2021 at 10:08:54PM +0000, Julien Grall wrote:
> 
> On Fri, 12 Nov 2021 at 21:15, Elliott Mitchell <ehem+xen@m5p.com> wrote:
> > > > 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.
> >
> > https://lists.xenproject.org/archives/html/xen-devel/2020-10/msg01841.html
> >
> > That is more or less a statement of handling of DSDT is the Right(tm)
> > solution for Domain 0 to have framebuffer on such a platform.
> 
> Reading through the thread, I agree this is the correct theoretical thing to do.
> However, as already pointed out back then, the effort seems quite big for the
> benefit of a single board (AFAIK none of the other SoC we support
> requires this).

Crucial word I would add to the end of the parenthsized sentence; "yet".
Seems entirely plausible other boards could end up needing this for one
reason or another.  Alternatively this could remove the need for many
platform-specific hacks or could simplify support for many boards all at
once.


> My preference is to introduce a per-platform quirk (I believe Stefano was happy
> with this). The advantage is we could get ACPI support for your board hopefully
> merged quicker.

This could be workable as a temporary workaround.  Longer term I suspect
it might well be rather better to *fully* tackle the issue *now*.
Otherwise this seems likely to turn into a database of board-specific
hacks for hundreds or thousands of devices.

I had left the discussion alone towards the end since I was unsure of
what exactly to target (or look at) for this goal.  I was also thinking
long-term planning pretty well required full support, the question was
merely "When?"


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

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

[Julien Grall]

On Fri, 12 Nov 2021 at 22:32, Elliott Mitchell <ehem+xen@m5p.com> wrote:
> > My preference is to introduce a per-platform quirk (I believe Stefano was happy
> > with this). The advantage is we could get ACPI support for your board hopefully
> > merged quicker.
>
> This could be workable as a temporary workaround.  Longer term I suspect
> it might well be rather better to *fully* tackle the issue *now*.
> Otherwise this seems likely to turn into a database of board-specific
> hacks for hundreds or thousands of devices.

As usual, you have to find a balance between cost vs benefits.

If you look at the Device-Tree side, we don' t have many platforms
requiring quirks.
In particular, the DMA is so far strictly limited to a single platform (RPI).
So I would be surprised if we suddenly require tons of quirks when using
ACPI.

Therefore I am unconvinced that such a big effort is necessary. That being said,
if you have plenty of time to invest to implement a DSDT parser in a
stub domain,
then I would be happy to review the patches.

Cheers,

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

[Elliott Mitchell]

On Fri, Nov 12, 2021 at 11:00:54PM +0000, Julien Grall wrote:
> On Fri, 12 Nov 2021 at 22:32, Elliott Mitchell <ehem+xen@m5p.com> wrote:
> > > My preference is to introduce a per-platform quirk (I believe Stefano was happy
> > > with this). The advantage is we could get ACPI support for your board hopefully
> > > merged quicker.
> >
> > This could be workable as a temporary workaround.  Longer term I suspect
> > it might well be rather better to *fully* tackle the issue *now*.
> > Otherwise this seems likely to turn into a database of board-specific
> > hacks for hundreds or thousands of devices.
> 
> As usual, you have to find a balance between cost vs benefits.
> 
> If you look at the Device-Tree side, we don' t have many platforms
> requiring quirks.
> In particular, the DMA is so far strictly limited to a single platform (RPI).
> So I would be surprised if we suddenly require tons of quirks when using
> ACPI.

Presently the DMA quirk would be the only consumer, but there will likely
be other consumers later.  Might there be few device-tree quirks due to a
short list of platforms?  Might full ACPI support vastly increase
Xen/ARM's target audience?  (partially ACPI so complex to support so many
varied devices)

I do concede a device-quirk is reasonable for the short-term.  Presently
I don't know where to look for better matching targets, so I'm trapped in
a cave with no light.


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

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

[Bertrand Marquis]

Hi Elliott,

> On 13 Nov 2021, at 01:03, Elliott Mitchell <ehem+xen@m5p.com> wrote:
> 
> On Fri, Nov 12, 2021 at 11:00:54PM +0000, Julien Grall wrote:
>> On Fri, 12 Nov 2021 at 22:32, Elliott Mitchell <ehem+xen@m5p.com> wrote:
>>>> My preference is to introduce a per-platform quirk (I believe Stefano was happy
>>>> with this). The advantage is we could get ACPI support for your board hopefully
>>>> merged quicker.
>>> 
>>> This could be workable as a temporary workaround.  Longer term I suspect
>>> it might well be rather better to *fully* tackle the issue *now*.
>>> Otherwise this seems likely to turn into a database of board-specific
>>> hacks for hundreds or thousands of devices.
>> 
>> As usual, you have to find a balance between cost vs benefits.
>> 
>> If you look at the Device-Tree side, we don' t have many platforms
>> requiring quirks.
>> In particular, the DMA is so far strictly limited to a single platform (RPI).
>> So I would be surprised if we suddenly require tons of quirks when using
>> ACPI.
> 
> Presently the DMA quirk would be the only consumer, but there will likely
> be other consumers later.  Might there be few device-tree quirks due to a
> short list of platforms?  Might full ACPI support vastly increase
> Xen/ARM's target audience?  (partially ACPI so complex to support so many
> varied devices)

We have been looking at the possibility to have ACPI support in Xen.
The main problem with that is the cost in lines of code in Xen which would be high
and as a consequence the maintenance cost would be high.
So if anything is done it must stay properly limited using ifdefs to make sure people
needing a “small” xen can still have one.

Now I am on the same side as Julien, I would be very happy to help reviewing if you
decide to do the work :-)

> 
> I do concede a device-quirk is reasonable for the short-term.  Presently
> I don't know where to look for better matching targets, so I'm trapped in
> a cave with no light.

What is your need exactly ? A target with frame buffer support ?

Regards
Bertrand

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

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

[Elliott Mitchell]

On Mon, Nov 15, 2021 at 10:06:20AM +0000, Bertrand Marquis wrote:
> 
> > On 13 Nov 2021, at 01:03, Elliott Mitchell <ehem+xen@m5p.com> wrote:
> > 
> > On Fri, Nov 12, 2021 at 11:00:54PM +0000, Julien Grall wrote:
> >> On Fri, 12 Nov 2021 at 22:32, Elliott Mitchell <ehem+xen@m5p.com> wrote:
> >>>> My preference is to introduce a per-platform quirk (I believe Stefano was happy
> >>>> with this). The advantage is we could get ACPI support for your board hopefully
> >>>> merged quicker.
> >>> 
> >>> This could be workable as a temporary workaround.  Longer term I suspect
> >>> it might well be rather better to *fully* tackle the issue *now*.
> >>> Otherwise this seems likely to turn into a database of board-specific
> >>> hacks for hundreds or thousands of devices.
> >> 
> >> As usual, you have to find a balance between cost vs benefits.
> >> 
> >> If you look at the Device-Tree side, we don' t have many platforms
> >> requiring quirks.
> >> In particular, the DMA is so far strictly limited to a single platform (RPI).
> >> So I would be surprised if we suddenly require tons of quirks when using
> >> ACPI.
> > 
> > Presently the DMA quirk would be the only consumer, but there will likely
> > be other consumers later.  Might there be few device-tree quirks due to a
> > short list of platforms?  Might full ACPI support vastly increase
> > Xen/ARM's target audience?  (partially ACPI so complex to support so many
> > varied devices)
> 
> We have been looking at the possibility to have ACPI support in Xen.
> The main problem with that is the cost in lines of code in Xen which would be high
> and as a consequence the maintenance cost would be high.
> So if anything is done it must stay properly limited using ifdefs to make sure people
> needing a ???small??? xen can still have one.
> 
> Now I am on the same side as Julien, I would be very happy to help reviewing if you
> decide to do the work :-)

I'm getting the impression everyone knows Xen/ARM urgently needs full
ACPI/UEFI support, just everyone has figured out adequate short-term
workarounds.  As such everyone keeps making small investments into
keeping their short-term workarounds in place, hoping someone else will
fall on the ACPI/UEFI grenade and save everyone.

This sounds suspiciously like the classic Tragedy of the Commons
situation.


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

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

[Jan Beulich]

On 12.11.2021 17:02, 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@lists.xenproject.org> 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.
> 
>>
>> 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).

Jan

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

[Julien Grall]

Hi Jan,

On 15/11/2021 10:13, Jan Beulich wrote:
> On 12.11.2021 17:02, 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@lists.xenproject.org> 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.
>>
>>>
>>> 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?

Cheers,

-- 
Julien Grall

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

[Jan Beulich]

On 15.11.2021 20:09, Julien Grall wrote:
> Hi Jan,
> 
> On 15/11/2021 10:13, Jan Beulich wrote:
>> On 12.11.2021 17:02, 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@lists.xenproject.org> 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.
>>>
>>>>
>>>> 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.

Well, the frame buffer info doesn't really get communicated via a
hypercall, but rather via start_info. Albeit for PVH my proposal to
reuse that wasn't accepted, and I'm still waiting for an alternative
proposal by either Roger or Andrew. IOW I don't know yet how this
will be done on PVH.

> 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.

Jan

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

[Elliott Mitchell]

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@m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

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

[Elliott Mitchell]

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@m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445