All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Alex Williamson" <alex.williamson@nvidia.com>
Cc: <alex@shazbot.org>, <kvm@vger.kernel.org>
Subject: Re: [PATCH] vfio/pci: Require vfio_device_ops.name
Date: Tue, 31 Mar 2026 23:48:50 +0200	[thread overview]
Message-ID: <DHHARIP50BM1.2DW62G3K7DDI2@kernel.org> (raw)
In-Reply-To: <20260331202443.2598404-1-alex.williamson@nvidia.com>

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>

      reply	other threads:[~2026-03-31 21:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-31 20:24 [PATCH] vfio/pci: Require vfio_device_ops.name Alex Williamson
2026-03-31 21:48 ` Danilo Krummrich [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DHHARIP50BM1.2DW62G3K7DDI2@kernel.org \
    --to=dakr@kernel.org \
    --cc=alex.williamson@nvidia.com \
    --cc=alex@shazbot.org \
    --cc=kvm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.