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

[Jim C. Brown]

On Wed, Feb 15, 2006 at 11:31:24AM +0000, Luke-Jr wrote:
> On Wednesday 15 February 2006 07:20, Jim C. Brown wrote:
> > 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.
> 
> Why are the structures needed? Could perhaps they be simply exported to 
> userland with a patch and qvm86 itself moved there?

You can't just give access to the GDT/LDT in userspace. I don't understand the
technical details but basically this is only accessable from the kernel.

Sure you could make a patch that gives access to these structures thru some
sort of kernel interface, but then you have already done much of the work that
qvm86 does.

Such a patch would potentially be more dangerous as well - e.g. it theoretically
could allow a non-root process running on the host to take over, by modifying
the segment descriptors so a part of its own code runs in kernel mode.

Basically, this route is more complicated/dangerous than the qvm86 way.

> 
> I don't like the idea that a bug in qvm86 could theoretically freeze/panic my 
> entire system, and don't plan to use it (nor kqemu), until that somehow 
> changes... Keeping the kernel changes minimal (eg, exporting stuff to 
> userland) reduces the code a dangerous bug can possibly occur in.

Agreed.

Alas, pure userspace virtualization, while possible, is so slow (at least on
x86) that it's not really worth doing. Basically you'd have to read ahead and
rewrite all memory accesses, segment descriptor accesses, etc... so the speed
you'd end up with would be comparable to qemu-softmmu alone.

> -- 
> 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.