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 EBE1343199; Wed, 18 Oct 2023 12:05:36 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 861AE410DD; Wed, 18 Oct 2023 12:05:36 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 1205040151 for ; Wed, 18 Oct 2023 12:05:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1697623528; 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=c+09sUa11VUVY3Ytdah7H4aKvSkcL48cbThP+UyABhU=; b=hAmEKDCC+iMz4+VvQ42wWcW6ECwUhF+SO0xnYGi+HE38Fwod2JjiGvdvBzSatMD6H5kNOV mdi3xvyHFTA9QGWB5HPV73mVQgUKGudatL+Ju9ONw1iBg9hdvpxx5BHjdwK9U4X4ZqCbWW 5IauuEpHRUWtsezRIb3z8IFiwOSSbCI= 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_256_GCM_SHA384) id us-mta-614-sVZiwsjgNoetJGSIZc8ydA-1; Wed, 18 Oct 2023 06:05:27 -0400 X-MC-Unique: sVZiwsjgNoetJGSIZc8ydA-1 Received: by mail-lj1-f198.google.com with SMTP id 38308e7fff4ca-2c50cec5d29so43079341fa.2 for ; Wed, 18 Oct 2023 03:05:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697623526; x=1698228326; 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=c+09sUa11VUVY3Ytdah7H4aKvSkcL48cbThP+UyABhU=; b=n9b6Az0Ln1UZOki1XaXOLXzg4Mg6KOy1aha1WEvL/MItM44XLcVNgttXVbIkVJ0Vdl b83C3KhuHeDgXi3epl6MbPUQjITFwx5JjW/PfWrqq9CjrUHVW9BI8qkuiO+pFU8Sq1o3 huXSNCnbxndyHFhL9Plnr/511DbOGRQTYBnprbPTDI1NpJw4ZucshVruCkU07E1mgfVJ QsEPkvpGRNiiNASjfWdjt08DWKLtK1fc1yeMv6q+MozigAxWbks6oM9FUt0Z3l8A37lQ 6vacFvHrAuy0VcjOJJdmF0m20hFN427KyTdOqzyEVB0fUcxMneB/wZrEFaAVg0c3CJG8 jLKA== X-Gm-Message-State: AOJu0YxKH3pf2+IzSyHq/ATt2LVQ2bOKKjaFRSuEYBuS/+723MjEqwvw sReURfMlxrsZjJrFtMhN8u3xHGZggE28zZLiQuoX565FyrboyB8sebA5YYR2o4BkaEZK/j4ntZQ bCJWSj4YM4eRNTJkPKdQ= X-Received: by 2002:a2e:720f:0:b0:2c5:1a8e:e4c9 with SMTP id n15-20020a2e720f000000b002c51a8ee4c9mr3355884ljc.31.1697623525813; Wed, 18 Oct 2023 03:05:25 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGzR/77GGbIj7rP7Pe7xExVpl+q6ISlFNLuLSytaxYIn/jS6lpuzMRLKPwLKDaXN2CgkIuJO52OX7P8B9AgRSs= X-Received: by 2002:a2e:720f:0:b0:2c5:1a8e:e4c9 with SMTP id n15-20020a2e720f000000b002c51a8ee4c9mr3355861ljc.31.1697623525361; Wed, 18 Oct 2023 03:05:25 -0700 (PDT) MIME-Version: 1.0 References: <20230807015820.1329972-1-wenwux.ma@intel.com> <20230830050713.58247-1-wenwux.ma@intel.com> In-Reply-To: From: David Marchand Date: Wed, 18 Oct 2023 12:05:14 +0200 Message-ID: Subject: Re: [PATCH v4] bus/pci: fix legacy device IO port map in secondary process To: "Ma, WenwuX" , "nipun.gupta@amd.com" , "chenbo.xia@outlook.com" Cc: "dev@dpdk.org" , "maxime.coquelin@redhat.com" , "Li, Miao" , "Ling, WeiX" , "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 Mon, Oct 9, 2023 at 5:06=E2=80=AFAM Ma, WenwuX wro= te: > > 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 b= ars. > > > > In summary, nothing in this patch checks that vfio has been configured = already > > and I think we need a refcount to handle those situations. > > > We call rte_vfio_setup_device just to get device info, we can call rte_vf= io_release_device as soon as pci_vfio_fill_regions is done. > This avoids reference counting operations, do you think it works? Afaics, rte_vfio_setup_device should not be called if a call to rte_pci_map_device for this device was successful (rte_pci_map_device itself calls rte_vfio_setup_device). And as a consequence, calling rte_vfio_release_device cannot be done unconditionnally neither. --=20 David Marchand