git: 69c47485b5f9 - main - x86/xen: use UNUSABLE e820 regions for external mappings
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 30 Jul 2024 07:57:12 UTC
The branch main has been updated by royger: URL: https://cgit.FreeBSD.org/src/commit/?id=69c47485b5f9609c32269523a704d1ad0c638a30 commit 69c47485b5f9609c32269523a704d1ad0c638a30 Author: Roger Pau Monné <royger@FreeBSD.org> AuthorDate: 2024-02-15 10:42:17 +0000 Commit: Roger Pau Monné <royger@FreeBSD.org> CommitDate: 2024-07-30 07:41:17 +0000 x86/xen: use UNUSABLE e820 regions for external mappings Using holes in the memory map to create external mappings (for example grants or foreign maps) can be dangerous, as the guest might not have enough knowledge of whether such holes are maybe MMIO of some devices. Workaround this by using UNUSABLE e820 ranges as scratch space for external mappings. The e820 memory map provided to dom0 is based on the native one, but since PVH dom0 uses second stage translation, the UNUSABLE ranges on the host memory map doesn't affect it, and we can also guarantee no device MMIO uses those. Additionally, any RAM in the e820 not available to dom0 because dom0 memory has been limited on the command line, or because those are in use by Xen, are converted to UNUSABLE in the dom0 memory map. Note that domU don't usually have UNUSABLE ranges in their memory maps, and hence the logic introduced here won't help in avoiding conflicts with MMIO regions. However the usage of external mappings on domUs is in general limited, and the logic introduced here simply won't be helpful to them, but won't regress the current state. Sponsored by: Cloud Software Group MFC after: 1 week Differential revision: https://reviews.freebsd.org/D46123 --- sys/x86/xen/hvm.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/sys/x86/xen/hvm.c b/sys/x86/xen/hvm.c index 22f070213f9b..d2ab1c32b0a2 100644 --- a/sys/x86/xen/hvm.c +++ b/sys/x86/xen/hvm.c @@ -47,6 +47,7 @@ #include <machine/cpu.h> #include <machine/md_var.h> #include <machine/metadata.h> +#include <machine/pc/bios.h> #include <machine/smp.h> #include <x86/apicreg.h> @@ -548,3 +549,52 @@ xen_has_iommu_maps(void) return (regs[0] & XEN_HVM_CPUID_IOMMU_MAPPINGS); } + +int +xen_arch_init_physmem(device_t dev, struct rman *mem) +{ + static struct bios_smap smap[128]; + struct xen_memory_map memmap = { + .nr_entries = nitems(smap), + }; + unsigned int i; + int error; + + set_xen_guest_handle(memmap.buffer, smap); + error = HYPERVISOR_memory_op(XENMEM_memory_map, &memmap); + if (error != 0) + return (error); + + /* + * Fill with UNUSABLE regions, as it's always fine to use those for + * foreign mappings, they will never be populated. + */ + for (i = 0; i < memmap.nr_entries; i++) { + const vm_paddr_t max_phys = cpu_getmaxphyaddr(); + vm_paddr_t start, end; + + if (smap[i].type != SMAP_TYPE_ACPI_ERROR) + continue; + + start = round_page(smap[i].base); + /* In 32bit mode we possibly need to truncate the addresses. */ + end = MIN(trunc_page(smap[i].base + smap[i].length) - 1, + max_phys); + + if (start >= end) + continue; + + if (bootverbose != 0) + device_printf(dev, + "scratch mapping region @ [%016jx, %016jx]\n", + start, end); + + error = rman_manage_region(mem, start, end); + if (error != 0) + device_printf(dev, + "unable to add scratch region [%016jx, %016jx]: %d\n", + start, end, error); + } + + return (0); +}