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.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 > > 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!
