It was reported that QEMU monitor command gva2gpa was reporting unmapped memory for a valid access (qemu-system-aarch64), during a copy from kernel to user space (__arch_copy_to_user symbol in Linux) [1]. This was affecting cpu_memory_rw_debug also, which is used in numerous places in our codebase. After investigating, the problem was specific to arm_cpu_get_phys_page_attrs_debug.
When performing user access from a privileged space, we need to do a second lookup for user mmu idx, following what get_a64_user_mem_index is doing at translation time. [1] https://lists.nongnu.org/archive/html/qemu-discuss/2025-04/msg00013.html Signed-off-by: Pierrick Bouvier <pierrick.bouv...@linaro.org> --- target/arm/ptw.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/target/arm/ptw.c b/target/arm/ptw.c index 6ea39ee5755..5b8d84d44df 100644 --- a/target/arm/ptw.c +++ b/target/arm/ptw.c @@ -3655,5 +3655,25 @@ hwaddr arm_cpu_get_phys_page_attrs_debug(CPUState *cs, vaddr addr, CPUARMState *env = &cpu->env; ARMMMUIdx mmu_idx = arm_mmu_idx(env); - return arm_cpu_get_phys_page(env, addr, attrs, mmu_idx); + hwaddr res = arm_cpu_get_phys_page(env, addr, attrs, mmu_idx); + + if (res != -1) { + return res; + } + + /* + * Memory may be accessible for an "unprivileged load/store" variant. + * In this case, get_a64_user_mem_index function generates an op using an + * unprivileged mmu idx, so we need to try with it. + */ + switch (mmu_idx) { + case ARMMMUIdx_E10_1: + case ARMMMUIdx_E10_1_PAN: + return arm_cpu_get_phys_page(env, addr, attrs, ARMMMUIdx_E10_0); + case ARMMMUIdx_E20_2: + case ARMMMUIdx_E20_2_PAN: + return arm_cpu_get_phys_page(env, addr, attrs, ARMMMUIdx_E20_0); + default: + return -1; + } } -- 2.39.5
