From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 931BE10A3; Sat, 19 Jan 2019 04:23:20 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2019 19:23:19 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,493,1539673200"; d="scan'208";a="311689809" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga006.fm.intel.com with ESMTP; 18 Jan 2019 19:23:19 -0800 Received: from fmsmsx111.amr.corp.intel.com (10.18.116.5) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 18 Jan 2019 19:23:19 -0800 Received: from shsmsx107.ccr.corp.intel.com (10.239.4.96) by fmsmsx111.amr.corp.intel.com (10.18.116.5) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 18 Jan 2019 19:23:18 -0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.196]) by SHSMSX107.ccr.corp.intel.com ([169.254.9.239]) with mapi id 14.03.0415.000; Sat, 19 Jan 2019 11:23:16 +0800 From: "Wang, Xiao W" To: "Burakov, Anatoly" , "dev@dpdk.org" CC: "Zhang, Qi Z" , "qingfu.cqf@alibaba-inc.com" , "thomas@monjalon.net" , "Stojaczyk, Dariusz" , "stable@dpdk.org" Thread-Topic: [PATCH v2] vfio: allow secondary process to query IOMMU type Thread-Index: AQHUrxgfRPOHmM8YVkS7yKxYtbUjYKW17L7w Date: Sat, 19 Jan 2019 03:23:14 +0000 Message-ID: References: <2101fda2f9030723c662419ec9b4a33d2dc7aded.1547807046.git.anatoly.burakov@intel.com> In-Reply-To: <2101fda2f9030723c662419ec9b4a33d2dc7aded.1547807046.git.anatoly.burakov@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNTVjZmVhYmYtZTk3OC00ZDdiLWE4MDItYzViY2EyYzg5MmFhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoib3YwVm5hNDBmRnJlT1ZGT1VTMlZEUVRwMHl4OHdnME56UDVPY3lUUzdEVEhFSG41MWpUcStFenFLbm93RDFaViJ9 dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2] vfio: allow secondary process to query IOMMU type X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2019 03:23:21 -0000 Hi Anatoly, > -----Original Message----- > From: Burakov, Anatoly > Sent: Friday, January 18, 2019 6:25 PM > To: dev@dpdk.org > Cc: Wang, Xiao W ; Zhang, Qi Z > ; qingfu.cqf@alibaba-inc.com; thomas@monjalon.net; > Stojaczyk, Dariusz ; stable@dpdk.org > Subject: [PATCH v2] vfio: allow secondary process to query IOMMU type >=20 > It is only possible to know IOMMU type of a given VFIO container > by attempting to initialize it. Since secondary process never > attempts to set up VFIO container itself (because they're shared > between primary and secondary), it never knows which IOMMU type > the container is using, and never sets up the appropriate config > structures. This results in inability to perform DMA mappings in > secondary process. >=20 > Fix this by allowing secondary process to query IOMMU type of > primary's default container at device initialization. >=20 > Note that this fix is assuming we're only interested in default > container. >=20 > Bugzilla ID: 174 >=20 > Fixes: 6bcb7c95fe14 ("vfio: share default container in multi-process") > Cc: dariusz.stojaczyk@intel.com > Cc: stable@dpdk.org >=20 > Signed-off-by: Anatoly Burakov > --- >=20 > Notes: > v2: > - Check if we found our IOMMU type within list of IOMMU types > - Don't request new default container fd as this should have > been done during rte_vfio_enable() >=20 > lib/librte_eal/linuxapp/eal/eal_vfio.c | 88 +++++++++++++++++++ > lib/librte_eal/linuxapp/eal/eal_vfio.h | 12 ++- > .../linuxapp/eal/eal_vfio_mp_sync.c | 16 ++++ > 3 files changed, 115 insertions(+), 1 deletion(-) >=20 > diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.c > b/lib/librte_eal/linuxapp/eal/eal_vfio.c > index 72cc65151..c821e8382 100644 > --- a/lib/librte_eal/linuxapp/eal/eal_vfio.c > +++ b/lib/librte_eal/linuxapp/eal/eal_vfio.c > @@ -549,6 +549,65 @@ vfio_mem_event_callback(enum rte_mem_event > type, const void *addr, size_t len, > } > } >=20 > +static int > +vfio_sync_default_container(void) > +{ > + struct rte_mp_msg mp_req, *mp_rep; > + struct rte_mp_reply mp_reply; > + struct timespec ts =3D {.tv_sec =3D 5, .tv_nsec =3D 0}; > + struct vfio_mp_param *p =3D (struct vfio_mp_param *)mp_req.param; > + int iommu_type_id; > + unsigned int i; > + > + /* cannot be called from primary */ > + if (rte_eal_process_type() !=3D RTE_PROC_SECONDARY) > + return -1; > + > + /* default container fd should have been opened in rte_vfio_enable() > */ > + if (!default_vfio_cfg->vfio_enabled || > + default_vfio_cfg->vfio_container_fd < 0) { > + RTE_LOG(ERR, EAL, "VFIO support is not initialized\n"); > + return -1; > + } > + > + /* find default container's IOMMU type */ > + p->req =3D SOCKET_REQ_IOMMU_TYPE; Since this function is to sync IOMMU type for the default container, should= we make the req type as SOCKET_REQ_DEFAULT_IOMMU_TYPE? BRs, Xiao