Re: [PATCH v4 8/9] tools: add example application to initialize dom0less PV drivers

[Julien Grall <julien@xxxxxxx>]

Hi Stefano,

On 06/04/2022 03:21, Stefano Stabellini wrote:
> On Fri, 1 Apr 2022, Juergen Gross wrote:
> > On 01.04.22 12:21, Julien Grall wrote:
> > > This would be a problem if Linux is still booting and hasn't yet call
> > > xenbus_probe_initcall().
> > >
> > > I understand we need to have the page setup before raising the event
> > > channel. I don't think we can allow Xenstored to set the HVM_PARAM (it may
> > > run in a domain with less privilege). So I think we may need to create a
> > > separate command to kick the client (not great).
> > >
> > > Juergen, any thoughts?
> > I think it should work like that:
> >
> > - setup the grant via xc_dom_gnttab_seed()
> > - introduce the domain to Xenstore
> > - call xc_hvm_param_set()
> >
> > When the guest is receiving the event, it should wait for the xenstore
> > page to appear.
>
> I am OK with what you wrote above, and I understand Julien's concerns
> about "waiting". Before discussing that, I would like to make sure I
> understood why setting HVM_PARAM_STORE_PFN first (before
> xs_introduce_domain) is not possible.
>
> In a previous reply to Julien I wrote that it is not a good idea to
> set HVM_PARAM_STORE_PFN in Xen before creating the domains because it
> would cause Linux to hang at boot. That is true, Linux hangs on
> drivers/xen/xenbus/xenbus_comms.c:xb_init_comms waiting on xb_waitq.
I looked at the implementation of xb_init_comms in 5.17 and I couldn't 
find out how it would block here. Can you clarify?
> It could wait a very long time as domUs are typically a lot faster than
> dom0 to boot.
>
> However, if we set HVM_PARAM_STORE_PFN before calling
> xs_introduce_domain in init-dom0less, for Linux to see it before
> xs_introduce_domain is done, Linux would need to be racing against
> init-dom0less. In that case, the wait in xb_init_comms would be minimal
> anyway. It shouldn't be a problem. There would be no "hang", just a wait
> a bit longer than usual.
From my understanding, Linux may send commands as soon as it sees 
HVM_PARAM_STORE_PFN. With your proposal, this may happen before 
xs_introduce_domain() has updated the features supported by Xenstored.
With the recent proposal from Juergen [1], an OS will need to read the 
features field to understand whether Xenstored support the extended 
version of a command.
This means, any commands sent before xs_introduce_domain() would not be 
able to take advantage of the new features. Therefore, we would need to 
wait until Xenstored has advertised the features.
With your approach, the wait would be a busy loop. Although, I am not 
entirely sure what you would be waiting on?
But if we use the 'connection status' field, then you could just delay 
the initialization until you receive an event and the connection status 
is connected.
Cheers,

[1] https://lore.kernel.org/xen-devel/20220316161017.3579-1-jgross@xxxxxxxx/

--
Julien Grall