From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH 2/6] hvm: add HVM_PARAM_VM_GENERATION_ID_ADDR Date: Tue, 10 Jun 2014 11:44:39 +0100 Message-ID: <5396E197.4050500@citrix.com> References: <1401801340-6196-1-git-send-email-david.vrabel@citrix.com> <1401801340-6196-3-git-send-email-david.vrabel@citrix.com> <1402396027.1250.18.camel@kazak.uk.xensource.com> <5396FCBA0200007800019679@mail.emea.novell.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 1WuJXo-0002Fb-Rj for xen-devel@lists.xenproject.org; Tue, 10 Jun 2014 10:44:45 +0000 In-Reply-To: <5396FCBA0200007800019679@mail.emea.novell.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: Jan Beulich Cc: Keir Fraser , Ian Campbell , Stefano Stabellini , Tim Deegan , Ian Jackson , David Vrabel , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On 10/06/14 11:40, Jan Beulich wrote: >>>> On 10.06.14 at 12:27, 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 >> Acked-by: Ian Campbell >> >> 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). > > Jan 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. ~Andrew