[Proposal] Move iommufd-device-plugin to the KubeVirt organization

[Lee Yarwood]

Hi all,

I'd like to propose moving the iommufd-device-plugin [1] project under
the KubeVirt GitHub organization.

What is it?

The iommufd-device-plugin is a Kubernetes device plugin that opens and
configures /dev/iommu (IOMMUFD) and passes the file descriptor to
virt-launcher pods via SCM_RIGHTS over a unix socket.

On modern kernels (6.2+), IOMMUFD replaces the legacy VFIO container
model. The IOMMUFD file descriptor needs to be pre-configured with
IOMMU_OPTION_RLIMIT_MODE for proper memory pinning accounting during
GPU/PCI device passthrough. Since virt-launcher runs unprivileged and
cannot open /dev/iommu itself, this device plugin handles it.

The plugin registers devices.kubevirt.io/iommufd as a Kubernetes
extended resource. When allocated it opens /dev/iommu, configures the
RLIMIT mode, and passes the configured FD into the container where
virt-launcher hands it to libvirt via virDomainFDAssociate.

Why move it under kubevirt?

This plugin is a key component of the kubevirt-aie project and the
ongoing work on the release-1.8-aie-nv branch. The plan is for the
kubevirt-aie-webhook to inject devices.kubevirt.io/iommufd resource
requests into virt-launcher pods, with the iommufd-device-plugin being
the counterpart that fulfills those requests on the node. Together
they will enable unprivileged GPU/PCI passthrough with IOMMUFD on the
CentOS Stream Accelerated Infrastructure Enablement builds.

Moving it under the kubevirt org alongside kubevirt-aie and
kubevirt-aie-webhook keeps these tightly coupled components under the
same governance, CI infrastructure, and maintainer team.

Looking ahead, future plans are still being discussed but we might end
up integrating the iommufd device plugin directly into
kubevirt/kubevirt in v1.9.0 or later. Having the project under the
kubevirt org now makes that future transition smoother and gives the
wider community visibility into the work in the meantime.

Maintainers

The existing kubevirt-aie-maintainers team (vladikr, jean-edouard,
xpivarc, lyarwood) will maintain the repo.

Licensing

Apache-2.0

The PR to add the repository to the org is here [2].

Feedback and questions welcome.

Thanks,
Lee

[1] https://github.com/vladikr/iommufd-device-plugin
[2] https://github.com/kubevirt/project-infra/pull/4876

[Roman Mohr]

Hi Lee,

without wanting to transform this into an architectural thread, I would have a question regarding to opening /dev/iommu here. Considering that we need SCM_RIGHTS, I wonder if it has implications that any pod could get that file descriptor if they wanted to. Is that something which virt-handler should expose to virt-launcher based on the knowledge that it is a VM pod, or does it not have any security implications?

Thanks,

Roman

--
You received this message because you are subscribed to the Google Groups "kubevirt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubevirt-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/kubevirt-dev/CAPkJ9DvcU6f1jcULE30AgH85_QENs_Hz2C7bSZa8CKJC2ZT6Lg%40mail.gmail.com.

[Vladik Romanovsky]

Hey Roman,

In general, *any* pod has access to the /dev/iommu device, can open and use it.
It's just a misc character device that can be opened directly. The device plugin doesn't grant any new access.
I think, moreover, the iommufd FD itself is harmless, since it's only useful when VFIO devices are becoming attached to it.
That requires having the VFIO devices FDs and only pods that have allocated these devices via some device plugin have those.

The only difference in this device plugin is that it configures IOMMU_OPTION_RLIMIT_MODE (replicating
 libvirt's virIOMMUFDOpenDevice) and then passes the FD to the virt-launcher. This is purely about memory accounting.
By default, the DMA memory account was global, per user, and this change is setting it to per-process RLIMIT_MEMLOCK.
That's replicating what libvirt does in virIOMMUFDOpenDevice (but we can't do this in the virt-launcher). It doesn't grant any additional capabilities.

The SCM_RIGHTS socket itself is created in a pod specific directory and consumed once, so it's not accessible to other pods.

I hope it makes sense.

Thanks,

Vladik 

 

The only differen

[Roman Mohr]

On Fri, Apr 3, 2026 at 5:13 AM Vladik Romanovsky <vrom...@redhat.com> wrote:

Hey Roman,

In general, *any* pod has access to the /dev/iommu device, can open and use it.
It's just a misc character device that can be opened directly. The device plugin doesn't grant any new access.
I think, moreover, the iommufd FD itself is harmless, since it's only useful when VFIO devices are becoming attached to it.
That requires having the VFIO devices FDs and only pods that have allocated these devices via some device plugin have those.

The only difference in this device plugin is that it configures IOMMU_OPTION_RLIMIT_MODE (replicating
 libvirt's virIOMMUFDOpenDevice) and then passes the FD to the virt-launcher. This is purely about memory accounting.
By default, the DMA memory account was global, per user, and this change is setting it to per-process RLIMIT_MEMLOCK.
That's replicating what libvirt does in virIOMMUFDOpenDevice (but we can't do this in the virt-launcher). It doesn't grant any additional capabilities.

The SCM_RIGHTS socket itself is created in a pod specific directory and consumed once, so it's not accessible to other pods.

I hope it makes sense.

Yeah, that makes absolute sense. One final question: Would it make sense to incorporate it into virt-handler as a whole? Then, using the built-in device-passthrough support with IOMMU would be very simple.

If every small component requires an extra pod and extra resources, it creates significant resource consumption and operational complexity. But no too hard thoughts in any way.

Thanks,

Roman

[Vladik Romanovsky]

On Fri, Apr 3, 2026 at 8:33 AM Roman Mohr <rm...@google.com> wrote:

On Fri, Apr 3, 2026 at 5:13 AM Vladik Romanovsky <vrom...@redhat.com> wrote:

Hey Roman,

In general, *any* pod has access to the /dev/iommu device, can open and use it.
It's just a misc character device that can be opened directly. The device plugin doesn't grant any new access.
I think, moreover, the iommufd FD itself is harmless, since it's only useful when VFIO devices are becoming attached to it.
That requires having the VFIO devices FDs and only pods that have allocated these devices via some device plugin have those.

The only difference in this device plugin is that it configures IOMMU_OPTION_RLIMIT_MODE (replicating
 libvirt's virIOMMUFDOpenDevice) and then passes the FD to the virt-launcher. This is purely about memory accounting.
By default, the DMA memory account was global, per user, and this change is setting it to per-process RLIMIT_MEMLOCK.
That's replicating what libvirt does in virIOMMUFDOpenDevice (but we can't do this in the virt-launcher). It doesn't grant any additional capabilities.

The SCM_RIGHTS socket itself is created in a pod specific directory and consumed once, so it's not accessible to other pods.

I hope it makes sense.

Yeah, that makes absolute sense. One final question: Would it make sense to incorporate it into virt-handler as a whole? Then, using the built-in device-passthrough support with IOMMU would be very simple.

Yes, absolutely! :)

That's the plan for 1.9. 

The current separation is mainly intended to minimize changes needed in the https://github.com/kubevirt/kubevirt-aie and to simplify the deployment without the need to change the virt-handler.

Thanks,

Vladik