From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
Date: Tue, 28 Jul 2015 19:12:11 +0000 [thread overview]
Message-ID: <55B7D40B.5080903@oracle.com> (raw)
In-Reply-To: <1438095769-2560-5-git-send-email-julien.grall@citrix.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Julien Grall <julien.grall@citrix.com>, xen-devel@lists.xenproject.org
Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
linux-kernel@vger.kernel.org,
"Russell King" <linux@arm.linux.org.uk>,
"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
"David Vrabel" <david.vrabel@citrix.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, "Roger Pau Monné" <roger.pau@citrix.com>,
"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
"Wei Liu" <wei.liu2@citrix.com>,
"Juergen Gross" <jgross@suse.com>,
"James E.J. Bottomley" <JBottomley@odin.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Jiri Slaby" <jslaby@suse.com>,
"Jean-Christophe Plagniol-Villard" <plagnioj@jcrosoft.com>,
"Tomi Valkeinen" <tomi.valkeinen@ti.com>,
linux-input@vger.kernel.org, netdev@vger.kernel.org,
linux-scsi@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-fbdev@vger.kernel.org
Subject: Re: [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
Date: Tue, 28 Jul 2015 15:12:11 -0400 [thread overview]
Message-ID: <55B7D40B.5080903@oracle.com> (raw)
In-Reply-To: <1438095769-2560-5-git-send-email-julien.grall@citrix.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Julien Grall <julien.grall@citrix.com>, xen-devel@lists.xenproject.org
Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
linux-kernel@vger.kernel.org,
"Russell King" <linux@arm.linux.org.uk>,
"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
"David Vrabel" <david.vrabel@citrix.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, "Roger Pau Monné" <roger.pau@citrix.com>,
"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
"Wei Liu" <wei.liu2@citrix.com>,
"Juergen Gross" <jgross@suse.com>,
"James E.J. Bottomley" <JBottomley@odin.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Jiri Slaby" <jslaby@suse.com>,
"Jean-Christophe Plagniol-Villard" <plagnioj@jcrosoft.com>,
"Tomi Valkeinen" <tomi.valkeinen@ti.com>,
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
Date: Tue, 28 Jul 2015 15:12:11 -0400 [thread overview]
Message-ID: <55B7D40B.5080903@oracle.com> (raw)
In-Reply-To: <1438095769-2560-5-git-send-email-julien.grall@citrix.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: boris.ostrovsky@oracle.com (Boris Ostrovsky)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
Date: Tue, 28 Jul 2015 15:12:11 -0400 [thread overview]
Message-ID: <55B7D40B.5080903@oracle.com> (raw)
In-Reply-To: <1438095769-2560-5-git-send-email-julien.grall@citrix.com>
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
next prev parent reply other threads:[~2015-07-28 19:12 UTC|newest]
Thread overview: 153+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-28 15:02 [PATCH 0/8] Use correctly the Xen memory terminologies in Linux Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` [PATCH 1/8] arm/xen: Remove helpers which are PV specific Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-31 10:44 ` Stefano Stabellini
2015-07-31 10:44 ` Stefano Stabellini
2015-07-31 10:44 ` Stefano Stabellini
2015-07-31 10:55 ` Ian Campbell
2015-07-31 10:55 ` Ian Campbell
2015-08-04 16:36 ` [Xen-devel] " Julien Grall
2015-08-04 16:36 ` Julien Grall
2015-08-04 16:36 ` Julien Grall
2015-07-31 10:55 ` Ian Campbell
2015-07-28 15:02 ` [PATCH 2/8] xen: Make clear that swiotlb and biomerge are dealing with DMA address Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:52 ` [Xen-devel] " David Vrabel
2015-07-28 15:52 ` David Vrabel
2015-07-28 16:06 ` Julien Grall
2015-07-28 16:06 ` [Xen-devel] " Julien Grall
2015-07-28 16:06 ` Julien Grall
2015-07-31 10:54 ` Stefano Stabellini
2015-07-31 10:54 ` Stefano Stabellini
2015-07-31 10:54 ` Stefano Stabellini
2015-07-28 15:52 ` David Vrabel
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` [PATCH 3/8] arm/xen: implement correctly pfn_to_mfn Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` [PATCH 4/8] xen: Use the correctly the Xen memory terminologies Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 17:16 ` [Xen-devel] " David Vrabel
2015-07-28 17:16 ` David Vrabel
2015-07-28 17:16 ` David Vrabel
2015-07-28 17:16 ` David Vrabel
2015-07-28 17:16 ` David Vrabel
2015-07-29 11:06 ` Julien Grall
2015-07-29 11:06 ` Julien Grall
2015-07-29 11:06 ` Julien Grall
2015-07-29 11:06 ` Julien Grall
2015-07-29 11:06 ` Julien Grall
2015-07-29 11:06 ` Julien Grall
2015-07-28 17:16 ` David Vrabel
2015-07-28 19:12 ` Boris Ostrovsky [this message]
2015-07-28 19:12 ` Boris Ostrovsky
2015-07-28 19:12 ` Boris Ostrovsky
2015-07-28 19:12 ` Boris Ostrovsky
2015-07-29 11:25 ` Julien Grall
2015-07-29 11:25 ` Julien Grall
2015-07-29 11:25 ` Julien Grall
2015-07-29 11:25 ` Julien Grall
2015-07-29 11:25 ` Julien Grall
2015-07-29 11:25 ` Julien Grall
2015-07-29 14:14 ` Boris Ostrovsky
2015-07-29 14:14 ` Boris Ostrovsky
2015-07-29 14:14 ` Boris Ostrovsky
2015-07-29 14:14 ` Boris Ostrovsky
2015-07-29 14:23 ` Julien Grall
2015-07-29 14:23 ` Julien Grall
2015-07-29 14:23 ` Julien Grall
2015-07-29 14:23 ` Julien Grall
2015-07-29 14:23 ` Julien Grall
2015-07-29 14:23 ` Julien Grall
2015-07-29 14:51 ` Boris Ostrovsky
2015-07-29 14:51 ` Boris Ostrovsky
2015-07-29 14:51 ` Boris Ostrovsky
2015-07-29 14:51 ` Boris Ostrovsky
2015-07-29 14:51 ` Boris Ostrovsky
2015-07-29 14:14 ` Boris Ostrovsky
2015-07-28 19:12 ` Boris Ostrovsky
2015-07-28 19:39 ` Chris (Christopher) Brand
2015-07-28 19:39 ` [Xen-devel] " Chris (Christopher) Brand
2015-07-28 19:39 ` Chris (Christopher) Brand
2015-07-28 19:39 ` Chris (Christopher) Brand
2015-07-28 19:39 ` Chris (Christopher) Brand
2015-07-28 19:39 ` Chris (Christopher) Brand
2015-07-28 19:39 ` Chris (Christopher) Brand
2015-07-29 11:27 ` Julien Grall
2015-07-29 11:27 ` [Xen-devel] " Julien Grall
2015-07-29 11:27 ` Julien Grall
2015-07-29 11:27 ` Julien Grall
2015-07-29 11:27 ` Julien Grall
2015-07-29 11:27 ` Julien Grall
2015-07-29 10:13 ` Wei Liu
2015-07-29 10:13 ` Wei Liu
2015-07-29 10:13 ` Wei Liu
2015-07-29 10:13 ` Wei Liu
2015-07-29 10:13 ` Wei Liu
2015-07-29 11:35 ` Julien Grall
2015-07-29 11:35 ` [Xen-devel] " Julien Grall
2015-07-29 11:35 ` Julien Grall
2015-07-29 11:35 ` Julien Grall
2015-07-29 11:35 ` Julien Grall
2015-07-29 11:35 ` Julien Grall
2015-07-29 11:38 ` David Vrabel
2015-07-29 11:38 ` [Xen-devel] " David Vrabel
2015-07-29 11:38 ` David Vrabel
2015-07-29 11:38 ` David Vrabel
2015-07-29 11:38 ` David Vrabel
2015-07-29 11:39 ` Wei Liu
2015-07-29 11:39 ` [Xen-devel] " Wei Liu
2015-07-29 11:39 ` Wei Liu
2015-07-29 11:39 ` Wei Liu
2015-07-29 11:39 ` Wei Liu
2015-07-29 11:39 ` Wei Liu
2015-07-31 11:02 ` Stefano Stabellini
2015-07-31 11:02 ` Stefano Stabellini
2015-07-31 11:02 ` Stefano Stabellini
2015-07-31 11:02 ` Stefano Stabellini
2015-07-31 11:02 ` Stefano Stabellini
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` [PATCH 5/8] xen/tmem: Use page_to_gfn rather than pfn_to_gfn Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` [PATCH 6/8] video/xen-fbfront: Further s/MFN/GFN clean-up Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 17:16 ` [Xen-devel] " David Vrabel
2015-07-28 17:16 ` David Vrabel
2015-07-28 17:16 ` David Vrabel
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` [PATCH 7/8] hvc/xen: " Julien Grall
2015-07-28 17:17 ` David Vrabel
2015-07-28 17:17 ` [Xen-devel] " David Vrabel
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` [PATCH 8/8] xen/privcmd: Further s/MFN/GFN/ clean-up Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 17:19 ` David Vrabel
[not found] ` <1438095769-2560-9-git-send-email-julien.grall-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
2015-07-28 17:19 ` [Xen-devel] " David Vrabel
2015-07-28 17:19 ` David Vrabel
2015-07-28 17:19 ` David Vrabel
2015-07-28 21:06 ` [PATCH 0/8] Use correctly the Xen memory terminologies in Linux H. Peter Anvin
2015-07-28 21:06 ` H. Peter Anvin
2015-07-28 21:06 ` H. Peter Anvin
2015-07-28 21:06 ` H. Peter Anvin
2015-07-28 21:06 ` H. Peter Anvin
2015-07-28 21:12 ` [Xen-devel] " Andrew Cooper
2015-07-28 21:12 ` Andrew Cooper
2015-07-28 21:12 ` Andrew Cooper
2015-07-28 21:12 ` Andrew Cooper
2015-07-28 21:12 ` Andrew Cooper
2015-07-28 21:12 ` Andrew Cooper
2015-07-29 11:02 ` Julien Grall
2015-07-29 11:02 ` Julien Grall
2015-07-29 11:02 ` Julien Grall
2015-07-29 11:02 ` Julien Grall
2015-07-29 11:02 ` Julien Grall
2015-07-29 11:02 ` Julien Grall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55B7D40B.5080903@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.