From: David Vrabel <david.vrabel@citrix.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>, xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
Andrew Jones <drjones@redhat.com>,
Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [PATCH] evtchn: make EVTCHNOP_reset suitable for kexec
Date: Mon, 28 Jul 2014 13:36:13 +0100 [thread overview]
Message-ID: <53D643BD.6050601@citrix.com> (raw)
In-Reply-To: <1406303329-21724-1-git-send-email-vkuznets@redhat.com>
On 25/07/14 16:48, Vitaly Kuznetsov wrote:
> It would be nice to allow guests to close all event channels in
> ABI-agnostic way on startup. This would allow a guest to perform
> full cleanup in case of kexec/kdump. EVTCHNOP_reset looks suitable
> for this purpose. However it has two issues:
>
> - current implementation unconditionally closes all event channels
> including store/console channels mapped to Dom0. There is no way
> for a guest to restore these channels after they were closed.
>
> - control blocks for vcpus need cleanup when FIFO ABI is being used.
>
> With this change a guest can simply do EVTCHNOP_reset before its
> init in both 2-level and FIFO cases. Unfortunately we'll need to
> put something like "xen_version >= 4.5" check before doing it as
> if we do it with the old implementation the guest will get stuck.
>
> The issue can also be solved by introducing a new EVTCHNOP
> operation but it seems that EVTCHNOP_reset was originally designed
> for such reset and it's not being used at this moment.
[...]
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -944,6 +944,7 @@ static long evtchn_reset(evtchn_reset_t *r)
> {
> domid_t dom = r->dom;
> struct domain *d;
> + struct evtchn *chn;
> int i, rc;
>
> d = rcu_lock_domain_by_any_id(dom);
> @@ -954,8 +955,20 @@ static long evtchn_reset(evtchn_reset_t *r)
> if ( rc )
> goto out;
>
> - for ( i = 0; port_is_valid(d, i); i++ )
> - (void)__evtchn_close(d, i);
> + for ( i = 1; port_is_valid(d, i); i++ )
> + {
> + /*
> + * Leave all interdomain connections to Dom0 untouched as we need to
> + * preserve store/console channels.
> + */
> + chn = evtchn_from_port(d, i);
> + if ( chn->state != ECS_INTERDOMAIN ||
> + chn->u.interdomain.remote_dom->domain_id != 0 )
> + (void)__evtchn_close(d, i);
I don't think we want to special case certain event channels in Xen like
this -- this will need to be in the guest or toolstack (probably the guest).
> + }
> +
> + if (d->evtchn_fifo)
> + evtchn_fifo_destroy(d);
I don't think it is safe to call evtchn_fifo_destroy() while there are
any event channels bound to the domain since another domain may be
simultaneously raising the event and it does so while holding a
different lock.
It would also need to consider the pending state of any bound event
channels and ensure they are marked pending in the 2-level bitmap, so
that events are not lost.
There is also the question of what to do with a bound event channel with
a port number greater than 4095 (or 1023 for a 32-bit x86 VM).
I think these three reasons means it is only safe to switch back to
2-level if no event channels are bound.
I think the guest can rebind the XenStore and console event channels
itself, after having done the reset. It will need to query Xen prior to
the reset to find the other end of the two event channels.
David
prev parent reply other threads:[~2014-07-28 12:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-25 15:48 [PATCH] evtchn: make EVTCHNOP_reset suitable for kexec Vitaly Kuznetsov
2014-07-25 15:58 ` Andrew Cooper
2014-07-25 16:25 ` Vitaly Kuznetsov
2014-07-25 17:06 ` Andrew Cooper
2014-07-28 6:24 ` Jan Beulich
2014-07-25 16:09 ` Jan Beulich
2014-07-25 16:16 ` Andrew Cooper
2014-07-25 16:23 ` Andrew Cooper
2014-07-28 6:18 ` Jan Beulich
2014-07-25 16:38 ` Vitaly Kuznetsov
2014-07-28 9:26 ` Ian Campbell
2014-07-28 12:36 ` David Vrabel [this message]
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=53D643BD.6050601@citrix.com \
--to=david.vrabel@citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=drjones@redhat.com \
--cc=vkuznets@redhat.com \
--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).