On 4/9/24 00:53, Henry Wang wrote:
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. Patch 5 is a
simple patch to do some code duplication clean-up in xc.
Hey Henry,
To help provide some perspective, these issues are not experienced with
hyperlaunch. This is because we understood early on that you cannot move
a lightweight version of the toolstack into hypervisor init and not
provide a mechanism to communicate what it did to the runtime control
plane. We evaluated the possible mechanism, to include introducing a new
hypercall op, and ultimately settled on using hypfs. The primary reason
is this information is static data that, while informative later, is
only necessary for the control plane to understand the state of the
system. As a result, hyperlaunch is able to allocate any and all special
pages required as part of domain construction and communicate their
addresses to the control plane. As for XSM, hypfs is already protected
and at this time we do not see any domain builder information needing to
be restricted separately from the data already present in hypfs.
I would like to make the suggestion that instead of continuing down this
path, perhaps you might consider adopting the hyperlaunch usage of
hypfs. Then adjust dom0less domain construction to allocate the special
pages at construction time. The original hyperlaunch series includes a
patch that provides the helper app for the xenstore announcement. And I
can provide you with updated versions if that would be helpful.
V/r,
Daniel P. Smith
