From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: [PATCH v11 11/11] (lib)xl: soft reset support Date: Mon, 14 Sep 2015 18:46:57 +0100 Message-ID: <20150914174657.GA18005@zion.uk.xensource.com> References: <1441373991-18332-1-git-send-email-vkuznets@redhat.com> <1441373991-18332-12-git-send-email-vkuznets@redhat.com> <20150914161529.GH2294@zion.uk.xensource.com> <87a8spym90.fsf@vitty.brq.redhat.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 1ZbXqJ-0002sr-Ts for xen-devel@lists.xenproject.org; Mon, 14 Sep 2015 17:47:04 +0000 Content-Disposition: inline In-Reply-To: <87a8spym90.fsf@vitty.brq.redhat.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: Vitaly Kuznetsov Cc: Andrew Jones , Julien Grall , Wei Liu , Ian Campbell , Stefano Stabellini , Andrew Cooper , Ian Jackson , Olaf Hering , Tim Deegan , David Vrabel , Jan Beulich , xen-devel@lists.xenproject.org, Daniel De Graaf , Keir Fraser List-Id: xen-devel@lists.xenproject.org On Mon, Sep 14, 2015 at 06:54:51PM +0200, Vitaly Kuznetsov wrote: > Wei Liu writes: > > > Sorry for the delay. > > > > FYI all other patches of this series were applied by Jan. You only need > > to resend this one. > > Cool, I will. > > > > > See below for a few comments. > > > > On Fri, Sep 04, 2015 at 03:39:51PM +0200, Vitaly Kuznetsov wrote: > >> Use existing create/restore path to perform 'soft reset' for HVM > >> domains. Tear everything down, e.g. destroy domain's device model, > >> remove the domain from xenstore, save toolstack record and start > >> over. > >> > >> Signed-off-by: Vitaly Kuznetsov > >> --- > >> Changes since v10: > >> - Adapt to 'migration v2' changes. > >> - Use LIBXL_DEVICE_MODEL_SAVE_FILE as Qemu save file (and rename it to > >> LIBXL_DEVICE_MODEL_RESTORE_FILE later) to support stubdom case (as > >> we connect consoles to both files on create. > >> - Fix coding style, minor description change in xl.cfg.pod.5 [Wei Liu] > >> > >> Signed-off-by: Vitaly Kuznetsov > >> --- > >> docs/man/xl.cfg.pod.5 | 8 +- > >> tools/libxl/libxl.c | 22 ++++- > >> tools/libxl/libxl.h | 15 ++++ > >> tools/libxl/libxl_create.c | 192 ++++++++++++++++++++++++++++++++++++++----- > >> tools/libxl/libxl_internal.h | 4 + > >> tools/libxl/libxl_types.idl | 2 + > >> tools/libxl/xl.h | 1 + > >> tools/libxl/xl_cmdimpl.c | 25 +++++- > >> 8 files changed, 242 insertions(+), 27 deletions(-) > >> > >> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 > >> index c6345b8..d8c4186 100644 > >> --- a/docs/man/xl.cfg.pod.5 > >> +++ b/docs/man/xl.cfg.pod.5 > >> @@ -349,6 +349,12 @@ destroy the domain. > >> write a "coredump" of the domain to F and then > >> restart the domain. > >> > >> +=item B > >> + > >> +Reset all Xen specific interfaces for the Xen-aware HVM domain allowing > >> +it to reestablish these interfaces and continue executing the domain. PV > >> +guest is not supported. > >> + > > > > And "non-Xen-aware HVM will crash" ? > > Sorry, I should have replied to that suggestion earlier. Non-Xen-aware > HVM guest can't really trigger this action and (in theory) is capable of > doing kexec without any assistance. > > > If there is no definite answer to > > guest state maybe just saying "PV guest and non-Xen-aware HVM guests are > > not supported" ? > > This sounds correct. > > > > > It's important to let user know about the consequence because libxl > > doesn't actually stop you from soft-resetting a HVM guest that is not > > Xen-aware. > > The question is who (and when/how) is going to trigger this action? In > case someone does that while HVM domain (doesn't really matter if it is > Xen-aware or not) does not expect this action it will crash. > > *In theory* nothing bad is going to happen to a non-Xen-aware HVM guest > if someone else will trigger this action for it (e.g. on 'reset' > signal), it will just get an assistance it doesn't need. > OK then. We should still make it clear it is unsupported for non-Xen-aware HVM guest even if it happens to work. Wei. > [...] > > -- > Vitaly