similar to: [PATCH 1/2] vhost: remove mutex ops in vhost_set_backend_features

On Tue, Sep 08, 2020 at 09:00:19PM +0800, Zhu, Lingshan wrote: > > On 9/8/2020 8:05 PM, Michael S. Tsirkin wrote: > > On Mon, Sep 07, 2020 at 06:52:19PM +0800, Zhu Lingshan wrote: > > In vhost_vdpa ioctl SET_BACKEND_FEATURES path, currect code > would try to acquire vhost dev mutex twice > (first shown in vhost_vdpa_unlocked_ioctl), which can

----- Original Message ----- > This commit introduced vhost_vdpa_set/get_backend_features() to > resolve these issues: > (1)In vhost_vdpa ioctl SET_BACKEND_FEATURES path, currect code > would try to acquire vhost dev mutex twice > (first shown in vhost_vdpa_unlocked_ioctl), which can lead > to a dead lock issue. > (2)SET_BACKEND_FEATURES was blindly added to vring ioctl

On Fri, Aug 03, 2018 at 03:04:51PM +0800, Jason Wang wrote: > We use to have message like: > > struct vhost_msg { > int type; > union { > struct vhost_iotlb_msg iotlb; > __u8 padding[64]; > }; > }; > > Unfortunately, there will be a hole of 32bit in 64bit machine because > of the alignment. This leads a different formats between 32bit API and > 64bit

We use to have message like: struct vhost_msg { int type; union { struct vhost_iotlb_msg iotlb; __u8 padding[64]; }; }; Unfortunately, there will be a hole of 32bit in 64bit machine because of the alignment. This leads a different formats between 32bit API and 64bit API. What's more it will break 32bit program running on 64bit machine. So fixing this by introducing a new message type

We use to have message like: struct vhost_msg { int type; union { struct vhost_iotlb_msg iotlb; __u8 padding[64]; }; }; Unfortunately, there will be a hole of 32bit in 64bit machine because of the alignment. This leads a different formats between 32bit API and 64bit API. What's more it will break 32bit program running on 64bit machine. So fixing this by introducing a new message type

We use to have message like: struct vhost_msg { int type; union { struct vhost_iotlb_msg iotlb; __u8 padding[64]; }; }; Unfortunately, there will be a hole of 32bit in 64bit machine because of the alignment. This leads a different formats between 32bit API and 64bit API. What's more it will break 32bit program running on 64bit machine. So fixing this by introducing a new message type

Hi all: This series tries to support batched IOTLB updating vhost-vdpa. Currently vhost-vdpa accepts userspace mapping via IOTLB API, and it can only forward one mapping to IOMMU or device through IOMMU API or dma_map(). Though set_map() is designed to have the capability to pass an rbtree based mapping to vDPA device, it's still be called at least once for each VHOST_IOTLB_UPDATE or

Hi all: This series tries to support batched IOTLB updating vhost-vdpa. Currently vhost-vdpa accepts userspace mapping via IOTLB API, and it can only forward one mapping to IOMMU or device through IOMMU API or dma_map(). Though set_map() is deisgend to have the capability to pass an rbtree based mapping to vDPA device, it's still be called at least once for each VHOST_IOTLB_UPDATE or

Commit 653055b9acd4 ("vhost-vdpa: support get/set backend features") introduces two malfunction backend features ioctls: 1) the ioctls was blindly added to vring ioctl instead of vdpa device ioctl 2) vhost_set_backend_features() was called when dev mutex has already been held which will lead a deadlock This patch fixes the above issues. Cc: Eli Cohen <elic at nvidia.com>

Commit 653055b9acd4 ("vhost-vdpa: support get/set backend features") introduces two malfunction backend features ioctls: 1) the ioctls was blindly added to vring ioctl instead of vdpa device ioctl 2) vhost_set_backend_features() was called when dev mutex has already been held which will lead a deadlock This patch fixes the above issues. Cc: Eli Cohen <elic at nvidia.com>

On Thu, Sep 24, 2020 at 11:21:02AM +0800, Jason Wang wrote: > Commit 653055b9acd4 ("vhost-vdpa: support get/set backend features") > introduces two malfunction backend features ioctls: > > 1) the ioctls was blindly added to vring ioctl instead of vdpa device > ioctl > 2) vhost_set_backend_features() was called when dev mutex has already > been held which will

On 2019/8/2 ??10:03, Michael S. Tsirkin wrote: > On Fri, Aug 02, 2019 at 05:40:07PM +0800, Jason Wang wrote: >> Btw, I come up another idea, that is to disable preemption when vhost thread >> need to access the memory. Then register preempt notifier and if vhost >> thread is preempted, we're sure no one will access the memory and can do the >> cleanup. > Great,

On Mon, Aug 05, 2019 at 12:33:45PM +0800, Jason Wang wrote: > > On 2019/8/2 ??10:03, Michael S. Tsirkin wrote: > > On Fri, Aug 02, 2019 at 05:40:07PM +0800, Jason Wang wrote: > > > Btw, I come up another idea, that is to disable preemption when vhost thread > > > need to access the memory. Then register preempt notifier and if vhost > > > thread is

On 2020/9/9 ??2:52, Zhu Lingshan wrote: > This commit removed unnecessary spin_locks in vhost_vring_call > and related operations. Because we manipulate irq offloading > contents in vhost_vdpa ioctl code path which is already > protected by dev mutex and vq mutex. > > Signed-off-by: Zhu Lingshan <lingshan.zhu at intel.com> Acked-by: Jason Wang <jasowang at

On Mon, Sep 28, 2020 at 02:35:04PM +0200, Greg Kurz wrote: > When the IOTLB device is enabled, the vring addresses we get from > userspace are GIOVAs. It is thus wrong to pass them to vq_access_ok() > which only takes HVAs. The IOTLB map is likely empty at this stage, > so there isn't much that can be done with these GIOVAs. Access validation > will be performed at IOTLB

On Mon, Sep 28, 2020 at 02:35:04PM +0200, Greg Kurz wrote: > When the IOTLB device is enabled, the vring addresses we get from > userspace are GIOVAs. It is thus wrong to pass them to vq_access_ok() > which only takes HVAs. The IOTLB map is likely empty at this stage, > so there isn't much that can be done with these GIOVAs. Access validation > will be performed at IOTLB

The _IOC_READ flag fits this ioctl request more because this request actually only writes to, but doesn't read from userspace. See NOTEs in include/uapi/asm-generic/ioctl.h for more information. Fixes: 429711aec282 ("vhost: switch to use new message format") Signed-off-by: Gleb Fotengauer-Malinovskiy <glebfm at altlinux.org> --- include/uapi/linux/vhost.h | 2 +- 1 file

The _IOC_READ flag fits this ioctl request more because this request actually only writes to, but doesn't read from userspace. See NOTEs in include/uapi/asm-generic/ioctl.h for more information. Fixes: 429711aec282 ("vhost: switch to use new message format") Signed-off-by: Gleb Fotengauer-Malinovskiy <glebfm at altlinux.org> --- include/uapi/linux/vhost.h | 2 +- 1 file

On 2018?09?04? 10:22, Michael S. Tsirkin wrote: > On Mon, Sep 03, 2018 at 08:59:13PM +0300, Gleb Fotengauer-Malinovskiy wrote: >> The _IOC_READ flag fits this ioctl request more because this request >> actually only writes to, but doesn't read from userspace. >> See NOTEs in include/uapi/asm-generic/ioctl.h for more information. >> >> Fixes: 429711aec282

On 2018?09?04? 10:22, Michael S. Tsirkin wrote: > On Mon, Sep 03, 2018 at 08:59:13PM +0300, Gleb Fotengauer-Malinovskiy wrote: >> The _IOC_READ flag fits this ioctl request more because this request >> actually only writes to, but doesn't read from userspace. >> See NOTEs in include/uapi/asm-generic/ioctl.h for more information. >> >> Fixes: 429711aec282