Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753275AbbG1TOG (ORCPT ); Tue, 28 Jul 2015 15:14:06 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:25906 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753177AbbG1TOE (ORCPT ); Tue, 28 Jul 2015 15:14:04 -0400 Message-ID: <55B7D40B.5080903@oracle.com> Date: Tue, 28 Jul 2015 15:12:11 -0400 From: Boris Ostrovsky User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Julien Grall , xen-devel@lists.xenproject.org CC: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, linux-kernel@vger.kernel.org, Russell King , Konrad Rzeszutek Wilk , David Vrabel , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Dmitry Torokhov , Wei Liu , Juergen Gross , "James E.J. Bottomley" , Greg Kroah-Hartman , Jiri Slaby , Jean-Christophe Plagniol-Villard , Tomi Valkeinen , linux-input@vger.kernel.org, netdev@vger.kernel.org, linux-scsi@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-fbdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 4/8] xen: Use the correctly the Xen memory terminologies References: <1438095769-2560-1-git-send-email-julien.grall@citrix.com> <1438095769-2560-5-git-send-email-julien.grall@citrix.com> In-Reply-To: <1438095769-2560-5-git-send-email-julien.grall@citrix.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1612 Lines: 52 On 07/28/2015 11:02 AM, Julien Grall wrote: > Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN > is meant, I suspect this is because the first support for Xen was for > PV. This brough some misimplementation of helpers on ARM and make the > developper confused the expected behavior. > > For instance, with pfn_to_mfn, we expect to get an MFN based on the name. > Although, if we look at the implementation on x86, it's returning a GFN. > > For clarity and avoid new confusion, replace any reference of mfn into > gnf in any helpers used by PV drivers. > @@ -730,7 +730,7 @@ static void xen_do_pin(unsigned level, unsigned long pfn) > struct mmuext_op op; > > op.cmd = level; > - op.arg1.mfn = pfn_to_mfn(pfn); > + op.arg1.mfn = pfn_to_gfn(pfn); This looks slightly odd. It is correct but given that purpose of this series is to make things more clear perhaps we can add another union member (gfn) to mmuext_op.arg1? (Of course, the hypervisor will continue referring to mfn which could still be confusing) > > xen_extend_mmuext_op(&op); > } > @@ -1323,7 +1323,7 @@ static void __xen_write_cr3(bool kernel, unsigned long cr3) > trace_xen_mmu_write_cr3(kernel, cr3); > > if (cr3) > - mfn = pfn_to_mfn(PFN_DOWN(cr3)); > + mfn = pfn_to_gfn(PFN_DOWN(cr3)); Here too. And further down, thoughout this patch. -boris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/