From: "Michael S. Tsirkin" <mst@redhat.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Marcel Apfelbaum <marcel.a@redhat.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
marcel@redhat.com,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>
Subject: Re: [PATCH v4] PCI: add kernel parameter to override devid<->driver mapping.
Date: Thu, 23 Oct 2014 16:06:54 +0300 [thread overview]
Message-ID: <20141023130654.GA11446@redhat.com> (raw)
In-Reply-To: <CAErSpo4bx1tZMi1rhKhRoE6v9EVr6iTFVw=oQaLEpzT+h=U5Tg@mail.gmail.com>
On Wed, Oct 22, 2014 at 03:28:29PM -0600, Bjorn Helgaas wrote:
> Hi Marcel,
>
> I'm not quite clear on what the objective is here, so I apologize for
> some questions that probably seem silly.
>
> On Mon, Oct 20, 2014 at 8:04 AM, Marcel Apfelbaum <marcel.a@redhat.com> wrote:
> > Scanning a lot of devices during boot requires a lot of time.
>
> I think what takes a lot of time is the .probe() method for some
> drivers, right? I first thought you meant that it took a long time
> for the PCI core to enumerate a lot of devices, but you're not
> changing anything there.
>
> If the intent is to reduce boot time, I don't think this is a general
> solution. Drivers should be able to schedule asynchronous things in
> their .probe() methods if necessary.
If this worked for all devices, we could just make probe
asynchronous in PCI core.
Unfortunately this doesn't work esp for storage devices
since people expect disks to be available for mount immediately.
If the point of the patch is to speed up boot, we could
try to probe everything in parallel?
Probe is serialized now, right?
> > On other scenarios there is a need to bind a driver to a specific slot.
>
> A short example here would be good. Are you talking about something
> like binding a NIC driver to one device while leaving others unbound
> for use by guests?
>
> > Binding devices to pci-stub driver does not work,
> > as it will not differentiate between devices of the
> > same type.
>
> I assume you mean booting with "pci-stub.ids=$VENDOR:$DEVICE" will
> make pci-stub bind to *all* matching devices, and you only want it to
> bind to some. Maybe pci-stub could be extended to pay attention to
> PCI bus addresses in addition to vendor/device IDs.
>
> > Using some start scripts is error prone.
> >
> > The solution leverages driver_override functionality introduced by
> >
> > commit: 782a985d7af26db39e86070d28f987cad21313c0
> > Author: Alex Williamson <alex.williamson@redhat.com>
> > Date: Tue May 20 08:53:21 2014 -0600
> >
> > PCI: Introduce new device binding path using pci_dev.driver_override
> >
> > In order to bind PCI slots to specific drivers use:
> > pci=driver[xxxx:xx:xx.x]=foo,driver[xxxx:xx:xx.x]=bar,...
>
> If/when you address Alex's comments about other bus types, can you
> also update the changelog to use the canonical commit reference
> format, i.e., 782a985d7af2 ("PCI: Introduce new device binding path
> using pci_dev.driver_override") in this case?
>
> PCI bus numbers are mutable, e.g., they can change with hotplug or
> other configuration changes. But I don't have any better suggestion,
> so I guess all we can do is be aware of this.
We could use slot capability for addressing if that's available.
> Speaking of hotplug, this is only a boot-time kernel parameter, with
> no opportunity to use this, e.g., to add slot/driver pairs, after
> boot. Do you not need that because of Alex's driver_override thing?
> How can we integrate this all together into a coherent whole? I'm a
> little confused as to how this would all be documented in a form
> usable by end-users.
>
> Bjorn
prev parent reply other threads:[~2014-10-23 13:03 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-20 14:04 [PATCH v4] PCI: add kernel parameter to override devid<->driver mapping Marcel Apfelbaum
2014-10-22 18:32 ` Alex Williamson
2014-10-23 12:32 ` Marcel Apfelbaum
2014-10-23 13:11 ` Alex Williamson
2014-10-23 13:36 ` Marcel Apfelbaum
2014-10-23 15:42 ` Stuart Yoder
2014-10-23 13:51 ` Stuart Yoder
2014-10-23 13:52 ` Marcel Apfelbaum
2014-10-23 13:44 ` Stuart Yoder
2014-10-23 13:57 ` Alex Williamson
2014-10-23 14:33 ` Marcel Apfelbaum
2014-10-23 14:49 ` Alex Williamson
2014-10-23 15:00 ` Marcel Apfelbaum
2014-10-23 15:54 ` Alex Williamson
2014-10-23 17:40 ` Marcel Apfelbaum
2014-10-22 21:28 ` Bjorn Helgaas
2014-10-23 12:48 ` Marcel Apfelbaum
2014-10-23 13:06 ` Michael S. Tsirkin [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=20141023130654.GA11446@redhat.com \
--to=mst@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=bhelgaas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=marcel.a@redhat.com \
--cc=marcel@redhat.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