git: 69c47485b5f9 - main - x86/xen: use UNUSABLE e820 regions for external mappings

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);
+}