Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp481991rwl; Thu, 23 Mar 2023 19:56:13 -0700 (PDT) X-Google-Smtp-Source: AK7set9mUiN6+lrIZ4ELd/eUjyZOMwBQ/hL3Ub0bIG0D41vCV/lsHDoxxzwoiAmYJHMZKfzNS9AH X-Received: by 2002:a05:6a20:4f9e:b0:d4:32bb:11bd with SMTP id gh30-20020a056a204f9e00b000d432bb11bdmr1077285pzb.45.1679626572830; Thu, 23 Mar 2023 19:56:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679626572; cv=none; d=google.com; s=arc-20160816; b=NrwVjBA7lhMpeIsQJJSesY9KToo01+3j9PwnsU8wFwVumpCLsdB9f07yE5OKDioKEj TUOS5MCRACOn1IMoegcyRgkgbKkUduMioFDJ+7r+g9v0ZKCxQCizEevijbdh6vK2r/I1 HcPBJZIeEcNOoswygZ/u3ZJrtKUeE5ddfGheQVn0wFalXIgjViHBUBlO1GT7QNIdt4X3 8/00jcoCE1iefTT6g2u+slogQL2W4tBfIlsnBNj6b6u+VFkCxC92vK15sKdOeDZVLIJ0 1OmITAI8E3ckI3oTpMbVfhTmPbfQdgf/meeuGEmQxXK+mZb9F/suQZQNwQp2ChTW8h+0 gG0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=+uAUlOWmnaNVo/VWoXQNmQTS2u7vnkE353p3vcNlNhc=; b=NPa89K5eH/N1w4/wvCed0nb0tPJdzHQoYOrv7YPzPa69aTedrymc4yC2lDVVK3QzXJ 2AGh4v+TCptJ+7TRqSduB+8q/Ma2D5j3av31crmRTdI7kWFiWyO7+XlxdbgdRZZuWfPT nb8gXDZTetmOdKrXLE2WpHUCLPtzu58qzpnjMy9fAF2axSKR5IPnSPwAxwaq2OQv5prS 1VAQfPIQl9WcLHZgTjYA0359amPRO2IcXajj4KTm32ni/3GFiLAzDVmaWmyeSJcd7gRb EMbv30VCbQTqi5oHgTJVvluDT5T4vv8uH2wvKxmdICWH77BPF/AJ3gl5+zxGegG3IBjv GNmg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Yi1EsPyV; 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 x5-20020a654145000000b004fb359820cfsi18977674pgp.573.2023.03.23.19.56.00; Thu, 23 Mar 2023 19:56:12 -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=Yi1EsPyV; 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 S229997AbjCXCzn (ORCPT + 99 others); Thu, 23 Mar 2023 22:55:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33492 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229864AbjCXCzk (ORCPT ); Thu, 23 Mar 2023 22:55:40 -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 5EB3D9756 for ; Thu, 23 Mar 2023 19:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1679626493; 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=+uAUlOWmnaNVo/VWoXQNmQTS2u7vnkE353p3vcNlNhc=; b=Yi1EsPyVBvI0hkrRYM3GszLSgDJNbK2UFGDw2WxUtIObPLdEME6sbKDoEsk12gAEYCc8pA VCPitFti9zLqjMRdgdqdQyp5wqPPDNlMNE+aDnxJ+FF5lgOYiGeMW5aC/sA0rG0F3kuc33 2OAn1mD5TRVxycVcC33yekc39qelhoA= Received: from mail-ot1-f71.google.com (mail-ot1-f71.google.com [209.85.210.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-642-q3y_l-5IMW6Kgka7xhTZkQ-1; Thu, 23 Mar 2023 22:54:51 -0400 X-MC-Unique: q3y_l-5IMW6Kgka7xhTZkQ-1 Received: by mail-ot1-f71.google.com with SMTP id e2-20020a9d5602000000b00694299f6ea9so165920oti.19 for ; Thu, 23 Mar 2023 19:54:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679626491; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+uAUlOWmnaNVo/VWoXQNmQTS2u7vnkE353p3vcNlNhc=; b=BDbEbIyM09UO/+oH/OKi8IWGhBlIh1jXRYyjETRX5WZTwA+JQdIzfoREfvS28rfKEm 9TK8gEX37NXboZe6nJcKPTM6jv6d69VijkkNVB9gfSohCR3lzzshx3WRJnFigU3iy41K apQg8fa5zJUattqX8gug4sCK4y5f1i7etq+TH/AzO8b9bo74DhU9Qf41Tq2HeBNIaYr2 Z47OXSIy2V5STAQqXOeO53rVZi8xaTrU2pvGfsDHMtstq0PxpEaGYRnxaviPUeWPF2dY GhDSB/m5dmfU6uy/gf2RPZMZPd+n5Uh884vJekUWKrYPgfR9T/03aUF2t/8Pue75fLjm zIxw== X-Gm-Message-State: AO0yUKX4vogd2menqMIJbkGrm/QYr/c3sbU7Df3hPTx8ArXvoeELuga7 eKNhFXjC7IvvsuL6cNseuABdloz7SvyMlct6EbX7m0B89z9iQIvrKWLiAjxaRUoQjTTaCoeohAE 3tXNBmGhrPRanmaDCg+7BeXbz6BmYEOMGk3X9JqsBI5YAOdGQa4QpZw== X-Received: by 2002:a05:6871:b19b:b0:177:9f9c:dc5 with SMTP id an27-20020a056871b19b00b001779f9c0dc5mr512928oac.9.1679626491037; Thu, 23 Mar 2023 19:54:51 -0700 (PDT) X-Received: by 2002:a05:6871:b19b:b0:177:9f9c:dc5 with SMTP id an27-20020a056871b19b00b001779f9c0dc5mr512917oac.9.1679626490818; Thu, 23 Mar 2023 19:54:50 -0700 (PDT) MIME-Version: 1.0 References: <20230321154804.184577-1-sgarzare@redhat.com> <20230321154804.184577-4-sgarzare@redhat.com> <20230323095006.jvbbdjvkdvhzcehz@sgarzare-redhat> In-Reply-To: <20230323095006.jvbbdjvkdvhzcehz@sgarzare-redhat> From: Jason Wang Date: Fri, 24 Mar 2023 10:54:39 +0800 Message-ID: Subject: Re: [PATCH v3 8/8] vdpa_sim: add support for user VA To: Stefano Garzarella 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Thu, Mar 23, 2023 at 5:50=E2=80=AFPM Stefano Garzarella wrote: > > On Thu, Mar 23, 2023 at 11:42:07AM +0800, Jason Wang wrote: > >On Tue, Mar 21, 2023 at 11:48=E2=80=AFPM Stefano Garzarella wrote: > >> > >> 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. > > > >I wonder if everything would be simplified if we just allow the parent > >to advertise whether or not it requires the address space. > > > >Then when vhost-vDPA probes the device it can simply advertise > >use_work as true so vhost core can use get_task_mm() in this case? > > IIUC set user_worker to true, it also creates the kthread in the vhost > core (but we can add another variable to avoid this). > > My biggest concern is the comment in include/linux/sched/mm.h. > get_task_mm() uses mmget(), but in the documentation they advise against > pinning the address space indefinitely, so I preferred in keeping > mmgrab() in the vhost core, then call mmget_not_zero() in the worker > only when it is running. Ok. > > In the future maybe mm will be used differently from parent if somehow > it is supported by iommu, so I would leave it to the parent to handle > this. This should be possible, I was told by Intel that their IOMMU can access the process page table for shared virtual memory. Thanks > > Thanks, > Stefano >