Re: [PATCH v3 10/21] linux-user: Fix guest_addr_valid vs reserved_va

2021-01-19 Thread Richard Henderson
On 1/19/21 7:03 AM, Peter Maydell wrote:
> On Fri, 15 Jan 2021 at 22:47, Richard Henderson
>  wrote:
>>
>> We must always use GUEST_ADDR_MAX, because even 32-bit hosts can
>> use -R  to restrict the memory address of the guest.
>>
>> Signed-off-by: Richard Henderson 
>> ---
>>  include/exec/cpu_ldst.h | 9 -
>>  1 file changed, 4 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/exec/cpu_ldst.h b/include/exec/cpu_ldst.h
>> index 4e6ef3d542..e62f4fba00 100644
>> --- a/include/exec/cpu_ldst.h
>> +++ b/include/exec/cpu_ldst.h
>> @@ -72,11 +72,10 @@ typedef uint64_t abi_ptr;
>>  /* All direct uses of g2h and h2g need to go away for usermode softmmu.  */
>>  #define g2h(x) ((void *)((uintptr_t)(abi_ptr)(x) + guest_base))
>>
>> -#if HOST_LONG_BITS <= TARGET_VIRT_ADDR_SPACE_BITS
>> -#define guest_addr_valid(x) (1)
>> -#else
>> -#define guest_addr_valid(x) ((x) <= GUEST_ADDR_MAX)
>> -#endif
>> +static inline bool guest_addr_valid(abi_ulong x)
>> +{
>> +return x <= GUEST_ADDR_MAX;
>> +}
> 
> Reviewed-by: Peter Maydell 
> 
> Looking back at patch 9 -- if we always check against
> GUEST_ADDR_MAX here, should we also do that for h2g_valid(),
> or are the two uses different ?
> (The v2->v3 changes list for patch 9 suggests we may have
> had this discussion previously, but I forget the details...)

I had thought we should always check GUEST_ADDR_MAX.

If something is outside G_A_M, then it doesn't fit
into the reserved_va that either (1) the user requested
via the command-line or (2) for which the guest has
constraints (e.g. TARGET_VIRT_ADDR_SPACE_BITS for sh4
or mips, requiring 31-bit addresses).


r~



Re: [PATCH v3 10/21] linux-user: Fix guest_addr_valid vs reserved_va

2021-01-19 Thread Peter Maydell
On Fri, 15 Jan 2021 at 22:47, Richard Henderson
 wrote:
>
> We must always use GUEST_ADDR_MAX, because even 32-bit hosts can
> use -R  to restrict the memory address of the guest.
>
> Signed-off-by: Richard Henderson 
> ---
>  include/exec/cpu_ldst.h | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/include/exec/cpu_ldst.h b/include/exec/cpu_ldst.h
> index 4e6ef3d542..e62f4fba00 100644
> --- a/include/exec/cpu_ldst.h
> +++ b/include/exec/cpu_ldst.h
> @@ -72,11 +72,10 @@ typedef uint64_t abi_ptr;
>  /* All direct uses of g2h and h2g need to go away for usermode softmmu.  */
>  #define g2h(x) ((void *)((uintptr_t)(abi_ptr)(x) + guest_base))
>
> -#if HOST_LONG_BITS <= TARGET_VIRT_ADDR_SPACE_BITS
> -#define guest_addr_valid(x) (1)
> -#else
> -#define guest_addr_valid(x) ((x) <= GUEST_ADDR_MAX)
> -#endif
> +static inline bool guest_addr_valid(abi_ulong x)
> +{
> +return x <= GUEST_ADDR_MAX;
> +}

Reviewed-by: Peter Maydell 

Looking back at patch 9 -- if we always check against
GUEST_ADDR_MAX here, should we also do that for h2g_valid(),
or are the two uses different ?
(The v2->v3 changes list for patch 9 suggests we may have
had this discussion previously, but I forget the details...)

thanks
-- PMM



[PATCH v3 10/21] linux-user: Fix guest_addr_valid vs reserved_va

2021-01-15 Thread Richard Henderson
We must always use GUEST_ADDR_MAX, because even 32-bit hosts can
use -R  to restrict the memory address of the guest.

Signed-off-by: Richard Henderson 
---
 include/exec/cpu_ldst.h | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/include/exec/cpu_ldst.h b/include/exec/cpu_ldst.h
index 4e6ef3d542..e62f4fba00 100644
--- a/include/exec/cpu_ldst.h
+++ b/include/exec/cpu_ldst.h
@@ -72,11 +72,10 @@ typedef uint64_t abi_ptr;
 /* All direct uses of g2h and h2g need to go away for usermode softmmu.  */
 #define g2h(x) ((void *)((uintptr_t)(abi_ptr)(x) + guest_base))
 
-#if HOST_LONG_BITS <= TARGET_VIRT_ADDR_SPACE_BITS
-#define guest_addr_valid(x) (1)
-#else
-#define guest_addr_valid(x) ((x) <= GUEST_ADDR_MAX)
-#endif
+static inline bool guest_addr_valid(abi_ulong x)
+{
+return x <= GUEST_ADDR_MAX;
+}
 
 static inline bool guest_range_valid(abi_ulong start, abi_ulong len)
 {
-- 
2.25.1