Re: [Xen-devel] [PATCH v7 00/10] toolstack-based approach to pvhvm guest kexec
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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 00/10] toolstack-based approach to pvhvm guest kexec
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? [...] > 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. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 00/10] toolstack-based approach to pvhvm guest kexec
"Jan Beulich" writes: On 28.05.15 at 14:27, wrote: >> "Jan Beulich" writes: >> >> On 27.05.15 at 17:25, wrote: This patch series provides x86 PVHVM domains with an ability to perform kexec/kdump-style operations. >>> >>> Before I get to look at this latest version, may I go a step back and >>> ask for clarification whether all of these (seemingly fragile) >>> manipulations are actually needed (such a rationale for the series >>> would btw be quite good to have in the overview mail, rather than >>> having to wade through mailing list history). In particular, why is it >>> that we need a new domain in the first place? After all, native >>> kexec doesn't imply a new physical machine either. Perhaps that >>> was discussed a long while back, but I can't seem to find any of >>> that now that I would like to read through it again. >> >> Yes, here are some highlights from last year's discussion: >> >> http://lists.xen.org/archives/html/xen-devel/2014-08/msg01908.html >> >> http://lists.xen.org/archives/html/xen-devel/2014-08/msg01979.html > > 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. I was under an impression Konrad was also suggesting building a new domain with "instead of chasing down different states (event channels, grants, vcpu's, pagetables, etc) we would wipe everything to a nice clean slate" (as we'll have to chase down all this bits with a 'reset-everything' hypercall) but now I'm not sure. AFAICT If we follow down the 'reset-everything' road it's not going to be any easier and less fragile. E.g. I don't see an easy way to deal with grants: even if we can clean all the internal bits we still have pages mapped to the backend domain (Qemu and other backends) and there is no easy way to ask them to unmap everything. We could (in theory) walk through all the pages of our domain replacing all pages which need replacement with empty pages but we need to temporary assign old pages somewhere, avoid over-allocation (as e.g. in tot_pages = max_pages case we can't add a single page to the domain). The support burden of a 'reset-everything' hypercall is also going to be heavier as all newly added bits will have to be added to it. 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). -- Vitaly ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 00/10] toolstack-based approach to pvhvm guest kexec
>>> On 28.05.15 at 14:27, wrote: > "Jan Beulich" writes: > > On 27.05.15 at 17:25, wrote: >>> This patch series provides x86 PVHVM domains with an ability to perform >>> kexec/kdump-style operations. >> >> Before I get to look at this latest version, may I go a step back and >> ask for clarification whether all of these (seemingly fragile) >> manipulations are actually needed (such a rationale for the series >> would btw be quite good to have in the overview mail, rather than >> having to wade through mailing list history). In particular, why is it >> that we need a new domain in the first place? After all, native >> kexec doesn't imply a new physical machine either. Perhaps that >> was discussed a long while back, but I can't seem to find any of >> that now that I would like to read through it again. > > Yes, here are some highlights from last year's discussion: > > http://lists.xen.org/archives/html/xen-devel/2014-08/msg01908.html > > http://lists.xen.org/archives/html/xen-devel/2014-08/msg01979.html 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. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 00/10] toolstack-based approach to pvhvm guest kexec
"Jan Beulich" writes: On 27.05.15 at 17:25, wrote: >> This patch series provides x86 PVHVM domains with an ability to perform >> kexec/kdump-style operations. > > Before I get to look at this latest version, may I go a step back and > ask for clarification whether all of these (seemingly fragile) > manipulations are actually needed (such a rationale for the series > would btw be quite good to have in the overview mail, rather than > having to wade through mailing list history). In particular, why is it > that we need a new domain in the first place? After all, native > kexec doesn't imply a new physical machine either. Perhaps that > was discussed a long while back, but I can't seem to find any of > that now that I would like to read through it again. Yes, here are some highlights from last year's discussion: http://lists.xen.org/archives/html/xen-devel/2014-08/msg01908.html http://lists.xen.org/archives/html/xen-devel/2014-08/msg01979.html http://lists.xen.org/archives/html/xen-devel/2014-08/msg01918.html -- Vitaly ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 00/10] toolstack-based approach to pvhvm guest kexec
>>> On 27.05.15 at 17:25, wrote: > This patch series provides x86 PVHVM domains with an ability to perform > kexec/kdump-style operations. Before I get to look at this latest version, may I go a step back and ask for clarification whether all of these (seemingly fragile) manipulations are actually needed (such a rationale for the series would btw be quite good to have in the overview mail, rather than having to wade through mailing list history). In particular, why is it that we need a new domain in the first place? After all, native kexec doesn't imply a new physical machine either. Perhaps that was discussed a long while back, but I can't seem to find any of that now that I would like to read through it again. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 00/10] toolstack-based approach to pvhvm guest kexec
This patch series provides x86 PVHVM domains with an ability to perform kexec/kdump-style operations. The main change in v7 is the XENMEM_soft_reset->XEN_DOMCTL_soft_reset change of the newly introduced hypercall. Changes are mentioned in individual patches. Here is the list of them grouped by the reviewer's name: Jan Beulich: - XENMEM_soft_reset->XEN_DOMCTL_soft_reset change - print a warning on !mfn_valid case - check PGC_allocated for pages - don't re-read page->count_info - minor structuring change - pause both source and destination domain while processing the hypercall - remove nr_transferred from public interface - other minor fixes in PATCH 04/10 - add a comment on why we don't do two XSM_TARGET checks in dummy.h Tim Deegan: - use get_gfn_type_access() in PoD case Wei Liu: - replace LIBXL_HAVE_SHUTDWON_REASON_SOFT_RESET with LIBXL_HAVE_SOFT_RESET Daniel De Graaf: - add reset_transfer vector to FLASK (I dropped Acked-by: on the patch because of the XENMEM_soft_reset->XEN_DOMCTL_soft_reset change.) Julien Grall: - check that xc_domain_getinfo() return the domain we asked for v6 of this series is available here: http://lists.xenproject.org/archives/html/xen-devel/2015-05/msg01613.html v5 and all the history of the series is available here: http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01312.html Vitaly Kuznetsov (10): xen: introduce SHUTDOWN_soft_reset shutdown reason libxl: support SHUTDOWN_soft_reset shutdown reason xen: introduce DOMDYING_locked state xen: Introduce XEN_DOMCTL_soft_reset xsm: add XEN_DOMCTL_soft_reset support libxc: support XEN_DOMCTL_soft_reset operation libxc: introduce soft reset for HVM domains xl: introduce enum domain_restart_type libxc: add XC_DEVICE_MODEL_SAVE_FILE (lib)xl: soft reset support docs/man/xl.cfg.pod.5| 12 ++ tools/flask/policy/policy/modules/xen/xen.if | 3 +- tools/libxc/Makefile | 1 + tools/libxc/include/xenctrl.h| 4 + tools/libxc/include/xenguest.h | 22 +++ tools/libxc/xc_domain.c | 12 ++ tools/libxc/xc_soft_reset.c | 280 +++ tools/libxl/libxl.c | 4 + tools/libxl/libxl.h | 14 ++ tools/libxl/libxl_create.c | 119 +++- tools/libxl/libxl_dm.c | 2 +- tools/libxl/libxl_internal.h | 26 +++ tools/libxl/libxl_types.idl | 4 + tools/libxl/xl.h | 7 + tools/libxl/xl_cmdimpl.c | 58 -- tools/python/xen/lowlevel/xl/xl.c| 1 + xen/common/domain.c | 187 ++ xen/common/domctl.c | 79 xen/common/shutdown.c| 6 + xen/include/public/domctl.h | 28 +++ xen/include/public/sched.h | 3 +- xen/include/xen/sched.h | 9 +- xen/include/xsm/dummy.h | 12 ++ xen/include/xsm/xsm.h| 8 + xen/xsm/dummy.c | 2 + xen/xsm/flask/hooks.c| 18 ++ xen/xsm/flask/policy/access_vectors | 7 + 27 files changed, 899 insertions(+), 29 deletions(-) create mode 100644 tools/libxc/xc_soft_reset.c -- 1.9.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
