On Sun, 10 Jan 2021 17:07:23 +0200
Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Extend PCI sysfs interface with a new callback that allows configure
> the number of MSI-X vectors for specific SR-IO VF. This is needed
> to optimize the performance of newly bound devices by allocating
> the
On Thu, 14 Jan 2021 13:43:57 -0800
Alexander Duyck wrote:
> On Thu, Jan 14, 2021 at 12:08 PM Jason Gunthorpe wrote:
> >
> > On Thu, Jan 14, 2021 at 11:24:12AM -0800, Alexander Duyck wrote:
> >
> > > > As you say BAR and MSI vector table are not so different, it seems
> > > > perfectly in line
On Thu, 14 Jan 2021 12:31:37 +0200
Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Some SR-IOV capable devices provide an ability to configure specific
> number of MSI-X vectors on their VF prior driver is probed on that VF.
>
> In order to make management easy, provide new read-only sysfs
On Thu, 14 Jan 2021 12:31:36 +0200
Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Extend PCI sysfs interface with a new callback that allows configure
> the number of MSI-X vectors for specific SR-IO VF. This is needed
> to optimize the performance of newly bound devices by allocating
> the
On Fri, 8 Jan 2021 09:25:25 +0200
Leon Romanovsky wrote:
> On Thu, Jan 07, 2021 at 10:54:38PM -0500, Don Dutile wrote:
> > On 1/7/21 7:57 PM, Bjorn Helgaas wrote:
> > > [+cc Alex, Don]
>
> <...>
>
> > > Help me connect the dots here. Is this required because of something
> > > peculiar to
On Fri, 23 Aug 2019 08:14:39 +
Parav Pandit wrote:
> Hi Alex,
>
>
> > -Original Message-
> > From: Jiri Pirko
> > Sent: Friday, August 23, 2019 1:42 PM
> > To: Parav Pandit
> > Cc: Alex Williamson ; Jiri Pirko
> > ; David S . Miller
On Fri, 23 Aug 2019 14:53:06 +
Parav Pandit wrote:
> > -Original Message-
> > From: Alex Williamson
> > Sent: Friday, August 23, 2019 7:58 PM
> > To: Parav Pandit
> > Cc: Jiri Pirko ; Jiri Pirko ; David S
> > . Miller
> > ; Kirti Wankhede
On Fri, 23 Aug 2019 16:14:04 +
Parav Pandit wrote:
> > -Original Message-
> > From: Alex Williamson
> > Sent: Friday, August 23, 2019 9:22 PM
> > To: Parav Pandit
> > Cc: Jiri Pirko ; Jiri Pirko ; David S
> > . Miller
> > ; Kirti Wankhede
On Fri, 8 Mar 2019 16:07:54 -0600
Parav Pandit wrote:
> Inherit dma mask of parent device in child mdev devices, so that
> protocol stack can use right dma mask while doing dma mappings.
>
> Signed-off-by: Parav Pandit
> ---
> drivers/vfio/mdev/mdev_core.c | 4
> 1 file changed, 4 insert
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
> other than the kernel.
>
> A new sysfs value called sri
On Mon, 12 Mar 2018 09:01:54 -0700
Alexander Duyck wrote:
> On Mon, Mar 12, 2018 at 12:59 AM, Christoph Hellwig wrote:
> > On Sun, Mar 11, 2018 at 09:59:09PM -0600, Alex Williamson wrote:
> >> I still struggle to understand why we need this "unmanaged"
> >&g
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
> include:
It appears to enable sriov when the _pf_ is n
On Wed, 28 Feb 2018 09:49:21 -0800
Alexander Duyck wrote:
> On Tue, Feb 27, 2018 at 2:25 PM, Alexander Duyck
> wrote:
> > On Tue, Feb 27, 2018 at 1:40 PM, Alex Williamson
> > wrote:
> >> On Tue, 27 Feb 2018 11:06:54 -0800
> >> Alexander Duyck wrote
On Wed, 28 Feb 2018 16:36:38 -0800
Alexander Duyck wrote:
> On Wed, Feb 28, 2018 at 2:59 PM, Alex Williamson
> wrote:
> > On Wed, 28 Feb 2018 09:49:21 -0800
> > Alexander Duyck wrote:
> >
> >> On Tue, Feb 27, 2018 at 2:25 PM, Alexander Duyck
> >> wr
On Thu, 1 Mar 2018 14:42:40 -0800
Alexander Duyck wrote:
> On Thu, Mar 1, 2018 at 12:22 PM, Alex Williamson
> wrote:
> > On Wed, 28 Feb 2018 16:36:38 -0800
> > Alexander Duyck wrote:
> >
> >> On Wed, Feb 28, 2018 at 2:59 PM, Alex Williamson
> >> wr
On Thu, 1 Mar 2018 18:49:53 -0800
Alexander Duyck wrote:
> On Thu, Mar 1, 2018 at 3:58 PM, Alex Williamson
> wrote:
> > On Thu, 1 Mar 2018 14:42:40 -0800
> > Alexander Duyck wrote:
> >
> >> On Thu, Mar 1, 2018 at 12:22 PM, Alex Williamson
> >> wr
On Fri, 2 Mar 2018 06:54:17 +
"Tian, Kevin" 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
> > > all. I think the Amazon solut
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
> provided here can be used by drivers such as vfio-pci and virt
On Sun, 12 Jul 2020 22:49:21 +0800
Zhu Lingshan wrote:
> We used to detect assigned device via VFIO manipulated device
> conters. This is less flexible consider VFIO is not the only
> interface for assigned device. vDPA devices has dedicated
> backed hardware as well. So this patch tries to detec
On Thu, 16 Jul 2020 19:23:45 +0800
Zhu Lingshan wrote:
> vDPA devices has dedicated backed hardware like
> passthrough-ed devices. Then it is possible to setup irq
> offloading to vCPU for vDPA devices. Thus this patch tries to
> manipulated assigned device counters via irqbypass manager.
>
> We
> 1 file changed, 8 insertions(+), 29 deletions(-)
Thanks!
Acked-by: Alex Williamson
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index 765e0e5d83ed9..33a88103f857f 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -1451,42 +1451,21 @@ static
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 functions. The X540 and X550 have added ACS capabili
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 is only be enable by defau
On Thu, 20 Jul 2017 15:53:04 -0700
Roland Dreier wrote:
> On Thu, Jul 20, 2017 at 3:15 PM, Alex Williamson
> wrote:
>
> > Most of the ACS capabilities are worded as "Must be implemented by
> > devices that implement ..." Shouldn't a hard-wired ACS capabilit
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 ability
> > to control tha
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
> > implemented + enabled. We're
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 confirmed that none of these devices does peer
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 82599 plus the device IDs for X540 and X550
> > > vari
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 - ; isn't a full statement.
>
> > ---
> > drivers/net/
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 specific operation into VF an
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 whi
On Thu, 2015-10-22 at 18:58 +0300, Or Gerlitz wrote:
> On Wed, Oct 21, 2015 at 10:20 PM, Alex Williamson
> wrote:
>
> > This is why the typical VF agnostic approach here is to using bonding
> > and fail over to a emulated device during migration, so performance
> &g
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 a
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 configuration space.
>
> Reproduction:
> Attach the de
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 -0700, Jeff Kirsher wro
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 becomes possible for a guest to
> >> essentially cripple a
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
---
drivers
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
---
drivers
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,
Alex
---
Alex Williamson (2):
igb: Teardown SR-IOV before unregister_netdev()
ixgbe: Teardown SR-IOV before unre
On Wed, 2015-07-29 at 12:16 -0700, David Miller wrote:
> From: Alex Williamson
> 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
rs 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/ethernet/intel/igb/igb_main.c
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
Acked-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
Acked-by
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 capability
> registers in
On Tue, 2015-09-15 at 18:39 +, Rustad, Mark D wrote:
> > On Sep 15, 2015, at 11:19 AM, Alex Williamson
> > wrote:
> >
> > In addition to the (PCI_SLOT() != devfn) issue, I'm concerned about
> > topologies like we see on Skylake. IIRC, the integrated NIC
On Tue, 2015-09-15 at 20:47 +, Rustad, Mark D wrote:
> > On Sep 15, 2015, at 12:04 PM, Alex Williamson
> > wrote:
> >
> >
> > FRU-type information is only one of the use cases of VPD, the spec also
> > defines (PCI rev 3.0, 6.4):
> >
> >
ehavior so that VFs are removed and the PF is functional for other
uses after unbind, regardless of the way VFs are enabled.
Signed-off-by: Alex Williamson
Cc: Greg Rose
Cc: Jeff Kirsher
---
I can only think that not disabling SR-IOV was meant to enable some
sort of persistence for VFs, but
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:
48 matches
Mail list logo
