[PATCH RFC 0/3] xen/arm: Allow dom0 to use the EFI framebuffer

Julien Grall posted 3 patches 2 years, 2 months ago
Test gitlab-ci failed
Patches applied successfully (tree, apply log)
git fetch https://gitlab.com/xen-project/patchew/xen tags/patchew/20220206192839.75711-1-julien@xen.org
xen/arch/arm/efi/efi-boot.h       |  6 --
xen/arch/arm/platform_hypercall.c | 15 +++++
xen/arch/arm/setup.c              |  4 ++
xen/arch/x86/efi/efi-boot.h       | 72 -----------------------
xen/common/efi/boot.c             | 96 +++++++++++++++++++++++++++----
xen/include/public/platform.h     |  2 +
xen/include/xen/vga.h             |  2 +-
7 files changed, 106 insertions(+), 91 deletions(-)
[PATCH RFC 0/3] xen/arm: Allow dom0 to use the EFI framebuffer
Posted by Julien Grall 2 years, 2 months ago
From: Julien Grall <jgrall@amazon.com>

Hi all,

This is a follow-up of the discussion [1].

When booting using EFI on Raspberry Pi 4, the graphical output will
be using the EFI framebuffer.

On baremetal, the information for the graphic output is retrieved
using the boot services. However, under Xen, dom0 has no access
to the EFI boot services. So we need to a different way to inform Dom0.

For x86 PV dom0, this is using the start_info. On Arm we have no such
thing, so this patch will introduce a new hypercall. This will
require a change in Linux [2] (Based on the 5.17-rc2) to issue the
hypercall and fill-up screen info.

I will properly send the Linux patch once we agree on the interface
between Xen and dom0.

With this series + Linux, I am able to use XFCE in dom0 on the
RPi 4 when booting using UEFI + ACPI.

Looking through the dmesg, there are still a few TODOs to handle:
    - Linux is not able to use the BGRT (Invalid address). This is
      because the driver checks the Image address is part of the UEFI
      Boot Services Area. Such area is not exposed to dom0 (yet).
      By-passing the check doesn't much help because all the EFI Boot
      Services area are given to the normal allocator. So we would
      need to reserve them.
    - The Wifi driver is crashing because it is dereferencing a NULL
      pointer (only seem to happen on Xen).
    - There are error messages of drivers trying to access the EFI
      runtime services (e.g. to fetch firmware for a device) but fails.
      This is expected as Xen doesn't yet expose the EFI runtimes
      services yet.

/!\ This has only been tested on Arm. I will sanity test x86 for the
next version.

Cheers,

[1] https://lore.kernel.org/xen-devel/YY3tSAFTCR4r2FaI@mattapan.m5p.com/
[2] https://pastebin.com/ztUm9Bf3

Julien Grall (3):
  xen/efi: Always query the console information and get GOP
  xen/arm: efi: Introduce and fill the vga_console_info
  xen: Introduce a platform sub-op to retrieve the VGA information

 xen/arch/arm/efi/efi-boot.h       |  6 --
 xen/arch/arm/platform_hypercall.c | 15 +++++
 xen/arch/arm/setup.c              |  4 ++
 xen/arch/x86/efi/efi-boot.h       | 72 -----------------------
 xen/common/efi/boot.c             | 96 +++++++++++++++++++++++++++----
 xen/include/public/platform.h     |  2 +
 xen/include/xen/vga.h             |  2 +-
 7 files changed, 106 insertions(+), 91 deletions(-)

-- 
2.32.0


Re: [PATCH RFC 0/3] xen/arm: Allow dom0 to use the EFI framebuffer
Posted by Jan Beulich 2 years, 2 months ago
On 06.02.2022 20:28, Julien Grall wrote:
> Looking through the dmesg, there are still a few TODOs to handle:
>     - Linux is not able to use the BGRT (Invalid address). This is
>       because the driver checks the Image address is part of the UEFI
>       Boot Services Area. Such area is not exposed to dom0 (yet).
>       By-passing the check doesn't much help because all the EFI Boot
>       Services area are given to the normal allocator. So we would
>       need to reserve them.

Respective checking is supposed to by done by (only) Xen in our case.
I thought we do so, hence if there's a bug in there I think it wants
fixing on the Xen side. The Dom0 kernel should never be exposed the
Boot Services areas, and hence it should really trust Xen having done
whatever needs doing.

Jan