From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id F3F4E426AE; Tue, 3 Oct 2023 12:21:18 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A7BA1402E2; Tue, 3 Oct 2023 12:21:18 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id 8A9E0402A2 for ; Tue, 3 Oct 2023 12:21:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1696328476; 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=NwqjjCccIyxbrGlaH98KakBKu1DAGR2XNJztmcipC44=; b=f6+YtoLcOUaxgQNpTtq2UNsAL1hSR4LemuAiBn6GQV32nj2ehwg5kA9Pv9XO4NrSKYxi/u EPv2O4WRNuotCGAf0IKmNxnZ3RC37GPFnd+w+IwPo4+WUk9ejfX233YBndMXPXpdhskeBv sJ+c2U15meUA+eOWz6J0TiADVPvN5BU= Received: from mail-lj1-f200.google.com (mail-lj1-f200.google.com [209.85.208.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-147-vInaglrxPrmLaHGLPZhVVw-1; Tue, 03 Oct 2023 06:21:14 -0400 X-MC-Unique: vInaglrxPrmLaHGLPZhVVw-1 Received: by mail-lj1-f200.google.com with SMTP id 38308e7fff4ca-2b710c5677eso6992251fa.0 for ; Tue, 03 Oct 2023 03:21:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696328473; x=1696933273; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=NwqjjCccIyxbrGlaH98KakBKu1DAGR2XNJztmcipC44=; b=c1x5+VsBBLeraPEyougYwthKmnFtm//7gwHmS7S0vBer8bqvlVWkWLuGtTr/07/ItR pzehYurSApY9aQDLvOk6kkg9c/3HeKg5eSNJLdz3w3EM2swFsKz6hrZgaWsJ6CWQ1MwR OquFnRjM7Nx5afBDnsBTzjQtrALo1+2VXETZdJQYNrAm0B+CwZLPyCjUY95wjKUxvsTe Jmb4Kt/+au95F4CdwNsWQ0fc4T9Nptj5HE+j5/vY9XAUo/JErkgYbAwFzsiTvuCVqixR emuap5JefZPOXzjzW8lzQSEk+MrzseIF5yqyuEZIL5DrGWtfVd8pJxTVMlEmqWJo+pB9 ziCQ== X-Gm-Message-State: AOJu0YzeHrCbeXoYXoVXxlZ9r3sSOQSj/EN1qoxwUKZp9MkzesQCcEiP SitTuxua9S3cwqTBlbS1b16mFWD0NhFwiZptTu5BDeTlqeBhPXkgW+A0prGthitx52nGnPI5vqV 6mH0nSpwC0vlQ6ilPs5U= X-Received: by 2002:a2e:9f44:0:b0:2bd:180d:67b1 with SMTP id v4-20020a2e9f44000000b002bd180d67b1mr11621250ljk.51.1696328473224; Tue, 03 Oct 2023 03:21:13 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGUy7IqvuwgsbL8ds3kwlWy1OUt9ZzX4mEbHQ4R4iLZSrEDPPqpHzidFGkKzNild/e/gdfdU90FZ8/sI5y4occ= X-Received: by 2002:a2e:9f44:0:b0:2bd:180d:67b1 with SMTP id v4-20020a2e9f44000000b002bd180d67b1mr11621235ljk.51.1696328472858; Tue, 03 Oct 2023 03:21:12 -0700 (PDT) MIME-Version: 1.0 References: <20230807015820.1329972-1-wenwux.ma@intel.com> <20230830050713.58247-1-wenwux.ma@intel.com> In-Reply-To: <20230830050713.58247-1-wenwux.ma@intel.com> From: David Marchand Date: Tue, 3 Oct 2023 12:21:01 +0200 Message-ID: Subject: Re: [PATCH v4] bus/pci: fix legacy device IO port map in secondary process To: Wenwu Ma , nipun.gupta@amd.com, chenbo.xia@outlook.com Cc: dev@dpdk.org, maxime.coquelin@redhat.com, miao.li@intel.com, weix.ling@intel.com, stable@dpdk.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Wed, Aug 30, 2023 at 7:07=E2=80=AFAM Wenwu Ma wrot= e: > > When doing IO port mapping for legacy device in secondary process, the > region information is missing, so, we need to refill it. > > Fixes: 4b741542ecde ("bus/pci: avoid depending on private kernel value") > Cc: stable@dpdk.org > > Signed-off-by: Wenwu Ma > > --- > drivers/bus/pci/linux/pci_vfio.c | 43 ++++++++++++++++++++++++++++++-- > 1 file changed, 41 insertions(+), 2 deletions(-) > > diff --git a/drivers/bus/pci/linux/pci_vfio.c b/drivers/bus/pci/linux/pci= _vfio.c > index e634de8322..5ef26c98d1 100644 > --- a/drivers/bus/pci/linux/pci_vfio.c > +++ b/drivers/bus/pci/linux/pci_vfio.c > @@ -1314,6 +1314,27 @@ pci_vfio_ioport_map(struct rte_pci_device *dev, in= t bar, > return -1; > } > > + if (rte_eal_process_type() =3D=3D RTE_PROC_SECONDARY) { > + struct vfio_device_info device_info =3D { .argsz =3D size= of(device_info) }; > + char pci_addr[PATH_MAX]; > + int vfio_dev_fd; > + struct rte_pci_addr *loc =3D &dev->addr; > + int ret; > + /* store PCI address string */ > + snprintf(pci_addr, sizeof(pci_addr), PCI_PRI_FMT, > + loc->domain, loc->bus, loc->devid, loc->f= unction); > + > + ret =3D rte_vfio_setup_device(rte_pci_get_sysfs_path(), p= ci_addr, > + &vfio_dev_fd, &device_inf= o); >From a pci bus API pov, nothing prevents a driver from mixing memory mapped with vfio and ioport resources (iow, calls to rte_pci_map_resource() and rte_pci_ioport_map()). IOW, it may not be the case with the net/virtio driver but, in theory, rte_pci_ioport_map()/pci_vfio_ioport_map() may be called after a rte_pci_map_resource() call. In a similar manner, from the API pov, rte_pci_ioport_map()/pci_vfio_ioport_map() may be called for multiple bars. In summary, nothing in this patch checks that vfio has been configured already and I think we need a refcount to handle those situations. Nipun, Chenbo, WDYT? > + if (ret) > + return -1; ret value is not used, so there is no need for this variable. if (rte_vfio_setup_device(rte_pci_get_sysfs_path(), pci_addr, &vfio_dev_fd, &device_info) !=3D 0) return -1; > + > + ret =3D pci_vfio_fill_regions(dev, vfio_dev_fd, &device_i= nfo); > + if (ret) > + return -1; Same here, ret is not needed. > + > + } > + > if (pci_vfio_get_region(dev, bar, &size, &offset) !=3D 0) { > RTE_LOG(ERR, EAL, "Cannot get offset of region %d.\n", ba= r); > return -1; > @@ -1361,8 +1382,26 @@ pci_vfio_ioport_write(struct rte_pci_ioport *p, > int > pci_vfio_ioport_unmap(struct rte_pci_ioport *p) > { > - RTE_SET_USED(p); > - return -1; > + char pci_addr[PATH_MAX] =3D {0}; > + struct rte_pci_addr *loc =3D &p->dev->addr; > + int ret, vfio_dev_fd; > + > + /* store PCI address string */ > + snprintf(pci_addr, sizeof(pci_addr), PCI_PRI_FMT, > + loc->domain, loc->bus, loc->devid, loc->function)= ; > + > + vfio_dev_fd =3D rte_intr_dev_fd_get(p->dev->intr_handle); > + if (vfio_dev_fd < 0) > + return -1; This check is odd and does not seem related. > + > + ret =3D rte_vfio_release_device(rte_pci_get_sysfs_path(), pci_add= r, > + vfio_dev_fd); > + if (ret < 0) { > + RTE_LOG(ERR, EAL, "Cannot release VFIO device\n"); > + return ret; > + } --=20 David Marchand