On 07/02/2025 02:53, Stefano Stabellini wrote: > From: Henry Wang <xin.wa...@amd.com> > > There are use cases (for example using the PV driver) in Dom0less > setup that require Dom0less DomUs start immediately with Dom0, but > initialize XenStore later after Dom0's successful boot and call to > the init-dom0less application. > > An error message can seen from the init-dom0less application on > 1:1 direct-mapped domains: > ``` > Allocating magic pages > memory.c:238:d0v0 mfn 0x39000 doesn't belong to d1 > Error on alloc magic pages > ``` > > The "magic page" is a terminology used in the toolstack as reserved > pages for the VM to have access to virtual platform capabilities. > Currently the magic pages for Dom0less DomUs are populated by the > init-dom0less app through populate_physmap(), and populate_physmap() > automatically assumes gfn == mfn for 1:1 direct mapped domains. This > cannot be true for the magic pages that are allocated later from the > init-dom0less 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. > > Since for init-dom0less, the magic page region is only for XenStore. > To solve above issue, this commit allocates the XenStore page for > Dom0less DomUs at the domain construction time. The PFN will be > noted and communicated to the init-dom0less application executed > from Dom0. To keep the XenStore late init protocol, set the connection > status to XENSTORE_RECONNECT. > > Since the guest magic region allocation from init-dom0less is for > XenStore, and the XenStore page is now allocated from the hypervisor, > instead of hardcoding the guest magic pages region, use > xc_hvm_param_get() to get the XenStore page PFN. Rename alloc_xs_page() > to get_xs_page() to reflect the changes. > > With this change, some existing code is not needed anymore, including: > (1) The definition of the XenStore page offset. > (2) Call to xc_domain_setmaxmem() and xc_clear_domain_page() as we > don't need to set the max mem and clear the page anymore. > (3) Foreign mapping of the XenStore page, setting of XenStore interface > status and HVM_PARAM_STORE_PFN from init-dom0less, as they are set > by the hypervisor. > > Take the opportunity to do some coding style improvements when possible. > > Reported-by: Alec Kwapis <alec.kwa...@medtronic.com> > Signed-off-by: Henry Wang <xin.wa...@amd.com> > Signed-off-by: Stefano Stabellini <stefano.stabell...@amd.com> Reviewed-by: Michal Orzel <michal.or...@amd.com>
I tested all 3 configurations: regular domU and static mem domU w\o direct map: Tested-by: Michal Orzel <michal.or...@amd.com> ~Michal
