mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 10:11:27 +01:00
Oleksandr Tyshchenko
b6fe410936
The extended region (safe range) is a region of guest physical address space which is unused and could be safely used to create grant/foreign mappings instead of wasting real RAM pages from the domain memory for establishing these mappings. The extended regions are chosen at the domain creation time and advertised to it via "reg" property under hypervisor node in the guest device-tree. As region 0 is reserved for grant table space (always present), the indexes for extended regions are 1...N. If extended regions could not be allocated for some reason, Xen doesn't fail and behaves as usual, so only inserts region 0. Please note the following limitations: - The extended region feature is only supported for 64-bit domain currently. - The ACPI case is not covered. *** As Dom0 is direct mapped domain on Arm (e.g. MFN == GFN) the algorithm to choose extended regions for it is different in comparison with the algorithm for non-direct mapped DomU. What is more, that extended regions should be chosen differently whether IOMMU is enabled or not. Provide RAM not assigned to Dom0 if IOMMU is disabled or memory holes found in host device-tree if otherwise. Make sure that extended regions are 2MB-aligned and located within maximum possible addressable physical memory range. The minimum size of extended region is 64MB. The maximum number of extended regions is 128, which is an artificial limit to minimize code changes (we reuse struct meminfo to describe extended regions, so there are an array field for 128 elements). It worth mentioning that unallocated memory solution (when the IOMMU is disabled) will work safely until Dom0 is able to allocate memory outside of the original range. Also introduce command line option to be able to globally enable or disable support for extended regions for Dom0 (enabled by default). Suggested-by: Julien Grall <jgrall@amazon.com> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> Reviewed-by: Luca Fancellu <luca.fancellu@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>