From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] evtchn: make EVTCHNOP_reset suitable for kexec Date: Fri, 25 Jul 2014 17:23:51 +0100 Message-ID: <53D28497.9070502@citrix.com> References: <1406303329-21724-1-git-send-email-vkuznets@redhat.com> <53D29D5F020000780002622D@mail.emea.novell.com> <53D282CB.9050904@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XAiHk-000274-6I for xen-devel@lists.xenproject.org; Fri, 25 Jul 2014 16:23:56 +0000 In-Reply-To: <53D282CB.9050904@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Vitaly Kuznetsov Cc: xen-devel@lists.xenproject.org, Andrew Jones , David Vrabel , Ian Campbell List-Id: xen-devel@lists.xenproject.org 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, 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