From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by smtp.lore.kernel.org (Postfix) with ESMTP id 14C9EE7C6E2 for ; Sat, 31 Jan 2026 20:14:01 +0000 (UTC) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D983D402AF; Sat, 31 Jan 2026 21:14:00 +0100 (CET) Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by mails.dpdk.org (Postfix) with ESMTP id 714D140274 for ; Sat, 31 Jan 2026 21:13:59 +0100 (CET) Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4806fbc6bf3so33574585e9.2 for ; Sat, 31 Jan 2026 12:13:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1769890439; x=1770495239; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=S0LcUKGhisOvXPcgAGjHu2gPdTtvHtYgAbPuJM0DSxQ=; b=YE5FgR69Mg/s+WapmxUzJW9NeH4bDuQlUnLfizqs/JGGZvKTUWph66ULInZ5BXQbXF i648gDJ+5VuUJrnpsjRG6AyUYipLLPEf+Gk2pwqlzIJQEUhyxCauIAfKK/2DTITBwvXf wUaMJHTj1q9SkM0rx2BHOYgE3xOL4FHF5vMhTme9dj3ysU3BMBv2HB4Ibh0MYJcx+bNu gVHC30hQRLSTH8y9eoyAGaovY5rLJn4ElFCBh6YDKdJ13Ht4ijQqeYrjLkYlwSuiSj18 WeLSAXiA48MEVkWPIUqMS6WculSWjgHi529QNMneIdhc4GEICAR8RWGwa7oNJKKK9LO/ pnPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769890439; x=1770495239; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=S0LcUKGhisOvXPcgAGjHu2gPdTtvHtYgAbPuJM0DSxQ=; b=Ih9b0kfaEiG+4YAH8KxnCOJfAWwZ0j8U04G2H9lJbmj+SHa08SuxkG7qVM+fgBjQ+O oOoQqn49JjhYiNuCOyhNRZ7aDHIt4Z4hCmtmQ8CTZ9Or6He+895ZnfSvzKR7FNnJAI7q PPNu2iIH5VrRo+aN5+rISHd5dIjsMT7lbS8HLKvP4fK+9T1lBaomxGyLOfCeqW2j9kK8 OHB6Wte1Ix7lfHS1l8UyXPDBvJgC+vJpWWpqHKZrUFoE9zDZB+dNnbkPBqVp1fAQHnwZ raIGDjwH/SJwJoTS5yCXdGjfY2R1sTJaU9k9BxdKMtn8H1b8VGZxfl3MfKeYjVuSg1P6 n8Ag== X-Gm-Message-State: AOJu0YxNgGbbM5n1/A515KsMPPJwMaCZZjJmlZYVrKPb5lOTOWayGe/4 Zlwp3ZVa1J5E6l9seFZFKFrztShG9HD7kTD9BeyVr1bVmm6z8YIifD5Ujtv4cZJC3XgeuwrmxeC WVMvt X-Gm-Gg: AZuq6aLzNFw2Czc8VWw23nHfLrR0T6QUT1kf4KKSlnsk4eaLe3KvRXVJ0cEDl8dQYFM v8C5n/SjGpSus73Wvq/yU1zy8TIUYf/UZhBRK+ffBGZNncyM872Vil7/cUiijjkAj56SlHWHQyo 9VFtQIwl6Fi/5CoG3P+4KUxZtdfrEVsekI2Xi/lH+DnIWtSJe51XQvziGftiKaxlF65HB1JkERM c91uJ+3o1Gqm70uUkfSXwqzV1ObAt8eTREcu+7+Ceimpm6BOXgqFrpsIByCowWhyme7sNSZz+Ty VdgZ+hSSD4Ko+rlXLWjGNBxKOVXZRMOiqj3EqxGbc44wp9WeL3qSnUGV6Zb4fI3uiMpVSnMrJJ1 HGVwWAR3dGJmtXIyzCt2sRPtrhArbmBC6VXfqKlMLiKBi/W+j5KnDiQYNG3vzQKunnNNb9d8/Mw 7D5vrfzL+8pg6gEUsbGerol4Vm5xYg2QHM9Ux2/Oegle2xisKFYg== X-Received: by 2002:a05:600c:4e47:b0:477:af07:dd21 with SMTP id 5b1f17b1804b1-482db49cdb6mr84044865e9.25.1769890438903; Sat, 31 Jan 2026 12:13:58 -0800 (PST) Received: from phoenix.lan (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066bfb59asm329496185e9.7.2026.01.31.12.13.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 31 Jan 2026 12:13:58 -0800 (PST) From: Stephen Hemminger To: dev@dpdk.org Cc: Stephen Hemminger Subject: [REVIEW] vfio: introduce cdev mode Date: Sat, 31 Jan 2026 12:13:54 -0800 Message-ID: <20260131201354.26947-1-stephen@networkplumber.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: =?utf-8?q?=3Cfced740802ecb03dd6f1d99bf02be080e99b5148=2E1763719?= =?utf-8?q?707=2Egit=2Eanatoly=2Eburakov=40intel=2Ecom=3E?= References: =?utf-8?q?=3Cfced740802ecb03dd6f1d99bf02be080e99b5148=2E17637197?= =?utf-8?q?07=2Egit=2Eanatoly=2Eburakov=40intel=2Ecom=3E?= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 AI-generated review of bundle-1718-vfio-cdev.mbox Reviewed using Claude (claude-opus-4-5-20251101) on 2026-01-31 This is an automated review. Please verify all suggestions. --- # DPDK Patch Review: VFIO cdev Mode Support (bundle-1718-vfio-cdev.mbox) This is a review of an 18-patch series adding VFIO cdev (IOMMUFD) mode support to DPDK. --- ## Patch 1/18: uapi: update to v6.17 and add iommufd.h ### Errors None. ### Warnings None. ### Info - Large patch adding kernel UAPI headers - this follows the established pattern for DPDK kernel header updates. --- ## Patch 2/18: vfio: make all functions internal ### Errors None. ### Warnings None. ### Info - Good cleanup converting public VFIO API to internal-only, reducing ABI stability surface. --- ## Patch 3/18: vfio: split get device info from setup ### Errors None. ### Warnings None. ### Info - Clean separation of concerns between setup and info retrieval. --- ## Patch 4/18: vfio: add container device assignment API ### Errors None. ### Warnings None. ### Info - New `rte_vfio_container_assign_device()` API provides cleaner semantics than group bind. --- ## Patch 5/18: net/nbl: do not use VFIO group bind API ### Errors None. ### Warnings 1. **File descriptor leak potential**: The `nbl_open_group_fd()` function opens a file descriptor that is stored in `common->groupfd`, but error paths in `nbl_mdev_map_device()` after line 431 may not properly close this fd before returning. ### Info - Converts NBL driver from group bind API to direct open. --- ## Patch 6/18: net/ntnic: use container device assignment API ### Errors None. ### Warnings None. ### Info - Clean conversion to new container assignment API. --- ## Patch 7/18: vdpa/ifc: use container device assignment API ### Errors None. ### Warnings None. ### Info - Straightforward conversion. --- ## Patch 8/18: vdpa/nfp: use container device assignment API ### Errors None. ### Warnings None. ### Info - Clean conversion removing unnecessary group tracking. --- ## Patch 9/18: vdpa/sfc: use container device assignment API ### Errors None. ### Warnings None. ### Info - Good simplification removing group fd and iommu_group_num fields. --- ## Patch 10/18: vhost: remove group-related API from drivers ### Errors None. ### Warnings None. ### Info - Removes unused `get_vfio_group_fd` callback from vDPA driver API. --- ## Patch 11/18: vfio: remove group-based API ### Errors None. ### Warnings None. ### Info - Completes removal of external group API, keeping internal implementation. --- ## Patch 12/18: vfio: cleanup and refactor ### Errors None. ### Warnings 1. **Documentation mismatch for rte_vfio_setup_device**: The header documentation states return of `<0 on failure`, but the implementation now returns -1 with `rte_errno = ENODEV` for devices not managed by VFIO. Callers need to check `rte_errno == ENODEV` to distinguish this case, which is documented, but ensure all callers in this patch are updated consistently. 2. **Potential resource leak in vfio_group_assign_device**: At the `dev_remove` label (around line 637 in eal_vfio.c), when a duplicate device is detected, `grp->n_devices--` is decremented but the device fd may not be properly cleaned up before calling `vfio_device_erase()`. The comment says "device will be closed" but verify the erase function handles this. ### Info - Major refactoring with consistent error handling via rte_errno. - New `enum vfio_result` provides clear internal error categorization. - Good separation of container, group, and device lifecycle management. --- ## Patch 13/18: bus/pci: use the new VFIO mode API ### Errors None. ### Warnings None. ### Info - Simple conversion to new mode query API. --- ## Patch 14/18: bus/fslmc: use the new VFIO mode API ### Errors None. ### Warnings None. ### Info - Good addition of mode check to prevent initialization in non-group modes. --- ## Patch 15/18: net/hinic3: use the new VFIO mode API ### Errors None. ### Warnings None. ### Info - Simple conversion. --- ## Patch 16/18: net/ntnic: use the new VFIO mode API ### Errors None. ### Warnings None. ### Info - Simple conversion. --- ## Patch 17/18: vfio: remove no-IOMMU check API ### Errors None. ### Warnings None. ### Info - Completes API cleanup now that mode query replaces direct noiommu check. --- ## Patch 18/18: vfio: introduce cdev mode ### Errors None. ### Warnings 1. **Missing error handling in cdev_attach_device_to_iommufd**: In `eal_vfio_cdev.c` around line 290, when bind with VF token fails and falls through to bind without token, the original bind structure is zeroed but there's no verification that the non-token bind actually succeeded before jumping to `attach`. The logic appears correct but consider adding a debug log for clarity. 2. **Potential fd leak in vfio_cdev_setup_device**: In `eal_vfio_cdev.c`, if `cdev_open_device_fd()` succeeds but `cdev_attach_device_to_iommufd()` fails, the device fd stored in `dev->fd` may not be closed by the caller. The caller (`vfio_cdev_assign_device`) calls `vfio_device_erase()` which should close it, but verify this path. ### Info - Comprehensive cdev/IOMMUFD implementation. - Good fallback from group mode to cdev mode during initialization. - Proper multiprocess support with IPC for fd sharing. - VF token support with graceful fallback for older kernels. --- ## Summary This is a well-structured patch series that adds VFIO cdev (IOMMUFD) mode support while cleaning up and modernizing the existing VFIO infrastructure. The main concerns are: 1. Minor potential resource management issues in error paths that should be verified 2. All patches follow DPDK coding standards 3. Commit messages are properly formatted 4. The incremental approach (cleanup first, then add new functionality) is appropriate The series is ready for integration with minor verification of the resource cleanup paths noted above.