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

Skip to content

vmm: return all-ones for unregistered MMIO and PIO reads - #8237

Merged
rbradford merged 2 commits into
cloud-hypervisor:mainfrom
arachsys-prs:unregistered-mmio-pio
May 16, 2026
Merged

rbradford merged 2 commits into
cloud-hypervisor:mainfrom
arachsys-prs:unregistered-mmio-pio

Conversation

@arachsys

Copy link
Copy Markdown
Contributor

When reading from an unregistered MMIO or PIO address, mmio_read() and pio_read() weren't initialising the buffer, so guests were reading stale bytes from the previous MMIO/PIO transaction rather than all 0xff bytes like master abort on real hardware.

Fill the buffer with 0xff on invalid reads in each case.

Fixes #7415

@arachsys
arachsys requested a review from a team as a code owner May 16, 2026 08:56
@arachsys

arachsys commented May 16, 2026

Copy link
Copy Markdown
Contributor Author

I could also fix 'read to unregistered address' with 'read from unregistered address' in the two info! messages while we're touching this code if you like? [Edit: saw the 👍 so now done.]

@rbradford rbradford left a comment

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.

Nice! This has been around a long time!

Comment thread vmm/src/vm.rs
Comment thread vmm/src/vm.rs Outdated
Comment thread vmm/src/vm.rs
@rbradford

Copy link
Copy Markdown
Member

FWIW - QEMU returns all zeroes for MMIO (and all ones for PIO) - should we worry about incompatibility here?

@arachsys

arachsys commented May 16, 2026

Copy link
Copy Markdown
Contributor Author

FWIW - QEMU returns all zeroes for MMIO (and all ones for PIO) - should we worry about incompatibility here?

Ah, interesting. The 0xff behaviour seems 'standard' and is certainly what https://github.com/torvalds/linux/blob/v6.17/arch/x86/kernel/cpu/amd.c#L1343 and torvalds/linux@e9576e0 suggest is the correct error value, but I'm not strongly wedded to it.

Either value would fix the strange FCH behaviour in #7415.

arachsys added 2 commits May 16, 2026 14:46
When reading from an unregistered MMIO address, mmio_read() wasn't
initialising the buffer, so guests were reading stale bytes from the
previous MMIO transaction rather than all 0xff bytes like master abort
on real hardware.

Fill data with 0xff on invalid reads.

Correct 'read to unregistered address' info message to 'read from
unregistered address' while we're touching this block.

Signed-off-by: Chris Webb <[email protected]>
When reading from an unregistered PIO address, pio_read() wasn't
initialising the buffer, so guests were reading stale bytes from the
previous PIO transaction rather than all 0xff bytes like master abort
on real hardware.

Fill data with 0xff on invalid reads.

Correct 'read to unregistered address' info message to 'read from
unregistered address' while we're touching this block.

Signed-off-by: Chris Webb <[email protected]>
@arachsys

Copy link
Copy Markdown
Contributor Author

Sorry to follow up to my own reply, but this thread:

https://lore.kernel.org/all/[email protected]/

suggests that qemu is returning 0xffffffff to at least the S5_RESET_STATUS mmio read. (Qemu isn't named in the first message, but it is further down the thread.)

@rbradford
rbradford added this pull request to the merge queue May 16, 2026
Merged via the queue into cloud-hypervisor:main with commit 7b29691 May 16, 2026
41 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.

Strange value for FCH_PM_S5_RESET_STATUS

2 participants