From: Jason Wang <jasowang@redhat.com>
To: Si-Wei Liu <si-wei.liu@oracle.com>, mst@redhat.com, elic@nvidia.com
Cc: linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
netdev@vger.kernel.org
Subject: Re: [PATCH v2 2/3] vdpa/mlx5: fix feature negotiation across device reset
Date: Thu, 18 Feb 2021 14:36:43 +0800 [thread overview]
Message-ID: <386fffb2-be75-9ce0-0a4d-1d47f91e7d16@redhat.com> (raw)
In-Reply-To: <1612993680-29454-3-git-send-email-si-wei.liu@oracle.com>
On 2021/2/11 上午5:47, Si-Wei Liu wrote:
> The mlx_features denotes the capability for which
> set of virtio features is supported by device. In
> principle, this field needs not be cleared during
> virtio device reset, as this capability is static
> and does not change across reset.
>
> In fact, the current code may have the assumption
> that mlx_features can be reloaded from firmware
> via the .get_features ops after device is reset
> (via the .set_status ops), which is unfortunately
> not true. The userspace VMM might save a copy
> of backend capable features and won't call into
> kernel again to get it on reset. This causes all
> virtio features getting disabled on newly created
> virtqs after device reset, while guest would hold
> mismatched view of available features. For e.g.,
> the guest may still assume tx checksum offload
> is available after reset and feature negotiation,
> causing frames with bogus (incomplete) checksum
> transmitted on the wire.
>
> Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
> Signed-off-by: Si-Wei Liu <si-wei.liu@oracle.com>
Acked-by: Jason Wang <jasowang@redhat.com>
> ---
> drivers/vdpa/mlx5/net/mlx5_vnet.c | 25 +++++++++++++++----------
> 1 file changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> index b8416c4..7c1f789 100644
> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> @@ -1486,16 +1486,8 @@ static u64 mlx_to_vritio_features(u16 dev_features)
> static u64 mlx5_vdpa_get_features(struct vdpa_device *vdev)
> {
> struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev);
> - struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev);
> - u16 dev_features;
>
> - dev_features = MLX5_CAP_DEV_VDPA_EMULATION(mvdev->mdev, device_features_bits_mask);
> - ndev->mvdev.mlx_features = mlx_to_vritio_features(dev_features);
> - if (MLX5_CAP_DEV_VDPA_EMULATION(mvdev->mdev, virtio_version_1_0))
> - ndev->mvdev.mlx_features |= BIT_ULL(VIRTIO_F_VERSION_1);
> - ndev->mvdev.mlx_features |= BIT_ULL(VIRTIO_F_ACCESS_PLATFORM);
> - print_features(mvdev, ndev->mvdev.mlx_features, false);
> - return ndev->mvdev.mlx_features;
> + return mvdev->mlx_features;
> }
>
> static int verify_min_features(struct mlx5_vdpa_dev *mvdev, u64 features)
> @@ -1788,7 +1780,6 @@ static void mlx5_vdpa_set_status(struct vdpa_device *vdev, u8 status)
> clear_virtqueues(ndev);
> mlx5_vdpa_destroy_mr(&ndev->mvdev);
> ndev->mvdev.status = 0;
> - ndev->mvdev.mlx_features = 0;
> ++mvdev->generation;
> return;
> }
> @@ -1907,6 +1898,19 @@ static int mlx5_get_vq_irq(struct vdpa_device *vdv, u16 idx)
> .free = mlx5_vdpa_free,
> };
>
> +static void query_virtio_features(struct mlx5_vdpa_net *ndev)
> +{
> + struct mlx5_vdpa_dev *mvdev = &ndev->mvdev;
> + u16 dev_features;
> +
> + dev_features = MLX5_CAP_DEV_VDPA_EMULATION(mvdev->mdev, device_features_bits_mask);
> + mvdev->mlx_features = mlx_to_vritio_features(dev_features);
> + if (MLX5_CAP_DEV_VDPA_EMULATION(mvdev->mdev, virtio_version_1_0))
> + mvdev->mlx_features |= BIT_ULL(VIRTIO_F_VERSION_1);
> + mvdev->mlx_features |= BIT_ULL(VIRTIO_F_ACCESS_PLATFORM);
> + print_features(mvdev, mvdev->mlx_features, false);
> +}
> +
> static int query_mtu(struct mlx5_core_dev *mdev, u16 *mtu)
> {
> u16 hw_mtu;
> @@ -2005,6 +2009,7 @@ static int mlx5v_probe(struct auxiliary_device *adev,
> init_mvqs(ndev);
> mutex_init(&ndev->reslock);
> config = &ndev->config;
> + query_virtio_features(ndev);
> err = query_mtu(mdev, &ndev->mtu);
> if (err)
> goto err_mtu;
next prev parent reply other threads:[~2021-02-18 7:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-10 21:47 [PATCH v2 0/3] mlx5_vdpa bug fixes Si-Wei Liu
2021-02-10 21:47 ` [PATCH v2 1/3] vdpa/mlx5: should exclude header length and fcs from mtu Si-Wei Liu
2021-02-10 21:47 ` [PATCH v2 2/3] vdpa/mlx5: fix feature negotiation across device reset Si-Wei Liu
2021-02-11 7:33 ` Eli Cohen
2021-02-18 6:36 ` Jason Wang [this message]
2021-02-10 21:48 ` [PATCH v2 3/3] vdpa/mlx5: defer clear_virtqueues to until DRIVER_OK Si-Wei Liu
2021-02-11 7:33 ` Eli Cohen
2021-02-16 15:21 ` Eli Cohen
2021-02-17 21:55 ` Si-Wei Liu
2021-02-18 6:37 ` Jason Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=386fffb2-be75-9ce0-0a4d-1d47f91e7d16@redhat.com \
--to=jasowang@redhat.com \
--cc=elic@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=si-wei.liu@oracle.com \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®