Repository navigation
Conversation
Coverage Report for CI Build 42779402185Coverage increased (+0.003%) to 41.758%Details
Uncovered Changes
Coverage RegressionsNo coverage regressions found. Coverage Stats💛 - Coveralls |
Lencerf
force-pushed
the
fix/virtio/mem-deadlock
branch
from
October 5, 2026 07:53
559998d to
5d94d21
Compare
Lencerf
force-pushed
the
fix/virtio/mem-deadlock
branch
from
October 5, 2026 08:02
5d94d21 to
37ac48e
Compare
Lencerf
marked this pull request as draft
October 5, 2026 08:20
A virtio worker holds RamBus::lock_layout() for as long as its device runs, while any change of the guest RAM layout takes the write lock. A change while a device runs therefore blocks until that device resets. For example, a vCPU hangs when the guest enables the DAX window BAR of a virtio-fs device while a virtio-blk device serves the root filesystem, and so does hot-plugging a device with such a BAR. Borrowing the read-copy-update idea of Linux RCU, - a reader calls RamBus::load() to get an Arc<Ram> snapshot, and holds the read lock only to clone the Arc; - a writer calls RamBus::update(), which copies the layout, changes the copy and publishes it. A failed update publishes nothing, and Memory changes all RAM ranges of a region in one update. A snapshot holds the ArcMemPages it maps, so the host mappings stay valid as long as anyone uses the snapshot, even after they are removed from the bus. A running worker keeps using the snapshot taken when its device was activated, so it does not see later layout changes yet. Signed-off-by: Changyuan Lyu <changyuanl@google.com>
Lencerf
force-pushed
the
fix/virtio/mem-deadlock
branch
from
November 10, 2026 08:01
37ac48e to
030b1b4
Compare
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.
A virtio worker holds
RamBus::lock_layout()for as long as its device runs,while any change of the guest RAM layout takes the write lock. A change while a
device runs therefore blocks until that device resets. For example, a vCPU
hangs when the guest enables the DAX window BAR of a virtio-fs device while a
virtio-blk device serves the root filesystem, and so does hot-plugging a device
with such a BAR.
Turn
RamBusinto an RCU cell ofRamsnapshots:RamBus::load()to get anArc<Ram>snapshot, and holds theread lock only to clone the
Arc.RamBus::update(), which copies the layout, changes the copyand publishes it. A failed update publishes nothing, and
Memorychanges allRAM ranges of a region in one update.
A snapshot holds the
ArcMemPagesit maps, so the host mappings stay valid aslong as anyone uses the snapshot, even after they are removed from the bus.
A running worker keeps using the snapshot taken when its device was activated,
so it does not see later layout changes yet. Follow-up changes let virtqueues
own their snapshot and move to new layouts between events, wake idle workers
after an update, and let the vhost-user backend accept memory changes while the
device runs.
The commit passes
cargo +nightly fmt --check,cargo clippy --all-targets -D warningson x86_64-unknown-linux-gnu/musl, aarch64-unknown-linux-gnu andaarch64-apple-darwin, and
cargo test --workspacelocally.