From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Chen, Tiejun" <tiejun.chen@intel.com>
Subject: Re: [v3][PATCH 03/16] xen/vtd: create RMRR mapping
Date: Fri, 19 Jun 2015 08:37:10 +0800
Message-ID: <55836436.5050108@intel.com>
References: <1433985325-16676-1-git-send-email-tiejun.chen@intel.com>
	<1433985325-16676-4-git-send-email-tiejun.chen@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D126289FEF@SHSMSX101.ccr.corp.intel.com>
	<5579558C.30709@intel.com>
	<20150611140729.GC1734@deinos.phlegethon.org>
	<557A4745.1030608@intel.com> <557A74EE.5090805@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12628B9F3@SHSMSX101.ccr.corp.intel.com>
	<557A7887.3030104@intel.com>
	<20150618100733.GB27209@deinos.phlegethon.org>
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: <20150618100733.GB27209@deinos.phlegethon.org>
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: Tim Deegan <tim@xen.org>
Cc: "Tian, Kevin" <kevin.tian@intel.com>, "wei.liu2@citrix.com" <wei.liu2@citrix.com>, "ian.campbell@citrix.com" <ian.campbell@citrix.com>, "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>, "Ian.Jackson@eu.citrix.com" <Ian.Jackson@eu.citrix.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "stefano.stabellini@citrix.com" <stefano.stabellini@citrix.com>, "jbeulich@suse.com" <jbeulich@suse.com>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
List-Id: xen-devel@lists.xenproject.org

On 2015/6/18 18:07, Tim Deegan wrote:
> At 14:13 +0800 on 12 Jun (1434118407), Chen, Tiejun wrote:
>>> could you explain why existing guest_physmap_remove_page can't
>>> serve the purpose so you need invent a new identity mapping
>>> specific one? For unmapping suppose it should be common regardless
>>> of whether it's identity-mapped or not. :-)
>>
>> I have some concerns here:
>>
>> #1. guest_physmap_remove_page() is a void function without a returning
>> value, so you still need a little change.
>
> I'd be happy with adding a return value to it -- even if other callers
> don't check it yet it's better to have errors ignored by callers than
> ignored inside the function. :)
>
>> #2. guest_physmap_remove_page() doesn't make readable in such a code
>> context;
>>
>> rmrr_identity_mapping()
>> {
>>       ...
>>       guest_physmap_remove_page()
>>       ...
>> }
>
> I think it's fine there.
>
> In general I'd prefer to avoid the code duplication of another helper
> function if we can.
>

Fine to me.

Thanks
Tiejun