Re: [PATCH RFC 1/3] xen/efi: Always query the console information and get GOP

[Elliott Mitchell <ehem+xen@xxxxxxx>]

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.


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