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 997C7426AE for ; Tue, 3 Oct 2023 12:21:17 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 752AA402A2; Tue, 3 Oct 2023 12:21:17 +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 66A4B4026B 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=1696328475; 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=OD8ZDAawVS0woqOZQeQ/qiwKZG05mlJeNRMKFRzMvkoTMHXQw8SmhcE9/ceXlruTdDEuDJ 6emVjyIHmYDbQXQz8fZe1GPok1beCPjF+I3E88gLxOXQFfvr6YGCPRjMHckTfYfHS4lbqL znAyCbmxlsxFtewYxv3MfQPK/3KWbpI= 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-593-Q16HaREiNfWWUxHq9BvD9A-1; Tue, 03 Oct 2023 06:21:14 -0400 X-MC-Unique: Q16HaREiNfWWUxHq9BvD9A-1 Received: by mail-lj1-f200.google.com with SMTP id 38308e7fff4ca-2c296e6501eso6903291fa.1 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=t15SZZPhQmh9fN8clzBv9WkAJf7Z977BPdh1TgWod9LPjXjt6QYnE22ffccKZTjWXb oxqDmJgLbc/wQHYSmlbZejdban2ytmNb2q1Ge3OqorkeeeCp8tEz4A2lcqMwPFDDBM87 mdlBWVyHZGf4nErfLJlj7DFTLMRLmXuVezvo39+ES1XlyJ0+yCUulQ1lS3yOkwKmSkua 64XTPGrKQPYcfwZk30z042+MWB4VX2TcWskxfNUKZq2plmjY2GJvlcQT4mR+LBBMbpF8 BTMSLpYqKY1eClQWbd9bl3hXYAo8cbrltVHT5aewZlcmjiX5cREtz1Bb/P8mb/kJ/fMs 7DwA== X-Gm-Message-State: AOJu0YyMANFZhfMksApLsiSkTsCHKcKKw/117lK8b+pcA3t7/aDMksgM rtyUmZXJxt8LD8Jg/DCjv3kNzdMpGUDjXgcCrC84u5BJP9fVNR4dwQpcFWg3YnGQzcsH7N16bdG Jo8AUycj5CrcgdS+4HBxYNFg= X-Received: by 2002:a2e:9f44:0:b0:2bd:180d:67b1 with SMTP id v4-20020a2e9f44000000b002bd180d67b1mr11621252ljk.51.1696328473226; 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: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-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