[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH 6/6] QEMU support for the Kernel Virtual Machine

From: Fabrice Bellard
Subject: [Qemu-devel] Re: [PATCH 6/6] QEMU support for the Kernel Virtual Machine interface
Date: Fri, 01 Feb 2008 10:49:08 +0100
User-agent: Thunderbird (X11/20070727)

Anthony Liguori wrote:
This patch actually enables KVM support for QEMU.  I apologize that it is so
large but this was the only sane way to preserve bisectability.

The goal of this patch is to add KVM support, but not to impact users when
KVM isn't being used.  It achieves this by using a kvm_enabled() macro that
evaluates to (0) when KVM support is not enabled.  An if (kvm_enabled()) is
just as good as using an #ifdef since GCC will eliminate the dead code.

This patches touches a lot of areas.  For performance reasons, the guest CPU
state is not kept in sync with CPUState.  This requires an explicit
synchronization whenever CPUState is required.  KVM also uses it's own main
loop as it runs each VCPU in it's own thread.

Trapping VGA updates via MMIO is far too slow when running KVM so there is
additional logic to allow VGA memory to be accessed as RAM.  We use KVM's
shadow page tables to keep track of which portions of RAM have been dirtied.

KVM also supports an in-kernel APIC implementation as a performance
enhancement.  Finally, KVM supports APIC TPR patching.  This allows TPR
accesses (which are very frequently for Windows) to be patches into CALL
instructions to the BIOS (for 32-bit guests).  This results in a very
sigificant performance improvement for Windows guests.

While this patch is very large, the new files are only included when KVM
support is compiled in.  Every change to QEMU is wrapped in an
if (kvm_enabled()) so the code disappears when KVM support is not compiled in.
This is done to ensure no regressions are introduced to normal QEMU.

Some questions:

- QEMU already maintains modified page status for VGA memory (and kqemu for example fully supports that), so I don't see why KVM needs a new method.

- Why is kvm_cpu_register_physical_memory() needed ? kqemu can work without it because there is a remapping between physical memory and RAM address. I suggest to add that feature in KVM or to modify cpu_register_physical_memory() to hide it.

- If KVM implements its own CPU loop, why are there patches in libqemu.a (CPU core) ?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]