Re: [qvm86-devel] kqemu 1.3.0 compatibility and small bugfix

[Jim C. Brown]

On Wed, Feb 15, 2006 at 07:11:45AM +0000, Luke-Jr wrote:
> Any idea why kqemu/qvm86 are kernel-level? Couldn't the majority of 
> virtualization occur in userspace and leave the rest emulated?

As I understand it, all virtualization done by qvm86 and older versions of kqemu
occur in a sort of userspace.

It is simply that one does not have the proper access to required structures
(such as LDT, GDT, etc) in the userspace of the host, so kernel level access
(specifically ring 0 access) is required.

The virtualization occurs in ring 3 itself, but its in a separate userspace that
is isolated from normal programs running in ring 3 on the host OS.

Also, kqemu 1.3.0 implements -kernel-kqemu, which virtualizes ring 0 code.
(Actually, virtualized ring 0 code is still run in ring 3, but you also need
to use quite a few hacks in order to make it run there.)

This patch lets qvm86 work with qemu 0.8.0 (well I tried a week old CVS actually
- and a heavily modified one at that) and even use the -kernel-kqemu parameter.
qvm86 recognizes ring 0 code and just calls qemu-softmmu on it anyways. So it
is compatible with the parameter, but specifying it doesn't actually do anything
yet.

> So this is actually being maintained? ;)
> 

I believe Paul Brook is still willing to accept patches for bugfixes and such.

I was also wrong about the memory corrupt fix. Evidently taking the lock does
not get rid of this bug (though it is still a good idea to take the lock
anyways). If I understand Paul correctly he hasn't been able to track down
this bug yet either.

> -- 
> Luke-Jr
> Developer, Utopios
> http://utopios.org/
> 
> 
> _______________________________________________
> qvm86-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/qvm86-devel
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.