fix(vmm): commit virtio-mem block state after the KVM slot update - #6176

Changes

• VirtioMem::update_range now applies a plug/unplug request one KVM slot at a time. For each slot it updates KVM first and only then commits that slot's block state (plugged_blocks, plugged_size), discarding an unplugged slot after it is committed.
• GuestRegionMmapExt::update_slot commits its per-slot bitmap only after the KVM_SET_USER_MEMORY_REGION update succeeds (and restores the slot's protection if the update fails).
• Added a unit test that plugs a range spanning two KVM slots with the second slot's memory-region update forced to fail, asserting only the first slot's block stays committed. A test-only fault injector on set_user_memory_region drives the failure.

Reason

update_range committed the block state for the whole request up front and only then updated the KVM slots, and update_slot flipped its per-slot bitmap before issuing the KVM ioctl. On a multi-slot plug/unplug that failed part way through (e.g. a slot update returning an error), the committed block state covered the entire range while KVM reflected only the slots that had actually been updated.

Committing each slot's state only after its KVM update succeeds keeps the block state and the KVM slots consistent on a partial failure: the operation stops with both reflecting exactly the slots that were updated, and a block is never discarded before it is committed as unplugged. The whole-range discard is now done per slot as each commits, which issues one discard per intersecting slot instead of one for the range.

1. Why not rollback:

• On a partial failure the operation stops and returns an error, leaving the block state and the KVM slots consistent with each other, rather than rolling back the slots that already succeeded. Rolling back would require re-issuing KVM slot updates, which allocate per-slot metadata and can themselves fail, most likely under the same resource pressure that caused the original failure, with no reliable way to recover if the unwind fails. Committing each slot's state only after its KVM update succeeds keeps the two consistent by construction.

2. Scope/spec note:

• The virtio-mem specification does not define behavior for a request that fails mid-execution, so this is a robustness fix. A slot update only fails under resource pressure (for example, hitting the KVM memory-slot limit), not on a normal request.

License Acceptance

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license. For more information on following Developer
Certificate of Origin and signing off your commits, please check
CONTRIBUTING.md.

PR Checklist

• I have read and understand CONTRIBUTING.md.
• I have run tools/devtool checkbuild --all to verify that the PR passes
  build checks on all supported architectures.
• I have run tools/devtool checkstyle to verify that the PR passes the
  automated style checks.
• I have described what is done in these changes, why they are needed, and
  how they are solving the problem in a clear and encompassing way.
• I have updated any relevant documentation (both in code and in the docs)
  in the PR.
• I have mentioned all user-facing changes in CHANGELOG.md.
• If a specific issue led to this PR, this PR closes the issue.
• When making API changes, I have followed the
  Runbook for Firecracker API changes.
• I have tested all new and changed functionalities in unit tests and/or
  integration tests.
• I have linked an issue to every new TODO.

• This functionality cannot be added in rust-vmm.