From: Laine Stump <laine@laine.org>
To: Alex Williamson <alex.williamson@redhat.com>,
bhelgaas@google.com, linux-pci@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
konrad.wilk@oracle.com, kim.phillips@linaro.org,
gregkh@linuxfoundation.org, agraf@suse.de,
stuart.yoder@freescale.com, libvir-list@redhat.com,
iommu@lists.linux-foundation.org, tech@virtualopensystems.com,
kvmarm@lists.cs.columbia.edu, christoffer.dall@linaro.org
Subject: Re: [libvirt] [PATCH v3] PCI: Introduce new device binding path using pci_dev.driver_override
Date: Thu, 22 May 2014 16:36:24 +0300 [thread overview]
Message-ID: <537DFD58.5040809@laine.org> (raw)
In-Reply-To: <20140520145136.28232.90707.stgit@bling.home>
On 05/20/2014 05:53 PM, 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
I'm not qualified to review the mechanics of the patch, but as a
potential consumer of this new interface (in libvirt), I want to say
that it is *immensely* improved over the racy, error prone method that
the kernel currently has available. The first day that I looked at the
libvirt code that uses the "new_id" method to bind drivers to devices, I
wished that there would instead be an interface more or less identical
to what Alex has described here - simple, deterministic, and with
minimal side effect outside of the exact device and driver pair we want
to bind.
next prev parent reply other threads:[~2014-05-22 13:36 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
2014-05-22 13:36 ` Laine Stump [this message]
[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
2014-05-28 21:59 ` Greg KH
2014-05-28 22:09 ` Bjorn Helgaas
2014-05-28 22:09 ` Bjorn Helgaas
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=537DFD58.5040809@laine.org \
--to=laine@laine.org \
--cc=agraf@suse.de \
--cc=alex.williamson@redhat.com \
--cc=bhelgaas@google.com \
--cc=christoffer.dall@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=iommu@lists.linux-foundation.org \
--cc=kim.phillips@linaro.org \
--cc=konrad.wilk@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=libvir-list@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=stuart.yoder@freescale.com \
--cc=tech@virtualopensystems.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 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.