Re: [PATCH v6 6/7] tools: add example application to initialize dom0less PV drivers

[Julien Grall <julien@xxxxxxx>]

Hi Stefano,

On 13/05/2022 02:09, Stefano Stabellini wrote:
> On Wed, 11 May 2022, Julien Grall wrote:
> > > +    rc = xs_introduce_domain(xsh, info->domid,
> > > +            (GUEST_MAGIC_BASE >> XC_PAGE_SHIFT) + XENSTORE_PFN_OFFSET,
> > > +            xenstore_evtchn);
> > I might be missing something here. In an ealier version, I pointed out that
> > xs_introduce_domain() would fail in the case the dom0less domain doesn't have
> > "xen,enhanced".
> >
> > AFAICT, you agreed that the (part?) of initialization should be skipped. But I
> > don't see the change in the code. Regarding the placement, we could either
> > fully skip init_domain() or just xs_introduce_domain(). The latter might be
> > better so all the domains are listed using xenstore-ls.
> >
> > So something like below should work:
> >
> > if ( xenstore_evtchn )
> > {
> >      rc = xs_introduce...();
> >      ...
> > }
> Yes, good point. xenstore_evtchn could be zero validly (first evtchn is
> zero),
Event channel 0 is always reserved when initialization the event channel 
subsystem (evtchn_init()):
evtchn_from_port(d, 0)->state = ECS_RESERVED;

> so instead I'll check on xenstore_pfn to be zero (xenstore_pfn is
> 0 for non-enhanced domUs.)
I spotted that difference but decided to not comment on it as Linux is 
already considering the values 0 and ~0 as invalid. However, I am not in 
favor on any code to rely on 0 means Xenstore will never be available 
while ~0 means that it might be available.
Anyway, as I wrote above, the event channel 0 is always reserved. So you 
can safely use this value to detect whether we allocated the event 
channel for Xenstore.
Cheers,

--
Julien Grall