Re: [PATCH v3 2/4] xen/arm: Alloc XenStore page for Dom0less DomUs from hypervisor

[Julien Grall <julien@xxxxxxx>]

Hi,

On 25/05/2024 00:02, Stefano Stabellini wrote:
> On Fri, 24 May 2024, Julien Grall wrote:
> > Hi Stefano,
> >
> > On 24/05/2024 23:49, Stefano Stabellini wrote:
> > > On Fri, 24 May 2024, Julien Grall wrote:
> > > > Hi Henry,
> > > >
> > > > + Juergen as the Xenstore maintainers. I'd like his opinion on the
> > > > approach.
> > > > The documentation of the new logic is in:
> > > >
> > > > https://lore.kernel.org/xen-devel/20240517032156.1490515-5-xin.wang2@xxxxxxx/
> > > >
> > > > FWIW I am happy in principle with the logic (this is what we discussed on
> > > > the
> > > > call last week). Some comments below.
> > > >
> > > > On 17/05/2024 04:21, 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
> > > > > ```
> > > > >
> > > > > 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.
> > > > So this commit is allocating the page, but it will not be used by
> > > > init-dom0less until the next patch. But Linux could use it. So would this
> > > > break bisection? If so, then I think patch #3 needs to be folded in this
> > > > patch.
> > > I think that's fine,
> > I am not sure what you mean. Are you saying it is ok to break bisection?
> No, I meant to say that it is fine to merge on commit.
>
>
> > > I'll leave that with you on commit.
> > I am sorry but I don't think the folding should be done on commit. It should
> > happen before hand because the commit message will also need to be updated.
> Understood. I'll send one more version with the patches merged (ideally
> with an ack?)
Sorry I don't feel it is right for me to ack this patch with the pending 
questions from Juergen.
Cheers,

--
Julien Grall