Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp48000ioo; Fri, 20 May 2022 13:35:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyrUr7uqT04WOcR+a5vJqGzVqc7dw2jdULr1fO8CD5un1XGOFfdrHD+vYBQv4T0PmVx99d8 X-Received: by 2002:a62:d045:0:b0:518:404d:9dc8 with SMTP id p66-20020a62d045000000b00518404d9dc8mr10177694pfg.60.1653078938792; Fri, 20 May 2022 13:35:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653078938; cv=none; d=google.com; s=arc-20160816; b=Bz0zJx1tneS9HAIR4mvMZCIb6BN3scaZIDZT311cDVSayW5TBp/6hGlF34Im6+flGj 2RfH/6WMKTfzAuIHy/g5cRpOJYpExntucqdfMPkLy8jI3QCc4h4JtSYHyR3Zlwm4lABk Cx7lBz3kPfb/UzsCbC8CyipaR4qvQ4mCiRTqjwkrA2L29KgprXLkoJVwZ+L7k58zKGBg PgjSO08zt88AE2VO7zEDVUC/GGR0UgtP5oj6XMsXjEgECtynRj6lq807eg85VAOFOGhJ Oa2g5WhK+jCcUCZLl4CcSHCRwSkPbS8DrH7z4vvU+IloTWZcFysvTcabO7UzDR/wh1GX /qZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=vxIfyueKTwi8me9odGJZHdVY8aeJtK9bNyPeP1e4+B0=; b=WAyI3PnqXp9Xumpyn6NpeRzlaXRGk2NBa9TT/adMi70yQaSlPQgsnL3/wr0KuoWg8u SxQyafG9Yv+xZNYUjySRWMTqXGm/lpJ6eG139OPbYTxI1E0lLWxhDqSBadwsh2JeA3jl 5WEiBY9fIFuHeBTIUMWZCljwyFqtbreSiYuuLq+LK55BdhBTBIadTtoRYoxswZNiFT07 ZQMWj5Dt8C2ENgWXtB/CLKZCCpoDoZM9lEEbMzHvY9HsxHMkf8bHd30HYGE4OzLmeugl eRcyleNwOh23XAlvwNcF2E/SHdfMdzlKs8WXtLCYACN29OCD2pTy3Q3pLN4lg7YX/qat nwfQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=R83s1U+U; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a17-20020a170902ee9100b0016180e07230si581338pld.459.2022.05.20.13.35.24; Fri, 20 May 2022 13:35:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=R83s1U+U; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S239222AbiETIEs (ORCPT + 99 others); Fri, 20 May 2022 04:04:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43870 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239114AbiETIEo (ORCPT ); Fri, 20 May 2022 04:04:44 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 06EDB14D7A4 for ; Fri, 20 May 2022 01:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1653033882; 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=vxIfyueKTwi8me9odGJZHdVY8aeJtK9bNyPeP1e4+B0=; b=R83s1U+UpR7bBIxnV6fg+evdB9SOA5tFhaowQN5dkkVACD6gZ2/QGYtqtMjyhJ261vBcqG /Hvq+nqM1TL7cDeJRHhV8SnB1qcy/nq5bNzr5Qjhc1gZbR/qf2fJB+19WWd5LPXRvLJhiq e3qXj0XIyGZb2IZIml2nC+M1PZGelco= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-609-BxkzoncIP8eB1SJBhhR0ug-1; Fri, 20 May 2022 04:04:40 -0400 X-MC-Unique: BxkzoncIP8eB1SJBhhR0ug-1 Received: by mail-qv1-f71.google.com with SMTP id ck16-20020a05621404d000b00461bcafbbe9so6118265qvb.23 for ; Fri, 20 May 2022 01:04:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=vxIfyueKTwi8me9odGJZHdVY8aeJtK9bNyPeP1e4+B0=; b=bA4dhLtnn9HqzbQJ/2X9CbvfdJQqWW1WX0Tg/j5GtxUWiardtJH/0WFTX2jcsiEYhA byIXL3nl3pMisq8l9DP0zYksZL9rdk9RtAKi8VDhzlHoAflho3cc2k56Q5vrlPVegCEv oFE9XXJaVzOcYZVkw02rHvswsHN8k5TQfDO/+tsG+obsD3q+66EvijiQQV9WNRfNRc4P vn09AAHWGfrhTFjztRk2IPYvEvaSqtPlxNvGoQSpk6B90xPgWiYPDYGqjCGcEMCwU1hH YUeQdUtRx7BoFXBwHGdxjhAC/XCAZbnFEhDCSm+q38Q5j1F+nRu7cBNmku1qsL0dHRMZ 51UA== X-Gm-Message-State: AOAM5322lwzobjPefkDwohAXSJsQgVK1+Aei7usBYOwoMUeq5YA4bUwe gVqVmd10Kv6h7gFxq/I3JS8YFlAvTELunQjA8ioRi4M7oWhXRCkhm2K/HB1G1s5yUwALy7tMocW oDZcr5OujF9CN4SSimiRP/TED4okvjg/Zf92g8xPu X-Received: by 2002:a05:622a:110c:b0:2f3:d347:6f8d with SMTP id e12-20020a05622a110c00b002f3d3476f8dmr6667359qty.403.1653033879835; Fri, 20 May 2022 01:04:39 -0700 (PDT) X-Received: by 2002:a05:622a:110c:b0:2f3:d347:6f8d with SMTP id e12-20020a05622a110c00b002f3d3476f8dmr6667325qty.403.1653033879554; Fri, 20 May 2022 01:04:39 -0700 (PDT) MIME-Version: 1.0 References: <20220330180436.24644-1-gdawar@xilinx.com> In-Reply-To: <20220330180436.24644-1-gdawar@xilinx.com> From: Eugenio Perez Martin Date: Fri, 20 May 2022 10:04:03 +0200 Message-ID: Subject: Re: [PATCH v2 00/19] Control VQ support in vDPA To: Gautam Dawar Cc: "Michael S. Tsirkin" , Jason Wang , kvm list , virtualization , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Martin Petrus Hubertus Habets , Harpreet Singh Anand , martinpo@xilinx.com, pabloc@xilinx.com, dinang@xilinx.com, tanuj.kamde@amd.com, habetsm.xilinx@gmail.com, ecree.xilinx@gmail.com, Gautam Dawar , Wu Zongyong , Christophe JAILLET , Eli Cohen , Zhu Lingshan , Stefano Garzarella , Xie Yongji , Si-Wei Liu , Parav Pandit , Longpeng , Dan Carpenter , Zhang Min Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 30, 2022 at 8:05 PM Gautam Dawar wrot= e: > > Hi All: > > This series tries to add the support for control virtqueue in vDPA. > > Control virtqueue is used by networking device for accepting various > commands from the driver. It's a must to support multiqueue and other > configurations. > > When used by vhost-vDPA bus driver for VM, the control virtqueue > should be shadowed via userspace VMM (Qemu) instead of being assigned > directly to Guest. This is because Qemu needs to know the device state > in order to start and stop device correctly (e.g for Live Migration). > > This requies to isolate the memory mapping for control virtqueue > presented by vhost-vDPA to prevent guest from accessing it directly. > > To achieve this, vDPA introduce two new abstractions: > > - address space: identified through address space id (ASID) and a set > of memory mapping in maintained > - virtqueue group: the minimal set of virtqueues that must share an > address space > > Device needs to advertise the following attributes to vDPA: > > - the number of address spaces supported in the device > - the number of virtqueue groups supported in the device > - the mappings from a specific virtqueue to its virtqueue groups > > The mappings from virtqueue to virtqueue groups is fixed and defined > by vDPA device driver. E.g: > > - For the device that has hardware ASID support, it can simply > advertise a per virtqueue group. > - For the device that does not have hardware ASID support, it can > simply advertise a single virtqueue group that contains all > virtqueues. Or if it wants a software emulated control virtqueue, it > can advertise two virtqueue groups, one is for cvq, another is for > the rest virtqueues. > > vDPA also allow to change the association between virtqueue group and > address space. So in the case of control virtqueue, userspace > VMM(Qemu) may use a dedicated address space for the control virtqueue > group to isolate the memory mapping. > > The vhost/vhost-vDPA is also extend for the userspace to: > > - query the number of virtqueue groups and address spaces supported by > the device > - query the virtqueue group for a specific virtqueue > - assocaite a virtqueue group with an address space > - send ASID based IOTLB commands > > This will help userspace VMM(Qemu) to detect whether the control vq > could be supported and isolate memory mappings of control virtqueue > from the others. > > To demonstrate the usage, vDPA simulator is extended to support > setting MAC address via a emulated control virtqueue. > > Please review. > > Changes since RFC v2: > > - Fixed memory leak for asid 0 in vhost_vdpa_remove_as() > - Removed unnecessary NULL check for iotlb in vhost_vdpa_unmap() and > changed its return type to void. > - Removed insignificant used_as member field from struct vhost_vdpa. > - Corrected the iommu parameter in call to vringh_set_iotlb() from > vdpasim_set_group_asid() > - Fixed build errors with vdpa_sim_net > - Updated alibaba, vdpa_user and virtio_pci vdpa parent drivers to > call updated vDPA APIs and ensured successful build > - Tested control (MAC address configuration) and data-path using > single virtqueue pair on Xilinx (now AMD) SN1022 SmartNIC device > and vdpa_sim_net software device using QEMU release at [1] > - Removed two extra blank lines after set_group_asid() in > include/linux/vdpa.h > > Changes since v1: > > - Rebased the v1 patch series on vhost branch of MST vhost git repo > git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git/log/?h=3Dvhost > - Updates to accommodate vdpa_sim changes from monolithic module in > kernel used v1 patch series to current modularized class (net, block) > based approach. > - Added new attributes (ngroups and nas) to "vdpasim_dev_attr" and > propagated them from vdpa_sim_net to vdpa_sim > - Widened the data-type for "asid" member of vhost_msg_v2 to __u32 > to accommodate PASID > - Fixed the buildbot warnings > - Resolved all checkpatch.pl errors and warnings > - Tested both control and datapath with Xilinx Smartnic SN1000 series > device using QEMU implementing the Shadow virtqueue and support for > VQ groups and ASID available at [1] > > Changes since RFC: > > - tweak vhost uAPI documentation > - switch to use device specific IOTLB really in patch 4 > - tweak the commit log > - fix that ASID in vhost is claimed to be 32 actually but 16bit > actually > - fix use after free when using ASID with IOTLB batching requests > - switch to use Stefano's patch for having separated iov > - remove unused "used_as" variable > - fix the iotlb/asid checking in vhost_vdpa_unmap() > > [1] Development QEMU release with support for SVQ, VQ groups and ASID: > github.com/eugpermar/qemu/releases/tag/vdpa_sw_live_migration.d%2F > asid_groups-v1.d%2F00 > > Thanks > > Gautam Dawar (19): > vhost: move the backend feature bits to vhost_types.h > virtio-vdpa: don't set callback if virtio doesn't need it > vhost-vdpa: passing iotlb to IOMMU mapping helpers > vhost-vdpa: switch to use vhost-vdpa specific IOTLB > vdpa: introduce virtqueue groups > vdpa: multiple address spaces support > vdpa: introduce config operations for associating ASID to a virtqueue > group > vhost_iotlb: split out IOTLB initialization > vhost: support ASID in IOTLB API > vhost-vdpa: introduce asid based IOTLB > vhost-vdpa: introduce uAPI to get the number of virtqueue groups > vhost-vdpa: introduce uAPI to get the number of address spaces > vhost-vdpa: uAPI to get virtqueue group id > vhost-vdpa: introduce uAPI to set group ASID > vhost-vdpa: support ASID based IOTLB API > vdpa_sim: advertise VIRTIO_NET_F_MTU > vdpa_sim: factor out buffer completion logic > vdpa_sim: filter destination mac address > vdpasim: control virtqueue support > > drivers/vdpa/alibaba/eni_vdpa.c | 2 +- > drivers/vdpa/ifcvf/ifcvf_main.c | 8 +- > drivers/vdpa/mlx5/net/mlx5_vnet.c | 11 +- > drivers/vdpa/vdpa.c | 5 + > drivers/vdpa/vdpa_sim/vdpa_sim.c | 100 ++++++++-- > drivers/vdpa/vdpa_sim/vdpa_sim.h | 3 + > drivers/vdpa/vdpa_sim/vdpa_sim_net.c | 169 +++++++++++++---- > drivers/vdpa/vdpa_user/vduse_dev.c | 3 +- > drivers/vdpa/virtio_pci/vp_vdpa.c | 2 +- > drivers/vhost/iotlb.c | 23 ++- > drivers/vhost/vdpa.c | 267 +++++++++++++++++++++------ > drivers/vhost/vhost.c | 23 ++- > drivers/vhost/vhost.h | 4 +- > drivers/virtio/virtio_vdpa.c | 2 +- > include/linux/vdpa.h | 44 ++++- > include/linux/vhost_iotlb.h | 2 + > include/uapi/linux/vhost.h | 26 ++- > include/uapi/linux/vhost_types.h | 11 +- > 18 files changed, 563 insertions(+), 142 deletions(-) > Hoping it's not too late for this, but I tested this series with my latest qemu CVQ SVQ RFC (v8). So, in that regard, Reviewed-by: Eugenio P=C3=A9rez