From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 18C47F72; Fri, 18 Jan 2019 11:13:30 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2019 02:13:29 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,489,1539673200"; d="scan'208";a="128818816" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.252.12.136]) ([10.252.12.136]) by orsmga001.jf.intel.com with ESMTP; 18 Jan 2019 02:13:27 -0800 To: dev@dpdk.org Cc: xiao.w.wang@intel.com, qi.z.zhang@intel.com, qingfu.cqf@alibaba-inc.com, thomas@monjalon.net, dariusz.stojaczyk@intel.com, stable@dpdk.org References: From: "Burakov, Anatoly" Message-ID: <41bd99e2-d02e-eb6c-8489-13fa07b555ea@intel.com> Date: Fri, 18 Jan 2019 10:13:26 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] 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: Fri, 18 Jan 2019 10:13:31 -0000 On 17-Jan-19 5:30 PM, Anatoly Burakov wrote: > 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. > > Fix this by allowing secondary process to query IOMMU type of > primary's default container at device initialization. > > Note that this fix is assuming we're only interested in default > container. > > Bugzilla ID: 174 > > Fixes: 6bcb7c95fe14 ("vfio: share default container in multi-process") > Cc: dariusz.stojaczyk@intel.com > Cc: stable@dpdk.org > > Signed-off-by: Anatoly Burakov > --- <...> > + /* we now have an fd for default container, as well as its IOMMU type. > + * now, set up default VFIO container config to match. > + */ > + for (i = 0; i < RTE_DIM(iommu_types); i++) { > + const struct vfio_iommu_type *t = &iommu_types[i]; > + if (t->type_id != iommu_type_id) > + continue; > + > + /* we found our IOMMU type */ > + default_vfio_cfg->vfio_enabled = 1; > + default_vfio_cfg->vfio_container_fd = vfio_container_fd; > + default_vfio_cfg->vfio_iommu_type = t; > + break; > + } Self-review: if IOMMU type wasn't found, we still return 0. Will fix in v2. > + > + return 0; > +} > + > int > rte_vfio_clear_group(int vfio_group_fd) > { > @@ -745,6 +805,26 @@ rte_vfio_setup_device(const char *sysfs_base, const char *dev_addr, > else > RTE_LOG(DEBUG, EAL, "Installed memory event callback for VFIO\n"); -- Thanks, Anatoly