Re: [Xen-devel] [PATCH v2] evtchn: make support for different ABIs tunable

["Elnikety, Eslam" <elnikety@xxxxxxxxxx>]

Hi Jan,

On 8. Aug 2019, at 15:27, Jan Beulich <JBeulich@xxxxxxxx> wrote:

On 07.08.2019 19:42, Eslam Elnikety wrote:

Support for FIFO event channel ABI was first introduced in Xen 4.4
(see 88910061ec6). Make this support tunable, since the choice of which
event channel ABI has implications for hibernation. Consider resuming a
pre Xen 4.4 hibernated Linux guest. During resume from hibernation, there
are two kernels involved: the "boot" kernel and the "resume" kernel. The
guest boot kernel defaults to FIFO ABI and instructs Xen via an
EVTCHNOP_init_control to switch from 2L to FIFO.

This should only be "may default to" - there's nothing making this
to be the case unconditionally afaict. Another option would be to
start the sentence "If the guest boot kernel defaults …".

Correct. v3 will use “If the guest book kernel defaults … “.

--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1170,6 +1170,11 @@ long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)

     case EVTCHNOP_init_control: {
         struct evtchn_init_control init_control;
+
+        /* Fail init_control for domains that must use 2l ABI */
+        if ( current->domain->options & XEN_DOMCTL_CDF_disable_fifo )
+            return -EPERM;
+
         if ( copy_from_guest(&init_control, arg, 1) != 0 )
             return -EFAULT;
         rc = evtchn_fifo_init_control(&init_control);

I think the check would better go into evtchn_fifo_init_control(),
at least as long as the setting really is FIFO-centric. Also the

Not sure. It is the FIFO ABI that defines EVTCHNOP_init_control (not defined in 2L). Short-circuiting the hypercall at this place seems more appropriate. Moreover, doing copy_from_guest and calling into evtchn_fifo_init_control only to return error is not optimal.

comment will become stale the moment a 3rd evtchn mechanism appears
- it shouldn't mention 2L as the setting isn't "2-level only". Then
again you may actually want it to behave like this, and hence be
named accordingly.

Correct. Will reword the comment to: /* Fail init_control for domains that cannot use FIFO ABI */

Irrespective of these remarks, and along the lines of comments on
the v1 thread, introducing wider control that would also allow
disabling 2-level (for HVM guests) would seem better to me. This
would then hopefully be coded up in a way that would make extending
it straightforward, once a 3rd mechanism appears.

Hmmm... we cannot force guests to call init_control (in order to flip from 2L to FIFO). Quoting from [1] 4.4 “If this call (EVTCHNOP_init_control) fails on the boot VCPU, the guest should continue to use the 2-level event channel ABI for all VCPUs.” Support for 2L ABI does not sound like something that can be optional. Once a 3rd mechanism appears, I imagine adding a corresponding domctl flag to control such mechanism.

[1] https://xenbits.xenproject.org/people/dvrabel/event-channels-F.pdf

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel