linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josh Triplett <josh@joshtriplett.org>
To: Matt Fleming <matt.fleming@intel.com>
Cc: linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, Len Brown <lenb@kernel.org>,
	Olof Johansson <olof@lixom.net>, Matthew Garrett <mjg@redhat.com>,
	David Howells <dhowells@redhat.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Jim Cromie <jim.cromie@gmail.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Pawel Moll <pawel.moll@arm.com>,
	linux-acpi@vger.kernel.org, linux-efi <linux-efi@vger.kernel.org>
Subject: Re: [PATCH 0/3] Fix ACPI BGRT support for images located in EFI boot services memory
Date: Tue, 4 Sep 2012 10:59:52 -0700	[thread overview]
Message-ID: <20120904175952.GA4103@jtriplet-mobl1> (raw)
In-Reply-To: <1346768840.4244.52.camel@mfleming-mobl1.ger.corp.intel.com>

On Tue, Sep 04, 2012 at 03:27:20PM +0100, Matt Fleming wrote:
> On Thu, 2012-08-30 at 14:28 -0700, Josh Triplett wrote:
> > The ACPI BGRT lets the OS access the BIOS logo image and its position on the
> > screen at boot time, allowing it to maintain that image on the screen until
> > ready to display something else, making boot more seamless.  This series fixes
> > support for accessing the boot logo image via the BGRT when the BIOS stores it
> > in EFI boot services memory, as recommended by the ACPI 5.0 spec.  Linux needs
> > to copy the image out of boot services memory before reclaiming boot services
> > memory.
> > 
> > The first patch refactors EFI initialization to defer freeing boot services
> > memory until later in the boot process, after we have ACPI available.  The
> > second patch adds a helper function to look up existing EFI boot services
> > mappings, to avoid re-mapping them.  The third patch moves BGRT initialization
> > to before the reclamation of boot services memory, copies the logo at that
> > point, and reworks the existing BGRT driver to use that existing copy.
> 
> Since we always end up doing a copy anyway, is there no way we could
> just copy the boot logo *without* deferring freeing the boot services
> code, e.g. move the copy before we do SetVirtualAddressMap()?

Unfortunately not.  We need enough of ACPI available to go read the
BGRT to know what to copy, so we need to defer freeing boot services
code until after we initialize ACPI (and thus everything ACPI needs,
which includes EFI since ACPI looks for root tables there).

> I wouldn't be surprised if some implementations got really cranky if
> we accessed boot services data after we installed a new virtual memory
> map.

Note that I've carefully accessed the boot services data *through* the
new virtual memory map, which should work fine.

> Besides, if we can avoid moving the efi_free_boot_services() call we can
> avoid littering init/main.c with more #ifdef CONFIG_X86 blocks.

Those seem easy enough to convert into appropriate always-available
stubs, if you'd like.  And I could move efi_free_boot_services() inside
efi_late_init(), too, keeping it an internal implementation detail of
EFI initialization.  Would that help?

- Josh Triplett

  reply	other threads:[~2012-09-04 18:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-30 21:28 [PATCH 0/3] Fix ACPI BGRT support for images located in EFI boot services memory Josh Triplett
2012-08-30 21:28 ` [PATCH 1/3] efi: Defer freeing boot services memory until after ACPI init Josh Triplett
2012-08-30 21:28 ` [PATCH 2/3] efi: Add a function to look up existing IO memory mappings Josh Triplett
2012-08-30 21:28 ` [PATCH 3/3] efi: Fix the ACPI BGRT driver for images located in EFI boot services memory Josh Triplett
2012-09-04 14:27 ` [PATCH 0/3] Fix ACPI BGRT support " Matt Fleming
2012-09-04 17:59   ` Josh Triplett [this message]
2012-09-04 18:10     ` H. Peter Anvin
2012-09-04 19:45       ` Josh Triplett
2012-09-04 20:24         ` H. Peter Anvin
2012-09-04 20:29           ` Josh Triplett
2012-09-04 20:11     ` Matt Fleming

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120904175952.GA4103@jtriplet-mobl1 \
    --to=josh@joshtriplett.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=dhowells@redhat.com \
    --cc=hpa@zytor.com \
    --cc=jim.cromie@gmail.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt.fleming@intel.com \
    --cc=mingo@redhat.com \
    --cc=mjg@redhat.com \
    --cc=olof@lixom.net \
    --cc=pawel.moll@arm.com \
    --cc=rusty@rustcorp.com.au \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).