[PATCH v5 11/22] tty/hvc: xen: Use xen page definition

2015-09-30 Thread Julien Grall
The console ring is always based on the page granularity of Xen.

Signed-off-by: Julien Grall <julien.gr...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>

---
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: Jiri Slaby <jsl...@suse.cz>
Cc: David Vrabel <david.vra...@citrix.com>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: linuxppc-dev@lists.ozlabs.org

Changes in v4:
- The ring is always 4K (i.e XEN_PAGE_SIZE), so no need to
map with PAGE_SIZE. This was correctly done in v2 but lost with
the rebase to the "s/mfn/gfn/" series

Changes in v3:
- Some changes has been moved in the series "Use correctly the
Xen memory terminologies in Linux".
- Add Stefano's reviewed-by
---
 drivers/tty/hvc/hvc_xen.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 10beb15..fa816b7 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -230,7 +230,7 @@ static int xen_hvm_console_init(void)
if (r < 0 || v == 0)
goto err;
gfn = v;
-   info->intf = xen_remap(gfn << PAGE_SHIFT, PAGE_SIZE);
+   info->intf = xen_remap(gfn << XEN_PAGE_SHIFT, XEN_PAGE_SIZE);
if (info->intf == NULL)
goto err;
info->vtermno = HVC_COOKIE;
@@ -472,7 +472,7 @@ static int xencons_resume(struct xenbus_device *dev)
struct xencons_info *info = dev_get_drvdata(>dev);
 
xencons_disconnect_backend(info);
-   memset(info->intf, 0, PAGE_SIZE);
+   memset(info->intf, 0, XEN_PAGE_SIZE);
return xencons_connect_backend(dev, info);
 }
 
-- 
2.1.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v4 11/20] tty/hvc: xen: Use xen page definition

2015-09-07 Thread Julien Grall
The console ring is always based on the page granularity of Xen.

Signed-off-by: Julien Grall <julien.gr...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>

---
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: Jiri Slaby <jsl...@suse.cz>
Cc: David Vrabel <david.vra...@citrix.com>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: linuxppc-dev@lists.ozlabs.org

Changes in v4:
- The ring is always 4K (i.e XEN_PAGE_SIZE), so no need to
map with PAGE_SIZE. This was correctly done in v2 but lost with
the rebase to the "s/mfn/gfn/" series

Changes in v3:
- Some changes has been moved in the series "Use correctly the
Xen memory terminologies in Linux".
- Add Stefano's reviewed-by
---
 drivers/tty/hvc/hvc_xen.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 10beb15..fa816b7 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -230,7 +230,7 @@ static int xen_hvm_console_init(void)
if (r < 0 || v == 0)
goto err;
gfn = v;
-   info->intf = xen_remap(gfn << PAGE_SHIFT, PAGE_SIZE);
+   info->intf = xen_remap(gfn << XEN_PAGE_SHIFT, XEN_PAGE_SIZE);
if (info->intf == NULL)
goto err;
info->vtermno = HVC_COOKIE;
@@ -472,7 +472,7 @@ static int xencons_resume(struct xenbus_device *dev)
struct xencons_info *info = dev_get_drvdata(>dev);
 
xencons_disconnect_backend(info);
-   memset(info->intf, 0, PAGE_SIZE);
+   memset(info->intf, 0, XEN_PAGE_SIZE);
return xencons_connect_backend(dev, info);
 }
 
-- 
2.1.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [Xen-devel] [PATCH v3 11/20] tty/hvc: xen: Use xen page definition

2015-08-28 Thread Julien Grall
Hi David,

On 20/08/15 10:55, David Vrabel wrote:
 On 07/08/15 17:46, Julien Grall wrote:
 The console ring is always based on the page granularity of Xen.
 [...]
 --- a/drivers/tty/hvc/hvc_xen.c
 +++ b/drivers/tty/hvc/hvc_xen.c
 @@ -230,7 +230,7 @@ static int xen_hvm_console_init(void)
  if (r  0 || v == 0)
  goto err;
  gfn = v;
 -info-intf = xen_remap(gfn  PAGE_SHIFT, PAGE_SIZE);
 +info-intf = xen_remap(gfn  XEN_PAGE_SHIFT, PAGE_SIZE);
 
 You need XEN_PAGE_SIZE here I think...

Right, I did the mistake while rebase on my s/mfn/gfn/ series. I will
fix it in the next version.

Regards,

-- 
Julien Grall
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 4/9] xen: Use correctly the Xen memory terminologies

2015-08-07 Thread Julien Grall
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.

Note that page_to_mfn has been renamed to xen_page_to_gfn to avoid a
name to close to the KVM function gfn_to_page.

Take also the opportunity to simplify simple construction such
as pfn_to_mfn(page_to_pfn(page)) into xen_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
Reviewed-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
Acked-by: Dmitry Torokhov dmitry.torok...@gmail.com
Acked-by: Wei Liu wei.l...@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: Ian Campbell ian.campb...@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-dev@lists.ozlabs.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org

Note that I've re-introduced in v2 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.

Changes in v3:
- Add Stefano's reviewed-by (except for the x86 bits)
- Add Wei (netback) and Dmitry's (input) acked-by
- Keep the VIRT - MACHINE macro in the same order as before
in arch/x86/include/asm/xen/page.h
- Rename page_to_gfn to xen_page_to_gfn to avoid confusion with
the KVM function gfn_to_page.
- Typoes in the commit title

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 | 31 +--
 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  | 12 +++-
 drivers/scsi/xen-scsifront.c| 10 +-
 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, 73 insertions(+), 51 deletions(-)

diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index 911d62b..1279563 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

[PATCH v3 0/9] Use correctly the Xen memory terminologies

2015-08-07 Thread Julien Grall
Hi all,

This patch series aims to use the memory terminologies described in
include/xen/mm.h [1] for Linux xen code.

The differences from v2 is minor but I resent it because my 64K series depends
on this series.

Linux is using mistakenly MFN when GFN is meant, I suspect this is because the
first support of Xen was for PV. This has brought some misimplementation
of memory helpers on ARM and make the developper confused about the expected
behavior.

For instance, with pfn_to_mfn, we expect to get a MFN based on the name.
Although, if we look at the implementation on x86, it's returning a GFN.
Most of the callers are also using it this way.

The first 2 patches of this series is ARM related in order to remove
PV specific helpers which should not be used and fixing the implementation of
pfn_to_mfn.

The rest of the series is here rename most of the usage in the common code
of MFN to GFN. I also took the opportunity to replace most of the call to
pfn_to_gfn in the common code by page_to_gfn avoid construction such
as pfn_to_gfn(page_to_pfn(...).

Note the one xen-blkfront will be dropped by 64K series [2], I can include
here if necessary.

Major changes in v3:
- More typoes
- Rename page_to_gfn to xen_page_to_gfn to avoid confusing with the
KVM function gfn_to_page

Major changes in v2:
- Use bfn rather than dfn for the DMA address
- Re-introduced pfn_to_mfn for PV guests only
- Typoes

For all the changes see in each patch.

This series is based on xentip for-linus-4.3 branch. A branch with all the
patches can be found here:
git://xenbits.xen.org/people/julieng/linux-arm.git branch page-renaming-v3

It has been boot tested on ARM64 and ARM32 and only built for x86.
I would be happy if someone can give a try on x86 as I don't have a x86
box setup with Xen.

Sincerely yours,

[1] 
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e758ed14f390342513405dd766e874934573e6cb
[2] https://lkml.org/lkml/2015/7/9/628

Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: David Vrabel david.vra...@citrix.com
Cc: Dmitry Torokhov dmitry.torok...@gmail.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: H. Peter Anvin h...@zytor.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ingo Molnar mi...@redhat.com
Cc: James E.J. Bottomley jbottom...@odin.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Jiri Slaby jsl...@suse.com
Cc: Juergen Gross jgr...@suse.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-in...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: Roger Pau Monné roger@citrix.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Wei Liu wei.l...@citrix.com
Cc: x...@kernel.org



Julien Grall (9):
  arm/xen: Remove helpers which are PV specific
  xen: Make clear that swiotlb and biomerge are dealing with DMA address
  arm/xen: implement correctly pfn_to_mfn
  xen: Use correctly the Xen memory terminologies
  xen/tmem: Use xen_page_to_gfn rather than pfn_to_gfn
  video/xen-fbfront: Further s/MFN/GFN clean-up
  hvc/xen: Further s/MFN/GFN clean-up
  xen/privcmd: Further s/MFN/GFN/ clean-up
  xen/xenbus: Rename the variable xen_store_mfn to xen_store_gfn

 arch/arm/include/asm/xen/page.h | 44 -
 arch/arm/xen/enlighten.c| 18 +++---
 arch/arm/xen/mm.c   |  4 +--
 arch/x86/include/asm/xen/page.h | 35 +-
 arch/x86/xen/mmu.c  | 32 
 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  | 12 +
 drivers/scsi/xen-scsifront.c| 10 
 drivers/tty/hvc/hvc_xen.c   | 18 ++
 drivers/video/fbdev/xen-fbfront.c   | 20 +++
 drivers/xen/balloon.c   |  2 +-
 drivers/xen/biomerge.c  |  6 ++---
 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/privcmd.c   | 44 -
 drivers/xen/swiotlb-xen.c   | 16 ++--
 drivers/xen/tmem.c  | 21 ++--
 drivers/xen/xenbus/xenbus_client.c  |  2 +-
 drivers/xen/xenbus/xenbus_dev_backend.c |  2 +-
 drivers/xen/xenbus/xenbus_probe.c   | 16 ++--
 drivers/xen/xlate_mmu.c | 18 +++---
 include/uapi/xen/privcmd.h  |  4

[PATCH v3 7/9] hvc/xen: Further s/MFN/GFN clean-up

2015-08-07 Thread Julien Grall
HVM_PARAM_CONSOLE_PFN is used to retrieved the console PFN for HVM
guest. It returns a PFN (aka GFN) and not a MFN.

Furthermore, use directly virt_to_gfn for both PV and HVM domain rather
than doing a special case for each of the them.

Signed-off-by: Julien Grall julien.gr...@citrix.com
Reviewed-by: David Vrabel david.vra...@citrix.com

---
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Jiri Slaby jsl...@suse.com
Cc: linuxppc-dev@lists.ozlabs.org

Changes in v2:
- Add David's reviewed-by
---
 drivers/tty/hvc/hvc_xen.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index efe5124..10beb15 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -200,7 +200,7 @@ static int xen_hvm_console_init(void)
 {
int r;
uint64_t v = 0;
-   unsigned long mfn;
+   unsigned long gfn;
struct xencons_info *info;
 
if (!xen_hvm_domain())
@@ -217,7 +217,7 @@ static int xen_hvm_console_init(void)
}
/*
 * If the toolstack (or the hypervisor) hasn't set these values, the
-* default value is 0. Even though mfn = 0 and evtchn = 0 are
+* default value is 0. Even though gfn = 0 and evtchn = 0 are
 * theoretically correct values, in practice they never are and they
 * mean that a legacy toolstack hasn't initialized the pv console 
correctly.
 */
@@ -229,8 +229,8 @@ static int xen_hvm_console_init(void)
r = hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, v);
if (r  0 || v == 0)
goto err;
-   mfn = v;
-   info-intf = xen_remap(mfn  PAGE_SHIFT, PAGE_SIZE);
+   gfn = v;
+   info-intf = xen_remap(gfn  PAGE_SHIFT, PAGE_SIZE);
if (info-intf == NULL)
goto err;
info-vtermno = HVC_COOKIE;
@@ -375,7 +375,6 @@ static int xencons_connect_backend(struct xenbus_device 
*dev,
int ret, evtchn, devid, ref, irq;
struct xenbus_transaction xbt;
grant_ref_t gref_head;
-   unsigned long mfn;
 
ret = xenbus_alloc_evtchn(dev, evtchn);
if (ret)
@@ -390,10 +389,6 @@ static int xencons_connect_backend(struct xenbus_device 
*dev,
irq, domU_hvc_ops, 256);
if (IS_ERR(info-hvc))
return PTR_ERR(info-hvc);
-   if (xen_pv_domain())
-   mfn = virt_to_gfn(info-intf);
-   else
-   mfn = __pa(info-intf)  PAGE_SHIFT;
ret = gnttab_alloc_grant_references(1, gref_head);
if (ret  0)
return ret;
@@ -402,7 +397,7 @@ static int xencons_connect_backend(struct xenbus_device 
*dev,
if (ref  0)
return ref;
gnttab_grant_foreign_access_ref(ref, info-xbdev-otherend_id,
-   mfn, 0);
+   virt_to_gfn(info-intf), 0);
 
  again:
ret = xenbus_transaction_start(xbt);
-- 
2.1.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [Xen-devel] [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies

2015-08-06 Thread Julien Grall
Hi,


On 04/08/15 19:12, Julien Grall wrote:
 diff --git a/include/xen/page.h b/include/xen/page.h
 index c5ed20b..e7e1425 100644
 --- a/include/xen/page.h
 +++ b/include/xen/page.h
 @@ -3,9 +3,9 @@
  
  #include asm/xen/page.h
  
 -static inline unsigned long page_to_mfn(struct page *page)
 +static inline unsigned long page_to_gfn(struct page *page)
  {
 - return pfn_to_mfn(page_to_pfn(page));
 + return pfn_to_gfn(page_to_pfn(page));
  }

I've just noticed that there is a function gfn_to_page used for KVM.

Maybe I should rename page_to_gfn to xen_page_to_gfn to avoid confusion
with KVM one?

Regards,

-- 
Julien Grall
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [Xen-devel] [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies

2015-08-06 Thread Julien Grall
On 06/08/15 12:06, Stefano Stabellini wrote:
 On Thu, 6 Aug 2015, Julien Grall wrote:
 Hi,


 On 04/08/15 19:12, Julien Grall wrote:
 diff --git a/include/xen/page.h b/include/xen/page.h
 index c5ed20b..e7e1425 100644
 --- a/include/xen/page.h
 +++ b/include/xen/page.h
 @@ -3,9 +3,9 @@
  
  #include asm/xen/page.h
  
 -static inline unsigned long page_to_mfn(struct page *page)
 +static inline unsigned long page_to_gfn(struct page *page)
  {
 -   return pfn_to_mfn(page_to_pfn(page));
 +   return pfn_to_gfn(page_to_pfn(page));
  }

 I've just noticed that there is a function gfn_to_page used for KVM.

 Maybe I should rename page_to_gfn to xen_page_to_gfn to avoid confusion
 with KVM one?
 
 Yeah, prepending xen would help to avoid namespace pollution.

Will do. May I keep your Reviewed-by for this mechanical change?

Regards,

-- 
Julien Grall
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies

2015-08-05 Thread Julien Grall
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [Xen-devel] [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies

2015-08-05 Thread Julien Grall
On 05/08/15 13:19, Boris Ostrovsky wrote:
 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;
  }

The identity function is only for ARM guest which are always
auto-translated (arch/arm/include/asm/xen/page.h).

The x86 version contains a check if the guest is auto-translated or not
(arch/x86/include/asm/xen/page.):

static inline unsigned long pfn_to_gfn(unsigned long pfn)
{
if (xen_feature(XENFEAT_auto_translated_physmap))
return pfn;
else
return pfn_to_mfn(pfn);
}

Regards,

-- 
Julien Grall
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies

2015-08-04 Thread Julien Grall
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-dev@lists.ozlabs.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org

---
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

[PATCH v2 7/8] hvc/xen: Further s/MFN/GFN clean-up

2015-08-04 Thread Julien Grall
HVM_PARAM_CONSOLE_PFN is used to retrieved the console PFN for HVM
guest. It returns a PFN (aka GFN) and not a MFN.

Furthermore, use directly virt_to_gfn for both PV and HVM domain rather
than doing a special case for each of the them.

Signed-off-by: Julien Grall julien.gr...@citrix.com
Reviewed-by: David Vrabel david.vra...@citrix.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Jiri Slaby jsl...@suse.com
Cc: linuxppc-dev@lists.ozlabs.org

---
Changes in v2:
- Add David's reviewed-by
---
 drivers/tty/hvc/hvc_xen.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index efe5124..10beb15 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -200,7 +200,7 @@ static int xen_hvm_console_init(void)
 {
int r;
uint64_t v = 0;
-   unsigned long mfn;
+   unsigned long gfn;
struct xencons_info *info;
 
if (!xen_hvm_domain())
@@ -217,7 +217,7 @@ static int xen_hvm_console_init(void)
}
/*
 * If the toolstack (or the hypervisor) hasn't set these values, the
-* default value is 0. Even though mfn = 0 and evtchn = 0 are
+* default value is 0. Even though gfn = 0 and evtchn = 0 are
 * theoretically correct values, in practice they never are and they
 * mean that a legacy toolstack hasn't initialized the pv console 
correctly.
 */
@@ -229,8 +229,8 @@ static int xen_hvm_console_init(void)
r = hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, v);
if (r  0 || v == 0)
goto err;
-   mfn = v;
-   info-intf = xen_remap(mfn  PAGE_SHIFT, PAGE_SIZE);
+   gfn = v;
+   info-intf = xen_remap(gfn  PAGE_SHIFT, PAGE_SIZE);
if (info-intf == NULL)
goto err;
info-vtermno = HVC_COOKIE;
@@ -375,7 +375,6 @@ static int xencons_connect_backend(struct xenbus_device 
*dev,
int ret, evtchn, devid, ref, irq;
struct xenbus_transaction xbt;
grant_ref_t gref_head;
-   unsigned long mfn;
 
ret = xenbus_alloc_evtchn(dev, evtchn);
if (ret)
@@ -390,10 +389,6 @@ static int xencons_connect_backend(struct xenbus_device 
*dev,
irq, domU_hvc_ops, 256);
if (IS_ERR(info-hvc))
return PTR_ERR(info-hvc);
-   if (xen_pv_domain())
-   mfn = virt_to_gfn(info-intf);
-   else
-   mfn = __pa(info-intf)  PAGE_SHIFT;
ret = gnttab_alloc_grant_references(1, gref_head);
if (ret  0)
return ret;
@@ -402,7 +397,7 @@ static int xencons_connect_backend(struct xenbus_device 
*dev,
if (ref  0)
return ref;
gnttab_grant_foreign_access_ref(ref, info-xbdev-otherend_id,
-   mfn, 0);
+   virt_to_gfn(info-intf), 0);
 
  again:
ret = xenbus_transaction_start(xbt);
-- 
2.1.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 0/8] Use correctly the Xen memory terminologies in Linux

2015-08-04 Thread Julien Grall
Hi all,

This patch series aims to use the memory terminologies described in
include/xen/mm.h [1] for Linux xen code.

Linux is using mistakenly MFN when GFN is meant, I suspect this is because the
first support of Xen was for PV. This has brought some misimplementation
of memory helpers on ARM and make the developper confused about the expected
behavior.

For instance, with pfn_to_mfn, we expect to get a MFN based on the name.
Although, if we look at the implementation on x86, it's returning a GFN.
Most of the callers are also using it this way.

The first 2 patches of this series is ARM related in order to remove
PV specific helpers which should not be used and fixing the implementation of
pfn_to_mfn.

The rest of the series is here rename most of the usage in the common code
of MFN to GFN. I also took the opportunity to replace most of the call to
pfn_to_gfn in the common code by page_to_gfn avoid construction such
as pfn_to_gfn(page_to_pfn(...).

Note the one xen-blkfront will be dropped by 64K series [2], I can include it
if necessary.

Major changes in v2:
- Use bfn rather than dfn for the DMA address
- Re-introduced pfn_to_mfn for PV guests only
- Typoes

For all the changes see in each patch.

This series is based on linus's branch. A branch with all the patches
can be found here:
git://xenbits.xen.org/people/julieng/linux-arm.git branch page-renaming-v2

It was been boot tested on ARM64 and only built for x86 and ARM32.
I would be happy if someone can give a try on x86 as I don't have a x86
box setup with Xen.

Sincerely yours,

[1] 
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e758ed14f390342513405dd766e874934573e6cb
[2] https://lkml.org/lkml/2015/7/9/628

Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: David Vrabel david.vra...@citrix.com
Cc: Dmitry Torokhov dmitry.torok...@gmail.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: H. Peter Anvin h...@zytor.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ingo Molnar mi...@redhat.com
Cc: James E.J. Bottomley jbottom...@odin.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Jiri Slaby jsl...@suse.com
Cc: Juergen Gross jgr...@suse.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-in...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: Roger Pau Monné roger@citrix.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Wei Liu wei.l...@citrix.com
Cc: x...@kernel.org

Julien Grall (8):
  arm/xen: Remove helpers which are PV specific
  xen: Make clear that swiotlb and biomerge are dealing with DMA address
  arm/xen: implement correctly pfn_to_mfn
  xen: Use the correctly the Xen memory terminologies
  xen/tmem: Use page_to_gfn rather than pfn_to_gfn
  video/xen-fbfront: Further s/MFN/GFN clean-up
  hvc/xen: Further s/MFN/GFN clean-up
  xen/privcmd: Further s/MFN/GFN/ clean-up

 arch/arm/include/asm/xen/page.h | 44 -
 arch/arm/xen/enlighten.c| 18 +++---
 arch/arm/xen/mm.c   |  4 +--
 arch/x86/include/asm/xen/page.h | 37 +--
 arch/x86/xen/mmu.c  | 32 
 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   | 18 ++
 drivers/video/fbdev/xen-fbfront.c   | 20 +++
 drivers/xen/balloon.c   |  2 +-
 drivers/xen/biomerge.c  |  6 ++---
 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/privcmd.c   | 44 -
 drivers/xen/swiotlb-xen.c   | 16 ++--
 drivers/xen/tmem.c  | 21 ++--
 drivers/xen/xenbus/xenbus_client.c  |  2 +-
 drivers/xen/xenbus/xenbus_dev_backend.c |  2 +-
 drivers/xen/xenbus/xenbus_probe.c   |  8 +++---
 drivers/xen/xlate_mmu.c | 18 +++---
 include/uapi/xen/privcmd.h  |  4 +++
 include/xen/page.h  |  4 +--
 include/xen/xen-ops.h   | 10 
 29 files changed, 183 insertions(+), 170 deletions(-)

-- 
2.1.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/8] Use correctly the Xen memory terminologies in Linux

2015-07-29 Thread Julien Grall
On 28/07/15 16:02, Julien Grall wrote:
 Hi all,
 
 This patch series aims to use the memory terminologies described in
 include/linux/mm.h [1] for Linux xen code.

I mistakenly wrote the wrong include here. It should be include/xen/mm.h
from the Xen tree:

http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e758ed14f390342513405dd766e874934573e6cb

Regards,

-- 
Julien Grall
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [Xen-devel] [PATCH 4/8] xen: Use the correctly the Xen memory terminologies

2015-07-29 Thread Julien Grall
Hi Chris,

On 28/07/15 20:39, Chris (Christopher) Brand 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
 Typo : brought
 Perhaps resulted in would be better ?
 
 misimplementation of helpers on ARM and make the developper confused the 
 expected behavior.
 Typo: developer.
 I'd also suggest ...and confused developers about the
 
 [...]
 
 For clarity and avoid new confusion, replace any reference of mfn into gnf 
 in any helpers used by PV drivers.
 Typo : gfn
 I'd suggest ...replace any reference to mfn with gfn...
 
 [...]

Thanks for telling me the typoes. I will fix it in the next version of
this series.

Regards,

-- 
Julien Grall
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 4/8] xen: Use the correctly the Xen memory terminologies

2015-07-29 Thread Julien Grall
Hi Boris,

On 28/07/15 20:12, Boris Ostrovsky wrote:
 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)

This operation is only used for PV guests, right?

IHMO re-introducing pfn_to_mfn for PV-guests only (i.e with a BUG_ON to
ensure no usage for auto-translated guest) would be the best solution.
It would avoid to have different name than the hypersivor one in the
hypercall interface. It will also make clear that virt_to_machine  co
is only PV specific.

I though doing this but I preferred to defer it to x86 expert as my
knowledge for x86 Xen is very limited. I don't know where it's more
suitable to use MFN or GFN. I guess this file (mmu.c) is mostly PV specific?

Would something like below fine for you?

static inline unsigned long pfn_to_mfn(unsigned long pfn)
{
unsigned long mfn;

BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));

mfn = __pfn_to_mfn(pfn);
if (mfn != INVALID_P2M_ENTRY)
mfn = ~(FOREIGN_FRAME_BIT | IDENTITY_FRAME_BIT);

return mfn;
}

static inline unsigned long pfn_to_gfn(unsigned long pfn)
{
if (xen_feature(XENFEAT_autotranslated_physmap))
return pfn;
else
return pfn_to_mfn(pfn);
}

Similar splitting would be done for gfn_to_pfn and mfn_to_pfn.

Regards,

-- 
Julien Grall
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [Xen-devel] [PATCH 4/8] xen: Use the correctly the Xen memory terminologies

2015-07-29 Thread Julien Grall
Hi Wei,

On 29/07/15 11:13, Wei Liu wrote:
 On Tue, Jul 28, 2015 at 04:02:45PM +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);
 
 Reviewed-by: Wei Liu wei.l...@citrix.com
 
 One possible improvement is to change gmfn in copy_gop to gfn as well.
 But that's outside of netback code.

The structure gnttab_copy is part of the hypervisor interface. Is it
fine to differ on the naming between Xen and Linux?

Or maybe we could do the change in the public headers in Xen repo too.
Is it fine to do field renaming in public headers?

Regards,

-- 
Julien Grall
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [Xen-devel] [PATCH 4/8] xen: Use the correctly the Xen memory terminologies

2015-07-29 Thread Julien Grall
On 28/07/15 18:16, David Vrabel wrote:
 On 28/07/15 16:02, 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 the benefit of other subsystem maintainers, this is a purely
 mechanical change in Xen-specific terminology.  It doesn't need reviews
 or acks from non-Xen people (IMO).
 
 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.

 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.

 I think it may be possible to do further clean up in the x86 code to
 ensure that helpers returning machine address (such as virt_address) is
 not used by no auto-translated guests. I will let x86 xen expert doing
 it.
 
 Reviewed-by: David Vrabel david.vra...@citrix.com
 
 It looks a bit odd to use GFN in some of the PV code where the
 hypervisor API uses MFN but overall I think using the correct
 terminology where possible is best.  But I'd like to have Boris's or
 Konrad's opinion on this.

I was thinking to introduce mfn_to_pfn  co which would be used only for
PV-guest (a BUG_ON would be here to ensure it) and hypercall related.

I didn't do it as I haven't much knowledge on x86 Xen and was able to
decide where I have to use pfn_to_mfn.

Regards,

-- 
Julien Grall
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 4/8] xen: Use the correctly the Xen memory terminologies

2015-07-29 Thread Julien Grall
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 0/8] Use correctly the Xen memory terminologies in Linux

2015-07-28 Thread Julien Grall
Hi all,

This patch series aims to use the memory terminologies described in
include/linux/mm.h [1] for Linux xen code.

Linux is using mistakenly MFN when GFN is meant, I suspect this is because the
first support of Xen was for PV. This has brought some misimplementation
of memory helpers on ARM and make the developper confused about the expected
behavior.

For instance, with pfn_to_mfn, we expect to get a MFN based on the name.
Although, if we look at the implementation on x86, it's returning a GFN.
Most of the callers are also using it this way.

The first 2 patches of this series is ARM related in order to remove
PV specific helpers which should not be used and fixing the implementation of
pfn_to_mfn.

The rest of the series is here rename most of the usage in the common code
of MFN to GFN. I also took the opportunity to replace most of the call to
pfn_to_gfn in the common code by page_to_gfn avoid construction such
as pfn_to_gfn(page_to_pfn(...).

Note the one xen-blkfront will be dropped by 64K series [2], I can include it
if necessary.

This series is based on Linux 4.2-rc4. A branch with all the patches
can be found here:
git://xenbits.xen.org/people/julieng/linux-arm.git branch page-renaming-v1

Sincerely yours,

[1] Xen tree: e758ed14f390342513405dd766e874934573e6cb
[2] https://lkml.org/lkml/2015/7/9/628

Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: David Vrabel david.vra...@citrix.com
Cc: Dmitry Torokhov dmitry.torok...@gmail.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: H. Peter Anvin h...@zytor.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ingo Molnar mi...@redhat.com
Cc: James E.J. Bottomley jbottom...@odin.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Jiri Slaby jsl...@suse.com
Cc: Juergen Gross jgr...@suse.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-in...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: Roger Pau Monné roger@citrix.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Wei Liu wei.l...@citrix.com
Cc: x...@kernel.org

Julien Grall (8):
  arm/xen: Remove helpers which are PV specific
  xen: Make clear that swiotlb and biomerge are dealing with DMA address
  arm/xen: implement correctly pfn_to_mfn
  xen: Use the correctly the Xen memory terminologies
  xen/tmem: Use page_to_gfn rather than pfn_to_gfn
  video/xen-fbfront: Further s/MFN/GFN clean-up
  hvc/xen: Further s/MFN/GFN clean-up
  xen/privcmd: Further s/MFN/GFN/ clean-up

 arch/arm/include/asm/xen/page.h | 44 +++---
 arch/arm/xen/enlighten.c| 18 ++---
 arch/arm/xen/mm.c   |  4 +--
 arch/x86/include/asm/xen/page.h | 34 +--
 arch/x86/xen/enlighten.c|  4 +--
 arch/x86/xen/mmu.c  | 48 -
 arch/x86/xen/p2m.c  | 32 +++---
 arch/x86/xen/setup.c| 12 -
 arch/x86/xen/smp.c  |  4 +--
 arch/x86/xen/suspend.c  |  8 +++---
 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   | 18 +
 drivers/video/fbdev/xen-fbfront.c   | 20 +++---
 drivers/xen/balloon.c   |  2 +-
 drivers/xen/biomerge.c  |  6 ++---
 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/privcmd.c   | 44 +++---
 drivers/xen/swiotlb-xen.c   | 16 +--
 drivers/xen/tmem.c  | 21 +--
 drivers/xen/xenbus/xenbus_client.c  |  2 +-
 drivers/xen/xenbus/xenbus_dev_backend.c |  2 +-
 drivers/xen/xenbus/xenbus_probe.c   |  8 +++---
 drivers/xen/xlate_mmu.c | 18 ++---
 include/uapi/xen/privcmd.h  |  4 +++
 include/xen/page.h  |  4 +--
 include/xen/xen-ops.h   | 10 +++
 33 files changed, 210 insertions(+), 214 deletions(-)

-- 
2.1.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 4/8] xen: Use the correctly the Xen memory terminologies

2015-07-28 Thread Julien Grall
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.

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.

I think it may be possible to do further clean up in the x86 code to
ensure that helpers returning machine address (such as virt_address) is
not used by no auto-translated guests. I will let x86 xen expert doing
it.

[1] Xen tree: 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-dev@lists.ozlabs.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
 arch/arm/include/asm/xen/page.h | 13 +++--
 arch/x86/include/asm/xen/page.h | 30 --
 arch/x86/xen/enlighten.c|  4 ++--
 arch/x86/xen/mmu.c  | 16 
 arch/x86/xen/p2m.c  | 32 
 arch/x86/xen/setup.c| 12 ++--
 arch/x86/xen/smp.c  |  4 ++--
 arch/x86/xen/suspend.c  |  8 
 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 ++--
 25 files changed, 96 insertions(+), 95 deletions(-)

diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index 493471f..f542f68 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 - DMA conversion */
@@ -65,9 +66,9 @@ static inline unsigned long dfn_to_pfn(unsigned long dfn)
 
 #define dfn_to_local_pfn(dfn)  dfn_to_pfn(dfn)
 
-/* VIRT - MACHINE conversion */
-#define virt_to_mfn(v) (pfn_to_mfn(virt_to_pfn(v)))
-#define mfn_to_virt(m) (__va(mfn_to_pfn(m)  PAGE_SHIFT))
+/* VIRT - GUEST conversion */
+#define virt_to_gfn(v) (pfn_to_gfn(virt_to_pfn(v)))
+#define gfn_to_virt(m) (__va(gfn_to_pfn(m)  PAGE_SHIFT))
 
 /* Only used in PV code. However ARM guest is always assimilated as HVM. */
 static inline xmaddr_t arbitrary_virt_to_machine(void *vaddr)
diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 046e91a..72d9f15 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -99,7 +99,7 @@ static inline unsigned long __pfn_to_mfn(unsigned long pfn)
return mfn

[PATCH 7/8] hvc/xen: Further s/MFN/GFN clean-up

2015-07-28 Thread Julien Grall
HVM_PARAM_CONSOLE_PFN is used to retrieved the console PFN for HVM
guest. It returns a PFN (aka GFN) and not a MFN.

Furthermore, use directly virt_to_gfn for both PV and HVM domain rather
than doing a special case for each of the them.

Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Jiri Slaby jsl...@suse.com
Cc: David Vrabel david.vra...@citrix.com
Cc: linuxppc-dev@lists.ozlabs.org
---
 drivers/tty/hvc/hvc_xen.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index efe5124..10beb15 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -200,7 +200,7 @@ static int xen_hvm_console_init(void)
 {
int r;
uint64_t v = 0;
-   unsigned long mfn;
+   unsigned long gfn;
struct xencons_info *info;
 
if (!xen_hvm_domain())
@@ -217,7 +217,7 @@ static int xen_hvm_console_init(void)
}
/*
 * If the toolstack (or the hypervisor) hasn't set these values, the
-* default value is 0. Even though mfn = 0 and evtchn = 0 are
+* default value is 0. Even though gfn = 0 and evtchn = 0 are
 * theoretically correct values, in practice they never are and they
 * mean that a legacy toolstack hasn't initialized the pv console 
correctly.
 */
@@ -229,8 +229,8 @@ static int xen_hvm_console_init(void)
r = hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, v);
if (r  0 || v == 0)
goto err;
-   mfn = v;
-   info-intf = xen_remap(mfn  PAGE_SHIFT, PAGE_SIZE);
+   gfn = v;
+   info-intf = xen_remap(gfn  PAGE_SHIFT, PAGE_SIZE);
if (info-intf == NULL)
goto err;
info-vtermno = HVC_COOKIE;
@@ -375,7 +375,6 @@ static int xencons_connect_backend(struct xenbus_device 
*dev,
int ret, evtchn, devid, ref, irq;
struct xenbus_transaction xbt;
grant_ref_t gref_head;
-   unsigned long mfn;
 
ret = xenbus_alloc_evtchn(dev, evtchn);
if (ret)
@@ -390,10 +389,6 @@ static int xencons_connect_backend(struct xenbus_device 
*dev,
irq, domU_hvc_ops, 256);
if (IS_ERR(info-hvc))
return PTR_ERR(info-hvc);
-   if (xen_pv_domain())
-   mfn = virt_to_gfn(info-intf);
-   else
-   mfn = __pa(info-intf)  PAGE_SHIFT;
ret = gnttab_alloc_grant_references(1, gref_head);
if (ret  0)
return ret;
@@ -402,7 +397,7 @@ static int xencons_connect_backend(struct xenbus_device 
*dev,
if (ref  0)
return ref;
gnttab_grant_foreign_access_ref(ref, info-xbdev-otherend_id,
-   mfn, 0);
+   virt_to_gfn(info-intf), 0);
 
  again:
ret = xenbus_transaction_start(xbt);
-- 
2.1.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 11/20] tty/hvc: xen: Use xen page definition

2015-07-09 Thread Julien Grall
The console ring is always based on the page granularity of Xen.

Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Jiri Slaby jsl...@suse.cz
Cc: David Vrabel david.vra...@citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: linuxppc-dev@lists.ozlabs.org
---
 drivers/tty/hvc/hvc_xen.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index a9d837f..2135944 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -230,7 +230,7 @@ static int xen_hvm_console_init(void)
if (r  0 || v == 0)
goto err;
mfn = v;
-   info-intf = xen_remap(mfn  PAGE_SHIFT, PAGE_SIZE);
+   info-intf = xen_remap(mfn  XEN_PAGE_SHIFT, XEN_PAGE_SIZE);
if (info-intf == NULL)
goto err;
info-vtermno = HVC_COOKIE;
@@ -392,7 +392,7 @@ static int xencons_connect_backend(struct xenbus_device 
*dev,
if (xen_pv_domain())
mfn = virt_to_mfn(info-intf);
else
-   mfn = __pa(info-intf)  PAGE_SHIFT;
+   mfn = __pa(info-intf)  XEN_PAGE_SHIFT;
ret = gnttab_alloc_grant_references(1, gref_head);
if (ret  0)
return ret;
@@ -476,7 +476,7 @@ static int xencons_resume(struct xenbus_device *dev)
struct xencons_info *info = dev_get_drvdata(dev-dev);
 
xencons_disconnect_backend(info);
-   memset(info-intf, 0, PAGE_SIZE);
+   memset(info-intf, 0, XEN_PAGE_SIZE);
return xencons_connect_backend(dev, info);
 }
 
-- 
2.1.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[RFC 14/23] tty/hvc: xen: Use xen page definition

2015-05-14 Thread Julien Grall
The console ring is always based on the page granularity of Xen.

Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Jiri Slaby jsl...@suse.cz
Cc: David Vrabel david.vra...@citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: linuxppc-dev@lists.ozlabs.org
---
 drivers/tty/hvc/hvc_xen.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 5bab1c6..a68d115 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -230,7 +230,7 @@ static int xen_hvm_console_init(void)
if (r  0 || v == 0)
goto err;
mfn = v;
-   info-intf = xen_remap(mfn  PAGE_SHIFT, PAGE_SIZE);
+   info-intf = xen_remap(mfn  XEN_PAGE_SHIFT, XEN_PAGE_SIZE);
if (info-intf == NULL)
goto err;
info-vtermno = HVC_COOKIE;
@@ -392,7 +392,7 @@ static int xencons_connect_backend(struct xenbus_device 
*dev,
if (xen_pv_domain())
mfn = virt_to_mfn(info-intf);
else
-   mfn = __pa(info-intf)  PAGE_SHIFT;
+   mfn = __pa(info-intf)  XEN_PAGE_SHIFT;
ret = gnttab_alloc_grant_references(1, gref_head);
if (ret  0)
return ret;
@@ -476,7 +476,7 @@ static int xencons_resume(struct xenbus_device *dev)
struct xencons_info *info = dev_get_drvdata(dev-dev);
 
xencons_disconnect_backend(info);
-   memset(info-intf, 0, PAGE_SIZE);
+   memset(info-intf, 0, XEN_PAGE_SIZE);
return xencons_connect_backend(dev, info);
 }
 
-- 
2.1.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev