[Qemu-devel] Re: Cutting a new QEMU release

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2483 bytes --]

Jamie Lokier wrote:
> Stefan Weil wrote:
>> The kvm kernel module could be a good replacement for kqemu
>> for those running linux on new cpus.
> 
> It's not yet, though.  kvm doesn't run 16-bit code properly.

You mean real mode, I guess. I think there are still a few holes in the
emulator that may bite you on certain DOSes or with some fancy boot
loaders. But 16-bit protected mode runs as fine as 32 or 64 bit for
quite a while now.

> I use kqemu to run older OSes, and kvm to run current ones.

I haven't found much code that caused troubles to kvm, but a lot that
broke kqemu - YMMV.

> 
> I like the idea of a "kvm-soft", which is basically kqemu with a kvm
> interface.  It would need a few extensions on the kvm interface, of
> course.
> 
> Another potential use for _part_ of kqemu, or kvm-soft, is emulating
> other CPUs with host kernel support for the memory map, instead of
> full software TLB.  That might be a performance accelerator for
> emulation, for some combinations of host and target CPUs where it's
> feasible to map the memory in that way.
> 
> If kqemu were evolved into an accelerator for cross-CPU emulation in
> that way, then its current use as an x86-on-x86 accelerator would just
> be a special case of that.

Most of kqemu's code base deals with / works around unvirtualizable x86
cruft. Memory management, page table handling is only a small subset.
And that part is focused on running guest code under the control of the
monitor, not in the TCG user space environment. So even if there is
something a kernel part could contribute to accelerate TCG execution,
I'm not sure that there will be a high re-use of kqemu's infrastructure
- or even kvm's.

You also should be aware of the fact the kqemu's x86 virtualization is
fairly fragile, only working for OSes like Linux and Windows, and even
there not always reliably (I've seen Linux kernels crashing). We are
evaluating alternative workarounds for these issues, but they will come
with their own limitations. Either they are too costly to implement
(binary translation) given the remaining lifetime of kqemu, or they
cause problems with self-checking guests (patch in traps & emulate). And
both will need special user space support beyond current kqemu's or
kvm's need. Depending on the outcome (for the picky customer OS), we may
be able to contribute to a properly maintained kqemu tree (or better:
kvm-soft). But this is yet open.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]