Global dirty bitmap #324
Merged
Global dirty bitmap #324
+11
−9
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bonzini
added a commit
to bonzini/cloud-hypervisor
that referenced
this pull request
May 21, 2025
For use in QEMU, I would like GuestMemoryRegion to return a BitmapSlice instead of a &Bitmap. This adds some flexibility that QEMU needs in order to support a single global dirty bitmap that is sliced by the various GuestMemoryRegions. However, this removes access to the methods of AtomicBitmap, and in particular reset() and get_and_reset(). Fortunately, cloud-hypervisor always uses GuestMemoryMmap, and therefore `region` is known to be a &GuestRegionMmap. Dereferencing it returns the MmapRegion to which the bitmap is attached, thus calling MmapRegion::bitmap(); this has the same effect as `<GuestRegionMmap as GuestRegion>::bitmap()`, and works both with or without rust-vmm/vm-memory#324. Signed-off-by: Paolo Bonzini <[email protected]>
bonzini
force-pushed
the
global-dirty-bitmap
branch
3 times, most recently
from
34f3532 to
0b3bca9
Compare
bonzini
added a commit
to bonzini/cloud-hypervisor
that referenced
this pull request
May 21, 2025
For use in QEMU, I would like GuestMemoryRegion to return a BitmapSlice instead of a &Bitmap. This adds some flexibility that QEMU needs in order to support a single global dirty bitmap that is sliced by the various GuestMemoryRegions. However, this removes access to the methods of AtomicBitmap, and in particular reset() and get_and_reset(). Fortunately, cloud-hypervisor always uses GuestMemoryMmap, and therefore `region` is known to be a &GuestRegionMmap. Dereferencing it returns the MmapRegion to which the bitmap is attached, thus calling MmapRegion::bitmap(); this has the same effect as `<GuestRegionMmap as GuestRegion>::bitmap()`, and works both with or without rust-vmm/vm-memory#324. Signed-off-by: Paolo Bonzini <[email protected]>
bonzini
requested review from
ShadowCurse,
alexandruag,
jiangliu and
roypat
as code owners
QEMU uses a global bitmap, with each RAM region using an offset into it. This could be easily represented if bitmap() returned a BaseSlice<&'static GlobalBitmap>, but there is a problem: bitmap() currently wants to return a reference to the bitmap! So change it to always return a slice. This is more flexible, and it isn't a performance problem because BitmapSlices are meant to be cheap wrappers around a reference or Arc<> Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
bonzini
force-pushed
the
global-dirty-bitmap
branch
from
0b3bca9 to
817e45b
Compare
4 tasks
github-merge-queue bot
pushed a commit
to cloud-hypervisor/cloud-hypervisor
that referenced
this pull request
May 21, 2025
For use in QEMU, I would like GuestMemoryRegion to return a BitmapSlice instead of a &Bitmap. This adds some flexibility that QEMU needs in order to support a single global dirty bitmap that is sliced by the various GuestMemoryRegions. However, this removes access to the methods of AtomicBitmap, and in particular reset() and get_and_reset(). Fortunately, cloud-hypervisor always uses GuestMemoryMmap, and therefore `region` is known to be a &GuestRegionMmap. Dereferencing it returns the MmapRegion to which the bitmap is attached, thus calling MmapRegion::bitmap(); this has the same effect as `<GuestRegionMmap as GuestRegion>::bitmap()`, and works both with or without rust-vmm/vm-memory#324. Signed-off-by: Paolo Bonzini <[email protected]>
roypat
approved these changes
May 21, 2025
ShadowCurse
approved these changes
May 21, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary of the PR
QEMU uses a global bitmap, with each RAM region using an offset into it. This could be easily represented if bitmap() returned a
BaseSlice<&'static GlobalBitmap>, but there is a problem:bitmap()currently wants to return a reference to the bitmap!So change it to always return a slice, like
VolatileMemoryalready does. This is more flexible, and in general it isn't going to affect performance because usingbitmap()is pretty niche; it's much more common to useVolatileMemory::get_slice()which already builds aBitmapSlice.Because this is a breaking change, I tried to see how much it breaks. I tried building cloud-hypervisor and all the places that needed
bitmap() -> &Self::Bactually knew the type of the region. So it only needed a few extra*to go from the GuestRegionMmap to the MmapRegion.Example changes to clients
Requirements
Before submitting your PR, please make sure you addressed the following
requirements:
git commit -s), and the commit message has max 60 characters for thesummary and max 75 characters for each description line.
test.
Release" section of CHANGELOG.md (if no such section exists, please create one).
unsafecode is properly documented.