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 761D2C49EA6 for ; Thu, 24 Jun 2021 09:16:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5D1EC61358 for ; Thu, 24 Jun 2021 09:16:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231489AbhFXJTO (ORCPT ); Thu, 24 Jun 2021 05:19:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57282 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231298AbhFXJTM (ORCPT ); Thu, 24 Jun 2021 05:19:12 -0400 Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 355FAC061574 for ; Thu, 24 Jun 2021 02:16:52 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id s15so7455053edt.13 for ; Thu, 24 Jun 2021 02:16:52 -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=ToYKmnHgqk/66SzWjvRy2Lj5kh6aXbY58HiBGtTfTYc=; b=ZEweUXuAJoGCGMqY3z9xEzvHeOc45CgfE+oRLPnwvWDM8sEylSod/l69pmO1wTq6Fk dJ6IJffz8PwtlA84nAwOMbu/T24GwtdMUEWh7Wfy0A/5i4gI8Lx4GorjU0lFTf+6k/vp waHl9OMa0UhLOi5kJckBgVUzPJL/7362ZFcIUrXc9waM3czme6JE2Mo08y5M7V+vITDj FSMllieK9ieeAYx2zFLgwFaafNl51St8nhwF6tDUKXqzbB8XsjnOGrlgyKrhcMFFDR5E SiRzn5cHnpY863Xr8EDmjh2FISKPY1AoSdoR/zlJVxPQyBejxzBJIxXPRJBt624oRvsJ Nt6A== 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=ToYKmnHgqk/66SzWjvRy2Lj5kh6aXbY58HiBGtTfTYc=; b=PikHHE9w9aMr81I8sGElFdwkzQtwgT1T1m+ZhGp3yyHyrKTo/Lzy2HFcY2Vk2MA9aL 4IVxgq8yF0b1h225QQpCh2IjDocivpB4O1Cv5hwj9GWQoB9nJtevpepVsOE47d4qQC35 ynYTd9RyDY70JaKoAherl8KqqYuh0fJA5BWpjfA6YO8P25pVYjSy2Vsv5ajqOuEbN0kx SggNDeT04LlQtdkLSlGYHM7dW7o+3xAjWTCr7aWe5NwVgFI2M1Tdca0mbyPWiqXOmoQs m+4STKFA3Si1OKlTvM7H2HKdWPgHMot3AK+RZGJ8FORB5BEy4qlWWy6u8bRpI1OB+7AR NGYA== X-Gm-Message-State: AOAM532z83JBg405Z2rGYjy3fbjKRtmNIh90tAIgIITGiqfLc1Pkk9BF +MBHmnSMOaBdUKwrkOwykPyQFr8U98hS6jX72y+5 X-Google-Smtp-Source: ABdhPJwzxlNtCT4qXONVb1tZWclCON16CNPSh2qEimKMjvYzH/fk8YJnTCoKh644GYgJY+nPjC5RJVk2i47qjgJpKlM= X-Received: by 2002:a05:6402:27ce:: with SMTP id c14mr5750686ede.118.1624526210663; Thu, 24 Jun 2021 02:16:50 -0700 (PDT) MIME-Version: 1.0 References: <20210615141331.407-1-xieyongji@bytedance.com> <20210615141331.407-10-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: <48cab125-093b-2299-ff9c-3de8c7c5ed3d@redhat.com> From: Yongji Xie Date: Thu, 24 Jun 2021 17:16:39 +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 Thu, Jun 24, 2021 at 4:14 PM Jason Wang wrote: > > > =E5=9C=A8 2021/6/24 =E4=B8=8B=E5=8D=8812:46, Yongji Xie =E5=86=99=E9=81= =93: > >> So we need to deal with both FEATURES_OK and reset, but probably not > >> DRIVER_OK. > >> > > OK, I see. Thanks for the explanation. One more question is how about > > clearing the corresponding status bit in get_status() rather than > > making set_status() fail. Since the spec recommends this way for > > validation which is done in virtio_dev_remove() and > > virtio_finalize_features(). > > > > Thanks, > > Yongji > > > > I think you can. Or it would be even better that we just don't set the > bit during set_status(). > Yes, that's what I mean. > I just realize that in vdpa_reset() we had: > > static inline void vdpa_reset(struct vdpa_device *vdev) > { > const struct vdpa_config_ops *ops =3D vdev->config; > > vdev->features_valid =3D false; > ops->set_status(vdev, 0); > } > > We probably need to add the synchronization here. E.g re-read with a > timeout. > Looks like the timeout is already in set_status(). Do we really need a duplicated one here? And how to handle failure? Adding a return value to virtio_config_ops->reset() and passing the error to the upper layer? Thanks, Yongji