[Rust-VMM] Goals for this list

[Jiang Liu]

Hi,
	Glad to meet you all here! I’m learning firecracker design and code these days, it’s really a great work.
 I have some questions about the memory model and virtio subsystems.
	1) Currently the memory_model subsystem is designed for specific scenarios, is it possible to extend the memory_model to support
more scenarios, such as memfd based mapping and memory subregions with different permission properties?
	2) Do you have any plan to support vhost-user VirtIO drivers?
	3) Is it possible to customize KVM kernel module for serverless usage cases?
Thanks,
Gerry

> On Dec 18, 2018, at 11:31 PM, Florescu, Andreea <fandree at amazon.com> wrote:
> 
> Hi,
> 
> I also started a "research" so to say about what crates we can share. I am working on a proposal and should have something ready in a few days.
> For the device models, I think a better approach would be to also include virtio devices, but export each of them individually using rust features (like we are currently doing in Firecracker with the vsock device).
> 
> One question I have is where would we host the crates? An organization on GitHub with all these crates would be super cool. Something like "rust-vmm" maybe?
> 
> Andreea
> 
> From: Liguori, Anthony <aliguori at amazon.com <mailto:aliguori at amazon.com>>
> Sent: Tuesday, December 18, 2018 1:30 AM
> To: rust-vmm at lists.opendev.org <mailto:rust-vmm at lists.opendev.org>
> Subject: [UNVERIFIED SENDER] [Rust-vmm] Goals for this list
>  
> Hi!
> 
> Very excited about this list and eager to begin discussions.  I wanted to start with what I see as the low hanging fruit and I what I see as the goal of this effort.
> 
> I'd like to build a set of crates, preferrably with a common name, that make it really easy to write VMMs in Rust.  I think Rust is an ideal language for building VMMs and that if the right primitives are there, a lot of interesting VMMs will emerge.
> 
> Some ideas I have for what would make good core creates:
> 
> 1) KVM bindgen bindings.  Right now, there is an issue with bindgen misgenerating code when encountering empty trailing arrays which are used in KVM.  Both crosvm and Firecracker get around this by modifying the headers by hand and then committing the results of bindgen.  Dylan also mentioned that they were unhappy about bindgen performance but this seems like an eventual optimization to me.
> 
> As a side note, I think having OS X hypervisor framework bindings and whatever the new Windows thing is would be pretty cool.  Maybe there's room for a wrapper around the three but it's not something that interesting to me in the near term.
> 
> 2) The crosvm data_model crate.  This one is super critical but easy to misunderstand as it allows for safe access to volatile memory.  Somewhat related is the mmap() bits from sys_util.  Not sure how the crosvm folks feel but I think there is some refactoring here that could be useful to build a memory crate.
> 
> 3) Some traits for device model implementations.  It's easy to really bike shed here so I reckon it's best to start with a concrete device model like a UART, work through what is required for interfaces, and then iterate from there.
> 
> 4) Common device models with only a single implementation (i.e. 16650A).  Not sure about virtio, maybe.
> 
> Curious what other people think here too.  I've got a couple weeks off coming up so I'd love to have some projects to have on here.
> 
> Regards,
> 
> Anthony Liguori
> 
> Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
> _______________________________________________
> Rust-vmm mailing list
> Rust-vmm at lists.opendev.org <mailto:Rust-vmm at lists.opendev.org>
> http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm <http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20181218/6565fb0e/attachment-0001.html>