From 5232bf0535f570c673f5ab5e14a9d2284b383d5c Mon Sep 17 00:00:00 2001 From: meganz009 Date: Mon, 11 Aug 2025 14:05:39 +0800 Subject: [PATCH 1/2] riscv/kexec_file: Fix relocation type R_RISCV_ADD16 and R_RISCV_SUB16 unknown commit a39416d8597a585d62a3e80bbce9ff3b400454a3 upstream. [ Upstream commit c6ebf2c528470a09be77d0d9df2c6617ea037ac5 ] Runs on the kernel with CONFIG_RISCV_ALTERNATIVE enabled: kexec -sl vmlinux Error: kexec_image: Unknown rela relocation: 34 kexec_image: Error loading purgatory ret=-8 and kexec_image: Unknown rela relocation: 38 kexec_image: Error loading purgatory ret=-8 The purgatory code uses the 16-bit addition and subtraction relocation type, but not handled, resulting in kexec_file_load failure. So add handle to arch_kexec_apply_relocations_add(). Tested on RISC-V64 Qemu-virt, issue fixed. Co-developed-by: Petr Tesarik Signed-off-by: Petr Tesarik Signed-off-by: Ying Sun Reviewed-by: Andrew Jones Link: https://lore.kernel.org/r/20240711083236.2859632-1-sunying@isrc.iscas.ac.cn Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin --- arch/riscv/kernel/elf_kexec.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/arch/riscv/kernel/elf_kexec.c b/arch/riscv/kernel/elf_kexec.c index e60fbd8660c4..8c32bf1eedda 100644 --- a/arch/riscv/kernel/elf_kexec.c +++ b/arch/riscv/kernel/elf_kexec.c @@ -444,6 +444,12 @@ int arch_kexec_apply_relocations_add(struct purgatory_info *pi, *(u32 *)loc = CLEAN_IMM(CJTYPE, *(u32 *)loc) | ENCODE_CJTYPE_IMM(val - addr); break; + case R_RISCV_ADD16: + *(u16 *)loc += val; + break; + case R_RISCV_SUB16: + *(u16 *)loc -= val; + break; case R_RISCV_ADD32: *(u32 *)loc += val; break; -- Gitee From d2c4e74621b75b35f3602b14975d074b0642c43e Mon Sep 17 00:00:00 2001 From: meganz009 Date: Mon, 11 Aug 2025 14:08:42 +0800 Subject: [PATCH 2/2] RISC-V: ACPI: fix early_ioremap to early_memremap commit b6f95df4f7af633167e2f9588e83814dcbcca29e upstream. commit 1966db682f064172891275cb951aa8c98a0a809b upstream. When SVPBMT is enabled, __acpi_map_table() will directly access the data in DDR through the IO attribute, rather than through hardware cache consistency, resulting in incorrect data in the obtained ACPI table. The log: ACPI: [ACPI:0x18] Invalid zero length. We do not assume whether the bootloader flushes or not. We should access in a cacheable way instead of maintaining cache consistency by software. Fixes: 3b426d4b5b14 ("RISC-V: ACPI : Fix for usage of pointers in different address space") Cc: stable@vger.kernel.org Reviewed-by: Alexandre Ghiti Signed-off-by: Yunhui Cui Reviewed-by: Sunil V L Link: https://lore.kernel.org/r/20241014130141.86426-1-cuiyunhui@bytedance.com Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman --- arch/riscv/kernel/acpi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/riscv/kernel/acpi.c b/arch/riscv/kernel/acpi.c index 56cb2c986c48..07a43843368d 100644 --- a/arch/riscv/kernel/acpi.c +++ b/arch/riscv/kernel/acpi.c @@ -204,7 +204,7 @@ void __init __iomem *__acpi_map_table(unsigned long phys, unsigned long size) if (!size) return NULL; - return early_ioremap(phys, size); + return early_memremap(phys, size); } void __init __acpi_unmap_table(void __iomem *map, unsigned long size) @@ -212,7 +212,7 @@ void __init __acpi_unmap_table(void __iomem *map, unsigned long size) if (!map || !size) return; - early_iounmap(map, size); + early_memunmap(map, size); } void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) -- Gitee