[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. I agree there is nothing today. But here, we have the liberty to initialize the feature bits in Xen.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). 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |