Re: [dpdk-dev] [PATCH v6 2/2] vhost: enable IOMMU for async vhost
From: Burakov, Anatoly <hidden>
Date: 2021-09-29 09:39:26
On 29-Sep-21 7:12 AM, Hu, Jiayu wrote:
Hi Xuan,quoted
-----Original Message----- From: Ding, Xuan <redacted> Sent: Wednesday, September 29, 2021 10:41 AM To: dev@dpdk.org; Burakov, Anatoly <redacted>; maxime.coquelin@redhat.com; Xia, Chenbo [off-list ref] Cc: Hu, Jiayu <redacted>; Jiang, Cheng1 <redacted>; Richardson, Bruce [off-list ref]; Pai G, Sunil [off-list ref]; Wang, Yinan [off-list ref]; Yang, YvonneX [off-list ref]; Ding, Xuan [off-list ref] Subject: [PATCH v6 2/2] vhost: enable IOMMU for async vhost The use of IOMMU has many advantages, such as isolation and address translation. This patch extends the capbility of DMA engine to use IOMMU if the DMA engine is bound to vfio. When set memory table, the guest memory will be mapped into the default container of DPDK. Signed-off-by: Xuan Ding <redacted> --- +async_dma_map(struct rte_vhost_mem_region *region, bool +*dma_map_success, bool do_map) { +uint64_t host_iova; +int ret = 0; + +host_iova = rte_mem_virt2iova((void *)(uintptr_t)region-quoted
host_user_addr);+if (do_map) { +/* Add mapped region into the default container of DPDK. */ +ret = rte_vfio_container_dma_map(RTE_VFIO_DEFAULT_CONTAINER_FD, + region->host_user_addr, + host_iova, + region->size); +*dma_map_success = ret == 0; + +if (ret) { +/* + * DMA device may bind with kernel driver, in this case, + * we don't need to program IOMMU manually. However, if no + * device is bound with vfio/uio in DPDK, and vfio kernel + * module is loaded, the API will still be called and return + * with ENODEV/ENOSUP. + * + * DPDK vfio only returns ENODEV/ENOSUP in very similar + * situations(vfio either unsupported, or supported + * but no devices found). Either way, no mappings could be + * performed. We treat it as normal case in async path. + */What do you mean by saying "vfio either unsupported"? Does it mean platform doesn't support iommu?
Unsupported as in the VFIO driver is not loaded. We don't really care if the *system* supports VFIO as much as whether it's *accessible to us*. I'm sure you would agree that scenario "VFIO is not supported" is exactly equivalent to "VFIO driver is not loaded", because from our perspective, in both cases the VFIO driver is not loaded :)
Thanks, Jiayu
-- Thanks, Anatoly