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 B536B4319A for ; Wed, 18 Oct 2023 12:05:37 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AD876411F3; Wed, 18 Oct 2023 12:05:37 +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 17F0940297 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-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-614-p0g0FNfZMPyoVyOnu3S7zw-1; Wed, 18 Oct 2023 06:05:27 -0400 X-MC-Unique: p0g0FNfZMPyoVyOnu3S7zw-1 Received: by mail-lj1-f200.google.com with SMTP id 38308e7fff4ca-2c50cec5d29so43079321fa.2 for ; Wed, 18 Oct 2023 03:05:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697623525; x=1698228325; 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=GXppBx8Ux37vopjhtfqhoevEzCPDlbPJ0sRWEc1IptM7f3ThDaK5+/y5H2As/X7b0y Wh0h9JVwMdVbwOAZNQ0NBnKwsAsw27KFMoa5D8K4xesukmyGDe0l8H/uLPVi3sVUa7G1 3EgVz93B5bivy4YOrVZRX1JgMsRXJNCz0TRr4HIxqKr7/JAW9hDf5XM8MEV192vWLvZB dDdG3MPb7YVr+YirUZMAQVx1VZ+hVSb4fwbuKKWtaSGjccWMvqMu1vk3aV6X3/OINad5 eBx6+x/uVoct1og/dA+hYlRElHDtbkVl5pr8zNs+syNYQ0tai/+yK3TgBtii0BC9yDts b3oQ== X-Gm-Message-State: AOJu0YwytZAdrsrclpQtfrX8FhQYXCBZRxzy/xc1r4gOP7gMbgHEASoY kGGMv6fypsOa4t7vN7EJdWz3Q6I5NKnVIHRMEW8CORdR2jF1J8IGiumzJq8gd4OHWpSkIHumdHr 1mggUn2GYnBLOUyUcYU7ndzA= X-Received: by 2002:a2e:720f:0:b0:2c5:1a8e:e4c9 with SMTP id n15-20020a2e720f000000b002c51a8ee4c9mr3355885ljc.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: 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 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