[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>


Xen-devel mailing list



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