Re: [RFC PATCH] linux-user: don't adjust base of found hole

[Laurent Vivier <laurent@vivier.eu>]

Le 16/12/2021 à 15:44, Alex Bennée a écrit :
> The pgb_find_hole function goes to the trouble of taking account of
> both mmap_min_addr and any offset we've applied to decide the starting
> address of a potential hole. This is especially important for
> emulating 32bit ARM in a 32bit build as we have applied the offset to
> ensure there will be space to map the ARM_COMMPAGE bellow the main
> guest map (using wrapped arithmetic).
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/690
> ---
>   linux-user/elfload.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/linux-user/elfload.c b/linux-user/elfload.c
> index 238979b8b6..8d839b79fb 100644
> --- a/linux-user/elfload.c
> +++ b/linux-user/elfload.c
> @@ -2334,7 +2334,7 @@ static uintptr_t pgb_find_hole(uintptr_t guest_loaddr, uintptr_t guest_size,
>   
>           /* Record the lowest successful match. */
>           if (ret < 0) {
> -            ret = align_start - guest_loaddr;
> +            ret = align_start;
>           }
>           /* If this hole contains the identity map, select it. */
>           if (align_start <= guest_loaddr &&
> 

It seems not consistent with what we have with fallback where we substract the guest_loadaddr:

2289     if (!maps) {
2290         ret = pgd_find_hole_fallback(guest_size, brk, align, offset);
2291         return ret == -1 ? -1 : ret - guest_loaddr;
2292     }

Thanks,
Laurent