From: Ian Campbell <ian.campbell@citrix.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.com>,
Keir Fraser <keir@xen.org>,
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>,
Olaf Hering <olaf@aepfle.de>, 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>
Subject: Re: [PATCH v7 07/10] libxc: introduce soft reset for HVM domains
Date: Tue, 2 Jun 2015 16:09:25 +0100 [thread overview]
Message-ID: <1433257765.15036.310.camel@citrix.com> (raw)
In-Reply-To: <1432740346-7887-8-git-send-email-vkuznets@redhat.com>
On Wed, 2015-05-27 at 17:25 +0200, Vitaly Kuznetsov wrote:
> Add new xc_soft_reset() function which performs so-called 'soft reset'
> for an HVM domain. It is being performed in the following way:
> - Save HVM context and all HVM params of the source domain;
> - Transfer all the source domain's memory to the destinatio domain with
"destination"
> XEN_DOMCTL_soft_reset;
> - Restore HVM context, HVM params, seed grant table for the new domain.
> When the operation succeeds the source domain is being destroyed and the
This is sounding a lot like a migration, with the refactoring done for
migration v2 is there any possibility we might be able to reuse any of
that?
(e.g. the list of hvmparams to be dealt with seems like something which
needs to be the same everywhere)
> + if ( xc_domain_get_pod_target(xch, source_dom, &pod_info[0], &pod_info[1],
> + &pod_info[2]) )
I don't like all the open coded [0], [1] and [2] in the following code
which this implies. You could define symbolic names TOT_PAGES=1, etc but
TBH I think you would be better off just having 3 appropriately named
variables instead of the array.
> + {
> + PERROR("Could not get old domain's PoD info");
> + return 1;
> + }
> +
> + if ( xc_domain_getinfo(xch, dest_dom, 1, &new_info) != 1 ||
> + new_info.domid != dest_dom )
> + {
> + PERROR("Could not get new domain's info");
> + return 1;
> + }
> +
> + if ( !old_info.hvm || !new_info.hvm )
> + {
> + PERROR("Soft reset is supported for HVM only");
> + return 1;
> + }
Should do these sorts of checks before real work, like getting the PoD
info.
> +
> + sharedinfo_pfn = old_info.shared_info_frame;
> + if ( xc_get_pfn_type_batch(xch, source_dom, 1, &sharedinfo_pfn) )
> + {
> + PERROR("xc_get_pfn_type_batch failed");
> + goto out;
> + }
> +
> + hvm_buf_size = xc_domain_hvm_getcontext(xch, source_dom, 0, 0);
> + if ( hvm_buf_size == -1 )
> + {
> + PERROR("Couldn't get HVM context size from Xen");
> + goto out;
> + }
> +
> + hvm_buf = malloc(hvm_buf_size);
> + if ( !hvm_buf )
> + {
> + ERROR("Couldn't allocate memory");
> + goto out;
> + }
> +
> + if ( xc_domain_hvm_getcontext(xch, source_dom, hvm_buf,
> + hvm_buf_size) == -1 )
> + {
> + PERROR("HVM:Could not get hvm buffer");
> + goto out;
> + }
> +
> + xc_hvm_param_get(xch, source_dom, HVM_PARAM_STORE_PFN,
> + &hvm_params[HVM_PARAM_STORE_PFN]);
> + store_pfn = hvm_params[HVM_PARAM_STORE_PFN];
> + *store_mfn = store_pfn;
> +
> + xc_hvm_param_get(xch, source_dom,
> + HVM_PARAM_CONSOLE_PFN,
> + &hvm_params[HVM_PARAM_CONSOLE_PFN]);
> + console_pfn = hvm_params[HVM_PARAM_CONSOLE_PFN];
> + *console_mfn = console_pfn;
> +
> + xc_hvm_param_get(xch, source_dom, HVM_PARAM_BUFIOREQ_PFN,
> + &hvm_params[HVM_PARAM_BUFIOREQ_PFN]);
> + buffio_pfn = hvm_params[HVM_PARAM_BUFIOREQ_PFN];
> +
> + xc_hvm_param_get(xch, source_dom, HVM_PARAM_IOREQ_PFN,
> + &hvm_params[HVM_PARAM_IOREQ_PFN]);
> + io_pfn = hvm_params[HVM_PARAM_IOREQ_PFN];
> +
> + xc_hvm_param_get(xch, source_dom, HVM_PARAM_IDENT_PT,
> + &hvm_params[HVM_PARAM_IDENT_PT]);
> +
> + xc_hvm_param_get(xch, source_dom, HVM_PARAM_PAGING_RING_PFN,
> + &hvm_params[HVM_PARAM_PAGING_RING_PFN]);
> +
> + xc_hvm_param_get(xch, source_dom, HVM_PARAM_VM86_TSS,
> + &hvm_params[HVM_PARAM_VM86_TSS]);
> +
> + xc_hvm_param_get(xch, source_dom, HVM_PARAM_ACPI_IOPORTS_LOCATION,
> + &hvm_params[HVM_PARAM_ACPI_IOPORTS_LOCATION]);
> +
> + xc_hvm_param_get(xch, source_dom, HVM_PARAM_VIRIDIAN,
> + &hvm_params[HVM_PARAM_VIRIDIAN]);
> +
> + xc_hvm_param_get(xch, source_dom, HVM_PARAM_PAE_ENABLED,
> + &hvm_params[HVM_PARAM_PAE_ENABLED]);
> +
> + xc_hvm_param_get(xch, source_dom, HVM_PARAM_STORE_EVTCHN,
> + &hvm_params[HVM_PARAM_STORE_EVTCHN]);
> +
> + xc_hvm_param_get(xch, source_dom, HVM_PARAM_IOREQ_SERVER_PFN,
> + &hvm_params[HVM_PARAM_IOREQ_SERVER_PFN]);
> +
> + xc_hvm_param_get(xch, source_dom, HVM_PARAM_NR_IOREQ_SERVER_PAGES,
> + &hvm_params[HVM_PARAM_NR_IOREQ_SERVER_PAGES]);
> +
> + xc_hvm_param_get(xch, source_dom, HVM_PARAM_VM_GENERATION_ID_ADDR,
> + &hvm_params[HVM_PARAM_VM_GENERATION_ID_ADDR]);
Even if this can't be shared with the migration please at least make it
table driven (i.e. an array of HVM_PARAM_* to wander over) so that
get/set can use the same table and not get out of sync.
Does the set have to follow the xc_domain_soft_reset and/or the get
precede the xc_domain_soft_reset? Or could a simple helper implement get
+set in one "move" operation? That would also remove the possibility of
forgetting to do both halves of one hvm param.
Ian.
next prev parent reply other threads:[~2015-06-02 15:12 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 [this message]
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
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=1433257765.15036.310.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=david.vrabel@citrix.com \
--cc=dgdegra@tycho.nsa.gov \
--cc=drjones@redhat.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.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=vkuznets@redhat.com \
--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.