From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 31CCCC25B0C for ; Wed, 10 Aug 2022 01:09:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id A44C3410C8; Wed, 10 Aug 2022 01:09:49 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org A44C3410C8 Authentication-Results: smtp4.osuosl.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=H83D/R4P X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEKlxNiglJRm; Wed, 10 Aug 2022 01:09:48 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp4.osuosl.org (Postfix) with ESMTPS id 9BDCC408A8; Wed, 10 Aug 2022 01:09:47 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 9BDCC408A8 Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6A76AC0032; Wed, 10 Aug 2022 01:09:47 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 46D06C002D for ; Wed, 10 Aug 2022 01:09:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 0D64681762 for ; Wed, 10 Aug 2022 01:09:46 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 0D64681762 Authentication-Results: smtp1.osuosl.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=H83D/R4P X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amr0_sWM1r1F for ; Wed, 10 Aug 2022 01:09:44 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 8E9C88149A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by smtp1.osuosl.org (Postfix) with ESMTPS id 8E9C88149A for ; Wed, 10 Aug 2022 01:09:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1660093783; 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: in-reply-to:in-reply-to:references:references; bh=ealoktxzQvMvoaVETXyzPEIriQf2QjBNBkFv9OiTEac=; b=H83D/R4Ps96JqvuwZmmzZ3usu78C7Nh7z3WUXzp4O8k9eCDp5KYVC8hKcKxGyEO+97PQ97 YRm+HQ61Roje/FKl253ELMDyXjdO3QYbmBVqzEc71ZVkic5guMe7d9FFt5A7B2LOvYiSwu U7H1+8UnUTioqX0g/NE3t/vCUzGvLJs= Received: from mail-lj1-f198.google.com (mail-lj1-f198.google.com [209.85.208.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-161-tKNe_FtZNxebeOzlY4UVmg-1; Tue, 09 Aug 2022 21:09:42 -0400 X-MC-Unique: tKNe_FtZNxebeOzlY4UVmg-1 Received: by mail-lj1-f198.google.com with SMTP id e25-20020a2e9e19000000b0025ff52b3c72so1090350ljk.14 for ; Tue, 09 Aug 2022 18:09:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=ealoktxzQvMvoaVETXyzPEIriQf2QjBNBkFv9OiTEac=; b=DfJAWlrZVpwcn0hfD6GgZRMdeyC+wuDLBAS68QGDFK6gXI7VdyZ6FTV24WP9e3yNQk DJSZH2oIEBmCcVK0+skRQLq7x/QXzCqe/EGcdzEtOJ3p5VnA+LBs/RoQmpnYMOMxyR1y xLYxTNisCYqJZRuxXYMcL91/FShwmTavXSTJDTNTvGcFSgclqqdBGcTkpW6Ni26Yc63o aqFS8am8W64t40eMjX10+2oYrDZZtxUASUjygbYlLhP8oYRUNxEKPrZjLogfK87kj550 WECOEMPpo8H3YNnTNot3mtOlUc4uPx2OpfKDe+Hm6EveggtosClef+gZO+wYCLDrcqa4 q7rQ== X-Gm-Message-State: ACgBeo23G2QICpIXt2HEiG5iO4/1jD34cQ+8OwKOzkmwC3kT2eH+rmFo kkLEQTt5NMboAk4DKd4ITMwLkob/fmT+y9/Q7EtHalkUl2NutV4YNwT81Cy2US55ytNBSSGExyJ QaWzEB+MZjV6pULW3vKKKSkyLCOS7NFwGMxtkHnIqkTXrpwY0ho5/ehmkRA== X-Received: by 2002:a05:6512:1594:b0:48d:25f2:a6d5 with SMTP id bp20-20020a056512159400b0048d25f2a6d5mr149951lfb.238.1660093780780; Tue, 09 Aug 2022 18:09:40 -0700 (PDT) X-Google-Smtp-Source: AA6agR6ZXM7tanNj9gTDHG0dFEK/yhr44bnYG5GLApfvvrxcQrT6B6gKB1dcdR8U6qr4EzRa0V7N7TmAUNPXbfbfZu8= X-Received: by 2002:a05:6512:1594:b0:48d:25f2:a6d5 with SMTP id bp20-20020a056512159400b0048d25f2a6d5mr149942lfb.238.1660093780576; Tue, 09 Aug 2022 18:09:40 -0700 (PDT) MIME-Version: 1.0 References: <20220722115309.82746-1-lingshan.zhu@intel.com> <20220722115309.82746-6-lingshan.zhu@intel.com> <20220809152457-mutt-send-email-mst@kernel.org> <42e6d45b-4fba-1c8e-1726-3f082dd7a629@oracle.com> In-Reply-To: <42e6d45b-4fba-1c8e-1726-3f082dd7a629@oracle.com> From: Jason Wang Date: Wed, 10 Aug 2022 09:09:29 +0800 Message-ID: Subject: Re: [PATCH V4 5/6] vDPA: answer num of queue pairs = 1 to userspace when VIRTIO_NET_F_MQ == 0 To: Si-Wei Liu X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Cc: "Michael S. Tsirkin" , "netdev@vger.kernel.org" , "virtualization@lists.linux-foundation.org" , "xieyongji@bytedance.com" , "gautam.dawar@amd.com" , Zhu Lingshan X-BeenThere: virtualization@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux virtualization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: virtualization-bounces@lists.linux-foundation.org Sender: "Virtualization" On Wed, Aug 10, 2022 at 8:54 AM Si-Wei Liu wrote: > > > > On 8/9/2022 12:36 PM, Michael S. Tsirkin wrote: > > On Fri, Jul 22, 2022 at 01:14:42PM +0000, Parav Pandit wrote: > >> > >>> From: Zhu Lingshan > >>> Sent: Friday, July 22, 2022 7:53 AM > >>> > >>> If VIRTIO_NET_F_MQ == 0, the virtio device should have one queue pair, so > >>> when userspace querying queue pair numbers, it should return mq=1 than > >>> zero. > >>> > >>> Function vdpa_dev_net_config_fill() fills the attributions of the vDPA > >>> devices, so that it should call vdpa_dev_net_mq_config_fill() so the > >>> parameter in vdpa_dev_net_mq_config_fill() should be feature_device than > >>> feature_driver for the vDPA devices themselves > >>> > >>> Before this change, when MQ = 0, iproute2 output: > >>> $vdpa dev config show vdpa0 > >>> vdpa0: mac 00:e8:ca:11:be:05 link up link_announce false max_vq_pairs 0 > >>> mtu 1500 > >>> > >>> After applying this commit, when MQ = 0, iproute2 output: > >>> $vdpa dev config show vdpa0 > >>> vdpa0: mac 00:e8:ca:11:be:05 link up link_announce false max_vq_pairs 1 > >>> mtu 1500 > >>> > >> No. We do not want to diverge returning values of config space for fields which are not present as discussed in previous versions. > >> Please drop this patch. > >> Nack on this patch. > > Wrt this patch as far as I'm concerned you guys are bikeshedding. > > > > Parav generally don't send nacks please they are not helpful. > > > > Zhu Lingshan please always address comments in some way. E.g. refer to > > them in the commit log explaining the motivation and the alternatives. > > I know you don't agree with Parav but ghosting isn't nice. > > > > I still feel what we should have done is > > not return a value, as long as we do return it we might > > as well return something reasonable, not 0. > Maybe I missed something but I don't get this, when VIRTIO_NET_F_MQ is > not negotiated, the VDPA_ATTR_DEV_NET_CFG_MAX_VQP attribute is simply > not there, but userspace (iproute) mistakenly puts a zero value there. > This is a pattern every tool in iproute follows consistently by large. I > don't get why kernel has to return something without seeing a very > convincing use case? > > Not to mention spec doesn't give us explicit definition for when the > field in config space becomes valid and/or the default value at first > sights as part of feature negotiation. If we want to stick to the model > Lingshan proposed, maybe fix the spec first then get back on the details? So spec said " The following driver-read-only field, max_virtqueue_pairs only exists if VIRTIO_NET_F_MQ or VIRTIO_NET_F_RSS is set. " My understanding is that the field is always valid if the device offers the feature. Btw, even if the spec is unclear, it would be very hard to "fix" it without introducing a new feature bit, it means we still need to deal with device without the new feature. Thanks > > -Siwei > > > > > And I like it that this fixes sparse warning actually: > > max_virtqueue_pairs it tagged as __virtio, not __le. > > > > However, I am worried there is another bug here: > > this is checking driver features. But really max vqs > > should not depend on that, it depends on device > > features, no? > > > > > > > >>> Signed-off-by: Zhu Lingshan > >>> --- > >>> drivers/vdpa/vdpa.c | 7 ++++--- > >>> 1 file changed, 4 insertions(+), 3 deletions(-) > >>> > >>> diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c index > >>> d76b22b2f7ae..846dd37f3549 100644 > >>> --- a/drivers/vdpa/vdpa.c > >>> +++ b/drivers/vdpa/vdpa.c > >>> @@ -806,9 +806,10 @@ static int vdpa_dev_net_mq_config_fill(struct > >>> vdpa_device *vdev, > >>> u16 val_u16; > >>> > >>> if ((features & BIT_ULL(VIRTIO_NET_F_MQ)) == 0) > >>> - return 0; > >>> + val_u16 = 1; > >>> + else > >>> + val_u16 = __virtio16_to_cpu(true, config- > >>>> max_virtqueue_pairs); > >>> - val_u16 = le16_to_cpu(config->max_virtqueue_pairs); > >>> return nla_put_u16(msg, VDPA_ATTR_DEV_NET_CFG_MAX_VQP, > >>> val_u16); } > >>> > >>> @@ -842,7 +843,7 @@ static int vdpa_dev_net_config_fill(struct > >>> vdpa_device *vdev, struct sk_buff *ms > >>> VDPA_ATTR_PAD)) > >>> return -EMSGSIZE; > >>> > >>> - return vdpa_dev_net_mq_config_fill(vdev, msg, features_driver, > >>> &config); > >>> + return vdpa_dev_net_mq_config_fill(vdev, msg, features_device, > >>> +&config); > >>> } > >>> > >>> static int > >>> -- > >>> 2.31.1 > > _______________________________________________ > > Virtualization mailing list > > Virtualization@lists.linux-foundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/virtualization > > _______________________________________________ > Virtualization mailing list > Virtualization@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/virtualization > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E60EEC25B0C for ; Wed, 10 Aug 2022 01:10:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229926AbiHJBJt (ORCPT ); Tue, 9 Aug 2022 21:09:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34670 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229972AbiHJBJp (ORCPT ); Tue, 9 Aug 2022 21:09:45 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 7237465834 for ; Tue, 9 Aug 2022 18:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1660093783; 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: in-reply-to:in-reply-to:references:references; bh=ealoktxzQvMvoaVETXyzPEIriQf2QjBNBkFv9OiTEac=; b=H83D/R4Ps96JqvuwZmmzZ3usu78C7Nh7z3WUXzp4O8k9eCDp5KYVC8hKcKxGyEO+97PQ97 YRm+HQ61Roje/FKl253ELMDyXjdO3QYbmBVqzEc71ZVkic5guMe7d9FFt5A7B2LOvYiSwu U7H1+8UnUTioqX0g/NE3t/vCUzGvLJs= Received: from mail-lj1-f198.google.com (mail-lj1-f198.google.com [209.85.208.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-22-va8_r6DkNGeohXR9eN0Nog-1; Tue, 09 Aug 2022 21:09:42 -0400 X-MC-Unique: va8_r6DkNGeohXR9eN0Nog-1 Received: by mail-lj1-f198.google.com with SMTP id u14-20020a2e844e000000b0025fbbfc610dso2387158ljh.6 for ; Tue, 09 Aug 2022 18:09:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=ealoktxzQvMvoaVETXyzPEIriQf2QjBNBkFv9OiTEac=; b=qSY8f8p2UIqWgucvZI9IDpQj33LBUP8ZY215v0K4b2xXdNvbExczk2p8L3Mu7kAfu9 79viyjxH2hbQi69RG342tX6FYt2ORRziXxBLV/xoUu6NOuIUQJY5mMDgTdm13qrXoxju FDfziqBkrtSQwrImnECC8xzXZreh4aU9XzdHo2l49byFcPlJqzPpGzfWTxlNSvIozPie dVnnxt6LMgfGLZUO3I00doiuzkGpl/kAPrnM2RbVckvojOVyD5psz+G1IpRSV6Ay4E/l dMm1SIiffpPA5EIdfyQX7B4Nwl3kufly354/7MRrz5fFYzG777zDETZWONWRBfO80KnD ydFg== X-Gm-Message-State: ACgBeo2/R+4rNDuagRXy9dpeVWK3zKFgxmqYiQYMmuWCsLOngs3qcoUW v0UoofIQH20I4CoOpX79sNEtUD3y2UP3fdQ8fEZulrY//83q/Tsho1ZXN1elkQ6zy6n3yvBgxXD J3gWdceaC0Ivs9MVZ8fcBEyj7q8fEvlzs X-Received: by 2002:a05:6512:1594:b0:48d:25f2:a6d5 with SMTP id bp20-20020a056512159400b0048d25f2a6d5mr149949lfb.238.1660093780779; Tue, 09 Aug 2022 18:09:40 -0700 (PDT) X-Google-Smtp-Source: AA6agR6ZXM7tanNj9gTDHG0dFEK/yhr44bnYG5GLApfvvrxcQrT6B6gKB1dcdR8U6qr4EzRa0V7N7TmAUNPXbfbfZu8= X-Received: by 2002:a05:6512:1594:b0:48d:25f2:a6d5 with SMTP id bp20-20020a056512159400b0048d25f2a6d5mr149942lfb.238.1660093780576; Tue, 09 Aug 2022 18:09:40 -0700 (PDT) MIME-Version: 1.0 References: <20220722115309.82746-1-lingshan.zhu@intel.com> <20220722115309.82746-6-lingshan.zhu@intel.com> <20220809152457-mutt-send-email-mst@kernel.org> <42e6d45b-4fba-1c8e-1726-3f082dd7a629@oracle.com> In-Reply-To: <42e6d45b-4fba-1c8e-1726-3f082dd7a629@oracle.com> From: Jason Wang Date: Wed, 10 Aug 2022 09:09:29 +0800 Message-ID: Subject: Re: [PATCH V4 5/6] vDPA: answer num of queue pairs = 1 to userspace when VIRTIO_NET_F_MQ == 0 To: Si-Wei Liu Cc: "Michael S. Tsirkin" , Parav Pandit , "netdev@vger.kernel.org" , Zhu Lingshan , "xieyongji@bytedance.com" , "gautam.dawar@amd.com" , "virtualization@lists.linux-foundation.org" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, Aug 10, 2022 at 8:54 AM Si-Wei Liu wrote: > > > > On 8/9/2022 12:36 PM, Michael S. Tsirkin wrote: > > On Fri, Jul 22, 2022 at 01:14:42PM +0000, Parav Pandit wrote: > >> > >>> From: Zhu Lingshan > >>> Sent: Friday, July 22, 2022 7:53 AM > >>> > >>> If VIRTIO_NET_F_MQ == 0, the virtio device should have one queue pair, so > >>> when userspace querying queue pair numbers, it should return mq=1 than > >>> zero. > >>> > >>> Function vdpa_dev_net_config_fill() fills the attributions of the vDPA > >>> devices, so that it should call vdpa_dev_net_mq_config_fill() so the > >>> parameter in vdpa_dev_net_mq_config_fill() should be feature_device than > >>> feature_driver for the vDPA devices themselves > >>> > >>> Before this change, when MQ = 0, iproute2 output: > >>> $vdpa dev config show vdpa0 > >>> vdpa0: mac 00:e8:ca:11:be:05 link up link_announce false max_vq_pairs 0 > >>> mtu 1500 > >>> > >>> After applying this commit, when MQ = 0, iproute2 output: > >>> $vdpa dev config show vdpa0 > >>> vdpa0: mac 00:e8:ca:11:be:05 link up link_announce false max_vq_pairs 1 > >>> mtu 1500 > >>> > >> No. We do not want to diverge returning values of config space for fields which are not present as discussed in previous versions. > >> Please drop this patch. > >> Nack on this patch. > > Wrt this patch as far as I'm concerned you guys are bikeshedding. > > > > Parav generally don't send nacks please they are not helpful. > > > > Zhu Lingshan please always address comments in some way. E.g. refer to > > them in the commit log explaining the motivation and the alternatives. > > I know you don't agree with Parav but ghosting isn't nice. > > > > I still feel what we should have done is > > not return a value, as long as we do return it we might > > as well return something reasonable, not 0. > Maybe I missed something but I don't get this, when VIRTIO_NET_F_MQ is > not negotiated, the VDPA_ATTR_DEV_NET_CFG_MAX_VQP attribute is simply > not there, but userspace (iproute) mistakenly puts a zero value there. > This is a pattern every tool in iproute follows consistently by large. I > don't get why kernel has to return something without seeing a very > convincing use case? > > Not to mention spec doesn't give us explicit definition for when the > field in config space becomes valid and/or the default value at first > sights as part of feature negotiation. If we want to stick to the model > Lingshan proposed, maybe fix the spec first then get back on the details? So spec said " The following driver-read-only field, max_virtqueue_pairs only exists if VIRTIO_NET_F_MQ or VIRTIO_NET_F_RSS is set. " My understanding is that the field is always valid if the device offers the feature. Btw, even if the spec is unclear, it would be very hard to "fix" it without introducing a new feature bit, it means we still need to deal with device without the new feature. Thanks > > -Siwei > > > > > And I like it that this fixes sparse warning actually: > > max_virtqueue_pairs it tagged as __virtio, not __le. > > > > However, I am worried there is another bug here: > > this is checking driver features. But really max vqs > > should not depend on that, it depends on device > > features, no? > > > > > > > >>> Signed-off-by: Zhu Lingshan > >>> --- > >>> drivers/vdpa/vdpa.c | 7 ++++--- > >>> 1 file changed, 4 insertions(+), 3 deletions(-) > >>> > >>> diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c index > >>> d76b22b2f7ae..846dd37f3549 100644 > >>> --- a/drivers/vdpa/vdpa.c > >>> +++ b/drivers/vdpa/vdpa.c > >>> @@ -806,9 +806,10 @@ static int vdpa_dev_net_mq_config_fill(struct > >>> vdpa_device *vdev, > >>> u16 val_u16; > >>> > >>> if ((features & BIT_ULL(VIRTIO_NET_F_MQ)) == 0) > >>> - return 0; > >>> + val_u16 = 1; > >>> + else > >>> + val_u16 = __virtio16_to_cpu(true, config- > >>>> max_virtqueue_pairs); > >>> - val_u16 = le16_to_cpu(config->max_virtqueue_pairs); > >>> return nla_put_u16(msg, VDPA_ATTR_DEV_NET_CFG_MAX_VQP, > >>> val_u16); } > >>> > >>> @@ -842,7 +843,7 @@ static int vdpa_dev_net_config_fill(struct > >>> vdpa_device *vdev, struct sk_buff *ms > >>> VDPA_ATTR_PAD)) > >>> return -EMSGSIZE; > >>> > >>> - return vdpa_dev_net_mq_config_fill(vdev, msg, features_driver, > >>> &config); > >>> + return vdpa_dev_net_mq_config_fill(vdev, msg, features_device, > >>> +&config); > >>> } > >>> > >>> static int > >>> -- > >>> 2.31.1 > > _______________________________________________ > > Virtualization mailing list > > Virtualization@lists.linux-foundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/virtualization > > _______________________________________________ > Virtualization mailing list > Virtualization@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/virtualization >