Re: [openxt-dev] Re: Follow up on libxl-fix-reboot.patch

[Rich Persaud <persaur@xxxxxxxxx>]

(adding xen-devel & toolstack devs)

On Dec 14, 2020, at 16:12, Jason Andryuk <jandryuk@xxxxxxxxx> wrote:
> 
> On Fri, Dec 11, 2020 at 3:56 PM Chris Rogers <crogers122@xxxxxxxxx> wrote:
>> 
>> This is a follow up to a request during our roadmapping meeting to clarify 
>> the purpose of libxl-fix-reboot.patch on the current version of Xen in 
>> OpenXT (4.12).  It's pretty simple.  While the domctl API does define a 
>> trigger for reset in xen/include/public/domctl.h:
>> 
> 
>> The call stack looks like this:
>>> libxl_send_trigger(ctx, domid, LIBXL_TRIGGER_RESET, 0);
>>> xc_domain_send_trigger(ctx->xch, domid, XEN_DOMCTL_SENDTRIGGER_RESET, 
>>> vcupid);
>>> do_domctl()
>>> arch_do_domctl()
>> and reaching the case statement in arch_do_domctl() for 
>> XEN_DOMCTL_sendtrigger, with RESET, we get -ENOSYS as illustrated above.
> 
> Thanks, Chris.  It's surprising that xl trigger reset exists, but
> isn't wired through to do anything.  And that reboot has a fallback
> command to something that doesn't work.
> 
> If we have to turn reboot into shutdown + start, it seems like that
> could be done in xenmgr instead of libxl.  Similarly, this may avoid
> the signaling between xenmgr and libxl.

If upstream Xen's libxl cannot support VM reset, can we drop/hide reset support 
from the OpenXT CLI and UIVM? That would avoid incurring costs for a fake 
feature with no long-term future. A reset is not the same as shutdown + start.  
If reset is not supportable, the user can perform shutdown + reboot manually. 
Then they would at least be aware of the consequences, e.g. temporary storage 
snapshots will be deleted and changes lost immediately.

OpenXT derivatives which need reset support can use another Xen toolstack which 
provides this capability, e.g. the Citrix XenServer xapi ocaml toolstack, for 
this single function.  Or the old XenClient xenops fork of xapi.

The long-term direction, based on an upstream prototype in Rust, is a low level 
toolstack daemon that accepts input over an RPC protocol that is stable and 
versioned, which will drive a stable hypercall ABI for Xen. We can ask for 
reset support to be prioritized in the Rust prototype, which would then enable 
testing of OpenXT integration.

Hopefully an upstream Xen LibXL developer will recall why the reset logic isn't 
yet fully wired up.

Rich