From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: Olaf Hering <olaf@aepfle.de>, Wei Liu <wei.liu2@citrix.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Julien Grall <julien.grall@linaro.org>,
Ian Jackson <ian.jackson@eu.citrix.com>,
Andrew Jones <drjones@redhat.com>, Tim Deegan <tim@xen.org>,
David Vrabel <david.vrabel@citrix.com>,
Jan Beulich <JBeulich@suse.com>,
xen-devel@lists.xenproject.org,
Daniel De Graaf <dgdegra@tycho.nsa.gov>,
Keir Fraser <keir@xen.org>
Subject: Re: [PATCH v7 00/10] toolstack-based approach to pvhvm guest kexec
Date: Tue, 02 Jun 2015 18:26:16 +0200 [thread overview]
Message-ID: <87siaavzyv.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <1433257081.15036.301.camel@citrix.com> (Ian Campbell's message of "Tue, 2 Jun 2015 15:58:01 +0100")
Ian Campbell <ian.campbell@citrix.com> 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
prev parent reply other threads:[~2015-06-02 16:26 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-27 15:25 [PATCH v7 00/10] toolstack-based approach to pvhvm guest kexec Vitaly Kuznetsov
2015-05-27 15:25 ` [PATCH v7 01/10] xen: introduce SHUTDOWN_soft_reset shutdown reason Vitaly Kuznetsov
2015-05-27 15:25 ` [PATCH v7 02/10] libxl: support " Vitaly Kuznetsov
2015-06-02 14:58 ` Ian Campbell
2015-05-27 15:25 ` [PATCH v7 03/10] xen: introduce DOMDYING_locked state Vitaly Kuznetsov
2015-05-27 15:25 ` [PATCH v7 04/10] xen: Introduce XEN_DOMCTL_soft_reset Vitaly Kuznetsov
2015-05-28 10:06 ` Tim Deegan
2015-05-28 11:56 ` Vitaly Kuznetsov
2015-05-28 12:52 ` Tim Deegan
2015-05-28 13:11 ` Vitaly Kuznetsov
2015-05-28 13:37 ` Tim Deegan
2015-05-28 13:53 ` Vitaly Kuznetsov
2015-05-28 15:02 ` Jan Beulich
2015-05-27 15:25 ` [PATCH v7 05/10] xsm: add XEN_DOMCTL_soft_reset support Vitaly Kuznetsov
2015-05-27 20:22 ` Daniel De Graaf
2015-05-29 16:16 ` Jan Beulich
2015-05-27 15:25 ` [PATCH v7 06/10] libxc: support XEN_DOMCTL_soft_reset operation Vitaly Kuznetsov
2015-06-02 15:00 ` Ian Campbell
2015-05-27 15:25 ` [PATCH v7 07/10] libxc: introduce soft reset for HVM domains Vitaly Kuznetsov
2015-06-02 15:09 ` Ian Campbell
2015-05-27 15:25 ` [PATCH v7 08/10] xl: introduce enum domain_restart_type Vitaly Kuznetsov
2015-06-02 15:11 ` Ian Campbell
2015-05-27 15:25 ` [PATCH v7 09/10] libxc: add XC_DEVICE_MODEL_SAVE_FILE Vitaly Kuznetsov
2015-06-02 15:12 ` Ian Campbell
2015-05-27 15:25 ` [PATCH v7 10/10] (lib)xl: soft reset support Vitaly Kuznetsov
2015-06-02 15:25 ` Ian Campbell
2015-05-28 12:20 ` [PATCH v7 00/10] toolstack-based approach to pvhvm guest kexec Jan Beulich
2015-05-28 12:27 ` Vitaly Kuznetsov
2015-05-28 13:05 ` Jan Beulich
2015-05-28 13:41 ` Vitaly Kuznetsov
2015-06-02 14:58 ` Ian Campbell
2015-06-02 16:26 ` Vitaly Kuznetsov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87siaavzyv.fsf@vitty.brq.redhat.com \
--to=vkuznets@redhat.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=david.vrabel@citrix.com \
--cc=dgdegra@tycho.nsa.gov \
--cc=drjones@redhat.com \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=julien.grall@linaro.org \
--cc=keir@xen.org \
--cc=olaf@aepfle.de \
--cc=stefano.stabellini@eu.citrix.com \
--cc=tim@xen.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.