All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Cc: Michael T <raselmsh@hotmail.com>
Subject: Re: [Qemu-devel] Guest memory mapping in Qemu
Date: Wed, 24 Mar 2010 13:05:09 +0000	[thread overview]
Message-ID: <201003241305.09507.paul@codesourcery.com> (raw)
In-Reply-To: <BAY132-W280E1230035A203253D20D0250@phx.gbl>

> If the technical documentation at
> http://www.usenix.org/publications/library/proceedings/usenix05/tech/freeni
> x/full_papers/bellard/bellard_html/index.html is still valid (I think it
>  is), Qemu has two modes of handling access to guest memory - system
>  emulation, in which an entire guest address space is mapped on the host,
>  and emulated MMU.  

No. qemu-fast (using the host address space) was removed long ago. There are a 
few stray remnants, but nothing useful. We always use an emulated MMU.

>  I was wondering whether something in-between would also
>  be feasible. That is, chunks of guest address space (say 4MB chunks for
>  the sake of the argument) are mmapped into the address space of the Qemu
>  process on the host, and when an access to guest memory is made, there is
>  an initial check to see whether it is in the same chunk as the last one,
>  in which case all the MMU emulation bits could be saved.  I could imagine
>  Qemu keeping a current/most recent chunk for each register which can be
>  used for relative addressing, plus one for non-register-relative accesses.
>   It seems to me that this could potentially speed up memory access quite a
>  bit, and as a bonus even make it easy to support x86 segmentation (as part
>  of the bounds check for whether a memory access is in a chunk).

This is effectively shadow paging implemented in userspace via mmap. It's very 
hard to make it work in a sane way, and even harder to make it go fast. TLB 
handling is already a significant bottleneck for many tasks, adding a mmap 
call is likely to make this orders of magnitude worse.  Most guests use 
virtual memory extensively, so the virtual->physical mappings tend to be 
extremely fragmented.

If you really want to do shadow paging for cross environments, you probably 
need to move it into kernel space. Either as a host kernel module, or as a 
bare-metal kernel/application that runs inside KVM. Even then you have to use 
various tricks to partition off a section of the host address space for use by 
qemu. It's not impossible, but it is a significant undertaking with somewhat 
unclear benefits.

Paul

  reply	other threads:[~2010-03-24 13:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-24 11:11 [Qemu-devel] Guest memory mapping in Qemu Michael T
2010-03-24 13:05 ` Paul Brook [this message]
2010-03-24 14:50   ` Michael T

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=201003241305.09507.paul@codesourcery.com \
    --to=paul@codesourcery.com \
    --cc=qemu-devel@nongnu.org \
    --cc=raselmsh@hotmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.