From: Bhushan Bharat-R65777 <R65777@freescale.com>
To: Wood Scott-B07421 <B07421@freescale.com>,
        Yoder Stuart-B08248 <B08248@freescale.com>
CC: Kim Phillips <kim.phillips@linaro.org>,
        Christoffer Dall <christoffer.dall@linaro.org>,
        Alex Williamson <alex.williamson@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "a.motakis@virtualopensystems.com" <a.motakis@virtualopensystems.com>,
        "agraf@suse.de" <agraf@suse.de>,
        Sethi Varun-B16395 <B16395@freescale.com>,
        "peter.maydell@linaro.org" <peter.maydell@linaro.org>,
        "santosh.shukla@linaro.org" <santosh.shukla@linaro.org>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
Subject: RE: RFC: (re-)binding the VFIO platform driver to a platform device
Thread-Topic: RFC: (re-)binding the VFIO platform driver to a platform device
Thread-Index: AQHOvtVzBV4rU1waRU2d31z3B2ehfZngRDQAgAAiCgCAAECXgIAAC74AgADT3ICAADVkAIAAAgwAgAADCQCAAB/ggIAACLGAgAACMICAAAU8gIAAIuWAgAE8pICAAAXnAIAABMAAgAAWmACACVTWgIAABWmAgAAGVwCAAAVEgIAAkmlw
Date: Thu, 10 Oct 2013 07:45:05 +0000
Message-ID: <6A3DF150A5B70D4F9B66A25E3F7C888D071AEE4C@039-SN2MPN1-012.039d.mgd.msft.net>
References: <1380738758.12932.43.camel@snotra.buserror.net>
	 <20131002184330.GC5108@cbox> <20131002203735.GA10871@kroah.com>
	 <1380748121.12932.89.camel@snotra.buserror.net>
	 <20131002211631.GA11914@kroah.com>
	 <1380749715.12932.109.camel@snotra.buserror.net>
	 <20131002234009.GA27714@kroah.com>
	 <1380825207.12932.151.camel@snotra.buserror.net>
	 <20131003185434.GA26123@kroah.com>
	 <1380827494.12932.161.camel@snotra.buserror.net>
	 <20131003203226.GB27336@kroah.com>
	 <9F6FE96B71CF29479FF1CDC8046E15036DDA62@039-SN1MPN1-002.039d.mgd.msft.net>
	 <1381346507.7979.334.camel@snotra.buserror.net>
	 <9F6FE96B71CF29479FF1CDC8046E15036DDAB4@039-SN1MPN1-002.039d.mgd.msft.net>
 <1381348999.7979.360.camel@snotra.buserror.net>
In-Reply-To: <1381348999.7979.360.camel@snotra.buserror.net>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Transfer-Encoding: 8bit
Content-Length: 5972
Lines: 134


> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Thursday, October 10, 2013 1:33 AM
> To: Yoder Stuart-B08248
> Cc: Wood Scott-B07421; Kim Phillips; Christoffer Dall; Alex Williamson; linux-
> kernel@vger.kernel.org; a.motakis@virtualopensystems.com; agraf@suse.de; Sethi
> Varun-B16395; Bhushan Bharat-R65777; peter.maydell@linaro.org;
> santosh.shukla@linaro.org; kvm@vger.kernel.org; gregkh@linuxfoundation.org
> Subject: Re: RFC: (re-)binding the VFIO platform driver to a platform device
> 
> On Wed, 2013-10-09 at 14:44 -0500, Yoder Stuart-B08248 wrote:
> >
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, October 09, 2013 2:22 PM
> > > To: Yoder Stuart-B08248
> > > Cc: Wood Scott-B07421; Kim Phillips; Christoffer Dall; Alex
> > > Williamson; linux-kernel@vger.kernel.org;
> > > a.motakis@virtualopensystems.com; agraf@suse.de; Sethi Varun-B16395;
> > > Bhushan Bharat-R65777; peter.maydell@linaro.org;
> > > santosh.shukla@linaro.org; kvm@vger.kernel.org;
> > > gregkh@linuxfoundation.org
> > > Subject: Re: RFC: (re-)binding the VFIO platform driver to a
> > > platform device
> > >
> > > On Wed, 2013-10-09 at 14:02 -0500, Yoder Stuart-B08248 wrote:
> > > > Have been thinking about this issue some more.  As Scott
> > > > mentioned, 'wildcard' matching for a driver can be fairly done in
> > > > the platform bus driver.  We could add a new flag to the platform driver
> struct:
> > > >
> > > > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > > > index 4f8bef3..4d6cf14 100644
> > > > --- a/drivers/base/platform.c
> > > > +++ b/drivers/base/platform.c
> > > > @@ -727,6 +727,10 @@ static int platform_match(struct device *dev,
> > > struct device_driver *drv)
> > > >         struct platform_device *pdev = to_platform_device(dev);
> > > >         struct platform_driver *pdrv = to_platform_driver(drv);
> > > >
> > > > +       /* the driver matches any device */
> > > > +       if (pdrv->match_any)
> > > > +               return 1;
> > > > +
> > > >         /* Attempt an OF style match first */
> > > >         if (of_driver_match_device(dev, drv))
> > > >                 return 1;
> > > >
> > > > However, the more problematic issue is that a bus driver has no
> > > > way to differentiate from an explicit bind request via sysfs and a
> > > > bind that happened through bus probing.
> > >
> > > Again, I think the wildcard match should be orthogonal to "don't
> > > bind by default" as far as the mechanism goes.
> > >
> > > There's already a "bool suppress_bind_attrs" to prevent sysfs
> > > bind/unbind.  I suggested a similar flag to mean the oppsosite --
> > > bind
> > > *only* through sysfs.  Greg KH was skeptical and wanted to see a
> > > patch before any further discussion.
> >
> > Ah, think I understand now...yes that works as well, and would be
> > less intrustive.   So are you writing a patch? :)
> 
> I've been meaning to since the previous round of discussion, but I've been busy.
> Would someone else be able to test it in the context of using it for VFIO?

I wish I could have but I do not have vfio-platform stuff. 

> 
> > It would be something like this, right?
> >
> > diff --git a/drivers/base/dd.c b/drivers/base/dd.c index
> > 35fa368..c9a61ea 100644
> > --- a/drivers/base/dd.c
> > +++ b/drivers/base/dd.c
> > @@ -389,7 +389,7 @@ static int __device_attach(struct device_driver
> > *drv, void *data)  {
> >         struct device *dev = data;
> >
> > -       if (!driver_match_device(drv, dev))
> > +       if (!drv->explicit_bind_only && !driver_match_device(drv,
> > + dev))
> >                 return 0;
> 
> if (drv->explicit_bind_only || !driver_match_device(drv, dev))
> 	return 0;

Scott, 
I am trying to understand what you are proposing here (example "DEVICE" can be handled by "DRIVER1" and "VFIO-PLATFORM-DRIVER"):
 - By default drv->explicit_bind_only will be clear in all drivers.
 - By default device->explicit_bind_only will also be clear for all devices.
 - On boot, matching devices will bound to the respective driver (DEVICE >==> DRIVER1).
   This will never bound with VFIO-PLATFORM-DRIVER. So far same as before.
 - Via Sysfs interface set drv->explicit_bind_only for VFIO-PLATFORM-DRIVER.
 - Then for the devices user want, set device->explicit_bind_only.
 - unbind DEVICE from DRIVER1
 - bind DEVICE with VFIO-PLATFORM-DRIVER. This time it will be successful because (device->explicit_bind_only && drv->explicit_bind_only) is set.
 - Now when done, unbind the DEVICE from VFIO-PLATFORM-DRIVER.
 - Now user can re-bind the device with either DRIVER1 or VFIO-PLATFORM-DRIVER.
 - Now once drv->explicit_bind_only is set in VFIO-PLATFORM-DRIVER, and a new device comes (device - hotplug) then can gets bound to matching drive and not with VFIO-PLATFORM-DRIVER.

This looks ok to me :)

Thanks
-Bharat
> 
> >         return driver_probe_device(drv, dev); @@ -450,7 +450,7 @@
> > static int __driver_attach(struct device *dev, void *data)
> >          * is an error.
> >          */
> >
> > -       if (!driver_match_device(drv, dev))
> > +       if (!drv->explicit_bind_only && !driver_match_device(drv,
> > + dev))
> >                 return 0;
> 
> Likewise -- or error out earlier in driver_attach().
> 
> Otherwise, that looks about right, for the driver side (though driver_attach
> could error out earlier rather than testing it inside the loop).
> 
> The other half of fixing the raciness is to ensure that the device doesn't get
> bound back to a non-VFIO driver (e.g. due to a module load or new_id).  The
> solution I proposed for that was a similar explicit-bind-only flag for a device,
> that the user sets through sysfs prior to unbinding.  This would also be useful
> in non-VFIO contexts to simply say "I don't want to use this device at all".
> 
> -Scott
> 

????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m????????????I?