Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp1227953rwl; Fri, 24 Mar 2023 07:53:21 -0700 (PDT) X-Google-Smtp-Source: AKy350ZYFwSD0xlfeRXX3W8mnrEO1y0xVVOXf4yE9tjF48izcIgaKXRImEYiZycwTHXTUXEy1QxT X-Received: by 2002:a17:906:1453:b0:92f:df03:551 with SMTP id q19-20020a170906145300b0092fdf030551mr2891778ejc.15.1679669600873; Fri, 24 Mar 2023 07:53:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679669600; cv=none; d=google.com; s=arc-20160816; b=jcWjoeeyKMrSh6bkHp3nz9Ivx3qCQZbbps4/qTj/dNjCLlpptVNLEOI0obwQqbLhst rWZ8goSQ+9uUQM5mUdSkXwiIC29XfK4jP8fh8sXMziq9+sEusgaoL7v2qCzKo8aw9mxj tW2vZVrT8A7A3CTcx/SCx0OGcr5YrMHzYdlvGIdRH2JzZzkkaoKJN9gcqPlWQnFLEaJe NAF+EDgi7WmbleppEFVeSsd4V8PM0uI3k98u3E5gRUdPB7u3slWPB4DF0bv0jYoHwEZy S03MzEs+95qmbg5uBm052woJuDmr2istqf5UPVY6GvP9DEwuE22bmKfK7DcnHbXu2n3G YkCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=AuOjQOzMJu7jhalrvIVzIXLam0VRoOPHkDU+QEY7YhI=; b=bqtTKbzzfwtnv0eum7Ev+xhwU7bSRaX9B1vHOBkDcjctncXgUBT5dVncp4Ae32b4TG xhJI9DAB1B2Sp/WBtX+gqWAP0P3/4qrO+Dc+ZNh5GO/SvosIOY8DVa0g2CXQgO/3iXFF KcsQuBJdn8MjMSyylSslbdEsM8BvEZ8P2DiWloxihIu0ry3GPBTvknyaj/KsPQXzk5AU g5U36UxbGTmc/os+fpCnlBrH4/vExrXtUfXeUWC4IRgRZLeHaxfGQ17X0v4NHQ/ZtMvu 0rREgHuLBNrIAIe7BuYohu1bHsObIX7TAiyMPmwmSmtIfDmYglRgb4YrAaBh7i9jodPB PCjg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=gkmf1zbq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id cw20-20020a170906479400b009329a33cbf2si23465363ejc.70.2023.03.24.07.52.56; Fri, 24 Mar 2023 07:53:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=gkmf1zbq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232206AbjCXOr6 (ORCPT + 99 others); Fri, 24 Mar 2023 10:47:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36918 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232218AbjCXOrw (ORCPT ); Fri, 24 Mar 2023 10:47:52 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CA6F718A8F for ; Fri, 24 Mar 2023 07:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1679669223; 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=AuOjQOzMJu7jhalrvIVzIXLam0VRoOPHkDU+QEY7YhI=; b=gkmf1zbq6bQV7ABVdmpbP65Iu3Fdif3EFYsApnmGRHdgUMqnQ4HIAXbzyQLRiAqo75bKGd WsX0Mc/WMn2AwEhmQl2Vfsb9RAD0RF5qQqEdLba7UZiKj2yHdQe1BedYwN2v2+Du3ErewG X7onXIQTbSUfq+D5tI1XhkZqRBBenoc= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-634-lHjobPb1PaW3FGRhx-6Kzw-1; Fri, 24 Mar 2023 10:47:01 -0400 X-MC-Unique: lHjobPb1PaW3FGRhx-6Kzw-1 Received: by mail-ed1-f71.google.com with SMTP id b1-20020aa7dc01000000b004ad062fee5eso3471881edu.17 for ; Fri, 24 Mar 2023 07:47:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679669220; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=AuOjQOzMJu7jhalrvIVzIXLam0VRoOPHkDU+QEY7YhI=; b=cRVrhi9tgHDfWQB9Y37uob92k5pbaH9yGGsB5aEJvtFr36yoJv5mUwxjI7nSnJMNw6 tobhoKIldVfWzlaaBrjNKEeHeZZQ5u3VlNvMPyvnlhExMUTwlBu36jmQnvrlIgtxKVww rsAM2rzC3oCz2HFm1q/lG3CVN0pNG08vTPngb9IDpurHhx1yKaFhM96TWUhca4hVduOR ByqzsBkm5kEpz7FaJgbpqu7I6NuziGnB5RXLF4zLRI8Isb4ng1MenMJxOBXwkuUhgI6Y 4JQO/q0U5p7jEu/4BX3078IuKC5pxEpl/Av6kIBHCw5X+psUPNlwlfcSixDVWu3tSAnS z5jA== X-Gm-Message-State: AAQBX9eCcN+dU7TV8ac4ILOmVMyHGSwxRVmzQXcGq0599KEvz0PVVAPX lk+MaSt5DKcjHJS/YdJbZrCr/DUI693G98xNOoWxM7PbZTO/WdWrePRmP9wmvCIoECBVDP/rT0V dCVYL4U5+O1LOxG8wl5jPKhr+ X-Received: by 2002:a17:906:fa1b:b0:922:2ba3:2348 with SMTP id lo27-20020a170906fa1b00b009222ba32348mr2995764ejb.7.1679669220707; Fri, 24 Mar 2023 07:47:00 -0700 (PDT) X-Received: by 2002:a17:906:fa1b:b0:922:2ba3:2348 with SMTP id lo27-20020a170906fa1b00b009222ba32348mr2995743ejb.7.1679669220454; Fri, 24 Mar 2023 07:47:00 -0700 (PDT) Received: from sgarzare-redhat (host-82-53-134-98.retail.telecomitalia.it. [82.53.134.98]) by smtp.gmail.com with ESMTPSA id c14-20020a509f8e000000b005003fd12eafsm10711203edf.63.2023.03.24.07.46.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Mar 2023 07:46:59 -0700 (PDT) Date: Fri, 24 Mar 2023 15:46:57 +0100 From: Stefano Garzarella To: Jason Wang Cc: virtualization@lists.linux-foundation.org, kvm@vger.kernel.org, stefanha@redhat.com, linux-kernel@vger.kernel.org, eperezma@redhat.com, "Michael S. Tsirkin" , Andrey Zhadchenko , netdev@vger.kernel.org Subject: Re: [PATCH v3 8/8] vdpa_sim: add support for user VA Message-ID: References: <20230321154228.182769-1-sgarzare@redhat.com> <20230321154804.184577-1-sgarzare@redhat.com> <20230321154804.184577-4-sgarzare@redhat.com> <78c7511a-deab-7e95-fde1-5317a568cf97@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <78c7511a-deab-7e95-fde1-5317a568cf97@redhat.com> X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 24, 2023 at 11:49:32AM +0800, Jason Wang wrote: > >在 2023/3/21 23:48, Stefano Garzarella 写道: >>The new "use_va" module parameter (default: true) is used in >>vdpa_alloc_device() to inform the vDPA framework that the device >>supports VA. >> >>vringh is initialized to use VA only when "use_va" is true and the >>user's mm has been bound. So, only when the bus supports user VA >>(e.g. vhost-vdpa). >> >>vdpasim_mm_work_fn work is used to serialize the binding to a new >>address space when the .bind_mm callback is invoked, and unbinding >>when the .unbind_mm callback is invoked. >> >>Call mmget_not_zero()/kthread_use_mm() inside the worker function >>to pin the address space only as long as needed, following the >>documentation of mmget() in include/linux/sched/mm.h: >> >> * Never use this function to pin this address space for an >> * unbounded/indefinite amount of time. >> >>Signed-off-by: Stefano Garzarella >>--- >> >>Notes: >> v3: >> - called mmget_not_zero() before kthread_use_mm() [Jason] >> As the documentation of mmget() in include/linux/sched/mm.h says: >> * Never use this function to pin this address space for an >> * unbounded/indefinite amount of time. >> I moved mmget_not_zero/kthread_use_mm inside the worker function, >> this way we pin the address space only as long as needed. >> This is similar to what vfio_iommu_type1_dma_rw_chunk() does in >> drivers/vfio/vfio_iommu_type1.c >> - simplified the mm bind/unbind [Jason] >> - renamed vdpasim_worker_change_mm_sync() [Jason] >> - fix commit message (s/default: false/default: true) >> v2: >> - `use_va` set to true by default [Eugenio] >> - supported the new unbind_mm callback [Jason] >> - removed the unbind_mm call in vdpasim_do_reset() [Jason] >> - avoided to release the lock while call kthread_flush_work() since we >> are now using a mutex to protect the device state >> >> drivers/vdpa/vdpa_sim/vdpa_sim.h | 1 + >> drivers/vdpa/vdpa_sim/vdpa_sim.c | 80 +++++++++++++++++++++++++++++++- >> 2 files changed, 79 insertions(+), 2 deletions(-) >> >>diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.h b/drivers/vdpa/vdpa_sim/vdpa_sim.h >>index 4774292fba8c..3a42887d05d9 100644 >>--- a/drivers/vdpa/vdpa_sim/vdpa_sim.h >>+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.h >>@@ -59,6 +59,7 @@ struct vdpasim { >> struct vdpasim_virtqueue *vqs; >> struct kthread_worker *worker; >> struct kthread_work work; >>+ struct mm_struct *mm_bound; >> struct vdpasim_dev_attr dev_attr; >> /* mutex to synchronize virtqueue state */ >> struct mutex mutex; >>diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c >>index ab4cfb82c237..23c891cdcd54 100644 >>--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c >>+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c >>@@ -35,10 +35,44 @@ module_param(max_iotlb_entries, int, 0444); >> MODULE_PARM_DESC(max_iotlb_entries, >> "Maximum number of iotlb entries for each address space. 0 means unlimited. (default: 2048)"); >>+static bool use_va = true; >>+module_param(use_va, bool, 0444); >>+MODULE_PARM_DESC(use_va, "Enable/disable the device's ability to use VA"); >>+ >> #define VDPASIM_QUEUE_ALIGN PAGE_SIZE >> #define VDPASIM_QUEUE_MAX 256 >> #define VDPASIM_VENDOR_ID 0 >>+struct vdpasim_mm_work { >>+ struct kthread_work work; >>+ struct vdpasim *vdpasim; >>+ struct mm_struct *mm_to_bind; >>+ int ret; >>+}; >>+ >>+static void vdpasim_mm_work_fn(struct kthread_work *work) >>+{ >>+ struct vdpasim_mm_work *mm_work = >>+ container_of(work, struct vdpasim_mm_work, work); >>+ struct vdpasim *vdpasim = mm_work->vdpasim; >>+ >>+ mm_work->ret = 0; >>+ >>+ //TODO: should we attach the cgroup of the mm owner? >>+ vdpasim->mm_bound = mm_work->mm_to_bind; >>+} >>+ >>+static void vdpasim_worker_change_mm_sync(struct vdpasim *vdpasim, >>+ struct vdpasim_mm_work *mm_work) >>+{ >>+ struct kthread_work *work = &mm_work->work; >>+ >>+ kthread_init_work(work, vdpasim_mm_work_fn); >>+ kthread_queue_work(vdpasim->worker, work); >>+ >>+ kthread_flush_work(work); >>+} >>+ >> static struct vdpasim *vdpa_to_sim(struct vdpa_device *vdpa) >> { >> return container_of(vdpa, struct vdpasim, vdpa); >>@@ -59,8 +93,10 @@ static void vdpasim_queue_ready(struct vdpasim *vdpasim, unsigned int idx) >> { >> struct vdpasim_virtqueue *vq = &vdpasim->vqs[idx]; >> uint16_t last_avail_idx = vq->vring.last_avail_idx; >>+ bool va_enabled = use_va && vdpasim->mm_bound; >>- vringh_init_iotlb(&vq->vring, vdpasim->features, vq->num, true, false, >>+ vringh_init_iotlb(&vq->vring, vdpasim->features, vq->num, true, >>+ va_enabled, >> (struct vring_desc *)(uintptr_t)vq->desc_addr, >> (struct vring_avail *) >> (uintptr_t)vq->driver_addr, >>@@ -130,8 +166,20 @@ static const struct vdpa_config_ops vdpasim_batch_config_ops; >> static void vdpasim_work_fn(struct kthread_work *work) >> { >> struct vdpasim *vdpasim = container_of(work, struct vdpasim, work); >>+ struct mm_struct *mm = vdpasim->mm_bound; >>+ >>+ if (mm) { >>+ if (!mmget_not_zero(mm)) >>+ return; > > >Do we need to check use_va here. Yep, right! > >Other than this > >Acked-by: Jason Wang Thanks for the reviews, Stefano