[Rust-VMM] [Rust-vmm] Goals for this list

Anthony Liguori aliguori at amazon.com
Wed Dec 19 22:19:26 UTC 2018

Allison Randal <allison at lohutok.net> writes:

> On 12/18/18 2:02 PM, Dylan Reid wrote:
>> On Mon, Dec 17, 2018 at 3:31 PM Liguori, Anthony <aliguori at amazon.com> wrote:
>>> 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.
>> My concerns are only around build time. That's certainly something
>> that can be optimized later and isn't specific to this use of bindgen.
>> It would be great to improve the current, manual bindgen process. It
>> will make using new KVM features easier.
> My experience with bindgen specifically for KVM, was that the result was
> a horrible mess, because linux/kvm.h and ioctl.h made such extensive use
> of #defines embedded within #defines, which bindgen translates into very
> poor Rust macros. (Rust macros are great, far more powerful and
> expressive than C # defines, but the Rust macros that bindgen generates
> automatically from C #defines are poor.)
> I experimented with simply defining the consts[1] and structs[2] in
> Rust, instead of using bindgen for translation, and found that a
> reasonable, modern interface to KVM actually only needs a small subset
> of ioctl.h and linux/kvm.h, and that Rust definitions of all the consts
> and structs are cleaner, more maintainable, and easier to review for
> security than the pile of garbage generated by bindgen. Also, the KVM
> ioctl interface is in more of a stable maintenance phase of development,
> rather than rapid evolution, so it really isn't much effort to maintain
> the Rust consts and structs in parallel to the C header files.
> In general, I think bindgen is great, but it's not a good fit for KVM
> specifically. There is a chance that bindgen could be modified to
> produce more sane Rust consts from C #defines, but at the moment, a
> human translator can do far better work than bindgen, and it's faster
> and more reliable to just do the hand-translation than it is to attempt
> to modify bindgen to do extensive compile-time optimizations on macros.
> I thought about finishing up the Rust consts and structs, and offering
> to contribute them to the KVM project. I could still do that if it would
> be useful to anyone. My own work has moved beyond a focus on Rust
> hypervisors, but I'm actively interested in seeing them move forward, so
> I'm happy to help where I can.

I did look at he work you've done and it's great!  I do think it's
important to cover everything though and especially to get architectures
like aarch64.

I think while the bindgen results are not beautiful, having a bindgen
layer gives us something we can build nicer interfaces on top of.


Anthony Liguori

> Allison
> [1] https://gitlab.com/preon/libkvm/blob/master/src/linux/kvm_consts.rs
> (not complete, just a proof-of-concept)
> [2] https://gitlab.com/preon/libkvm/blob/master/src/linux/kvm_structs.rs
> (not complete, just a proof-of-concept)

More information about the Rust-vmm mailing list