|
[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 |