Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp42512pxv; Thu, 24 Jun 2021 02:18:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxHVMJo2tu3nyDvCJbiyrTyqyM69oIiWKcWWl1QxxhdlUp+0kXpbwXvnJGXG9cI1hCscpoX X-Received: by 2002:a50:fb17:: with SMTP id d23mr5806478edq.58.1624526290947; Thu, 24 Jun 2021 02:18:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624526290; cv=none; d=google.com; s=arc-20160816; b=T5mNAbpCY70YK6b8EXeLnIdq+WHJ79RLGpQe3VIHwEbGmS0WifKHqFmXNvHCgGSH67 DSNqv6sRRo05keqlXiaQBA3R/Ob1wxM8phvrmOciyqN5+H00sLLp7PxTHtFcjQ0V5saY 7+VwKgr7mFOr2pOz+B0LjDEkYtRLjnE20YjOKwJ4sOs44hfPQbOiQiQu7r36DLRHuAZB NExXdV/5cDjbvhA3th9D2pjGlXER7UIwCaEFGXr3avlmtba4Bu3p/jBrUI4KsaMWZlwK gCoLJ+ZnrNlCisYR0ITmhF+0U0pGtCNx+7AGePm3xNe94PiRVlc6O6L0Vrgi28EUDqi1 mtsw== 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=ToYKmnHgqk/66SzWjvRy2Lj5kh6aXbY58HiBGtTfTYc=; b=tINLN3orSvci+DCytviL+VdTkVnN0KD48OUFrKUKMQ4JfcpGDl4UYqcp24w0hBrla8 nLTm+QHkCxalKkj8+XI43nPUfnYXJBfJbFoLMKloQ93S8hIVsZjBvZSbTYMZfm/Kf/If xj7t7PsNdxkRNWk9QswMefdGfoNXfJmtbLO1VcOhBe4VkXlbuz1aEGlH5vNRjGt/m+Fk CZyqORHYejavBi9/vuvgry3HR/4jqbl+vDFhSl4DnRWnWRnYQJlFycGoW+JmIlAEyb0H SBzpWjBXyaznt53ixNJfgIZtyTE1cFZHgDNmTOuXvwhgqOLzFplsVKKA26hnlXEAPJ58 2Plg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20150623.gappssmtp.com header.s=20150623 header.b=ZEweUXuA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ci23si2211828ejc.149.2021.06.24.02.17.47; Thu, 24 Jun 2021 02:18:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@bytedance-com.20150623.gappssmtp.com header.s=20150623 header.b=ZEweUXuA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231455AbhFXJTN (ORCPT + 99 others); Thu, 24 Jun 2021 05:19:13 -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-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