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


_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Reply via email to