search

rust-vmm / community

rust-vmm community content
491 stars 27 forks source link

Collaboration / Merge with Ketuvim #62

Open npmccallum opened 5 years ago

npmccallum commented 5 years ago

I'm the author of the Ketuvim project. We currently provide an API for KVM with an emphasis on type safety. However, we are still young so we haven't fully accomplished this goal yet. Perhaps we could find a way to merge the projects or at least collaborate?

One major difference between our two approaches is that rust-vmm publicly uses C types generated with bindgen. Ketuvim's strategy has been to use bindgen to generate initial structures and then remove all public access and add safe methods and types with the same memory layout.

Another (similar) strategy we have taken is to carefully define wrapper types that preserve mutability and lifetimes. This allows the hypervisor to work without unsafe blocks.

One major benefit of Ketuvim is that we have full, working AMD SEV support via the sev crate (of which I'm also the author). Perhaps this crate could be merged into rust-vmm too?

Anyway, let me know your thoughts. What is the right way to move forward?

npmccallum commented 5 years ago

I forgot to mention that we are also working with the rust-os project to define memory layout compatible types for hardware features (like register flags, etc.). These should be reusable for things like register tweaking.

andreeaflorescu commented 5 years ago

Hey @npmccallum I'll take a look at your code, sounds interesting. We definitely don't want to re-invent the wheel where there is no need to. If we could merge the projects/work together that'd be great. When you say an API for KVM do you mean something similar to what we have in kvm-ioctls?

I would also recommend to drop an email to the rust-vmm email list as it has a larger audience.

andreeaflorescu commented 5 years ago

rust-vmm email list: rust-vmm@lists.opendev.org

npmccallum commented 5 years ago

@andreeaflorescu Yes. However, we have one crate that does the job of multiple of your crates. So there isn't exactly a one-to-one mapping.

andreeaflorescu commented 5 years ago

@npmccallum what other crates are you referring to?

npmccallum commented 5 years ago

We cover at least kvm-bindings and kvm-ioctls. We also provide additional types that can be reused in a variety of situations.

npmccallum commented 5 years ago

(Some of this is stuff I'm about to push.)

kailun-qin commented 4 years ago

Hi @npmccallum and @andreeaflorescu , I have made a follow-up work for this based on enarx project. Please kindly help review the drafted PR. Let me know if any comment or suggestion. Thanks a lot.

andreeaflorescu commented 4 years ago

@kailun-qin thanks for the PR! I'll take a look in a couple of days. I need to ramp up on what's up with SEV first :))

alxiord commented 4 years ago

Hey @kailun-qin, I looked over your PR too, there's one thing that stands out in particular - it introduces a dependency of the sev crate, which, if I got it right, is the one embedded in enarx. If that's the case, it introduces a consumption issue, because:

@npmccallum do you have any plans to publish this crate (and/or others :smiley:) from enarx?

npmccallum commented 4 years ago

@aghecenco Yes. We are stabilizing sev over the next few weeks and pushing a release since we are close to our first release of enarx-keepldr (which depends on sev).

npmccallum commented 4 years ago

@aghecenco Also, I think our upcoming changes to the sev API would make the linkage to rust-vmm indirect through the AsRawFd trait (we only need the file descriptor of the VM).

kailun-qin commented 4 years ago

Thank you all for the feedbacks and review comments. I've already seen that https://github.com/enarx/enarx-keepldr, https://github.com/enarx/sev and https://github.com/enarx/sevctl are published out! Let's wait a while and see how to move this forward.

connorkuehl commented 3 years ago

Also, I think our upcoming changes to the sev API would make the linkage to rust-vmm indirect through the AsRawFd trait (we only need the file descriptor of the VM).

This is now the case for the sev crate. Here's an example of an SEV VM launch using kvm-ioctls, passing in the VmFd as an AsRawFd trait object; there are no hard dependencies on any KVM ioctl implementation. So, someone could just pick their favorite KVM ioctls crate and the sev crate would interoperate with it without any fuss as long as the VM's file descriptor is at hand.