[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 07/17] linux-user: Fix guest_addr_valid vs reserved_va
From: |
Richard Henderson |
Subject: |
Re: [PATCH v2 07/17] linux-user: Fix guest_addr_valid vs reserved_va |
Date: |
Sat, 11 Jul 2020 12:26:19 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 |
On 6/25/20 9:37 AM, Peter Maydell wrote:
> On Fri, 5 Jun 2020 at 05:17, Richard Henderson
> <richard.henderson@linaro.org> wrote:
>>
>> We must always use GUEST_ADDR_MAX, because even 32-bit hosts can
>> use -R <reserved_va> to restrict the memory address of the guest.
>>
>> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
>> ---
>> include/exec/cpu_ldst.h | 9 ++++-----
>> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> Doesn't this run into trouble with the arm32 commpage?
> The reserved_va is set there to 0xffff0000 (stopping
> at the commpage), but the addresses within the commpage
> themselves are still valid guest addresses.
Not really. The commpage is Special, and gets allocated differently. Normal
binaries work, e.g. our standard busybox ls.
I would imagine the corner case that doesn't work is that you couldn't issue a
syscall to the commpage, e.g.
write(1, 0xfffff000, 1);
because the commpage is now outside the normal address space.
But given that it only matters with an explicit -R command-line option, this
falls into the Well Don't Do That Then category. This is a generic option, and
works as expected with other 32-bit guests.
r~
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [PATCH v2 07/17] linux-user: Fix guest_addr_valid vs reserved_va,
Richard Henderson <=