From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vitaly Kuznetsov Subject: Re: [PATCH v7 00/10] toolstack-based approach to pvhvm guest kexec Date: Tue, 02 Jun 2015 18:26:16 +0200 Message-ID: <87siaavzyv.fsf@vitty.brq.redhat.com> References: <1432740346-7887-1-git-send-email-vkuznets@redhat.com> <5567241B020000780007E8FA@mail.emea.novell.com> <5567241B020000780007E8FA@mail.emea.novell.com> <87d21kq43z.fsf@vitty.brq.redhat.com> <55672EB4020000780007E973@mail.emea.novell.com> <874mmwq0nt.fsf@vitty.brq.redhat.com> <1433257081.15036.301.camel@citrix.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 1Yzp1E-0003Iv-Oa for xen-devel@lists.xenproject.org; Tue, 02 Jun 2015 16:26:24 +0000 In-Reply-To: <1433257081.15036.301.camel@citrix.com> (Ian Campbell's message of "Tue, 2 Jun 2015 15:58:01 +0100") List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Olaf Hering , Wei Liu , Stefano Stabellini , Andrew Cooper , Julien Grall , Ian Jackson , Andrew Jones , Tim Deegan , David Vrabel , Jan Beulich , xen-devel@lists.xenproject.org, Daniel De Graaf , Keir Fraser List-Id: xen-devel@lists.xenproject.org Ian Campbell writes: > On Thu, 2015-05-28 at 15:41 +0200, Vitaly Kuznetsov wrote: >> > I.e. what you currently implement is David's model without Konrad's >> > later alternative really having been explored? Iiuc David's main >> > reservation (which I share) was against a myriad of reset-this and >> > reset-that hypercalls, which Konrad's reset-everything would >> > address equally well. > > FWIW it seems to me that David's suggestion without Konrad's > modification is the simplest and least fragile approach. Is there some > impetus to prefer a reset-all hypercall? > I'm actually doing a 'proof-of-concept' for the 'reset-all' solution, I hope to send it out this week. Personally, I think that the 'toolstack-based approach' would be less fragile and easier to support. > [...] >> The approach used in this series is not significantly different from how >> an HVM domain is doing normal reboot: we destroy the original domain and >> create a new one instead of cleaning up the original one (as it looks >> safer and much easier I suppose). > > Right, that was my first thought too. > > Ian. -- Vitaly