lkml.org 
[lkml]   [2014]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v4] PCI: add kernel parameter to override devid<->driver mapping.
From
Date
On Thu, 2014-10-23 at 13:51 +0000, Stuart Yoder wrote:
>
> > -----Original Message-----
> > From: Marcel Apfelbaum [mailto:marcel.a@redhat.com]
> > Sent: Thursday, October 23, 2014 7:32 AM
> > To: Alex Williamson
> > Cc: linux-pci@vger.kernel.org; bhelgaas@google.com; linux-kernel@vger.kernel.org; marcel@redhat.com;
> > mst@redhat.com; Yoder Stuart-B08248
> > Subject: Re: [PATCH v4] PCI: add kernel parameter to override devid<->driver mapping.
> >
> > On Wed, 2014-10-22 at 12:32 -0600, Alex Williamson wrote:
> > > [cc+ stuart]
> > >
> > > On Mon, 2014-10-20 at 17:04 +0300, Marcel Apfelbaum wrote:
> > > > Scanning a lot of devices during boot requires a lot of time.
> > > > On other scenarios there is a need to bind a driver to a specific slot.
> > > >
> > > > Binding devices to pci-stub driver does not work,
> > > > as it will not differentiate between devices of the
> > > > same type. 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,...
> > > >
> > > > Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
> > > > ---
> > > > v3 -> v4:
> > > > - Addressed Alex Williamson's comments:
> > > > - Modified the type of driver_override_entry's fields
> > > > - Used PCI_DEVFN when appropriated
> > > > - Removed redundant checks
> > > > - Replaced BUG_ON with pr_err messages
> > > > - Simpler command line parsing
> > > > - Addressed Michael S. Tsirkin comments
> > > > - removed DRIVER_OVERRIDE_NAME_LENGTH limitation
> > > > v2 -> v3:
> > > > - Corrected subject line
> > > > v1 -> v2:
> > > > - Addressed Michael S. Tsirkin comments
> > > > - Removed 32 slots limitation
> > > > - Better handling of memory allocation failures
> > > > (preferred BUG_ON over error messages)
> > > > - Addressed Alex Williamson's comments:
> > > > - Modified commit message to show parameter usage more clear.
> > > > - I preferred to re-use parse_args instead of manually using
> > > > strstr in order to better comply with command line parsing
> > > > rules.
> > > > - I didn't use any locking when parsing the command line args
> > > > (see parse_done usage) assuming that first call will be
> > > > early in system boot and no race can occur. Please correct
> > > > me if I am wrong.
> > > >
> > > > Notes:
> > > > - I have further ideas on top of this patch based on your reviews.
> > > > I thought of:
> > > > - Use wildcards to specify entire buses/devices, something like:
> > > > driver[0001:02:*.*]=pci-stub
> > > > - Use comma to separate several devices:
> > > > driver[0001:02:03.4,0001:02:04.0,...]=pci-stub
> > > > - Make domain optional:
> > > > driver[00:03.0]=pci-stub
> > > >
> > > > Comments will be appreciated,
> > > > Thanks,
> > > > Marcel
> > > > Documentation/kernel-parameters.txt | 4 ++
> > > > drivers/pci/bus.c | 111 ++++++++++++++++++++++++++++++++++++
> > > > drivers/pci/pci.c | 2 +
> > > > 3 files changed, 117 insertions(+)
> > >
> > > The driver_override feature that we're making use of here is also going
> > > to be supported by platform devices and potentially more bustypes in the
> > > future, so I'm concerned that making a pci specific kernel parameter is
> > > too shortsighted. Instead we could hook on to BUS_NOTIFY_ADD_DEVICE for
> > > bustypes that support driver_override so we can have a common interface.
> > The real question here if those bus types/devices would benefit from this
> > feature, and I also must confess that I have no knowledge of the other buses.
> > Can anyone confirm that it does make sense for them?
>
> We don't have vfio-platform in use yet, so not much actual real world user
> experience yet. But, I think it makes sense. Especially, given that we are
> inventing a kernel parameter I think we should design the syntax so that it
> can work buses can implement support for this. The driver_override mechanism
> is not bus specific, so let's not make the kernel parameter bus specific.
Make sense, point taken.
I'll come up with something.

Thank you Stuart,
Marcel
>
> > > Perhaps:
> > >
> > > driver_override=pci,0000:02:00.0=pci-stub;platform,fakename=vfio-platform
> > >
> > > Finding delimiters that don't conflict may be challenging. Also, can we
> > > assume that bus-name:dev-name is unique for every bustype? It is for
> > > pci, platform?
> > For PCI, sure the domain:bus:dev.func is unique, for platform I have no idea,
> > can anyone that knows "platform" confirm or deny?
>
> Yes, dev-name will be unique. All platform devices are under a single
> platform bus.
>
> Stuart





\
 
 \ /
  Last update: 2014-10-23 16:21    [W:0.056 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site