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

Skip to content

virtio-devices: Respect PCI CFG cap.length for BAR access - #8272

Merged
rbradford merged 3 commits into
cloud-hypervisor:mainfrom
weltling:virtio-pci-cfg-cap-access-width
May 27, 2026
Merged

rbradford merged 3 commits into
cloud-hypervisor:mainfrom
weltling:virtio-pci-cfg-cap-access-width

Conversation

@weltling

Copy link
Copy Markdown
Member

The VIRTIO_PCI_CAP_PCI_CFG indirect access mechanism was ignoring the cap.length field written by the guest driver. PCI config register reads always produce a 4 byte buffer, so when a driver set cap.length to 1 for a byte wide access to device_status at common config offset 0x14, the VMM passed all 4 bytes to read_bar, dispatching to the dword handler which does not cover that offset.

Use cap.length to determine the actual BAR access width per virtio spec 4.1.4.9.1. Also replace the unsafe transmute with the safe Le32::to_native() conversion.

weltling added 2 commits May 23, 2026 16:13
The VIRTIO_PCI_CAP_PCI_CFG indirect access mechanism was ignoring
the cap.length field written by the guest driver. PCI config register
reads always produce a 4 byte buffer, so when a driver set cap.length
to 1 for a byte wide access to device_status at common config offset
0x14, the VMM passed all 4 bytes to read_bar, dispatching to the
dword handler which does not cover that offset.

Use cap.length to determine the actual BAR access width per virtio
spec 4.1.4.9.1. Also replace the unsafe transmute with the safe
Le32::to_native() conversion.

Signed-off-by: Anatol Belski <[email protected]>
Verify that bar_access_params clamps the access length to cap.length
when the PCI config read buffer is larger.

Signed-off-by: Anatol Belski <[email protected]>
@weltling
weltling requested a review from a team as a code owner May 23, 2026 14:17
Verify that bar_access_params uses data_len when it is smaller than
cap.length.

Signed-off-by: Anatol Belski <[email protected]>
@weltling
weltling force-pushed the virtio-pci-cfg-cap-access-width branch from aa6b0ec to 7048e9e Compare May 24, 2026 10:25
@rbradford
rbradford added this pull request to the merge queue May 27, 2026
@rbradford
rbradford removed this pull request from the merge queue due to a manual request May 27, 2026
@rbradford
rbradford added this pull request to the merge queue May 27, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to no response for status checks May 27, 2026
@rbradford
rbradford added this pull request to the merge queue May 27, 2026
@rbradford

Copy link
Copy Markdown
Member

I think this might be causing failures on the vfio test suite - can you take a look?

@rbradford

Copy link
Copy Markdown
Member

Looks like it is working this time - might just have been a flake but please investigate to see if it's possibly related.

Merged via the queue into cloud-hypervisor:main with commit d0634d1 May 27, 2026
41 checks passed
@weltling

Copy link
Copy Markdown
Member Author

Looks like it is working this time - might just have been a flake but please investigate to see if it's possibly related.

Sure, I'm gonna run --integration-vfio locally several times to see what it reveals.

@weltling
weltling deleted the virtio-pci-cfg-cap-access-width branch May 27, 2026 18:14
@weltling

Copy link
Copy Markdown
Member Author

Looks like it is working this time - might just have been a flake but please investigate to see if it's possibly related.

It turns out the vfio test image is private, thus instead I went looking at the CI logs. From there, on the VMM side device activation and BAR reprogramming take place with no anomaly, like

30.905403s: <vcpu2> INFO:pci/src/configuration.rs:1033 -- Detected BAR reprogramming: (BAR 2) 0x3fe0->0x10
30.906290s: <vcpu2> INFO:pci/src/vfio.rs:1339 -- BAR reprogramming parameter is returned: [BarReprogrammingParams { old_base: 3fe000000000, new_base: 1000000000, len: 1000000000, region_type: Memory64BitRegion }]

I'd therefore lean towards flake for now.

Thanks

@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.

2 participants