From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>, Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: xen-devel@lists.xenproject.org, Andrew Jones <drjones@redhat.com>,
David Vrabel <david.vrabel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [PATCH] evtchn: make EVTCHNOP_reset suitable for kexec
Date: Fri, 25 Jul 2014 17:23:51 +0100 [thread overview]
Message-ID: <53D28497.9070502@citrix.com> (raw)
In-Reply-To: <53D282CB.9050904@citrix.com>
On 25/07/14 17:16, Andrew Cooper wrote:
> On 25/07/14 17:09, Jan Beulich wrote:
>>>>> On 25.07.14 at 17:48, <vkuznets@redhat.com> wrote:
>>> @@ -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);
>>> + }
>> You can't alter the behavior of an existing hypercall like this. Did
>> you at all check why it closes all channels, i.e. for what purpose
>> it got introduced?
>>
>> And apart from that blindly leaving all interdomain channels intact
>> doesn't seem reasonable either.
>>
>> Jan
>>
> I agree with your comment regarding interdomain channels.
>
> However, there absolutely nothing a domain can do to recover from a
> closed xenstore or console connection, as it is state set up by the
> toolstack at domain build time, rather than state set up during early boot.
>
> Whatever the intention of this hypercall originally, I can't see how a
> domain could possibly recover having used it.
>
> ~Andrew
Right - digging into the history shows that this was introduced 7 years
ago as a mixed toolstack or use-on-self hypercall. In the toolstack
case, clearing all channels unconditionally is fine as the toolstack can
reset the xenstore/console event channels.
However, when using it with DOMID_SELF, the domain will clobber itself
irrevocably.
I think it would be acceptable to reset the console and store event
channels if and only if current->domain != d
~Andrew
next prev parent reply other threads:[~2014-07-25 16:23 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 [this message]
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
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=53D28497.9070502@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=JBeulich@suse.com \
--cc=david.vrabel@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).