Re: [PATCH 1/3] xen/arm/dom0less-build: Alloc magic pages for Dom0less DomUs from hypervisor

[Henry Wang <xin.wang2@xxxxxxx>]

Hi Daniel,

On 4/30/2024 6:22 PM, Daniel P. Smith wrote:
> On 4/29/24 22:55, Henry Wang wrote:
> > Hi Daniel,
> >
> > On 4/30/2024 8:27 AM, Daniel P. Smith wrote:
> > > On 4/25/24 23:14, Henry Wang wrote:
> > > > 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
> > > > ```
> > > > This is because 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.
> > > >
> > > > To solve above issue, this commit allocates the magic pages for
> > > > Dom0less DomUs at the domain construction time. The base address/PFN
> > > > of the magic page region will be noted and communicated to the
> > > > init-dom0less application in Dom0.
> > > Might I suggest we not refer to these as magic pages? I would 
> > > consider them as hypervisor reserved pages for the VM to have access 
> > > to virtual platform capabilities. We may see this expand in the 
> > > future for some unforeseen, new capability.
> > I think magic page is a specific terminology to refer to these pages, 
> > see alloc_magic_pages() for both x86 and Arm. I will reword the last 
> > paragraph of the commit message to refer them as "hypervisor reserved 
> > pages (currently used as magic pages on Arm)" if this sounds good to 
> > you.
> I would highlight that is a term used in the toolstack, while is 
> probably not the best, there is no reason to change in there, but the 
> hypervisor does not carry that terminology. IMHO we should not 
> introduce it there and be explicit about why the pages are getting 
> reserved.
Thanks for the suggestion. I will rework the commit message.

Kind regards,
Henry

> v/r,
> dps