Re: [Xen-devel] [PATCH v3 4/8] xen: Use typesafe gfn in xenmem_add_to_physmap_one

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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@xxxxxxx>
> > > Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
> > > 
> > > ---
> > > Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> > > Cc: Jan Beulich <jbeulich@xxxxxxxx>
> > > Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> > > Cc: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
> > > Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> > > Cc: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> > > Cc: Tim Deegan <tim@xxxxxxx>
> > > Cc: Wei Liu <wei.liu2@xxxxxxxxxx>
> > > 
> > >      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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel