kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Yishai Hadas <yishaih@nvidia.com>,
	bhelgaas@google.com, corbet@lwn.net, alex.williamson@redhat.com,
	diana.craciun@oss.nxp.com, kwankhede@nvidia.com,
	eric.auger@redhat.com, masahiroy@kernel.org,
	michal.lkml@markovi.net, linux-pci@vger.kernel.org,
	linux-doc@vger.kernel.org, kvm@vger.kernel.org,
	linux-s390@vger.kernel.org, linux-kbuild@vger.kernel.org,
	mgurtovoy@nvidia.com, maorg@nvidia.com, leonro@nvidia.com
Subject: Re: [PATCH 09/12] PCI: Add a PCI_ID_F_VFIO_DRIVER_OVERRIDE flag to struct pci_device_id
Date: Thu, 12 Aug 2021 15:26:32 -0500	[thread overview]
Message-ID: <20210812202632.GA2504075@bjorn-Precision-5520> (raw)
In-Reply-To: <20210812195126.GA4026@nvidia.com>

On Thu, Aug 12, 2021 at 04:51:26PM -0300, Jason Gunthorpe wrote:
> On Thu, Aug 12, 2021 at 10:57:07AM -0500, Bjorn Helgaas wrote:
> > On Thu, Aug 12, 2021 at 10:27:28AM -0300, Jason Gunthorpe wrote:
> > > On Wed, Aug 11, 2021 at 02:07:37PM -0500, Bjorn Helgaas wrote:
> > > > On Thu, Aug 05, 2021 at 09:23:57PM -0300, Jason Gunthorpe wrote:
> > 
> > > > Do the other bus types have a flag analogous to
> > > > PCI_ID_F_VFIO_DRIVER_OVERRIDE?  If we're doing something similar to
> > > > other bus types, it'd be nice if the approach were similar.
> > > 
> > > They could, this series doesn't attempt it. I expect the approach to
> > > be similar as driver_override was copied from PCI to other
> > > busses. When this is completed I hope to take a look at it.
> > 
> > I think this would make more sense as two patches:
> > 
> >   - Add a "PCI_ID_DRIVER_OVERRIDE" flag.  This is not VFIO-specific,
> >     since nothing in PCI depends on the VFIO-ness of drivers that use
> >     the flag.  The only point here is that driver id_table entries
> >     with this flag only match when driver_override matches the driver.
> 
> This would require using two flags, one to indicate the above to the
> PCI code and another to indicate the vfio_pci string to
> file2alias. This doesn't seem justified at this point, IMHO.

I don't think it requires two flags.  do_pci_entry() has:

  if (flags & PCI_ID_F_VFIO_DRIVER_OVERRIDE)
    strcpy(alias, "vfio_pci:");

I'm just proposing a rename:

s/PCI_ID_F_VFIO_DRIVER_OVERRIDE/PCI_ID_DRIVER_OVERRIDE/

> >   - Update file2alias.c to export the flags and the "vfio_pci:" alias.
> >     This seems to be the only place where VFIO comes into play, and
> >     putting it in a separate patch will make it much smaller and it
> >     will be clear how it could be extended for other buses.
> 
> Well, I don't want to see a flag called PCI_ID_DRIVER_OVERRIDE mapped
> to the string "vfio_pci", that is just really confusing.

Hahaha, I see, that's fair :)  It confused me for a long time why you
wanted "VFIO" in the flag name because from the kernel's point of
view, the flag is not related to any VFIO-ness.  It's only related to
a special variety of driver_override, and VFIO happens to be one user
of it.

I think a separate patch that maps the flag to "vfio_pci" would be
less confusing because without the distractions of the PCI core
changes, it will be obvious that "vfio_" is a file2alias thing that's
there for userspace convenience, not for kernel reasons.

Do you envision any other prefixes in the future?  I hope we don't
have to clutter pci_match_device() with checking multiple flags.
Maybe the problem is that the modules.alias entry includes "vfio_" --
maybe we need a more generic prefix with just the idea of an
"alternate" driver.

Bjorn

  reply	other threads:[~2021-08-12 20:26 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-21 16:15 [PATCH 00/12] Introduce vfio_pci_core subsystem Yishai Hadas
2021-07-21 16:15 ` [PATCH 01/12] vfio/pci: Rename vfio_pci.c to vfio_pci_core.c Yishai Hadas
2021-07-21 16:15 ` [PATCH 02/12] vfio/pci: Rename vfio_pci_private.h to vfio_pci_core.h Yishai Hadas
2021-07-21 16:16 ` [PATCH 03/12] vfio/pci: Rename vfio_pci_device to vfio_pci_core_device Yishai Hadas
2021-07-21 16:16 ` [PATCH 04/12] vfio/pci: Rename ops functions to fit core namings Yishai Hadas
2021-07-21 16:16 ` [PATCH 05/12] vfio/pci: Include vfio header in vfio_pci_core.h Yishai Hadas
2021-07-21 16:16 ` [PATCH 06/12] vfio/pci: Split the pci_driver code out of vfio_pci_core.c Yishai Hadas
2021-07-21 16:16 ` [PATCH 07/12] vfio/pci: Move igd initialization to vfio_pci.c Yishai Hadas
2021-07-21 16:16 ` [PATCH 08/12] vfio/pci: Move module parameters " Yishai Hadas
2021-07-21 16:16 ` [PATCH 09/12] PCI: Add a PCI_ID_F_VFIO_DRIVER_OVERRIDE flag to struct pci_device_id Yishai Hadas
2021-07-27 16:34   ` Alex Williamson
2021-07-27 17:14     ` Jason Gunthorpe
2021-07-27 23:02       ` Alex Williamson
2021-07-27 23:42         ` Jason Gunthorpe
2021-08-04 20:34   ` Bjorn Helgaas
2021-08-05 16:47     ` Max Gurtovoy
2021-08-06  0:23     ` Jason Gunthorpe
2021-08-11 12:22       ` Max Gurtovoy
2021-08-11 19:07       ` Bjorn Helgaas
2021-08-12 13:27         ` Jason Gunthorpe
2021-08-12 15:57           ` Bjorn Helgaas
2021-08-12 19:51             ` Jason Gunthorpe
2021-08-12 20:26               ` Bjorn Helgaas [this message]
2021-08-12 23:21                 ` Max Gurtovoy
2021-08-13 17:44                   ` Bjorn Helgaas
2021-08-14 23:27                     ` Max Gurtovoy
2021-08-16 17:21                       ` Bjorn Helgaas
2021-08-17 13:01                         ` Max Gurtovoy
2021-08-17 14:13                           ` Bjorn Helgaas
2021-08-17 14:44                             ` Max Gurtovoy
2021-08-12 15:42   ` Bjorn Helgaas
2021-07-21 16:16 ` [PATCH 10/12] vfio: Use select for eventfd Yishai Hadas
2021-07-21 16:16 ` [PATCH 11/12] vfio: Use kconfig if XX/endif blocks instead of repeating 'depends on' Yishai Hadas
2021-07-21 16:16 ` [PATCH 12/12] vfio/pci: Introduce vfio_pci_core.ko Yishai Hadas
2021-07-21 17:39   ` Leon Romanovsky
2021-07-22  9:06     ` Yishai Hadas
2021-07-22  9:22       ` Max Gurtovoy
2021-07-23 14:13         ` Leon Romanovsky
2021-07-25 10:45           ` Max Gurtovoy
2021-07-27 21:54   ` Alex Williamson
2021-07-27 23:09     ` Jason Gunthorpe
2021-07-28  4:56       ` Leon Romanovsky
2021-07-28  5:43       ` Christoph Hellwig
2021-07-28  7:04         ` Arnd Bergmann
2021-07-28  7:17           ` Leon Romanovsky
2021-07-28 12:03         ` Jason Gunthorpe
2021-07-28 12:12           ` Arnd Bergmann
2021-07-28 12:29           ` Christoph Hellwig
2021-07-28 12:47             ` Jason Gunthorpe
2021-07-28 12:55               ` Christoph Hellwig
2021-07-28 13:31                 ` Jason Gunthorpe
2021-07-28 13:08               ` Arnd Bergmann
2021-07-28 17:26                 ` Jason Gunthorpe
2021-08-04 13:41 ` [PATCH 00/12] Introduce vfio_pci_core subsystem Yishai Hadas
2021-08-04 15:27   ` Alex Williamson

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=20210812202632.GA2504075@bjorn-Precision-5520 \
    --to=helgaas@kernel.org \
    --cc=alex.williamson@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=corbet@lwn.net \
    --cc=diana.craciun@oss.nxp.com \
    --cc=eric.auger@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=leonro@nvidia.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=maorg@nvidia.com \
    --cc=masahiroy@kernel.org \
    --cc=mgurtovoy@nvidia.com \
    --cc=michal.lkml@markovi.net \
    --cc=yishaih@nvidia.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).