similar to: [PATCH vhost next 05/10] vhost: Fix documentation

On 2020/7/20 ??3:14, Eli Cohen wrote: > Fix documentation to match actual function prototypes. > > Reviewed-by: Parav Pandit <parav at mellanox.com> > Signed-off-by: Eli Cohen <eli at mellanox.com> Acked-by: Jason Wang <jasowang at redhat.com> > --- > drivers/vhost/iotlb.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git

This patch factors out IOTLB into a dedicated module in order to be reused by other modules like vringh. User may choose to enable the automatic retiring by specifying VHOST_IOTLB_FLAG_RETIRE flag to fit for the case of vhost device IOTLB implementation. Signed-off-by: Jason Wang <jasowang at redhat.com> --- MAINTAINERS | 1 + drivers/vhost/Kconfig | 7 ++

This patch contains trivial changes for the vhost_iotlb_itree_next() documentation, fixing the function name and the description of first argument (@map). Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- drivers/vhost/iotlb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/vhost/iotlb.c b/drivers/vhost/iotlb.c index 1f0ca6e44410..34aec4ba331e

This patch implements a software vDPA networking device. The datapath is implemented through vringh and workqueue. The device has an on-chip IOMMU which translates IOVA to PA. For kernel virtio drivers, vDPA simulator driver provides dma_ops. For vhost driers, set_map() methods of vdpa_config_ops is implemented to accept mappings from vhost. Currently, vDPA device simulator will loopback TX

This patch implements a software vDPA networking device. The datapath is implemented through vringh and workqueue. The device has an on-chip IOMMU which translates IOVA to PA. For kernel virtio drivers, vDPA simulator driver provides dma_ops. For vhost driers, set_map() methods of vdpa_config_ops is implemented to accept mappings from vhost. Currently, vDPA device simulator will loopback TX

On Mon, Feb 10, 2020 at 11:56:08AM +0800, Jason Wang wrote: > This patch implements a software vDPA networking device. The datapath > is implemented through vringh and workqueue. The device has an on-chip > IOMMU which translates IOVA to PA. For kernel virtio drivers, vDPA > simulator driver provides dma_ops. For vhost driers, set_map() methods > of vdpa_config_ops is implemented to

Hi Eli, Thank you for the patch! Yet something to improve: [auto build test ERROR on next-20200715] url: https://github.com/0day-ci/linux/commits/Eli-Cohen/VDPA-support-for-Mellanox-ConnectX-devices/20200716-155039 base: ca0e494af5edb59002665bf12871e94b4163a257 config: ia64-allmodconfig (attached as .config) compiler: ia64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build):

? 2023/2/7 20:08, Nanyong Sun ??: > From: Rong Wang <wangrong68 at huawei.com> > > Once enable iommu domain for one device, the MSI > translation tables have to be there for software-managed MSI. > Otherwise, platform with software-managed MSI without an > irq bypass function, can not get a correct memory write event > from pcie, will not get irqs. > The solution is

From: Max Gurtovoy <maxg at mellanox.com> Iommu iotlb can be accessed by different cores for performing IO using multiple virt queues. Add a spinlock to synchronize iotlb accesses. This could be easily reproduced when using more than 1 pktgen threads to inject traffic to vdpa simulator. Fixes: 2c53d0f64c06f("vdpasim: vDPA device simulator") Cc: stable at vger.kernel.org

Pinned pages are not properly accounted particularly when mapping error occurs on IOTLB update. Clean up dangling pinned pages for the error path. As the inflight pinned pages, specifically for memory region that strides across multiple chunks, would need more than one free page for book keeping and accounting. For simplicity, pin pages for all memory in the IOVA range in one go rather than have

Pinned pages are not properly accounted particularly when mapping error occurs on IOTLB update. Clean up dangling pinned pages for the error path. As the inflight pinned pages, specifically for memory region that strides across multiple chunks, would need more than one free page for book keeping and accounting. For simplicity, pin pages for all memory in the IOVA range in one go rather than have

On 2020/10/30 ??3:45, Si-Wei Liu wrote: > This reverts commit 7ed9e3d97c32d969caded2dfb6e67c1a2cc5a0b1. > > Signed-off-by: Si-Wei Liu <si-wei.liu at oracle.com> > --- > drivers/vhost/vdpa.c | 119 +++++++++++++++++++++------------------------------ > 1 file changed, 48 insertions(+), 71 deletions(-) I saw this has been reverted there

Hi all: This is an update version of vDPA support in kernel. vDPA device is a device that uses a datapath which complies with the virtio specifications with vendor specific control path. vDPA devices can be both physically located on the hardware or emulated by software. vDPA hardware devices are usually implemented through PCIE with the following types: - PF (Physical Function) - A single

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:

Hi all: This is an updated version of kernel support for vDPA device. Various changes were made based on the feedback since last verion. One major change is to drop the sysfs API and leave the management interface for future development, and introudce the incremental DMA bus operations. Please see changelog for more information. The work on vhost, IFCVF (intel VF driver for vDPA) and qemu is

Hi all: This is an update version of vDPA support in kernel. vDPA device is a device that uses a datapath which complies with the virtio specifications with vendor specific control path. vDPA devices can be both physically located on the hardware or emulated by software. vDPA hardware devices are usually implemented through PCIE with the following types: - PF (Physical Function) - A single

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 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

On Thu, Dec 31, 2015 at 03:13:45PM +0800, Jason Wang wrote: > This patch tries to implement an device IOTLB for vhost. This could be > used with for co-operation with userspace(qemu) implementation of > iommu for a secure DMA environment in guest. > > The idea is simple. When vhost meets an IOTLB miss, it will request > the assistance of userspace to do the translation, this is