On Mon, Nov 11, 2019 at 05:59:42PM +0000, Ard Biesheuvel wrote:
> On Mon, 11 Nov 2019 at 15:44, Andy Shevchenko
> <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> >
> > When the commit 69c1f396f25b ("efi/x86: Convert x86 EFI earlyprintk
> > into generic earlycon implementation") moved x86 specific EFI earlyprintk
> > implementation to shared location it also tweaked the behaviour. In particular
> > it dropped a trick with full framebuffer remapping after page initialization.
> > This lead to two regressions:
> > 1) very slow scrolling after page initialization;
> > 2) kernel hang when keep_bootcon parameter is being provided.
> >
> > Returning the trick back fixes #2 and mitigates, i.e. reduces the window when
> > slowness appears, #1 presumably due to eliminating heavy map()/unmap()
> > operations per each pixel line on the screen.
> Thanks for fixing this. One question below.
>
> > +static __init int early_efi_map_fb(void)
> > +{
> > + u32 size;
> > +
> > + size = screen_info.lfb_size;
> > + if (pgprot_val(fb_prot) == pgprot_val(PAGE_KERNEL))
> > + efi_fb = memremap(fb_base, size, MEMREMAP_WB);
> > + else
> > + efi_fb = memremap(fb_base, size, MEMREMAP_WC);
> > +
> > + return efi_fb ? 0 : -ENOMEM;
> > +}
> > +early_initcall(early_efi_map_fb);
> > +
> > +static __exit void early_efi_unmap_fb(void)
>
> Will there be a user for this routine? If not, can we just drop it?
The same question can be applied to the driver core part(s), e.g.
deferred_probe_exit() in dd.c).
The above basically what Greg KH told people to do. While it is partially cargo
cult here I can imagine that in some environments (virtual or kexec) somebody
would like to get a picture of (post-mortem?) analysis where it would be
helpful. Also code looks symmetrical in order to resource management. So, if
you insist, I'll remove it, although I personally like my variant.
> > +{
> > + memunmap(efi_fb);
> > +}
--
With Best Regards,
Andy Shevchenko
