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

[Julien Grall <julien@xxxxxxx>]

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@xxxxxxxxxxxxxx/
--
Julien Grall