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.wa...@amd.com/ > > > > 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 > The init-dom0less application could then check HVM_PARAM_STORE_PFN > being set and call XS_introduce_domain. > > Note that at least C-xenstored does not need the PFN of the Xenstore > page, as it is just using GNTTAB_RESERVED_XENSTORE for mapping the > page.
