<story><title>Announcing qboot, a minimal x86 firmware for QEMU</title><url>https://lwn.net/Articles/645455/</url></story><parent_chain><item><author>viraptor</author><text>This is great, but lately I just can&amp;#x27;t keep up with the virtualisation changes. I got really excited about google&amp;#x27;s novm - that&amp;#x27;s dead now. kvmtools never got included into kernel afaik. qboot will be great, but it looks like it doesn&amp;#x27;t really support the light IO solutions (like novm&amp;#x27;s file, rather than block access). Now there&amp;#x27;s clear containers which is actually kvm, which looks like docker-meets-qboot. And many others in between.&lt;p&gt;This doesn&amp;#x27;t seem right, honestly. Half of the projects have the same approach or goals. (quick boot time and no legacy supported) So why do they die and get reinvented every single time?&lt;p&gt;Something is wrong...</text></item></parent_chain><comment><author>stefanha</author><text>&amp;gt; it doesn&amp;#x27;t really support the light IO solutions (like novm&amp;#x27;s file, rather than block access)&lt;p&gt;That is incorrect.  novm just implements the virtio-9p device that QEMU has supported for years.&lt;p&gt;Clear Linux does add something new: a pmem (NVDIMM) device that bypasses the guest kernel&amp;#x27;s page cache.  This involves host kernel, guest kernel, and kvmtool changes.&lt;p&gt;The advantage of pmem is that short-lived VMs can directly access data from the host instead of copying in.  But this feature needs to be added to QEMU&amp;#x2F;KVM anyway to support new persistent memory hardware (see &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;pmem.io&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;pmem.io&amp;#x2F;&lt;/a&gt;) so it won&amp;#x27;t be unique for long.</text></comment>
<story><title>Announcing qboot, a minimal x86 firmware for QEMU</title><url>https://lwn.net/Articles/645455/</url></story><parent_chain><item><author>viraptor</author><text>This is great, but lately I just can&amp;#x27;t keep up with the virtualisation changes. I got really excited about google&amp;#x27;s novm - that&amp;#x27;s dead now. kvmtools never got included into kernel afaik. qboot will be great, but it looks like it doesn&amp;#x27;t really support the light IO solutions (like novm&amp;#x27;s file, rather than block access). Now there&amp;#x27;s clear containers which is actually kvm, which looks like docker-meets-qboot. And many others in between.&lt;p&gt;This doesn&amp;#x27;t seem right, honestly. Half of the projects have the same approach or goals. (quick boot time and no legacy supported) So why do they die and get reinvented every single time?&lt;p&gt;Something is wrong...</text></item></parent_chain><comment><author>wtallis</author><text>Look at what Xen has gone through: &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;wiki.xen.org&amp;#x2F;wiki&amp;#x2F;File:XenModes.png&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;wiki.xen.org&amp;#x2F;wiki&amp;#x2F;File:XenModes.png&lt;/a&gt;&lt;p&gt;They started with HVM and PV, and have since evolved HVM toward PV by removing legacy support and software emulation and have now settled (for now?) on doing every the PV way except where hardware virtualization assistance is faster on modern hardware. Some of this shifting has been due to changes in hardware capabilities, and some of it has been due to earlier efforts being developed from an incomplete understanding of what techniques are faster.</text></comment>