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.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. > > > > > > 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?)
