Hi Javier, thanks for the explanations - they make things much clear to me. Still I have one more misunderstanding - please see below. Javier Guerra Giraldez wrote: > you're mixing several buzzwords: > > - paravirtual/fully virtualized guest: this refers as to how the guest runs in > terms of the lowest level of hardware, mainly about accessing CPU's ring0, the > most privileged mode of execution. paravirtualized guests can't access ring0, > so can't do some very low level CPU operations. for this, the guest is > modified to use some hypervisor calls instead of CPU operations. since the > guest OS has to be modified, usually the VM system doesn't bother fully > emulating IO hardware either. Xen works in either mode, KVM only works in > 'fully virtualized' mode, using HVM capabilities. > > - paravirtualized drivers: usually paravirtualized guests (which KVM doesn't > do) also have some special IO channels, which are faster than emulating every > detail of an existing piece of hardware. but even if you're fully emulating a > CPU, there's nothing preventing you from creating special device drivers that > know how to access the Hypervisor communication channels to do any IO needed. > the advantage is that these drivers are easy to integrate into an oterwise- > unmodified OS. What is still unclear to me is that's the actual difference between PV drivers implementation in paravirtual linux guest and PV dirvers in HVM linux guest? AFAIK in xen guest the PV front-end drivers are quite simple, and in KVM guest to use PV drivers the guest linux needs to be compiled with paravirtual guest and viritio drivers support. So in both cases the OS is modified - but there is the actual difference? Thanks Alex > that makes it possible to use PV drivers on windows guests, > gaining most (if not all) performance advantages of PV guests without access > to the guest OS's source code. > > - virtio: is the IO interface presented to the guest for communicating with > the emulator. at least KVM uses it, but i think Xen's interface is similar. > there are several virtio clients in current Linux kernels, so if you select > virtio network, and block device when launching KVM, a Linux guest gets a big > speedup. also available if you install the PV drivers on windows guests (for > network, block drivers aren't available yet). > > - CPU type: this is only how the CPU identifies itself to the guest, and what > capabilities it advertises. AFAIK, it doesn't mean any software emulation (á > la qemu), or maybe only a few non-performance-sensitive. it's useful mainly > to facilitate guest migration between different hosts. if the guest OS sees > the same CPU as the host, it might see it changing, and since all modern OSs > check the CPU type at bootup to activate different optimised code, changing it > while running would make it crash. advertising only the features common to > all hosts lets it stay constant no matter how you move the guest around. > originally Xen supported migration only between identical hosts, but there's > some special features to allow this on some cases. i don't know how complete > they're currently. > > hope that clears the waters a bit. > > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
