[Qemu-devel] QVM86, SKAS.. many modules, one vision?

[Qemu-devel] QVM86, SKAS.. many modules, one vision?

[Ian Rogers]

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?

Regards,

Ian Rogers
- http://www.cs.manchester.ac.uk/apt/projects/jamaica
- http://www.binarytranslator.org/

Re: [Qemu-devel] QVM86, SKAS.. many modules, one vision?

[Paul Brook]

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

Re: [Qemu-devel] QVM86, SKAS.. many modules, one vision?

[Ian Rogers]

Paul Brook wrote:

>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.
>  
>
Yup, but if you are emulating more than just a user process (ie a whole 
OS), or you can't guarantee the security of the user process (ie it 
could go messing with the translation cache), then just mapping things 
elsewhere is just adopting the ostrich position. Multi-segments are an 
obvious way to solve this but currently there's little support in the 
OS. modify_ldt works quite well, you can hide the translation cache 
below it, but it means you can't map pages at the end of the address 
space. That's why some module support would be good.

Regards,

Ian Rogers