Yeah, this is quite an exciting project, it's very impressive! I'm so looking forward to see this can be integrated with kata! Great job anyway! Thanks Anthony for your nice open source project! Cheers! Wei 发件人: Xu Wang [mailto:xu@hyper.sh] 发送时间: 2018年11月27日 14:09 收件人: Liguori, Anthony <aliguori@amazon.com> 抄送: Liguori, Anthony via Kata-hypervisor <kata-hypervisor@lists.katacontainers.io> 主题: Re: [Kata-hypervisor] Firecracker Micro-VM Thanks Anthony! Very exciting project. Nice to see project like Firecracker and Nemu, which are working on modern secure and high efficiency VMM. Will take a look soon. Have a good time at re:Invent :) Cheers!, Xu [https://track.mixmax.com/api/track/v2/HnAH5XQvEfmfwONKC/gIoNnLyVGc5hGQ1hnI] On Tue, Nov 27, 2018 1:42 PM, Liguori, Anthony via Kata-hypervisor kata-hypervisor@lists.katacontainers.io<mailto:kata-hypervisor@lists.katacontainers.io> wrote: Howdy, Earlier today we released a new Open Source project we're calling Firecracker. I wanted to take a moment to share a little bit about what our goals of this project are since I think it aligns well with a lot we've discussed here. First, let me describe what it is. Firecracker is a VMM written in Rust that supports a minimal device model and loads a Linux and initramfs directly. It only supports virtio devices models (MMIO, not PCI) and has very basic support for things like UART and PC-KBD. It started out based on Crosvm (which is a wonderful piece of code!) but we took it in a different direction being focused much more on the serverless use-case than on the desktop application use-case. My hope is that over time we can share a bunch with the Crosvm project via common crates. Today we are using Firecracker to run portions of both AWS Lambda and AWS Fargate. We wanted to get the project to a point where it was useful and we think we've gotten it there so we're now making it generally available. There is a *ton* of work to do though. I think there's a ton of exploration to do around what is the device model that makes the most sense (I'm not convinced it's virtio-mmio). I also think there's a lot that can be improved on the Linux side too. I'm hoping folks are interested and we're very committed to working with the broader community on this. https://firecracker-microvm.github.io/ On a personal note, I absolutely love Rust! I think the language was made for this purpose. Anyway, we're happy to answer any questions you may have and look forwarding to chatting on the upcoming call on Dec 6th. Regards, Anthony Liguori -- Xu Wang CTO & Cofounder, Hyper github/twitter/wechat: @gnawux http://hyper.sh<http://hyper.sh/> Hyper_: Make VM run like container

On 27/11/18 10:33, Jon Olson wrote:

On Tue, Nov 27, 2018, 1:13 AM Paolo Bonzini <pbonzini@redhat.com <mailto:pbonzini@redhat.com> wrote:

On 27/11/18 06:42, Liguori, Anthony via Kata-hypervisor wrote: > On a personal note, I absolutely love Rust!  I think the language was made for this purpose.

Yes, it's very interesting.  I hope to introduce Rust in QEMU too, and I'd love to discuss with you (also based on your QEMU background) what you think is the best way to hook Rust and C together.

Go the other direction -- use the C as spec, and build up the Rust to meet it.

Don't marry C and Rust unless you have a use case that requires it.

My use case is that, for example, having virtqueue processing in Rust would give me 90% of the benefit of a full rewrite already. It's possibly the only part of QEMU that runs all the time, is exposed to untrusted data and needs to be damn fast. For the specific case of virtqueues, pushing them out of process by writing a vhost-user server in Rust would make sense too. However, you still would not be able to reduce the attack surface of the control plane. QEMU being written in C rather than C++ makes it much simpler to use Rust's FFI; the complicated part of C+Rust seems to be mapping lifetimes back to e.g. C reference counts. That probably means one of these: 1) writing something like Rc or Arc, that sends ref and unref operations back to C. In theory the advantage is that you write the least Rust code, in practice your reimplementation would be much less polished than the Rust standard library so I don't think it's a good idea. 2) converting the core data structures to Rust and then writing a C wrapper for them. The disadvantage is that you have to work bottom-up. On the other hand, the core data structures are also where we have the best testcases so it's probably the easiest. 3) for very special cases such as functions that absolutely have to be inlined, writing the same code twice, in both Rust and C. This would be the case for something like RCU's read side. Paolo

A while ago I looked at https://github.com/crossbeam-rs/crossbeam-epoch, and it seemed like it could be adapted to become an RCU implementation and/or a wrapper for QEMU's RCU.  This would be very important since RCU is used for several central data structures in QEMU (e.g. the memory regions).

Paolo

_______________________________________________ Kata-hypervisor mailing list Kata-hypervisor@lists.katacontainers.io <mailto:Kata-hypervisor@lists.katacontainers.io> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-hypervisor