Message-ID: <b1639ca1ba8f4b7d9a361784bcca6a2e@CY1PR0301MB0748.namprd03.prod.outlook.com>
Date:	Thu, 23 Oct 2014 15:42:52 +0000
From:	Stuart Yoder <stuart.yoder@...escale.com>
To:	Marcel Apfelbaum <marcel.a@...hat.com>,
	Alex Williamson <alex.williamson@...hat.com>
CC:	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"marcel@...hat.com" <marcel@...hat.com>,
	"mst@...hat.com" <mst@...hat.com>,
	Eric Auger <eric.auger@...aro.org>
Subject: RE: [PATCH v4] PCI: add kernel parameter to override devid<->driver
 mapping.



> -----Original Message-----
> From: Marcel Apfelbaum [mailto:marcel.a@...hat.com]
> Sent: Thursday, October 23, 2014 8:37 AM
> To: Alex Williamson
> Cc: linux-pci@...r.kernel.org; bhelgaas@...gle.com; linux-kernel@...r.kernel.org; marcel@...hat.com;
> mst@...hat.com; Yoder Stuart-B08248
> Subject: Re: [PATCH v4] PCI: add kernel parameter to override devid<->driver mapping.
> 
> On Thu, 2014-10-23 at 07:11 -0600, Alex Williamson wrote:
> > On Thu, 2014-10-23 at 15:32 +0300, Marcel Apfelbaum wrote:
> > > 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@...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,...
> > > > >
> > > > > Signed-off-by: Marcel Apfelbaum <marcel.a@...hat.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?
> >
> > Platform devices are adding vfio support, so I expect the next logical
> > question will be how to reserve devices for use by vfio at boot.
> Well, I'll have to learn more about vfio before saying anything,
> but my question is if it can be deferred or it has to be part of
> this patch. If the platform devices do not have a slot like hw address,
> maybe it can be configured separately.
> 
> I saw this patch as a PCI patch, and not "driver_override" expansion;
> meaning that I only leveraged an existing feature, not trying to
> extend it.

I think other buses may want to use the same mechanism to specify driver
bindings, so I think the main thing is to not define a syntax that makes
that problematic.

Looking at your original syntax, I think it could work for different
bus types.  Could have something like:

   platform=driver[xxxx]=foo,driver[xxxx]=vfio-platform
   pci=driver[xxxx:xx:xx.x]=foo,driver[xxxx:xx:xx.x]=bar

So no strong opinion on that vs Alex's proposal:

   driver_override=pci,0000:02:00.0=pci-stub;platform,xxxx=vfio-platform

It seems to me that either could work.

Thanks,
Stuart

Powered by blists - more mailing lists