[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 4/6] libxc, libxl, hvmloader: strip out outdated VM generation ID implementation
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 <david.vrabel@xxxxxxxxxx> >> --- >> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |