Re: [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
On Tue, Aug 04, 2015 at 07:12:48PM +0100, Julien Grall wrote:
[...]
> diff --git a/drivers/net/xen-netback/netback.c
> b/drivers/net/xen-netback/netback.c
> index 7d50711..3b7b7c3 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -314,7 +314,7 @@ static void xenvif_gop_frag_copy(struct xenvif_queue
> *queue, struct sk_buff *skb
> } else {
> copy_gop->source.domid = DOMID_SELF;
> copy_gop->source.u.gmfn =
> - virt_to_mfn(page_address(page));
> + virt_to_gfn(page_address(page));
> }
> copy_gop->source.offset = offset;
>
> @@ -1284,7 +1284,7 @@ static void xenvif_tx_build_gops(struct xenvif_queue
> *queue,
> queue->tx_copy_ops[*copy_ops].source.offset = txreq.offset;
>
> queue->tx_copy_ops[*copy_ops].dest.u.gmfn =
> - virt_to_mfn(skb->data);
> + virt_to_gfn(skb->data);
> queue->tx_copy_ops[*copy_ops].dest.domid = DOMID_SELF;
> queue->tx_copy_ops[*copy_ops].dest.offset =
> offset_in_page(skb->data);
Acked-by: Wei Liu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
On Wed, Aug 05, 2015 at 11:08:55AM +0100, Stefano Stabellini wrote: > On Tue, 4 Aug 2015, 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 resulted in some misimplementation of helpers on ARM and > > confused developers about 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 to mfn with > > gfn in any helpers used by PV drivers. The x86 code will still keep some > > reference of pfn_to_mfn but exclusively for PV (a BUG_ON has been added > > to ensure this). No changes as been made in the hypercall field, even > > though they may be invalid, in order to keep the same as the defintion > > in xen repo. > > > > Take also the opportunity to simplify simple construction such > > as pfn_to_mfn(page_to_pfn(page)) into page_to_gfn. More complex clean up > > will come in follow-up patches. > > > > [1] > > http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e758ed14f390342513405dd766e874934573e6cb > > > > Signed-off-by: Julien Grall > > Cc: Stefano Stabellini > > Cc: Russell King > > Cc: Konrad Rzeszutek Wilk > > Cc: Boris Ostrovsky > > Cc: David Vrabel > > Cc: Thomas Gleixner > > Cc: Ingo Molnar > > Cc: "H. Peter Anvin" > > Cc: x...@kernel.org > > Cc: "Roger Pau Monné" > > Cc: Dmitry Torokhov > > Cc: Ian Campbell > > Cc: Wei Liu > > Cc: Juergen Gross > > Cc: "James E.J. Bottomley" > > Cc: Greg Kroah-Hartman > > Cc: Jiri Slaby > > Cc: Jean-Christophe Plagniol-Villard > > Cc: Tomi Valkeinen > > Cc: linux-in...@vger.kernel.org > > Cc: net...@vger.kernel.org > > Cc: linux-s...@vger.kernel.org > > Cc: linuxppc-...@lists.ozlabs.org > > Cc: linux-fb...@vger.kernel.org > > Cc: linux-arm-ker...@lists.infradead.org > > Aside from the x86 bits: > > Reviewed-by: Stefano Stabellini Not really important, but just in case anyone waits for my ack on input bits: Acked-by: Dmitry Torokhov Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
On 08/05/2015 06:51 AM, Julien Grall wrote:
diff --git a/drivers/video/fbdev/xen-fbfront.c
b/drivers/video/fbdev/xen-fbfront.c
index 09dc447..25e3cce 100644
--- a/drivers/video/fbdev/xen-fbfront.c
+++ b/drivers/video/fbdev/xen-fbfront.c
@@ -539,7 +539,7 @@ static int xenfb_remove(struct xenbus_device *dev)
static unsigned long vmalloc_to_mfn(void *address)
{
-return pfn_to_mfn(vmalloc_to_pfn(address));
+return pfn_to_gfn(vmalloc_to_pfn(address));
}
Are you sure? This will return vmalloc_to_pfn(address)).
I guess you mean vmalloc_to_mfn will return vmalloc_to_pfn?
If so, it will be only the case on auto-translated case (because pfn ==
gfn). In the case of PV, the mfn will be returned.
How will mfn be returned on PV when pfn_to_gfn() is an identity function?
static inline unsigned long pfn_to_gfn(unsigned long pfn)
{
return pfn;
}
-boris
Although, this function is misnamed. It's fixed in a follow-up patch
(see #6) because it's required more renaming than this function. I
didn't want to add such changes within this patch.
Regards,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
Hi Boris,
On 05/08/15 00:16, Boris Ostrovsky wrote:
> On 08/04/2015 02:12 PM, Julien Grall wrote:
>> /*
>>* We detect special mappings in one of two ways:
>> @@ -217,9 +232,13 @@ static inline unsigned long
>> bfn_to_local_pfn(unsigned long mfn)
>> /* VIRT <-> MACHINE conversion */
>> #define virt_to_machine(v)(phys_to_machine(XPADDR(__pa(v
>> -#define virt_to_pfn(v) (PFN_DOWN(__pa(v)))
>> #define virt_to_mfn(v)(pfn_to_mfn(virt_to_pfn(v)))
>> #define mfn_to_virt(m)(__va(mfn_to_pfn(m) << PAGE_SHIFT))
>> +#define virt_to_pfn(v) (PFN_DOWN(__pa(v)))
>
> This looks like unnecessary change.
Right, I made the mistake when I re-introduced virt_to_mfn in this
version. It was dropped in the previous one.
>> diff --git a/drivers/video/fbdev/xen-fbfront.c
>> b/drivers/video/fbdev/xen-fbfront.c
>> index 09dc447..25e3cce 100644
>> --- a/drivers/video/fbdev/xen-fbfront.c
>> +++ b/drivers/video/fbdev/xen-fbfront.c
>> @@ -539,7 +539,7 @@ static int xenfb_remove(struct xenbus_device *dev)
>> static unsigned long vmalloc_to_mfn(void *address)
>> {
>> -return pfn_to_mfn(vmalloc_to_pfn(address));
>> +return pfn_to_gfn(vmalloc_to_pfn(address));
>> }
>
> Are you sure? This will return vmalloc_to_pfn(address)).
I guess you mean vmalloc_to_mfn will return vmalloc_to_pfn?
If so, it will be only the case on auto-translated case (because pfn ==
gfn). In the case of PV, the mfn will be returned.
Although, this function is misnamed. It's fixed in a follow-up patch
(see #6) because it's required more renaming than this function. I
didn't want to add such changes within this patch.
Regards,
--
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
On Tue, 4 Aug 2015, 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 resulted in some misimplementation of helpers on ARM and
> confused developers about 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 to mfn with
> gfn in any helpers used by PV drivers. The x86 code will still keep some
> reference of pfn_to_mfn but exclusively for PV (a BUG_ON has been added
> to ensure this). No changes as been made in the hypercall field, even
> though they may be invalid, in order to keep the same as the defintion
> in xen repo.
>
> Take also the opportunity to simplify simple construction such
> as pfn_to_mfn(page_to_pfn(page)) into page_to_gfn. More complex clean up
> will come in follow-up patches.
>
> [1]
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e758ed14f390342513405dd766e874934573e6cb
>
> Signed-off-by: Julien Grall
> Cc: Stefano Stabellini
> Cc: Russell King
> Cc: Konrad Rzeszutek Wilk
> Cc: Boris Ostrovsky
> Cc: David Vrabel
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: x...@kernel.org
> Cc: "Roger Pau Monné"
> Cc: Dmitry Torokhov
> Cc: Ian Campbell
> Cc: Wei Liu
> Cc: Juergen Gross
> Cc: "James E.J. Bottomley"
> Cc: Greg Kroah-Hartman
> Cc: Jiri Slaby
> Cc: Jean-Christophe Plagniol-Villard
> Cc: Tomi Valkeinen
> Cc: linux-in...@vger.kernel.org
> Cc: net...@vger.kernel.org
> Cc: linux-s...@vger.kernel.org
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: linux-fb...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
Aside from the x86 bits:
Reviewed-by: Stefano Stabellini
> Note that I've re-introduced mfn_to_pfn & co only for x86 PV code.
> The helpers contain a BUG_ON to ensure that it's never called for
> auto-translated guests. I did as best as my can to determine whether
> mfn or gfn helpers should be used. Although, I haven't tried to boot
> it.
>
> It may be possible to do further cleanup in the mmu.c where I found
> some check to auto-translated. I'm not sure why given that the pvmmu
> callback are only used for non-auto translated guest.
>
> Finally, given those changes, I didn't retain the Reviewed-by/Acked-by.
>
> Changes in v2:
> - Give directly the URL to the commit rather than the commit ID
> - xenstored_local_init: keep the cast to void *
> - Typoes
> - Keep pfn_to_mfn for x86 and PV-only. The *mfn* helpers are
> used in arch/x86/xen for enlighten.c, mmu.c, p2m.c, setup.c,
> smp.c and mm.c
> ---
> arch/arm/include/asm/xen/page.h | 13 +++--
> arch/x86/include/asm/xen/page.h | 33
> ++---
> arch/x86/xen/smp.c | 2 +-
> drivers/block/xen-blkfront.c| 6 +++---
> drivers/input/misc/xen-kbdfront.c | 4 ++--
> drivers/net/xen-netback/netback.c | 4 ++--
> drivers/net/xen-netfront.c | 8
> drivers/scsi/xen-scsifront.c| 8 +++-
> drivers/tty/hvc/hvc_xen.c | 5 +++--
> drivers/video/fbdev/xen-fbfront.c | 4 ++--
> drivers/xen/balloon.c | 2 +-
> drivers/xen/events/events_base.c| 2 +-
> drivers/xen/events/events_fifo.c| 4 ++--
> drivers/xen/gntalloc.c | 3 ++-
> drivers/xen/manage.c| 2 +-
> drivers/xen/tmem.c | 4 ++--
> drivers/xen/xenbus/xenbus_client.c | 2 +-
> drivers/xen/xenbus/xenbus_dev_backend.c | 2 +-
> drivers/xen/xenbus/xenbus_probe.c | 8 +++-
> include/xen/page.h | 4 ++--
> 20 files changed, 69 insertions(+), 51 deletions(-)
>
> diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> index 087d86e..51e5bf1 100644
> --- a/arch/arm/include/asm/xen/page.h
> +++ b/arch/arm/include/asm/xen/page.h
> @@ -34,14 +34,15 @@ typedef struct xpaddr {
> unsigned long __pfn_to_mfn(unsigned long pfn);
> extern struct rb_root phys_to_mach;
>
> -static inline unsigned long pfn_to_mfn(unsigned long pfn)
> +/* Pseudo-physical <-> Guest conversion */
> +static inline unsigned long pfn_to_gfn(unsigned long pfn)
> {
> return pfn;
> }
>
> -static inline unsigned long mfn_to_pfn(unsigned long mfn)
> +static inline unsigned long gfn_to_pfn(unsigned long gfn)
> {
> - return mfn;
> + return gfn;
> }
>
> /* Pseudo-physical <-> BUS conversion */
> @@ -65,9 +66,9 @@ static inline unsigned long bfn_to_pfn(unsigned long bfn)
>
> #define bfn_to_local_pfn(bfn)bfn_to_pfn(bfn)
>
> -/* VIRT <-> MACHINE conversion */
> -#define virt_to_mfn(v) (pfn_to_mfn(virt_to_pfn(v)))
> -#define
Re: [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
On Tue, 4 Aug 2015, Boris Ostrovsky wrote:
> On 08/04/2015 02:12 PM, Julien Grall wrote:
> > /*
> >* We detect special mappings in one of two ways:
> > @@ -217,9 +232,13 @@ static inline unsigned long bfn_to_local_pfn(unsigned
> > long mfn)
> > /* VIRT <-> MACHINE conversion */
> > #define virt_to_machine(v)(phys_to_machine(XPADDR(__pa(v
> > -#define virt_to_pfn(v) (PFN_DOWN(__pa(v)))
> > #define virt_to_mfn(v)(pfn_to_mfn(virt_to_pfn(v)))
> > #define mfn_to_virt(m)(__va(mfn_to_pfn(m) << PAGE_SHIFT))
> > +#define virt_to_pfn(v) (PFN_DOWN(__pa(v)))
>
> This looks like unnecessary change.
>
>
> > diff --git a/drivers/video/fbdev/xen-fbfront.c
> > b/drivers/video/fbdev/xen-fbfront.c
> > index 09dc447..25e3cce 100644
> > --- a/drivers/video/fbdev/xen-fbfront.c
> > +++ b/drivers/video/fbdev/xen-fbfront.c
> > @@ -539,7 +539,7 @@ static int xenfb_remove(struct xenbus_device *dev)
> > static unsigned long vmalloc_to_mfn(void *address)
> > {
> > - return pfn_to_mfn(vmalloc_to_pfn(address));
> > + return pfn_to_gfn(vmalloc_to_pfn(address));
> > }
>
> Are you sure? This will return vmalloc_to_pfn(address)).
I think that is OK: there is no behavioural change here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
On Tue, 4 Aug 2015, Boris Ostrovsky wrote:
On 08/04/2015 02:12 PM, Julien Grall wrote:
/*
* We detect special mappings in one of two ways:
@@ -217,9 +232,13 @@ static inline unsigned long bfn_to_local_pfn(unsigned
long mfn)
/* VIRT - MACHINE conversion */
#define virt_to_machine(v)(phys_to_machine(XPADDR(__pa(v
-#define virt_to_pfn(v) (PFN_DOWN(__pa(v)))
#define virt_to_mfn(v)(pfn_to_mfn(virt_to_pfn(v)))
#define mfn_to_virt(m)(__va(mfn_to_pfn(m) PAGE_SHIFT))
+#define virt_to_pfn(v) (PFN_DOWN(__pa(v)))
This looks like unnecessary change.
diff --git a/drivers/video/fbdev/xen-fbfront.c
b/drivers/video/fbdev/xen-fbfront.c
index 09dc447..25e3cce 100644
--- a/drivers/video/fbdev/xen-fbfront.c
+++ b/drivers/video/fbdev/xen-fbfront.c
@@ -539,7 +539,7 @@ static int xenfb_remove(struct xenbus_device *dev)
static unsigned long vmalloc_to_mfn(void *address)
{
- return pfn_to_mfn(vmalloc_to_pfn(address));
+ return pfn_to_gfn(vmalloc_to_pfn(address));
}
Are you sure? This will return vmalloc_to_pfn(address)).
I think that is OK: there is no behavioural change here.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
On Tue, 4 Aug 2015, 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 resulted in some misimplementation of helpers on ARM and
confused developers about 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 to mfn with
gfn in any helpers used by PV drivers. The x86 code will still keep some
reference of pfn_to_mfn but exclusively for PV (a BUG_ON has been added
to ensure this). No changes as been made in the hypercall field, even
though they may be invalid, in order to keep the same as the defintion
in xen repo.
Take also the opportunity to simplify simple construction such
as pfn_to_mfn(page_to_pfn(page)) into page_to_gfn. More complex clean up
will come in follow-up patches.
[1]
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e758ed14f390342513405dd766e874934573e6cb
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: David Vrabel david.vra...@citrix.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: x...@kernel.org
Cc: Roger Pau Monné roger@citrix.com
Cc: Dmitry Torokhov dmitry.torok...@gmail.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
Cc: Juergen Gross jgr...@suse.com
Cc: James E.J. Bottomley jbottom...@odin.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Jiri Slaby jsl...@suse.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-in...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-s...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Aside from the x86 bits:
Reviewed-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
Note that I've re-introduced mfn_to_pfn co only for x86 PV code.
The helpers contain a BUG_ON to ensure that it's never called for
auto-translated guests. I did as best as my can to determine whether
mfn or gfn helpers should be used. Although, I haven't tried to boot
it.
It may be possible to do further cleanup in the mmu.c where I found
some check to auto-translated. I'm not sure why given that the pvmmu
callback are only used for non-auto translated guest.
Finally, given those changes, I didn't retain the Reviewed-by/Acked-by.
Changes in v2:
- Give directly the URL to the commit rather than the commit ID
- xenstored_local_init: keep the cast to void *
- Typoes
- Keep pfn_to_mfn for x86 and PV-only. The *mfn* helpers are
used in arch/x86/xen for enlighten.c, mmu.c, p2m.c, setup.c,
smp.c and mm.c
---
arch/arm/include/asm/xen/page.h | 13 +++--
arch/x86/include/asm/xen/page.h | 33
++---
arch/x86/xen/smp.c | 2 +-
drivers/block/xen-blkfront.c| 6 +++---
drivers/input/misc/xen-kbdfront.c | 4 ++--
drivers/net/xen-netback/netback.c | 4 ++--
drivers/net/xen-netfront.c | 8
drivers/scsi/xen-scsifront.c| 8 +++-
drivers/tty/hvc/hvc_xen.c | 5 +++--
drivers/video/fbdev/xen-fbfront.c | 4 ++--
drivers/xen/balloon.c | 2 +-
drivers/xen/events/events_base.c| 2 +-
drivers/xen/events/events_fifo.c| 4 ++--
drivers/xen/gntalloc.c | 3 ++-
drivers/xen/manage.c| 2 +-
drivers/xen/tmem.c | 4 ++--
drivers/xen/xenbus/xenbus_client.c | 2 +-
drivers/xen/xenbus/xenbus_dev_backend.c | 2 +-
drivers/xen/xenbus/xenbus_probe.c | 8 +++-
include/xen/page.h | 4 ++--
20 files changed, 69 insertions(+), 51 deletions(-)
diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index 087d86e..51e5bf1 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -34,14 +34,15 @@ typedef struct xpaddr {
unsigned long __pfn_to_mfn(unsigned long pfn);
extern struct rb_root phys_to_mach;
-static inline unsigned long pfn_to_mfn(unsigned long pfn)
+/* Pseudo-physical - Guest conversion */
+static inline unsigned long pfn_to_gfn(unsigned long pfn)
{
return pfn;
}
-static inline unsigned long mfn_to_pfn(unsigned long mfn)
+static inline unsigned long gfn_to_pfn(unsigned long gfn)
{
- return mfn;
+ return gfn;
Re: [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
Hi Boris,
On 05/08/15 00:16, Boris Ostrovsky wrote:
On 08/04/2015 02:12 PM, Julien Grall wrote:
/*
* We detect special mappings in one of two ways:
@@ -217,9 +232,13 @@ static inline unsigned long
bfn_to_local_pfn(unsigned long mfn)
/* VIRT - MACHINE conversion */
#define virt_to_machine(v)(phys_to_machine(XPADDR(__pa(v
-#define virt_to_pfn(v) (PFN_DOWN(__pa(v)))
#define virt_to_mfn(v)(pfn_to_mfn(virt_to_pfn(v)))
#define mfn_to_virt(m)(__va(mfn_to_pfn(m) PAGE_SHIFT))
+#define virt_to_pfn(v) (PFN_DOWN(__pa(v)))
This looks like unnecessary change.
Right, I made the mistake when I re-introduced virt_to_mfn in this
version. It was dropped in the previous one.
diff --git a/drivers/video/fbdev/xen-fbfront.c
b/drivers/video/fbdev/xen-fbfront.c
index 09dc447..25e3cce 100644
--- a/drivers/video/fbdev/xen-fbfront.c
+++ b/drivers/video/fbdev/xen-fbfront.c
@@ -539,7 +539,7 @@ static int xenfb_remove(struct xenbus_device *dev)
static unsigned long vmalloc_to_mfn(void *address)
{
-return pfn_to_mfn(vmalloc_to_pfn(address));
+return pfn_to_gfn(vmalloc_to_pfn(address));
}
Are you sure? This will return vmalloc_to_pfn(address)).
I guess you mean vmalloc_to_mfn will return vmalloc_to_pfn?
If so, it will be only the case on auto-translated case (because pfn ==
gfn). In the case of PV, the mfn will be returned.
Although, this function is misnamed. It's fixed in a follow-up patch
(see #6) because it's required more renaming than this function. I
didn't want to add such changes within this patch.
Regards,
--
Julien Grall
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
On 08/05/2015 06:51 AM, Julien Grall wrote:
diff --git a/drivers/video/fbdev/xen-fbfront.c
b/drivers/video/fbdev/xen-fbfront.c
index 09dc447..25e3cce 100644
--- a/drivers/video/fbdev/xen-fbfront.c
+++ b/drivers/video/fbdev/xen-fbfront.c
@@ -539,7 +539,7 @@ static int xenfb_remove(struct xenbus_device *dev)
static unsigned long vmalloc_to_mfn(void *address)
{
-return pfn_to_mfn(vmalloc_to_pfn(address));
+return pfn_to_gfn(vmalloc_to_pfn(address));
}
Are you sure? This will return vmalloc_to_pfn(address)).
I guess you mean vmalloc_to_mfn will return vmalloc_to_pfn?
If so, it will be only the case on auto-translated case (because pfn ==
gfn). In the case of PV, the mfn will be returned.
How will mfn be returned on PV when pfn_to_gfn() is an identity function?
static inline unsigned long pfn_to_gfn(unsigned long pfn)
{
return pfn;
}
-boris
Although, this function is misnamed. It's fixed in a follow-up patch
(see #6) because it's required more renaming than this function. I
didn't want to add such changes within this patch.
Regards,
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
On Wed, Aug 05, 2015 at 11:08:55AM +0100, Stefano Stabellini wrote: On Tue, 4 Aug 2015, 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 resulted in some misimplementation of helpers on ARM and confused developers about 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 to mfn with gfn in any helpers used by PV drivers. The x86 code will still keep some reference of pfn_to_mfn but exclusively for PV (a BUG_ON has been added to ensure this). No changes as been made in the hypercall field, even though they may be invalid, in order to keep the same as the defintion in xen repo. Take also the opportunity to simplify simple construction such as pfn_to_mfn(page_to_pfn(page)) into page_to_gfn. More complex clean up will come in follow-up patches. [1] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e758ed14f390342513405dd766e874934573e6cb Signed-off-by: Julien Grall julien.gr...@citrix.com Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Cc: Russell King li...@arm.linux.org.uk Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com Cc: Boris Ostrovsky boris.ostrov...@oracle.com Cc: David Vrabel david.vra...@citrix.com Cc: Thomas Gleixner t...@linutronix.de Cc: Ingo Molnar mi...@redhat.com Cc: H. Peter Anvin h...@zytor.com Cc: x...@kernel.org Cc: Roger Pau Monné roger@citrix.com Cc: Dmitry Torokhov dmitry.torok...@gmail.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com Cc: Juergen Gross jgr...@suse.com Cc: James E.J. Bottomley jbottom...@odin.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Jiri Slaby jsl...@suse.com Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: linux-in...@vger.kernel.org Cc: net...@vger.kernel.org Cc: linux-s...@vger.kernel.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-fb...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Aside from the x86 bits: Reviewed-by: Stefano Stabellini stefano.stabell...@eu.citrix.com Not really important, but just in case anyone waits for my ack on input bits: Acked-by: Dmitry Torokhov dmitry.torok...@gmail.com Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
On Tue, Aug 04, 2015 at 07:12:48PM +0100, Julien Grall wrote:
[...]
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index 7d50711..3b7b7c3 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -314,7 +314,7 @@ static void xenvif_gop_frag_copy(struct xenvif_queue
*queue, struct sk_buff *skb
} else {
copy_gop-source.domid = DOMID_SELF;
copy_gop-source.u.gmfn =
- virt_to_mfn(page_address(page));
+ virt_to_gfn(page_address(page));
}
copy_gop-source.offset = offset;
@@ -1284,7 +1284,7 @@ static void xenvif_tx_build_gops(struct xenvif_queue
*queue,
queue-tx_copy_ops[*copy_ops].source.offset = txreq.offset;
queue-tx_copy_ops[*copy_ops].dest.u.gmfn =
- virt_to_mfn(skb-data);
+ virt_to_gfn(skb-data);
queue-tx_copy_ops[*copy_ops].dest.domid = DOMID_SELF;
queue-tx_copy_ops[*copy_ops].dest.offset =
offset_in_page(skb-data);
Acked-by: Wei Liu wei.l...@citrix.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
On 08/04/2015 02:12 PM, Julien Grall wrote:
/*
* We detect special mappings in one of two ways:
@@ -217,9 +232,13 @@ static inline unsigned long bfn_to_local_pfn(unsigned long
mfn)
/* VIRT <-> MACHINE conversion */
#define virt_to_machine(v)(phys_to_machine(XPADDR(__pa(v
-#define virt_to_pfn(v) (PFN_DOWN(__pa(v)))
#define virt_to_mfn(v)(pfn_to_mfn(virt_to_pfn(v)))
#define mfn_to_virt(m)(__va(mfn_to_pfn(m) << PAGE_SHIFT))
+#define virt_to_pfn(v) (PFN_DOWN(__pa(v)))
This looks like unnecessary change.
diff --git a/drivers/video/fbdev/xen-fbfront.c
b/drivers/video/fbdev/xen-fbfront.c
index 09dc447..25e3cce 100644
--- a/drivers/video/fbdev/xen-fbfront.c
+++ b/drivers/video/fbdev/xen-fbfront.c
@@ -539,7 +539,7 @@ static int xenfb_remove(struct xenbus_device *dev)
static unsigned long vmalloc_to_mfn(void *address)
{
- return pfn_to_mfn(vmalloc_to_pfn(address));
+ return pfn_to_gfn(vmalloc_to_pfn(address));
}
Are you sure? This will return vmalloc_to_pfn(address)).
-boris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
On 08/04/2015 02:12 PM, Julien Grall wrote:
/*
* We detect special mappings in one of two ways:
@@ -217,9 +232,13 @@ static inline unsigned long bfn_to_local_pfn(unsigned long
mfn)
/* VIRT - MACHINE conversion */
#define virt_to_machine(v)(phys_to_machine(XPADDR(__pa(v
-#define virt_to_pfn(v) (PFN_DOWN(__pa(v)))
#define virt_to_mfn(v)(pfn_to_mfn(virt_to_pfn(v)))
#define mfn_to_virt(m)(__va(mfn_to_pfn(m) PAGE_SHIFT))
+#define virt_to_pfn(v) (PFN_DOWN(__pa(v)))
This looks like unnecessary change.
diff --git a/drivers/video/fbdev/xen-fbfront.c
b/drivers/video/fbdev/xen-fbfront.c
index 09dc447..25e3cce 100644
--- a/drivers/video/fbdev/xen-fbfront.c
+++ b/drivers/video/fbdev/xen-fbfront.c
@@ -539,7 +539,7 @@ static int xenfb_remove(struct xenbus_device *dev)
static unsigned long vmalloc_to_mfn(void *address)
{
- return pfn_to_mfn(vmalloc_to_pfn(address));
+ return pfn_to_gfn(vmalloc_to_pfn(address));
}
Are you sure? This will return vmalloc_to_pfn(address)).
-boris
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
