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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 27 May 2024, Jürgen Groß wrote:
> On 25.05.24 01:19, Stefano Stabellini wrote:
> > On Fri, 24 May 2024, Jürgen Groß wrote:
> > > On 24.05.24 15:58, 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.
> > > 
> > > I'm not against this logic, but I'm wondering why it needs to be so
> > > complicated.
> > 
> > Actually the reason I like it is that in my view, this is the simplest
> > approach. You allocate a domain, you also allocate the xenstore page
> > together with it. Initially the xenstore connection has an
> > "uninitialized" state, as it should be. That's it. At some point, when
> > xenstored is ready, the state changes to CONNECTED.
> > 
> > 
> > > Can't the domU itself allocate the Xenstore page from its RAM pages,
> > > write the PFN into the Xenstore grant tab entry, and then make it
> > > public via setting HVM_PARAM_STORE_PFN?
> > 
> > This is not simpler in my view
> 
> Okay, fine with me. I had the impression that violating the 1:1 mapping
> of the domain would add complexity, but if you are fine with that I don't
> mind your approach.

Yes, that's fine. Thanks!