qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Richard Henderson <rth@twiddle.net>
To: Riku Voipio <riku.voipio@iki.fi>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] linux-user: Align mmap memory to the	target page size.
Date: Mon, 25 Jan 2010 08:38:52 -0800	[thread overview]
Message-ID: <4B5DC91C.1050308@twiddle.net> (raw)
In-Reply-To: <20100125133502.GA28489@afflict.kos.to>

On 01/25/2010 05:35 AM, Riku Voipio wrote:
> On Fri, Jan 15, 2010 at 07:43:48AM -0800, Richard Henderson wrote:
>>> This patch uses a more complex search algorithm that takes the result
>>> of the previous allocation into account.  We normally search upward,
>>> but notice 2 consecutive results and start searching downward instead.
>
>> I've failed to take guest_base into account properly; my testing
>> happened to have guest_base = 0.  New patch to follow.
>
> Did you have time to look at this again?

Some.  There is an additional problem.

The target's pages are recorded in the physical page mapping via 
page_set_flags, whose input address is bounded by 
TARGET_PHYS_ADDR_SPACE_BITS, which is local to exec.c.  Doubly 
unfortunately, page_set_flags silently discards pages that it considers 
must be outside the target's address space.

It's fairly easy to get the x86-64 kernel to return a vma outside the 
range of any of the existing TARGET_PHYS_ADDR_SPACE_BITS.  Which works 
fine inside the TB's, but causes any other syscall to return -EFAULT.

We have a check

    /* If address fits target address space we've found what we need */
    if ((unsigned long)ptr + size - 1 <= (abi_ulong)-1)
        break;

which kind-of works for 32-bit targets.  (You'll note, of course, that 
the comparison is against PTR, which is a host address; the correct test 
would have been h2g_valid, as seen with -B 0x100000000.)  However, it 
does nothing for 64-bit targets and the artificial 2**42 virtual address 
space limit we impose on most of them.

I talked with pbrook a bit about this on irc, and there seems to be no 
simple solution (like exporting TARGET_PHYS_ADDR_SPACE_BITS, possibly 
renamed as TARGET_ADDR_SPACE_BITS, in cpu.h) that would be acceptable to 
him.

Given the number of patches I've already submitted that aren't being 
reviewed, I'm unlikely to develop the momentum to totally rewrite qemu's 
page table support.  Particularly without a clue as to what sort of 
solution might be acceptable.  (Something like Sparc64's hashed page 
tables perhaps, which support a full 64-bit virtual address space?)


r~

      reply	other threads:[~2010-01-25 16:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-15  0:38 [Qemu-devel] [PATCH] linux-user: Align mmap memory to the target page size Richard Henderson
2010-01-15 15:43 ` Richard Henderson
2010-01-25 13:35   ` Riku Voipio
2010-01-25 16:38     ` Richard Henderson [this message]

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=4B5DC91C.1050308@twiddle.net \
    --to=rth@twiddle.net \
    --cc=qemu-devel@nongnu.org \
    --cc=riku.voipio@iki.fi \
    /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).