On 8/21/24 11:20, Zhang, Rui wrote:
External email: Use caution opening links or attachments
On Thu, 2024-08-01 at 09:48 +0800, KobaK wrote:
PRMT needs to find the correct type of block to
translate the PA-VA mapping for EFI runtime services.
The issue arises because the PRMT is finding a block of type
EFI_CONVENTIONAL_MEMORY,
which is not appropriate for runtime services as described in Section
2.2.2 (Runtime
Services) of the UEFI Specification [1]. Since the PRM handler is a
type of runtime
service, this causes an exception when the PRM handler is called.
Too many characters in one line.
https://docs.kernel.org/process/submitting-patches.html#the-canonical-patch-format
will fix this in the description.
[Firmware Bug]: Unable to handle paging request in EFI runtime
service
WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-
wrappers.c:341 __efi_queue_work+0x11c/0x170
Call trace:
__efi_queue_work+0x11c/0x170
efi_call_acpi_prm_handler+0x68/0xd0
acpi_platformrt_space_handler+0x198/0x258
acpi_ev_address_space_dispatch+0x144/0x388
acpi_ex_access_region+0x9c/0x118
acpi_ex_write_serial_bus+0xc4/0x218
acpi_ex_write_data_to_field+0x168/0x218
acpi_ex_store_object_to_node+0x1a8/0x258
acpi_ex_store+0xec/0x330
acpi_ex_opcode_1A_1T_1R+0x15c/0x618
acpi_ds_exec_end_op+0x274/0x548
acpi_ps_parse_loop+0x10c/0x6b8
acpi_ps_parse_aml+0x140/0x3b0
acpi_ps_execute_method+0x12c/0x2a0
acpi_ns_evaluate+0x210/0x310
acpi_evaluate_object+0x178/0x358
acpi_proc_write+0x1a8/0x8a0 [acpi_call]
proc_reg_write+0xcc/0x150
vfs_write+0xd8/0x380
ksys_write+0x70/0x120
__arm64_sys_write+0x24/0x48
invoke_syscall.constprop.0+0x80/0xf8
do_el0_svc+0x50/0x110
el0_svc+0x48/0x1d0
el0t_64_sync_handler+0x15c/0x178
el0t_64_sync+0x1a8/0x1b0
Find a block with specific type to fix this.
prmt find a block with EFI_RUNTIME_SERVICES_DATA for prm handler.
prmt find a block with EFI_RUNTIME_SERVICES_CODE for prm context.
By using the correct memory types for runtime services,
we can ensure that the PRM handler and
its context are properly mapped in the virtual address space during
runtime,
preventing the paging request error.
some general rules to follow when writing a changelog
https://docs.kernel.org/process/maintainer-tip.html 4.2.3. Changelog
will decorate this.
[1]
https://uefi.org/sites/default/files/resources/UEFI_Spec_2_10_Aug29.pdf
Fixes: cefc7ca46235 ("ACPI: PRM: implement OperationRegion handler
for the PlatformRtMechanism subtype")
Signed-off-by: KobaK <kobak@xxxxxxxxxx>
Reviewed-by: Matthew R. Ochs <mochs@xxxxxxxxxx>
---
drivers/acpi/prmt.c | 46 ++++++++++++++++++++++++++++++-------------
--
1 file changed, 31 insertions(+), 15 deletions(-)
diff --git a/drivers/acpi/prmt.c b/drivers/acpi/prmt.c
index c78453c74ef5..e2f0bdd81013 100644
--- a/drivers/acpi/prmt.c
+++ b/drivers/acpi/prmt.c
@@ -72,17 +72,21 @@ struct prm_module_info {
struct prm_handler_info handlers[]
__counted_by(handler_count);
};
-static u64 efi_pa_va_lookup(u64 pa)
+static u64 efi_pa_va_lookup(u64 pa, u32 type)
{
efi_memory_desc_t *md;
u64 pa_offset = pa & ~PAGE_MASK;
u64 page = pa & PAGE_MASK;
for_each_efi_memory_desc(md) {
- if (md->phys_addr < pa && pa < md->phys_addr +
PAGE_SIZE * md->num_pages)
+ if ((md->type == type) &&
+ (md->phys_addr < pa && pa < md->phys_addr +
PAGE_SIZE * md->num_pages)) {
return pa_offset + md->virt_addr + page - md-
phys_addr;
+ }
}
+ pr_err("PRM: Failed to find a block for pa: %lx type %u\n",
pa, type);
+
If it is a pr_err, why not error out?
or what is the proper handling for such failures?
return 0;
}
@@ -148,9 +152,12 @@ acpi_parse_prmt(union acpi_subtable_headers
*header, const unsigned long end)
th = &tm->handlers[cur_handler];
guid_copy(&th->guid, (guid_t *)handler_info-
handler_guid);
- th->handler_addr = (void
*)efi_pa_va_lookup(handler_info->handler_address);
- th->static_data_buffer_addr =
efi_pa_va_lookup(handler_info->static_data_buffer_address);
- th->acpi_param_buffer_addr =
efi_pa_va_lookup(handler_info->acpi_param_buffer_address);
+ th->handler_addr =
+ (void *)efi_pa_va_lookup(handler_info-
handler_address, EFI_RUNTIME_SERVICES_CODE);
+ th->static_data_buffer_addr =
+ efi_pa_va_lookup(handler_info-
static_data_buffer_address, EFI_RUNTIME_SERVICES_DATA);
+ th->acpi_param_buffer_addr =
+ efi_pa_va_lookup(handler_info-
acpi_param_buffer_address, EFI_RUNTIME_SERVICES_DATA);
} while (++cur_handler < tm->handler_count && (handler_info =
get_next_handler(handler_info)));
return 0;
@@ -250,8 +257,16 @@ static acpi_status
acpi_platformrt_space_handler(u32 function,
handler = find_prm_handler(&buffer->handler_guid);
module = find_prm_module(&buffer->handler_guid);
- if (!handler || !module)
- goto invalid_guid;
+ if (!handler || !module) {
+ buffer->prm_status =
PRM_HANDLER_GUID_NOT_FOUND;
+ goto error;
I think it is okay to return AE_OK directly, right?
thanks,
rui
I'm also good for this.
I followed the convention in this block.
If change to "return", i will change all "goto error".
How do you think?
+ }
+
+ if (!handler->handler_addr || !handler-
static_data_buffer_addr ||
+ !handler->acpi_param_buffer_addr) {
+ buffer->prm_status = PRM_HANDLER_ERROR;
+ goto error;
+ }
ACPI_COPY_NAMESEG(context.signature, "PRMC");
context.revision = 0x0;
@@ -274,8 +289,10 @@ static acpi_status
acpi_platformrt_space_handler(u32 function,
case PRM_CMD_START_TRANSACTION:
module = find_prm_module(&buffer->handler_guid);
- if (!module)
- goto invalid_guid;
+ if (!module) {
+ buffer->prm_status =
PRM_HANDLER_GUID_NOT_FOUND;
+ goto error;
+ }
if (module->updatable)
module->updatable = false;
@@ -286,8 +303,10 @@ static acpi_status
acpi_platformrt_space_handler(u32 function,
case PRM_CMD_END_TRANSACTION:
module = find_prm_module(&buffer->handler_guid);
- if (!module)
- goto invalid_guid;
+ if (!module) {
+ buffer->prm_status =
PRM_HANDLER_GUID_NOT_FOUND;
+ goto error;
+ }
if (module->updatable)
buffer->prm_status =
UPDATE_UNLOCK_WITHOUT_LOCK;
@@ -301,10 +320,7 @@ static acpi_status
acpi_platformrt_space_handler(u32 function,
break;
}
- return AE_OK;
-
-invalid_guid:
- buffer->prm_status = PRM_HANDLER_GUID_NOT_FOUND;
+error:
return AE_OK;
}
