On Sun, Feb 13, 2011 at 3:22 PM, Steve Sapovits <steves06@xxxxxxxxxxx> wrote:
>> that's not exact since KVM doesn't run 'on top of' the Linux kernel;
>> it's part of the Linux kernel. as such, it has the same 'bare metal'
>> access to hardware as the rest of the kernel or the Xen hypervisor.
>
> One differing factor is paravirtualization. To clarify my comments
> regarding KVM: I meant it runs *in* the kernel. So, yes -- when
> accessing hardware without paravirtualization, making a Linux kernel
> call versus making a Xen hypervisor/micorkernel call is probably half
> a dozen of one/6 of the other. However, when running paravirtualized
> guests, the dedicated nature of the Xen approach can offer better
> performance. Here's a good paper on the subject:
Just to clarify, my comment was about the characterization of KVM as a
type 2 hypervisor. it's not.
now, about the paravirtualization / full virtualization, that's a
totally different issue. Definitely Xen does offer a complete mode of
operation that's simply inexistent on KVM.
The pros/cons of each mode is open for discussion, and changes one way
or the other not only for different uses, but also changes with
processor generations. first-gen full-virtualization was noticeably
slower, second-gen made the difference much smaller, and there's hints
of new optimizations that could swing the performance advantage again
far toward paravirtualization.... or maybe the other way.
In any case, offering both options is a good thing :-)
but i think it's not about a KVM vs. Xen debate. And my specific
comment was defintely not about Xen at all. just to say: KVM is type
1. no matter what drivers you use, which parts of the VM are
emulated, which are virtualized and which are paravirtualized, it's
always type 1
--
Javier
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home