All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Arvind Sankar <nivedita@alum.mit.edu>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	linux-efi <linux-efi@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Bhupesh Sharma <bhsharma@redhat.com>,
	Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Subject: Re: [PATCH 6/6] efi/earlycon: Remap entire framebuffer after page initialization
Date: Mon, 9 Dec 2019 19:24:13 +0000	[thread overview]
Message-ID: <CAKv+Gu8QWcSwRajsO5voTQJxDHy613ugCd_R6=SStf9ABrmtfQ@mail.gmail.com> (raw)
In-Reply-To: <20191209191242.GA3075464@rani.riverdale.lan>

On Mon, 9 Dec 2019 at 20:12, Arvind Sankar <nivedita@alum.mit.edu> wrote:
>
> On Fri, Dec 06, 2019 at 04:55:42PM +0000, Ard Biesheuvel wrote:
> > From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> >
> > When commit 69c1f396f25b
> >
> >   "efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation"
> >
> > moved the x86 specific EFI earlyprintk implementation to a shared location,
> > it also tweaked the behaviour. In particular, it dropped a trick with full
> > framebuffer remapping after page initialization, leading to two regressions:
> > 1) very slow scrolling after page initialization,
> > 2) kernel hang when the 'keep_bootcon' command line argument is passed.
> >
> > Putting the tweak back fixes #2 and mitigates #1, i.e., it limits the slow
> > behavior to the early boot stages, presumably due to eliminating heavy
> > map()/unmap() operations per each pixel line on the screen.
> >
>
> Could the efi earlycon have an interaction with PCI resource allocation,
> similar to what commit dcf8f5ce3165 ("drivers/fbdev/efifb: Allow BAR to
> be moved instead of claiming it") fixed for efifb?

Yes. If the BAR gets moved, things will break. This is mostly an issue
for the keep_bootcon case, but that is documented as being a debug
feature specifically for addressing console initialization related
issues. Earlycon itself is also a debug feature, so if you hit the BAR
reallocation issue, you're simply out of luck. Note that this happens
rarely in practice, only on non-x86 systems where the firmware and the
kernel have very different policies regarding BAR allocation, and on
DT based systems, you can force the OS to honour the existing
allocation by using linux,pci-probe-only

  reply	other threads:[~2019-12-09 19:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-06 16:55 [GIT PULL 0/6] EFI fixes for v5.5 Ard Biesheuvel
2019-12-06 16:55 ` [PATCH 1/6] efi/memreserve: register reservations as 'reserved' in /proc/iomem Ard Biesheuvel
2019-12-08 13:33   ` [tip: efi/urgent] efi/memreserve: Register " tip-bot2 for Ard Biesheuvel
2019-12-06 16:55 ` [PATCH 2/6] efi/gop: Return EFI_NOT_FOUND if there are no usable GOPs Ard Biesheuvel
2019-12-08 13:33   ` [tip: efi/urgent] " tip-bot2 for Arvind Sankar
2019-12-06 16:55 ` [PATCH 3/6] efi/gop: Return EFI_SUCCESS if a usable GOP was found Ard Biesheuvel
2019-12-08 13:33   ` [tip: efi/urgent] " tip-bot2 for Arvind Sankar
2019-12-06 16:55 ` [PATCH 4/6] efi/gop: Fix memory leak from __gop_query32/64 Ard Biesheuvel
2019-12-08 13:33   ` [tip: efi/urgent] efi/gop: Fix memory leak in __gop_query32/64() tip-bot2 for Arvind Sankar
2019-12-06 16:55 ` [PATCH 5/6] efi: fix type of unload field in efi_loaded_image_t Ard Biesheuvel
2019-12-08 13:33   ` [tip: efi/urgent] efi: Fix efi_loaded_image_t::unload type tip-bot2 for Arvind Sankar
2019-12-06 16:55 ` [PATCH 6/6] efi/earlycon: Remap entire framebuffer after page initialization Ard Biesheuvel
2019-12-08 13:33   ` [tip: efi/urgent] " tip-bot2 for Andy Shevchenko
2019-12-09 19:12   ` [PATCH 6/6] " Arvind Sankar
2019-12-09 19:24     ` Ard Biesheuvel [this message]
2019-12-10 20:05       ` Arvind Sankar
2019-12-11 11:26         ` Ard Biesheuvel
2019-12-11 15:55           ` Arvind Sankar

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='CAKv+Gu8QWcSwRajsO5voTQJxDHy613ugCd_R6=SStf9ABrmtfQ@mail.gmail.com' \
    --to=ard.biesheuvel@linaro.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=ardb@kernel.org \
    --cc=bhsharma@redhat.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.mizuma@jp.fujitsu.com \
    --cc=mingo@kernel.org \
    --cc=nivedita@alum.mit.edu \
    --cc=tglx@linutronix.de \
    --subject='Re: [PATCH 6/6] efi/earlycon: Remap entire framebuffer after page initialization' \
    /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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.