[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

 


Rackspace

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