| Message ID | 20220206192839.75711-2-julien@xen.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | xen/arm: Allow dom0 to use the EFI framebuffer | expand |
On 06.02.2022 20:28, Julien Grall wrote: > From: Julien Grall <jgrall@amazon.com> > > Currently, the EFI stub will only query the console information and > get the GOP when using the configuration file. > > However, GRUB is never providing the a configuration file. So the > EFI framebuffer will not be usable at least on Arm (support will > be added in a follow-up patch). > > Move out the code outside of the configuration file section. > > Take the opportunity to remove the variable 'size' which was > set but never used (interestingly GCC is only complaining if it is > initialization when declaring the variable). > > With this change, GCC 8.3 will complain of argc potentially been > used unitiatlized. I suspect this is because the argc will > be iniitalized and used in a different if code-blocks. Yet they > are using the same check. I'm inclined to suggest this wants to be a separate change, with its own justification. You're not touching any use of argc here, after all. > Signed-off-by: Julien Grall <jgrall@amazon.com> > > ---- > > It is not entirely clear to me why the GOP was only fetched when > the configuration file is used. > > I have tested this on RPI4 and it seems to work. Any chance this > was done to workaround an x86 platform? This was done so in the context of making the code work for Arm. See commit c38cf865ec82 ("EFI: ignore EFI commandline, skip console setup when booted from GRUB"), the description of which explicitly says "Don't do EFI console or video configuration when booted by GRUB. The EFI boot code does some console and video initialization to support native EFI boot from the EFI boot manager or EFI shell. This initlization should not be done when booted using GRUB." What you say now is effectively the opposite (and unlike back then x86 is now able to use this code path as well, so needs considering too). Cc-ing Daniel for possibly having a GrUB-side opinion. Jan > --- a/xen/common/efi/boot.c > +++ b/xen/common/efi/boot.c > @@ -1129,9 +1129,11 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) > static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID; > EFI_LOADED_IMAGE *loaded_image; > EFI_STATUS status; > - unsigned int i, argc; > + /* Initialize argc to stop GCC complaining */ > + unsigned int i, argc = 0; > CHAR16 **argv, *file_name, *cfg_file_name = NULL, *options = NULL; > - UINTN gop_mode = ~0; > + UINTN gop_mode = ~0, cols = 0, rows = 0; > + > EFI_SHIM_LOCK_PROTOCOL *shim_lock; > EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL; > union string section = { NULL }, name; > @@ -1219,18 +1221,16 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) > > efi_arch_relocate_image(0); > > + if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode, > + &cols, &rows) == EFI_SUCCESS ) > + efi_arch_console_init(cols, rows); > + > + gop = efi_get_gop(); > + > if ( use_cfg_file ) > { > EFI_FILE_HANDLE dir_handle; > - UINTN depth, cols, rows, size; > - > - size = cols = rows = depth = 0; > - > - if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode, > - &cols, &rows) == EFI_SUCCESS ) > - efi_arch_console_init(cols, rows); > - > - gop = efi_get_gop(); > + UINTN depth = 0; > > /* Get the file system interface. */ > dir_handle = get_parent_handle(loaded_image, &file_name);
Hi Jan, On 07/02/2022 08:46, Jan Beulich wrote: > On 06.02.2022 20:28, Julien Grall wrote: >> From: Julien Grall <jgrall@amazon.com> >> >> Currently, the EFI stub will only query the console information and >> get the GOP when using the configuration file. >> >> However, GRUB is never providing the a configuration file. So the >> EFI framebuffer will not be usable at least on Arm (support will >> be added in a follow-up patch). >> >> Move out the code outside of the configuration file section. >> >> Take the opportunity to remove the variable 'size' which was >> set but never used (interestingly GCC is only complaining if it is >> initialization when declaring the variable). >> >> With this change, GCC 8.3 will complain of argc potentially been >> used unitiatlized. I suspect this is because the argc will >> be iniitalized and used in a different if code-blocks. Yet they >> are using the same check. > > I'm inclined to suggest this wants to be a separate change, with its > own justification. You're not touching any use of argc here, after > all. Ok. I will split it. > >> Signed-off-by: Julien Grall <jgrall@amazon.com> >> >> ---- >> >> It is not entirely clear to me why the GOP was only fetched when >> the configuration file is used. >> >> I have tested this on RPI4 and it seems to work. Any chance this >> was done to workaround an x86 platform? > > This was done so in the context of making the code work for Arm. See > commit c38cf865ec82 ("EFI: ignore EFI commandline, skip console setup > when booted from GRUB"), the description of which explicitly says > > "Don't do EFI console or video configuration when booted by GRUB. The EFI boot > code does some console and video initialization to support native EFI boot from > the EFI boot manager or EFI shell. This initlization should not be done when > booted using GRUB." I read that and still couldn't figure out why this was done like that. > > What you say now is effectively the opposite (and unlike back then > x86 is now able to use this code path as well, so needs considering > too). Cc-ing Daniel for possibly having a GrUB-side opinion. I am quite interested to know the answer. Linux is able to use the EFI framebuffer when booting via GRUB. So I am a bit puzzled why we are preventing this setup on dom0/Xen. Cheers,
On 07.02.2022 19:52, Julien Grall wrote: > On 07/02/2022 08:46, Jan Beulich wrote: >> On 06.02.2022 20:28, Julien Grall wrote: >>> It is not entirely clear to me why the GOP was only fetched when >>> the configuration file is used. >>> >>> I have tested this on RPI4 and it seems to work. Any chance this >>> was done to workaround an x86 platform? >> >> This was done so in the context of making the code work for Arm. See >> commit c38cf865ec82 ("EFI: ignore EFI commandline, skip console setup >> when booted from GRUB"), the description of which explicitly says >> >> "Don't do EFI console or video configuration when booted by GRUB. The EFI boot >> code does some console and video initialization to support native EFI boot from >> the EFI boot manager or EFI shell. This initlization should not be done when >> booted using GRUB." > > I read that and still couldn't figure out why this was done like that. > >> >> What you say now is effectively the opposite (and unlike back then >> x86 is now able to use this code path as well, so needs considering >> too). Cc-ing Daniel for possibly having a GrUB-side opinion. > > I am quite interested to know the answer. Linux is able to use the EFI > framebuffer when booting via GRUB. So I am a bit puzzled why we are > preventing this setup on dom0/Xen. To be honest - same here. Jan
On Mon, Feb 07, 2022 at 06:52:57PM +0000, Julien Grall wrote: > On 07/02/2022 08:46, Jan Beulich wrote: > > On 06.02.2022 20:28, Julien Grall wrote: > >> > >> It is not entirely clear to me why the GOP was only fetched when > >> the configuration file is used. > >> > >> I have tested this on RPI4 and it seems to work. Any chance this > >> was done to workaround an x86 platform? > > > > This was done so in the context of making the code work for Arm. See > > commit c38cf865ec82 ("EFI: ignore EFI commandline, skip console setup > > when booted from GRUB"), the description of which explicitly says > > > > "Don't do EFI console or video configuration when booted by GRUB. The EFI boot > > code does some console and video initialization to support native EFI boot from > > the EFI boot manager or EFI shell. This initlization should not be done when > > booted using GRUB." > > I read that and still couldn't figure out why this was done like that. The most likely motivation was simply "Eww! ACPI/UEFI use gobs of memory! Purge the abomination!" Unfortunately ACPI/UEFI are large an complex due to trying to solve a large and complex problem. ACPI/UEFI attempt to provide an OS agnostic presentation of the hardware layout. Whereas device-trees are a common *format* for presenting hardware to *an* OS (similar to how JSON is a common format). Due to the size and complexity, most developers have preferred the simpler device-tree format even though that severely limits OS choice. As such, nuking ACPI/UEFI's presence is common in the ARM world. Versus the x86 world where Intel dragged everyone onto ACPI/UEFI. One can see this in patches like Roman Shaposhnik's "Making full 2G of memory available to Xen on HiKey" which simply tosses EFI into the garbage bin as useless overhead. Yet the ARM world is now large enough to justify OS-agnostic solutions such as ACPI/UEFI. The standards behind device-trees might be heading in this direction, but they're way behind. You stated your patch was for 5.17-rc2. How much backporting would you expect this patch to be viable for? (I'm unsure how much churn is occuring in the relevant portions of Linux) The long-term branches of Linux include 5.4.179, 5.10.100 and 5.15.23. `patch` indicated it could apply to 5.10.92 source with fuzz (hmm). This suggests 5.15 is likely viable, but 5.10 is risky and 5.4 is a very long shot.
Hi, On 12/02/2022 01:33, Elliott Mitchell wrote: > On Mon, Feb 07, 2022 at 06:52:57PM +0000, Julien Grall wrote: >> On 07/02/2022 08:46, Jan Beulich wrote: >>> On 06.02.2022 20:28, Julien Grall wrote: >>>> >>>> It is not entirely clear to me why the GOP was only fetched when >>>> the configuration file is used. >>>> >>>> I have tested this on RPI4 and it seems to work. Any chance this >>>> was done to workaround an x86 platform? >>> >>> This was done so in the context of making the code work for Arm. See >>> commit c38cf865ec82 ("EFI: ignore EFI commandline, skip console setup >>> when booted from GRUB"), the description of which explicitly says >>> >>> "Don't do EFI console or video configuration when booted by GRUB. The EFI boot >>> code does some console and video initialization to support native EFI boot from >>> the EFI boot manager or EFI shell. This initlization should not be done when >>> booted using GRUB." >> >> I read that and still couldn't figure out why this was done like that. > > The most likely motivation was simply "Eww! ACPI/UEFI use gobs of > memory! Purge the abomination!" > > Unfortunately ACPI/UEFI are large an complex due to trying to solve a > large and complex problem. ACPI/UEFI attempt to provide an OS agnostic > presentation of the hardware layout. Whereas device-trees are a common > *format* for presenting hardware to *an* OS (similar to how JSON is a > common format). > > Due to the size and complexity, most developers have preferred the > simpler device-tree format even though that severely limits OS choice. > As such, nuking ACPI/UEFI's presence is common in the ARM world. Versus > the x86 world where Intel dragged everyone onto ACPI/UEFI. > > One can see this in patches like Roman Shaposhnik's "Making full 2G of > memory available to Xen on HiKey" which simply tosses EFI into the > garbage bin as useless overhead. I couldn't find a series with this name in my archives. By any chance, are you referring to [1]? [...] > > You stated your patch was for 5.17-rc2. How much backporting would you > expect this patch to be viable for? (I'm unsure how much churn is > occuring in the relevant portions of Linux) The long-term branches of > Linux include 5.4.179, 5.10.100 and 5.15.23. `patch` indicated it could > apply to 5.10.92 source with fuzz (hmm). This suggests 5.15 is likely > viable, but 5.10 is risky and 5.4 is a very long shot. I haven't looked at backports, so I don't know. But this is not a patch I would consider to request for backport myself because IHMO this is adding device support. Cheers, [1] https://lore.kernel.org/all/CAMmSBy8Zh00tebTvz=__GDv478++b-2t4248YnkH0W9DVgqKbw@mail.gmail.com/
On Sat, Feb 12, 2022 at 01:10:52PM +0000, Julien Grall wrote: > > On 12/02/2022 01:33, Elliott Mitchell wrote: > > On Mon, Feb 07, 2022 at 06:52:57PM +0000, Julien Grall wrote: > >> On 07/02/2022 08:46, Jan Beulich wrote: > >>> On 06.02.2022 20:28, Julien Grall wrote: > >>>> > >>>> It is not entirely clear to me why the GOP was only fetched when > >>>> the configuration file is used. > >>>> > >>>> I have tested this on RPI4 and it seems to work. Any chance this > >>>> was done to workaround an x86 platform? > >>> > >>> This was done so in the context of making the code work for Arm. See > >>> commit c38cf865ec82 ("EFI: ignore EFI commandline, skip console setup > >>> when booted from GRUB"), the description of which explicitly says > >>> > >>> "Don't do EFI console or video configuration when booted by GRUB. The EFI boot > >>> code does some console and video initialization to support native EFI boot from > >>> the EFI boot manager or EFI shell. This initlization should not be done when > >>> booted using GRUB." > >> > >> I read that and still couldn't figure out why this was done like that. > > > > The most likely motivation was simply "Eww! ACPI/UEFI use gobs of > > memory! Purge the abomination!" > > > > Unfortunately ACPI/UEFI are large an complex due to trying to solve a > > large and complex problem. ACPI/UEFI attempt to provide an OS agnostic > > presentation of the hardware layout. Whereas device-trees are a common > > *format* for presenting hardware to *an* OS (similar to how JSON is a > > common format). > > > > Due to the size and complexity, most developers have preferred the > > simpler device-tree format even though that severely limits OS choice. > > As such, nuking ACPI/UEFI's presence is common in the ARM world. Versus > the x86 world where Intel dragged everyone onto ACPI/UEFI. > > > > One can see this in patches like Roman Shaposhnik's "Making full 2G of > > memory available to Xen on HiKey" which simply tosses EFI into the > > garbage bin as useless overhead. > > I couldn't find a series with this name in my archives. By any chance, > are you referring to [1]? The patch may have appeared under more than one title. The raw content is publically visible at: https://github.com/lf-edge/eve/blob/master/pkg/xen/arch/aarch64/0002-arm-efi-mem-detection.patch The issue is few ARM projects are really trying to support enough different devices for ACPI/UEFI to hit their forte. At which point ACPI/UEFI get treated as worthless overhead. > > You stated your patch was for 5.17-rc2. How much backporting would you > > expect this patch to be viable for? (I'm unsure how much churn is > > occuring in the relevant portions of Linux) The long-term branches of > > Linux include 5.4.179, 5.10.100 and 5.15.23. `patch` indicated it could > > apply to 5.10.92 source with fuzz (hmm). This suggests 5.15 is likely > > viable, but 5.10 is risky and 5.4 is a very long shot. > I haven't looked at backports, so I don't know. But this is not a patch > I would consider to request for backport myself because IHMO this is > adding device support. People who need this feature are likely to backport it themselves. Looking at the 5.10.92 source I've got handy, it appears reasonable. The fuzz appears to have be a missed newline when I attempted to grab the patch from the site you used. You want test reports yet?
On 12/02/2022 18:20, Elliott Mitchell wrote: > On Sat, Feb 12, 2022 at 01:10:52PM +0000, Julien Grall wrote: >> >> On 12/02/2022 01:33, Elliott Mitchell wrote: >>> On Mon, Feb 07, 2022 at 06:52:57PM +0000, Julien Grall wrote: >>>> On 07/02/2022 08:46, Jan Beulich wrote: >>>>> On 06.02.2022 20:28, Julien Grall wrote: >>>>>> >>>>>> It is not entirely clear to me why the GOP was only fetched when >>>>>> the configuration file is used. >>>>>> >>>>>> I have tested this on RPI4 and it seems to work. Any chance this >>>>>> was done to workaround an x86 platform? >>>>> >>>>> This was done so in the context of making the code work for Arm. See >>>>> commit c38cf865ec82 ("EFI: ignore EFI commandline, skip console setup >>>>> when booted from GRUB"), the description of which explicitly says >>>>> >>>>> "Don't do EFI console or video configuration when booted by GRUB. The EFI boot >>>>> code does some console and video initialization to support native EFI boot from >>>>> the EFI boot manager or EFI shell. This initlization should not be done when >>>>> booted using GRUB." >>>> >>>> I read that and still couldn't figure out why this was done like that. >>> >>> The most likely motivation was simply "Eww! ACPI/UEFI use gobs of >>> memory! Purge the abomination!" >>> >>> Unfortunately ACPI/UEFI are large an complex due to trying to solve a >>> large and complex problem. ACPI/UEFI attempt to provide an OS agnostic >>> presentation of the hardware layout. Whereas device-trees are a common >>> *format* for presenting hardware to *an* OS (similar to how JSON is a >>> common format). >>> >>> Due to the size and complexity, most developers have preferred the >>> simpler device-tree format even though that severely limits OS choice. >>> As such, nuking ACPI/UEFI's presence is common in the ARM world. Versus > the x86 world where Intel dragged everyone onto ACPI/UEFI. >>> >>> One can see this in patches like Roman Shaposhnik's "Making full 2G of >>> memory available to Xen on HiKey" which simply tosses EFI into the >>> garbage bin as useless overhead. >> >> I couldn't find a series with this name in my archives. By any chance, >> are you referring to [1]? > > The patch may have appeared under more than one title. The raw content > is publically visible at: > > https://github.com/lf-edge/eve/blob/master/pkg/xen/arch/aarch64/0002-arm-efi-mem-detection.patch > > The issue is few ARM projects are really trying to support enough > different devices for ACPI/UEFI to hit their forte. At which point > ACPI/UEFI get treated as worthless overhead. Thanks! I wasn't aware of that patch. >>> You stated your patch was for 5.17-rc2. How much backporting would you >>> expect this patch to be viable for? (I'm unsure how much churn is >>> occuring in the relevant portions of Linux) The long-term branches of >>> Linux include 5.4.179, 5.10.100 and 5.15.23. `patch` indicated it could >>> apply to 5.10.92 source with fuzz (hmm). This suggests 5.15 is likely >>> viable, but 5.10 is risky and 5.4 is a very long shot. > >> I haven't looked at backports, so I don't know. But this is not a patch >> I would consider to request for backport myself because IHMO this is >> adding device support. > > People who need this feature are likely to backport it themselves. Well, anyone can ask backport. I am not planning to ask nor do the backport work myselff. But feel free to send an e-mail to stable after the Linux patch is merged. > > Looking at the 5.10.92 source I've got handy, it appears reasonable. The > fuzz appears to have be a missed newline when I attempted to grab the > patch from the site you used. > > You want test reports yet? I need to do some respin. So I would say wait until the next version. Cheers,
Hi Daniel, Gentle ping. Your feedback on this approach would be helpful. On 07/02/2022 08:46, Jan Beulich wrote: > On 06.02.2022 20:28, Julien Grall wrote: >> From: Julien Grall <jgrall@amazon.com> >> >> Currently, the EFI stub will only query the console information and >> get the GOP when using the configuration file. >> >> However, GRUB is never providing the a configuration file. So the >> EFI framebuffer will not be usable at least on Arm (support will >> be added in a follow-up patch). >> >> Move out the code outside of the configuration file section. >> >> Take the opportunity to remove the variable 'size' which was >> set but never used (interestingly GCC is only complaining if it is >> initialization when declaring the variable). >> >> With this change, GCC 8.3 will complain of argc potentially been >> used unitiatlized. I suspect this is because the argc will >> be iniitalized and used in a different if code-blocks. Yet they >> are using the same check. > > I'm inclined to suggest this wants to be a separate change, with its > own justification. You're not touching any use of argc here, after > all. > >> Signed-off-by: Julien Grall <jgrall@amazon.com> >> >> ---- >> >> It is not entirely clear to me why the GOP was only fetched when >> the configuration file is used. >> >> I have tested this on RPI4 and it seems to work. Any chance this >> was done to workaround an x86 platform? > > This was done so in the context of making the code work for Arm. See > commit c38cf865ec82 ("EFI: ignore EFI commandline, skip console setup > when booted from GRUB"), the description of which explicitly says > > "Don't do EFI console or video configuration when booted by GRUB. The EFI boot > code does some console and video initialization to support native EFI boot from > the EFI boot manager or EFI shell. This initlization should not be done when > booted using GRUB." > > What you say now is effectively the opposite (and unlike back then > x86 is now able to use this code path as well, so needs considering > too). Cc-ing Daniel for possibly having a GrUB-side opinion. > > Jan > >> --- a/xen/common/efi/boot.c >> +++ b/xen/common/efi/boot.c >> @@ -1129,9 +1129,11 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) >> static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID; >> EFI_LOADED_IMAGE *loaded_image; >> EFI_STATUS status; >> - unsigned int i, argc; >> + /* Initialize argc to stop GCC complaining */ >> + unsigned int i, argc = 0; >> CHAR16 **argv, *file_name, *cfg_file_name = NULL, *options = NULL; >> - UINTN gop_mode = ~0; >> + UINTN gop_mode = ~0, cols = 0, rows = 0; >> + >> EFI_SHIM_LOCK_PROTOCOL *shim_lock; >> EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL; >> union string section = { NULL }, name; >> @@ -1219,18 +1221,16 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) >> >> efi_arch_relocate_image(0); >> >> + if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode, >> + &cols, &rows) == EFI_SUCCESS ) >> + efi_arch_console_init(cols, rows); >> + >> + gop = efi_get_gop(); >> + >> if ( use_cfg_file ) >> { >> EFI_FILE_HANDLE dir_handle; >> - UINTN depth, cols, rows, size; >> - >> - size = cols = rows = depth = 0; >> - >> - if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode, >> - &cols, &rows) == EFI_SUCCESS ) >> - efi_arch_console_init(cols, rows); >> - >> - gop = efi_get_gop(); >> + UINTN depth = 0; >> >> /* Get the file system interface. */ >> dir_handle = get_parent_handle(loaded_image, &file_name); > Cheers,
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c index 12fd0844bd55..80e4e32623c4 100644 --- a/xen/common/efi/boot.c +++ b/xen/common/efi/boot.c @@ -1129,9 +1129,11 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID; EFI_LOADED_IMAGE *loaded_image; EFI_STATUS status; - unsigned int i, argc; + /* Initialize argc to stop GCC complaining */ + unsigned int i, argc = 0; CHAR16 **argv, *file_name, *cfg_file_name = NULL, *options = NULL; - UINTN gop_mode = ~0; + UINTN gop_mode = ~0, cols = 0, rows = 0; + EFI_SHIM_LOCK_PROTOCOL *shim_lock; EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL; union string section = { NULL }, name; @@ -1219,18 +1221,16 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) efi_arch_relocate_image(0); + if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode, + &cols, &rows) == EFI_SUCCESS ) + efi_arch_console_init(cols, rows); + + gop = efi_get_gop(); + if ( use_cfg_file ) { EFI_FILE_HANDLE dir_handle; - UINTN depth, cols, rows, size; - - size = cols = rows = depth = 0; - - if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode, - &cols, &rows) == EFI_SUCCESS ) - efi_arch_console_init(cols, rows); - - gop = efi_get_gop(); + UINTN depth = 0; /* Get the file system interface. */ dir_handle = get_parent_handle(loaded_image, &file_name);