LWN: Comments on "KVM 15"

KVM 15

slamb — Fri, 09 Mar 2007 17:04:09 +0000

Perhaps some day you can aspire to being "poa mchizi com ndizi", or "cool crazy like a banana".

KVM 15

joern — Mon, 05 Mar 2007 13:03:04 +0000

Actually, I consider relying on hardware virtualization the smallest advantage of all. Even if the paravirtualization approach makes sense - and in many cases it does - there is no reason to re-implement a scheduler, memory management, hardware-bug workarounds, etc.

The ultimate hypervisor is the Linux kernel and kvm is the first widely-available project to take advantage of it.

Intel <=> AMD

avik — Sun, 04 Mar 2007 06:04:42 +0000

Programs detect cpu capabilities by means of the cpuid instruction. Since
that instruction is itself virtualized and controlled by the host
userspace, one can tell virtualize a processor with the least capabilities
that are in use on the server farm. Gievn that, programs will only use
instructions that are present on all processors that can be a migration
target.

Intel <=> AMD

addw — Sat, 03 Mar 2007 09:36:25 +0000

''guest systems can be moved between Intel and AMD processors with no problems at all.''

What about those programs that use different instructions depending on the CPU ? These generally detect the CPU type when they start, but after a migration they will fail - since they don't redetect again.

KVM 15

marduk — Thu, 01 Mar 2007 22:17:38 +0000

Has the KVM changes to qemu made it's way into qemu proper, or do they still use a forked version?

KVM 15

avik — Thu, 01 Mar 2007 11:31:55 +0000

Ah, I see what you're trying -- trying to give all those *other* projects the honour.

Well, er, yes.

It could also be interpreted as an mean and underhanded swipe at other virtualization projects which have written their own kernel. I'm sure no one on LWN would suggest that I'd make such an insinuation, though.

It won't work. We'll still consider you a cool potato. This is the kinda thing that makes my Windows-using co-workers go; "Linux can do *what*?" which happens at increasing frequency lately.

It's all part of the master plan. I get to be a cool potato (potato?!) *and* appear to be generous soul who's only wish is to see the credit go where it really belongs.

KVM 15

ekj — Thu, 01 Mar 2007 10:50:31 +0000

Ah, I see what you're trying -- trying to give all those *other* projects the honour.

It won't work. We'll still consider you a cool potato. This is the kinda thing that makes my Windows-using co-workers go; "Linux can do *what*?" which happens at increasing frequency lately.

KVM 15

avik — Thu, 01 Mar 2007 07:13:10 +0000

In addition to relying on hardware virtualization, kvm has two additional advantages:

it relies on the kernel for the stuff the kernel is good at: scheduling, memory management, security, I/O, power management; the list goes on and on.
it relies on qemu for the stuff qemu is good at: emulation. kvm only uses the chipset and I/O emulation (and not the cpu emulation), but a world of work was saved by using qemu. Live migration, for example, is actually a qemu project which was adapted to also support kvm.

By relying on the kernel and qemu, kvm is able to focus firmly on virtualization issues. That is what makes the fast development pace possible.

[I'm the kvm maintainer]

Correction

avik — Thu, 01 Mar 2007 07:01:57 +0000

The guest is still running while this copy process is happening. Whenever it tries to modify a page which has already been copied, it will trap back into QEMU [...]

No, assuming the guest is running under kvm (and not pure qemu), the guest will trap into the kernel (which marks the page dirty), and then resumes execution.

KVM 15

aliguori — Thu, 01 Mar 2007 04:31:43 +0000

<i>As it happens, guest systems can be moved between Intel and AMD processors with no problems at all. Moving a 64-bit guest to a 32-bit host remains impossible; the KVM developers appear uninterested in fixing this particular limitation anytime soon.</i>

KVM migration is being developed in parallel to QEMU migration. It will actually be possible to migration a 64-bit KVM guest to a 32-bit host running qemu-system-x86_64. In fact, it will be possible to migrate a 64-bit x86 KVM guest to qemu-system-x86_64 running on PowerPC (or any platform that QEMU supports).

Of course, you are moving from a virtualized host to an emulated host so performance will suffer. Even if a host is 64-bit capable, if it's running in 32-bit mode, supporting a 64-bit guest is just too much of a pain for virtualization.