On 01.11.23 17:57, Andrew Cooper wrote:
On 01/11/2023 4:42 pm, Juergen Gross wrote:On 01.11.23 17:38, Andrew Cooper wrote:On 01/11/2023 9:00 am, Juergen Gross wrote:It might be perfectly fine not to have a control/shutdown Xenstore node. If this is the case, don't crash, but just terminate the shutdown thread after issuing a message that shutdown isn't available.In fini_shutdown() clearing the watch can result in an error now, in case the early exit above was taken. Just ignore this error now. Signed-off-by: Juergen Gross <[email protected]>Which cases might we not have a control/shutdown node?Xenstore-stubdom. It should _never_ shutdown, and it isn't really under control of Xen tools (other than being created).I'm all for coping better with its absence, but it's not a piece of the Xen ABI which is optional.I'd like to differ here. See reasoning above.If we're going to permit this configuration, then I think it needs an extension to xenstore-paths to make it officially optional. And I think it's reasonable to support, but I wouldn't go as far as saying "never". If you've cleaved the global xenstored in twain/trine/etc, then individual parts of it can shut down normally.
Xenstore-stubdom is a very special case. I don't think its shutdown node can be under control of the normal Xen tools, as only the stubdom can know whether it is able to react in any sensible way to it. It needs to take specific measures to ensure that even its ABI-compliant reaction to a shutdown request is visible to Xen tools (remember that this reaction is a write to the shutdown node causing a watch event in dom0, which won't work with Xenstore going down). In the end there is no way the shutdown node can be present when starting Xenstore-stubdom. There is no Xenstore at the time the node is probed in today's Mini-OS boot sequence. Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
