netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: alex.williamson@redhat.com
Cc: intel-wired-lan@lists.osuosl.org, jeffrey.t.kirsher@intel.com,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] igb/ixgbe: Fix ordering of SR-IOV teardown
Date: Wed, 29 Jul 2015 12:16:30 -0700 (PDT)	[thread overview]
Message-ID: <20150729.121630.2264285348757503000.davem@davemloft.net> (raw)
In-Reply-To: <20150727223753.10121.78169.stgit@gimli.home>

From: Alex Williamson <alex.williamson@redhat.com>
Date: Mon, 27 Jul 2015 17:18:28 -0600

> When running a Windows 2012 R2 guest with a pair of VFs assigned
> through vfio-pci, we run into a problem trying to hot-unplug those VFs
> after the PF has unregistered the netdev.  This is a common scenario
> if the PF is unbound from the driver while VFs are active.  In the
> case of igb, the resulting guest behavior differs slightly between the
> Microsoft provided and Intel add-on guest drivers.  With the Microsoft
> driver, the guest seems to stumble through ejecting both VFs, but
> takes longer than normal to do so.  With the Intel drivers, only one
> VF is unplugged, but Device Manager still shows it as present.  The
> second VF is non-functional but also still shown in Device Manager.
> At this point, the guest is in such a state that it will not cleanly
> shutdown.  With ixgbe VFs, both the Microsoft and Intel drivers take
> on this latter behavior.
> 
> For both, I've found that disabling SR-IOV before unregistering the PF
> netdev device allows the hot-unplug to proceed without interruption or
> further ill behavior in the guest.  This is true regardless of which
> driver is used.  I don't fully understand what dependency is broken
> by unregistering the netdev prior to disabling SR-IOV, but I also
> don't see the benefit in delaying SR-IOV teardown in this call path.
> It could potentially be moved even earlier, but I'll let those more
> familiar with the hardware and code make that determination.  In any
> case, the VM behavior is substantially improved by this slight
> re-ordering.
> 
> I don't have an i40e for testing, but it already appears to disable
> SR-IOV much earlier in the unbind path, so I wouldn't expect to find
> similar issues.  Thanks,

Patch #2 does not apply cleanly, please respin this series against
my 'net' GIT tree, thanks.

  parent reply	other threads:[~2015-07-29 19:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-27 23:18 [PATCH 0/2] igb/ixgbe: Fix ordering of SR-IOV teardown Alex Williamson
2015-07-27 23:18 ` [PATCH 1/2] igb: Teardown SR-IOV before unregister_netdev() Alex Williamson
2015-07-27 23:42   ` [Intel-wired-lan] " Williams, Mitch A
2015-08-11  2:11   ` Brown, Aaron F
2015-07-27 23:18 ` [PATCH 2/2] ixgbe: " Alex Williamson
2015-07-27 23:42   ` [Intel-wired-lan] " Williams, Mitch A
2015-07-29 19:16 ` David Miller [this message]
2015-07-29 19:33   ` [PATCH 0/2] igb/ixgbe: Fix ordering of SR-IOV teardown Alex Williamson
2015-07-29 21:31     ` David Miller
2015-08-03 22:51       ` Jeff Kirsher

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=20150729.121630.2264285348757503000.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=alex.williamson@redhat.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.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).