rust-vmm / vfio-ioctls Goto Github PK

The new function wants to take a KVM VFIO device.

This is fine within the context of rust-vmm, but userspace drivers may not care about KVM at all. Removing this restriction can potentially make this crate more useful to a wider audience.

I'm in the process of plumbing through MSHV code to vfio-ioctls.

Andreea made a suggestion at #2 (comment). Unfortunately there are still some KVM specific calls that can't be expressed easily with traits.

I'm thinking about introducing a kvm feature and a mshv feature, just like what we did in Cloud Hypervisor's hypervisor crate.

Any comments on this approach?

It should be vfio_map_guest_memory.

This crate does not have any test. We discussed about this at the sync meeting and @jiangliu mentioned that there are some hardware dependencies.

Can we come up with a list of tests that we can implement that could work on the current host running the CI?

Something really basic works on my machine, so I assume it will work in the CI as well:

#[cfg(test)]
mod test {
    use std::sync::Arc;
    use kvm_bindings::bindings::{kvm_create_device, kvm_device_type_KVM_DEV_TYPE_VFIO};
    use kvm_ioctls::Kvm;
    use crate::{VfioContainer, VfioDevice};

    #[test]
    fn test_create_container() {
        let kvm = Kvm::new().unwrap();
        let vm = kvm.create_vm().unwrap();

        let mut vfio_dev = kvm_create_device {
            type_: kvm_device_type_KVM_DEV_TYPE_VFIO,
            fd: 0,
            flags: 0,
        };

        let device_fd = vm.create_device(&mut vfio_dev).unwrap();
        let vfio_container = VfioContainer::new(Arc::new(device_fd)).unwrap();
    }
}

At this point this test is not doing anything useful, but we can add some checks about assumptions that need to hold true. I would be interested in coming up with a list of test that we can write so maybe we can add them in separate issues.

@jiangliu @rbradford @sboeuf what do you think?

To ease maintenance, it would be great to merge vfio-bindings and vfio-ioctls into a workspace. And rename the vfio-ioctls repo to vfio.

I'm opening this issue as I'd like to know about the list of capabilities exposed by VFIO for each region in case the flag VFIO_REGION_INFO_FLAG_CAPS is present. And in particular, I'd like to identify when a region has VFIO_REGION_INFO_CAP_MSIX_MAPPABLE set, so that I don't ignore the mapping of the BAR containing the MSIX table.

I looked at the current code and realized there's only one capability being supported: VFIO_REGION_INFO_CAP_SPARSE_MMAP. The problem with the current implementation is that it is fully specific to VFIO_REGION_INFO_CAP_SPARSE_MMAP and it assumes there's gonna be only one capability. Moreover, everything's hidden internally, meaning the consumer of the crate has no idea if the capability was present or not.

@jiangliu any suggestion about the best way to solve this? I was thinking we should introduce a new field as part of VfioRegion, which would contain a list of VfioRegionInfoCap, where VfioRegionInfoCap would contain the information we need.
Or we can go much simpler by providing the caller with the list of capabilities associated with a region.
WDYT?