| Message ID | 20220206192839.75711-1-julien@xen.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | xen/arm: Allow dom0 to use the EFI framebuffer | expand |
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
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(-)