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:
> On 23/06/16 14:06, Stefano Stabellini wrote:
> > On Thu, 23 Jun 2016, Julien Grall wrote:
> > > On 23/06/16 11:20, Stefano Stabellini wrote:
> > > > On Tue, 21 Jun 2016, Julien Grall wrote:
> > > > 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.
> 
> Currently, Aarch32 supports up to 40-bit whilst Aarch64 supports up to 48-bit
> (even 52-bit with ARMv8.2). So this should be ok for now.
> 
> However, pretty much everywhere in Xen we assume that the frame number is
> unsigned long (see mm.c, p2m.c,...). We would have much more work to do than
> this small patch.
> 
> I would rather start to switch to gfn/mfn internally and keep the underlying
> type as "unsigned long" until we effectively need 64-bit frame.
> 
> The main reason is 64-bit frame will result into a bigger binary for ARM32
> with no apparent reason (40-bit is hardcoded in setup_virt_paging). Switching
> to gfn/mfn will allow us to uint64_t where it will be required.

OK.

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