[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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?


-- 
(\___(\___(\______          --=> 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





 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.