Received: by 2002:ab2:1689:0:b0:1f7:5705:b850 with SMTP id d9csp2089968lqa; Tue, 30 Apr 2024 07:58:58 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCWDqHSjyRj9Kg8Wg2VWucEToi0Xy3+BcLHPNZbn1l+SQcdkqYJfL5oxxrjrvumrKzj5OroK7biGU20CyuizJcVUrw89A2RZp9Ealc35Iw== X-Google-Smtp-Source: AGHT+IHRai0ErQxzO+bLSXpZM03SYf8K0bJ1Jbm1JwflJVBLINCYryaXXF19PsJFjkDpx9cw1WQF X-Received: by 2002:a17:906:6895:b0:a58:c0e2:9792 with SMTP id n21-20020a170906689500b00a58c0e29792mr7446828ejr.61.1714489138316; Tue, 30 Apr 2024 07:58:58 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1714489138; cv=pass; d=google.com; s=arc-20160816; b=v8DRRqMq051begK7vu4XnArvIu4hUZLVUZpGSekU5kT05zZ1MhsL6n3RuOTJYmrXMS 20sAt94gltyX2XGryng4D48yadeIedwDB1G6yeCEALhMCEay4HA9sqSyU8OaD/PWLSRD ime7KWqtSLOP+nrbOM7s2cpf/PsueVhtmw4I6vycxQDV1wXB/2lpd7V0NyxKS06XEzBO arulcJvxW6yheEGBa0NnMsEIzzwVGF9meCj77Tp12gZf3hzPjRinjKOPOT3rgzUpft0n bYFNGts0izT2N4401FTQesXgEtMbIiHbcsvT0ZD9f0XmNmfOajXgfwvARFy1scIfGO/m 6H5w== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=lodTDKg2xwHPYnAltWFRXCouS1OEYGV8IYBFwRFSrBA=; fh=tXslIEC/iII+0o9YvlUtRXapl6zSPusBr1yEidN1Q7w=; b=TcmOTDBeMCBgFuntUGF1scVXLAiF9MoN+parZ9qPAqxAGEsEbLUJOD3XKabEt3v5Qm GYi2bX+TgM3/UZ7rNrWw9jd7UY/ixhtZJWgkeyq24+AF2S/GyS7N7OkvLn8l/K668Eba aOth4jcLJ92Q+uz38GXN3+SJw4gPmmDgwHjVTvgNY2/vDoivtkNoiDe2BzCNa1mAndGl uMZoNIpmgibqsfG9OmrWmfBNc6yQ8Icf5lnCVVEEXN46s9gw/UYXhmHlaooF4sTPb4ce azhEYyOkT9t72Ct3qwgDVYhnnSfFi2weZ/CdOFa9nPeMVazMAwIELvuVAe7Je5Myim+/ a5Cw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=AgnTlBcf; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-164209-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-164209-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id kx3-20020a170907774300b00a593d95f876si160891ejc.233.2024.04.30.07.58.58 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Apr 2024 07:58:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-164209-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=AgnTlBcf; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-164209-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-164209-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id B1B731F21680 for ; Tue, 30 Apr 2024 14:58:57 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 52B4777114; Tue, 30 Apr 2024 14:58:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="AgnTlBcf" Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F3BBD770E0 for ; Tue, 30 Apr 2024 14:58:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.19 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714489130; cv=none; b=km167y3PeSmy3HsojG/n+NACwh+P7RSW3LwfmmuuRkvdP/TzXsll6z0tgQM1lMV5qqgUR6jDz/icZSdAtoVFaz7gBE1k8L2w+sFz7taDAhSzw97Bg66yZhzCOznL65fuYa9GLT6bKMI6x/Wvq7G7Gc4PcGhC49pylquscKDL3e8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714489130; c=relaxed/simple; bh=JBVAR+sLuGoJYKowBGO4Ad8l5eFBbZOvpATG0wKcI6E=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=R0KCVzS/QES7FN/JpF+9toG80nl1MUwb3qqdTIfqEKG7ppduqlOltE14nQq2R2Yy7X5jpT7mdpUdbelUk0jtSYF9+1ZkCkXyF/XjgO+f6a8k9+SWnFfOHfjO9mey0L5MiMtzFKqYXnVNkRlYxvHr6hfVs4B9J1z1QRAPVWjoW/8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=AgnTlBcf; arc=none smtp.client-ip=198.175.65.19 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1714489129; x=1746025129; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=JBVAR+sLuGoJYKowBGO4Ad8l5eFBbZOvpATG0wKcI6E=; b=AgnTlBcfMuXkBffoZZ2x1j4biXiVEGaFviQ9EfpVgoBRnFx2biuNfogW UJin8f5tv3OOKHn8933eUYjQRZEDg8jUMVtSunBX2srHKR1xLlDidLwJu T3LOPrEHTZdlVuuuFtiIpKKa96PlXICTaJKFf+gHp4wAzd/iHo5X5l5Tt SK3IohkSJb8zSp6uNotIYa0aJ5Ib9r7nmLSYVmxhuofK/prHO6CoH5sNY PS39maQuFqkTi4JQS0KVJII9Bodj2I95hLCChtApJc/TraYHPgAeEVATn y8fHrC64tsB9kCidJhDg21oSbgGiVxmBbQBLR/vyX9frnEmwiK1pBmTl0 g==; X-CSE-ConnectionGUID: VWPoaYx7TrS6Xp+0DNPDsw== X-CSE-MsgGUID: nehywbi3QlimQBLcAPvFkg== X-IronPort-AV: E=McAfee;i="6600,9927,11060"; a="10059815" X-IronPort-AV: E=Sophos;i="6.07,242,1708416000"; d="scan'208";a="10059815" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Apr 2024 07:58:49 -0700 X-CSE-ConnectionGUID: UXIgDc36RUabnKJBXrtVMQ== X-CSE-MsgGUID: bU6XimoEQIyW+ufqsKOryg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,242,1708416000"; d="scan'208";a="31282110" Received: from unknown (HELO allen-box.sh.intel.com) ([10.239.159.127]) by orviesa004.jf.intel.com with ESMTP; 30 Apr 2024 07:58:45 -0700 From: Lu Baolu To: Jason Gunthorpe , Kevin Tian , Joerg Roedel , Will Deacon , Robin Murphy , Jean-Philippe Brucker , Nicolin Chen , Yi Liu , Jacob Pan , Joel Granados Cc: iommu@lists.linux.dev, virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, Lu Baolu Subject: [PATCH v5 0/9] IOMMUFD: Deliver IO page faults to user space Date: Tue, 30 Apr 2024 22:57:01 +0800 Message-Id: <20240430145710.68112-1-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This series implements the functionality of delivering IO page faults to user space through the IOMMUFD framework. One feasible use case is the nested translation. Nested translation is a hardware feature that supports two-stage translation tables for IOMMU. The second-stage translation table is managed by the host VMM, while the first-stage translation table is owned by user space. This allows user space to control the IOMMU mappings for its devices. When an IO page fault occurs on the first-stage translation table, the IOMMU hardware can deliver the page fault to user space through the IOMMUFD framework. User space can then handle the page fault and respond to the device top-down through the IOMMUFD. This allows user space to implement its own IO page fault handling policies. User space application that is capable of handling IO page faults should allocate a fault object, and bind the fault object to any domain that it is willing to handle the fault generatd for them. On a successful return of fault object allocation, the user can retrieve and respond to page faults by reading or writing to the file descriptor (FD) returned. The iommu selftest framework has been updated to test the IO page fault delivery and response functionality. The series and related patches are available on GitHub: https://github.com/LuBaolu/intel-iommu/commits/iommufd-io-pgfault-delivery-v5 Change log: v5: - Removed attach handle reference count from the core. Drivers will now synchronize their use of handles and domain attach/detach. - Automatically responds to all outstanding faults in hwpt detach or replace paths. - Supports getting a domain-type specific attach handle. - Reorganized the series by changing the patch order. - Miscellaneous cleanup. v4: https://lore.kernel.org/linux-iommu/20240403011519.78512-1-baolu.lu@linux.intel.com/ - Add the iommu domain attachment handle to replace the iopf-specific domain attachment interfaces introduced in the previous v3. - Replace the iommu_sva with iommu domain attachment handle. - Refine some fields in the fault and response message encoding according to feedback collected during v3 review period. - Refine and fix some problems in the fault FD implementation. - Miscellaneous cleanup. v3: https://lore.kernel.org/linux-iommu/20240122073903.24406-1-baolu.lu@linux.intel.com/ - Add iopf domain attach/detach/replace interfaces to manage the reference counters of hwpt and device, ensuring that both can only be destroyed after all outstanding IOPFs have been responded to. - Relocate the fault handling file descriptor from hwpt to a fault object to enable a single fault handling object to be utilized across multiple domains. - Miscellaneous cleanup and performance improvements. v2: https://lore.kernel.org/linux-iommu/20231026024930.382898-1-baolu.lu@linux.intel.com/ - Move all iommu refactoring patches into a sparated series and discuss it in a different thread. The latest patch series [v6] is available at https://lore.kernel.org/linux-iommu/20230928042734.16134-1-baolu.lu@linux.intel.com/ - We discussed the timeout of the pending page fault messages. We agreed that we shouldn't apply any timeout policy for the page fault handling in user space. https://lore.kernel.org/linux-iommu/20230616113232.GA84678@myrica/ - Jason suggested that we adopt a simple file descriptor interface for reading and responding to I/O page requests, so that user space applications can improve performance using io_uring. https://lore.kernel.org/linux-iommu/ZJWjD1ajeem6pK3I@ziepe.ca/ v1: https://lore.kernel.org/linux-iommu/20230530053724.232765-1-baolu.lu@linux.intel.com/ Lu Baolu (9): iommu: Introduce domain attachment handle iommu: Replace sva_iommu with iommu_attach_handle iommu: Add attachment handle to struct iopf_group iommufd: Add fault and response message definitions iommufd: Add iommufd fault object iommufd: Fault-capable hwpt attach/detach/replace iommufd: Associate fault object with iommufd_hw_pgtable iommufd/selftest: Add IOPF support for mock device iommufd/selftest: Add coverage for IOPF test include/linux/iommu.h | 32 +- include/linux/uacce.h | 2 +- drivers/dma/idxd/idxd.h | 2 +- drivers/iommu/iommu-priv.h | 17 + drivers/iommu/iommufd/iommufd_private.h | 43 ++ drivers/iommu/iommufd/iommufd_test.h | 8 + include/uapi/linux/iommufd.h | 122 ++++++ tools/testing/selftests/iommu/iommufd_utils.h | 84 +++- drivers/dma/idxd/cdev.c | 4 +- drivers/iommu/io-pgfault.c | 34 +- drivers/iommu/iommu-sva.c | 43 +- drivers/iommu/iommu.c | 156 +++++++- drivers/iommu/iommufd/device.c | 16 +- drivers/iommu/iommufd/fault.c | 373 ++++++++++++++++++ drivers/iommu/iommufd/hw_pagetable.c | 35 +- drivers/iommu/iommufd/main.c | 8 +- drivers/iommu/iommufd/selftest.c | 63 +++ drivers/misc/uacce/uacce.c | 2 +- tools/testing/selftests/iommu/iommufd.c | 18 + .../selftests/iommu/iommufd_fail_nth.c | 2 +- drivers/iommu/iommufd/Makefile | 1 + 21 files changed, 959 insertions(+), 106 deletions(-) create mode 100644 drivers/iommu/iommufd/fault.c -- 2.34.1