From: Arvind Sankar <nivedita@alum.mit.edu>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Arvind Sankar <nivedita@alum.mit.edu>,
linux-efi <linux-efi@vger.kernel.org>,
Guenter Roeck <linux@roeck-us.net>
Subject: Re: [PATCH 1/1] efi/libstub: Fix mixed mode boot issue after macro refactor
Date: Mon, 4 May 2020 10:27:41 -0400 [thread overview]
Message-ID: <20200504142741.GA21142@rani.riverdale.lan> (raw)
In-Reply-To: <CAMj1kXEjvRkcZ7_J9zVbqFoZsRfbDA8c_xyHRM+je2njHeDEMQ@mail.gmail.com>
On Mon, May 04, 2020 at 04:15:59PM +0200, Ard Biesheuvel wrote:
> On Mon, 4 May 2020 at 16:02, Arvind Sankar <nivedita@alum.mit.edu> wrote:
> >
> > On Mon, May 04, 2020 at 10:05:23AM +0200, Ard Biesheuvel wrote:
> > > On Mon, 4 May 2020 at 02:38, Arvind Sankar <nivedita@alum.mit.edu> wrote:
> > > >
> > > > Commit
> > > > 22090f84bc3f ("efi/libstub: unify EFI call wrappers for non-x86")
> > > >
> > > > refactored the macros that are used to provide wrappers for mixed-mode
> > > > calls on x86, allowing us to boot a 64-bit kernel on 32-bit firmware.
> > > >
> > > > Unfortunately, this broke mixed mode boot due to the fact that
> > > > efi_is_native() is not a macro on x86.
> > > >
> > > > Fix this by conditioning the generic macro definitions on
> > > > CONFIG_EFI_MIXED, and removing the wrapper definitions on x86 if
> > > > CONFIG_EFI_MIXED is not enabled.
> > > >
> > > > Reported-by: Guenter Roeck <linux@roeck-us.net>
> > > > Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
> > >
> > > Thanks Arvind.
> > >
> > > Currently, CONFIG_EFI_MIXED is never referenced outside of arch/x86,
> > > and I prefer to keep it that way.
> >
> > All these macros go together though -- they should either all be defined
> > or none, so it makes sense to put them under a single #if.
>
> True.
>
> > If you think
> > it's possible that a future architecture might need the wrappers but not
> > be mixed, we could maybe add an ARCH_NEEDS_EFISTUB_WRAPPERS?
> >
>
> Well, remember that x86 used wrappers for native invocations only two
> releases ago, but that was mainly because of the SysV vs MS ABI issue,
> so the issue could emerge again, but it is unlikely.
>
Yep.
Would the below be more palatable?
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index cd0c3fbf6156..6b9ab0d8b2a7 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -225,13 +225,15 @@ efi_status_t efi_set_virtual_address_map(unsigned long memory_map_size,
/* arch specific definitions used by the stub code */
-extern const bool efi_is64;
+#ifdef CONFIG_EFI_MIXED
+
+#define ARCH_HAS_EFISTUB_WRAPPERS
static inline bool efi_is_64bit(void)
{
- if (IS_ENABLED(CONFIG_EFI_MIXED))
- return efi_is64;
- return IS_ENABLED(CONFIG_X86_64);
+ extern const bool efi_is64;
+
+ return efi_is64;
}
static inline bool efi_is_native(void)
@@ -356,6 +358,15 @@ static inline u32 efi64_convert_status(efi_status_t status)
runtime), \
func, __VA_ARGS__))
+#else /* CONFIG_EFI_MIXED */
+
+static inline bool efi_is_64bit(void)
+{
+ return IS_ENABLED(CONFIG_X86_64);
+}
+
+#endif /* CONFIG_EFI_MIXED */
+
extern bool efi_reboot_required(void);
extern bool efi_is_table_address(unsigned long phys_addr);
diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
index 874233cf8820..4f10a09563f3 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -33,20 +33,14 @@ extern bool efi_novamap;
extern const efi_system_table_t *efi_system_table;
-#ifndef efi_bs_call
+#ifndef ARCH_HAS_EFISTUB_WRAPPERS
+
+#define efi_is_native() (true)
#define efi_bs_call(func, ...) efi_system_table->boottime->func(__VA_ARGS__)
-#endif
-#ifndef efi_rt_call
#define efi_rt_call(func, ...) efi_system_table->runtime->func(__VA_ARGS__)
-#endif
-#ifndef efi_is_native
-#define efi_is_native() (true)
-#endif
-#ifndef efi_table_attr
#define efi_table_attr(inst, attr) (inst->attr)
-#endif
-#ifndef efi_call_proto
#define efi_call_proto(inst, func, ...) inst->func(inst, ##__VA_ARGS__)
+
#endif
#define efi_info(msg) do { \
next prev parent reply other threads:[~2020-05-04 14:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-03 15:45 [PATCH] efi/libstub/x86: fix mixed mode boot issue after macro refactor Ard Biesheuvel
2020-05-04 0:38 ` [PATCH 0/1] efi/libstub: Fix mixed mode boot on efi/next Arvind Sankar
2020-05-04 0:38 ` [PATCH 1/1] efi/libstub: Fix mixed mode boot issue after macro refactor Arvind Sankar
2020-05-04 8:05 ` Ard Biesheuvel
2020-05-04 14:02 ` Arvind Sankar
2020-05-04 14:15 ` Ard Biesheuvel
2020-05-04 14:27 ` Arvind Sankar [this message]
2020-05-04 14:33 ` Ard Biesheuvel
2020-05-04 15:02 ` [PATCH v2] " Arvind Sankar
2020-05-05 7:58 ` Ard Biesheuvel
2020-05-04 2:25 ` [PATCH 0/1] efi/libstub: Fix mixed mode boot on efi/next Guenter Roeck
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=20200504142741.GA21142@rani.riverdale.lan \
--to=nivedita@alum.mit.edu \
--cc=ardb@kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux@roeck-us.net \
/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).