Piavlo wrote: > Alexander Graf wrote: > > virtio drivers have nothing to do with CPU. > > Yes I mistakenly used the term "viritio drivers" instead of > "paravirtual guest support". So what I wanted to ask is if I build a > guest kernel with paravitual support > will it make the native hardware cpu features available inside the guest > like in Xen kernel? Or paravirtual support is for device drivers only > and has no impact on CPU handling like in Xen? > I thought that KVM (as Xen) is a bare metal hypervisor with regards to > giving access native access to the CPU which have svm or vmx support, > and not just CPU emulation. > I'm confused here - can someone shed some light on my ignorance on the > matter? 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. 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. -- Javier -- 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
