search for: romanovski

On Thu, Jan 26, 2023 at 09:15:03PM +0200, Leon Romanovsky wrote: > From: Leon Romanovsky <leonro at nvidia.com> > > In netdev common pattern, xxtack pointer is forwarded to the drivers ~~~~~~ extack > to be filled with error message. However, the caller can easily > overwrite the filled message. > > Instead of

On Fri, 27 Jan 2023 00:32:13 +0200 Vladimir Oltean wrote: > On Thu, Jan 26, 2023 at 09:15:03PM +0200, Leon Romanovsky wrote: > > From: Leon Romanovsky <leonro at nvidia.com> > > > > In netdev common pattern, xxtack pointer is forwarded to the drivers > ~~~~~~ > extack > > > to be filled with error

In netdev common pattern, extack pointer is forwarded to the drivers to be filled with error message. However, the caller can easily overwrite the filled message. Instead of adding multiple "if (!extack->_msg)" checks before any NL_SET_ERR_MSG() call, which appears after call to the driver, let's add new macro to common code. [1] https://lore.kernel.org/all/Y9Irgrgf3uxOjwUm at

From: Leon Romanovsky <leonro at nvidia.com> In netdev common pattern, xxtack pointer is forwarded to the drivers to be filled with error message. However, the caller can easily overwrite the filled message. Instead of adding multiple "if (!extack->_msg)" checks before any NL_SET_ERR_MSG() call, which appears after call to the driver, let's add this check to common code.

Hello, On Sun, 2023-01-29 at 18:51 +0200, Leon Romanovsky wrote: > In netdev common pattern, extack pointer is forwarded to the drivers > to be filled with error message. However, the caller can easily > overwrite the filled message. > > Instead of adding multiple "if (!extack->_msg)" checks before any > NL_SET_ERR_MSG() call, which appears after call to the

On Fri, Jan 27, 2023 at 12:32:13AM +0200, Vladimir Oltean wrote: > On Thu, Jan 26, 2023 at 09:15:03PM +0200, Leon Romanovsky wrote: > > From: Leon Romanovsky <leonro at nvidia.com> > > > > In netdev common pattern, xxtack pointer is forwarded to the drivers > ~~~~~~ > extack > > > to be filled with

From: Leon Romanovsky <leonro at nvidia.com> Changelog: v1: * Renamed _mlx5_rescan_driver to be mlx5_rescan_driver_locked like in other parts of the mlx5 driver. * Renamed MLX5_INTERFACE_PROTOCOL_VDPA to tbe MLX5_INTERFACE_PROTOCOL_VNET as a preparation to coming series from Eli C. * Some small naming renames in mlx5_vdpa. * Refactored adev index code to make Parav's SF series

On Mon, Nov 02, 2020 at 05:07:59AM +0000, Parav Pandit wrote: > > > > From: Leon Romanovsky <leon at kernel.org> > > Sent: Monday, November 2, 2020 1:46 AM > > > > From: Leon Romanovsky <leonro at nvidia.com> > > > > Remove exposed driver version as it was done in other drivers, so module > > version will work correctly by displaying the

On Fri, Sep 18, 2020 at 11:22:45AM +0300, Leon Romanovsky wrote: > On Thu, Sep 17, 2020 at 07:35:03PM -0700, Randy Dunlap wrote: > > From: Randy Dunlap <rdunlap at infradead.org> > > > > drivers/vdpa/mlx5/ uses vhost_iotlb*() interfaces, so add a dependency > > on VHOST to eliminate build errors. > > > > ld: drivers/vdpa/mlx5/core/mr.o: in function

Thanks: Vladik Romanovsky, Ming Xie. --- v2v/output_glance.ml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/v2v/output_glance.ml b/v2v/output_glance.ml index e38b172..179448b 100644 --- a/v2v/output_glance.ml +++ b/v2v/output_glance.ml @@ -92,6 +92,10 @@ object | Virtio_net -> "virtio" | E1000 -> "e1000" | RTL8139 ->

On Fri, 27 Jan 2023 07:26:13 +0200 Leon Romanovsky wrote: > > That'd be my preference too, FWIW. It's only the offload cases which > > need this sort of fallback. > > Of course not, almost any error unwind path which sets extack will need it. I guess we can come up with scenarios where the new behavior would be useful. But the fact is - your patch changes 4 places...

From: Randy Dunlap <rdunlap at infradead.org> drivers/vdpa/mlx5/ uses vhost_iotlb*() interfaces, so add a dependency on VHOST to eliminate build errors. ld: drivers/vdpa/mlx5/core/mr.o: in function `add_direct_chain': mr.c:(.text+0x106): undefined reference to `vhost_iotlb_itree_first' ld: mr.c:(.text+0x1cf): undefined reference to `vhost_iotlb_itree_next' ld:

On 9/24/20 3:24 AM, Eli Cohen wrote: > On Thu, Sep 24, 2020 at 05:30:55AM -0400, Michael S. Tsirkin wrote: >>>> --- linux-next-20200917.orig/drivers/vdpa/Kconfig >>>> +++ linux-next-20200917/drivers/vdpa/Kconfig >>>> @@ -31,7 +31,7 @@ config IFCVF >>>> >>>> config MLX5_VDPA >>>> bool "MLX5 VDPA support library for

On 9/24/20 3:24 AM, Eli Cohen wrote: > On Thu, Sep 24, 2020 at 05:30:55AM -0400, Michael S. Tsirkin wrote: >>>> --- linux-next-20200917.orig/drivers/vdpa/Kconfig >>>> +++ linux-next-20200917/drivers/vdpa/Kconfig >>>> @@ -31,7 +31,7 @@ config IFCVF >>>> >>>> config MLX5_VDPA >>>> bool "MLX5 VDPA support library for

From: Randy Dunlap <rdunlap at infradead.org> drivers/vdpa/mlx5/ uses vhost_iotlb*() interfaces, so select VHOST to eliminate build errors. ld: drivers/vdpa/mlx5/core/mr.o: in function `add_direct_chain': mr.c:(.text+0x106): undefined reference to `vhost_iotlb_itree_first' ld: mr.c:(.text+0x1cf): undefined reference to `vhost_iotlb_itree_next' ld: mr.c:(.text+0x30d): undefined

From: Randy Dunlap <rdunlap at infradead.org> drivers/vdpa/mlx5/ uses vhost_iotlb*() interfaces, so add a dependency on VHOST to eliminate build errors. ld: drivers/vdpa/mlx5/core/mr.o: in function `add_direct_chain': mr.c:(.text+0x106): undefined reference to `vhost_iotlb_itree_first' ld: mr.c:(.text+0x1cf): undefined reference to `vhost_iotlb_itree_next' ld:

On Fri, Sep 25, 2020 at 10:20:05AM +0300, Leon Romanovsky wrote: > On Thu, Sep 24, 2020 at 12:02:43PM -0400, Michael S. Tsirkin wrote: > > On Thu, Sep 24, 2020 at 08:47:05AM -0700, Randy Dunlap wrote: > > > On 9/24/20 3:24 AM, Eli Cohen wrote: > > > > On Thu, Sep 24, 2020 at 05:30:55AM -0400, Michael S. Tsirkin wrote: > > > >>>> ---

Hi everyone, Unfortunately, I'm facing an issue with libvirt 5.1.0 when probing capabilities. Failed to probe capabilities for /usr/bin/qemu-system-x86_64: internal error: Failed to start QEMU binary /usr/bin/qemu-system-x86_64 for probing: qemu-system-x86_64: cannot create PID file: Cannot open pid file: Permission denied I see that the qmp directory is being created, however, it belongs

On Fri, Apr 19, 2019 at 01:16:06PM +0200, Hannes Reinecke wrote: > On 4/15/19 12:35 PM, Yuval Shaia wrote: > > On Thu, Apr 11, 2019 at 07:02:15PM +0200, Cornelia Huck wrote: > > > On Thu, 11 Apr 2019 14:01:54 +0300 > > > Yuval Shaia <yuval.shaia at oracle.com> wrote: > > > > > > > Data center backends use more and more RDMA or RoCE devices and

flight 17325 linux-linus real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/17325/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 9 guest-start fail REGR. vs. 12557 test-amd64-i386-xl-credit2 15 guest-stop fail REGR. vs. 12557 test-amd64-i386-xl 15 guest-stop