qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Johnson <ericj@mips.com>
To: Alexander Graf <agraf@suse.de>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Riku Voipio <riku.voipio@linaro.org>,
	Michael Tokarev <mjt@tls.msk.ru>,
	qemu-devel qemu-devel <qemu-devel@nongnu.org>,
	Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [Qemu-devel] [PATCH] linux-user: fix mips 32-on-64 prealloc case
Date: Thu, 3 Jan 2013 10:39:10 -0800	[thread overview]
Message-ID: <50E5D04E.8010107@mips.com> (raw)
In-Reply-To: <7A6BA085-93BA-407E-AAE9-58247D779A2C@suse.de>

[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2428 bytes --]

  reply	other threads:[~2013-01-03 18:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-03 13:17 [Qemu-devel] [PATCH] linux-user: fix mips 32-on-64 prealloc case Alexander Graf
2013-01-03 17:19 ` Peter Maydell
2013-01-03 17:24   ` Alexander Graf
2013-01-03 18:39     ` Eric Johnson [this message]
2013-01-03 18:50       ` Richard Henderson
2013-01-03 19:09         ` Eric Johnson
2013-01-08 15:45 ` Aurelien Jarno

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50E5D04E.8010107@mips.com \
    --to=ericj@mips.com \
    --cc=agraf@suse.de \
    --cc=aurelien@aurel32.net \
    --cc=mjt@tls.msk.ru \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=riku.voipio@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).