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

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


  • To: Eslam Elnikety <elnikety@xxxxxxxxxx>
  • From: Jan Beulich <JBeulich@xxxxxxxx>
  • Date: Thu, 8 Aug 2019 13:27:08 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XSuD7o9lJSy1SrZ/srw3RYB44TECyFbrGOiEB5A3+so=; b=JkaysLJ6414fnqNebL3wnN3RvfyLEGgYg60t32kCXrUbtrV1jqY06ASF31I7J9j2SgQOR5WL6mQMF7k6dS86rc9BS2b41ORudAhb4nopYpfFdBy98e9UMQfEydyP3pUDQASGGKTOyvfJhD5hyviynNTJ2pEFfq3MYyhVbGZqiBBT9hDQ44eMnP4wnjsjzwpFzrpbca19sP1jcrlxxFE8fj7QzqHlOleGSrbLdPVvocY/0VT1YiAF1KQcgWLxIj8DQWb6mdNkE5zye2E07HgBfVfdWG1grF0DxOtsWW3b0PfCXq7TLjyS97YYNOqYM96ehJWX+l2oPQmfCXq8nK2Q0A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LIm8FDpmMHMHixwjwkay1Xg5/rxdStIJQUh+60K2HIjWx4paF7JpKC4Pg3xMXrEYsPCtV+tRrnhqvV4e/NUi1p00Edrx5cDyyO1Ccz5ifv5mWly3SqoC3Ht4zHYR/ObGLOcaN6D4N68mpXwdZtLvEmn2hqsP5CSbLFAq7pYTzo2AG2zQtgk+c4EN+iCgaOq2GAC9Hdh8edGMwR1AgiUAefBZY5uypfs5wWVn2Yx8Tx5SQ1byZOs+4qnGVhqLypfTwJ+4ZzvRhL9q84ZOcJVmaOWx1w9c1MBtYaAZQcWblmiMMFGqvu9kyR93n2RyHk4/y/p/CDgsgGijNUV24D9c3g==
  • Authentication-results: spf=none (sender IP is ) smtp.mailfrom=JBeulich@xxxxxxxx;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, Julien Grall <julien.grall@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, David Woodhouse <dwmw@xxxxxxxxxxxx>
  • Delivery-date: Thu, 08 Aug 2019 13:28:30 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHVTUemBo6+AevzQUaLlW2s+A9xKqbxP0SA
  • Thread-topic: [PATCH v2] evtchn: make support for different ABIs tunable

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 ...".

> --- 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
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.

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.

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

 


Rackspace

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