guestmem: add supports_locking to gate zero-copy IO#3924
Open
jstarks wants to merge 3 commits into
Open
Conversation
Memory behind an emulated IOMMU translates each guest access on demand and has no stable host mapping, so its pages cannot be locked for zero-copy IO. Devices that lock guest buffers as a fast path would fail or produce incorrect results against such backings. Add a supports_locking query to GuestMemory (and the underlying GuestMemoryAccess trait) that reports whether locking is possible. The result is computed once at construction and cached, since it never changes for a given backing and is checked on hot IO paths; multi-region memory reports support only when every region supports it. Update the block device and virtio-vsock zero-copy paths to consult this query and fall back to bounce buffering / read_at/write_at when locking is unavailable.
|
This PR modifies files containing For more on why we check whole files, instead of just diffs, check out the Rustonomicon |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR adds an explicit supports_locking() capability query to GuestMemory/GuestMemoryAccess so zero-copy IO paths can reliably detect when page-locking is impossible (e.g., guest memory accessed via on-demand translation behind an emulated IOMMU) and fall back to copying/bounce-buffer paths.
Changes:
- Introduces
GuestMemoryAccess::supports_locking()(defaulting tomapping().is_some()) and exposesGuestMemory::supports_locking()with a cached per-backing result. - Computes conservative locking support for multi-region guest memory (only true when all present backing regions support locking).
- Gates zero-copy fast paths in
virtio_vsockanddisk_blockdeviceonsupports_locking(), falling back to copying paths when needed.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| vm/vmcore/guestmem/src/lib.rs | Adds supports_locking() query and caches the value in GuestMemoryInner, including multi-region aggregation. |
| vm/devices/virtio/virtio_vsock/src/lib.rs | Avoids attempting payload locking when guest memory doesn’t support locking, triggering the bounce-buffer path. |
| vm/devices/storage/disk_blockdevice/src/lib.rs | Forces bounce buffering (no zero-copy lock) when guest memory reports locking is unsupported. |
Comment on lines
+1195
to
+1197
| /// Cached result of [`DynGuestMemoryAccess::supports_locking`], since it is | ||
| /// queried on hot zero-copy paths and never changes for a given backing. | ||
| supports_locking: bool, |
Comment on lines
+1468
to
+1472
| // Locking is only supported if every backing region supports it. | ||
| let supports_locking = imps | ||
| .iter() | ||
| .flatten() | ||
| .all(GuestMemoryAccess::supports_locking); |
Comment on lines
+1634
to
+1642
| /// Returns whether this memory supports locking pages via | ||
| /// [`lock_gpns`](Self::lock_gpns) and [`lock_range`](Self::lock_range). | ||
| /// | ||
| /// Memory behind an emulated IOMMU has no stable host mapping and cannot | ||
| /// be locked; zero-copy callers should check this and fall back to a | ||
| /// copying path when it returns `false`. | ||
| pub fn supports_locking(&self) -> bool { | ||
| self.inner.supports_locking | ||
| } |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Memory behind an emulated IOMMU translates each guest access on demand and has no stable host mapping, so its pages cannot be locked for zero-copy IO. Devices that lock guest buffers as a fast path would fail or produce incorrect results against such backings.
Add a supports_locking query to GuestMemory (and the underlying GuestMemoryAccess trait) that reports whether locking is possible. The result is computed once at construction and cached, since it never changes for a given backing and is checked on hot IO paths; multi-region memory reports support only when every region supports it.
Update the block device and virtio-vsock zero-copy paths to consult this query and fall back to bounce buffering / read_at/write_at when locking is unavailable.