From 406251a408f51a5ff1b7d41a1d590b35aff5b0fa Mon Sep 17 00:00:00 2001 From: John Ernberg Date: Mon, 12 May 2025 07:14:50 +0000 Subject: [PATCH 1/4] xen: swiotlb: Wire up map_resource callback When running Xen on iMX8QXP, an Arm SoC without IOMMU, DMA performed via its eDMA v3 DMA engine fail with a mapping error. The eDMA performs DMA between RAM and MMIO space, and it's the MMIO side that cannot be mapped. MMIO->RAM DMA access cannot be bounce buffered if it would straddle a page boundary and on Xen the MMIO space is 1:1 mapped for Arm, and x86 PV Dom0. Cases where MMIO space is not 1:1 mapped, such as x86 PVH Dom0, requires an IOMMU present to deal with the mapping. Considering the above the map_resource callback can just be wired to the existing dma_direct_map_resource() function. There is nothing to do for unmap so the unmap callback is not needed. Signed-off-by: John Ernberg Reviewed-by: Stefano Stabellini Message-ID: <20250512071440.3726697-1-john.ernberg@actia.se> Signed-off-by: Juergen Gross --- drivers/xen/swiotlb-xen.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index ef56a2500ed6..da1a7d3d377c 100644 --- a/drivers/xen/swiotlb-xen.c +++ b/drivers/xen/swiotlb-xen.c @@ -426,4 +426,5 @@ const struct dma_map_ops xen_swiotlb_dma_ops = { .alloc_pages_op = dma_common_alloc_pages, .free_pages = dma_common_free_pages, .max_mapping_size = swiotlb_max_mapping_size, + .map_resource = dma_direct_map_resource, }; From d24c6b78ac550072df359c17e6aadddf079257d0 Mon Sep 17 00:00:00 2001 From: Roger Pau Monne Date: Wed, 14 May 2025 11:20:36 +0200 Subject: [PATCH 2/4] xen: enable XEN_UNPOPULATED_ALLOC as part of xen.config MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit PVH dom0 is useless without XEN_UNPOPULATED_ALLOC, as otherwise it will very likely balloon out all dom0 memory to map foreign and grant pages. Enable it by default as part of xen.config. This also requires enabling MEMORY_HOTREMOVE and ZONE_DEVICE. Signed-off-by: Roger Pau Monné Reviewed-by: Juergen Gross Message-ID: <20250514092037.28970-1-roger.pau@citrix.com> Signed-off-by: Juergen Gross --- kernel/configs/xen.config | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/configs/xen.config b/kernel/configs/xen.config index 6878b9a49be8..1875a0a5047a 100644 --- a/kernel/configs/xen.config +++ b/kernel/configs/xen.config @@ -13,6 +13,8 @@ CONFIG_SCSI=y CONFIG_FB=y CONFIG_INPUT_MISC=y CONFIG_MEMORY_HOTPLUG=y +CONFIG_MEMORY_HOTREMOVE=y +CONFIG_ZONE_DEVICE=y CONFIG_TTY=y # Technically not required but otherwise produces # pretty useless systems starting from allnoconfig @@ -47,3 +49,4 @@ CONFIG_XEN_GNTDEV=m CONFIG_XEN_GRANT_DEV_ALLOC=m CONFIG_SWIOTLB_XEN=y CONFIG_XEN_PRIVCMD=m +CONFIG_XEN_UNPOPULATED_ALLOC=y From 74287971dbb3fe322bb316afd9e7fb5807e23bee Mon Sep 17 00:00:00 2001 From: Roger Pau Monne Date: Wed, 14 May 2025 10:04:26 +0200 Subject: [PATCH 3/4] xen/x86: fix initial memory balloon target MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When adding extra memory regions as ballooned pages also adjust the balloon target, otherwise when the balloon driver is started it will populate memory to match the target value and consume all the extra memory regions added. This made the usage of the Xen `dom0_mem=,max:` command line parameter for dom0 not work as expected, as the target won't be adjusted and when the balloon is started it will populate memory straight to the 'max:' value. It would equally affect domUs that have memory != maxmem. Kernels built with CONFIG_XEN_UNPOPULATED_ALLOC are not affected, because the extra memory regions are consumed by the unpopulated allocation driver, and then balloon_add_regions() becomes a no-op. Reported-by: John Fixes: 87af633689ce ('x86/xen: fix balloon target initialization for PVH dom0') Signed-off-by: Roger Pau Monné Reviewed-by: Juergen Gross Tested-by: Marek Marczykowski-Górecki Message-ID: <20250514080427.28129-1-roger.pau@citrix.com> Signed-off-by: Juergen Gross --- drivers/xen/balloon.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 8c852807ba1c..2de37dcd7556 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -704,15 +704,18 @@ static int __init balloon_add_regions(void) /* * Extra regions are accounted for in the physmap, but need - * decreasing from current_pages to balloon down the initial - * allocation, because they are already accounted for in - * total_pages. + * decreasing from current_pages and target_pages to balloon + * down the initial allocation, because they are already + * accounted for in total_pages. */ - if (extra_pfn_end - start_pfn >= balloon_stats.current_pages) { + pages = extra_pfn_end - start_pfn; + if (pages >= balloon_stats.current_pages || + pages >= balloon_stats.target_pages) { WARN(1, "Extra pages underflow current target"); return -ERANGE; } - balloon_stats.current_pages -= extra_pfn_end - start_pfn; + balloon_stats.current_pages -= pages; + balloon_stats.target_pages -= pages; } return 0; From 7f9bbc1140ff8796230bc2634055763e271fd692 Mon Sep 17 00:00:00 2001 From: Stefano Stabellini Date: Mon, 12 May 2025 14:54:52 -0700 Subject: [PATCH 4/4] xen/arm: call uaccess_ttbr0_enable for dm_op hypercall dm_op hypercalls might come from userspace and pass memory addresses as parameters. The memory addresses typically correspond to buffers allocated in userspace to hold extra hypercall parameters. On ARM, when CONFIG_ARM64_SW_TTBR0_PAN is enabled, they might not be accessible by Xen, as a result ioreq hypercalls might fail. See the existing comment in arch/arm64/xen/hypercall.S regarding privcmd_call for reference. For privcmd_call, Linux calls uaccess_ttbr0_enable before issuing the hypercall thanks to commit 9cf09d68b89a. We need to do the same for dm_op. This resolves the problem. Cc: stable@kernel.org Fixes: 9cf09d68b89a ("arm64: xen: Enable user access before a privcmd hvc call") Signed-off-by: Stefano Stabellini Reviewed-by: Juergen Gross Message-ID: Signed-off-by: Juergen Gross --- arch/arm64/xen/hypercall.S | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/arch/arm64/xen/hypercall.S b/arch/arm64/xen/hypercall.S index 9d01361696a1..ae551b857137 100644 --- a/arch/arm64/xen/hypercall.S +++ b/arch/arm64/xen/hypercall.S @@ -83,7 +83,26 @@ HYPERCALL3(vcpu_op); HYPERCALL1(platform_op_raw); HYPERCALL2(multicall); HYPERCALL2(vm_assist); -HYPERCALL3(dm_op); + +SYM_FUNC_START(HYPERVISOR_dm_op) + mov x16, #__HYPERVISOR_dm_op; \ + /* + * dm_op hypercalls are issued by the userspace. The kernel needs to + * enable access to TTBR0_EL1 as the hypervisor would issue stage 1 + * translations to user memory via AT instructions. Since AT + * instructions are not affected by the PAN bit (ARMv8.1), we only + * need the explicit uaccess_enable/disable if the TTBR0 PAN emulation + * is enabled (it implies that hardware UAO and PAN disabled). + */ + uaccess_ttbr0_enable x6, x7, x8 + hvc XEN_IMM + + /* + * Disable userspace access from kernel once the hyp call completed. + */ + uaccess_ttbr0_disable x6, x7 + ret +SYM_FUNC_END(HYPERVISOR_dm_op); SYM_FUNC_START(privcmd_call) mov x16, x0