From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Jan Beulich" <JBeulich@suse.com>
Subject: Re: (v2) Design proposal for RMRR fix
Date: Wed, 21 Jan 2015 10:18:37 +0000
Message-ID: <54BF8B0D02000078000575FB@mail.emea.novell.com>
References: <54B68FA10200007800054F01@mail.emea.novell.com>
	<54B6B578.60106@eu.citrix.com>
	<54B78A5A02000078000552C2@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D126147864@SHSMSX101.ccr.corp.intel.com>
	<CAFLBxZYfOBaSEgDQn9mgR7u+rw8TtfncfBMhBKzm83K1cUFhkA@mail.gmail.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12614A4FD@SHSMSX101.ccr.corp.intel.com>
	<54BCDD53020000780005645A@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12614C0B0@SHSMSX101.ccr.corp.intel.com>
	<20150119113359.GB17236@deinos.phlegethon.org>
	<54BCFB8D0200007800056684@mail.emea.novell.com>
	<20150119122334.GD17236@deinos.phlegethon.org>
	<54BD1A1802000078000567E7@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12614D01A@SHSMSX101.ccr.corp.intel.com>
	<54BE11D20200007800056C73@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12614D81D@SHSMSX101.ccr.corp.intel.com>
	<54BE29A30200007800056D31@mail.emea.novell.com>
	<1421750332.10440.208.camel@citrix.com>
	<54BE40990200007800056E99@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12614F09E@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12614F09E@SHSMSX101.ccr.corp.intel.com>
Content-Disposition: inline
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: Kevin Tian <kevin.tian@intel.com>
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, George Dunlap <George.Dunlap@eu.citrix.com>, Tim Deegan <tim@xen.org>, "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Yang Z Zhang <yang.z.zhang@intel.com>, Tiejun Chen <tiejun.chen@intel.com>
List-Id: xen-devel@lists.xenproject.org

>>> On 21.01.15 at 03:30, <kevin.tian@intel.com> wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> Yeah, for the actual E820 the conversion of course has to happen.
>> But I think there's no strong need for it to be done on the variant
>> obtainable via hypercall - it would only destroy information, and who
>> knows what having that piece of information available may be good
>> for in the future.
> 
> If not destroying the new flag, it may break BIOS or OS if they don't know
> the new flag. So I'd interpret the life cycle of new flag bit only valid
> between hypercall return and constructing actual e820, and it will be
> translated into E820_RESERVE in actual e820 if no conflict is detected.

That's what I said above. I'm advocating for keeping the flag set only
in what the hypercall returns.

Jan