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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 5D35EC11F66 for ; Tue, 29 Jun 2021 03:56:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 473C761D4B for ; Tue, 29 Jun 2021 03:56:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232056AbhF2D7N (ORCPT ); Mon, 28 Jun 2021 23:59:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46364 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231750AbhF2D7H (ORCPT ); Mon, 28 Jun 2021 23:59:07 -0400 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9F726C061574 for ; Mon, 28 Jun 2021 20:56:39 -0700 (PDT) Received: by mail-ej1-x62f.google.com with SMTP id c17so7911596ejk.13 for ; Mon, 28 Jun 2021 20:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=D86WnvUg/Gf6HvI1cRKKP6mYttXzkG9si4A9EUDsAM8=; b=ktycy0u3fd2n2LkkSyJRlmSxqWEZlI+BMvbBCygDsyL4bIVPtYgv5F3+OlCovp8IE5 YdPYVKSMPNv8K2fsE7c+BMChTcNAl5zpMojzsBvnVkL4PPrg7fnB0m/BFLGeBU0lzU1m MU7KsdUKUmnRFvYuD/eV+6Db6BPIOkjzmSt9osG/AWuczpiHFJ2Bu4tU+ciassk5Ffh/ eGTomGEeKsvnc7O2JYvkMtm4pMXolMCXY87xsSrpS765Ssqow1gwNrBX4Dxq/qiRbqeG izQopD22vjrMYv+U6MDcAo2FarGQHBrWmq+Nm6+vmwbR1xRB/et+FjzeuFqj2ugygP0H WDGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=D86WnvUg/Gf6HvI1cRKKP6mYttXzkG9si4A9EUDsAM8=; b=coq4sphUo1BcpcIIKrvIkRk6/iWUhMncIhN3H6YzkNVNkDAw37IiQ46PKh3n8Wdqbp 6XVN0t9LRh71o8FsEENm9zUFHzMLBDFrh4GANwmjAxzLjLNsfSDEzvjHwbh/3AqG8gaq cbmUbJhgvMqThUE2o8Fd6bRuLqMes79ZucynhKLQ1hZxbKD5komlVaLmFNMWfKTcLpW8 JyZsxc9nTQjEVQQDIU0Z3a004etoHO5qO/LDNrCS1e/8lNHtJf8CrrBy0UXpPRYnkxTR cm11pR98+L7qTWsm809IcSd8AqYVTZVFYTLFwjIazbEYq4KDyffcmY7Y/87KO/7t/IJI xEsA== X-Gm-Message-State: AOAM531jQyUVB9/+JeGoJKfeCah6BK6CDPKTNyFS2R/qGeclevpeCbLr ucybbI3ZRRAc3FMOyG6KRB+zhnExazX1haOGFGJY X-Google-Smtp-Source: ABdhPJwtp85h6QY/GJlNTdlYZ5BUszc1XLhwmkDVnzLYJaYJYGPEVbGPDY3rOdmLE4oNkfRjGeiuf2gOtKcicAsxgrk= X-Received: by 2002:a17:906:7142:: with SMTP id z2mr27152930ejj.427.1624938998259; Mon, 28 Jun 2021 20:56:38 -0700 (PDT) MIME-Version: 1.0 References: <20210615141331.407-1-xieyongji@bytedance.com> <1bba439f-ffc8-c20e-e8a4-ac73e890c592@redhat.com> <0aeb7cb7-58e5-1a95-d830-68edd7e8ec2e@redhat.com> <48cab125-093b-2299-ff9c-3de8c7c5ed3d@redhat.com> In-Reply-To: From: Yongji Xie Date: Tue, 29 Jun 2021 11:56:27 +0800 Message-ID: Subject: Re: Re: [PATCH v8 09/10] vduse: Introduce VDUSE - vDPA Device in Userspace To: Jason Wang Cc: "Michael S. Tsirkin" , Stefan Hajnoczi , Stefano Garzarella , Parav Pandit , Christoph Hellwig , Christian Brauner , Randy Dunlap , Matthew Wilcox , Al Viro , Jens Axboe , bcrl@kvack.org, Jonathan Corbet , =?UTF-8?Q?Mika_Penttil=C3=A4?= , Dan Carpenter , joro@8bytes.org, Greg KH , songmuchun@bytedance.com, virtualization , netdev@vger.kernel.org, kvm , linux-fsdevel@vger.kernel.org, iommu@lists.linux-foundation.org, linux-kernel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 29, 2021 at 11:29 AM Jason Wang wrote: > > > =E5=9C=A8 2021/6/29 =E4=B8=8A=E5=8D=8810:26, Yongji Xie =E5=86=99=E9=81= =93: > > On Mon, Jun 28, 2021 at 12:40 PM Jason Wang wrote= : > >> > >> =E5=9C=A8 2021/6/25 =E4=B8=8B=E5=8D=8812:19, Yongji Xie =E5=86=99=E9= =81=93: > >>>> 2b) for set_status(): simply relay the message to userspace, reply i= s no > >>>> needed. Userspace will use a command to update the status when the > >>>> datapath is stop. The the status could be fetched via get_stats(). > >>>> > >>>> 2b looks more spec complaint. > >>>> > >>> Looks good to me. And I think we can use the reply of the message to > >>> update the status instead of introducing a new command. > >>> > >> Just notice this part in virtio_finalize_features(): > >> > >> virtio_add_status(dev, VIRTIO_CONFIG_S_FEATURES_OK); > >> status =3D dev->config->get_status(dev); > >> if (!(status & VIRTIO_CONFIG_S_FEATURES_OK)) { > >> > >> So we no reply doesn't work for FEATURES_OK. > >> > >> So my understanding is: > >> > >> 1) We must not use noreply for set_status() > >> 2) We can use noreply for get_status(), but it requires a new ioctl to > >> update the status. > >> > >> So it looks to me we need synchronize for both get_status() and > >> set_status(). > >> > > We should not send messages to userspace in the FEATURES_OK case. So > > the synchronization is not necessary. > > > As discussed previously, there could be a device that mandates some > features (VIRTIO_F_RING_PACKED). So it can choose to not accept > FEATURES_OK is packed virtqueue is not negotiated. > > In this case we need to relay the message to userspace. > OK, I see. If so, I prefer to only use noreply for set_status(). We do not set the status bit if the message is failed. In this way, we don't need to change lots of virtio core codes to handle the failure of set_status()/get_status(). Thanks, Yongji