[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 3/3] xen/arm: fix mask calculation in pdx_init_mask
>>> On 04.06.19 at 00:02, <sstabellini@xxxxxxxxxx> wrote: > --- a/xen/arch/arm/setup.c > +++ b/xen/arch/arm/setup.c > @@ -482,7 +482,14 @@ static void __init init_pdx(void) > { > paddr_t bank_start, bank_size, bank_end; > > - u64 mask = pdx_init_mask(bootinfo.mem.bank[0].start); > + /* > + * Arm does not have any restrictions on the bits to compress. Pass 0 to > + * let the common code further restrict the mask. > + * > + * If the logic changes in pfn_pdx_hole_setup we might have to > + * update this function too. > + */ > + u64 mask = pdx_init_mask(0x0); Seeing Julien's clarification on the previous version's discussion, how about switching this one to uint64_t as well at this occasion? > --- a/xen/common/pdx.c > +++ b/xen/common/pdx.c > @@ -50,9 +50,12 @@ static u64 __init fill_mask(u64 mask) > return mask; > } > > +/* > + * We don't compress the first MAX_ORDER bit of the addresses. > + */ This is a single line comment. > u64 __init pdx_init_mask(u64 base_addr) It wouldn't hamper patch readability much if even this one was switched to uint64_t at the same time, thus restoring consistency with ... > { > - return fill_mask(base_addr - 1); > + return fill_mask(max(base_addr, (u64)1 << (MAX_ORDER + PAGE_SHIFT)) - 1); ... the requested use of uint64_t here. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |