[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] xen: arm: handle initrd addresses above the 4G boundary



On Mon, 2013-12-09 at 14:11 +0000, Julien Grall wrote:
> 
> On 12/09/2013 02:00 PM, Ian Campbell wrote:
> > On Mon, 2013-12-09 at 13:52 +0000, Julien Grall wrote:
> >>
> >> On 12/09/2013 11:15 AM, Ian Campbell wrote:
> >>> On Fri, 2013-12-06 at 17:39 +0000, Julien Grall wrote:
> >>>>>> Perhaps you update the comment by saying we are assuming bytes is 
> >>>>>> 4-byte
> >>>>>> aligned.
> >>>>>
> >>>>> Maybe it would be better to round up?
> >>>>
> >>>> No because if we round up, we would read to much data. dt_read_number is
> >>>> not able to check the size.
> >>>
> >>> Right.
> >>>
> >>> I think what I shall do is change the caller to accept exactly
> >>> sizeof(u32) or sizeof(u64) bytes and not any value between.
> >>
> >> It's fine to have size between sizeof(u32) or sizeof(u64), the address
> >> will just be truncated.
> >>
> >> We have several location in Xen, where we rely on this behavior.
> >
> > Do you have examples?
> >
> > Since dt_read_number can't cope with anything which isn't a multiple of
> > 32-bits I don't see a problem with rejecting them early instead of
> > waiting until later and failing with an obscure error because an address
> > has been truncated.
> 
> In smp_init_cpus (arch/arm/smpboot.c), Xen only checks that reg_len is 
> greater than the required number of cells.

Hrm, I'm not sure that is setting a precedent which we should be
following elsewhere.

I'm pretty sure ePAPR says that numeric fields should be either 1 or 2
cells. I don't think the fact that Xen is more forgiving in some places
means it has to be everywhere.

Ian.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.