Re: [pci PATCH v4 1/4] pci-iov: Add support for unmanaged SR-IOV

On Mon, 12 Mar 2018 09:01:54 -0700 Alexander Duyck <alexander.du...@gmail.com> wrote: > On Mon, Mar 12, 2018 at 12:59 AM, Christoph Hellwig <h...@lst.de> wrote: > > On Sun, Mar 11, 2018 at 09:59:09PM -0600, Alex Williamson wrote: > >> I still struggle to understa

Re: [pci PATCH v4 1/4] pci-iov: Add support for unmanaged SR-IOV

On Thu, 08 Mar 2018 11:02:29 -0800 Alexander Duyck wrote: > From: Alexander Duyck > > This patch is meant to add some basic functionality to support for SR-IOV > on devices when the VFs are not managed by some other entity in the device >

Re: [PATCH 1/3] pci-iov: Add support for unmanaged SR-IOV

On Fri, 02 Mar 2018 15:44:25 -0800 Alexander Duyck wrote: > From: Alexander Duyck > > This patch is meant to add some basic functionality to support for SR-IOV > on devices when the VFs are not managed by the kernel. The functions >

Re: [PATCH] pci-iov: Add support for unmanaged SR-IOV

On Fri, 2 Mar 2018 06:54:17 + "Tian, Kevin" <kevin.t...@intel.com> wrote: > > From: Alex Williamson > > Sent: Friday, March 2, 2018 4:22 AM > > > > > > I am pretty sure that you are describing is true of some, but not for > > > al

Re: [PATCH] pci-iov: Add support for unmanaged SR-IOV

On Thu, 1 Mar 2018 18:49:53 -0800 Alexander Duyck <alexander.du...@gmail.com> wrote: > On Thu, Mar 1, 2018 at 3:58 PM, Alex Williamson > <alex.william...@redhat.com> wrote: > > On Thu, 1 Mar 2018 14:42:40 -0800 > > Alexander Duyck <alexander.du...@gmail.com> w

Re: [PATCH] pci-iov: Add support for unmanaged SR-IOV

On Thu, 1 Mar 2018 14:42:40 -0800 Alexander Duyck <alexander.du...@gmail.com> wrote: > On Thu, Mar 1, 2018 at 12:22 PM, Alex Williamson > <alex.william...@redhat.com> wrote: > > On Wed, 28 Feb 2018 16:36:38 -0800 > > Alexander Duyck <alexander.du...@gmail.com&

Re: [PATCH] pci-iov: Add support for unmanaged SR-IOV

On Wed, 28 Feb 2018 16:36:38 -0800 Alexander Duyck <alexander.du...@gmail.com> wrote: > On Wed, Feb 28, 2018 at 2:59 PM, Alex Williamson > <alex.william...@redhat.com> wrote: > > On Wed, 28 Feb 2018 09:49:21 -0800 > > Alexander Duyck <alexander.du...@gmail.com&

Re: [PATCH] pci-iov: Add support for unmanaged SR-IOV

On Wed, 28 Feb 2018 09:49:21 -0800 Alexander Duyck <alexander.du...@gmail.com> wrote: > On Tue, Feb 27, 2018 at 2:25 PM, Alexander Duyck > <alexander.du...@gmail.com> wrote: > > On Tue, Feb 27, 2018 at 1:40 PM, Alex Williamson > > <alex.william...@redhat.com>

Re: [PATCH] pci-iov: Add support for unmanaged SR-IOV

On Tue, 27 Feb 2018 11:06:54 -0800 Alexander Duyck wrote: > From: Alexander Duyck > > This patch is meant to add support for SR-IOV on devices when the VFs are > not managed by the kernel. Examples of recent patches attempting to do this

Re: [PATCH] PCI: Update ACS quirk for more Intel 10G NICs

On Fri, 4 Aug 2017 13:28:32 + David Laight wrote: > From: Bjorn Helgaas > > Sent: 03 August 2017 22:49 > > On Thu, Jul 20, 2017 at 02:41:01PM -0700, Roland Dreier wrote: > > > From: Roland Dreier > > > > > > Add one more variant of the

Re: [PATCH] PCI: Update ACS quirk for more Intel 10G NICs

On Thu, 3 Aug 2017 16:49:11 -0500 Bjorn Helgaas wrote: > On Thu, Jul 20, 2017 at 02:41:01PM -0700, Roland Dreier wrote: > > From: Roland Dreier > > > > Add one more variant of the 82599 plus the device IDs for X540 and X550 > > variants. Intel has

Re: [PATCH] PCI: Update ACS quirk for more Intel 10G NICs

On Mon, 24 Jul 2017 12:31:39 -0700 Roland Dreier wrote: > > Is there a misunderstanding of the code flow here? We're never setting > > EC. In the first code block we're just masking out requested > > capabilities where unimplemented capabilities is the same as > >

Re: [PATCH] PCI: Update ACS quirk for more Intel 10G NICs

On Mon, 24 Jul 2017 10:18:56 -0700 Roland Dreier wrote: > > I think that the device implementing ACS and not implementing certain > > features that are "must be implemented if..." is a positive indication > > that the device does not have that behavior and therefore the

Re: [PATCH] PCI: Update ACS quirk for more Intel 10G NICs

On Thu, 20 Jul 2017 15:53:04 -0700 Roland Dreier <roland.dre...@gmail.com> wrote: > On Thu, Jul 20, 2017 at 3:15 PM, Alex Williamson > <alex.william...@redhat.com> wrote: > > > Most of the ACS capabilities are worded as "Must be implemented by > > devices

Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported

On Sat, 22 Jul 2017 12:19:38 +0800 Ding Tianhong wrote: > Hi Sinan, Bjorn: > > On 2017/7/14 21:54, Sinan Kaya wrote: > > On 7/13/2017 9:26 PM, Ding Tianhong wrote: > >> There is no code to enable the PCIe Relaxed Ordering bit in the > >> configuration space, > >> it

Re: [PATCH] PCI: Update ACS quirk for more Intel 10G NICs

On Thu, 20 Jul 2017 14:41:01 -0700 Roland Dreier wrote: > From: Roland Dreier > > Add one more variant of the 82599 plus the device IDs for X540 and X550 > variants. Intel has confirmed that none of these devices does peer-to-peer > between

Re: [PATCH 1/3] Fix ERROR: trailing statements should be on next line

On Mon, 15 May 2017 05:58:05 +0300 "Michael S. Tsirkin" wrote: > On Sun, May 14, 2017 at 07:51:28PM +0200, Maciek Fijalkowski wrote: > > From: Maciej Fijalkowski > > > > Signed-off-by: Maciej Fijalkowski > > I prefer the original form - ;

Re: [net-next 5/5] PCI: disable FLR for 82579 device

On Tue, 27 Sep 2016 13:17:02 -0500 Bjorn Helgaas wrote: > On Sun, Sep 25, 2016 at 10:02:43AM +0300, Neftin, Sasha wrote: > > On 9/24/2016 12:05 AM, Jeff Kirsher wrote: > > >On Fri, 2016-09-23 at 09:01 -0500, Bjorn Helgaas wrote: > > >>On Thu, Sep 22, 2016 at 11:39:01PM

Re: [net-next 5/5] PCI: disable FLR for 82579 device

On Thu, 22 Sep 2016 23:39:01 -0700 Jeff Kirsher wrote: > From: Sasha Neftin > > 82579 has a problem reattaching itself after the device is detached. > The bug was reported by Redhat. The suggested fix is to disable > FLR capability in PCIe

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

On Thu, 11 Aug 2016 11:52:02 -0700 Alexander Duyck wrote: > On Wed, Aug 10, 2016 at 4:54 PM, Benjamin Herrenschmidt > wrote: > > On Wed, 2016-08-10 at 08:47 -0700, Alexander Duyck wrote: > >> > >> The problem is if we don't do this it

Re: [RFC Patch 00/12] IXGBE: Add live migration support for SRIOV NIC

On Fri, 2015-10-23 at 11:36 -0700, Alexander Duyck wrote: > On 10/21/2015 09:37 AM, Lan Tianyu wrote: > > This patchset is to propose a new solution to add live migration support > > for 82599 > > SRIOV network card. > > > > Im our solution, we prefer to put all device specific operation into VF

Re: [Qemu-devel] [RFC Patch 00/12] IXGBE: Add live migration support for SRIOV NIC

On Thu, 2015-10-22 at 15:32 +0300, Michael S. Tsirkin wrote: > On Wed, Oct 21, 2015 at 01:20:27PM -0600, Alex Williamson wrote: > > The trouble here is that the VF needs to be unplugged prior to the start > > of migration because we can't do effective dirty page tracking while

Re: [RFC Patch 00/12] IXGBE: Add live migration support for SRIOV NIC

On Thu, 2015-10-22 at 18:58 +0300, Or Gerlitz wrote: > On Wed, Oct 21, 2015 at 10:20 PM, Alex Williamson > <alex.william...@redhat.com> wrote: > > > This is why the typical VF agnostic approach here is to using bonding > > and fail over to a emulated device durin

Re: [RFC Patch 00/12] IXGBE: Add live migration support for SRIOV NIC

On Wed, 2015-10-21 at 21:45 +0300, Or Gerlitz wrote: > On Wed, Oct 21, 2015 at 7:37 PM, Lan Tianyu wrote: > > This patchset is to propose a new solution to add live migration support > > for 82599 SRIOV network card. > > > In our solution, we prefer to put all device

Re: [PATCH V4 1/2] pci: Add dev_flags bit to access VPD through function 0

On Mon, 2015-07-13 at 11:40 -0700, Mark D Rustad wrote: > From: Mark Rustad > > Add a dev_flags bit, PCI_DEV_FLAGS_VPD_REF_F0, to access VPD through > function 0 to provide VPD access on other functions. This is for > hardware devices that provide copies of the same VPD

Re: [PATCH V4 1/2] pci: Add dev_flags bit to access VPD through function 0

On Tue, 2015-09-15 at 18:39 +, Rustad, Mark D wrote: > > On Sep 15, 2015, at 11:19 AM, Alex Williamson <alex.william...@redhat.com> > > wrote: > > > > In addition to the (PCI_SLOT() != devfn) issue, I'm concerned about > > topologies like we see on Skylak

Re: [PATCH V4 1/2] pci: Add dev_flags bit to access VPD through function 0

On Tue, 2015-09-15 at 20:47 +, Rustad, Mark D wrote: > > On Sep 15, 2015, at 12:04 PM, Alex Williamson <alex.william...@redhat.com> > > wrote: > > > > > > FRU-type information is only one of the use cases of VPD, the spec also > > defines (PCI rev

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

in the unbind path, so I wouldn't expect to find similar issues. Thanks, Alex --- Alex Williamson (2): igb: Teardown SR-IOV before unregister_netdev() ixgbe: Teardown SR-IOV before unregister_netdev() drivers/net/ethernet/intel/igb/igb_main.c |8 drivers/net/ethernet/intel

[PATCH v2 1/2] igb: Teardown SR-IOV before unregister_netdev()

by shutting down the VM or hot-unplugging the devices from the VM. Unfortunately in the case of a Windows 2012 R2 guest, hot-unplug is broken due to the ordering of the PF driver teardown. Disabling SR-IOV prior to unregister_netdev() avoids this issue. Signed-off-by: Alex Williamson alex.william

[PATCH v2 2/2] ixgbe: Teardown SR-IOV before unregister_netdev()

by shutting down the VM or hot-unplugging the devices from the VM. Unfortunately in the case of a Windows 2012 R2 guest, hot-unplug is broken due to the ordering of the PF driver teardown. Disabling SR-IOV prior to unregister_netdev() avoids this issue. Signed-off-by: Alex Williamson alex.william

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

On Wed, 2015-07-29 at 12:16 -0700, David Miller wrote: From: Alex Williamson alex.william...@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

[PATCH 2/2] ixgbe: Teardown SR-IOV before unregister_netdev()

by shutting down the VM or hot-unplugging the devices from the VM. Unfortunately in the case of a Windows 2012 R2 guest, hot-unplug is broken due to the ordering of the PF driver teardown. Disabling SR-IOV prior to unregister_netdev() avoids this issue. Signed-off-by: Alex Williamson alex.william

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

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, Alex --- Alex Williamson (2): igb: Teardown SR-IOV before unregister_netdev() ixgbe: Teardown SR-IOV before unregister_netdev() drivers/net

[PATCH] ixgbe: Remove bimodal SR-IOV disabling

and the PF is functional for other uses after unbind, regardless of the way VFs are enabled. Signed-off-by: Alex Williamson alex.william...@redhat.com Cc: Greg Rose gregory.v.r...@intel.com Cc: Jeff Kirsher jeffrey.t.kirs...@intel.com --- I can only think that not disabling SR-IOV was meant

Re: [PATCH] ixgbe: Remove bimodal SR-IOV disabling

On Fri, 2015-07-10 at 21:36 +, Rose, Gregory V wrote: -Original Message- From: Alex Williamson [mailto:alex.william...@redhat.com] Sent: Friday, July 10, 2015 2:32 PM To: intel-wired-...@lists.osuosl.org; Kirsher, Jeffrey T Cc: netdev@vger.kernel.org; linux-ker