From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH RFC 1/4] xen: evtchn: make evtchn_reset() ready for soft reset Date: Fri, 5 Jun 2015 09:58:48 +0100 Message-ID: <1433494728.7108.141.camel@citrix.com> References: <1433338522-8422-1-git-send-email-vkuznets@redhat.com> <1433338522-8422-2-git-send-email-vkuznets@redhat.com> <20150604140556.GF74656@deinos.phlegethon.org> <55706C8C.6090607@citrix.com> <20150604154704.GL74656@deinos.phlegethon.org> <55717F5202000078000812C7@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Z0nSx-0000Eq-LH for xen-devel@lists.xenproject.org; Fri, 05 Jun 2015 08:59:03 +0000 In-Reply-To: <55717F5202000078000812C7@mail.emea.novell.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 Cc: Olaf Hering , Wei Liu , Stefano Stabellini , Andrew Cooper , Julien Grall , Ian Jackson , Andrew Jones , Tim Deegan , David Vrabel , xen-devel@lists.xenproject.org, Vitaly Kuznetsov , Keir Fraser , Daniel De Graaf List-Id: xen-devel@lists.xenproject.org On Fri, 2015-06-05 at 09:52 +0100, Jan Beulich wrote: > >>> On 04.06.15 at 17:47, wrote: > > At 16:19 +0100 on 04 Jun (1433434780), David Vrabel wrote: > >> On 04/06/15 15:05, Tim Deegan wrote: > >> > At 15:35 +0200 on 03 Jun (1433345719), Vitaly Kuznetsov wrote: > >> >> We need to close all event channel so the domain performing soft reset > >> >> will be able to open them back. Interdomain channels are, however, > >> >> special. We need to keep track of who opened it as in (the most common) > >> >> case it was opened by the control domain we won't be able (and allowed) to > >> >> re-establish it. > >> > > >> > > >> > I'm not sure I understand -- can you give an example of what this is > >> > avoiding? I would have thought that the kexec'ing VM needs to tear > >> > down _all_ its connections and then restart the ones it wantrs in the > >> > new OS. > >> > >> There are some that are in state ECS_UNBOUND (console, xenstore, I > >> think) at start of day that are allocated on behalf of the domain by the > >> toolstack. The kexec'd image will expect them in these same state. > > > > I see. But does that not come under "tear down all its connections > > and then restart the ones it wants"? I.e. should the guest not reset > > all its channels and then allocate fresh console & xenstore ones? > > But just like during boot the guest doesn't (and can't) created these, > it also can't do so after kexec. The remote side needs to be set up > for it, so it can simply bind to them. I don't think this can work without > tool stack involvement. Which IIRC is pretty much the logic which lead to the more toolstack centric approach in the other series. Are you suggesting something in the middle?