linux-kernel - Re: [PATCH v4] PCI: add kernel parameter to override devid<->driver mapping.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAErSpo4bx1tZMi1rhKhRoE6v9EVr6iTFVw=oQaLEpzT+h=U5Tg@mail.gmail.com>
Date:	Wed, 22 Oct 2014 15:28:29 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Marcel Apfelbaum <marcel.a@...hat.com>
Cc:	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	marcel@...hat.com, "Michael S. Tsirkin" <mst@...hat.com>,
	"alex.williamson@...hat.com" <alex.williamson@...hat.com>
Subject: Re: [PATCH v4] PCI: add kernel parameter to override devid<->driver mapping.

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@...hat.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.

> 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@...hat.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.

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/