Hi Archana, On 3/19/20 7:51 AM, Shinde, Archana M wrote:

Hi Adrian,

I am surprised you are seeing a char device on the Kata side, Kata on seeing a vfio device, does a device passthrough for the device. On the guest side, if the driver for the device has been added to the kernel, the device would be bound to the guest driver. We don’t do a vfio assignment on the guest side. You're surprise tranquilizes me :) Indeed I did not expect it either.

Perhaps, this doc explaining how SRIOV devices are passed to Kata using device passthrough will make things clearer: https://github.com/kata-containers/documentation/blob/8d5f2f0783fc2f848514c5...

I would suggest opening an issue on github with your exact setup and logs, so that we can track it there.

Will do.

Thanks, Archana

On 3/17/20, 11:08 AM, "Adrian Moreno" <amorenoz@redhat.com> wrote:

Hi,

I am playing with kata + qemu and SR-IOV passthrough and I have some questions in order to understand it better.

If I add, say for example "/dev/vfio/40" to the kata container, I find the same char device inside the container even though vfio might not even be loaded in the guest kernel, so I wonder:

- Why is kata creating that device? I would expect kata to expose a virtual PCI device (backed by the vfio device mentioned), but: - Wouldn't it be the guest's vfio driver (if any) the one to assign the iommu group to the pci device?

- How is kata creating the device, i.e: what is listening on it?

Thanks for the help.

- Adrián

_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev