Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1381899pxb; Sun, 21 Feb 2021 23:38:15 -0800 (PST) X-Google-Smtp-Source: ABdhPJwwycZwas4pyCVoPKjzkmwwQxs7mgVCTX6/2OeeZvylW/ISmy9fkfyy21/JrDOW2PP22pJA X-Received: by 2002:a05:6402:216:: with SMTP id t22mr21088209edv.168.1613979494897; Sun, 21 Feb 2021 23:38:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613979494; cv=none; d=google.com; s=arc-20160816; b=o69Lwg0EH3t3gxctzlI6cDbKRoblQhUrmEyNiWrZ/DfPQjprqfWDORjti047wZLnav 62HmDdbrSpnHDk6VRK/a6oOvmvmcHTw7K1b22NuViysXwoMKKWSStmkvECehzkL7/84x wrGyjNGqzfMcGz0TmJNvBCRATPBVI4N5G2G04IyI0ZcWr/WLIblTJY24LkIp3yzxdd2i 1OPUkLvul/5En/28QbBtPECxLA3ALV9q9Yz7mVjortX6Xjubx2oaPslGXxeyxCGu+TGH CraSOs0NTb67dNkYEGXF6T0jmfcNkLdAHrmaL/L4J0wT/ja8TjbkEYFnq8KgQ573qSCZ ZNWw== 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=6FVHK+rXFWPhvTdgY3ca3NMaeJHpQu46VbcX/NLNp1o=; b=JvOs9nI6sftis4ZE6peNNwspZ2xcW1rpSnJRFB1OkZL2msxOOHI61xIPDeRea+gzWz 2AQ1sHeh/pz/0+hTY2gC7buKB5hFG3oWuVSXTrOJrzaxXL/g4TRmFU03xvuswITHdCHo /xmUGPO3UEzvA37IJULeDNH8cB1/dHT5RAN75DTG3W1Af9ys12ldBi1n2aTuYPiHFMCu zlOaxedmnWtIsqLBe9cIMB+rrYEp7mmX4L3M9YMYfm/Q5hSDA14kM+J/7pB6CN94S2Ga NO3vOj4I0y6234uy9gwtDyovTkNnc5sBQsfQ9GHz5u0mPV0XyW/z0M5FO/e5ZZo36xkh 1v4g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BBRGR8EE; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t9si11559688ejx.434.2021.02.21.23.37.52; Sun, 21 Feb 2021 23:38:14 -0800 (PST) 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=@redhat.com header.s=mimecast20190719 header.b=BBRGR8EE; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230128AbhBVHgW (ORCPT + 99 others); Mon, 22 Feb 2021 02:36:22 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:37442 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230042AbhBVHgL (ORCPT ); Mon, 22 Feb 2021 02:36:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1613979284; 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=6FVHK+rXFWPhvTdgY3ca3NMaeJHpQu46VbcX/NLNp1o=; b=BBRGR8EEsaKbEYis3B4wqnH00BkdrfJ1aggwobhwkTPPHI8ByrPvhRfalWLuRESDXparV/ X25GR473nxAfDyoS3PtDqnIDgaToLYVFoWyGqVlWU9x/ZZNgKN8s35AblGr65hN1SNuSVV bKGDkk/2iF1oGcYsOeoKk5JWs173Hms= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-448-WFkvTmykN2KrAvAA3Z3ZgQ-1; Mon, 22 Feb 2021 02:34:42 -0500 X-MC-Unique: WFkvTmykN2KrAvAA3Z3ZgQ-1 Received: by mail-ed1-f71.google.com with SMTP id l23so6558515edt.23 for ; Sun, 21 Feb 2021 23:34:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=6FVHK+rXFWPhvTdgY3ca3NMaeJHpQu46VbcX/NLNp1o=; b=mgR0lqifHL/VcHSpEo1Orixnn+knbeWCspDjihEVXr2GwjK6FmnrTzoQfq+g1xJYvw XGIRpFh7wb3++rw8SSsCWtU/F4wiigCLw7VOVzka+QJfpCG21EaLa49sXGZaWLXTjQPO mUArdZHA01r070SuuSZ3zbG/MZeEfaQ06wNNJOUatmWWa0wrRgVEpHrUw2VvV/Q3X9Ud DYtzxjFYBIoX+yaxTmkt+3f4dYEQqYTJ/gf++5PNDM/8rlTzVDG/HgAVugqHUwhlh3XD r1s1oRq2Xnc/CMGhqoszQCC6U9Lq2juKvjuAeO9E2w6Ux7wGt+MRt2FGEy2C7AqKFIgV MQGw== X-Gm-Message-State: AOAM533kECsKnTgZZzmNiyDZZwVuUCTi1ngbaRKFmiP6qgdXGZ+xzEBp +EKhMNcnrkf/0HmEOVJYM5ObXi/bwPBqc/D/WhSS2t95aQ25TgquK+0IST1IxmkjGYx5+YPdkOk fA6UeoxfkJqpNDbnCiSguYrOb X-Received: by 2002:a05:6402:3d8:: with SMTP id t24mr21009491edw.298.1613979280811; Sun, 21 Feb 2021 23:34:40 -0800 (PST) X-Received: by 2002:a05:6402:3d8:: with SMTP id t24mr21009478edw.298.1613979280624; Sun, 21 Feb 2021 23:34:40 -0800 (PST) Received: from redhat.com (bzq-79-180-2-31.red.bezeqint.net. [79.180.2.31]) by smtp.gmail.com with ESMTPSA id m26sm4603396eja.6.2021.02.21.23.34.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Feb 2021 23:34:40 -0800 (PST) Date: Mon, 22 Feb 2021 02:34:37 -0500 From: "Michael S. Tsirkin" To: Jason Wang Cc: Si-Wei Liu , elic@nvidia.com, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, netdev@vger.kernel.org Subject: Re: [PATCH] vdpa/mlx5: set_features should allow reset to zero Message-ID: <20210222023040-mutt-send-email-mst@kernel.org> References: <1613735698-3328-1-git-send-email-si-wei.liu@oracle.com> <605e7d2d-4f27-9688-17a8-d57191752ee7@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <605e7d2d-4f27-9688-17a8-d57191752ee7@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 22, 2021 at 12:14:17PM +0800, Jason Wang wrote: > > On 2021/2/19 7:54 下午, Si-Wei Liu wrote: > > Commit 452639a64ad8 ("vdpa: make sure set_features is invoked > > for legacy") made an exception for legacy guests to reset > > features to 0, when config space is accessed before features > > are set. We should relieve the verify_min_features() check > > and allow features reset to 0 for this case. > > > > It's worth noting that not just legacy guests could access > > config space before features are set. For instance, when > > feature VIRTIO_NET_F_MTU is advertised some modern driver > > will try to access and validate the MTU present in the config > > space before virtio features are set. > > > This looks like a spec violation: > > " > > The following driver-read-only field, mtu only exists if VIRTIO_NET_F_MTU is > set. > This field specifies the maximum MTU for the driver to use. > " > > Do we really want to workaround this? > > Thanks And also: The driver MUST follow this sequence to initialize a device: 1. Reset the device. 2. Set the ACKNOWLEDGE status bit: the guest OS has noticed the device. 3. Set the DRIVER status bit: the guest OS knows how to drive the device. 4. Read device feature bits, and write the subset of feature bits understood by the OS and driver to the device. During this step the driver MAY read (but MUST NOT write) the device-specific configuration fields to check that it can support the device before accepting it. 5. Set the FEATURES_OK status bit. The driver MUST NOT accept new feature bits after this step. 6. Re-read device status to ensure the FEATURES_OK bit is still set: otherwise, the device does not support our subset of features and the device is unusable. 7. Perform device-specific setup, including discovery of virtqueues for the device, optional per-bus setup, reading and possibly writing the device’s virtio configuration space, and population of virtqueues. 8. Set the DRIVER_OK status bit. At this point the device is “live”. so accessing config space before FEATURES_OK is a spec violation, right? > > > Rejecting reset to 0 > > prematurely causes correct MTU and link status unable to load > > for the very first config space access, rendering issues like > > guest showing inaccurate MTU value, or failure to reject > > out-of-range MTU. > > > > Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices") > > Signed-off-by: Si-Wei Liu > > --- > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 15 +-------------- > > 1 file changed, 1 insertion(+), 14 deletions(-) > > > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c > > index 7c1f789..540dd67 100644 > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c > > @@ -1490,14 +1490,6 @@ static u64 mlx5_vdpa_get_features(struct vdpa_device *vdev) > > return mvdev->mlx_features; > > } > > -static int verify_min_features(struct mlx5_vdpa_dev *mvdev, u64 features) > > -{ > > - if (!(features & BIT_ULL(VIRTIO_F_ACCESS_PLATFORM))) > > - return -EOPNOTSUPP; > > - > > - return 0; > > -} > > - > > static int setup_virtqueues(struct mlx5_vdpa_net *ndev) > > { > > int err; > > @@ -1558,18 +1550,13 @@ static int mlx5_vdpa_set_features(struct vdpa_device *vdev, u64 features) > > { > > struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev); > > struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev); > > - int err; > > print_features(mvdev, features, true); > > - err = verify_min_features(mvdev, features); > > - if (err) > > - return err; > > - > > ndev->mvdev.actual_features = features & ndev->mvdev.mlx_features; > > ndev->config.mtu = cpu_to_mlx5vdpa16(mvdev, ndev->mtu); > > ndev->config.status |= cpu_to_mlx5vdpa16(mvdev, VIRTIO_NET_S_LINK_UP); > > - return err; > > + return 0; > > } > > static void mlx5_vdpa_set_config_cb(struct vdpa_device *vdev, struct vdpa_callback *cb)