kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Yoder Stuart-B08248 <B08248@freescale.com>
Cc: "a.motakis@virtualopensystems.com"
	<a.motakis@virtualopensystems.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"kvm@vger.kernel.org list" <kvm@vger.kernel.org>,
	Bhushan Bharat-R65777 <R65777@freescale.com>
Subject: Re: binding/unbinding devices to vfio-pci
Date: Tue, 02 Jul 2013 09:22:50 -0600	[thread overview]
Message-ID: <1372778570.30572.881.camel@ul30vt.home> (raw)
In-Reply-To: <9F6FE96B71CF29479FF1CDC8046E15036330AE@039-SN1MPN1-004.039d.mgd.msft.net>

On Tue, 2013-07-02 at 15:13 +0000, Yoder Stuart-B08248 wrote:
> 
> > -----Original Message-----
> > From: Alex Williamson [mailto:alex.williamson@redhat.com]
> > Sent: Tuesday, July 02, 2013 9:46 AM
> > To: Yoder Stuart-B08248
> > Cc: kvm@vger.kernel.org list; Alexander Graf; Bhushan Bharat-R65777; a.motakis@virtualopensystems.com;
> > virtualization@lists.linux-foundation.org
> > Subject: Re: binding/unbinding devices to vfio-pci
> > 
> > On Tue, 2013-07-02 at 14:15 +0000, Yoder Stuart-B08248 wrote:
> > > Alex,
> > >
> > > I'm trying to think through how binding/unbinding of devices will
> > > work with VFIO for platform devices and have a couple of questions
> > > about how vfio-pci works.
> > >
> > > When you bind a device to vfio-pci, e.g.:
> > > # echo 1102 0002 > /sys/bus/pci/drivers/vfio-pci/new_id
> > >
> > > ...I understand that the echo into 'new_id' tells the
> > > vfio pci driver that it now handles the specified PCI ID.
> > >
> > > But now there are 2 drivers that handle that PCI ID,
> > > the original host driver and vfio-pci.   Say that
> > > you hotplug a PCI device that matches that ID.   Which of
> > > the 2 drivers are going to get bound to the device?
> > >
> > > Also, if you unbind a device from vfio-pci and want to
> > > bind it again to the normal host driver you would just
> > > echo the full device info into the 'bind' sysfs file
> > > for the host driver, right?
> > >
> > >     echo 0000:06:0d.0 > /sys/bus/pci/drivers/...
> > 
> > Hi Stuart,
> > 
> > The driver binding interface is far from perfect.  In your scenario
> > where you've added the ID for one device, then hotplug another device
> > with the same ID, the results are indeterminate.  Both vfio-pci and the
> > host driver, assuming it's still loaded, can claim the device, it's just
> > a matter of which gets probed first.
> > 
> > Generally that window should be very short though.  To bind a device,
> > the user should do:
> > 
> > 1) echo ssss:bb:dd.f > /sys/bus/pci/devices/ssss:bb:dd.f/driver/unbind
> > 2) echo vvvv dddd > /sys/bus/pci/drivers/vfio-pci/new_id
> > 3) echo ssss:bb:dd.f > /sys/bus/pci/drivers/vfio-pci/bind
> > 4) echo vvvv dddd > /sys/bus/pci/drivers/vfio-pci/remove_id
> > 
> > There are actually a number of ways you can do this and the default
> > autoprobe behavior really makes step 3) unnecessary as the driver core
> > will probe any unbound devices as soon as a new_id is added to vfio-pci.
> > That can be changed by:
> > 
> > # echo 0 > /sys/bus/pci/drivers_autoprobe
> > 
> > But then we have to worry about races from any devices that might have
> > been hotplugged in the interim.
> 
> But, even apart from hot-plugged devices, what about the device
> we just unbound?  There are now 2 host drivers that can handle the
> device when the autoprobe happens.  Is it just luck that vfio-pci
> is the one that gets the device?

If we have an unbound device and "echo ID > new_id", then just that
driver with the new_id is autoprobed, not the original host driver.
Thanks,

Alex

  reply	other threads:[~2013-07-02 15:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-02 14:15 binding/unbinding devices to vfio-pci Yoder Stuart-B08248
2013-07-02 14:46 ` Alex Williamson
2013-07-02 15:13   ` Yoder Stuart-B08248
2013-07-02 15:22     ` Alex Williamson [this message]
2013-07-02 16:25     ` Hannes Reinecke

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=1372778570.30572.881.camel@ul30vt.home \
    --to=alex.williamson@redhat.com \
    --cc=B08248@freescale.com \
    --cc=R65777@freescale.com \
    --cc=a.motakis@virtualopensystems.com \
    --cc=kvm@vger.kernel.org \
    --cc=virtualization@lists.linux-foundation.org \
    /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;
as well as URLs for NNTP newsgroup(s).