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

[Julien Grall <julien@xxxxxxx>]

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,

--
Julien Grall