Rust?
What would you do?
________________________________________ From: Anthony Liguori aliguori@amazon.com Sent: Wednesday, June 6, 2018 6:36 PM To: Jessie Frazelle (TUPPERWARE); Ernst, Eric; Sasha Levin; Manohar Castelino Cc: kata-hypervisor@lists.katacontainers.io Subject: Re: [Kata-hypervisor] Link to the Hypervisor Prototype
"Jessie Frazelle (TUPPERWARE)" jessfraz@microsoft.com writes:
Anthony,
Would you be willing to dedicate resources to a _hypothetical_ rewrite of that layer that we could replace qemu with in the form of a go library?
0:)
Go is so 2015. Rust is where it's at now :-)
In all seriousness, I've always felt strongly that a device model needs to avoid garbage collection. While it's not strictly a real time system, OSes have an expectation that PIO or MMIO operations have an upper bound of latency.
The other challenge with Go is unpredictable memory usage due to automatic heap growth. If you want to do planning around density, being able to rationalize about the memory overhead from the VMM layer is pretty important.
Regards,
Anthony Liguori
From: Anthony Liguori aliguori@amazon.com Sent: Wednesday, June 6, 2018 5:00 PM To: Ernst, Eric; Sasha Levin; Manohar Castelino Cc: kata-hypervisor@lists.katacontainers.io Subject: Re: [Kata-hypervisor] Link to the Hypervisor Prototype
"Ernst, Eric" eric.ernst@intel.com writes:
Hey Sasha, Anthony –
I want to set a bit of context here. At the face to face discussion in Vancouver, we had agreed to share the prototyping we have put in place to better understand how far we could go to remove legacy, and minimize the number of device models, while still booting key workloads. Manohar’s response is to address the action that everyone in the meeting requested.
Yup, appreciate the sharing and am disappointed I wasn't able to attend in person. I'm sure Paolo gave you lots of great feedback but let me expand a bit on why I think this is the wrong approach. Ultimately, you are certainly free to continue down this path though but just thought you may find this useful.
The pieces of QEMU that are easy to remove are largely already configurable at build time. From a practical perspective, if you build your "prototype" and measure the resulting executable size compared to a minimalistic configuration, you will find very little actual reduction in code.
The stuff that's hard to remove is deeply ingrained (like QMP and QOM) or parts that are just hairy (like vl.c). Years of effort have gone into decoupling these bits.
So you get very little actual benefit (in code size reduction) by forking but get to bare the burden of independent maintenance.
Regards,
Anthony Liguori
Cheers, Eric
On 6/6/18, 1:46 PM, "Sasha Levin" Alexander.Levin@microsoft.com wrote:
On Wed, Jun 06, 2018 at 08:08:46PM +0000, Castelino, Manohar R wrote: >Folks, > >Please find below the link to the initial prototype code that tries to reduce the number of emulated devices in QEMU that can still boot most cloud workloads. [snip] Out of curiousity, have you looked at kvmtool (https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fwill%2Fkvmtool.git%2F&data=02%7C01%7Cjessfraz%40microsoft.com%7C604dbe2ada034e62d2f908d5cbf07f6b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636639156156262890&sdata=xEWVp9B0rIFl5Ez1cGTMz9ClFs5Ril%2FTJN2SgVta824%3D&reserved=0)? Forking qemu rather than building on top of it (or using something else) isn't going to end well IMO. _______________________________________________ Kata-hypervisor mailing list Kata-hypervisor@lists.katacontainers.io https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.katacontainers.io%2Fcgi-bin%2Fmailman%2Flistinfo%2Fkata-hypervisor&data=02%7C01%7Cjessfraz%40microsoft.com%7C604dbe2ada034e62d2f908d5cbf07f6b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636639156156262890&sdata=kJsXnzaf7xjwtTB6HPpG4nXVVV7YdXlGnp4Eu3Mn2gA%3D&reserved=0
Kata-hypervisor mailing list Kata-hypervisor@lists.katacontainers.io https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.kataco...
Kata-hypervisor mailing list Kata-hypervisor@lists.katacontainers.io https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.kataco...