[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.