From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Date: Wed, 29 Jul 2015 14:23:03 +0000 Subject: Re: [PATCH 4/8] xen: Use the correctly the Xen memory terminologies Message-Id: <55B8E1C7.6070608@citrix.com> List-Id: References: <1438095769-2560-1-git-send-email-julien.grall@citrix.com> <1438095769-2560-5-git-send-email-julien.grall@citrix.com> <55B7D40B.5080903@oracle.com> <55B8B846.2060103@citrix.com> <55B8DFD7.6070107@oracle.com> In-Reply-To: <55B8DFD7.6070107@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-arm-kernel@lists.infradead.org On 29/07/15 15:14, Boris Ostrovsky wrote: >> static inline unsigned long pfn_to_gfn(unsigned long pfn) >> { >> if (xen_feature(XENFEAT_autotranslated_physmap)) >> return pfn; >> else >> return pfn_to_mfn(pfn); >> } > > > But you'd still say 'op.arg1.mfn = pfn_to_gfn(pfn);' in xen_do_pin() > i.e. assign GFN to MFN, right? That's what I was referring to. Well no. I would use op.arg1.mfn = pfn_to_mfn(pfn) given that the code, if I'm right, is only executed for PV. mfn = pfn_to_gfn(...) was valid too because on PV is always an MFN. The suggestion of pfn_to_mfn was just for more readability, > (In general, I am not sure a guest should ever use 'mfn' as it is purely > a hypervisor construct. Including p2m, which I think should really be > p2g as this is what we use to figure out what to stick into page tables) I think avoid to use mfn in the hypervisor interface is out-of-scope for this series. If we ever want to modify the Xen API in Linux, we should do in sync with Xen to avoid inconsistency on naming. Anyway, the oddity of mfn = pfn_to_gfn(...) is mostly contained in the x86 specific code. I don't mind to either add pfn_to_mfn and use it or add a comment /* PV-specific so mfn = gfn */ for every use of mfn pfn_to_gfn(...). Regards, -- Julien Grall From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH 4/8] xen: Use the correctly the Xen memory terminologies Date: Wed, 29 Jul 2015 15:23:03 +0100 Message-ID: <55B8E1C7.6070608@citrix.com> References: <1438095769-2560-1-git-send-email-julien.grall@citrix.com> <1438095769-2560-5-git-send-email-julien.grall@citrix.com> <55B7D40B.5080903@oracle.com> <55B8B846.2060103@citrix.com> <55B8DFD7.6070107@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55B8DFD7.6070107@oracle.com> Sender: linux-kernel-owner@vger.kernel.org To: Boris Ostrovsky , xen-devel@lists.xenproject.org Cc: linux-fbdev@vger.kernel.org, "H. Peter Anvin" , Jiri Slaby , stefano.stabellini@eu.citrix.com, Russell King , linux-scsi@vger.kernel.org, x86@kernel.org, Tomi Valkeinen , linux-input@vger.kernel.org, Jean-Christophe Plagniol-Villard , ian.campbell@citrix.com, Konrad Rzeszutek Wilk , "James E.J. Bottomley" , Thomas Gleixner , Ingo Molnar , linux-arm-kernel@lists.infradead.org, Juergen Gross , Wei Liu , Greg Kroah-Hartman , Dmitry Torokhov , linux-kernel@vger.kernel.org, David Vrabel , netdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, =?win List-Id: linux-input@vger.kernel.org On 29/07/15 15:14, Boris Ostrovsky wrote: >> static inline unsigned long pfn_to_gfn(unsigned long pfn) >> { >> if (xen_feature(XENFEAT_autotranslated_physmap)) >> return pfn; >> else >> return pfn_to_mfn(pfn); >> } > > > But you'd still say 'op.arg1.mfn = pfn_to_gfn(pfn);' in xen_do_pin() > i.e. assign GFN to MFN, right? That's what I was referring to. Well no. I would use op.arg1.mfn = pfn_to_mfn(pfn) given that the code, if I'm right, is only executed for PV. mfn = pfn_to_gfn(...) was valid too because on PV is always an MFN. The suggestion of pfn_to_mfn was just for more readability, > (In general, I am not sure a guest should ever use 'mfn' as it is purely > a hypervisor construct. Including p2m, which I think should really be > p2g as this is what we use to figure out what to stick into page tables) I think avoid to use mfn in the hypervisor interface is out-of-scope for this series. If we ever want to modify the Xen API in Linux, we should do in sync with Xen to avoid inconsistency on naming. Anyway, the oddity of mfn = pfn_to_gfn(...) is mostly contained in the x86 specific code. I don't mind to either add pfn_to_mfn and use it or add a comment /* PV-specific so mfn == gfn */ for every use of mfn = pfn_to_gfn(...). Regards, -- Julien Grall From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 157171A11A8 for ; Thu, 30 Jul 2015 00:24:03 +1000 (AEST) Message-ID: <55B8E1C7.6070608@citrix.com> Date: Wed, 29 Jul 2015 15:23:03 +0100 From: Julien Grall MIME-Version: 1.0 To: Boris Ostrovsky , CC: , "H. Peter Anvin" , "Jiri Slaby" , , Russell King , , , Tomi Valkeinen , , Jean-Christophe Plagniol-Villard , , Konrad Rzeszutek Wilk , "James E.J. Bottomley" , Thomas Gleixner , Ingo Molnar , , Juergen Gross , "Wei Liu" , Greg Kroah-Hartman , Dmitry Torokhov , , David Vrabel , , , =?windows-1252?Q?Roger_Pau_Monn=E9?= 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> <55B7D40B.5080903@oracle.com> <55B8B846.2060103@citrix.com> <55B8DFD7.6070107@oracle.com> In-Reply-To: <55B8DFD7.6070107@oracle.com> Content-Type: text/plain; charset="windows-1252" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 29/07/15 15:14, Boris Ostrovsky wrote: >> static inline unsigned long pfn_to_gfn(unsigned long pfn) >> { >> if (xen_feature(XENFEAT_autotranslated_physmap)) >> return pfn; >> else >> return pfn_to_mfn(pfn); >> } > > > But you'd still say 'op.arg1.mfn = pfn_to_gfn(pfn);' in xen_do_pin() > i.e. assign GFN to MFN, right? That's what I was referring to. Well no. I would use op.arg1.mfn = pfn_to_mfn(pfn) given that the code, if I'm right, is only executed for PV. mfn = pfn_to_gfn(...) was valid too because on PV is always an MFN. The suggestion of pfn_to_mfn was just for more readability, > (In general, I am not sure a guest should ever use 'mfn' as it is purely > a hypervisor construct. Including p2m, which I think should really be > p2g as this is what we use to figure out what to stick into page tables) I think avoid to use mfn in the hypervisor interface is out-of-scope for this series. If we ever want to modify the Xen API in Linux, we should do in sync with Xen to avoid inconsistency on naming. Anyway, the oddity of mfn = pfn_to_gfn(...) is mostly contained in the x86 specific code. I don't mind to either add pfn_to_mfn and use it or add a comment /* PV-specific so mfn == gfn */ for every use of mfn = pfn_to_gfn(...). Regards, -- Julien Grall From mboxrd@z Thu Jan 1 00:00:00 1970 From: julien.grall@citrix.com (Julien Grall) Date: Wed, 29 Jul 2015 15:23:03 +0100 Subject: [PATCH 4/8] xen: Use the correctly the Xen memory terminologies In-Reply-To: <55B8DFD7.6070107@oracle.com> References: <1438095769-2560-1-git-send-email-julien.grall@citrix.com> <1438095769-2560-5-git-send-email-julien.grall@citrix.com> <55B7D40B.5080903@oracle.com> <55B8B846.2060103@citrix.com> <55B8DFD7.6070107@oracle.com> Message-ID: <55B8E1C7.6070608@citrix.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 29/07/15 15:14, Boris Ostrovsky wrote: >> static inline unsigned long pfn_to_gfn(unsigned long pfn) >> { >> if (xen_feature(XENFEAT_autotranslated_physmap)) >> return pfn; >> else >> return pfn_to_mfn(pfn); >> } > > > But you'd still say 'op.arg1.mfn = pfn_to_gfn(pfn);' in xen_do_pin() > i.e. assign GFN to MFN, right? That's what I was referring to. Well no. I would use op.arg1.mfn = pfn_to_mfn(pfn) given that the code, if I'm right, is only executed for PV. mfn = pfn_to_gfn(...) was valid too because on PV is always an MFN. The suggestion of pfn_to_mfn was just for more readability, > (In general, I am not sure a guest should ever use 'mfn' as it is purely > a hypervisor construct. Including p2m, which I think should really be > p2g as this is what we use to figure out what to stick into page tables) I think avoid to use mfn in the hypervisor interface is out-of-scope for this series. If we ever want to modify the Xen API in Linux, we should do in sync with Xen to avoid inconsistency on naming. Anyway, the oddity of mfn = pfn_to_gfn(...) is mostly contained in the x86 specific code. I don't mind to either add pfn_to_mfn and use it or add a comment /* PV-specific so mfn == gfn */ for every use of mfn = pfn_to_gfn(...). Regards, -- Julien Grall From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH 4/8] xen: Use the correctly the Xen memory terminologies Date: Wed, 29 Jul 2015 15:23:03 +0100 Message-ID: <55B8E1C7.6070608@citrix.com> References: <1438095769-2560-1-git-send-email-julien.grall@citrix.com> <1438095769-2560-5-git-send-email-julien.grall@citrix.com> <55B7D40B.5080903@oracle.com> <55B8B846.2060103@citrix.com> <55B8DFD7.6070107@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Cc: , "H. Peter Anvin" , "Jiri Slaby" , , Russell King , , , Tomi Valkeinen , , Jean-Christophe Plagniol-Villard , , Konrad Rzeszutek Wilk , "James E.J. Bottomley" , Thomas Gleixner , Ingo Molnar , , Juergen Gross , "Wei Liu" , Greg Kroah-Hartman , Dmitry Torokhov , , David Vrabel , , , =?win To: Boris Ostrovsky , Return-path: In-Reply-To: <55B8DFD7.6070107@oracle.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On 29/07/15 15:14, Boris Ostrovsky wrote: >> static inline unsigned long pfn_to_gfn(unsigned long pfn) >> { >> if (xen_feature(XENFEAT_autotranslated_physmap)) >> return pfn; >> else >> return pfn_to_mfn(pfn); >> } > > > But you'd still say 'op.arg1.mfn = pfn_to_gfn(pfn);' in xen_do_pin() > i.e. assign GFN to MFN, right? That's what I was referring to. Well no. I would use op.arg1.mfn = pfn_to_mfn(pfn) given that the code, if I'm right, is only executed for PV. mfn = pfn_to_gfn(...) was valid too because on PV is always an MFN. The suggestion of pfn_to_mfn was just for more readability, > (In general, I am not sure a guest should ever use 'mfn' as it is purely > a hypervisor construct. Including p2m, which I think should really be > p2g as this is what we use to figure out what to stick into page tables) I think avoid to use mfn in the hypervisor interface is out-of-scope for this series. If we ever want to modify the Xen API in Linux, we should do in sync with Xen to avoid inconsistency on naming. Anyway, the oddity of mfn = pfn_to_gfn(...) is mostly contained in the x86 specific code. I don't mind to either add pfn_to_mfn and use it or add a comment /* PV-specific so mfn == gfn */ for every use of mfn = pfn_to_gfn(...). Regards, -- Julien Grall