All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
To: Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	kim.phillips-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	stuart.yoder-KZfg59tc24xl57MIdRCFDg@public.gmane.org,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	agraf-l3A5Bk7waGM@public.gmane.org,
	libvir-list-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	tech-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org,
	kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org,
	christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
Subject: Re: [PATCH v3] PCI: Introduce new device binding path using pci_dev.driver_override
Date: Wed, 28 May 2014 14:59:56 -0700	[thread overview]
Message-ID: <20140528215956.GA7339@kroah.com> (raw)
In-Reply-To: <20140528030742.GO11907-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>

On Tue, May 27, 2014 at 09:07:42PM -0600, Bjorn Helgaas wrote:
> On Tue, May 20, 2014 at 08:53:21AM -0600, Alex Williamson wrote:
> > The driver_override field allows us to specify the driver for a device
> > rather than relying on the driver to provide a positive match of the
> > device.  This shortcuts the existing process of looking up the vendor
> > and device ID, adding them to the driver new_id, binding the device,
> > then removing the ID, but it also provides a couple advantages.
> > 
> > First, the above existing process allows the driver to bind to any
> > device matching the new_id for the window where it's enabled.  This is
> > often not desired, such as the case of trying to bind a single device
> > to a meta driver like pci-stub or vfio-pci.  Using driver_override we
> > can do this deterministically using:
> > 
> > echo pci-stub > /sys/bus/pci/devices/0000:03:00.0/driver_override
> > echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind
> > echo 0000:03:00.0 > /sys/bus/pci/drivers_probe
> > 
> > Previously we could not invoke drivers_probe after adding a device
> > to new_id for a driver as we get non-deterministic behavior whether
> > the driver we intend or the standard driver will claim the device.
> > Now it becomes a deterministic process, only the driver matching
> > driver_override will probe the device.
> > 
> > To return the device to the standard driver, we simply clear the
> > driver_override and reprobe the device:
> > 
> > echo > /sys/bus/pci/devices/0000:03:00.0/driver_override
> > echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind
> > echo 0000:03:00.0 > /sys/bus/pci/drivers_probe
> > 
> > Another advantage to this approach is that we can specify a driver
> > override to force a specific binding or prevent any binding.  For
> > instance when an IOMMU group is exposed to userspace through VFIO
> > we require that all devices within that group are owned by VFIO.
> > However, devices can be hot-added into an IOMMU group, in which case
> > we want to prevent the device from binding to any driver (override
> > driver = "none") or perhaps have it automatically bind to vfio-pci.
> > With driver_override it's a simple matter for this field to be set
> > internally when the device is first discovered to prevent driver
> > matches.
> > 
> > Signed-off-by: Alex Williamson <alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > Cc: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
> 
> Greg, are you going to weigh in on this?  It does seem to solve some real
> problems.  ISTR you had an opinion once, but I don't know your current
> thoughts.

This looks good to me:

Acked-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	linux-pci@vger.kernel.org, kvm@vger.kernel.org,
	konrad.wilk@oracle.com, kim.phillips@linaro.org,
	stuart.yoder@freescale.com, agraf@suse.de,
	libvir-list@redhat.com, iommu@lists.linux-foundation.org,
	christoffer.dall@linaro.org, tech@virtualopensystems.com,
	kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] PCI: Introduce new device binding path using pci_dev.driver_override
Date: Wed, 28 May 2014 14:59:56 -0700	[thread overview]
Message-ID: <20140528215956.GA7339@kroah.com> (raw)
In-Reply-To: <20140528030742.GO11907@google.com>

On Tue, May 27, 2014 at 09:07:42PM -0600, Bjorn Helgaas wrote:
> On Tue, May 20, 2014 at 08:53:21AM -0600, Alex Williamson wrote:
> > The driver_override field allows us to specify the driver for a device
> > rather than relying on the driver to provide a positive match of the
> > device.  This shortcuts the existing process of looking up the vendor
> > and device ID, adding them to the driver new_id, binding the device,
> > then removing the ID, but it also provides a couple advantages.
> > 
> > First, the above existing process allows the driver to bind to any
> > device matching the new_id for the window where it's enabled.  This is
> > often not desired, such as the case of trying to bind a single device
> > to a meta driver like pci-stub or vfio-pci.  Using driver_override we
> > can do this deterministically using:
> > 
> > echo pci-stub > /sys/bus/pci/devices/0000:03:00.0/driver_override
> > echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind
> > echo 0000:03:00.0 > /sys/bus/pci/drivers_probe
> > 
> > Previously we could not invoke drivers_probe after adding a device
> > to new_id for a driver as we get non-deterministic behavior whether
> > the driver we intend or the standard driver will claim the device.
> > Now it becomes a deterministic process, only the driver matching
> > driver_override will probe the device.
> > 
> > To return the device to the standard driver, we simply clear the
> > driver_override and reprobe the device:
> > 
> > echo > /sys/bus/pci/devices/0000:03:00.0/driver_override
> > echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind
> > echo 0000:03:00.0 > /sys/bus/pci/drivers_probe
> > 
> > Another advantage to this approach is that we can specify a driver
> > override to force a specific binding or prevent any binding.  For
> > instance when an IOMMU group is exposed to userspace through VFIO
> > we require that all devices within that group are owned by VFIO.
> > However, devices can be hot-added into an IOMMU group, in which case
> > we want to prevent the device from binding to any driver (override
> > driver = "none") or perhaps have it automatically bind to vfio-pci.
> > With driver_override it's a simple matter for this field to be set
> > internally when the device is first discovered to prevent driver
> > matches.
> > 
> > Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> Greg, are you going to weigh in on this?  It does seem to solve some real
> problems.  ISTR you had an opinion once, but I don't know your current
> thoughts.

This looks good to me:

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

  parent reply	other threads:[~2014-05-28 21:59 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-20 14:53 [PATCH v3] PCI: Introduce new device binding path using pci_dev.driver_override Alex Williamson
2014-05-20 14:53 ` Alex Williamson
     [not found] ` <20140520145136.28232.90707.stgit-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
2014-05-21  8:25   ` Alexander Graf
2014-05-21  8:25     ` Alexander Graf
2014-05-28  3:07   ` Bjorn Helgaas
2014-05-28  3:07     ` Bjorn Helgaas
     [not found]     ` <20140528030742.GO11907-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2014-05-28  3:30       ` Greg KH
2014-05-28  3:30         ` Greg KH
2014-05-28 21:59       ` Greg KH [this message]
2014-05-28 21:59         ` Greg KH
2014-05-28 22:09   ` Bjorn Helgaas
2014-05-28 22:09     ` Bjorn Helgaas
2014-05-22 13:36 ` [libvirt] " Laine Stump

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=20140528215956.GA7339@kroah.com \
    --to=gregkh-hqyy1w1ycw8ekmwlsbkhg0b+6bgklq7r@public.gmane.org \
    --cc=agraf-l3A5Bk7waGM@public.gmane.org \
    --cc=bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
    --cc=christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=kim.phillips-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org \
    --cc=libvir-list-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=stuart.yoder-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
    --cc=tech-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.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.