From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Chen, Tiejun" <tiejun.chen@intel.com>
Subject: Re: [v10][PATCH 07/16] hvmloader/e820: construct guest
 e820 table
Date: Mon, 20 Jul 2015 21:57:23 +0800
Message-ID: <55ACFE43.1060801@intel.com>
References: <1437373023-14884-1-git-send-email-tiejun.chen@intel.com>
	<1437373023-14884-8-git-send-email-tiejun.chen@intel.com>
	<CAFLBxZYxuJ7LV+TG3G5Y8iQf=Wks+vd_EVYx4oSKFOXB6q_aKA@mail.gmail.com>
	<55ACF64F.70702@intel.com>
	<CAFLBxZZwWX84bG-_-sd-Jh5aGtG+8m_TBBrqZUNv8V9JaqRJ+Q@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <CAFLBxZZwWX84bG-_-sd-Jh5aGtG+8m_TBBrqZUNv8V9JaqRJ+Q@mail.gmail.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
List-Id: xen-devel@lists.xenproject.org

>>> Actually, now that you mention it -- this should probably happen
>>> instead when we update hvm_info->{low,high}_mem_pgend.
>>
>>
>> I also considered this point previously but I thought just right now we only
>> update hvm_info->low/high_mem_pgend inside pci_setup(). But you can't
>> guarantee this would be a sole place in the future. Instead,
>> memory_map.map[] would always be copied into e820 when we build e820 table.
>
> We can guarantee it, if nothing else by making sure that no new
> changes are added which change the one but not the other.

This means you have to syn this again once you change hvm_info so I 
think this may cost a little bit.

Thanks
Tiejun

>
> But perhaps better would be to put a check in build_e820_map() to
> BUG() if hvm_info and memory_map are out of sync.
>
> On the other hand, looking at this now, I think that long-term we
> should probably move to have *all* information about the memory layout
> passed to hvmloader via the memory map, rather than via hvm_info.
> That way we can also get rid of the "magic" knowledge that hvmloader
> has about the memory layout (e.g., the VGA hole).
>
>   -George
>