From: Ard Biesheuvel <ardb@kernel.org>
To: linux-efi@vger.kernel.org
Cc: Ard Biesheuvel <ardb@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>
Subject: [PATCH v2 08/11] acpi/prmt: Use EFI runtime sandbox to invoke PRM handlers
Date: Fri, 18 Aug 2023 13:37:21 +0200 [thread overview]
Message-ID: <20230818113724.368492-9-ardb@kernel.org> (raw)
In-Reply-To: <20230818113724.368492-1-ardb@kernel.org>
Instead of bypassing the kernel's adaptation layer for performing EFI
runtime calls, wire up ACPI PRM handling into it. This means these calls
can no longer occur concurrently with EFI runtime calls, and will be
made from the EFI runtime workqueue. It also means any page faults
occurring during PRM handling will be identified correctly as
originating in firmware code.
While at it, give the function pointer struct member a more descriptive
name so it will stand out in diagnostic messages if any issues do occur.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
drivers/acpi/Kconfig | 2 +-
drivers/acpi/prmt.c | 6 ++--
drivers/firmware/efi/runtime-wrappers.c | 32 ++++++++++++++++++++
include/linux/efi.h | 5 +++
4 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 00dd309b66828182..cee82b473dc50921 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -581,7 +581,7 @@ config ACPI_VIOT
config ACPI_PRMT
bool "Platform Runtime Mechanism Support"
- depends on EFI && (X86_64 || ARM64)
+ depends on EFI_RUNTIME_WRAPPERS && (X86_64 || ARM64)
default y
help
Platform Runtime Mechanism (PRM) is a firmware interface exposing a
diff --git a/drivers/acpi/prmt.c b/drivers/acpi/prmt.c
index 71b9adaaf33b93cf..7020584096bfaaaf 100644
--- a/drivers/acpi/prmt.c
+++ b/drivers/acpi/prmt.c
@@ -260,9 +260,9 @@ static acpi_status acpi_platformrt_space_handler(u32 function,
context.static_data_buffer = handler->static_data_buffer_addr;
context.mmio_ranges = module->mmio_info;
- status = efi_call_virt_pointer(handler, handler_addr,
- handler->acpi_param_buffer_addr,
- &context);
+ status = efi_call_acpi_prm_handler(handler->handler_addr,
+ handler->acpi_param_buffer_addr,
+ &context);
if (status == EFI_SUCCESS) {
buffer->prm_status = PRM_HANDLER_SUCCESS;
} else {
diff --git a/drivers/firmware/efi/runtime-wrappers.c b/drivers/firmware/efi/runtime-wrappers.c
index afe9248cc5bc61ba..71d3c70f0705e1b9 100644
--- a/drivers/firmware/efi/runtime-wrappers.c
+++ b/drivers/firmware/efi/runtime-wrappers.c
@@ -108,6 +108,12 @@ union efi_rts_args {
u64 *max_size;
int *reset_type;
} QUERY_CAPSULE_CAPS;
+
+ struct {
+ efi_status_t (__efiapi *acpi_prm_handler)(u64, void *);
+ u64 param_buffer_addr;
+ void *context;
+ } ACPI_PRM_HANDLER;
};
struct efi_runtime_work efi_rts_work;
@@ -283,6 +289,14 @@ static void efi_call_rts(struct work_struct *work)
args->QUERY_CAPSULE_CAPS.max_size,
args->QUERY_CAPSULE_CAPS.reset_type);
break;
+ case EFI_ACPI_PRM_HANDLER:
+#ifdef CONFIG_ACPI_PRMT
+ status = arch_efi_call_virt(&args->ACPI_PRM_HANDLER,
+ acpi_prm_handler,
+ args->ACPI_PRM_HANDLER.param_buffer_addr,
+ args->ACPI_PRM_HANDLER.context);
+ break;
+#endif
default:
/*
* Ideally, we should never reach here because a caller of this
@@ -560,3 +574,21 @@ void efi_native_runtime_setup(void)
efi.update_capsule = virt_efi_update_capsule;
efi.query_capsule_caps = virt_efi_query_capsule_caps;
}
+
+#ifdef CONFIG_ACPI_PRMT
+
+efi_status_t
+efi_call_acpi_prm_handler(efi_status_t (__efiapi *handler_addr)(u64, void *),
+ u64 param_buffer_addr, void *context)
+{
+ efi_status_t status;
+
+ if (down_interruptible(&efi_runtime_lock))
+ return EFI_ABORTED;
+ status = efi_queue_work(ACPI_PRM_HANDLER, handler_addr,
+ param_buffer_addr, context);
+ up(&efi_runtime_lock);
+ return status;
+}
+
+#endif
diff --git a/include/linux/efi.h b/include/linux/efi.h
index cf450b6fbfd20aa5..15b94dad5091b406 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -1229,6 +1229,10 @@ extern int efi_tpm_final_log_size;
extern unsigned long rci2_table_phys;
+efi_status_t
+efi_call_acpi_prm_handler(efi_status_t (__efiapi *handler_addr)(u64, void *),
+ u64 param_buffer_addr, void *context);
+
/*
* efi_runtime_service() function identifiers.
* "NONE" is used by efi_recover_from_page_fault() to check if the page
@@ -1248,6 +1252,7 @@ enum efi_rts_ids {
EFI_RESET_SYSTEM,
EFI_UPDATE_CAPSULE,
EFI_QUERY_CAPSULE_CAPS,
+ EFI_ACPI_PRM_HANDLER,
};
union efi_rts_args;
--
2.39.2
next prev parent reply other threads:[~2023-08-18 11:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-18 11:37 [PATCH v2 00/11] efi: Clean up runtime wrapper and wire it up for PRM Ard Biesheuvel
2023-08-18 11:37 ` [PATCH v2 01/11] efi/x86: Move EFI runtime call setup/teardown helpers out of line Ard Biesheuvel
2023-08-18 11:37 ` [PATCH v2 02/11] efi/arm64: " Ard Biesheuvel
2023-08-21 10:24 ` Catalin Marinas
2023-08-18 11:37 ` [PATCH v2 03/11] efi/riscv: " Ard Biesheuvel
2023-08-18 11:37 ` [PATCH v2 04/11] efi/runtime-wrappers: Use type safe encapsulation of call arguments Ard Biesheuvel
2023-08-18 11:37 ` [PATCH v2 05/11] efi/runtime-wrapper: Move workqueue manipulation out of line Ard Biesheuvel
2023-08-18 11:37 ` [PATCH v2 06/11] efi/runtime-wrappers: Remove duplicated macro for service returning void Ard Biesheuvel
2023-08-18 11:37 ` [PATCH v2 07/11] efi/runtime-wrappers: Don't duplicate setup/teardown code Ard Biesheuvel
2023-08-18 11:37 ` Ard Biesheuvel [this message]
2023-08-18 11:37 ` [PATCH v2 09/11] efi/runtime-wrappers: Clean up white space and add __init annotation Ard Biesheuvel
2023-08-18 11:37 ` [RFC PATCH v2 10/11] efi/x86: Realign EFI runtime stack Ard Biesheuvel
2023-08-18 11:37 ` [RFC PATCH v2 11/11] efi/x86: Rely on compiler to emit MS ABI calls Ard Biesheuvel
2023-08-22 2:01 ` [PATCH v2 00/11] efi: Clean up runtime wrapper and wire it up for PRM Nathan Chancellor
2023-08-22 7:53 ` Ard Biesheuvel
2023-08-22 10:00 ` Ard Biesheuvel
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=20230818113724.368492-9-ardb@kernel.org \
--to=ardb@kernel.org \
--cc=aou@eecs.berkeley.edu \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=linux-efi@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=rafael.j.wysocki@intel.com \
--cc=rafael@kernel.org \
--cc=tglx@linutronix.de \
--cc=will@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