Let's step back a bit

Posted Jun 3, 2009 20:09 UTC (Wed) by nevets (subscriber, #11875)
In reply to: Let's step back a bit by BrucePerens
Parent article: Xen again

KVM only works on hardware that has virtualization support. Of my 12 boxes, I have three that do that. One is crap, the other is OK, and the third is my latest laptop.

KVM developers have no interest (nor have they designed KVM) to work with paravirtualization (the thing needed by the OS to support non virtualization supported hardware). Although, I do believe KVM can make use of virtio, but that's another story.

We have enough in the kernel to support a DomU. That is, a true guest.

But Dom0 is a special guest with Xen. The Xen hypervisor passes off the work of drivers to Dom0 to have it do the work. But this interface between Dom0 and the hypervisor is a bit more intrusive than the interface needed by DomU (and already exists).

The issue is that once we add this Dom0 interface, we will forever need to support it. Because any changes we make will break Xen. This is why I suggested having Linux host the Xen source code. Then we can freely change the Dom0<->hypervisor interface without worrying about breaking an external ABI.

Note, my suggestion is not about Xen being inside Linux. It would still be a micro kernel loaded first. But the vmlinuz image would be one. First we load the Xen hypervisor, and then we load Dom0. This will couple the two tightly and the user would not need to worry about incompatibilities.

Let's step back a bit

Posted Jun 4, 2009 8:42 UTC (Thu) by rwmj (subscriber, #5474) [Link] (4 responses)

Bruce, this is an interesting and valid point, but it's also a bit like the discussion of 3D rendering that happened in the mid 90s. Sure, 3D graphics cards were rare and expensive at first, and that meant there was a place for software rendering.

Nowadays though no serious 3D program (ie. no game!) comes with a software renderer, because the 3D hardware is everywhere, on motherboards, in open handhelds like the GP2x-Wiz, and even in experimental boards like the ARM-based Beagleboard.

Hardware virt support is in just about every new x86-64 processor that comes out. A few 32 bit netbooks don't have it right now, but it'll come to those too.

Also don't overlook the fact that KVM does have software emulation. OK, it's slow, it's in userspace, and it relies on qemu. Nevertheless, just running qemu-kvm will transparently fall back to software emulation if the hardware doesn't support virtualization.

Rich.

Let's step back a bit

Posted Jun 4, 2009 8:43 UTC (Thu) by rwmj (subscriber, #5474) [Link]

s/Bruce/nevets/ ...

Let's step back a bit

Posted Jun 4, 2009 12:18 UTC (Thu) by nye (subscriber, #51576) [Link]

While I mostly agree, there are still a number of new mainstream CPUs which don't support hardware virtualisation, mostly aimed at the budget or mobile market. I know if I could use KVM on this laptop it would make my life a little easier. I've never used Xen so I don't know if it would be worth the effort for my purposes, but I'd be a lot more likely to try if it were in the kernel already.

Let's step back a bit

Posted Jun 4, 2009 17:44 UTC (Thu) by buchanmilne (guest, #42315) [Link] (1 responses)

<blockquote>Hardware virt support is in just about every new x86-64 processor that comes out.</blockquote>

But, an 18-month-old 16-core (8*"Dual Core AMD Opteron(tm) Processor 885") server (Sun X4600-M1) doesn't have it. With another 5 years of lifetime on these boxes, it really would be nice to keep Xen (which is what they are currently running). There's no way I would migrate this (with heavily utilised VMs) to qemu-kvm ...

Let's step back a bit

Posted Jun 4, 2009 21:28 UTC (Thu) by jimparis (guest, #38647) [Link]

But when you were purchasing a box 18 months ago, with a plan for a 5-year lifetime, wasn't it a huge mistake to overlook the hardware virtualization feature? I mean, KVM was merged into the kernel some 28 months ago.
I agree your situation sucks, but it seems more of a purchasing mistake than a reason to not move the world towards proper hardware virtualization.