xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Eslam Elnikety <elnikety@amazon.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Julien Grall <julien.grall@arm.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	xen-devel@lists.xenproject.org,
	David Woodhouse <dwmw@amazon.co.uk>
Subject: Re: [Xen-devel] [PATCH] evtchn: make support for different ABIs tunable
Date: Wed, 7 Aug 2019 16:35:22 +0200	[thread overview]
Message-ID: <36fedb78-e68a-60f8-f14c-387e720c4975@suse.com> (raw)
In-Reply-To: <20190807112024.19480-1-elnikety@amazon.com>

On 07.08.2019 13:20, Eslam Elnikety wrote:
> Adding 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. The guest boot kernel defaults to FIFO
> ABI, whereas the resume kernel assumes 2L. This, in turn, results in Xen
> and the resumed kernel talking past each other (due to different protocols
> FIFO vs 2L).
> 
> In order to announce to guests that the event channel ABI does not support
> FIFO, the hypervisor returns ENOSYS on init_control operation. When this
> operation fails, the guest should continue to use the 2L event channel ABI.
> For example, in Linux drivers/xen/events/events_base.c:
> 
>      if (fifo_events)
>          ret = xen_evtchn_fifo_init();
>      if (ret < 0)
>          xen_evtchn_2l_init();
> 
> and xen_evtchn_fifo_init fails when EVTCHNOP_init_control fails. This commit
> does not change the current default behaviour: announce FIFO event channels
> ABI support for guests unless explicitly stated otherwise at domaincreate.
> 
> Signed-off-by: Eslam Elnikety <elnikety@amazon.com>

Seeing that there looks to form agreement that restricting evtchn
variants just like gnttab ones is wanted (I'm still not really
convinced it is the right approach for the problem at hand, but I
do agree having such control may be helpful in general), a few
remarks on the patch itself:

> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -444,6 +444,9 @@ struct domain *domain_create(domid_t domid,
>           d->controller_pause_count = 1;
>           atomic_inc(&d->pause_count);
>   
> +        if ( d->options & XEN_DOMCTL_CDF_disable_fifo )
> +            d->disable_evtchn_fifo = 1;

This wants to be "true".

> --- 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->disable_evtchn_fifo )
> +            return -ENOSYS;

ENOSYS is not an appropriate error code here. EOPNOTSUPP might
be, and I guess there are more options (like EPERM or EACCES).

> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -338,6 +338,7 @@ struct domain
>      struct evtchn  **evtchn_group[NR_EVTCHN_GROUPS]; /* all other buckets */
>      unsigned int     max_evtchns;     /* number supported by ABI */
>      unsigned int     max_evtchn_port; /* max permitted port number */
> +    bool             disable_evtchn_fifo;            /* force 2l ABI */
>      unsigned int     valid_evtchns;   /* number of allocated event channels */
>      spinlock_t       event_lock;
>      const struct evtchn_port_ops *evtchn_port_ops;

I suppose you can find a better place to put this 1-byte field
than between two 32-bit ones, leaving a 3-byte hole.

Jan

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

  parent reply	other threads:[~2019-08-07 14:35 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-07 11:20 [Xen-devel] [PATCH] evtchn: make support for different ABIs tunable Eslam Elnikety
2019-08-07 11:40 ` Andrew Cooper
2019-08-07 12:04   ` Woodhouse, David
2019-08-07 12:18     ` Jan Beulich
2019-08-07 12:24     ` Andrew Cooper
2019-08-07 12:07   ` Elnikety, Eslam
2019-08-07 12:20     ` Jan Beulich
2019-08-07 13:27       ` Elnikety, Eslam
2019-08-07 12:30     ` Andrew Cooper
2019-08-07 13:01       ` Elnikety, Eslam
2019-08-07 13:41 ` Andrew Cooper
2019-08-07 14:30   ` Jan Beulich
2019-08-07 15:00     ` Andrew Cooper
2019-08-07 15:08       ` Jan Beulich
2019-08-07 15:57         ` Andrew Cooper
2019-08-07 16:03           ` Jan Beulich
2019-08-14 12:51             ` George Dunlap
2019-08-14 13:02               ` Andrew Cooper
2019-08-19 12:16                 ` Eslam Elnikety
2019-08-07 15:43   ` Elnikety, Eslam
2019-08-07 14:35 ` Jan Beulich [this message]
2019-08-07 14:41   ` Julien Grall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=36fedb78-e68a-60f8-f14c-387e720c4975@suse.com \
    --to=jbeulich@suse.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=dwmw@amazon.co.uk \
    --cc=elnikety@amazon.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=julien.grall@arm.com \
    --cc=konrad.wilk@oracle.com \
    --cc=sstabellini@kernel.org \
    --cc=tim@xen.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).