From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Cc: Ian Rogers <ian.rogers@manchester.ac.uk>
Subject: Re: [Qemu-devel] QVM86, SKAS.. many modules, one vision?
Date: Mon, 9 May 2005 13:39:02 +0100 [thread overview]
Message-ID: <200505091339.03936.paul@codesourcery.com> (raw)
In-Reply-To: <427F28CF.1030300@manchester.ac.uk>
On Monday 09 May 2005 10:09, Ian Rogers wrote:
> Hi,
>
> I recently spent some effort working out what Separate Kernel Address
> Space (SKAS) did for user-mode-linux (UML). The results of this keen be
> seen here:
>
> http://news.gmane.org/group/gmane.linux.uml.devel/last=/force_load=t
> on the thread "Using SKAS, any examples?"
>
> the conclusion to this is that with SKAS you can create separate address
> spaces and map pages (possibly shared) into them. You can then use
> ptrace to control the execution of something in that separate address
> space.
>
> This is all well and good, but when emulating one instruction set on
> another the executing code needs to peek and poke the separate address
> space. With SKAS this can only be done by using a page with a shared
> mapping, or by executing some host machine code in the separate address
> space.
>
> What would be good is if multi-segments could be enabled and then
> cs/ds/es could be used by the emulator and fs/gs could map to higher in
> the linear address space and onto the separate address spaces. These
> address spaces would then be addressable with just a segment over-ride.
>
> It seems these goals are likely in part to be shared by qvm86 and kqemu.
> Is it worth working toward a unified Linux module specifically for
> emulation?
IIUC SKAS doesn't give you access to the full address space. It just creates a
new process, giving you a "clean" linux userspace. For full system emulation
this isn't sufficient, you need to full address space.
For user-mode emulation the largest chunk of address space is the translated
code buffer. This needs to be able to directly address the guest memory
space, so sharing a VM with the host qemu process isn't really a problem. We
just map the host qemu out of the way somewhere. This is different from
native UML where with SKAS you can run applications without any foreign areas
mapped into the guest address space.
Paul
next prev parent reply other threads:[~2005-05-09 13:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-09 9:09 [Qemu-devel] QVM86, SKAS.. many modules, one vision? Ian Rogers
2005-05-09 12:39 ` Paul Brook [this message]
2005-05-09 12:59 ` Ian Rogers
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=200505091339.03936.paul@codesourcery.com \
--to=paul@codesourcery.com \
--cc=ian.rogers@manchester.ac.uk \
--cc=qemu-devel@nongnu.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).