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.gr...@arm.com> > > > Acked-by: Jan Beulich <jbeul...@suse.com> > > > > > > --- > > > Cc: Stefano Stabellini <sstabell...@kernel.org> > > > Cc: Jan Beulich <jbeul...@suse.com> > > > Cc: Andrew Cooper <andrew.coop...@citrix.com> > > > Cc: George Dunlap <george.dun...@eu.citrix.com> > > > Cc: Ian Jackson <ian.jack...@eu.citrix.com> > > > Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> > > > Cc: Tim Deegan <t...@xen.org> > > > Cc: Wei Liu <wei.l...@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
