Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp233199pxb; Wed, 24 Feb 2021 00:06:32 -0800 (PST) X-Google-Smtp-Source: ABdhPJxQOboYrKDTxbBkuQB0JmpFRMOw1etZajqn7Cq/vk80N+n+oNHr68w8qg7vbIBrmPXsInnV X-Received: by 2002:a17:907:d0b:: with SMTP id gn11mr29669189ejc.144.1614153992256; Wed, 24 Feb 2021 00:06:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614153992; cv=none; d=google.com; s=arc-20160816; b=hUHApO2hAtpOEkORN9Kl1KwuAXUXuQobt8JOLCtgTjX8CjYhJgY6BnF5Q99nAmDPVO SqLoW76PCSSaxYYkM5W0TLaAow+wi12JgQH+T36u4PlazJy6NS+u7I7hAMBP3phsff2a /iMNH8KUjUsAW998rnoEiG1hf7QSfi/FO9q9wK2JtwLueCO3smcQ8DqumiUI2dNQX42f WB6w2XbaSaT5z/3e8tshXoGs4oXz86P/k06XipMHlqQbMvCoBfs7Fd+dGNWkMUjEqg0B cY9kCRpMGQNVxBSXPIGbNAEZMyQG1dOSVKEosEzQ+sCYZVjO83pdPOSD2hhJlDktea1p /jDg== 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=66ucE3xxAUBgeHQc2W+xDbouWd2JXR+g+qFxokJjKqg=; b=wU2nW67LnEAFSsMPHhkRLdfwpk8uqsXgLyLsjDL76tjlaRsesDPgnk7K5V3Sllz0Tw cp+8ZohM2pN/Nb3RqaslnW9VnqzynNZJWlV0jzFP3FJ0ZSOK5SsqAAbXYdCosUT2JRrQ fTVI+MW9MYvt1YUoFQTpLWjyOaj06ZuDtuoWV8Ewp6wcKOyBNmbVbGK7A81PEtAqy2K+ Nd6g7237HTAtiA7JVJM/W+funCVpBH9Hf3A+m4OZcx30Znqdr0pbqiWbCLECkkr4HJ6L v3nLoNA5EeDBcSm2WPnpRPBni/Jjmu2wHG+bC4mtQKmbsV4MYnkCvKbDF+UBRhl54G5p UK8Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=biBi6C4o; 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 dn20si932587ejc.418.2021.02.24.00.06.08; Wed, 24 Feb 2021 00:06:32 -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=biBi6C4o; 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 S233866AbhBXGta (ORCPT + 99 others); Wed, 24 Feb 2021 01:49:30 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:37117 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234252AbhBXGt1 (ORCPT ); Wed, 24 Feb 2021 01:49:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1614149280; 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=66ucE3xxAUBgeHQc2W+xDbouWd2JXR+g+qFxokJjKqg=; b=biBi6C4oUgqVa7xiMxgfSV8hUqiiR8Y8ZgIRWL26YnradpH4cZEJeK4YmIa9amhEEZZELz UVWe5gpEJcuKK8GyarCjwHPTgh4r9HxIHVIwVb1i4kV4GxAemD0sbb1d0NI0InHT6B6Ah1 dR1N9ZH7/A0kyWiRZ/8eFbpQO4E2NnQ= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-437-pF_Fs1SJPSKp2SkLQbL5Zg-1; Wed, 24 Feb 2021 01:47:58 -0500 X-MC-Unique: pF_Fs1SJPSKp2SkLQbL5Zg-1 Received: by mail-wm1-f72.google.com with SMTP id b62so153216wmc.5 for ; Tue, 23 Feb 2021 22:47:58 -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=66ucE3xxAUBgeHQc2W+xDbouWd2JXR+g+qFxokJjKqg=; b=ROKcY2z/HQhy2shleQygvj7Nnp4re7HEBXwRMOUUPPefE/ZpAvedKmYw5FUI1ksAkl OsEJzv1uGxnHNXW/OesMbrs+QqsYJuqB9vuHaO2DDmVAp3zGjho+kwI4nOugJz5BfHDW MjFyETMbF23pbzGk9e8vLXbo5HqQHVSMnbK3O0AHy8J1fGKSUnm9VvzHMm3a+QjSoN8r Jzs1H2+Eh1QlfG2FC+VH9dmfUmRcPXUVBjqM53/0QApB7uz+1X/D5/9CWEfoVRevd88X QMakugZSZvXOQzPaJ90KkZydJA9W9Lrf03o8gTnrQ9EncOndkLjxiXkJ8w9V+K/OHRD5 Z0xQ== X-Gm-Message-State: AOAM533dWXWGM2vqCUwRXKFQC3hzuGbQ4P27kgDVieO8lDdl5qAAIi8n gqMkItXh9uuDM/3yi04L2HDTZ0Fy8kODM8bMkmHzAEtjKjxjyIDmyNVn7B6v2H7Ng3QrNMqOWjK PCqdh+DrSh7CpAlVYsH1DX/Cz X-Received: by 2002:a5d:474a:: with SMTP id o10mr11010277wrs.176.1614149277314; Tue, 23 Feb 2021 22:47:57 -0800 (PST) X-Received: by 2002:a5d:474a:: with SMTP id o10mr11010260wrs.176.1614149277168; Tue, 23 Feb 2021 22:47:57 -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 4sm2210009wrr.27.2021.02.23.22.47.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Feb 2021 22:47:56 -0800 (PST) Date: Wed, 24 Feb 2021 01:47:54 -0500 From: "Michael S. Tsirkin" To: Eli Cohen Cc: Jason Wang , Si-Wei Liu , 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: <20210224014700-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> <20210222023040-mutt-send-email-mst@kernel.org> <22fe5923-635b-59f0-7643-2fd5876937c2@oracle.com> <20210223082536-mutt-send-email-mst@kernel.org> <3ff5fd23-1db0-2f95-4cf9-711ef403fb62@oracle.com> <7e6291a4-30b1-6b59-a2bf-713e7b56826d@redhat.com> <20210224000528-mutt-send-email-mst@kernel.org> <20210224064520.GA204317@mtl-vdi-166.wap.labs.mlnx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210224064520.GA204317@mtl-vdi-166.wap.labs.mlnx> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 24, 2021 at 08:45:20AM +0200, Eli Cohen wrote: > On Wed, Feb 24, 2021 at 12:17:58AM -0500, Michael S. Tsirkin wrote: > > On Wed, Feb 24, 2021 at 11:20:01AM +0800, Jason Wang wrote: > > > > > > On 2021/2/24 3:35 上午, Si-Wei Liu wrote: > > > > > > > > > > > > On 2/23/2021 5:26 AM, Michael S. Tsirkin wrote: > > > > > On Tue, Feb 23, 2021 at 10:03:57AM +0800, Jason Wang wrote: > > > > > > On 2021/2/23 9:12 上午, Si-Wei Liu wrote: > > > > > > > > > > > > > > On 2/21/2021 11:34 PM, Michael S. Tsirkin wrote: > > > > > > > > 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? > > > > > > > It is, but it's not relevant to what this commit tries to address. I > > > > > > > thought the legacy guest still needs to be supported. > > > > > > > > > > > > > > Having said, a separate patch has to be posted to fix the guest driver > > > > > > > issue where this discrepancy is introduced to > > > > > > > virtnet_validate() (since > > > > > > > commit fe36cbe067). But it's not technically related to this patch. > > > > > > > > > > > > > > -Siwei > > > > > > > > > > > > I think it's a bug to read config space in validate, we should > > > > > > move it to > > > > > > virtnet_probe(). > > > > > > > > > > > > Thanks > > > > > I take it back, reading but not writing seems to be explicitly > > > > > allowed by spec. > > > > > So our way to detect a legacy guest is bogus, need to think what is > > > > > the best way to handle this. > > > > Then maybe revert commit fe36cbe067 and friends, and have QEMU detect > > > > legacy guest? Supposedly only config space write access needs to be > > > > guarded before setting FEATURES_OK. > > > > > > > > > I agree. My understanding is that all vDPA must be modern device (since > > > VIRITO_F_ACCESS_PLATFORM is mandated) instead of transitional device. > > > > > > Thanks > > > > Well mlx5 has some code to handle legacy guests ... > > Eli, could you comment? Is that support unused right now? > > > > If you mean support for version 1.0, well the knob is there but it's not > set in the firmware I use. Note sure if we will support this. Hmm you mean it's legacy only right now? Well at some point you will want advanced goodies like RSS and all that is gated on 1.0 ;) > > > > > > > > > > > > > -Siwie > > > > > > > > > > > > > > > > > > > > > > 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) > > > > > >