[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2/6] hvm: add HVM_PARAM_VM_GENERATION_ID_ADDR
>>> On 10.06.14 at 12:44, <andrew.cooper3@xxxxxxxxxx> wrote: > On 10/06/14 11:40, Jan Beulich wrote: >>>>> On 10.06.14 at 12:27, <Ian.Campbell@xxxxxxxxxx> wrote: >>> On Tue, 2014-06-03 at 14:15 +0100, David Vrabel wrote: >>>> HVM_PARAM_VM_GENERATION_ID_ADDR is the guest physical address of the >>>> VM Generation ID. This parameter will be written by hvmloader and read >>>> by the toolstack when updating the gen. ID (e.g., after restoring from a >>>> snapshot). >>>> >>>> A HVM parameter is easier for the save/restore code to work with (than >>>> a XenStore key). >>>> >>>> Signed-off-by: David Vrabel <david.vrabel@xxxxxxxxxx> >>> Acked-by: Ian Campbell <ian.campbell@citrix,com> >>> >>> It's a bit ambiguous for hvm params which the hypervisor doesn't >>> actually interpret but strictly speaking this needs to be CCd to the h/v >>> guys. Added Jan/Keir.Tim. >> Adding a parameter used by the tools only in general would seem fine, >> yet in the case at hand it looks to be a quite questionable one: I >> didn't look too closely at the series so far, and hence it's unclear to >> me how any part of the tools can safely know the location of any >> particular data item inside the guest kernel. Plus I don't see what >> would guarantee that physical address to not change (after all >> Windows does swap certain parts of kernel memory if necessary). > > hvmloader allocates a physical area, marked as reserved in the E820, > then tells window "your generation ID is as this physical address". > > Its location is never going to change after boot, but tools subsequently > need to know where it is in the guest to update its value. Ah, okay, that's fine then. I.e. for the interface addition: Acked-by: Jan Beulich <jbeulich@xxxxxxxx> Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |