From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH 4/6] libxc, libxl, hvmloader: strip out outdated VM generation ID implementation Date: Mon, 2 Jun 2014 10:23:11 +0100 Message-ID: <538C427F.4070602@citrix.com> References: <1401211909-27771-1-git-send-email-david.vrabel@citrix.com> <1401211909-27771-5-git-send-email-david.vrabel@citrix.com> <1401288625.10916.11.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WrOSa-00016S-LJ for xen-devel@lists.xenproject.org; Mon, 02 Jun 2014 09:23:16 +0000 In-Reply-To: <1401288625.10916.11.camel@kazak.uk.xensource.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: Ian Campbell Cc: xen-devel@lists.xenproject.org, Ian Jackson , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 28/05/14 15:50, Ian Campbell wrote: > On Tue, 2014-05-27 at 18:31 +0100, David Vrabel wrote: >> The VM generation ID support in libxc/libxl was based on a draft >> specification which subsequently changed considerably. Remove much of >> the code in anticipation of introducing something simpler that >> conforms to the current specification from Microsoft. >> >> Switch to using a HVM param (HVM_PARAM_VM_GENERATION_ID_ADDR) instead >> of the hvmloader/generation-id-address XenStore key. This simplifies >> save/restore since it only needs to transfer the value of this param. >> >> Signed-off-by: David Vrabel >> --- >> tools/firmware/hvmloader/acpi/build.c | 9 +++---- >> tools/libxc/xc_domain_restore.c | 44 +++------------------------------ >> tools/libxc/xc_domain_save.c | 5 ++-- >> tools/libxc/xenguest.h | 8 ++---- >> tools/libxl/libxl_create.c | 12 +++------ >> tools/libxl/libxl_dom.c | 25 ++----------------- >> tools/libxl/libxl_internal.h | 8 ++---- >> tools/libxl/libxl_save_callout.c | 10 +++----- >> tools/libxl/libxl_save_helper.c | 9 +++---- >> tools/libxl/libxl_save_msgs_gen.pl | 3 +-- > > I've forgotten how this existing stuff works, but since there is no > touching of libxl_types.idl or libxl.h here I think there was no > application facing nob for the existing stuff, right? (the relevant > libxc parameter is hardcoded in libxl). > > Hence nothing to remove and nothing to add a comment about. Yes. >> --- a/tools/libxc/xc_domain_save.c >> +++ b/tools/libxc/xc_domain_save.c >> @@ -1634,7 +1633,7 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter >> } chunk = { 0, }; >> >> chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR; >> - chunk.data = vm_generationid_addr; >> + xc_get_hvm_param(xch, dom, HVM_PARAM_VM_GENERATION_ID_ADDR, &chunk.data); > > Are there any N->N+1 migration concerns here? > > I don't think so, since the stream always contains the address and what > happens to it is entirely internal to the given host. Is that correct? Yes, that is correct. David