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

Re: [PATCH v3 3/5] xen/arm: configure dom0less domain for enabling xenstore after boot



Hi Stefano,

On 01/04/2022 01:34, Stefano Stabellini wrote:
Because (as you noted as a comment to the following patch) as soon as
d->arch.hvm.params[HVM_PARAM_STORE_PFN] is set the guest can continue
with the initialization and will expect the right data to be set on the
page.

I think you misunderstood my question. From my understanding, at the moment,
Linux would break with your proposal. So you need to modify the kernel in
order to support what you are doing.

Linux does not break with this proposal. I wrote a longer explanation
[1] some time ago.

I guess I should not have written "broken" here. But instead point out that...


In short: the master branch and any supported versions of Linux boots
fine with this proposal without changes, however it wouldn't be able to
use PV drivers when started as dom0less kernel.

To be able to use the new feature, this patch is required [2].

... without the extra patch is Linux, you would not be able to take advantage of this feature.

IOW, we have room to decide the approach here.

Xenstore protocol has a way to allow (re)connection (see
docs/mics/xenstore-ring.txt). This feature looks quite suited to what you are
trying to do here (we want to delay the connection).

The main advantage with this approach is the resources allocation for Xenstore
will be done in the place and the work in Linux could be re-used for
non-dom0less domain.

Have you explored it?

Luca (CCed) is the original author. I don't know if he explored that
approach. I have not looked into it in any details but I think there
might be challenges: in this case there is nothing on the shared page.
There are no feature bits as it has not been initialized (xenstored is
the one initializating it).
I agree there is nothing today. But here, we have the liberty to initialize the feature bits in Xen.


Keep in mind that Luca and I have done many tests on this approach, both
the Xen side, the Linux side (very many different kernel versions) and
complex configurations (both network and block PV drivers, DMA mastering
devices, etc.) If we changed approach now we would lose some of the
value of the past efforts.

I appreciate the effort you put into testing this approach. However, this is an external interface that we will consider stable as soon as the two sides (Xen and Linux) are committed. So I want to make sure we are not putting ourself in a corner.

One major issue I can forsee with your approach is the xenstore initialization seem to only works for HVM. In theory, we may have the same need for PV (e.g. in the case of Hyperlaunch).

How would your proposal work for PV guest?

Note that I now that PV guest may not work without Xenstore. But I don't see any reason why we could not start them before Xenstored.

Cheers,

--
Julien Grall



 


Rackspace

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