netdev - Re: [PATCH 0/2] igb/ixgbe: Fix ordering of SR-IOV teardown

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20150729.121630.2264285348757503000.davem@davemloft.net>
Date:	Wed, 29 Jul 2015 12:16:30 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	alex.williamson@...hat.com
Cc:	intel-wired-lan@...ts.osuosl.org, jeffrey.t.kirsher@...el.com,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] igb/ixgbe: Fix ordering of SR-IOV teardown

From: Alex Williamson <alex.williamson@...hat.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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html