From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Chen, Tiejun" <tiejun.chen@intel.com>
Subject: Re: [RFC][PATCH 13/13] hvmloader/e820: construct guest
	e820 table
Date: Fri, 15 May 2015 16:00:33 +0800
Message-ID: <5555A7A1.9020006@intel.com>
References: <1428657724-3498-1-git-send-email-tiejun.chen@intel.com>
	<1428657724-3498-14-git-send-email-tiejun.chen@intel.com>
	<553529850200007800073DB7@mail.emea.novell.com>
	<55558E20.6020305@intel.com>
	<5555AD8B020000780007A5AE@mail.emea.novell.com>
	<555594AA.4040905@intel.com>
	<5555B4D7020000780007A620@mail.emea.novell.com>
	<55559C07.6000601@intel.com>
	<5555BDAF020000780007A679@mail.emea.novell.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: <5555BDAF020000780007A679@mail.emea.novell.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: Jan Beulich <JBeulich@suse.com>
Cc: tim@xen.org, kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com, andrew.cooper3@citrix.com, Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org, stefano.stabellini@citrix.com, yang.z.zhang@intel.com
List-Id: xen-devel@lists.xenproject.org

On 2015/5/15 15:34, Jan Beulich wrote:
>>>> On 15.05.15 at 09:11, <tiejun.chen@intel.com> wrote:
>> On 2015/5/15 14:56, Jan Beulich wrote:
>>>>>> On 15.05.15 at 08:39, <tiejun.chen@intel.com> wrote:
>>>> On 2015/5/15 14:25, Jan Beulich wrote:
>>>>>>>> On 15.05.15 at 08:11, <tiejun.chen@intel.com> wrote:
>>>>>> Even we may separate the
>>>>>> low memory to construct memory_map.map[]...
>>>>>
>>>>> ???
>>>>
>>>> Sorry I just mean that the low memory is not represented with only one
>>>> memory_map.map[] in some cases.
>>>
>>> That's correct.
>>>
>>
>> So just lets keep that original BUG_ON()?
>
> In your previous reply you seemed to agree that the BUG_ON() is
> becoming meaningless. Why do you now suggest to keep it then?
>

Sorry just let me clear this.

We still need to check this,

(hvm_info->low_mem_pgend << PAGE_SHIFT) < (2u << 20)

Right? I agree the original is really less relevant as you said. But 
what is that meaningful BUG_ON() as you expect?

I have no better ideas and just show one draft thought in previous email.

Thanks
Tiejun