Patchwork linux-user: fix mips 32-on-64 prealloc case

login
register
mail settings
Submitter Alexander Graf
Date Jan. 3, 2013, 1:17 p.m.
Message ID <1357219038-841-1-git-send-email-agraf@suse.de>
Download mbox | patch
Permalink /patch/209249/
State New
Headers show

Comments

Alexander Graf - Jan. 3, 2013, 1:17 p.m.
MIPS only supports 31 bits of virtual address space for user space, so let's
make sure we stay within that limit with our preallocated memory block.

This fixes the MIPS user space targets when executed without command line
option.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 linux-user/main.c | 5 +++++
 1 file changed, 5 insertions(+)
Peter Maydell - Jan. 3, 2013, 5:19 p.m.
On 3 January 2013 13:17, Alexander Graf <agraf@suse.de> wrote:
> MIPS only supports 31 bits of virtual address space for user space, so let's
> make sure we stay within that limit with our preallocated memory block.
>
> This fixes the MIPS user space targets when executed without command line
> option.

This looks weird -- why should the guest care that we've reserved a
4GB block which it only uses half of? Or is the problem that host
mmap() ends up handing out addresses from anywhere in the 4GB
reserved area?

-- PMM
Alexander Graf - Jan. 3, 2013, 5:24 p.m.
On 03.01.2013, at 18:19, Peter Maydell wrote:

> On 3 January 2013 13:17, Alexander Graf <agraf@suse.de> wrote:
>> MIPS only supports 31 bits of virtual address space for user space, so let's
>> make sure we stay within that limit with our preallocated memory block.
>> 
>> This fixes the MIPS user space targets when executed without command line
>> option.
> 
> This looks weird -- why should the guest care that we've reserved a
> 4GB block which it only uses half of? Or is the problem that host
> mmap() ends up handing out addresses from anywhere in the 4GB
> reserved area?

Even worse, it starts from the top IIRC.

MIPS uses the upper virtual address bit for kernel/user space indication. I'm not sure where exactly this logic falls apart in our case, but user space virtual addresses above 2GB are simple illegal in that world, so I wouldn't expect QEMU or a guest process to cope with them.


Alex
Eric Johnson - Jan. 3, 2013, 6:39 p.m.
On 01/03/2013 09:24 AM, Alexander Graf wrote:
> On 03.01.2013, at 18:19, Peter Maydell wrote:
>
>> On 3 January 2013 13:17, Alexander Graf<agraf@suse.de>  wrote:
>>> MIPS only supports 31 bits of virtual address space for user space, so let's
>>> make sure we stay within that limit with our preallocated memory block.
>>>
>>> This fixes the MIPS user space targets when executed without command line
>>> option.
>> This looks weird -- why should the guest care that we've reserved a
>> 4GB block which it only uses half of? Or is the problem that host
>> mmap() ends up handing out addresses from anywhere in the 4GB
>> reserved area?
> Even worse, it starts from the top IIRC.
>
> MIPS uses the upper virtual address bit for kernel/user space indication. I'm not sure where exactly this logic falls apart in our case, but user space virtual addresses above 2GB are simple illegal in that world, so I wouldn't expect QEMU or a guest process to cope with them.
>
>
> Alex
>
>

While making this change please keep in mind that newer MIPS32 
processors allow more than 31 bits of user address space (up to 3.5 GiB) 
if they have Enhanced Virtual Address support.  For example see the 
Software User's Manual for the interAptiv processors:

At the bottom of the page
http://www.mips.com/products/processor-cores/aptiv/interaptiv/
is the link
interAptiv^(TM) Multiprocessing System Software User's Manual 
<http://www.mips.com/secure-download/index.dot?product_name=/auth/MD00904-2B-interAptiv-SUM-01.04.pdf>

Go to section
1.2.7.5 Enhanced Virtual Address

Eric
Richard Henderson - Jan. 3, 2013, 6:50 p.m.
On 01/03/2013 10:39 AM, Eric Johnson wrote:
> While making this change please keep in mind that newer MIPS32
> processors allow more than 31 bits of user address space (up to 3.5
> GiB) if they have Enhanced Virtual Address support.

Interesting.

Well, would you be able to help figure out exactly what's going on in:

  http://lists.gnu.org/archive/html/qemu-devel/2012-12/msg03233.html

and the thread leading up to it?

Now, I don't *know* that this is an emulation failure -- the linux-user-test
binary certainly isn't aware of enhanced virtual addresses.  So it's
possible that (older?) binaries can't cope with more than 2GB.

Alternately, it really is a translation problem somewhere...


r~
Eric Johnson - Jan. 3, 2013, 7:09 p.m.
On 01/03/2013 10:50 AM, Richard Henderson wrote:
> On 01/03/2013 10:39 AM, Eric Johnson wrote:
>> While making this change please keep in mind that newer MIPS32
>> processors allow more than 31 bits of user address space (up to 3.5
>> GiB) if they have Enhanced Virtual Address support.
> Interesting.
>
> Well, would you be able to help figure out exactly what's going on in:
>
>    http://lists.gnu.org/archive/html/qemu-devel/2012-12/msg03233.html
>
> and the thread leading up to it?
>
> Now, I don't *know* that this is an emulation failure -- the linux-user-test
> binary certainly isn't aware of enhanced virtual addresses.  So it's
> possible that (older?) binaries can't cope with more than 2GB.
>
> Alternately, it really is a translation problem somewhere...
>
>
> r~

That is correct.  The current test and MIPS32 processors supported by 
QEMU do not support more than 2 GiB of user space.  I didn't mean to 
imply otherwise.

Looking at the MIPS32 processor linux-user on a 64-bit host issue is 
already on my long list of tasks.  Sorry I have not been able to look at 
it yet.

On second thought ignore my EVA comment for now.  We'll worry about that 
when implementing EVA.

Eric
Aurelien Jarno - Jan. 8, 2013, 3:45 p.m.
On Thu, Jan 03, 2013 at 02:17:18PM +0100, Alexander Graf wrote:
> MIPS only supports 31 bits of virtual address space for user space, so let's
> make sure we stay within that limit with our preallocated memory block.
> 
> This fixes the MIPS user space targets when executed without command line
> option.
> 
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
>  linux-user/main.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/linux-user/main.c b/linux-user/main.c
> index c4d10ac..a2bc09d 100644
> --- a/linux-user/main.c
> +++ b/linux-user/main.c
> @@ -57,7 +57,12 @@ int have_guest_base;
>   * This way we will never overlap with our own libraries or binaries or stack
>   * or anything else that QEMU maps.
>   */
> +# ifdef TARGET_MIPS
> +/* MIPS only supports 31 bits of virtual address space for user space */
> +unsigned long reserved_va = 0x77000000;
> +# else
>  unsigned long reserved_va = 0xf7000000;
> +# endif
>  #else
>  unsigned long reserved_va;
>  #endif

Thanks, applied.

Patch

diff --git a/linux-user/main.c b/linux-user/main.c
index c4d10ac..a2bc09d 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -57,7 +57,12 @@  int have_guest_base;
  * This way we will never overlap with our own libraries or binaries or stack
  * or anything else that QEMU maps.
  */
+# ifdef TARGET_MIPS
+/* MIPS only supports 31 bits of virtual address space for user space */
+unsigned long reserved_va = 0x77000000;
+# else
 unsigned long reserved_va = 0xf7000000;
+# endif
 #else
 unsigned long reserved_va;
 #endif