[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.