tests: Remove asserts on the value of local Vsock CID #2975
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
simonjbeaumont
force-pushed
the
sb/vsock-ci
branch
5 times, most recently
from
be4856b to
134ba74
Compare
simonjbeaumont
force-pushed
the
sb/vsock-ci
branch
from
39c43b8 to
07f5bae
Compare
simonjbeaumont
changed the title
simonjbeaumont
force-pushed
the
sb/vsock-ci
branch
from
3dbb403 to
69d1b30
Compare
Lukasa
approved these changes
Nov 20, 2024
Contributor
Lukasa
left a comment
Lukasa
left a comment
There was a problem hiding this comment.
Nice cleanup, thanks @simonjbeaumont!
Lukasa
pushed a commit
to Lukasa/swift-nio
that referenced
this pull request
Nov 22, 2024
### Motivation: We have some tests for our Vsock support that only run when we detect the system supports Vsock. These weren't running in CI but, now we've migrated CI to GitHub Actions, they can. In prototyping this though, I discovered that one of our tests was too strict, and will fail for VMs running on Hyper-V, which is the hypervisor used by GitHub actions. Specifically, we have support for getting the local context ID by a channel option. This is implemented by an ioctl, but the semantics of the return value differ between the various Vsock transport kernel modules: - `virtio_transport`: returns the guest CID, which is a number greater than `VMADDR_CID_HOST`, but less than `VMADDR_CID_ANY`, and returns `VMADDR_CID_ANY` as an error. - `vsock_loopback`: returns `VMADDR_CID_LOCAL` always. - `vmci_transport`: returns the guest CID if the guest and host transport are active; `VMADDR_CID_HOST` if only the host transport is active; and `VMCI_INVALID_ID` otherwise, which happens to be the same value as `VMADDR_CID_ANY`. - `hyperv_transport`: returns `VMADDR_CID_ANY` always. For this reason, we should probably remove any attempts to interpret the validity of the value that comes back from the driver and users will need to know what to do with it. ### Modifications: - tests: Only run Vsock echo tests on Linux, when `vsock_loopback` is loaded. - tests: Remove asserts on the value of local Vsock CID. - ci: Add pipeline that runs Vsock tests. ### Result: - Vsock tests will no longer run unless `vsock_loopback` kernel module is loaded. - Vsock tests will no longer fail in Hyper-V VMs. - Vsock tests will now run in CI. (cherry picked from commit 64eb8bf)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Motivation:
We have some tests for our Vsock support that only run when we detect the system supports Vsock. These weren't running in CI but, now we've migrated CI to GitHub Actions, they can. In prototyping this though, I discovered that one of our tests was too strict, and will fail for VMs running on Hyper-V, which is the hypervisor used by GitHub actions.
Specifically, we have support for getting the local context ID by a channel option. This is implemented by an ioctl, but the semantics of the return value differ between the various Vsock transport kernel modules:
virtio_transport: returns the guest CID, which is a number greater thanVMADDR_CID_HOST, but less thanVMADDR_CID_ANY, and returnsVMADDR_CID_ANYas an error.vsock_loopback: returnsVMADDR_CID_LOCALalways.vmci_transport: returns the guest CID if the guest and host transport are active;VMADDR_CID_HOSTif only the host transport is active; andVMCI_INVALID_IDotherwise, which happens to be the same value asVMADDR_CID_ANY.hyperv_transport: returnsVMADDR_CID_ANYalways.For this reason, we should probably remove any attempts to interpret the validity of the value that comes back from the driver and users will need to know what to do with it.
Modifications:
vsock_loopbackis loaded.Result:
vsock_loopbackkernel module is loaded.