On Sun, May 28, 2017 at 10:46:45AM +0200, Sylvain Leroux wrote: > On 05/28/2017 08:34 AM, Christoph Hellwig wrote: > > I think your mail just very much eplained why this arbitrary type 1 > > vs type 2 classification doesn't make any sense at all. > > > > As of myself, I would consider more the "type 1 vs type 2" thing as a > continuum rather than two distinct solutions. Most if not all modern > virtualization solutions probably lies somewhere between those two > extreme cases. Not just all modern, but simply all, that's why the difference didn't every make sense. Each IBM's CP (aka VM) always allowed executing some code, and it's been growing more and more. Or VMWare ESXi supports running unmodified Linux binaries - it has various limitations compared to modern Linux, but if you compare it to early Linux or even early unix it's a fully featured OS. At the same time if run Linux/KVM with a a totally cut down kernel config and a root fs that contains nothing but kvmtool or qemu it's about as useless for running general purpose programs on the hypervisor kernel as it gets. > It is somewhat more easy to answer that question for Xen or > Hyper-V--since the dom0/Parent partition *is* really handled as a VM by > those hypervisors. But I don't think there is a similar concept with > KVM. Or is there? There isn't. > An other argument I read is KVM is "type 1" because the hypervisor runs > in kernel space. Whereas (for example) VirtualBox is type 2 because the > hypervisor runs in user space. That's not the case. Virtualbox has a (horrible) kernel module that does all the low-level hypervisor work. Think of it as a badly written replacement for both kvm and kqemu.
