public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] vfio/pci: Require vfio_device_ops.name
@ 2026-03-31 20:24 Alex Williamson
  2026-03-31 21:48 ` Danilo Krummrich
  0 siblings, 1 reply; 2+ messages in thread
From: Alex Williamson @ 2026-03-31 20:24 UTC (permalink / raw)
  To: alex; +Cc: Alex Williamson, kvm, Danilo Krummrich

vfio-pci-core code makes use of the vfio_device_ops.name field in order
to set a default driver_override for VFs created on a user-owned PF.
This avoids default driver matching, which might otherwise bind those
VFs to native drivers.

The mechanism for this currently uses kasprintf(), which will set
driver_override to the literal "(null)" if name is NULL.  This is
effective in sequestering the device, but presents a challenging debug
situation to differentiate driver_override being set to "(null)" versus
being NULL and interpreted as "(null)" via the sysfs show attribute.

There's also a tree-wide effort to convert to generic driver_override
support, where passing NULL will generate an error, resulting in a
WARN_ON without setting any driver_override.

All drivers making use of vfio-pci-core already set a driver name,
therefore by requiring this behavior, all of these corner cases are
rendered moot.  This is expected to have no impact on current
in-kernel drivers.

Suggested-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Alex Williamson <alex.williamson@nvidia.com>
---
 drivers/vfio/pci/vfio_pci_core.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index d43745fe4c84..84d60689d386 100644
--- a/drivers/vfio/pci/vfio_pci_core.c
+++ b/drivers/vfio/pci/vfio_pci_core.c
@@ -2139,6 +2139,10 @@ int vfio_pci_core_register_device(struct vfio_pci_core_device *vdev)
 	if (WARN_ON(vdev != dev_get_drvdata(dev)))
 		return -EINVAL;
 
+	/* Drivers must set a name.  Required for sequestering SR-IOV VFs */
+	if (WARN_ON(!vdev->vdev.ops->name))
+		return -EINVAL;
+
 	if (pdev->hdr_type != PCI_HEADER_TYPE_NORMAL)
 		return -EINVAL;
 
-- 
2.51.0


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] vfio/pci: Require vfio_device_ops.name
  2026-03-31 20:24 [PATCH] vfio/pci: Require vfio_device_ops.name Alex Williamson
@ 2026-03-31 21:48 ` Danilo Krummrich
  0 siblings, 0 replies; 2+ messages in thread
From: Danilo Krummrich @ 2026-03-31 21:48 UTC (permalink / raw)
  To: Alex Williamson; +Cc: alex, kvm

On Tue Mar 31, 2026 at 10:24 PM CEST, Alex Williamson wrote:
> vfio-pci-core code makes use of the vfio_device_ops.name field in order
> to set a default driver_override for VFs created on a user-owned PF.
> This avoids default driver matching, which might otherwise bind those
> VFs to native drivers.
>
> The mechanism for this currently uses kasprintf(), which will set
> driver_override to the literal "(null)" if name is NULL.  This is
> effective in sequestering the device, but presents a challenging debug
> situation to differentiate driver_override being set to "(null)" versus
> being NULL and interpreted as "(null)" via the sysfs show attribute.
>
> There's also a tree-wide effort to convert to generic driver_override
> support, where passing NULL will generate an error, resulting in a
> WARN_ON without setting any driver_override.
>
> All drivers making use of vfio-pci-core already set a driver name,
> therefore by requiring this behavior, all of these corner cases are
> rendered moot.  This is expected to have no impact on current
> in-kernel drivers.
>
> Suggested-by: Danilo Krummrich <dakr@kernel.org>
> Signed-off-by: Alex Williamson <alex.williamson@nvidia.com>

Reviewed-by: Danilo Krummrich <dakr@kernel.org>

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-03-31 21:48 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-03-31 20:24 [PATCH] vfio/pci: Require vfio_device_ops.name Alex Williamson
2026-03-31 21:48 ` Danilo Krummrich

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox