xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Stefano Stabellini <sstabellini@kernel.org>
To: Julien Grall <julien.grall@arm.com>
Cc: Tim Deegan <tim@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	xen-devel@lists.xen.org, Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v3 4/8] xen: Use typesafe gfn in xenmem_add_to_physmap_one
Date: Thu, 23 Jun 2016 14:06:55 +0100 (BST)	[thread overview]
Message-ID: <alpine.DEB.2.10.1606231403420.2575@sstabellini-ThinkPad-X260> (raw)
In-Reply-To: <576BBD5C.5030404@arm.com>

On Thu, 23 Jun 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 23/06/16 11:20, Stefano Stabellini wrote:
> > On Tue, 21 Jun 2016, Julien Grall wrote:
> > > The x86 version of the function xenmem_add_to_physmap_one contains
> > > variable name gpfn and gfn which make the code very confusing.
> > > I have left unchanged for now.
> > > 
> > > Also, rename gpfn to gfn in the ARM version as the latter is the correct
> > > acronym for a guest physical frame.
> > > 
> > > Finally, remove the trailing whitespace around the changes.
> > > 
> > > Signed-off-by: Julien Grall <julien.grall@arm.com>
> > > Acked-by: Jan Beulich <jbeulich@suse.com>
> > > 
> > > ---
> > > Cc: Stefano Stabellini <sstabellini@kernel.org>
> > > Cc: Jan Beulich <jbeulich@suse.com>
> > > Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> > > Cc: George Dunlap <george.dunlap@eu.citrix.com>
> > > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > Cc: Tim Deegan <tim@xen.org>
> > > Cc: Wei Liu <wei.liu2@citrix.com>
> > > 
> > >      Changes in v3:
> > >          - Add Jan's acked-by for non-ARM bits
> > > ---
> > >   xen/arch/arm/mm.c    | 10 +++++-----
> > >   xen/arch/x86/mm.c    | 15 +++++++--------
> > >   xen/common/memory.c  |  6 +++---
> > >   xen/include/xen/mm.h |  2 +-
> > >   4 files changed, 16 insertions(+), 17 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> > > index 5ab9b75..6882d54 100644
> > > --- a/xen/arch/arm/mm.c
> > > +++ b/xen/arch/arm/mm.c
> > > @@ -1046,7 +1046,7 @@ int xenmem_add_to_physmap_one(
> > >       unsigned int space,
> > >       union xen_add_to_physmap_batch_extra extra,
> > >       unsigned long idx,
> > > -    xen_pfn_t gpfn)
> > > +    gfn_t gfn)
> > 
> > I think there is a possible loss of information here: xen_pfn_t is
> > always uint64_t on both ARM and ARM64, while gfn_t is unsigned long with
> > its current definition. Or am I missing something?
> > 
> > In fact, given that ARM supports LPAE, shouldn't gfn by defined as
> > xen_pfn_t in terms of storage size (TYPE_SAFE(xen_pfn_t, gfn)) ?
> 
> With LPAE, ARM32 supports up to 40-bit PA so the frame will be encoded on
> 28-bit. So unsigned long is perfectly fine here.

Somehow I have always assumed that the 40-bit limitation was just
temporary. That ARM in the future will just increase that number up to
64-bit eventually.

If you don't think there is any risk of that happening, then I am fine
with this. We just have to keep in mind that many of the guest
interfaces use xen_pfn_t, which has a different size on ARM.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2016-06-23 13:06 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-21 13:20 [PATCH v3 0/8] xen/arm: Use the typesafes gfn and mfn Julien Grall
2016-06-21 13:20 ` [PATCH v3 1/8] xen/arm: Rename gmfn_to_mfn to gfn_to_mfn and use gfn/mfn typesafe Julien Grall
2016-06-23 10:06   ` Stefano Stabellini
2016-06-21 13:20 ` [PATCH v3 2/8] xen/mm: Introduce a bunch of helpers for the typesafes mfn and gfn Julien Grall
2016-06-22  7:03   ` Jan Beulich
2016-06-21 13:20 ` [PATCH v3 3/8] xen: Use typesafe gfn/mfn in guest_physmap_* helpers Julien Grall
2016-06-23 10:11   ` Stefano Stabellini
2016-06-21 13:20 ` [PATCH v3 4/8] xen: Use typesafe gfn in xenmem_add_to_physmap_one Julien Grall
2016-06-23 10:20   ` Stefano Stabellini
2016-06-23 10:43     ` Julien Grall
2016-06-23 13:06       ` Stefano Stabellini [this message]
2016-06-23 13:33         ` Julien Grall
2016-06-23 13:41           ` Stefano Stabellini
2016-06-23 13:58   ` Stefano Stabellini
2016-06-21 13:20 ` [PATCH v3 5/8] xen/arm: Rename grant_table_gfpn into grant_table_gfn and use the typesafe gfn Julien Grall
2016-06-23 14:00   ` Stefano Stabellini
2016-06-21 13:20 ` [PATCH v3 6/8] xen: Use the typesafe mfn and gfn in map_mmio_regions Julien Grall
2016-06-23 14:05   ` Stefano Stabellini
2016-06-23 14:08     ` Julien Grall
2016-06-23 14:15       ` Stefano Stabellini
2016-06-23 14:58         ` Julien Grall
2016-06-21 13:20 ` [PATCH v3 7/8] xen/arm: Rework the interface of p2m_lookup and use typesafe gfn and mfn Julien Grall
2016-06-23 14:14   ` Stefano Stabellini
2016-06-24 13:58     ` Julien Grall
2016-06-24 14:03       ` Andrew Cooper
2016-06-21 13:20 ` [PATCH v3 8/8] xen/arm: p2m_cache_flush: Use the correct terminology and typesafe gfn 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=alpine.DEB.2.10.1606231403420.2575@sstabellini-ThinkPad-X260 \
    --to=sstabellini@kernel.org \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien.grall@arm.com \
    --cc=tim@xen.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).