From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [v4][PATCH 03/19] xen/vtd: create RMRR mapping Date: Wed, 24 Jun 2015 15:26:32 +0800 Message-ID: <558A5BA8.9040703@intel.com> References: <1435053450-25131-1-git-send-email-tiejun.chen@intel.com> <1435053450-25131-4-git-send-email-tiejun.chen@intel.com> <55894D4902000078000881D3@mail.emea.novell.com> <558A03CD.3090206@intel.com> <558A6ED30200007800088AD9@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <558A6ED30200007800088AD9@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: Yang Zhang , Kevin Tian , Tim Deegan , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org >> Note actually we just need p2m_remove_page() to unmap these mapping on >> both ept and vt-d sides, and guest_physmap_remove_page is really a >> wrapper of p2m_remove_page(). > > And I agree with Tim regarding the desire to avoid code duplication. > Yet that's no reason to do it asymmetrically: > clear_identity_p2m_entry() could still be an inline (or macro) wrapper > around guest_physmap_remove_page(). That way, apart from making I can define that as a macro close to set_identity_p2m_entry() in p2m.h. > the code above look nicer, if the latter needs extending in the future > for some reason, simply converting the wrapper to a real function is > possible without needing to touch the call site(s). > > This would need to go into patch 2; I wonder whether folding that Yes. > and this one wouldn't be warranted, avoiding the former adding Are you saying to fold patch #2 and patch #3? But shouldn't we always define a new and then use that in practice subsequently? Even with two patches, respectively. Thanks Tiejun > (at that point) dead code. > > Jan > > >