Message ID | 20240104153753.2931026-3-maxime.coquelin@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-16863-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:6f82:b0:100:9c79:88ff with SMTP id tb2csp5687023dyb; Thu, 4 Jan 2024 07:39:13 -0800 (PST) X-Google-Smtp-Source: AGHT+IGiODITCO3OsXQ1n+/Jb3a/zchjV18zhUBsi5547z0oKopAKpPssabHBB4gGuM8nbA7E7fG X-Received: by 2002:a17:902:ced0:b0:1d4:c4bd:4d11 with SMTP id d16-20020a170902ced000b001d4c4bd4d11mr959951plg.5.1704382752759; Thu, 04 Jan 2024 07:39:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704382752; cv=none; d=google.com; s=arc-20160816; b=Parwpac4sooWKlBQx7kBBCGwCCWWM+N7657xxqO7q4Z6Qb21Lc5f09Hi2B8pATonZn irQB2k0GGNyxjwBiPNv6d7Qd5nLsH1V/K2x9a+Df4zX1i5XqXHex0BazbuJbxDy/Rh1G ctxvHSyBJe/UZ5YC9eokESsK0ARZ/+Fno0x7mJQj/9W5sfYEjXKGBnjlg/trI+3gosSW BIQsg/TA228x3PAlp58aZD8tib5vbriJmhxrWyGzDTHm6rHTe/WTOVACK0DrRTISBAaW ErC+FS3J7zbSakZu7culm8qgQlj63sMMvhXBHuQaOx+9cQNmSFzbNXK+P1y4tqr+FAkA EBpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=jY+Y8f7msSBOyPpnVlDqciKOzAOrzUzlYnkERV/e6aE=; fh=+YAWGNokPfoHg1oXKIXy6skWlEnaUutNlHrvMBZ3/ec=; b=kkKONmwhqxWt6DcJM6P9nhizE+LXJb5k5Hm6dizqDyzts5n5IlXLVBpeVaRGq72Qhl DALwNikSZHkaUYdaRKOH88uMl3it9YAqJDyZWdWRenohOGLLj59PkW1/MxQUGZQVG20W xsZTg7QGYp5vMC9Se0Tws79TBlnp2IO3oHP3ZVH6lGfvrIZWF72ES1CJd6FLMnuVyQrI cqY95WU0daL5j8ZgOG3TumfGzLZs2TO29ogs8+E2eaqQ6zG7LKltkx0N3F/YbIe0ttaT jmk2TZbOAAz7eIANaPWIx7ZwKcuT5BNaayhSl2o360dH9MKbZV1V44B9VX9GK84YQlch UqcA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=jWoGjQtj; spf=pass (google.com: domain of linux-kernel+bounces-16863-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-16863-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id h1-20020a170902704100b001d3f1b83756si23852792plt.259.2024.01.04.07.39.12 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jan 2024 07:39:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-16863-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=jWoGjQtj; spf=pass (google.com: domain of linux-kernel+bounces-16863-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-16863-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 7E10D2877AA for <ouuuleilei@gmail.com>; Thu, 4 Jan 2024 15:39:12 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 04965250F3; Thu, 4 Jan 2024 15:38:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="jWoGjQtj" X-Original-To: linux-kernel@vger.kernel.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F1EBD249E9 for <linux-kernel@vger.kernel.org>; Thu, 4 Jan 2024 15:38:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1704382687; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jY+Y8f7msSBOyPpnVlDqciKOzAOrzUzlYnkERV/e6aE=; b=jWoGjQtj6j90C2x0XSpAyP5NmROuCOSIFHR9Lmwmy95wME4bOX5Rrp8deSC6b73VS+/cyv hNq8juj2rT/6xb6RvhhhTdZH/w38CvZ0VCoHr5ZmUWL9gbRKOEGVpAq7HdxAy+Ot4vhsPl m5VPgLI6wGLl5YO/eDyHdr0VIGsUQl8= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-515-0ZYvtpH_MeCHbJRHQRxZqg-1; Thu, 04 Jan 2024 10:38:03 -0500 X-MC-Unique: 0ZYvtpH_MeCHbJRHQRxZqg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1302E862F78; Thu, 4 Jan 2024 15:38:03 +0000 (UTC) Received: from max-p1.redhat.com (unknown [10.39.208.29]) by smtp.corp.redhat.com (Postfix) with ESMTP id 06558C15E6A; Thu, 4 Jan 2024 15:38:00 +0000 (UTC) From: Maxime Coquelin <maxime.coquelin@redhat.com> To: mst@redhat.com, jasowang@redhat.com, xuanzhuo@linux.alibaba.com, xieyongji@bytedance.com, virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, david.marchand@redhat.com, lulu@redhat.com Cc: Maxime Coquelin <maxime.coquelin@redhat.com> Subject: [PATCH v6 2/3] vduse: Temporarily fail if control queue features requested Date: Thu, 4 Jan 2024 16:37:52 +0100 Message-ID: <20240104153753.2931026-3-maxime.coquelin@redhat.com> In-Reply-To: <20240104153753.2931026-1-maxime.coquelin@redhat.com> References: <20240104153753.2931026-1-maxime.coquelin@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1787174848995801299 X-GMAIL-MSGID: 1787174848995801299 |
Series |
vduse: add support for networking devices
|
|
Commit Message
Maxime Coquelin
Jan. 4, 2024, 3:37 p.m. UTC
Virtio-net driver control queue implementation is not safe
when used with VDUSE. If the VDUSE application does not
reply to control queue messages, it currently ends up
hanging the kernel thread sending this command.
Some work is on-going to make the control queue
implementation robust with VDUSE. Until it is completed,
let's fail features check if any control-queue related
feature is requested.
Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
---
drivers/vdpa/vdpa_user/vduse_dev.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
Comments
On Thu, Jan 4, 2024 at 11:38 PM Maxime Coquelin <maxime.coquelin@redhat.com> wrote: > > Virtio-net driver control queue implementation is not safe > when used with VDUSE. If the VDUSE application does not > reply to control queue messages, it currently ends up > hanging the kernel thread sending this command. > > Some work is on-going to make the control queue > implementation robust with VDUSE. Until it is completed, > let's fail features check if any control-queue related > feature is requested. > > Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com> > --- > drivers/vdpa/vdpa_user/vduse_dev.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c > index 0486ff672408..94f54ea2eb06 100644 > --- a/drivers/vdpa/vdpa_user/vduse_dev.c > +++ b/drivers/vdpa/vdpa_user/vduse_dev.c > @@ -28,6 +28,7 @@ > #include <uapi/linux/virtio_config.h> > #include <uapi/linux/virtio_ids.h> > #include <uapi/linux/virtio_blk.h> > +#include <uapi/linux/virtio_ring.h> > #include <linux/mod_devicetable.h> > > #include "iova_domain.h" > @@ -46,6 +47,15 @@ > > #define IRQ_UNBOUND -1 > > +#define VDUSE_NET_INVALID_FEATURES_MASK \ > + (BIT_ULL(VIRTIO_NET_F_CTRL_VQ) | \ > + BIT_ULL(VIRTIO_NET_F_CTRL_RX) | \ > + BIT_ULL(VIRTIO_NET_F_CTRL_VLAN) | \ > + BIT_ULL(VIRTIO_NET_F_GUEST_ANNOUNCE) | \ > + BIT_ULL(VIRTIO_NET_F_MQ) | \ > + BIT_ULL(VIRTIO_NET_F_CTRL_MAC_ADDR) | \ > + BIT_ULL(VIRTIO_NET_F_RSS)) We need to make this as well: VIRTIO_NET_F_CTRL_GUEST_OFFLOADS Other than this, Acked-by: Jason Wang <jasowang@redhat.com> Thanks > + > struct vduse_virtqueue { > u16 index; > u16 num_max; > @@ -1680,6 +1690,9 @@ static bool features_is_valid(struct vduse_dev_config *config) > if ((config->device_id == VIRTIO_ID_BLOCK) && > (config->features & (1ULL << VIRTIO_BLK_F_CONFIG_WCE))) > return false; > + else if ((config->device_id == VIRTIO_ID_NET) && > + (config->features & VDUSE_NET_INVALID_FEATURES_MASK)) > + return false; > > return true; > } > -- > 2.43.0 >
On 1/5/24 03:45, Jason Wang wrote: > On Thu, Jan 4, 2024 at 11:38 PM Maxime Coquelin > <maxime.coquelin@redhat.com> wrote: >> >> Virtio-net driver control queue implementation is not safe >> when used with VDUSE. If the VDUSE application does not >> reply to control queue messages, it currently ends up >> hanging the kernel thread sending this command. >> >> Some work is on-going to make the control queue >> implementation robust with VDUSE. Until it is completed, >> let's fail features check if any control-queue related >> feature is requested. >> >> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com> >> --- >> drivers/vdpa/vdpa_user/vduse_dev.c | 13 +++++++++++++ >> 1 file changed, 13 insertions(+) >> >> diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c >> index 0486ff672408..94f54ea2eb06 100644 >> --- a/drivers/vdpa/vdpa_user/vduse_dev.c >> +++ b/drivers/vdpa/vdpa_user/vduse_dev.c >> @@ -28,6 +28,7 @@ >> #include <uapi/linux/virtio_config.h> >> #include <uapi/linux/virtio_ids.h> >> #include <uapi/linux/virtio_blk.h> >> +#include <uapi/linux/virtio_ring.h> >> #include <linux/mod_devicetable.h> >> >> #include "iova_domain.h" >> @@ -46,6 +47,15 @@ >> >> #define IRQ_UNBOUND -1 >> >> +#define VDUSE_NET_INVALID_FEATURES_MASK \ >> + (BIT_ULL(VIRTIO_NET_F_CTRL_VQ) | \ >> + BIT_ULL(VIRTIO_NET_F_CTRL_RX) | \ >> + BIT_ULL(VIRTIO_NET_F_CTRL_VLAN) | \ >> + BIT_ULL(VIRTIO_NET_F_GUEST_ANNOUNCE) | \ >> + BIT_ULL(VIRTIO_NET_F_MQ) | \ >> + BIT_ULL(VIRTIO_NET_F_CTRL_MAC_ADDR) | \ >> + BIT_ULL(VIRTIO_NET_F_RSS)) > > We need to make this as well: > > VIRTIO_NET_F_CTRL_GUEST_OFFLOADS I missed it, and see others have been added in the Virtio spec repository (BTW, I see this specific one is missing in the dependency list [0], I will submit a patch). I wonder if it is not just simpler to just check for VIRTIO_NET_F_CTRL_VQ is requested. As we fail instead of masking out, the VDUSE driver won't be the one violating the spec so it should be good? It will avoid having to update the mask if new features depending on it are added (or forgetting to update it). WDYT? Thanks, Maxime [0]: https://github.com/oasis-tcs/virtio-spec/blob/5fc35a7efb903fc352da81a6d2be5c01810b68d3/device-types/net/description.tex#L129 > Other than this, > > Acked-by: Jason Wang <jasowang@redhat.com> > > Thanks > >> + >> struct vduse_virtqueue { >> u16 index; >> u16 num_max; >> @@ -1680,6 +1690,9 @@ static bool features_is_valid(struct vduse_dev_config *config) >> if ((config->device_id == VIRTIO_ID_BLOCK) && >> (config->features & (1ULL << VIRTIO_BLK_F_CONFIG_WCE))) >> return false; >> + else if ((config->device_id == VIRTIO_ID_NET) && >> + (config->features & VDUSE_NET_INVALID_FEATURES_MASK)) >> + return false; >> >> return true; >> } >> -- >> 2.43.0 >> >
On Fri, Jan 5, 2024 at 9:12 AM Maxime Coquelin <maxime.coquelin@redhat.com> wrote: > > > > On 1/5/24 03:45, Jason Wang wrote: > > On Thu, Jan 4, 2024 at 11:38 PM Maxime Coquelin > > <maxime.coquelin@redhat.com> wrote: > >> > >> Virtio-net driver control queue implementation is not safe > >> when used with VDUSE. If the VDUSE application does not > >> reply to control queue messages, it currently ends up > >> hanging the kernel thread sending this command. > >> > >> Some work is on-going to make the control queue > >> implementation robust with VDUSE. Until it is completed, > >> let's fail features check if any control-queue related > >> feature is requested. > >> > >> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com> > >> --- > >> drivers/vdpa/vdpa_user/vduse_dev.c | 13 +++++++++++++ > >> 1 file changed, 13 insertions(+) > >> > >> diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c > >> index 0486ff672408..94f54ea2eb06 100644 > >> --- a/drivers/vdpa/vdpa_user/vduse_dev.c > >> +++ b/drivers/vdpa/vdpa_user/vduse_dev.c > >> @@ -28,6 +28,7 @@ > >> #include <uapi/linux/virtio_config.h> > >> #include <uapi/linux/virtio_ids.h> > >> #include <uapi/linux/virtio_blk.h> > >> +#include <uapi/linux/virtio_ring.h> > >> #include <linux/mod_devicetable.h> > >> > >> #include "iova_domain.h" > >> @@ -46,6 +47,15 @@ > >> > >> #define IRQ_UNBOUND -1 > >> > >> +#define VDUSE_NET_INVALID_FEATURES_MASK \ > >> + (BIT_ULL(VIRTIO_NET_F_CTRL_VQ) | \ > >> + BIT_ULL(VIRTIO_NET_F_CTRL_RX) | \ > >> + BIT_ULL(VIRTIO_NET_F_CTRL_VLAN) | \ > >> + BIT_ULL(VIRTIO_NET_F_GUEST_ANNOUNCE) | \ > >> + BIT_ULL(VIRTIO_NET_F_MQ) | \ > >> + BIT_ULL(VIRTIO_NET_F_CTRL_MAC_ADDR) | \ > >> + BIT_ULL(VIRTIO_NET_F_RSS)) > > > > We need to make this as well: > > > > VIRTIO_NET_F_CTRL_GUEST_OFFLOADS > > I missed it, and see others have been added in the Virtio spec > repository (BTW, I see this specific one is missing in the dependency > list [0], I will submit a patch). > > I wonder if it is not just simpler to just check for > VIRTIO_NET_F_CTRL_VQ is requested. As we fail instead of masking out, > the VDUSE driver won't be the one violating the spec so it should be > good? > > It will avoid having to update the mask if new features depending on it > are added (or forgetting to update it). > > WDYT? > I think it is safer to work with a whitelist, instead of a blacklist. As any new feature might require code changes in QEMU. Is that possible? > Thanks, > Maxime > > [0]: > https://github.com/oasis-tcs/virtio-spec/blob/5fc35a7efb903fc352da81a6d2be5c01810b68d3/device-types/net/description.tex#L129 > > Other than this, > > > > Acked-by: Jason Wang <jasowang@redhat.com> > > > > Thanks > > > >> + > >> struct vduse_virtqueue { > >> u16 index; > >> u16 num_max; > >> @@ -1680,6 +1690,9 @@ static bool features_is_valid(struct vduse_dev_config *config) > >> if ((config->device_id == VIRTIO_ID_BLOCK) && > >> (config->features & (1ULL << VIRTIO_BLK_F_CONFIG_WCE))) > >> return false; > >> + else if ((config->device_id == VIRTIO_ID_NET) && > >> + (config->features & VDUSE_NET_INVALID_FEATURES_MASK)) > >> + return false; > >> > >> return true; > >> } > >> -- > >> 2.43.0 > >> > > > >
On 1/5/24 10:59, Eugenio Perez Martin wrote: > On Fri, Jan 5, 2024 at 9:12 AM Maxime Coquelin > <maxime.coquelin@redhat.com> wrote: >> >> >> >> On 1/5/24 03:45, Jason Wang wrote: >>> On Thu, Jan 4, 2024 at 11:38 PM Maxime Coquelin >>> <maxime.coquelin@redhat.com> wrote: >>>> >>>> Virtio-net driver control queue implementation is not safe >>>> when used with VDUSE. If the VDUSE application does not >>>> reply to control queue messages, it currently ends up >>>> hanging the kernel thread sending this command. >>>> >>>> Some work is on-going to make the control queue >>>> implementation robust with VDUSE. Until it is completed, >>>> let's fail features check if any control-queue related >>>> feature is requested. >>>> >>>> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com> >>>> --- >>>> drivers/vdpa/vdpa_user/vduse_dev.c | 13 +++++++++++++ >>>> 1 file changed, 13 insertions(+) >>>> >>>> diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c >>>> index 0486ff672408..94f54ea2eb06 100644 >>>> --- a/drivers/vdpa/vdpa_user/vduse_dev.c >>>> +++ b/drivers/vdpa/vdpa_user/vduse_dev.c >>>> @@ -28,6 +28,7 @@ >>>> #include <uapi/linux/virtio_config.h> >>>> #include <uapi/linux/virtio_ids.h> >>>> #include <uapi/linux/virtio_blk.h> >>>> +#include <uapi/linux/virtio_ring.h> >>>> #include <linux/mod_devicetable.h> >>>> >>>> #include "iova_domain.h" >>>> @@ -46,6 +47,15 @@ >>>> >>>> #define IRQ_UNBOUND -1 >>>> >>>> +#define VDUSE_NET_INVALID_FEATURES_MASK \ >>>> + (BIT_ULL(VIRTIO_NET_F_CTRL_VQ) | \ >>>> + BIT_ULL(VIRTIO_NET_F_CTRL_RX) | \ >>>> + BIT_ULL(VIRTIO_NET_F_CTRL_VLAN) | \ >>>> + BIT_ULL(VIRTIO_NET_F_GUEST_ANNOUNCE) | \ >>>> + BIT_ULL(VIRTIO_NET_F_MQ) | \ >>>> + BIT_ULL(VIRTIO_NET_F_CTRL_MAC_ADDR) | \ >>>> + BIT_ULL(VIRTIO_NET_F_RSS)) >>> >>> We need to make this as well: >>> >>> VIRTIO_NET_F_CTRL_GUEST_OFFLOADS >> >> I missed it, and see others have been added in the Virtio spec >> repository (BTW, I see this specific one is missing in the dependency >> list [0], I will submit a patch). >> >> I wonder if it is not just simpler to just check for >> VIRTIO_NET_F_CTRL_VQ is requested. As we fail instead of masking out, >> the VDUSE driver won't be the one violating the spec so it should be >> good? >> >> It will avoid having to update the mask if new features depending on it >> are added (or forgetting to update it). >> >> WDYT? >> > > I think it is safer to work with a whitelist, instead of a blacklist. > As any new feature might require code changes in QEMU. Is that > possible? Well, that's how it was done in previous revision. :) I changed to a blacklist for consistency with block device's WCE feature check after Jason's comment. I'm not sure moving back to a whitelist brings much advantages when compared to the effort of keeping it up to date. Just blacklisting VIRTIO_NET_F_CTRL_VQ is enough in my opinion. Thanks, Maxime >> Thanks, >> Maxime >> >> [0]: >> https://github.com/oasis-tcs/virtio-spec/blob/5fc35a7efb903fc352da81a6d2be5c01810b68d3/device-types/net/description.tex#L129 >>> Other than this, >>> >>> Acked-by: Jason Wang <jasowang@redhat.com> >>> >>> Thanks >>> >>>> + >>>> struct vduse_virtqueue { >>>> u16 index; >>>> u16 num_max; >>>> @@ -1680,6 +1690,9 @@ static bool features_is_valid(struct vduse_dev_config *config) >>>> if ((config->device_id == VIRTIO_ID_BLOCK) && >>>> (config->features & (1ULL << VIRTIO_BLK_F_CONFIG_WCE))) >>>> return false; >>>> + else if ((config->device_id == VIRTIO_ID_NET) && >>>> + (config->features & VDUSE_NET_INVALID_FEATURES_MASK)) >>>> + return false; >>>> >>>> return true; >>>> } >>>> -- >>>> 2.43.0 >>>> >>> >> >> >
On Fri, Jan 5, 2024 at 6:14 PM Maxime Coquelin <maxime.coquelin@redhat.com> wrote: > > > > On 1/5/24 10:59, Eugenio Perez Martin wrote: > > On Fri, Jan 5, 2024 at 9:12 AM Maxime Coquelin > > <maxime.coquelin@redhat.com> wrote: > >> > >> > >> > >> On 1/5/24 03:45, Jason Wang wrote: > >>> On Thu, Jan 4, 2024 at 11:38 PM Maxime Coquelin > >>> <maxime.coquelin@redhat.com> wrote: > >>>> > >>>> Virtio-net driver control queue implementation is not safe > >>>> when used with VDUSE. If the VDUSE application does not > >>>> reply to control queue messages, it currently ends up > >>>> hanging the kernel thread sending this command. > >>>> > >>>> Some work is on-going to make the control queue > >>>> implementation robust with VDUSE. Until it is completed, > >>>> let's fail features check if any control-queue related > >>>> feature is requested. > >>>> > >>>> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com> > >>>> --- > >>>> drivers/vdpa/vdpa_user/vduse_dev.c | 13 +++++++++++++ > >>>> 1 file changed, 13 insertions(+) > >>>> > >>>> diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c > >>>> index 0486ff672408..94f54ea2eb06 100644 > >>>> --- a/drivers/vdpa/vdpa_user/vduse_dev.c > >>>> +++ b/drivers/vdpa/vdpa_user/vduse_dev.c > >>>> @@ -28,6 +28,7 @@ > >>>> #include <uapi/linux/virtio_config.h> > >>>> #include <uapi/linux/virtio_ids.h> > >>>> #include <uapi/linux/virtio_blk.h> > >>>> +#include <uapi/linux/virtio_ring.h> > >>>> #include <linux/mod_devicetable.h> > >>>> > >>>> #include "iova_domain.h" > >>>> @@ -46,6 +47,15 @@ > >>>> > >>>> #define IRQ_UNBOUND -1 > >>>> > >>>> +#define VDUSE_NET_INVALID_FEATURES_MASK \ > >>>> + (BIT_ULL(VIRTIO_NET_F_CTRL_VQ) | \ > >>>> + BIT_ULL(VIRTIO_NET_F_CTRL_RX) | \ > >>>> + BIT_ULL(VIRTIO_NET_F_CTRL_VLAN) | \ > >>>> + BIT_ULL(VIRTIO_NET_F_GUEST_ANNOUNCE) | \ > >>>> + BIT_ULL(VIRTIO_NET_F_MQ) | \ > >>>> + BIT_ULL(VIRTIO_NET_F_CTRL_MAC_ADDR) | \ > >>>> + BIT_ULL(VIRTIO_NET_F_RSS)) > >>> > >>> We need to make this as well: > >>> > >>> VIRTIO_NET_F_CTRL_GUEST_OFFLOADS > >> > >> I missed it, and see others have been added in the Virtio spec > >> repository (BTW, I see this specific one is missing in the dependency > >> list [0], I will submit a patch). > >> > >> I wonder if it is not just simpler to just check for > >> VIRTIO_NET_F_CTRL_VQ is requested. As we fail instead of masking out, > >> the VDUSE driver won't be the one violating the spec so it should be > >> good? > >> > >> It will avoid having to update the mask if new features depending on it > >> are added (or forgetting to update it). > >> > >> WDYT? > >> > > > > I think it is safer to work with a whitelist, instead of a blacklist. > > As any new feature might require code changes in QEMU. Is that > > possible? > > Well, that's how it was done in previous revision. :) > > I changed to a blacklist for consistency with block device's WCE feature > check after Jason's comment. > > I'm not sure moving back to a whitelist brings much advantages when > compared to the effort of keeping it up to date. Just blacklisting > VIRTIO_NET_F_CTRL_VQ is enough in my opinion. I think this makes sense. Thanks > > Thanks, > Maxime > > >> Thanks, > >> Maxime > >> > >> [0]: > >> https://github.com/oasis-tcs/virtio-spec/blob/5fc35a7efb903fc352da81a6d2be5c01810b68d3/device-types/net/description.tex#L129 > >>> Other than this, > >>> > >>> Acked-by: Jason Wang <jasowang@redhat.com> > >>> > >>> Thanks > >>> > >>>> + > >>>> struct vduse_virtqueue { > >>>> u16 index; > >>>> u16 num_max; > >>>> @@ -1680,6 +1690,9 @@ static bool features_is_valid(struct vduse_dev_config *config) > >>>> if ((config->device_id == VIRTIO_ID_BLOCK) && > >>>> (config->features & (1ULL << VIRTIO_BLK_F_CONFIG_WCE))) > >>>> return false; > >>>> + else if ((config->device_id == VIRTIO_ID_NET) && > >>>> + (config->features & VDUSE_NET_INVALID_FEATURES_MASK)) > >>>> + return false; > >>>> > >>>> return true; > >>>> } > >>>> -- > >>>> 2.43.0 > >>>> > >>> > >> > >> > > >
diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c index 0486ff672408..94f54ea2eb06 100644 --- a/drivers/vdpa/vdpa_user/vduse_dev.c +++ b/drivers/vdpa/vdpa_user/vduse_dev.c @@ -28,6 +28,7 @@ #include <uapi/linux/virtio_config.h> #include <uapi/linux/virtio_ids.h> #include <uapi/linux/virtio_blk.h> +#include <uapi/linux/virtio_ring.h> #include <linux/mod_devicetable.h> #include "iova_domain.h" @@ -46,6 +47,15 @@ #define IRQ_UNBOUND -1 +#define VDUSE_NET_INVALID_FEATURES_MASK \ + (BIT_ULL(VIRTIO_NET_F_CTRL_VQ) | \ + BIT_ULL(VIRTIO_NET_F_CTRL_RX) | \ + BIT_ULL(VIRTIO_NET_F_CTRL_VLAN) | \ + BIT_ULL(VIRTIO_NET_F_GUEST_ANNOUNCE) | \ + BIT_ULL(VIRTIO_NET_F_MQ) | \ + BIT_ULL(VIRTIO_NET_F_CTRL_MAC_ADDR) | \ + BIT_ULL(VIRTIO_NET_F_RSS)) + struct vduse_virtqueue { u16 index; u16 num_max; @@ -1680,6 +1690,9 @@ static bool features_is_valid(struct vduse_dev_config *config) if ((config->device_id == VIRTIO_ID_BLOCK) && (config->features & (1ULL << VIRTIO_BLK_F_CONFIG_WCE))) return false; + else if ((config->device_id == VIRTIO_ID_NET) && + (config->features & VDUSE_NET_INVALID_FEATURES_MASK)) + return false; return true; }