All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Takashi Iwai <tiwai@suse.de>, "Lee, Chun-Yi" <jlee@suse.com>,
	linux-efi <linux-efi@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] efi: Downgrade "EFI_MEMMAP is not enabled" message
Date: Fri, 01 Mar 2019 15:14:34 +0100	[thread overview]
Message-ID: <s5h5zt2el6d.wl-tiwai@suse.de> (raw)
In-Reply-To: <CAKv+Gu91QeeFHXfp4ShM2z1hbypwnoRKzZQQ3Sktk1sASXvR6Q@mail.gmail.com>

On Fri, 01 Mar 2019 15:02:23 +0100,
Ard Biesheuvel wrote:
> 
> On Fri, 1 Mar 2019 at 15:01, Takashi Iwai <tiwai@suse.de> wrote:
> >
> > On Fri, 01 Mar 2019 14:53:39 +0100,
> > Ard Biesheuvel wrote:
> > >
> > > On Fri, 1 Mar 2019 at 14:40, Takashi Iwai <tiwai@suse.de> wrote:
> > > >
> > > > Since 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes
> > > > when mapping the FB"), efifb_probe() checks its memory range via
> > > > efi_mem_desc_lookup(), and this leads to a spurious error message
> > > > "EFI_MEMMAP is not enabled" at every boot on KVM.  This is quite
> > > > annoying since the error message appears even if you set "quiet" boot
> > > > option.
> > > >
> > > > Actually there are only a few places that call efi_mem_desc_lookup()
> > > > function, and the other callers do give the explicit error messages
> > > > when the function returns an error in anyway.  That is, the error
> > > > message in the function is more or less moot.
> > > >
> > > > So let's downgrade the error message for stop annoying users.
> > > >
> > > > Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when mapping the FB")
> > > > Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1127339
> > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > ---
> > > >  drivers/firmware/efi/efi.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > > > index 55b77c576c42..50ac33097458 100644
> > > > --- a/drivers/firmware/efi/efi.c
> > > > +++ b/drivers/firmware/efi/efi.c
> > > > @@ -409,7 +409,7 @@ int efi_mem_desc_lookup(u64 phys_addr, efi_memory_desc_t *out_md)
> > > >         efi_memory_desc_t *md;
> > > >
> > > >         if (!efi_enabled(EFI_MEMMAP)) {
> > > > -               pr_err_once("EFI_MEMMAP is not enabled.\n");
> > > > +               pr_debug("EFI_MEMMAP is not enabled.\n");
> > > >                 return -EINVAL;
> > > >         }
> > > >
> > >
> > > efifb_probe() only calls efi_mem_desc_lookup() if
> > > screen_info.orig_video_isVGA == VIDEO_TYPE_EFI, which only gets
> > > assigned on a EFI boot.
> > >
> > > So even though I don't object to the patch as is, I would like to
> > > understand where this error message is coming from, given that it
> > > means that you are running on a UEFI system without the EFI memory
> > > map.
> > >
> > > Is this system booting via GRUB in EFI mode?
> >
> > No, it's booted in legacy boot mode.  But the primary fb is efifb, and
> > that's why the message appears.
> >
> 
> So how are we ending up with
> 
> screen_info.orig_video_isVGA == VIDEO_TYPE_EFI
> 
> ??

Ah, sorry, my description was too ambiguous.

Actually our GRUB2 default setup boots the Linux kernel with linuxefi.
What I meant was that I invoked qemu-kvm without any -bios option, so
it's no EFI BIOS.


thanks,

Takashi

  reply	other threads:[~2019-03-01 14:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-01 13:40 [PATCH] efi: Downgrade "EFI_MEMMAP is not enabled" message Takashi Iwai
2019-03-01 13:53 ` Ard Biesheuvel
2019-03-01 14:01   ` Takashi Iwai
2019-03-01 14:02     ` Ard Biesheuvel
2019-03-01 14:14       ` Takashi Iwai [this message]
2019-03-01 14:57         ` Ard Biesheuvel
2019-03-01 15:27           ` Takashi Iwai
2019-03-26 15:24             ` Takashi Iwai
2019-03-26 16:04               ` Ard Biesheuvel
2019-03-26 16:07                 ` Takashi Iwai

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=s5h5zt2el6d.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=ard.biesheuvel@linaro.org \
    --cc=jlee@suse.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.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 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.