Accept VIRTIO_F_VERSION_1 if offered
#196
Merged
Conversation
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
Contributor
Author
|
@qwandor CI for aarch64 succeeded but the logs show the vsock server panicked and because it was in the shell's background, the CI did not fail: |
qwandor
reviewed
Jun 13, 2025
epilys
force-pushed
the
accept-version1-feature-bit
branch
from
a834f9d to
1ddff95
Compare
qwandor
approved these changes
Jun 18, 2025
Collaborator
qwandor
left a comment
qwandor
left a comment
There was a problem hiding this comment.
Looks good, but I'm not sure why the tests are hanging.
Collaborator
|
The test failures do seem legitimate, I can reproduce it locally. Running |
Contributor
Author
|
I guess the |
Contributor
Author
|
By removing the version 1 feature bit from Network's supported_features, the tests don't block. I'm looking into it to see if it's a qemu bug. |
epilys
force-pushed
the
accept-version1-feature-bit
branch
2 times, most recently
from
7e69932 to
91b6876
Compare
Contributor
Author
|
The bug was that |
qwandor
reviewed
Sep 12, 2025
epilys
force-pushed
the
accept-version1-feature-bit
branch
from
91b6876 to
6d19ea2
Compare
Size of header struct depends on whether we're using legacy VIRTIO or in legacy case, if MRG_RXBUF feature was negotiated. This is a problem because in many places we rely on the header size which was hardcoded. Encode whether we're using the legacy layout and decide on runtime which header struct layout to use. If using legacy header, the missing fields are filled with zeros. This is hidden from the API user. Signed-off-by: Manos Pitsidianakis <[email protected]>
Currently, when we initialize a device, we do not conform to section 6.1 of the VIRTIO spec. It says: > 6.1 Driver Requirements: Reserved Feature Bits > A driver MUST accept VIRTIO_F_VERSION_1 if it is offered. To fix conformance, check for presence of the VIRTIO_F_VERSION_1 and accept it if it's offered, always. Signed-off-by: Manos Pitsidianakis <[email protected]>
epilys
force-pushed
the
accept-version1-feature-bit
branch
from
6d19ea2 to
97f5982
Compare
qwandor
approved these changes
Sep 16, 2025
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.
Currently, when we initialize a device, we do not conform to section 6.1 of the VIRTIO spec.
It says:
To fix conformance, check for presence of the VIRTIO_F_VERSION_1 and accept it if it's offered, always.
This is because not only the requirement is a
MUSTbut also a device may fail to operate if it's not accepted:This bug was encountered in COQOS hypervisor which failed with: