From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-17.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B0B09C433DB for ; Wed, 23 Dec 2020 09:05:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0697C22475 for ; Wed, 23 Dec 2020 09:05:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0697C22475 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 072F96B00C3; Wed, 23 Dec 2020 04:05:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F3EAF8D0015; Wed, 23 Dec 2020 04:05:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DB7D98D0001; Wed, 23 Dec 2020 04:05:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0251.hostedemail.com [216.40.44.251]) by kanga.kvack.org (Postfix) with ESMTP id C22376B00C3 for ; Wed, 23 Dec 2020 04:05:42 -0500 (EST) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 918A91EF2 for ; Wed, 23 Dec 2020 09:05:42 +0000 (UTC) X-FDA: 77623964124.19.bears70_08115b327467 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin19.hostedemail.com (Postfix) with ESMTP id 6FFC61ACC29 for ; Wed, 23 Dec 2020 09:05:42 +0000 (UTC) X-HE-Tag: bears70_08115b327467 X-Filterd-Recvd-Size: 11932 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Wed, 23 Dec 2020 09:05:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1608714341; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bzp4miSYa1YbX1pzPBEvAGZlsG6n9vA+NtKZUy2Yneg=; b=K6/WLmJ3b/Tg6ZVbtN6nWvJvfo1d2Kur9EMCWis6dBeWPYSay2nowEt7XI3SHdwGUZYtw6 q67NE1YBwzOJEAUcUiJqpXpz3VNMFtnSD9OK5zSNkqltECfcH2klyKvzkGwN3KRRbQF/wy wD+nUMJZN+zq1FOk9fSQu94h2uZv9+o= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-397-Vmgvr832MN-qZP6m-ec38Q-1; Wed, 23 Dec 2020 04:05:37 -0500 X-MC-Unique: Vmgvr832MN-qZP6m-ec38Q-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9F6BD107AD2F; Wed, 23 Dec 2020 09:05:34 +0000 (UTC) Received: from [10.72.12.54] (ovpn-12-54.pek2.redhat.com [10.72.12.54]) by smtp.corp.redhat.com (Postfix) with ESMTP id B0CB619D9C; Wed, 23 Dec 2020 09:05:22 +0000 (UTC) Subject: Re: [RFC v2 09/13] vduse: Add support for processing vhost iotlb message To: Xie Yongji , mst@redhat.com, stefanha@redhat.com, sgarzare@redhat.com, parav@nvidia.com, akpm@linux-foundation.org, rdunlap@infradead.org, willy@infradead.org, viro@zeniv.linux.org.uk, axboe@kernel.dk, bcrl@kvack.org, corbet@lwn.net Cc: virtualization@lists.linux-foundation.org, netdev@vger.kernel.org, kvm@vger.kernel.org, linux-aio@kvack.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org References: <20201222145221.711-1-xieyongji@bytedance.com> <20201222145221.711-10-xieyongji@bytedance.com> From: Jason Wang Message-ID: <6818a214-d587-4f0b-7de6-13c4e7e94ab6@redhat.com> Date: Wed, 23 Dec 2020 17:05:21 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20201222145221.711-10-xieyongji@bytedance.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2020/12/22 =E4=B8=8B=E5=8D=8810:52, Xie Yongji wrote: > To support vhost-vdpa bus driver, we need a way to share the > vhost-vdpa backend process's memory with the userspace VDUSE process. > > This patch tries to make use of the vhost iotlb message to achieve > that. We will get the shm file from the iotlb message and pass it > to the userspace VDUSE process. > > Signed-off-by: Xie Yongji > --- > Documentation/driver-api/vduse.rst | 15 +++- > drivers/vdpa/vdpa_user/vduse_dev.c | 147 ++++++++++++++++++++++++++++= ++++++++- > include/uapi/linux/vduse.h | 11 +++ > 3 files changed, 171 insertions(+), 2 deletions(-) > > diff --git a/Documentation/driver-api/vduse.rst b/Documentation/driver-= api/vduse.rst > index 623f7b040ccf..48e4b1ba353f 100644 > --- a/Documentation/driver-api/vduse.rst > +++ b/Documentation/driver-api/vduse.rst > @@ -46,13 +46,26 @@ The following types of messages are provided by the= VDUSE framework now: > =20 > - VDUSE_GET_CONFIG: Read from device specific configuration space > =20 > +- VDUSE_UPDATE_IOTLB: Update the memory mapping in device IOTLB > + > +- VDUSE_INVALIDATE_IOTLB: Invalidate the memory mapping in device IOTL= B > + > Please see include/linux/vdpa.h for details. > =20 > -In the data path, VDUSE framework implements a MMU-based on-chip IOMMU > +The data path of userspace vDPA device is implemented in different way= s > +depending on the vdpa bus to which it is attached. > + > +In virtio-vdpa case, VDUSE framework implements a MMU-based on-chip IO= MMU > driver which supports mapping the kernel dma buffer to a userspace io= va > region dynamically. The userspace iova region can be created by passi= ng > the userspace vDPA device fd to mmap(2). > =20 > +In vhost-vdpa case, the dma buffer is reside in a userspace memory reg= ion > +which will be shared to the VDUSE userspace processs via the file > +descriptor in VDUSE_UPDATE_IOTLB message. And the corresponding addres= s > +mapping (IOVA of dma buffer <-> VA of the memory region) is also inclu= ded > +in this message. > + > Besides, the eventfd mechanism is used to trigger interrupt callbacks= and > receive virtqueue kicks in userspace. The following ioctls on the use= rspace > vDPA device fd are provided to support that: > diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_use= r/vduse_dev.c > index b974333ed4e9..d24aaacb6008 100644 > --- a/drivers/vdpa/vdpa_user/vduse_dev.c > +++ b/drivers/vdpa/vdpa_user/vduse_dev.c > @@ -34,6 +34,7 @@ > =20 > struct vduse_dev_msg { > struct vduse_dev_request req; > + struct file *iotlb_file; > struct vduse_dev_response resp; > struct list_head list; > wait_queue_head_t waitq; > @@ -325,12 +326,80 @@ static int vduse_dev_set_vq_state(struct vduse_de= v *dev, > return ret; > } > =20 > +static int vduse_dev_update_iotlb(struct vduse_dev *dev, struct file *= file, > + u64 offset, u64 iova, u64 size, u8 perm) > +{ > + struct vduse_dev_msg *msg; > + int ret; > + > + if (!size) > + return -EINVAL; > + > + msg =3D vduse_dev_new_msg(dev, VDUSE_UPDATE_IOTLB); > + msg->req.size =3D sizeof(struct vduse_iotlb); > + msg->req.iotlb.offset =3D offset; > + msg->req.iotlb.iova =3D iova; > + msg->req.iotlb.size =3D size; > + msg->req.iotlb.perm =3D perm; > + msg->req.iotlb.fd =3D -1; > + msg->iotlb_file =3D get_file(file); > + > + ret =3D vduse_dev_msg_sync(dev, msg); My feeling is that we should provide consistent API for the userspace=20 device to use. E.g we'd better carry the IOTLB message for both virtio/vhost drivers. It looks to me for virtio drivers we can still use UPDAT_IOTLB message=20 by using VDUSE file as msg->iotlb_file here. > + vduse_dev_msg_put(msg); > + fput(file); > + > + return ret; > +} > + > +static int vduse_dev_invalidate_iotlb(struct vduse_dev *dev, > + u64 iova, u64 size) > +{ > + struct vduse_dev_msg *msg; > + int ret; > + > + if (!size) > + return -EINVAL; > + > + msg =3D vduse_dev_new_msg(dev, VDUSE_INVALIDATE_IOTLB); > + msg->req.size =3D sizeof(struct vduse_iotlb); > + msg->req.iotlb.iova =3D iova; > + msg->req.iotlb.size =3D size; > + > + ret =3D vduse_dev_msg_sync(dev, msg); > + vduse_dev_msg_put(msg); > + > + return ret; > +} > + > +static unsigned int perm_to_file_flags(u8 perm) > +{ > + unsigned int flags =3D 0; > + > + switch (perm) { > + case VHOST_ACCESS_WO: > + flags |=3D O_WRONLY; > + break; > + case VHOST_ACCESS_RO: > + flags |=3D O_RDONLY; > + break; > + case VHOST_ACCESS_RW: > + flags |=3D O_RDWR; > + break; > + default: > + WARN(1, "invalidate vhost IOTLB permission\n"); > + break; > + } > + > + return flags; > +} > + > static ssize_t vduse_dev_read_iter(struct kiocb *iocb, struct iov_ite= r *to) > { > struct file *file =3D iocb->ki_filp; > struct vduse_dev *dev =3D file->private_data; > struct vduse_dev_msg *msg; > - int size =3D sizeof(struct vduse_dev_request); > + unsigned int flags; > + int fd, size =3D sizeof(struct vduse_dev_request); > ssize_t ret =3D 0; > =20 > if (iov_iter_count(to) < size) > @@ -349,6 +418,18 @@ static ssize_t vduse_dev_read_iter(struct kiocb *i= ocb, struct iov_iter *to) > if (ret) > return ret; > } > + > + if (msg->req.type =3D=3D VDUSE_UPDATE_IOTLB && msg->req.iotlb.fd =3D=3D= -1) { > + flags =3D perm_to_file_flags(msg->req.iotlb.perm); > + fd =3D get_unused_fd_flags(flags); > + if (fd < 0) { > + vduse_dev_enqueue_msg(dev, msg, &dev->send_list); > + return fd; > + } > + fd_install(fd, get_file(msg->iotlb_file)); > + msg->req.iotlb.fd =3D fd; > + } > + > ret =3D copy_to_iter(&msg->req, size, to); > if (ret !=3D size) { > vduse_dev_enqueue_msg(dev, msg, &dev->send_list); > @@ -565,6 +646,69 @@ static void vduse_vdpa_set_config(struct vdpa_devi= ce *vdpa, unsigned int offset, > vduse_dev_set_config(dev, offset, buf, len); > } > =20 > +static void vduse_vdpa_invalidate_iotlb(struct vduse_dev *dev, > + struct vhost_iotlb_msg *msg) > +{ > + vduse_dev_invalidate_iotlb(dev, msg->iova, msg->size); > +} > + > +static int vduse_vdpa_update_iotlb(struct vduse_dev *dev, > + struct vhost_iotlb_msg *msg) > +{ > + u64 uaddr =3D msg->uaddr; > + u64 iova =3D msg->iova; > + u64 size =3D msg->size; > + u64 offset; > + struct vm_area_struct *vma; > + int ret; > + > + while (uaddr < msg->uaddr + msg->size) { > + vma =3D find_vma(current->mm, uaddr); > + ret =3D -EINVAL; > + if (!vma) > + goto err; > + > + size =3D min(msg->size, vma->vm_end - uaddr); > + offset =3D (vma->vm_pgoff << PAGE_SHIFT) + uaddr - vma->vm_start; > + if (vma->vm_file && (vma->vm_flags & VM_SHARED)) { > + ret =3D vduse_dev_update_iotlb(dev, vma->vm_file, offset, > + iova, size, msg->perm); > + if (ret) > + goto err; My understanding is that vma is something that should not be known by a=20 device. So I suggest to move the above processing to vhost-vdpa.c. Thanks > + } > + iova +=3D size; > + uaddr +=3D size; > + } > + return 0; > +err: > + vduse_dev_invalidate_iotlb(dev, msg->iova, iova - msg->iova); > + return ret; > +} > + > +static int vduse_vdpa_process_iotlb_msg(struct vdpa_device *vdpa, > + struct vhost_iotlb_msg *msg) > +{ > + struct vduse_dev *dev =3D vdpa_to_vduse(vdpa); > + int ret =3D 0; > + > + switch (msg->type) { > + case VHOST_IOTLB_UPDATE: > + ret =3D vduse_vdpa_update_iotlb(dev, msg); > + break; > + case VHOST_IOTLB_INVALIDATE: > + vduse_vdpa_invalidate_iotlb(dev, msg); > + break; > + case VHOST_IOTLB_BATCH_BEGIN: > + case VHOST_IOTLB_BATCH_END: > + break; > + default: > + ret =3D -EINVAL; > + break; > + } > + > + return ret; > +} > + > static void vduse_vdpa_free(struct vdpa_device *vdpa) > { > struct vduse_dev *dev =3D vdpa_to_vduse(vdpa); > @@ -597,6 +741,7 @@ static const struct vdpa_config_ops vduse_vdpa_conf= ig_ops =3D { > .set_status =3D vduse_vdpa_set_status, > .get_config =3D vduse_vdpa_get_config, > .set_config =3D vduse_vdpa_set_config, > + .process_iotlb_msg =3D vduse_vdpa_process_iotlb_msg, > .free =3D vduse_vdpa_free, > }; > =20 > diff --git a/include/uapi/linux/vduse.h b/include/uapi/linux/vduse.h > index 873305dfd93f..c5080851f140 100644 > --- a/include/uapi/linux/vduse.h > +++ b/include/uapi/linux/vduse.h > @@ -21,6 +21,8 @@ enum vduse_req_type { > VDUSE_GET_STATUS, > VDUSE_SET_CONFIG, > VDUSE_GET_CONFIG, > + VDUSE_UPDATE_IOTLB, > + VDUSE_INVALIDATE_IOTLB, > }; > =20 > struct vduse_vq_num { > @@ -51,6 +53,14 @@ struct vduse_dev_config_data { > __u8 data[VDUSE_CONFIG_DATA_LEN]; > }; > =20 > +struct vduse_iotlb { > + __u32 fd; > + __u64 offset; > + __u64 iova; > + __u64 size; > + __u8 perm; > +}; > + > struct vduse_dev_request { > __u32 type; /* request type */ > __u32 unique; /* request id */ > @@ -62,6 +72,7 @@ struct vduse_dev_request { > struct vduse_vq_ready vq_ready; /* virtqueue ready status */ > struct vduse_vq_state vq_state; /* virtqueue state */ > struct vduse_dev_config_data config; /* virtio device config space = */ > + struct vduse_iotlb iotlb; /* iotlb message */ > __u64 features; /* virtio features */ > __u8 status; /* device status */ > };