arch: Correctly set guest physical address space size for AMD - #8291
Merged
rbradford merged 2 commits intoMay 29, 2026
Merged
Conversation
When generating guest CPUID, we set PhysAddrSize (EAX bits 7:0) based on the host's physical address bits. On AMD hosts with SME, get_host_cpu_phys_bits() subtracts the c-bit reduction from this value, but the code here only writes the result to bits 7:0 and leaves GuestPhysAddrSize (bits 23:16) at the unmodified host value. This creates a gap: e.g. PhysAddrSize=43 but GuestPhysAddrSize=48. Guest firmware that reads GuestPhysAddrSize will see a larger address space than the VMM provides, and may place PCI BARs beyond the MMIO bus range. However, Cloud-hypervisor sizes its MMIO bus to phys_bits. Fix by setting both PhysAddrSize (bits 7:0) and GuestPhysAddrSize (bits 23:16) to phys_bits, using mask 0xff00_ff00 instead of 0xffff_ff00. Signed-off-by: Ruben Hakobyan <[email protected]>
get_host_cpu_phys_bits() subtracts the SME c-bit reduction from PhysAddrSize (CPUID 0x80000008 EAX bits 7:0). The result sets the guest's CPUID and MMIO address space size. The c-bit reduction is not needed here. QEMU's equivalent (host_cpu_phys_bits() in target/i386/host-cpu.c) returns PhysAddrSize without reduction. Signed-off-by: Ruben Hakobyan <[email protected]>
rhakobyan
force-pushed
the
sev_snp_address_space_fix
branch
from
May 29, 2026 02:53
651e47b to
0862c5d
Compare
rbradford
approved these changes
May 29, 2026
rbradford
left a comment
Member
There was a problem hiding this comment.
Looks good and i've checked that this behaviour matches QEMU and kernel expections.
rhakobyan
marked this pull request as ready for review
May 29, 2026 10:51
github-merge-queue
Bot
removed this pull request from the merge queue due to no response for status checks
May 29, 2026
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
2 participants
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.
We've seen a guest boot hang when running VMs with Oak stage0 firmware on EC2 c6a.metal instances.
The root cause seems to be that cloud-hypervisor sets CPUID 0x80000008 PhysAddrSize (bits 7:0) to 43 (after SME c-bit reduction) but leaves GuestPhysAddrSize (bits 23:16) at the host default value of 48. Stage0 reads GuestPhysAddrSize to determine the guest address space and places PCI BARs near the top of 48-bit space.
Cloud-hypervisor's MMIO bus only covers 43 bits (mem64 area ends at 0x7ffffeeffff), so those devices are unreachable.
The fix sets both CPUID fields to the same value.
With the second commit we get rid of the reduction to the physical address space size, which doesn't seem to be needed, and just cuts the address space to 43 bits.