Open Stack

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/8d5f2f0783fc2f848514c5d2fd1991fd7b755be7/use-cases/using-SRIOV-and-kata.md
> 
> 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 at 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 at lists.katacontainers.io
>     http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
>     
>