Accept pre-opened VFIO cdev and iommufd FDs#8287
Conversation
0d10fc1 to
cd380da
Compare
|
@arctic-alpaca How is this going to interact with your new proposed FD work - I want to make sure we end up having these clash |
I thought about this and don't think it should be a problem. The main overlap is in how FDs are passed via the CLI or API, and in both cases this change follows the existing status quo (e.g., virtio-net FDs). Whatever redesign we apply to FD handling later should apply to the changes here in the same way. |
saravan2
left a comment
There was a problem hiding this comment.
The first commit build: Bump iommufd-ioctls and vfio-ioctls needs to update fuzz/Cargo.lock because a committed lockfile in our repo that doesn't match the manifests is misleading.
Our CI builds fuzz without --locked so it repairs the stale committed lockfile automatically instead of erroring on it.
I cannot say for sure whether this relaxed setup was intentional so that contributors need not bother updating fuzz/Cargo.lock
Thanks for the ping! The changes in this PR will lead to a bit more churn, but don't conflict with anything I'm working on.
I'm (also) working on replacing the |
2e7fa00 to
c4e988c
Compare
|
All comments are addressed. PTAL. Thank you! |
|
@likebreath Thanks! We're in an unfortunate situation where VFIO integration tests have been red for some time. I don't really have the bandwidth or knowledge to address that - would you be happy landing this first with those tests known failing or would you prefer to try and get those fixed? |
|
@rbradford Thank you for bringing this to my attention. I'd prefer to land this PR first and then address the CI issue around VFIO separately. The changes here are pretty self-contained and is tested by a new integration test. This would also enable @saravan2's work on vfio device live migration as well as the @arctic-alpaca's work on FD refactoring. I also noticed more flakyness around the VFIO CI worker recently, particularly around vfio device hotplug, and I believe it is related to the nested virtualization setup (that relates to virtio-iommu being used for the L1 VM). Need to take further look. |
8d99ab5 to
d0a1dff
Compare
dbe2172 to
91cb6e7
Compare
Signed-off-by: Bo Chen <bchen@crusoe.ai>
Update the seccomp filter for vmm and vcpu thread, because `Drop for VfioIommufd` since vfio-ioctls v0.6.1 now issues IOMMU_DESTROY to release the IOAS allocated for each VM boot. Signed-off-by: Bo Chen <bchen@crusoe.ai>
Relax DeviceConfig::path from PathBuf to Option<PathBuf> in preparation to accept an externally-opened vfio cdev FD. The parser and OpenAPI spec still enforces that `path` is set, so callers see no behavior change. Signed-off-by: Bo Chen <bchen@crusoe.ai> Assisted-by: Claude:Opus-4.7
Add a new `fd: Option<i32>` field to DeviceConfig so a caller can supply a pre-opened vfio cdev FD (e.g. /dev/vfio/devices/vfioN) in addition to the existing sysfs path. The CLI `--device` option now accepts `fd=<n>`, parsed alongside the existing options. Signed-off-by: Bo Chen <bchen@crusoe.ai> Assisted-by: Claude:Opus-4.7
Signed-off-by: Bo Chen <bchen@crusoe.ai> Assisted-by: Claude:Opus-4.7
Signed-off-by: Bo Chen <bchen@crusoe.ai> Assisted-by: Claude:Opus-4.7
`path` is no longer required in the DeviceConfig, since a VFIO device may also be supplied via a pre-opened cdev FD passed via SCM_RIGHTS alongside the /vm.add-device request. Signed-off-by: Bo Chen <bchen@crusoe.ai> Assisted-by: Claude:Opus-4.7
Signed-off-by: Bo Chen <bchen@crusoe.ai> Assisted-by: Claude:Opus-4.7
The CLI `--platform` option now accepts `iommufd_fd=<n>` alongside the existing `iommufd=on|off`. Signed-off-by: Bo Chen <bchen@crusoe.ai> Assisted-by: Claude:Opus-4.7
Signed-off-by: Bo Chen <bchen@crusoe.ai> Assisted-by: Claude:Opus-4.7
This also covers the usage of pre-opened iommufd FD. Signed-off-by: Bo Chen <bchen@crusoe.ai> Assisted-by: Claude:Opus-4.7
91cb6e7 to
b895cd2
Compare
Enable cloud-hypervisor to consume pre-opened VFIO cdev and iommufd file descriptors supplied by the caller, rather than always opening them itself from sysfs and /dev/iommu. This lets a privileged orchestrator open and configure the device nodes once and hand the FDs to an unprivileged VMM, both at boot (CLI) and at runtime (HTTP API). It is also a prerequisite for live migration for VMs using VFIO devices, where the destination VM cannot be tied to the exact sysfs device node on the source host.