Skip to content

[RFC] Simplify type-level handling of vm_memory's Bitmap trait #325

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

roypat
Copy link
Member

@roypat roypat commented Jan 24, 2025

Summary of the PR

Hi vm-virtio folks!

I was messing around with vm-memory's bitmap tracking functionality, in hopes of making it less of a mess (commit in my fork: rust-vmm/vm-memory@ce80a91 - admittedly not sure if I succeeded), but in doing so, I found out why vm-virtio needs those WithBitmapSlice trait bounds. So this PR eliminates them (and has the added advantage of making vm-virtio forward compatible with my bitmap proposal to vm-memory).

Admittedly, I'm a bit worried about all those explicit type hints the compiler suddenly needs in the tests (update: figured out what these are able: Reader::write does not refer to Self as a type at all now, so when I write Reader::<T>::new() the return value will be completely unrelated to T. ugh.) , but figured I'd throw it y'all's way anyway :)

I compiled the vhost workspace against this, and everything goes through without modifications there

Requirements

Before submitting your PR, please make sure you addressed the following
requirements:

  • All commits in this PR have Signed-Off-By trailers (with
    git commit -s), and the commit message has max 60 characters for the
    summary and max 75 characters for each description line.
  • [N/A] All added/changed functionality has a corresponding unit/integration
    test.
  • All added/changed public-facing functionality has entries in the "Upcoming
    Release" section of CHANGELOG.md (if no such section exists, please create one).
  • [N/A] Any newly added unsafe code is properly documented.

The `DescriptorChain::read` and `DescriptorChain::write` define a `B:
BitmapSlice` type parameter. However, the type of the bitmap that will
be associated with the `VolatileSlices` is already transitively
prescribed by the `M` type parameter on the `DescriptorChain` object
itself. To reconcile this, these functions need lengthy
`WithBitmapSlice` bounds (which tells the compiler "these two different
BitMap type variables are actually the same").

Drop the `B: Bitmap` slice parameter from these functions, and instead
simply return `Reader<'a, MS<M::Target>>`, where `MS<M::Target>`
resolves to the bitmap type induced by the guest memory implementation.
This avoids the `WithBitmapSlice` bounds completely.

Signed-off-by: Patrick Roy <roypat@amazon.co.uk>
@roypat roypat force-pushed the bitmap-bounds-fixup branch from b0f1a4c to 2031379 Compare January 24, 2025 18:07
@stefano-garzarella
Copy link
Member

Admittedly, I'm a bit worried about all those explicit type hints the compiler suddenly needs in the tests (update: figured out what these are able: Reader::write does not refer to Self as a type at all now, so when I write Reader::<T>::new() the return value will be completely unrelated to T. ugh.) , but figured I'd throw it y'all's way anyway :)

Yep, I'm a bit worried too.

I compiled the vhost workspace against this, and everything goes through without modifications there

I think you should try the vhost-devices workspace where there are the devices that really consume the queues, maybe there we have more to change.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants