Collaboration / Merge with Ketuvim

[npmccallum]

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]

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]

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]

rust-vmm email list: [email protected]

[npmccallum]

@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]

@npmccallum what other crates are you referring to?

[npmccallum]

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

[npmccallum]

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

[kailun-qin]

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]

@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]

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:

• Cargo can't consume sev from the enarx repo because enarx doesn't have a Cargo.toml (I think) => to get the code to build, you'd need to embed sev in kvm-ioctls, which isn't the desired state;
• even if that worked, kvm-ioctls couldn't be published unless sev was on crates.io.

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

[npmccallum]

@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]

@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]

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]

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.