From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Jones <drjones@redhat.com>,
Ian Campbell <Ian.Campbell@citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
David Vrabel <david.vrabel@citrix.com>,
Jan Beulich <JBeulich@suse.com>
Subject: [PATCH v3 1/1] evtchn: make EVTCHNOP_reset suitable for kexec
Date: Wed, 30 Jul 2014 18:28:05 +0200 [thread overview]
Message-ID: <1406737685-3686-2-git-send-email-vkuznets@redhat.com> (raw)
In-Reply-To: <1406737685-3686-1-git-send-email-vkuznets@redhat.com>
It would be nice to allow guests to close all event channels in
ABI-agnostic way in case of kexec/kdump. EVTCHNOP_reset looks suitable
for this purpose. However control blocks for vcpus and event array need
cleanup when FIFO ABI is being used.
With this change a guest can simply do EVTCHNOP_reset before kexec in
both 2-level and FIFO cases. It is also important to perform store/console
channel remapping after such call.
The issue can also be solved by introducing a new EVTCHNOP operation but
it seems that EVTCHNOP_reset can be reused.
[The idea was suggested by Ian Campbell, Andrew Cooper, and David Vrabel]
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
Changes from v2:
- use d->event_lock when switching ABI [David Vrabel]
- add documentation to xen/include/public/event_channel.h [David Vrabel]
- check for 'dom == DOMID_SELF' instead of 'd == current->domain' to
allow guests use unaltered behavior [Jan Beulich]
Changes from v1:
- Change EVTCHNOP_reset behavior when it is being called by the guest
with DOMID_SELF only [Andrew Cooper, Jan Beulich].
- Do not skip interdomain store/console channels, let the guest rebind
them [David Vrabel].
- Do evtchn_2l_init() after evtchn_fifo_destroy() so the guest can
perform e.g. EVTCHNOP_bind_interdomain operations after EVTCHNOP_reset.
---
xen/common/event_channel.c | 15 +++++++++++++++
xen/common/event_fifo.c | 1 +
xen/include/public/event_channel.h | 4 ++++
3 files changed, 20 insertions(+)
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index db952af..a7becae 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -957,6 +957,21 @@ static long evtchn_reset(evtchn_reset_t *r)
for ( i = 0; port_is_valid(d, i); i++ )
(void)__evtchn_close(d, i);
+ spin_lock(&d->event_lock);
+
+ if ( (dom == DOMID_SELF) && d->evtchn_fifo )
+ {
+ /*
+ * Guest domain called EVTCHNOP_reset with DOMID_SELF, destroying
+ * FIFO event array and control blocks, resetting evtchn_port_ops to
+ * evtchn_port_ops_2l.
+ */
+ evtchn_fifo_destroy(d);
+ evtchn_2l_init(d);
+ }
+
+ spin_unlock(&d->event_lock);
+
rc = 0;
out:
diff --git a/xen/common/event_fifo.c b/xen/common/event_fifo.c
index 1fce3f1..51b4ff6 100644
--- a/xen/common/event_fifo.c
+++ b/xen/common/event_fifo.c
@@ -451,6 +451,7 @@ static void cleanup_event_array(struct domain *d)
for ( i = 0; i < EVTCHN_FIFO_MAX_EVENT_ARRAY_PAGES; i++ )
unmap_guest_page(d->evtchn_fifo->event_array[i]);
xfree(d->evtchn_fifo);
+ d->evtchn_fifo = NULL;
}
static void setup_ports(struct domain *d)
diff --git a/xen/include/public/event_channel.h b/xen/include/public/event_channel.h
index 49ac8cc..05e531d 100644
--- a/xen/include/public/event_channel.h
+++ b/xen/include/public/event_channel.h
@@ -264,6 +264,10 @@ typedef struct evtchn_unmask evtchn_unmask_t;
* NOTES:
* 1. <dom> may be specified as DOMID_SELF.
* 2. Only a sufficiently-privileged domain may specify other than DOMID_SELF.
+ * 3. Destroys all control blocks and event array, resets event channel
+ * operations to 2-level ABI if called with <dom> == DOMID_SELF and FIFO
+ * ABI was used. Guests should not bind events during EVTCHNOP_reset call
+ * as these events are likely to be lost.
*/
struct evtchn_reset {
/* IN parameters. */
--
1.9.3
prev parent reply other threads:[~2014-07-30 16:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-30 16:28 [PATCH v3 0/1] evtchn: make EVTCHNOP_reset suitable for kexec Vitaly Kuznetsov
2014-07-30 16:28 ` Vitaly Kuznetsov [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=1406737685-3686-2-git-send-email-vkuznets@redhat.com \
--to=vkuznets@redhat.com \
--cc=Ian.Campbell@citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=david.vrabel@citrix.com \
--cc=drjones@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).