Re: [Xen-devel] [PATCH v5 2/2] xen/arm: fix mask calculation in pdx_init_mask

[Julien Grall <julien.grall@xxxxxxx>]

Hi Stefano,

On 6/21/19 9:24 PM, Stefano Stabellini wrote:
> The mask calculation in pdx_init_mask is wrong when the first bank
> starts at address 0x0. The reason is that pdx_init_mask will do '0 - 1'
> causing an underflow. As a result, the mask becomes 0xffffffffffffffff
> which is the biggest possible mask and ends up causing a significant
> memory waste in the frametable size computation.
>
> For instance, on platforms that have a low memory bank starting at 0x0
> and a high memory bank, the frametable will end up covering all the
> holes in between.
>
> The purpose of the mask is to be passed as a parameter to
> pfn_pdx_hole_setup, which based on the mask parameter calculates
> pfn_pdx_hole_shift, pfn_pdx_bottom_mask, etc. which are actually the
> important masks for frametable initialization later on.
>
> pfn_pdx_hole_setup never compresses addresses below MAX_ORDER bits (1GB
> on ARM). Thus, it is safe to initialize mask passing 1ULL << (MAX_ORDER
> + PAGE_SHIFT) as start address to pdx_init_mask.
>
> Signed-off-by: Stefano Stabellini <stefanos@xxxxxxxxxx>
> Reviewed-by: Julien Grall <julien.grall@xxxxxxx>
> Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
Unfortunately this patch is breaking boot on AMD Seattle (laxton{0,1}) 
see [1]. The bisector fingered this patch [2].
To unblock osstest, I have taken the liberty to revert the patch on staging.

From Linux, the memory range for Seattle is
0x0000008000000000-0x00000087ffffffff

I am not entirely sure why this patch affects the boot. Stefano can you 
look at it?
Cheers,

[1] 
http://logs.test-lab.xenproject.org/osstest/results/history/test-arm64-arm64-xl-xsm/xen-unstable-smoke.html
[2] https://lists.xen.org/archives/html/xen-devel/2019-06/msg01549.html

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel