From mboxrd@z Thu Jan  1 00:00:00 1970
From: Vitaly Kuznetsov <vkuznets@redhat.com>
Subject: Re: [PATCH] evtchn: make EVTCHNOP_reset suitable for
	kexec
Date: Fri, 25 Jul 2014 18:38:12 +0200
Message-ID: <8738dpjswb.fsf@vitty.brq.redhat.com>
References: <1406303329-21724-1-git-send-email-vkuznets@redhat.com>
	<53D29D5F020000780002622D@mail.emea.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vkuznets@redhat.com>) id 1XAiVj-0002wy-0t
	for xen-devel@lists.xenproject.org; Fri, 25 Jul 2014 16:38:23 +0000
In-Reply-To: <53D29D5F020000780002622D@mail.emea.novell.com> (Jan Beulich's
	message of "Fri, 25 Jul 2014 17:09:35 +0100")
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Andrew Jones <drjones@redhat.com>, David Vrabel <david.vrabel@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xenproject.org
List-Id: xen-devel@lists.xenproject.org

"Jan Beulich" <JBeulich@suse.com> writes:

>>>> 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?

Originally I though about introducing new hypercall to cleans up all
control blocks when FIFO-based event channel ABI is being used (see
"[PATCH RFC] evtchn: introduce EVTCHNOP_fifo_destroy hypercall"
email). Andrew and Ian convinced me to reuse EVTCHNOP_reset to be
ABI-agnostic here.

I'm not sure how to check the purpose of introduction but I did check
that EVTCHNOP_reset is not being used neither in Linux kernel nor in
http://xenbits.xensource.com/ext/win-pvdrivers/. The original commit
which introduces it is:
 commit 115209d91bcd3734ddaaf58a4a1cdbb4c44cd4fa
 Author: kfraser@localhost.localdomain <kfraser@localhost.localdomain>
 Date:   Fri Jan 19 17:20:57 2007 +0000

    [XEN] New event-channel reset operation.
    Plumbed through libxenctrl to python.
    
    From: Andrei Petrov <andrei.petrov@xensource.com>
    Signed-off-by: Keir Fraser <keir@xensource.com>

It would be great if you can point out EVTCHNOP_reset usages I'm not
aware of. We can revise the descision of reusing EVTCHNOP_reset in case
we break things.

>
> And apart from that blindly leaving all interdomain channels intact
> doesn't seem reasonable either.

I agree here, see my reply to Andrew. We need to preserve console/store
channels only and any suggestion on how to distinguish them from other
interdomain mappings to Dom0 on hypervisor side are welcome.

>
> Jan
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

-- 
  Vitaly