Thanks to visit codestin.com
Credit goes to github.com

Skip to content

vmm: Reject resizing below the boot size with an error - #8428

Merged
rbradford merged 1 commit into
cloud-hypervisor:mainfrom
rbradford:202606/reject-memory-resize-below-boot
Jun 19, 2026
Merged

rbradford merged 1 commit into
cloud-hypervisor:mainfrom
rbradford:202606/reject-memory-resize-below-boot

Conversation

@rbradford

Copy link
Copy Markdown
Member

This was already handled with user memory zones but not with the default
memory. Make a small refactoring to move the boot RAM check into
MemoryManager rather than split across Vm and MemoryManager.

Signed-off-by: Rob Bradford [email protected]

This was already handled with user memory zones but not with the default
memory. Make a small refactoring to move the boot RAM check into
MemoryManager rather than split across Vm and MemoryManager.

Signed-off-by: Rob Bradford <[email protected]>
@rbradford
rbradford requested a review from a team as a code owner June 18, 2026 14:16
Comment thread vmm/src/memory_manager.rs

/// Forbidden operation. Impossible to resize guest memory below the boot
/// RAM as it is not removable with virtio-mem.
#[error("Invalid resize request: desired_size = {0} below boot size = {1}")]

@phip1611 phip1611 Jun 18, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No strong opinion: would hex make sense here?

Suggested change
#[error("Invalid resize request: desired_size = {0} below boot size = {1}")]
#[error("Invalid resize request: desired_size = 0x{0:x} below boot size = 0x{1:x}")]

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's tricky - addresses should always be hex - but for sizes. I think it's better not (but it's not always readable) - we could convert them to MiB?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree about the sizes not being displayed as hex, but I also like the idea of printing sizes as kiB/MiB/GiB whenever it makes sense. Should we implement the Display trait? But given we can't simply implement it on a usize, should we create a MemorySize or GuestMemorySize so that we would implement Display there?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I personally like the idea of MemorySize with a Display impl. Let's do that in a follow-up and stick here to the raw integer I'd say

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I love this idea - another candidate for our utils crate (although almost all users seem to be in vmm/). For consistency with the other places (i've just checked) I will leave as raw bytes for now.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

although almost all users seem to be in vmm

by the way: Have you seen #7607?

If we ever tackle this, it would improve developer productivity for everyone a lot (at least if you do frequent rebuilds)

@rbradford
rbradford added this pull request to the merge queue Jun 19, 2026
Merged via the queue into cloud-hypervisor:main with commit 6fee484 Jun 19, 2026
39 checks passed
@github-project-automation github-project-automation Bot moved this from 🆕 New to ✅ Done in Cloud Hypervisor Roadmap Jul 8, 2026
@rbradford rbradford added the bug-fix Bug fix to include in release notes label Jul 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug-fix Bug fix to include in release notes

Projects

Status: ✅ Done

Development

Successfully merging this pull request may close these issues.

3 participants