| Message ID | 1631034578-12598-1-git-send-email-olekstysh@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add handling of extended regions (safe ranges) on Arm (Was "xen/memory: Introduce a hypercall to provide unallocated space") | expand |
Hello all On 07.09.21 20:09, Oleksandr Tyshchenko wrote: > From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> > > You can find an initial discussion at [1]. > > 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. > > The extended regions are calculated differently for direct mapped > Dom0 (with and without IOMMU) and non-direct mapped DomUs. > > Please note the following limitations: > - The extended region feature is only supported for 64-bit domain. > - The ACPI case is not covered. > > Also please note that we haven't figured out yet how to properly > extend the Xen hypervisor device-tree bindings on Arm (either via new > compatible or via new property). I decided to go with new property > for now, but this can be changed. This uncertainty is the main reason > why this series is marked as RFC. Sorry, I messed up the device tree binding's purpose here. New DT property "extended-region" (to inform guest about the presence of additional regions in "reg" property) is not really needed. Guest can simply infer that from the number of regions in "reg" property (region 0 - reserved for grant table space, regions 1...n - extended regions). Instead, new compatible/property will be needed (but only after this patch [1] or alternative goes in) to indicate that "region 0 is safe to use". Until this patch is merged it is not safe to use extended regions for the grant table space. Thanks to Julien for clarifying these bits. I am going to remove the advertisement of unneeded "extended-region" property in the code and send new version soon. [1] https://lore.kernel.org/xen-devel/1631228688-30347-1-git-send-email-olekstysh@gmail.com/ > > Patch series is also available at [2]. > > The corresponding Linux changes is not in a good shape now (require > some cleanup and refactoring), I will publish them once put them > in order (I hope, it will be in a few days). > > [1] https://lore.kernel.org/xen-devel/1627489110-25633-1-git-send-email-olekstysh@gmail.com/ > [2] https://github.com/otyshchenko1/xen/commits/map_opt_ml2 > > Oleksandr Tyshchenko (3): > xen: Introduce "gpaddr_bits" field to XEN_SYSCTL_physinfo > xen/arm: Add handling of extended regions for Dom0 > toolstack/arm: Add handling of extended regions for DomU > > tools/include/libxl.h | 7 ++ > tools/libs/light/libxl.c | 2 + > tools/libs/light/libxl_arm.c | 92 +++++++++++++++- > tools/libs/light/libxl_types.idl | 2 + > xen/arch/arm/domain_build.c | 233 ++++++++++++++++++++++++++++++++++++++- > xen/arch/arm/sysctl.c | 2 + > xen/arch/x86/sysctl.c | 2 + > xen/include/public/sysctl.h | 3 +- > 8 files changed, 338 insertions(+), 5 deletions(-) >
Hello all On 10.09.21 02:20, Oleksandr wrote: > > Hello all > > On 07.09.21 20:09, Oleksandr Tyshchenko wrote: >> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> >> >> You can find an initial discussion at [1]. >> >> 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. >> >> The extended regions are calculated differently for direct mapped >> Dom0 (with and without IOMMU) and non-direct mapped DomUs. >> >> Please note the following limitations: >> - The extended region feature is only supported for 64-bit domain. >> - The ACPI case is not covered. >> >> Also please note that we haven't figured out yet how to properly >> extend the Xen hypervisor device-tree bindings on Arm (either via new >> compatible or via new property). I decided to go with new property >> for now, but this can be changed. This uncertainty is the main reason >> why this series is marked as RFC. > > Sorry, I messed up the device tree binding's purpose here. > > New DT property "extended-region" (to inform guest about the presence > of additional regions in "reg" property) is not really needed. Guest > can simply infer that from the number of regions > in "reg" property (region 0 - reserved for grant table space, regions > 1...n - extended regions). > Instead, new compatible/property will be needed (but only after this > patch [1] or alternative goes in) to indicate that "region 0 is safe > to use". Until this patch is merged it is > not safe to use extended regions for the grant table space. > > Thanks to Julien for clarifying these bits. > > I am going to remove the advertisement of unneeded "extended-region" > property in the code and send new version soon. I have just pushed new version [1]. Please ignore this one. Sorry for the inconvenience. [1] https://lore.kernel.org/xen-devel/1631297924-8658-1-git-send-email-olekstysh@gmail.com/
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> You can find an initial discussion at [1]. 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. The extended regions are calculated differently for direct mapped Dom0 (with and without IOMMU) and non-direct mapped DomUs. Please note the following limitations: - The extended region feature is only supported for 64-bit domain. - The ACPI case is not covered. Also please note that we haven't figured out yet how to properly extend the Xen hypervisor device-tree bindings on Arm (either via new compatible or via new property). I decided to go with new property for now, but this can be changed. This uncertainty is the main reason why this series is marked as RFC. Patch series is also available at [2]. The corresponding Linux changes is not in a good shape now (require some cleanup and refactoring), I will publish them once put them in order (I hope, it will be in a few days). [1] https://lore.kernel.org/xen-devel/1627489110-25633-1-git-send-email-olekstysh@gmail.com/ [2] https://github.com/otyshchenko1/xen/commits/map_opt_ml2 Oleksandr Tyshchenko (3): xen: Introduce "gpaddr_bits" field to XEN_SYSCTL_physinfo xen/arm: Add handling of extended regions for Dom0 toolstack/arm: Add handling of extended regions for DomU tools/include/libxl.h | 7 ++ tools/libs/light/libxl.c | 2 + tools/libs/light/libxl_arm.c | 92 +++++++++++++++- tools/libs/light/libxl_types.idl | 2 + xen/arch/arm/domain_build.c | 233 ++++++++++++++++++++++++++++++++++++++- xen/arch/arm/sysctl.c | 2 + xen/arch/x86/sysctl.c | 2 + xen/include/public/sysctl.h | 3 +- 8 files changed, 338 insertions(+), 5 deletions(-)