Re: [Xen-devel] [PATCH] libxc: Fix xc_mem_event.c compilation for ARM

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2014-06-23 at 16:34 +0100, Ian Jackson wrote:
> Julien Grall writes ("[PATCH] libxc: Fix xc_mem_event.c compilation for ARM"):
> > The commit 6ae2df9 "mem_access: Add helper API to setup ring and enable
> > mem_access break libxc compilation for ARM.
> > 
> > This is because xc_map_foreign_map and xc_domain_decrease_reservation_exact
> > is taking an xen_pfn_t in parameters. On ARM, xen_pfn_t is always an 
> > uin64_t.
> 
> I have applied this, mostly because we don't want to have a broken
> build for any length of time, but:
> 
> > -    unsigned long ring_pfn, mmap_pfn;
> > +    unsigned long pfn;
> > +    xen_pfn_t ring_pfn, mmap_pfn;
> ...
> > -    rc1 = xc_get_hvm_param(xch, domain_id, param, &ring_pfn);
> > +    rc1 = xc_get_hvm_param(xch, domain_id, param, &pfn);
> ...
> > -    mmap_pfn = ring_pfn;
> > +    ring_pfn = pfn;
> > +    mmap_pfn = pfn;
> 
> I asked on IRC:
> 
> 16:05 <@Diziet> julieng: If xen_pfn_t is uint64_t and on 32-bit ARM unsigned 
>                 long is uint32_t, how can the xc_get_hvm_param in 
>                 xc_mem_event_enable DTRT ?
> 
> I don't know whether that's a real problem.  (Related seems to be the
> question of whether we support a 32-bit dom0 with 64-bit guests on ARM
> and if not what stops the user from setting up such a thing.)

It's supported, although it's not clear that it is such a useful thing
to be doing on ARM (on x86 32-bit PAE was quite a nice trade off between
memory size vs performance due to the 64-bit syscall overhead, which
doesn't apply to ARM).

I'm _pretty_ sure that the only things which we pass as a pfn to HVM
params are the "magic pfns", which are at a hardcoded guest location
which needs to be under 4GB anyway so that 32-bit non-LPAE guests can
map them, so no danger of an actual overflow. We never see the actual
MFN.

FWIW I think the same issue with HVM parameters would impact 32-bit dom0
on x86 too, but I suppose the magic PFNs have the same property there
too. Luckily I think David's patches sorts it out at the root.

> 
> Thanks,
> Ian.



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