[RFC PATCH 0/3] Add handling of extended regions (safe ranges) on Arm (Was "xen/memory: Introduce a hypercall to provide unallocated space")

Oleksandr Tyshchenko posted 3 patches 2 weeks, 4 days ago
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(-)

[RFC PATCH 0/3] Add handling of extended regions (safe ranges) on Arm (Was "xen/memory: Introduce a hypercall to provide unallocated space")

Posted by Oleksandr Tyshchenko 2 weeks, 4 days ago
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(-)

-- 
2.7.4


Re: [RFC PATCH 0/3] Add handling of extended regions (safe ranges) on Arm (Was "xen/memory: Introduce a hypercall to provide unallocated space")

Posted by Oleksandr 2 weeks, 1 day ago
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(-)
>
-- 
Regards,

Oleksandr Tyshchenko


Re: [RFC PATCH 0/3] Add handling of extended regions (safe ranges) on Arm (Was "xen/memory: Introduce a hypercall to provide unallocated space")

Posted by Oleksandr 2 weeks, 1 day ago
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/


-- 
Regards,

Oleksandr Tyshchenko