[PATCH v3 0/4] DOMCTL-based guest magic region allocation for 11 domUs

Henry Wang posted 4 patches 1 month ago
Patches applied successfully (tree, apply log)
git fetch https://gitlab.com/xen-project/patchew/xen tags/patchew/20240403081626.375313-1-xin.wang2@amd.com
There is a newer version of this series
tools/helpers/init-dom0less.c            |  36 +++++--
tools/include/xenctrl.h                  |   4 +
tools/libs/ctrl/xc_domain.c              |  33 ++++++
xen/arch/arm/dom0less-build.c            |  11 ++
xen/arch/arm/domain.c                    |  15 +++
xen/arch/arm/domain_build.c              | 131 +++++++++++++++--------
xen/arch/arm/domctl.c                    |  32 +++++-
xen/arch/arm/include/asm/domain.h        |   8 ++
xen/arch/arm/include/asm/domain_build.h  |   4 +
xen/arch/arm/include/asm/setup.h         |   5 +
xen/arch/arm/include/asm/static-memory.h |   7 ++
xen/arch/arm/static-memory.c             |  39 +++++++
xen/common/memory.c                      |  22 +++-
xen/include/public/arch-arm.h            |  11 ++
xen/include/public/domctl.h              |  27 +++++
xen/include/public/memory.h              |   5 +
xen/include/xen/mm.h                     |   7 ++
17 files changed, 339 insertions(+), 58 deletions(-)
[PATCH v3 0/4] DOMCTL-based guest magic region allocation for 11 domUs
Posted by Henry Wang 1 month ago
An error message can seen from the init-dom0less application on
direct-mapped 1:1 domains:
```
Allocating magic pages
memory.c:238:d0v0 mfn 0x39000 doesn't belong to d1
Error on alloc magic pages
```

This is because populate_physmap() automatically assumes gfn == mfn
for direct mapped domains. This cannot be true for the magic pages
that are allocated later for 1:1 Dom0less DomUs from the init-dom0less
helper application executed in Dom0. For domain using statically
allocated memory but not 1:1 direct-mapped, similar error "failed to
retrieve a reserved page" can be seen as the reserved memory list
is empty at that time.

This series tries to fix this issue using a DOMCTL-based approach,
because for 1:1 direct-mapped domUs, we need to avoid the RAM regions
and inform the toolstack about the region found by hypervisor for
mapping the magic pages. Patch 1 introduced a new DOMCTL to get the
guest memory map, currently only used for the magic page regions.
Patch 2 generalized the extended region finding logic so that it can
be reused for other use cases such as finding 1:1 domU magic regions.
Patch 3 uses the same approach as finding the extended regions to find
the guest magic page regions for direct-mapped DomUs. Patch 4 avoids
hardcoding all base addresses of guest magic region in the init-dom0less
application by consuming the newly introduced DOMCTL.

Gitlab pipeline for this series:
https://gitlab.com/xen-project/people/henryw/xen/-/pipelines/1238005196

Henry Wang (4):
  xen/domctl, tools: Introduce a new domctl to get guest memory map
  xen/arm: Generalize the extended region finding logic
  xen/arm: Find unallocated spaces for magic pages of direct-mapped domU
  xen/memory, tools: Avoid hardcoding GUEST_MAGIC_BASE in init-dom0less

 tools/helpers/init-dom0less.c            |  36 +++++--
 tools/include/xenctrl.h                  |   4 +
 tools/libs/ctrl/xc_domain.c              |  33 ++++++
 xen/arch/arm/dom0less-build.c            |  11 ++
 xen/arch/arm/domain.c                    |  15 +++
 xen/arch/arm/domain_build.c              | 131 +++++++++++++++--------
 xen/arch/arm/domctl.c                    |  32 +++++-
 xen/arch/arm/include/asm/domain.h        |   8 ++
 xen/arch/arm/include/asm/domain_build.h  |   4 +
 xen/arch/arm/include/asm/setup.h         |   5 +
 xen/arch/arm/include/asm/static-memory.h |   7 ++
 xen/arch/arm/static-memory.c             |  39 +++++++
 xen/common/memory.c                      |  22 +++-
 xen/include/public/arch-arm.h            |  11 ++
 xen/include/public/domctl.h              |  27 +++++
 xen/include/public/memory.h              |   5 +
 xen/include/xen/mm.h                     |   7 ++
 17 files changed, 339 insertions(+), 58 deletions(-)

-- 
2.34.1