Re: [PATCH v4 4/5] xen/memory, tools: Avoid hardcoding GUEST_MAGIC_BASE in init-dom0less

[Henry Wang <xin.wang2@xxxxxxx>]

Hi Jan,

On 4/19/2024 2:18 PM, Jan Beulich wrote:
> On 19.04.2024 04:31, Henry Wang wrote:
> > On 4/18/2024 8:54 PM, Jan Beulich wrote:
> > > On 09.04.2024 06:53, Henry Wang wrote:
> > > > --- a/xen/include/public/memory.h
> > > > +++ b/xen/include/public/memory.h
> > > > @@ -21,6 +21,7 @@
> > > >    #define XENMEM_increase_reservation 0
> > > >    #define XENMEM_decrease_reservation 1
> > > >    #define XENMEM_populate_physmap     6
> > > > +#define XENMEM_populate_physmap_heap_alloc 29
> > > Without a comment, how is one supposed to know what the difference is of
> > > this new sub-op compared to the "normal" one? I actually wonder whether
> > > referring to a Xen internal (allocation requested to come from the heap)
> > > is actually a good idea here. I'm inclined to suggest to name this after
> > > the purpose it has from the guest or tool stack perspective.
> > >
> > > Speaking of which: Is this supposed to be guest-accessible, or is it
> > > intended for tool-stack use only (I have to admit I don't even know where
> > > init-dom0less actually runs)? In the latter case that also wants enforcing.
> > > This may require an adjustment to the XSM hook in use here. Cc-ing Daniel
> > > for possible advice.
> > This sub-op should be called by the init-dom0less application (toolstack
> > side), which runs in Dom0.
> I'm puzzled: How can init-dom0less (note its name!) run in Dom0, when there
> is none?
[1] is the original patch that introduced this application (More details 
can be found in the cover letter of the original series of [1]). I think 
the use case for this application is to make dom0less domains to use the 
PV driver when dom0 and dom0less domUs exist at the same time. There 
used to be a discussion regarding the naming confusion, see [2] commit 
message, but I cannot remember if this discussion has settled or not.
[1] 
https://lore.kernel.org/xen-devel/20220505001656.395419-6-sstabellini@xxxxxxxxxx/
[2] 
https://lore.kernel.org/xen-devel/20230630091210.3742121-1-luca.fancellu@xxxxxxx/
Kind regards,
Henry

> Jan
>
> > Daniel has proposed an alternative solution
> > which is based on the hypfs. If we decide to go that route, I think I
> > will rewrite the series. I will wait for the discussion settled. Thanks
> > for looping in Daniel!
> >
> > Kind regards,
> > Henry