[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |