{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":440949075,"defaultBranch":"dev-iommu-5.14-rfcv1","name":"iommufd","ownerLogin":"nicolinc","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2021-12-22T18:24:54.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/89113456?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1725696665.0","currentOid":""},"activityList":{"items":[{"before":null,"after":"02d6624ffff1c0923d2254f0cac84593d224074d","ref":"refs/heads/wip/iommufd_doc_nesting","pushedAt":"2024-09-07T08:11:05.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"Documuuentation: userspace-api: Update iommufd doc for HWPT_PAGING/NESTED\n\nThe previous IOMMUFD_OBJ_HW_PAGETABLE has been reworked to two separated\nobjects: IOMMUFD_OBJ_HWPT_PAGING and IOMMUFD_OBJ_HWPT_NESTED in order to\nsupport a nested translation context.\n\nCorresponding to the latest iommufd APIs and uAPIs, update the doc so as\nto reflect the new design.\n\nSigned-off-by: Nicolin Chen ","shortMessageHtmlLink":"Documuuentation: userspace-api: Update iommufd doc for HWPT_PAGING/NE…"}},{"before":"eb2883d6e71faa3f92844acbc3f85f279dc2fbdb","after":"530993c3aafa1b0fc3d879b8119e13c629d12e2b","ref":"refs/heads/vcmdq_in_kernel-fix","pushedAt":"2024-09-05T02:24:49.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"iommu/tegra241-cmdqv: Do not allocate vcmdq until dma_set_mask_and_coherent\n\nIt's observed that, when the first 4GB of system memory was reserved, all\nVCMDQ allocations failed (even with the smallest qsz in the last attempt):\n arm-smmu-v3: found companion CMDQV device: NVDA200C:00\n arm-smmu-v3: option mask 0x10\n arm-smmu-v3: failed to allocate queue (0x8000 bytes) for vcmdq0\n acpi NVDA200C:00: tegra241_cmdqv: Falling back to standard SMMU CMDQ\n arm-smmu-v3: ias 48-bit, oas 48-bit (features 0x001e1fbf)\n arm-smmu-v3: allocated 524288 entries for cmdq\n arm-smmu-v3: allocated 524288 entries for evtq\n arm-smmu-v3: allocated 524288 entries for priq\n\nThis is because the 4GB reserved memory shifted the entire DMA zone from a\nlower 32-bit range (on a system without the 4GB carveout) to higher range,\nwhile the dev->coherent_dma_mask was set to DMA_BIT_MASK(32) by default.\n\nThe dma_set_mask_and_coherent() call is done in arm_smmu_device_hw_probe()\nof the SMMU driver. So any DMA allocation from tegra241_cmdqv_probe() must\nwait until the coherent_dma_mask is correctly set.\n\nMove the vintf/vcmdq structure initialization routine into a different op,\n\"init_structures\". Call it at the end of arm_smmu_init_structures(), where\nstandard SMMU queues get allocated.\n\nMost of the impl_ops aren't ready until vintf/vcmdq structure are init-ed.\nSo replace the full impl_ops with an init_ops in __tegra241_cmdqv_probe().\n\nAnd switch to tegra241_cmdqv_impl_ops later in arm_smmu_init_structures().\nNote that tegra241_cmdqv_impl_ops does not link to the new init_structures\nop after this switch, since there is no point in having it once it's done.\n\nFixes: 918eb5c856f6 (\"iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV\")\nReported-by: Matt Ochs \nSigned-off-by: Nicolin Chen ","shortMessageHtmlLink":"iommu/tegra241-cmdqv: Do not allocate vcmdq until dma_set_mask_and_co…"}},{"before":"19fda9a18c4da75d98eaee1c9995e761d482dc32","after":"eb2883d6e71faa3f92844acbc3f85f279dc2fbdb","ref":"refs/heads/vcmdq_in_kernel-fix","pushedAt":"2024-09-05T01:54:45.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"iommu/tegra241-cmdqv: Do not allocate vcmdq until dma_set_mask_and_coherent\n\nIt's observed that, when the first 4GB of system memory was reserved, all\nVCMDQ allocations failed (even with the smallest qsz in the last attempt):\n arm-smmu-v3: found companion CMDQV device: NVDA200C:00\n arm-smmu-v3: option mask 0x10\n arm-smmu-v3: failed to allocate queue (0x8000 bytes) for vcmdq0\n acpi NVDA200C:00: tegra241_cmdqv: Falling back to standard SMMU CMDQ\n arm-smmu-v3: ias 48-bit, oas 48-bit (features 0x001e1fbf)\n arm-smmu-v3: allocated 524288 entries for cmdq\n arm-smmu-v3: allocated 524288 entries for evtq\n arm-smmu-v3: allocated 524288 entries for priq\n\nThis is because the 4GB reserved memory shifted the entire DMA zone from a\nlower 32-bit range (on a system without the 4GB carveout) to higher range,\nwhile the dev->coherent_dma_mask was set to DMA_BIT_MASK(32) by default.\n\nThe dma_set_mask_and_coherent() call is done in arm_smmu_device_hw_probe()\nof the SMMU driver. So any DMA allocation from tegra241_cmdqv_probe() must\nwait until the coherent_dma_mask is correctly set.\n\nMove the vintf/vcmdq structure initialization routine into a different op,\n\"init_structures\". Call it at the end of arm_smmu_init_structures(), where\nstandard SMMU queues get allocated.\n\nMost of the impl_ops aren't ready until vintf/vcmdq structure are init-ed.\nSo replace the full impl_ops with an init_ops in __tegra241_cmdqv_probe().\nAnd switch to tegra241_cmdqv_impl_ops later in arm_smmu_init_structures().\n\nFixes: 918eb5c856f6 (\"iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV\")\nReported-by: Matt Ochs \nSigned-off-by: Nicolin Chen ","shortMessageHtmlLink":"iommu/tegra241-cmdqv: Do not allocate vcmdq until dma_set_mask_and_co…"}},{"before":"0e0d3fdc52654248e996b10e714e09494c3f86cf","after":"19fda9a18c4da75d98eaee1c9995e761d482dc32","ref":"refs/heads/vcmdq_in_kernel-fix","pushedAt":"2024-09-04T23:52:42.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"iommu/tegra241-cmdqv: Do not allocate vcmdq until dma_set_mask_and_coherent\n\nIt's observed that, when the first 4GB of system memory was reserved, all\nVCMDQ allocations failed (even with the smallest qsz in the last attempt):\n arm-smmu-v3: found companion CMDQV device: NVDA200C:00\n arm-smmu-v3: option mask 0x10\n arm-smmu-v3: failed to allocate queue (0x8000 bytes) for vcmdq0\n acpi NVDA200C:00: tegra241_cmdqv: Falling back to standard SMMU CMDQ\n arm-smmu-v3: ias 48-bit, oas 48-bit (features 0x001e1fbf)\n arm-smmu-v3: allocated 524288 entries for cmdq\n arm-smmu-v3: allocated 524288 entries for evtq\n arm-smmu-v3: allocated 524288 entries for priq\n\nThis is because the 4GB reserved memory shifted the entire DMA zone from a\nlower 32-bit range (on a system without the 4GB carveout) to higher range,\nwhile the dev->coherent_dma_mask was set to DMA_BIT_MASK(32) by default.\n\nThe dma_set_mask_and_coherent() call is done in arm_smmu_device_hw_probe()\nof the SMMU driver. So any DMA allocation from tegra241_cmdqv_probe() must\nwait until the coherent_dma_mask is correctly set.\n\nMove the vintf/vcmdq structure initialization routine into a different op,\n\"init_structures\". Call it at the end of arm_smmu_init_structures(), where\nstandard SMMU queues get allocated.\n\nBoth tegra241_cmdqv_get_cmdq() and tegra241_cmdqv_remove() can be entered\nbefore arm_smmu_init_structures() finishes impl_ops->init_structures(). So\nvalidate cmdqv->vintfs pointer at the top of those two functions.\n\nFixes: 918eb5c856f6 (\"iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV\")\nReported-by: Matt Ochs \nSigned-off-by: Nicolin Chen ","shortMessageHtmlLink":"iommu/tegra241-cmdqv: Do not allocate vcmdq until dma_set_mask_and_co…"}},{"before":null,"after":"0e0d3fdc52654248e996b10e714e09494c3f86cf","ref":"refs/heads/vcmdq_in_kernel-fix","pushedAt":"2024-09-02T05:49:59.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"iommu/tegra241-cmdqv: Fix -Wformat-truncation warnings in lvcmdq_error_header\n\nKernel test robot reported a few trucation warnings at the snprintf:\ndrivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c:\n\tIn function ‘tegra241_vintf_free_lvcmdq’:\ndrivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c:239:56:\n\twarning: ‘%u’ directive output may be truncated writing between 1 and\n\t5 bytes into a region of size between 3 and 11 [-Wformat-truncation=]\n 239 | snprintf(header, hlen, \"VINTF%u: VCMDQ%u/LVCMDQ%u: \",\n | ^~\ndrivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c:239:32: note: directive argument\n\tin the range [0, 65535]\n 239 | snprintf(header, hlen, \"VINTF%u: VCMDQ%u/LVCMDQ%u: \",\n | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~\ndrivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c:239:9: note: ‘snprintf’ output\n\tbetween 25 and 37 bytes into a destination of size 32\n 239 | snprintf(header, hlen, \"VINTF%u: VCMDQ%u/LVCMDQ%u: \",\n | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n 240 | vcmdq->vintf->idx, vcmdq->idx, vcmdq->lidx);\n\nFix by bumping up the size of the header to hold more characters.\n\nFixes: 918eb5c856f6 (\"iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV\")\nReported-by: kernel test robot \nCloses: https://lore.kernel.org/oe-kbuild-all/202409020406.7ed5uojF-lkp@intel.com/\nSigned-off-by: Nicolin Chen ","shortMessageHtmlLink":"iommu/tegra241-cmdqv: Fix -Wformat-truncation warnings in lvcmdq_erro…"}},{"before":"6427a14407a05a59e673c96b736bdf2bc3f7632a","after":"0c608aa6162889da46a0aa23c84936881c5faa4c","ref":"refs/heads/vcmdq_in_kernel-v14","pushedAt":"2024-08-29T22:31:05.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"cover-letter: Add Tegra241 (Grace) CMDQV Support (part 1/2)\n\nNVIDIA's Tegra241 (Grace) SoC has a CMDQ-Virtualization (CMDQV) hardware\nthat extends standard ARM SMMUv3 to support multiple command queues with\nvirtualization capabilities. Though this is similar to the ECMDQ in SMMU\nv3.3, CMDQV provides additional Virtual Interfaces (VINTFs) allowing VMs\nto have their own VINTFs and Virtual Command Queues (VCMDQs). The VCMDQs\ncan only execute a limited set of commands, mainly invalidation commands\nwhen exclusively used by the VMs, compared to the standard SMMUv3 CMDQ.\n\nThus, there are two parts of patch series to add its support: the basic\nin-kernel support as part 1, and the user-space support as part 2.\n\nThe in-kernel support is to detect/configure the CMDQV hardware and then\nallocate a VINTF with some VCMDQs for the kernel/hypervisor to use. Like\nECMDQ, CMDQV also allows the kernel to use multiple VCMDQs, giving some\nlimited performance improvement: up to 20% reduction of TLB invalidation\ntime was measured by a multi-threaded DMA unmap benchmark, compared to a\nsingle queue.\n\nThe user-space support is to provide uAPIs (via IOMMUFD) for hypervisors\nin user space to passthrough VCMDQs to VMs, allowing these VMs to access\nthe VCMDQs directly without trappings, i.e. no VM Exits. This gives huge\nperformance improvements: 70% to 90% reductions of TLB invalidation time\nwere measured by various DMA unmap tests running in a guest OS, compared\nto a nested SMMU CMDQ (with trappings).\n\nThis is the part-1 series:\n - Preparatory changes to share the existing SMMU functions\n - A new CMDQV driver and extending the SMMUv3 driver to interact with\n the new driver\n - Limit the commands for a guest kernel.\n\nIt's available on Github:\nhttps://github.com/nicolinc/iommufd/commits/vcmdq_in_kernel-v14\n\nAnd the part-2 RFC series is also sent for discussion:\nhttps://lore.kernel.org/all/cover.1712978212.git.nicolinc@nvidia.com/\n\nNote that this in-kernel support isn't confined to host kernels running\non Grace-powered servers, but is also used by guest kernels running on\nVMs virtualized on those servers. So, those VMs must install the driver,\nideally before the part 2 is merged. So, later those servers would only\nneed to upgrade their host kernels without bothering the VMs.\n\nThank you!\n\nChangelog\nv14:\n * Rebased on Will's for-joerg/arm-smmu/updates\n * Added a missed kdoc for \"dev\" in struct tegra241_cmdqv\n * Corrected typo-ed function names in the impl commit message\nv13:\n https://lore.kernel.org/all/cover.1724453781.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc4\n * Fixed the lidx calculation in the isr()\n * Dropped the arm_smmu_get_iort_node from v12\n * Dropped the WARN_ON_ONCE in arm_smmu_cmdq_batch_init()\n * Replaced ARM_SMMU_OPT_SECONDARY_CMDQ_CS_NONE_ONLY with\n ARM_SMMU_OPT_TEGRA241_CMDQV for impl-level probe\n * Split the minimal cmdqv dsdt probe part from the tegra241_cmdqv\n to the common driver since it might run on other platforms too\n * Added an impl_dev to forward the device node to cmdqv driver so\n it can use it for prints and HW resources probe\n * Switched to the open-code approach provided by Will, replacing\n the patch \"Enforce arm_smmu_cmdq_build_sync_cmd\"\n * Added a supports_cmd op in the struct arm_smmu_cmdq, so as to\n scan the command at each arm_smmu_cmdq_batch_add call\nv12:\n https://lore.kernel.org/all/cover.1723754745.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc3\n * Added Jason's Reviewed-by\n * Added an arm_smmu_impl_probe helper\n * Added an arm_smmu_get_iort_node helper\n * Slightly updated the CMDQV acpi probe()\n * Added a static_assert() for smmu in struct tegra241_cmdqv\nv11:\n https://lore.kernel.org/all/cover.1722993435.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc2\n * Fixed \"vtinfs\" typo in kdoc\n * Maxed out the max_n_shift to hardware allowed value\nv10:\n https://lore.kernel.org/all/cover.1722206275.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc1\n * Added impl design mimicing arm-smmu (v2) driver\n * Replaced the CS_NONE quirk with a new smmu option\n * Fixed misaligned 64-bit register reading in the isr()\n * Explicitly assign opcode to arm_smmu_cmdq_batch_init() where\n cmd/ent might potentially not be initialized.\nv9:\n https://lore.kernel.org/all/cover.1718228494.git.nicolinc@nvidia.com/\n * Rebased on 6.10-rc3\n * Replaced \"base + offset\" in write_config() with REG helpers\n * Added \"Reviewed-by\" line from Jason, to the remaining PATCH-5\nv8:\n https://lore.kernel.org/all/cover.1716883239.git.nicolinc@nvidia.com/\n * Added \"Reviewed-by\" lines from Jason\n * Replaced memset with a simple \"cmd[1] = 0\"\n * Replaced MMIO read/write helpers with REG_* macros\n * Dropped the racy static string in lvcmdq_error_header()\n * Added a few lines of comments to arm_smmu_get_cmdq at the line\n calling tegra241_cmdqv_get_cmdq()\nv7:\n https://lore.kernel.org/all/cover.1715147377.git.nicolinc@nvidia.com/\n * Moved all public symbols into one single patch\n * Enforced a command batch to use the same cmdq\n * Enforced the use of arm_smmu_cmdq_build_sync_cmd()\n * Reworked the tegra241-cmdqv driver patch\n - Dropped logging macros, cmdqv->dev, and atomic\n - Dropped devm_* and added tegra241_cmdqv_device_remove()\n - Moved all structure allocations to cmdqv's probe() from\n device_reset() where only register configurations remains\n - Switched the config macros to inline functions\n - Optimized ISR routine with 64-bit reading MMIO\n - Scan once per batch against command list\n - Reorganized function locations\n - Minor readability changes\nv6:\n https://lore.kernel.org/all/cover.1714451595.git.nicolinc@nvidia.com/\n * Reordered the patch sequence to fix git-bisect break\n * Added a status cache to cmdqv/vintf/vcmdq structure\n * Added gerror/gerrorn value match in hw_deinit()\n * Minimized changes in __arm_smmu_cmdq_skip_err()\n * Preallocated VCMDQs to VINTFs for stablility\nv5:\n https://lore.kernel.org/all/cover.1712977210.git.nicolinc@nvidia.com/\n * Improved print/mmio helpers\n * Added proper register reset routines\n * Reorganized init/deinit functions to share with VIOMMU callbacks in\n the upcoming part-2 user-space series (RFC)\nv4:\n https://lore.kernel.org/all/cover.1711690673.git.nicolinc@nvidia.com/\n * Rebased on v6.9-rc1\n * Renamed to \"tegra241-cmdqv\", following other Grace kernel patches\n * Added a set of print and MMIO helpers\n * Reworked the guest limitation patch\nv3:\n https://lore.kernel.org/all/20211119071959.16706-1-nicolinc@nvidia.com/\n * Dropped VMID and mdev patches to redesign later based on IOMMUFD\n * Separated HYP_OWN part for guest support into a new patch\n * Added new preparatory changes\nv2:\n https://lore.kernel.org/all/20210831025923.15812-1-nicolinc@nvidia.com/\n * Added mdev interface support for hypervisor and VMs\n * Added preparatory changes for mdev interface implementation\n * PATCH-12 Changed ->issue_cmdlist() to ->get_cmdq() for a better\n integration with recently merged ECMDQ-related changes\nv1:\n https://lore.kernel.org/all/20210723193140.9690-1-nicolinc@nvidia.com/","shortMessageHtmlLink":"cover-letter: Add Tegra241 (Grace) CMDQV Support (part 1/2)"}},{"before":"5287d420e90459e85ebe88602eb52bba9b9c8040","after":"16fb4791aa7698e11b7e22126972feaaaa40ea52","ref":"refs/heads/iommufd_virq-v1","pushedAt":"2024-08-27T16:43:25.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-2 VIRQ)\n\nAs the part-2 of the VIOMMU infrastructure, this series introduces a VIRQ\nobject after repurposing the existing FAULT object, which provides a nice\nnotification pathway to the user space already. So, the first thing to do\nis reworking the FAULT object.\n\nMimicing the HWPT structures, add a common EVENT structure to support its\nderivatives: EVENT_IOPF (the prior FAULT object) and EVENT_VIRQ (new one).\nIOMMUFD_CMD_VIRQ_ALLOC is introduced to allocate EVENT_VIRQ for a VIOMMU.\nOne VIOMMU can have multiple VIRQs in different types but can not support\nmultiple VIRQs with the same types.\n\nDrivers might need the VIOMMU's vdev_id list or the exact vdev_id link of\nthe passthrough device's to forward IRQs/events via the VIOMMU framework.\nThus, extend the set/unset_vdev_id ioctls down to the driver using VIOMMU\nops. This allows drivers to take the control of a vdev_id's lifecycle.\n\nThe forwarding part is fairly simple but might need to replace a physical\ndevice ID with a virtual device ID. So, there comes with some helpers for\ndrivers to use.\n\nAs usual, this series comes with the selftest coverage for this new VIRQ,\nand with a real world use case in the ARM SMMUv3 driver.\n\nThis must be based on the VIOMMU Part-1 series. It's on Github:\nhttps://github.com/nicolinc/iommufd/commits/iommufd_virq-v1\nParing QEMU branch for testing:\nhttps://github.com/nicolinc/qemu/commits/wip/for_iommufd_virq-v1\n\nThanks!\nNicolin","shortMessageHtmlLink":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-2 VIRQ)"}},{"before":"24478ddba2fd4dbf8de7c5ebe232c4fa5e9e1637","after":"f5b7d41a784261d703ae28d03e711ca48d1ebae0","ref":"refs/heads/iommufd_viommu_p1-v2","pushedAt":"2024-08-27T16:41:04.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-1)\n\nThis series introduces a new VIOMMU infrastructure and related ioctls.\n\nIOMMUFD has been using the HWPT infrastructure for all cases, including a\nnested IO page table support. Yet, there're limitations for an HWPT-based\nstructure to support some advanced HW-accelerated features, such as CMDQV\non NVIDIA Grace, and HW-accelerated vIOMMU on AMD. Even for a multi-IOMMU\nenvironment, it is not straightforward for nested HWPTs to share the same\nparent HWPT (stage-2 IO pagetable), with the HWPT infrastructure alone.\n\nThe new VIOMMU object is an additional layer, between the nested HWPT and\nits parent HWPT, to give to both the IOMMUFD core and an IOMMU driver an\nadditional structure to support HW-accelerated feature:\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested0 |--->| viommu0 ------------------\n ---------------- | | HW-accel feats |\n ----------------------------\n\nOn a multi-IOMMU system, the VIOMMU object can be instanced to the number\nof vIOMMUs in a guest VM, while holding the same parent HWPT to share the\nstage-2 IO pagetable. Each VIOMMU then just need to only allocate its own\nVMID to attach the shared stage-2 IO pagetable to the physical IOMMU:\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested0 |--->| viommu0 ------------------\n ---------------- | | VMID0 |\n ----------------------------\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested1 |--->| viommu1 ------------------\n ---------------- | | VMID1 |\n ----------------------------\n\nAs an initial part-1, add ioctls to support a VIOMMU-based invalidation:\n IOMMUFD_CMD_VIOMMU_ALLOC to allocate a VIOMMU object\n IOMMUFD_CMD_VIOMMU_SET/UNSET_VDEV_ID to set/clear device's virtual ID\n (Resue IOMMUFD_CMD_HWPT_INVALIDATE for a VIOMMU object to flush cache\n by a given driver data)\n\nWorth noting that the VDEV_ID is for a per-VIOMMU device list for drivers\nto look up the device's physical instance from its virtual ID in a VM. It\nis essential for a VIOMMU-based invalidation where the request contains a\ndevice's virtual ID for its device cache flush, e.g. ATC invalidation.\n\nAs for the implementation of the series, add an IOMMU_VIOMMU_TYPE_DEFAULT\ntype for a core-allocated-core-managed VIOMMU object, allowing drivers to\nsimply hook a default viommu ops for viommu-based invalidation alone. And\nprovide some viommu helpers to drivers for VDEV_ID translation and parent\ndomain lookup. Add VIOMMU invalidation support to ARM SMMUv3 driver for a\nreal world use case. This adds supports of arm-smmuv-v3's CMDQ_OP_ATC_INV\nand CMDQ_OP_CFGI_CD/ALL commands, supplementing HWPT-based invalidations.\n\nIn the future, drivers will also be able to choose a driver-managed type\nto hold its own structure by adding a new type to enum iommu_viommu_type.\nMore VIOMMU-based structures and ioctls will be introduced in part-2/3 to\nsupport a driver-managed VIOMMU, e.g. VQUEUE object for a HW accelerated\nqueue, VIRQ (or VEVENT) object for IRQ injections. Although we repurposed\nthe VIOMMU object from an earlier RFC discussion, for a referece:\nhttps://lore.kernel.org/all/cover.1712978212.git.nicolinc@nvidia.com/\n\nThis series is on Github:\nhttps://github.com/nicolinc/iommufd/commits/iommufd_viommu_p1-v2\nParing QEMU branch for testing:\nhttps://github.com/nicolinc/qemu/commits/wip/for_iommufd_viommu_p1-v2\n\nChangelog\nv2\n * Limited vdev_id to one per idev\n * Added a rw_sem to protect the vdev_id list\n * Reworked driver-level APIs with proper lockings\n * Added a new viommu_api file for IOMMUFD_DRIVER config\n * Dropped useless iommu_dev point from the viommu structure\n * Added missing index numnbers to new types in the uAPI header\n * Dropped IOMMU_VIOMMU_INVALIDATE uAPI; Instead, reuse the HWPT one\n * Reworked mock_viommu_cache_invalidate() using the new iommu helper\n * Reordered details of set/unset_vdev_id handlers for proper lockings\n * Added arm_smmu_cache_invalidate_user patch from Jason's nesting series\nv1\n https://lore.kernel.org/all/cover.1723061377.git.nicolinc@nvidia.com/\n\nThanks!\nNicolin","shortMessageHtmlLink":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-1)"}},{"before":"c39b644b687ce5260ff8a2afbf6b62d99c61b6c7","after":"5287d420e90459e85ebe88602eb52bba9b9c8040","ref":"refs/heads/iommufd_virq-v1","pushedAt":"2024-08-27T16:30:48.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-2 VIRQ)\n\nAs the part-2 of the VIOMMU infrastructure, this series introduces a VIRQ\nobject after repurposing the existing FAULT object, which provides a nice\nnotification pathway to the user space already. So, the first thing to do\nis reworking the FAULT object.\n\nMimicing the HWPT structures, add a common EVENT structure to support its\nderivatives: EVENT_IOPF (the prior FAULT object) and EVENT_VIRQ (new one).\nIOMMUFD_CMD_VIRQ_ALLOC is introduced to allocate EVENT_VIRQ for a VIOMMU.\nOne VIOMMU can have multiple VIRQs in different types but can not support\nmultiple VIRQs with the same types.\n\nDrivers might need the VIOMMU's vdev_id list or the exact vdev_id link of\nthe passthrough device's to forward IRQs/events via the VIOMMU framework.\nThus, extend the set/unset_vdev_id ioctls down to the driver using VIOMMU\nops. This allows drivers to take the control of a vdev_id's lifecycle.\n\nThe forwarding part is fairly simple but might need to replace a physical\ndevice ID with a virtual device ID. So, there comes with some helpers for\ndrivers to use.\n\nAs usual, this series comes with the selftest coverage for this new VIRQ,\nand with a real world use case in the ARM SMMUv3 driver.\n\nThis must be based on the VIOMMU Part-1 series. It's on Github:\nhttps://github.com/nicolinc/iommufd/commits/iommufd_virq-v1\nParing QEMU branch for testing:\nhttps://github.com/nicolinc/qemu/commits/wip/for_iommufd_virq-v1\n\nThanks!\nNicolin","shortMessageHtmlLink":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-2 VIRQ)"}},{"before":"f994f840a31e45edd31f34f42a2d070493f3900f","after":"24478ddba2fd4dbf8de7c5ebe232c4fa5e9e1637","ref":"refs/heads/iommufd_viommu_p1-v2","pushedAt":"2024-08-27T16:28:00.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-1)\n\nThis series introduces a new VIOMMU infrastructure and related ioctls.\n\nIOMMUFD has been using the HWPT infrastructure for all cases, including a\nnested IO page table support. Yet, there're limitations for an HWPT-based\nstructure to support some advanced HW-accelerated features, such as CMDQV\non NVIDIA Grace, and HW-accelerated vIOMMU on AMD. Even for a multi-IOMMU\nenvironment, it is not straightforward for nested HWPTs to share the same\nparent HWPT (stage-2 IO pagetable), with the HWPT infrastructure alone.\n\nThe new VIOMMU object is an additional layer, between the nested HWPT and\nits parent HWPT, to give to both the IOMMUFD core and an IOMMU driver an\nadditional structure to support HW-accelerated feature:\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested0 |--->| viommu0 ------------------\n ---------------- | | HW-accel feats |\n ----------------------------\n\nOn a multi-IOMMU system, the VIOMMU object can be instanced to the number\nof vIOMMUs in a guest VM, while holding the same parent HWPT to share the\nstage-2 IO pagetable. Each VIOMMU then just need to only allocate its own\nVMID to attach the shared stage-2 IO pagetable to the physical IOMMU:\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested0 |--->| viommu0 ------------------\n ---------------- | | VMID0 |\n ----------------------------\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested1 |--->| viommu1 ------------------\n ---------------- | | VMID1 |\n ----------------------------\n\nAs an initial part-1, add ioctls to support a VIOMMU-based invalidation:\n IOMMUFD_CMD_VIOMMU_ALLOC to allocate a VIOMMU object\n IOMMUFD_CMD_VIOMMU_SET/UNSET_VDEV_ID to set/clear device's virtual ID\n (Resue IOMMUFD_CMD_HWPT_INVALIDATE for a VIOMMU object to flush cache\n by a given driver data)\n\nWorth noting that the VDEV_ID is for a per-VIOMMU device list for drivers\nto look up the device's physical instance from its virtual ID in a VM. It\nis essential for a VIOMMU-based invalidation where the request contains a\ndevice's virtual ID for its device cache flush, e.g. ATC invalidation.\n\nAs for the implementation of the series, add an IOMMU_VIOMMU_TYPE_DEFAULT\ntype for a core-allocated-core-managed VIOMMU object, allowing drivers to\nsimply hook a default viommu ops for viommu-based invalidation alone. And\nprovide some viommu helpers to drivers for VDEV_ID translation and parent\ndomain lookup. Add VIOMMU invalidation support to ARM SMMUv3 driver for a\nreal world use case. This adds supports of arm-smmuv-v3's CMDQ_OP_ATC_INV\nand CMDQ_OP_CFGI_CD/ALL commands, supplementing HWPT-based invalidations.\n\nIn the future, drivers will also be able to choose a driver-managed type\nto hold its own structure by adding a new type to enum iommu_viommu_type.\nMore VIOMMU-based structures and ioctls will be introduced in part-2/3 to\nsupport a driver-managed VIOMMU, e.g. VQUEUE object for a HW accelerated\nqueue, VIRQ (or VEVENT) object for IRQ injections. Although we repurposed\nthe VIOMMU object from an earlier RFC discussion, for a referece:\nhttps://lore.kernel.org/all/cover.1712978212.git.nicolinc@nvidia.com/\n\nThis series is on Github:\nhttps://github.com/nicolinc/iommufd/commits/iommufd_viommu_p1-v2\nParing QEMU branch for testing:\nhttps://github.com/nicolinc/qemu/commits/wip/for_iommufd_viommu_p1-v2\n\nChangelog\nv2\n * Limited vdev_id to one per idev\n * Added a rw_sem to protect the vdev_id list\n * Reworked driver-level APIs with proper lockings\n * Added a new viommu_api file for IOMMUFD_DRIVER config\n * Dropped useless iommu_dev point from the viommu structure\n * Added missing index numnbers to new types in the uAPI header\n * Dropped IOMMU_VIOMMU_INVALIDATE uAPI; Instead, reuse the HWPT one\n * Reworked mock_viommu_cache_invalidate() using the new iommu helper\n * Reordered details of set/unset_vdev_id handlers for proper lockings\nv1\n https://lore.kernel.org/all/cover.1723061377.git.nicolinc@nvidia.com/\n\nThanks!\nNicolin","shortMessageHtmlLink":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-1)"}},{"before":"2667809feaa07f385950236c6991be9212fda521","after":"6427a14407a05a59e673c96b736bdf2bc3f7632a","ref":"refs/heads/vcmdq_in_kernel-v14","pushedAt":"2024-08-27T16:02:44.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"cover-letter: Add Tegra241 (Grace) CMDQV Support (part 1/2)\n\nNVIDIA's Tegra241 (Grace) SoC has a CMDQ-Virtualization (CMDQV) hardware\nthat extends standard ARM SMMUv3 to support multiple command queues with\nvirtualization capabilities. Though this is similar to the ECMDQ in SMMU\nv3.3, CMDQV provides additional Virtual Interfaces (VINTFs) allowing VMs\nto have their own VINTFs and Virtual Command Queues (VCMDQs). The VCMDQs\ncan only execute a limited set of commands, mainly invalidation commands\nwhen exclusively used by the VMs, compared to the standard SMMUv3 CMDQ.\n\nThus, there are two parts of patch series to add its support: the basic\nin-kernel support as part 1, and the user-space support as part 2.\n\nThe in-kernel support is to detect/configure the CMDQV hardware and then\nallocate a VINTF with some VCMDQs for the kernel/hypervisor to use. Like\nECMDQ, CMDQV also allows the kernel to use multiple VCMDQs, giving some\nlimited performance improvement: up to 20% reduction of TLB invalidation\ntime was measured by a multi-threaded DMA unmap benchmark, compared to a\nsingle queue.\n\nThe user-space support is to provide uAPIs (via IOMMUFD) for hypervisors\nin user space to passthrough VCMDQs to VMs, allowing these VMs to access\nthe VCMDQs directly without trappings, i.e. no VM Exits. This gives huge\nperformance improvements: 70% to 90% reductions of TLB invalidation time\nwere measured by various DMA unmap tests running in a guest OS, compared\nto a nested SMMU CMDQ (with trappings).\n\nThis is the part-1 series:\n - Preparatory changes to share the existing SMMU functions\n - A new CMDQV driver and extending the SMMUv3 driver to interact with\n the new driver\n - Limit the commands for a guest kernel.\n\nIt's available on Github:\nhttps://github.com/nicolinc/iommufd/commits/vcmdq_in_kernel-v14\n\nAnd the part-2 RFC series is also sent for discussion:\nhttps://lore.kernel.org/all/cover.1712978212.git.nicolinc@nvidia.com/\n\nNote that this in-kernel support isn't confined to host kernels running\non Grace-powered servers, but is also used by guest kernels running on\nVMs virtualized on those servers. So, those VMs must install the driver,\nideally before the part 2 is merged. So, later those servers would only\nneed to upgrade their host kernels without bothering the VMs.\n\nThank you!\n\nChangelog\nv14:\n * Rebased on Will's for-joerg/arm-smmu/updates\n * Added a missed kdoc for \"dev\" in struct tegra241_cmdqv\n * Dropped the default case in acpi_smmu_iort_probe_model()\nv13:\n https://lore.kernel.org/all/cover.1724453781.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc4\n * Fixed the lidx calculation in the isr()\n * Dropped the arm_smmu_get_iort_node from v12\n * Dropped the WARN_ON_ONCE in arm_smmu_cmdq_batch_init()\n * Replaced ARM_SMMU_OPT_SECONDARY_CMDQ_CS_NONE_ONLY with\n ARM_SMMU_OPT_TEGRA241_CMDQV for impl-level probe\n * Split the minimal cmdqv dsdt probe part from the tegra241_cmdqv\n to the common driver since it might run on other platforms too\n * Added an impl_dev to forward the device node to cmdqv driver so\n it can use it for prints and HW resources probe\n * Switched to the open-code approach provided by Will, replacing\n the patch \"Enforce arm_smmu_cmdq_build_sync_cmd\"\n * Added a supports_cmd op in the struct arm_smmu_cmdq, so as to\n scan the command at each arm_smmu_cmdq_batch_add call\nv12:\n https://lore.kernel.org/all/cover.1723754745.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc3\n * Added Jason's Reviewed-by\n * Added an arm_smmu_impl_probe helper\n * Added an arm_smmu_get_iort_node helper\n * Slightly updated the CMDQV acpi probe()\n * Added a static_assert() for smmu in struct tegra241_cmdqv\nv11:\n https://lore.kernel.org/all/cover.1722993435.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc2\n * Fixed \"vtinfs\" typo in kdoc\n * Maxed out the max_n_shift to hardware allowed value\nv10:\n https://lore.kernel.org/all/cover.1722206275.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc1\n * Added impl design mimicing arm-smmu (v2) driver\n * Replaced the CS_NONE quirk with a new smmu option\n * Fixed misaligned 64-bit register reading in the isr()\n * Explicitly assign opcode to arm_smmu_cmdq_batch_init() where\n cmd/ent might potentially not be initialized.\nv9:\n https://lore.kernel.org/all/cover.1718228494.git.nicolinc@nvidia.com/\n * Rebased on 6.10-rc3\n * Replaced \"base + offset\" in write_config() with REG helpers\n * Added \"Reviewed-by\" line from Jason, to the remaining PATCH-5\nv8:\n https://lore.kernel.org/all/cover.1716883239.git.nicolinc@nvidia.com/\n * Added \"Reviewed-by\" lines from Jason\n * Replaced memset with a simple \"cmd[1] = 0\"\n * Replaced MMIO read/write helpers with REG_* macros\n * Dropped the racy static string in lvcmdq_error_header()\n * Added a few lines of comments to arm_smmu_get_cmdq at the line\n calling tegra241_cmdqv_get_cmdq()\nv7:\n https://lore.kernel.org/all/cover.1715147377.git.nicolinc@nvidia.com/\n * Moved all public symbols into one single patch\n * Enforced a command batch to use the same cmdq\n * Enforced the use of arm_smmu_cmdq_build_sync_cmd()\n * Reworked the tegra241-cmdqv driver patch\n - Dropped logging macros, cmdqv->dev, and atomic\n - Dropped devm_* and added tegra241_cmdqv_device_remove()\n - Moved all structure allocations to cmdqv's probe() from\n device_reset() where only register configurations remains\n - Switched the config macros to inline functions\n - Optimized ISR routine with 64-bit reading MMIO\n - Scan once per batch against command list\n - Reorganized function locations\n - Minor readability changes\nv6:\n https://lore.kernel.org/all/cover.1714451595.git.nicolinc@nvidia.com/\n * Reordered the patch sequence to fix git-bisect break\n * Added a status cache to cmdqv/vintf/vcmdq structure\n * Added gerror/gerrorn value match in hw_deinit()\n * Minimized changes in __arm_smmu_cmdq_skip_err()\n * Preallocated VCMDQs to VINTFs for stablility\nv5:\n https://lore.kernel.org/all/cover.1712977210.git.nicolinc@nvidia.com/\n * Improved print/mmio helpers\n * Added proper register reset routines\n * Reorganized init/deinit functions to share with VIOMMU callbacks in\n the upcoming part-2 user-space series (RFC)\nv4:\n https://lore.kernel.org/all/cover.1711690673.git.nicolinc@nvidia.com/\n * Rebased on v6.9-rc1\n * Renamed to \"tegra241-cmdqv\", following other Grace kernel patches\n * Added a set of print and MMIO helpers\n * Reworked the guest limitation patch\nv3:\n https://lore.kernel.org/all/20211119071959.16706-1-nicolinc@nvidia.com/\n * Dropped VMID and mdev patches to redesign later based on IOMMUFD\n * Separated HYP_OWN part for guest support into a new patch\n * Added new preparatory changes\nv2:\n https://lore.kernel.org/all/20210831025923.15812-1-nicolinc@nvidia.com/\n * Added mdev interface support for hypervisor and VMs\n * Added preparatory changes for mdev interface implementation\n * PATCH-12 Changed ->issue_cmdlist() to ->get_cmdq() for a better\n integration with recently merged ECMDQ-related changes\nv1:\n https://lore.kernel.org/all/20210723193140.9690-1-nicolinc@nvidia.com/","shortMessageHtmlLink":"cover-letter: Add Tegra241 (Grace) CMDQV Support (part 1/2)"}},{"before":null,"after":"2667809feaa07f385950236c6991be9212fda521","ref":"refs/heads/vcmdq_in_kernel-v14","pushedAt":"2024-08-27T16:00:45.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"cover-letter: Add Tegra241 (Grace) CMDQV Support (part 1/2)\n\nNVIDIA's Tegra241 (Grace) SoC has a CMDQ-Virtualization (CMDQV) hardware\nthat extends standard ARM SMMUv3 to support multiple command queues with\nvirtualization capabilities. Though this is similar to the ECMDQ in SMMU\nv3.3, CMDQV provides additional Virtual Interfaces (VINTFs) allowing VMs\nto have their own VINTFs and Virtual Command Queues (VCMDQs). The VCMDQs\ncan only execute a limited set of commands, mainly invalidation commands\nwhen exclusively used by the VMs, compared to the standard SMMUv3 CMDQ.\n\nThus, there are two parts of patch series to add its support: the basic\nin-kernel support as part 1, and the user-space support as part 2.\n\nThe in-kernel support is to detect/configure the CMDQV hardware and then\nallocate a VINTF with some VCMDQs for the kernel/hypervisor to use. Like\nECMDQ, CMDQV also allows the kernel to use multiple VCMDQs, giving some\nlimited performance improvement: up to 20% reduction of TLB invalidation\ntime was measured by a multi-threaded DMA unmap benchmark, compared to a\nsingle queue.\n\nThe user-space support is to provide uAPIs (via IOMMUFD) for hypervisors\nin user space to passthrough VCMDQs to VMs, allowing these VMs to access\nthe VCMDQs directly without trappings, i.e. no VM Exits. This gives huge\nperformance improvements: 70% to 90% reductions of TLB invalidation time\nwere measured by various DMA unmap tests running in a guest OS, compared\nto a nested SMMU CMDQ (with trappings).\n\nThis is the part-1 series:\n - Preparatory changes to share the existing SMMU functions\n - A new CMDQV driver and extending the SMMUv3 driver to interact with\n the new driver\n - Limit the commands for a guest kernel.\n\nIt's available on Github:\nhttps://github.com/nicolinc/iommufd/commits/vcmdq_in_kernel-v14\n\nAnd the part-2 RFC series is also sent for discussion:\nhttps://lore.kernel.org/all/cover.1712978212.git.nicolinc@nvidia.com/\n\nNote that this in-kernel support isn't confined to host kernels running\non Grace-powered servers, but is also used by guest kernels running on\nVMs virtualized on those servers. So, those VMs must install the driver,\nideally before the part 2 is merged. So, later those servers would only\nneed to upgrade their host kernels without bothering the VMs.\n\nThank you!\n\nChangelog\nv14:\n * Rebased on Will's for-joerg/arm-smmu/updates\n * Added a missed kdoc for \"dev\" in struct tegra241_cmdqv\n * Dropped the default case in acpi_smmu_iort_probe_model()\nv13:\n https://lore.kernel.org/linux-iommu/cover.1724453781.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc4\n * Fixed the lidx calculation in the isr()\n * Dropped the arm_smmu_get_iort_node from v12\n * Dropped the WARN_ON_ONCE in arm_smmu_cmdq_batch_init()\n * Replaced ARM_SMMU_OPT_SECONDARY_CMDQ_CS_NONE_ONLY with\n ARM_SMMU_OPT_TEGRA241_CMDQV for impl-level probe\n * Split the minimal cmdqv dsdt probe part from the tegra241_cmdqv\n to the common driver since it might run on other platforms too\n * Added an impl_dev to forward the device node to cmdqv driver so\n it can use it for prints and HW resources probe\n * Switched to the open-code approach provided by Will, replacing\n the patch \"Enforce arm_smmu_cmdq_build_sync_cmd\"\n * Added a supports_cmd op in the struct arm_smmu_cmdq, so as to\n scan the command at each arm_smmu_cmdq_batch_add call\nv12:\n https://lore.kernel.org/all/cover.1723754745.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc3\n * Added Jason's Reviewed-by\n * Added an arm_smmu_impl_probe helper\n * Added an arm_smmu_get_iort_node helper\n * Slightly updated the CMDQV acpi probe()\n * Added a static_assert() for smmu in struct tegra241_cmdqv\nv11:\n https://lore.kernel.org/all/cover.1722993435.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc2\n * Fixed \"vtinfs\" typo in kdoc\n * Maxed out the max_n_shift to hardware allowed value\nv10:\n https://lore.kernel.org/all/cover.1722206275.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc1\n * Added impl design mimicing arm-smmu (v2) driver\n * Replaced the CS_NONE quirk with a new smmu option\n * Fixed misaligned 64-bit register reading in the isr()\n * Explicitly assign opcode to arm_smmu_cmdq_batch_init() where\n cmd/ent might potentially not be initialized.\nv9:\n https://lore.kernel.org/all/cover.1718228494.git.nicolinc@nvidia.com/\n * Rebased on 6.10-rc3\n * Replaced \"base + offset\" in write_config() with REG helpers\n * Added \"Reviewed-by\" line from Jason, to the remaining PATCH-5\nv8:\n https://lore.kernel.org/all/cover.1716883239.git.nicolinc@nvidia.com/\n * Added \"Reviewed-by\" lines from Jason\n * Replaced memset with a simple \"cmd[1] = 0\"\n * Replaced MMIO read/write helpers with REG_* macros\n * Dropped the racy static string in lvcmdq_error_header()\n * Added a few lines of comments to arm_smmu_get_cmdq at the line\n calling tegra241_cmdqv_get_cmdq()\nv7:\n https://lore.kernel.org/all/cover.1715147377.git.nicolinc@nvidia.com/\n * Moved all public symbols into one single patch\n * Enforced a command batch to use the same cmdq\n * Enforced the use of arm_smmu_cmdq_build_sync_cmd()\n * Reworked the tegra241-cmdqv driver patch\n - Dropped logging macros, cmdqv->dev, and atomic\n - Dropped devm_* and added tegra241_cmdqv_device_remove()\n - Moved all structure allocations to cmdqv's probe() from\n device_reset() where only register configurations remains\n - Switched the config macros to inline functions\n - Optimized ISR routine with 64-bit reading MMIO\n - Scan once per batch against command list\n - Reorganized function locations\n - Minor readability changes\nv6:\n https://lore.kernel.org/all/cover.1714451595.git.nicolinc@nvidia.com/\n * Reordered the patch sequence to fix git-bisect break\n * Added a status cache to cmdqv/vintf/vcmdq structure\n * Added gerror/gerrorn value match in hw_deinit()\n * Minimized changes in __arm_smmu_cmdq_skip_err()\n * Preallocated VCMDQs to VINTFs for stablility\nv5:\n https://lore.kernel.org/all/cover.1712977210.git.nicolinc@nvidia.com/\n * Improved print/mmio helpers\n * Added proper register reset routines\n * Reorganized init/deinit functions to share with VIOMMU callbacks in\n the upcoming part-2 user-space series (RFC)\nv4:\n https://lore.kernel.org/all/cover.1711690673.git.nicolinc@nvidia.com/\n * Rebased on v6.9-rc1\n * Renamed to \"tegra241-cmdqv\", following other Grace kernel patches\n * Added a set of print and MMIO helpers\n * Reworked the guest limitation patch\nv3:\n https://lore.kernel.org/all/20211119071959.16706-1-nicolinc@nvidia.com/\n * Dropped VMID and mdev patches to redesign later based on IOMMUFD\n * Separated HYP_OWN part for guest support into a new patch\n * Added new preparatory changes\nv2:\n https://lore.kernel.org/all/20210831025923.15812-1-nicolinc@nvidia.com/\n * Added mdev interface support for hypervisor and VMs\n * Added preparatory changes for mdev interface implementation\n * PATCH-12 Changed ->issue_cmdlist() to ->get_cmdq() for a better\n integration with recently merged ECMDQ-related changes\nv1:\n https://lore.kernel.org/all/20210723193140.9690-1-nicolinc@nvidia.com/","shortMessageHtmlLink":"cover-letter: Add Tegra241 (Grace) CMDQV Support (part 1/2)"}},{"before":"46a757e318e5d30a104a2f9ec1be99c08c786ea5","after":"c39b644b687ce5260ff8a2afbf6b62d99c61b6c7","ref":"refs/heads/iommufd_virq-v1","pushedAt":"2024-08-26T20:59:08.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-2 VIRQ)\n\nAs the part-2 of the VIOMMU infrastructure, this series introduces a VIRQ\nobject after repurposing the existing FAULT object, which provides a nice\nnotification pathway to the user space already. So, the first thing to do\nis reworking the FAULT object.\n\nMimicing the HWPT structures, add a common EVENT structure to support its\nderivatives: EVENT_IOPF (the prior FAULT object) and EVENT_VIRQ (new one).\nIOMMUFD_CMD_VIRQ_ALLOC is introduced to allocate EVENT_VIRQ for a VIOMMU.\nOne VIOMMU can have multiple VIRQs in different types but can not support\nmultiple VIRQs with the same types.\n\nDrivers might need the VIOMMU's vdev_id list or the exact vdev_id link of\nthe passthrough device's to forward IRQs/events via the VIOMMU framework.\nThus, extend the set/unset_vdev_id ioctls down to the driver using VIOMMU\nops. This allows drivers to take the control of a vdev_id's lifecycle.\n\nThe forwarding part is fairly simple but might need to replace a physical\ndevice ID with a virtual device ID. So, there comes with some helpers for\ndrivers to use.\n\nAs usual, this series comes with the selftest coverage for this new VIRQ,\nand with a real world use case in the ARM SMMUv3 driver.\n\nThis must be based on the VIOMMU Part-1 series. It's on Github:\nhttps://github.com/nicolinc/iommufd/commits/iommufd_virq-v1\nParing QEMU branch for testing:\nhttps://github.com/nicolinc/qemu/commits/wip/for_iommufd_virq-v1\n\nThanks!\nNicolin","shortMessageHtmlLink":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-2 VIRQ)"}},{"before":"6e0287626f15b4862d49ba6fc62f68d3deb60efa","after":"f994f840a31e45edd31f34f42a2d070493f3900f","ref":"refs/heads/iommufd_viommu_p1-v2","pushedAt":"2024-08-26T20:55:54.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-1)\n\nThis series introduces a new VIOMMU infrastructure and related ioctls.\n\nIOMMUFD has been using the HWPT infrastructure for all cases, including a\nnested IO page table support. Yet, there're limitations for an HWPT-based\nstructure to support some advanced HW-accelerated features, such as CMDQV\non NVIDIA Grace, and HW-accelerated vIOMMU on AMD. Even for a multi-IOMMU\nenvironment, it is not straightforward for nested HWPTs to share the same\nparent HWPT (stage-2 IO pagetable), with the HWPT infrastructure alone.\n\nThe new VIOMMU object is an additional layer, between the nested HWPT and\nits parent HWPT, to give to both the IOMMUFD core and an IOMMU driver an\nadditional structure to support HW-accelerated feature:\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested0 |--->| viommu0 ------------------\n ---------------- | | HW-accel feats |\n ----------------------------\n\nOn a multi-IOMMU system, the VIOMMU object can be instanced to the number\nof vIOMMUs in a guest VM, while holding the same parent HWPT to share the\nstage-2 IO pagetable. Each VIOMMU then just need to only allocate its own\nVMID to attach the shared stage-2 IO pagetable to the physical IOMMU:\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested0 |--->| viommu0 ------------------\n ---------------- | | VMID0 |\n ----------------------------\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested1 |--->| viommu1 ------------------\n ---------------- | | VMID1 |\n ----------------------------\n\nAs an initial part-1, add ioctls to support a VIOMMU-based invalidation:\n IOMMUFD_CMD_VIOMMU_ALLOC to allocate a VIOMMU object\n IOMMUFD_CMD_VIOMMU_SET/UNSET_VDEV_ID to set/clear device's virtual ID\n (Resue IOMMUFD_CMD_HWPT_INVALIDATE for a VIOMMU object to flush cache\n by a given driver data)\n\nWorth noting that the VDEV_ID is for a per-VIOMMU device list for drivers\nto look up the device's physical instance from its virtual ID in a VM. It\nis essential for a VIOMMU-based invalidation where the request contains a\ndevice's virtual ID for its device cache flush, e.g. ATC invalidation.\n\nAs for the implementation of the series, add an IOMMU_VIOMMU_TYPE_DEFAULT\ntype for a core-allocated-core-managed VIOMMU object, allowing drivers to\nsimply hook a default viommu ops for viommu-based invalidation alone. And\nprovide some viommu helpers to drivers for VDEV_ID translation and parent\ndomain lookup. Add VIOMMU invalidation support to ARM SMMUv3 driver for a\nreal world use case. This adds supports of arm-smmuv-v3's CMDQ_OP_ATC_INV\nand CMDQ_OP_CFGI_CD/ALL commands, supplementing HWPT-based invalidations.\n\nIn the future, drivers will also be able to choose a driver-managed type\nto hold its own structure by adding a new type to enum iommu_viommu_type.\nMore VIOMMU-based structures and ioctls will be introduced in part-2/3 to\nsupport a driver-managed VIOMMU, e.g. VQUEUE object for a HW accelerated\nqueue, VIRQ (or VEVENT) object for IRQ injections. Although we repurposed\nthe VIOMMU object from an earlier RFC discussion, for a referece:\nhttps://lore.kernel.org/all/cover.1712978212.git.nicolinc@nvidia.com/\n\nThis series is on Github:\nhttps://github.com/nicolinc/iommufd/commits/iommufd_viommu_p1-v2\nParing QEMU branch for testing:\nhttps://github.com/nicolinc/qemu/commits/wip/for_iommufd_viommu_p1-v2\n\nChangelog\nv2\n * Limited vdev_id to one per idev\n * Added a rw_sem to protect the vdev_id list\n * Reworked driver-level APIs with proper lockings\n * Added a new viommu_api file for IOMMUFD_DRIVER config\n * Dropped useless iommu_dev point from the viommu structure\n * Added missing index numnbers to new types in the uAPI header\n * Dropped IOMMU_VIOMMU_INVALIDATE uAPI; Instead, reuse the HWPT one\n * Reworked mock_viommu_cache_invalidate() using the new iommu helper\n * Reordered details of set/unset_vdev_id handlers for proper lockings\nv1\n https://lore.kernel.org/all/cover.1723061377.git.nicolinc@nvidia.com/\n\nThanks!\nNicolin","shortMessageHtmlLink":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-1)"}},{"before":"e31adbd4d14b3cbe5b6abcd1ab30adf3fa2e2620","after":"b3170de82892e6147b78677d89d5f1073eafa6fc","ref":"refs/heads/vcmdq_in_kernel-v13","pushedAt":"2024-08-23T22:56:00.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"cover-letter: Add Tegra241 (Grace) CMDQV Support (part 1/2)\n\nNVIDIA's Tegra241 (Grace) SoC has a CMDQ-Virtualization (CMDQV) hardware\nthat extends standard ARM SMMUv3 to support multiple command queues with\nvirtualization capabilities. Though this is similar to the ECMDQ in SMMU\nv3.3, CMDQV provides additional Virtual Interfaces (VINTFs) allowing VMs\nto have their own VINTFs and Virtual Command Queues (VCMDQs). The VCMDQs\ncan only execute a limited set of commands, mainly invalidation commands\nwhen exclusively used by the VMs, compared to the standard SMMUv3 CMDQ.\n\nThus, there are two parts of patch series to add its support: the basic\nin-kernel support as part 1, and the user-space support as part 2.\n\nThe in-kernel support is to detect/configure the CMDQV hardware and then\nallocate a VINTF with some VCMDQs for the kernel/hypervisor to use. Like\nECMDQ, CMDQV also allows the kernel to use multiple VCMDQs, giving some\nlimited performance improvement: up to 20% reduction of TLB invalidation\ntime was measured by a multi-threaded DMA unmap benchmark, compared to a\nsingle queue.\n\nThe user-space support is to provide uAPIs (via IOMMUFD) for hypervisors\nin user space to passthrough VCMDQs to VMs, allowing these VMs to access\nthe VCMDQs directly without trappings, i.e. no VM Exits. This gives huge\nperformance improvements: 70% to 90% reductions of TLB invalidation time\nwere measured by various DMA unmap tests running in a guest OS, compared\nto a nested SMMU CMDQ (with trappings).\n\nThis is the part-1 series:\n - Preparatory changes to share the existing SMMU functions\n - A new CMDQV driver and extending the SMMUv3 driver to interact with\n the new driver\n - Limit the commands for a guest kernel.\n\nIt's available on Github:\nhttps://github.com/nicolinc/iommufd/commits/vcmdq_in_kernel-v13\n\nAnd the part-2 RFC series is also sent for discussion:\nhttps://lore.kernel.org/all/cover.1712978212.git.nicolinc@nvidia.com/\n\nNote that this in-kernel support isn't confined to host kernels running\non Grace-powered servers, but is also used by guest kernels running on\nVMs virtualized on those servers. So, those VMs must install the driver,\nideally before the part 2 is merged. So, later those servers would only\nneed to upgrade their host kernels without bothering the VMs.\n\nThank you!\n\nChangelog\nv13:\n * Rebased on 6.11-rc4\n * Fixed the lidx calculation in the isr()\n * Dropped the arm_smmu_get_iort_node from v12\n * Dropped the WARN_ON_ONCE in arm_smmu_cmdq_batch_init()\n * Replaced ARM_SMMU_OPT_SECONDARY_CMDQ_CS_NONE_ONLY with\n ARM_SMMU_OPT_TEGRA241_CMDQV for impl-level probe\n * Split the minimal cmdqv dsdt probe part from the tegra241_cmdqv\n to the common driver since it might run on other platforms too\n * Added an impl_dev to forward the device node to cmdqv driver so\n it can use it for prints and HW resources probe\n * Switched to the open-code approach provided by Will, replacing\n the patch \"Enforce arm_smmu_cmdq_build_sync_cmd\"\n * Added a supports_cmd op in the struct arm_smmu_cmdq, so as to\n scan the command at each arm_smmu_cmdq_batch_add call\nv12:\n https://lore.kernel.org/all/cover.1723754745.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc3\n * Added Jason's Reviewed-by\n * Added an arm_smmu_impl_probe helper\n * Added an arm_smmu_get_iort_node helper\n * Slightly updated the CMDQV acpi probe()\n * Added a static_assert() for smmu in struct tegra241_cmdqv\nv11:\n https://lore.kernel.org/all/cover.1722993435.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc2\n * Fixed \"vtinfs\" typo in kdoc\n * Maxed out the max_n_shift to hardware allowed value\nv10:\n https://lore.kernel.org/all/cover.1722206275.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc1\n * Added impl design mimicing arm-smmu (v2) driver\n * Replaced the CS_NONE quirk with a new smmu option\n * Fixed misaligned 64-bit register reading in the isr()\n * Explicitly assign opcode to arm_smmu_cmdq_batch_init() where\n cmd/ent might potentially not be initialized.\nv9:\n https://lore.kernel.org/all/cover.1718228494.git.nicolinc@nvidia.com/\n * Rebased on 6.10-rc3\n * Replaced \"base + offset\" in write_config() with REG helpers\n * Added \"Reviewed-by\" line from Jason, to the remaining PATCH-5\nv8:\n https://lore.kernel.org/all/cover.1716883239.git.nicolinc@nvidia.com/\n * Added \"Reviewed-by\" lines from Jason\n * Replaced memset with a simple \"cmd[1] = 0\"\n * Replaced MMIO read/write helpers with REG_* macros\n * Dropped the racy static string in lvcmdq_error_header()\n * Added a few lines of comments to arm_smmu_get_cmdq at the line\n calling tegra241_cmdqv_get_cmdq()\nv7:\n https://lore.kernel.org/all/cover.1715147377.git.nicolinc@nvidia.com/\n * Moved all public symbols into one single patch\n * Enforced a command batch to use the same cmdq\n * Enforced the use of arm_smmu_cmdq_build_sync_cmd()\n * Reworked the tegra241-cmdqv driver patch\n - Dropped logging macros, cmdqv->dev, and atomic\n - Dropped devm_* and added tegra241_cmdqv_device_remove()\n - Moved all structure allocations to cmdqv's probe() from\n device_reset() where only register configurations remains\n - Switched the config macros to inline functions\n - Optimized ISR routine with 64-bit reading MMIO\n - Scan once per batch against command list\n - Reorganized function locations\n - Minor readability changes\nv6:\n https://lore.kernel.org/all/cover.1714451595.git.nicolinc@nvidia.com/\n * Reordered the patch sequence to fix git-bisect break\n * Added a status cache to cmdqv/vintf/vcmdq structure\n * Added gerror/gerrorn value match in hw_deinit()\n * Minimized changes in __arm_smmu_cmdq_skip_err()\n * Preallocated VCMDQs to VINTFs for stablility\nv5:\n https://lore.kernel.org/all/cover.1712977210.git.nicolinc@nvidia.com/\n * Improved print/mmio helpers\n * Added proper register reset routines\n * Reorganized init/deinit functions to share with VIOMMU callbacks in\n the upcoming part-2 user-space series (RFC)\nv4:\n https://lore.kernel.org/all/cover.1711690673.git.nicolinc@nvidia.com/\n * Rebased on v6.9-rc1\n * Renamed to \"tegra241-cmdqv\", following other Grace kernel patches\n * Added a set of print and MMIO helpers\n * Reworked the guest limitation patch\nv3:\n https://lore.kernel.org/all/20211119071959.16706-1-nicolinc@nvidia.com/\n * Dropped VMID and mdev patches to redesign later based on IOMMUFD\n * Separated HYP_OWN part for guest support into a new patch\n * Added new preparatory changes\nv2:\n https://lore.kernel.org/all/20210831025923.15812-1-nicolinc@nvidia.com/\n * Added mdev interface support for hypervisor and VMs\n * Added preparatory changes for mdev interface implementation\n * PATCH-12 Changed ->issue_cmdlist() to ->get_cmdq() for a better\n integration with recently merged ECMDQ-related changes\nv1:\n https://lore.kernel.org/all/20210723193140.9690-1-nicolinc@nvidia.com/","shortMessageHtmlLink":"cover-letter: Add Tegra241 (Grace) CMDQV Support (part 1/2)"}},{"before":"6bc1b56bd53f63528f90f6fc93b33fdd8b754375","after":"e31adbd4d14b3cbe5b6abcd1ab30adf3fa2e2620","ref":"refs/heads/vcmdq_in_kernel-v13","pushedAt":"2024-08-23T22:48:24.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"cover-letter: Add Tegra241 (Grace) CMDQV Support (part 1/2)\n\nNVIDIA's Tegra241 (Grace) SoC has a CMDQ-Virtualization (CMDQV) hardware\nthat extends standard ARM SMMUv3 to support multiple command queues with\nvirtualization capabilities. Though this is similar to the ECMDQ in SMMU\nv3.3, CMDQV provides additional Virtual Interfaces (VINTFs) allowing VMs\nto have their own VINTFs and Virtual Command Queues (VCMDQs). The VCMDQs\ncan only execute a limited set of commands, mainly invalidation commands\nwhen exclusively used by the VMs, compared to the standard SMMUv3 CMDQ.\n\nThus, there are two parts of patch series to add its support: the basic\nin-kernel support as part 1, and the user-space support as part 2.\n\nThe in-kernel support is to detect/configure the CMDQV hardware and then\nallocate a VINTF with some VCMDQs for the kernel/hypervisor to use. Like\nECMDQ, CMDQV also allows the kernel to use multiple VCMDQs, giving some\nlimited performance improvement: up to 20% reduction of TLB invalidation\ntime was measured by a multi-threaded DMA unmap benchmark, compared to a\nsingle queue.\n\nThe user-space support is to provide uAPIs (via IOMMUFD) for hypervisors\nin user space to passthrough VCMDQs to VMs, allowing these VMs to access\nthe VCMDQs directly without trappings, i.e. no VM Exits. This gives huge\nperformance improvements: 70% to 90% reductions of TLB invalidation time\nwere measured by various DMA unmap tests running in a guest OS, compared\nto a nested SMMU CMDQ (with trappings).\n\nThis is the part-1 series:\n - Preparatory changes to share the existing SMMU functions\n - A new CMDQV driver and extending the SMMUv3 driver to interact with\n the new driver\n - Limit the commands for a guest kernel.\n\nIt's available on Github:\nhttps://github.com/nicolinc/iommufd/commits/vcmdq_in_kernel-v13\n\nAnd the part-2 RFC series is also sent for discussion:\nhttps://lore.kernel.org/all/cover.1712978212.git.nicolinc@nvidia.com/\n\nNote that this in-kernel support isn't confined to host kernels running\non Grace-powered servers, but is also used by guest kernels running on\nVMs virtualized on those servers. So, those VMs must install the driver,\nideally before the part 2 is merged. So, later those servers would only\nneed to upgrade their host kernels without bothering the VMs.\n\nThank you!\n\nChangelog\nv13:\n * Fixed the lidx calculation in the isr()\n * Dropped the arm_smmu_get_iort_node from v12\n * Dropped the WARN_ON_ONCE in arm_smmu_cmdq_batch_init()\n * Replaced ARM_SMMU_OPT_SECONDARY_CMDQ_CS_NONE_ONLY with\n ARM_SMMU_OPT_TEGRA241_CMDQV for impl-level probe\n * Split the minimal cmdqv dsdt probe part from the tegra241_cmdqv\n to the common driver since it might run on other platforms too\n * Added an impl_dev to forward the device node to cmdqv driver so\n it can use it for prints and HW resources probe\n * Switched to the open-code approach provided by Will, replacing\n the patch \"Enforce arm_smmu_cmdq_build_sync_cmd\"\n * Added a supports_cmd op in the struct arm_smmu_cmdq, so as to\n scan the command at each arm_smmu_cmdq_batch_add call\nv12:\n https://lore.kernel.org/all/cover.1723754745.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc3\n * Added Jason's Reviewed-by\n * Added an arm_smmu_impl_probe helper\n * Added an arm_smmu_get_iort_node helper\n * Slightly updated the CMDQV acpi probe()\n * Added a static_assert() for smmu in struct tegra241_cmdqv\nv11:\n https://lore.kernel.org/all/cover.1722993435.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc2\n * Fixed \"vtinfs\" typo in kdoc\n * Maxed out the max_n_shift to hardware allowed value\nv10:\n https://lore.kernel.org/all/cover.1722206275.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc1\n * Added impl design mimicing arm-smmu (v2) driver\n * Replaced the CS_NONE quirk with a new smmu option\n * Fixed misaligned 64-bit register reading in the isr()\n * Explicitly assign opcode to arm_smmu_cmdq_batch_init() where\n cmd/ent might potentially not be initialized.\nv9:\n https://lore.kernel.org/all/cover.1718228494.git.nicolinc@nvidia.com/\n * Rebased on 6.10-rc3\n * Replaced \"base + offset\" in write_config() with REG helpers\n * Added \"Reviewed-by\" line from Jason, to the remaining PATCH-5\nv8:\n https://lore.kernel.org/all/cover.1716883239.git.nicolinc@nvidia.com/\n * Added \"Reviewed-by\" lines from Jason\n * Replaced memset with a simple \"cmd[1] = 0\"\n * Replaced MMIO read/write helpers with REG_* macros\n * Dropped the racy static string in lvcmdq_error_header()\n * Added a few lines of comments to arm_smmu_get_cmdq at the line\n calling tegra241_cmdqv_get_cmdq()\nv7:\n https://lore.kernel.org/all/cover.1715147377.git.nicolinc@nvidia.com/\n * Moved all public symbols into one single patch\n * Enforced a command batch to use the same cmdq\n * Enforced the use of arm_smmu_cmdq_build_sync_cmd()\n * Reworked the tegra241-cmdqv driver patch\n - Dropped logging macros, cmdqv->dev, and atomic\n - Dropped devm_* and added tegra241_cmdqv_device_remove()\n - Moved all structure allocations to cmdqv's probe() from\n device_reset() where only register configurations remains\n - Switched the config macros to inline functions\n - Optimized ISR routine with 64-bit reading MMIO\n - Scan once per batch against command list\n - Reorganized function locations\n - Minor readability changes\nv6:\n https://lore.kernel.org/all/cover.1714451595.git.nicolinc@nvidia.com/\n * Reordered the patch sequence to fix git-bisect break\n * Added a status cache to cmdqv/vintf/vcmdq structure\n * Added gerror/gerrorn value match in hw_deinit()\n * Minimized changes in __arm_smmu_cmdq_skip_err()\n * Preallocated VCMDQs to VINTFs for stablility\nv5:\n https://lore.kernel.org/all/cover.1712977210.git.nicolinc@nvidia.com/\n * Improved print/mmio helpers\n * Added proper register reset routines\n * Reorganized init/deinit functions to share with VIOMMU callbacks in\n the upcoming part-2 user-space series (RFC)\nv4:\n https://lore.kernel.org/all/cover.1711690673.git.nicolinc@nvidia.com/\n * Rebased on v6.9-rc1\n * Renamed to \"tegra241-cmdqv\", following other Grace kernel patches\n * Added a set of print and MMIO helpers\n * Reworked the guest limitation patch\nv3:\n https://lore.kernel.org/all/20211119071959.16706-1-nicolinc@nvidia.com/\n * Dropped VMID and mdev patches to redesign later based on IOMMUFD\n * Separated HYP_OWN part for guest support into a new patch\n * Added new preparatory changes\nv2:\n https://lore.kernel.org/all/20210831025923.15812-1-nicolinc@nvidia.com/\n * Added mdev interface support for hypervisor and VMs\n * Added preparatory changes for mdev interface implementation\n * PATCH-12 Changed ->issue_cmdlist() to ->get_cmdq() for a better\n integration with recently merged ECMDQ-related changes\nv1:\n https://lore.kernel.org/all/20210723193140.9690-1-nicolinc@nvidia.com/","shortMessageHtmlLink":"cover-letter: Add Tegra241 (Grace) CMDQV Support (part 1/2)"}},{"before":"a00b46c7eca4788ce809c7bb32f9b3866cc65aa6","after":"6bc1b56bd53f63528f90f6fc93b33fdd8b754375","ref":"refs/heads/wip/vcmdq_in_kernel-v13","pushedAt":"2024-08-23T20:25:40.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"cover-letter: Add Tegra241 (Grace) CMDQV Support (part 1/2)\n\nNVIDIA's Tegra241 (Grace) SoC has a CMDQ-Virtualization (CMDQV) hardware\nthat extends standard ARM SMMUv3 to support multiple command queues with\nvirtualization capabilities. Though this is similar to the ECMDQ in SMMU\nv3.3, CMDQV provides additional Virtual Interfaces (VINTFs) allowing VMs\nto have their own VINTFs and Virtual Command Queues (VCMDQs). The VCMDQs\ncan only execute a limited set of commands, mainly invalidation commands\nwhen exclusively used by the VMs, compared to the standard SMMUv3 CMDQ.\n\nThus, there are two parts of patch series to add its support: the basic\nin-kernel support as part 1, and the user-space support as part 2.\n\nThe in-kernel support is to detect/configure the CMDQV hardware and then\nallocate a VINTF with some VCMDQs for the kernel/hypervisor to use. Like\nECMDQ, CMDQV also allows the kernel to use multiple VCMDQs, giving some\nlimited performance improvement: up to 20% reduction of TLB invalidation\ntime was measured by a multi-threaded DMA unmap benchmark, compared to a\nsingle queue.\n\nThe user-space support is to provide uAPIs (via IOMMUFD) for hypervisors\nin user space to passthrough VCMDQs to VMs, allowing these VMs to access\nthe VCMDQs directly without trappings, i.e. no VM Exits. This gives huge\nperformance improvements: 70% to 90% reductions of TLB invalidation time\nwere measured by various DMA unmap tests running in a guest OS, compared\nto a nested SMMU CMDQ (with trappings).\n\nThis is the part-1 series:\n - Preparatory changes to share the existing SMMU functions\n - A new CMDQV driver and extending the SMMUv3 driver to interact with\n the new driver\n - Limit the commands for a guest kernel.\n\nIt's available on Github:\nhttps://github.com/nicolinc/iommufd/commits/vcmdq_in_kernel-v13\n\nAnd the part-2 RFC series is also sent for discussion:\nhttps://lore.kernel.org/all/cover.1712978212.git.nicolinc@nvidia.com/\n\nNote that this in-kernel support isn't confined to host kernels running\non Grace-powered servers, but is also used by guest kernels running on\nVMs virtualized on those servers. So, those VMs must install the driver,\nideally before the part 2 is merged. So, later those servers would only\nneed to upgrade their host kernels without bothering the VMs.\n\nThank you!\n\nChangelog\nv13:\n * Fixed the lidx calculation in the isr()\n * Dropped the WARN_ON_ONCE in arm_smmu_cmdq_batch_init()\n * Switched to the open-code approach provided by Will, replacing\n the patch \"Enforce arm_smmu_cmdq_build_sync_cmd\"\n * Added a supports_cmd op in the struct arm_smmu_cmdq, so as to\n scan the command at each arm_smmu_cmdq_batch_add call\nv12:\n https://lore.kernel.org/all/cover.1723754745.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc3\n * Added Jason's Reviewed-by\n * Added an arm_smmu_impl_probe helper\n * Added an arm_smmu_get_iort_node helper\n * Slightly updated the CMDQV acpi probe()\n * Added a static_assert() for smmu in struct tegra241_cmdqv\nv11:\n https://lore.kernel.org/all/cover.1722993435.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc2\n * Fixed \"vtinfs\" typo in kdoc\n * Maxed out the max_n_shift to hardware allowed value\nv10:\n https://lore.kernel.org/all/cover.1722206275.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc1\n * Added impl design mimicing arm-smmu (v2) driver\n * Replaced the CS_NONE quirk with a new smmu option\n * Fixed misaligned 64-bit register reading in the isr()\n * Explicitly assign opcode to arm_smmu_cmdq_batch_init() where\n cmd/ent might potentially not be initialized.\nv9:\n https://lore.kernel.org/all/cover.1718228494.git.nicolinc@nvidia.com/\n * Rebased on 6.10-rc3\n * Replaced \"base + offset\" in write_config() with REG helpers\n * Added \"Reviewed-by\" line from Jason, to the remaining PATCH-5\nv8:\n https://lore.kernel.org/all/cover.1716883239.git.nicolinc@nvidia.com/\n * Added \"Reviewed-by\" lines from Jason\n * Replaced memset with a simple \"cmd[1] = 0\"\n * Replaced MMIO read/write helpers with REG_* macros\n * Dropped the racy static string in lvcmdq_error_header()\n * Added a few lines of comments to arm_smmu_get_cmdq at the line\n calling tegra241_cmdqv_get_cmdq()\nv7:\n https://lore.kernel.org/all/cover.1715147377.git.nicolinc@nvidia.com/\n * Moved all public symbols into one single patch\n * Enforced a command batch to use the same cmdq\n * Enforced the use of arm_smmu_cmdq_build_sync_cmd()\n * Reworked the tegra241-cmdqv driver patch\n - Dropped logging macros, cmdqv->dev, and atomic\n - Dropped devm_* and added tegra241_cmdqv_device_remove()\n - Moved all structure allocations to cmdqv's probe() from\n device_reset() where only register configurations remains\n - Switched the config macros to inline functions\n - Optimized ISR routine with 64-bit reading MMIO\n - Scan once per batch against command list\n - Reorganized function locations\n - Minor readability changes\nv6:\n https://lore.kernel.org/all/cover.1714451595.git.nicolinc@nvidia.com/\n * Reordered the patch sequence to fix git-bisect break\n * Added a status cache to cmdqv/vintf/vcmdq structure\n * Added gerror/gerrorn value match in hw_deinit()\n * Minimized changes in __arm_smmu_cmdq_skip_err()\n * Preallocated VCMDQs to VINTFs for stablility\nv5:\n https://lore.kernel.org/all/cover.1712977210.git.nicolinc@nvidia.com/\n * Improved print/mmio helpers\n * Added proper register reset routines\n * Reorganized init/deinit functions to share with VIOMMU callbacks in\n the upcoming part-2 user-space series (RFC)\nv4:\n https://lore.kernel.org/all/cover.1711690673.git.nicolinc@nvidia.com/\n * Rebased on v6.9-rc1\n * Renamed to \"tegra241-cmdqv\", following other Grace kernel patches\n * Added a set of print and MMIO helpers\n * Reworked the guest limitation patch\nv3:\n https://lore.kernel.org/all/20211119071959.16706-1-nicolinc@nvidia.com/\n * Dropped VMID and mdev patches to redesign later based on IOMMUFD\n * Separated HYP_OWN part for guest support into a new patch\n * Added new preparatory changes\nv2:\n https://lore.kernel.org/all/20210831025923.15812-1-nicolinc@nvidia.com/\n * Added mdev interface support for hypervisor and VMs\n * Added preparatory changes for mdev interface implementation\n * PATCH-12 Changed ->issue_cmdlist() to ->get_cmdq() for a better\n integration with recently merged ECMDQ-related changes\nv1:\n https://lore.kernel.org/all/20210723193140.9690-1-nicolinc@nvidia.com/","shortMessageHtmlLink":"cover-letter: Add Tegra241 (Grace) CMDQV Support (part 1/2)"}},{"before":null,"after":"a00b46c7eca4788ce809c7bb32f9b3866cc65aa6","ref":"refs/heads/wip/vcmdq_in_kernel-v13","pushedAt":"2024-08-23T20:24:45.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-1)\n\nThis series introduces a new VIOMMU infrastructure and related ioctls.\n\nIOMMUFD has been using the HWPT infrastructure for all cases, including a\nnested IO page table support. Yet, there're limitations for an HWPT-based\nstructure to support some advanced HW-accelerated features, such as CMDQV\non NVIDIA Grace, and HW-accelerated vIOMMU on AMD. Even for a multi-IOMMU\nenvironment, it is not straightforward for nested HWPTs to share the same\nparent HWPT (stage-2 IO pagetable), with the HWPT infrastructure alone.\n\nThe new VIOMMU object is an additional layer, between the nested HWPT and\nits parent HWPT, to give to both the IOMMUFD core and an IOMMU driver an\nadditional structure to support HW-accelerated feature:\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested0 |--->| viommu0 ------------------\n ---------------- | | HW-accel feats |\n ----------------------------\n\nOn a multi-IOMMU system, the VIOMMU object can be instanced to the number\nof vIOMMUs in a guest VM, while holding the same parent HWPT to share the\nstage-2 IO pagetable. Each VIOMMU then just need to only allocate its own\nVMID to attach the shared stage-2 IO pagetable to the physical IOMMU:\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested0 |--->| viommu0 ------------------\n ---------------- | | VMID0 |\n ----------------------------\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested1 |--->| viommu1 ------------------\n ---------------- | | VMID1 |\n ----------------------------\n\nAs an initial part-1, add ioctls to support a VIOMMU-based invalidation:\n IOMMUFD_CMD_VIOMMU_ALLOC to allocate a VIOMMU object\n IOMMUFD_CMD_VIOMMU_SET/UNSET_VDEV_ID to set/clear device's virtual ID\n IOMMUFD_CMD_VIOMMU_INVALIDATE to flush cache by a given driver data\n\nWorth noting that the VDEV_ID is for a per-VIOMMU device list for drivers\nto look up the device's physical instance from its virtual ID in a VM. It\nis essential for a VIOMMU-based invalidation where the request contains a\ndevice's virtual ID for its device cache flush, e.g. ATC invalidation.\n\nAs for the implementation of the series, add an IOMMU_VIOMMU_TYPE_DEFAULT\ntype for a core-allocated-core-managed VIOMMU object, allowing drivers to\nsimply hook a default viommu ops for viommu-based invalidation alone. And\nprovide some viommu helpers to drivers for VDEV_ID translation and parent\ndomain lookup. Introduce an IOMMU_VIOMMU_INVALIDATE_DATA_ARM_SMMUV3 for a\nreal world use case. This adds supports of arm-smmuv-v3's CMDQ_OP_ATC_INV\nand CMDQ_OP_CFGI_CD/ALL commands, supplementing HWPT-based invalidations.\n\nIn the future, drivers will also be able to choose a driver-managed type\nto hold its own structure by adding a new type to enum iommu_viommu_type.\nMore VIOMMU-based structures and ioctls will be introduced in part-2/3 to\nsupport a driver-managed VIOMMU, e.g. VQUEUE object for a HW accelerated\nqueue, VIRQ (or VEVENT) object for IRQ injections. Although we repurposed\nthe VIOMMU object from an earlier RFC discussion, for a referece:\nhttps://lore.kernel.org/all/cover.1712978212.git.nicolinc@nvidia.com/\n\nThis series is on Github:\nhttps://github.com/nicolinc/iommufd/commits/iommufd_viommu_p1-v2\n\nChangelog\nv2\n * Limited vdev_id to one per idev\n * Added a rw_sem to protect the vdev_id list\n * Reworked driver-level APIs with proper lockings\n * Added a new viommu_api file for IOMMUFD_DRIVER config\n * Dropped useless iommu_dev point from the viommu structure\n * Added missing index numnbers to new types in the uAPI header\n * Dropped IOMMU_VIOMMU_INVALIDATE uAPI; Instead, reuse the HWPT one\n * Reworked mock_viommu_cache_invalidate() using the new iommu helper\n * Reordered details of set/unset_vdev_id handlers for proper lockings\nv1\n https://lore.kernel.org/all/cover.1723061377.git.nicolinc@nvidia.com/\n\nThanks!\nNicolin","shortMessageHtmlLink":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-1)"}},{"before":"dffc651600a736bd0de8193e5c8fb4d836cc2a84","after":"46a757e318e5d30a104a2f9ec1be99c08c786ea5","ref":"refs/heads/iommufd_virq-v1","pushedAt":"2024-08-23T01:31:48.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-2 VIRQ)\n\nAs the part-2 of the VIOMMU infrastructure, this series introduces a VIRQ\nobject after repurposing the existing FAULT object, which provides a nice\nnotification pathway to the user space already. So, the first thing to do\nis reworking the FAULT object.\n\nMimicing the HWPT structures, add a common EVENT structure to support its\nderivatives: EVENT_IOPF (the prior FAULT object) and EVENT_VIRQ (new one).\nIOMMUFD_CMD_VIRQ_ALLOC is introduced to allocate EVENT_VIRQ for a VIOMMU.\nOne VIOMMU can have multiple VIRQs in different types but can not support\nmultiple VIRQs with the same types.\n\nDrivers might need the VIOMMU's vdev_id list or the exact vdev_id link of\nthe passthrough device's to forward IRQs/events via the VIOMMU framework.\nThus, extend the set/unset_vdev_id ioctls down to the driver using VIOMMU\nops. This allows drivers to take the control of a vdev_id's lifecycle.\n\nThe forwarding part is fairly simple but might need to replace a physical\ndevice ID with a virtual device ID. So, there comes with some helpers for\ndrivers to use.\n\nAs usual, this series comes with the selftest coverage for this new VIRQ,\nand with a real world use case in the ARM SMMUv3 driver.\n\nThis must be based on the VIOMMU Part-1 series. It's on Github:\nhttps://github.com/nicolinc/iommufd/commits/iommufd_virq-v1\nParing QEMU branch for testing:\nhttps://github.com/nicolinc/qemu/commits/wip/for_iommufd_virq-v1\n\nThanks!\nNicolin","shortMessageHtmlLink":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-2 VIRQ)"}},{"before":"df7e1cf5360bfca4fe40f436e1b569d40e86290b","after":"6e0287626f15b4862d49ba6fc62f68d3deb60efa","ref":"refs/heads/iommufd_viommu_p1-v2","pushedAt":"2024-08-23T01:31:41.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-1)\n\nThis series introduces a new VIOMMU infrastructure and related ioctls.\n\nIOMMUFD has been using the HWPT infrastructure for all cases, including a\nnested IO page table support. Yet, there're limitations for an HWPT-based\nstructure to support some advanced HW-accelerated features, such as CMDQV\non NVIDIA Grace, and HW-accelerated vIOMMU on AMD. Even for a multi-IOMMU\nenvironment, it is not straightforward for nested HWPTs to share the same\nparent HWPT (stage-2 IO pagetable), with the HWPT infrastructure alone.\n\nThe new VIOMMU object is an additional layer, between the nested HWPT and\nits parent HWPT, to give to both the IOMMUFD core and an IOMMU driver an\nadditional structure to support HW-accelerated feature:\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested0 |--->| viommu0 ------------------\n ---------------- | | HW-accel feats |\n ----------------------------\n\nOn a multi-IOMMU system, the VIOMMU object can be instanced to the number\nof vIOMMUs in a guest VM, while holding the same parent HWPT to share the\nstage-2 IO pagetable. Each VIOMMU then just need to only allocate its own\nVMID to attach the shared stage-2 IO pagetable to the physical IOMMU:\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested0 |--->| viommu0 ------------------\n ---------------- | | VMID0 |\n ----------------------------\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested1 |--->| viommu1 ------------------\n ---------------- | | VMID1 |\n ----------------------------\n\nAs an initial part-1, add ioctls to support a VIOMMU-based invalidation:\n IOMMUFD_CMD_VIOMMU_ALLOC to allocate a VIOMMU object\n IOMMUFD_CMD_VIOMMU_SET/UNSET_VDEV_ID to set/clear device's virtual ID\n (Resue IOMMUFD_CMD_HWPT_INVALIDATE for a VIOMMU object to flush cache\n by a given driver data)\n\nWorth noting that the VDEV_ID is for a per-VIOMMU device list for drivers\nto look up the device's physical instance from its virtual ID in a VM. It\nis essential for a VIOMMU-based invalidation where the request contains a\ndevice's virtual ID for its device cache flush, e.g. ATC invalidation.\n\nAs for the implementation of the series, add an IOMMU_VIOMMU_TYPE_DEFAULT\ntype for a core-allocated-core-managed VIOMMU object, allowing drivers to\nsimply hook a default viommu ops for viommu-based invalidation alone. And\nprovide some viommu helpers to drivers for VDEV_ID translation and parent\ndomain lookup. Add VIOMMU invalidation support to ARM SMMUv3 driver for a\nreal world use case. This adds supports of arm-smmuv-v3's CMDQ_OP_ATC_INV\nand CMDQ_OP_CFGI_CD/ALL commands, supplementing HWPT-based invalidations.\n\nIn the future, drivers will also be able to choose a driver-managed type\nto hold its own structure by adding a new type to enum iommu_viommu_type.\nMore VIOMMU-based structures and ioctls will be introduced in part-2/3 to\nsupport a driver-managed VIOMMU, e.g. VQUEUE object for a HW accelerated\nqueue, VIRQ (or VEVENT) object for IRQ injections. Although we repurposed\nthe VIOMMU object from an earlier RFC discussion, for a referece:\nhttps://lore.kernel.org/all/cover.1712978212.git.nicolinc@nvidia.com/\n\nThis series is on Github:\nhttps://github.com/nicolinc/iommufd/commits/iommufd_viommu_p1-v2\nParing QEMU branch for testing:\nhttps://github.com/nicolinc/qemu/commits/wip/for_iommufd_viommu_p1-v2\n\nChangelog\nv2\n * Limited vdev_id to one per idev\n * Added a rw_sem to protect the vdev_id list\n * Reworked driver-level APIs with proper lockings\n * Added a new viommu_api file for IOMMUFD_DRIVER config\n * Dropped useless iommu_dev point from the viommu structure\n * Added missing index numnbers to new types in the uAPI header\n * Dropped IOMMU_VIOMMU_INVALIDATE uAPI; Instead, reuse the HWPT one\n * Reworked mock_viommu_cache_invalidate() using the new iommu helper\n * Reordered details of set/unset_vdev_id handlers for proper lockings\nv1\n https://lore.kernel.org/all/cover.1723061377.git.nicolinc@nvidia.com/\n\nThanks!\nNicolin","shortMessageHtmlLink":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-1)"}},{"before":"372d58123fdf34f491bc44e2815be02d753bc463","after":"dffc651600a736bd0de8193e5c8fb4d836cc2a84","ref":"refs/heads/iommufd_virq-v1","pushedAt":"2024-08-23T01:02:37.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-2 VIRQ)\n\nAs the part-2 of the VIOMMU infrastructure, this series introduces a VIRQ\nobject after repurposing the existing FAULT object, which provides a nice\nnotification pathway to the user space already. So, the first thing to do\nis reworking the FAULT object.\n\nMimicing the HWPT structures, add a common EVENT structure to support its\nderivatives: EVENT_IOPF (the prior FAULT object) and EVENT_VIRQ (new one).\nIOMMUFD_CMD_VIRQ_ALLOC is introduced to allocate EVENT_VIRQ for a VIOMMU.\nOne VIOMMU can have multiple VIRQs in different types but can not support\nmultiple VIRQs with the same types.\n\nDrivers might need the VIOMMU's vdev_id list or the exact vdev_id link of\nthe passthrough device's to forward IRQs/events via the VIOMMU framework.\nThus, extend the set/unset_vdev_id ioctls down to the driver using VIOMMU\nops. This allows drivers to take the control of a vdev_id's lifecycle.\n\nThe forwarding part is fairly simple but might need to replace a physical\ndevice ID with a virtual device ID. So, there comes with some helpers for\ndrivers to use.\n\nAs usual, this series comes with the selftest coverage for this new VIRQ,\nand with a real world use case in the ARM SMMUv3 driver.\n\nThis must be based on the VIOMMU Part-1 series. It's on Github:\nhttps://github.com/nicolinc/iommufd/commits/iommufd_virq-v1\nParing QEMU branch for testing:\nhttps://github.com/nicolinc/qemu/commits/wip/for_iommufd_virq-v1\n\nThanks!\nNicolin","shortMessageHtmlLink":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-2 VIRQ)"}},{"before":"dc3a8528d32dcaf1a5598e345d979163e69d6641","after":"372d58123fdf34f491bc44e2815be02d753bc463","ref":"refs/heads/iommufd_virq-v1","pushedAt":"2024-08-22T07:08:27.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-2 VIRQ)\n\nAs the part-2 of the VIOMMU infrastructure, this series introduces a VIRQ\nobject after repurposing the existing FAULT object, which provides a nice\nnotification pathway to the user space already. So, the first thing to do\nis reworking the FAULT object.\n\nMimicing the HWPT structures, add a common EVENT structure to support its\nderivatives: EVENT_IOPF (the prior FAULT object) and EVENT_VIRQ (new one).\nIOMMUFD_CMD_VIRQ_ALLOC is introduced to allocate EVENT_VIRQ for a VIOMMU.\nOne VIOMMU can have multiple VIRQs in different types but can not support\nmultiple VIRQs with the same types.\n\nDrivers might need the VIOMMU's vdev_id list or the exact vdev_id link of\nthe passthrough device's to forward IRQs/events via the VIOMMU framework.\nThus, extend the set/unset_vdev_id ioctls down to the driver using VIOMMU\nops. This allows drivers to take the control of a vdev_id's lifecycle.\n\nThe forwarding part is fairly simple but might need to replace a physical\ndevice ID with a virtual device ID. So, there comes with some helpers for\ndrivers to use.\n\nAs usual, this series comes with the selftest coverage for this new VIRQ,\nand with a real world use case in the ARM SMMUv3 driver.\n\nThis must be based on the VIOMMU Part-1 series. It's on Github:\nhttps://github.com/nicolinc/iommufd/commits/iommufd_virq-v1\nParing QEMU branch for testing:\nhttps://github.com/nicolinc/qemu/commits/wip/for_iommufd_virq-v1\n\nThanks!\nNicolin","shortMessageHtmlLink":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-2 VIRQ)"}},{"before":"14fa17ecdbb44b93179f1d3325fa32259ccdd98b","after":"df7e1cf5360bfca4fe40f436e1b569d40e86290b","ref":"refs/heads/iommufd_viommu_p1-v2","pushedAt":"2024-08-22T06:51:42.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-1)\n\nThis series introduces a new VIOMMU infrastructure and related ioctls.\n\nIOMMUFD has been using the HWPT infrastructure for all cases, including a\nnested IO page table support. Yet, there're limitations for an HWPT-based\nstructure to support some advanced HW-accelerated features, such as CMDQV\non NVIDIA Grace, and HW-accelerated vIOMMU on AMD. Even for a multi-IOMMU\nenvironment, it is not straightforward for nested HWPTs to share the same\nparent HWPT (stage-2 IO pagetable), with the HWPT infrastructure alone.\n\nThe new VIOMMU object is an additional layer, between the nested HWPT and\nits parent HWPT, to give to both the IOMMUFD core and an IOMMU driver an\nadditional structure to support HW-accelerated feature:\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested0 |--->| viommu0 ------------------\n ---------------- | | HW-accel feats |\n ----------------------------\n\nOn a multi-IOMMU system, the VIOMMU object can be instanced to the number\nof vIOMMUs in a guest VM, while holding the same parent HWPT to share the\nstage-2 IO pagetable. Each VIOMMU then just need to only allocate its own\nVMID to attach the shared stage-2 IO pagetable to the physical IOMMU:\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested0 |--->| viommu0 ------------------\n ---------------- | | VMID0 |\n ----------------------------\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested1 |--->| viommu1 ------------------\n ---------------- | | VMID1 |\n ----------------------------\n\nAs an initial part-1, add ioctls to support a VIOMMU-based invalidation:\n IOMMUFD_CMD_VIOMMU_ALLOC to allocate a VIOMMU object\n IOMMUFD_CMD_VIOMMU_SET/UNSET_VDEV_ID to set/clear device's virtual ID\n (Resue IOMMUFD_CMD_HWPT_INVALIDATE for a VIOMMU object to flush cache\n by a given driver data)\n\nWorth noting that the VDEV_ID is for a per-VIOMMU device list for drivers\nto look up the device's physical instance from its virtual ID in a VM. It\nis essential for a VIOMMU-based invalidation where the request contains a\ndevice's virtual ID for its device cache flush, e.g. ATC invalidation.\n\nAs for the implementation of the series, add an IOMMU_VIOMMU_TYPE_DEFAULT\ntype for a core-allocated-core-managed VIOMMU object, allowing drivers to\nsimply hook a default viommu ops for viommu-based invalidation alone. And\nprovide some viommu helpers to drivers for VDEV_ID translation and parent\ndomain lookup. Add VIOMMU invalidation support to ARM SMMUv3 driver for a\nreal world use case. This adds supports of arm-smmuv-v3's CMDQ_OP_ATC_INV\nand CMDQ_OP_CFGI_CD/ALL commands, supplementing HWPT-based invalidations.\n\nIn the future, drivers will also be able to choose a driver-managed type\nto hold its own structure by adding a new type to enum iommu_viommu_type.\nMore VIOMMU-based structures and ioctls will be introduced in part-2/3 to\nsupport a driver-managed VIOMMU, e.g. VQUEUE object for a HW accelerated\nqueue, VIRQ (or VEVENT) object for IRQ injections. Although we repurposed\nthe VIOMMU object from an earlier RFC discussion, for a referece:\nhttps://lore.kernel.org/all/cover.1712978212.git.nicolinc@nvidia.com/\n\nThis series is on Github:\nhttps://github.com/nicolinc/iommufd/commits/iommufd_viommu_p1-v2\nParing QEMU branch for testing:\nhttps://github.com/nicolinc/qemu/commits/wip/for_iommufd_viommu_p1-v2\n\nChangelog\nv2\n * Limited vdev_id to one per idev\n * Added a rw_sem to protect the vdev_id list\n * Reworked driver-level APIs with proper lockings\n * Added a new viommu_api file for IOMMUFD_DRIVER config\n * Dropped useless iommu_dev point from the viommu structure\n * Added missing index numnbers to new types in the uAPI header\n * Dropped IOMMU_VIOMMU_INVALIDATE uAPI; Instead, reuse the HWPT one\n * Reworked mock_viommu_cache_invalidate() using the new iommu helper\n * Reordered details of set/unset_vdev_id handlers for proper lockings\nv1\n https://lore.kernel.org/all/cover.1723061377.git.nicolinc@nvidia.com/\n\nThanks!\nNicolin","shortMessageHtmlLink":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-1)"}},{"before":null,"after":"dc3a8528d32dcaf1a5598e345d979163e69d6641","ref":"refs/heads/iommufd_virq-v1","pushedAt":"2024-08-22T06:44:13.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-2 VIRQ)","shortMessageHtmlLink":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-2 VIRQ)"}},{"before":"a00b46c7eca4788ce809c7bb32f9b3866cc65aa6","after":"14fa17ecdbb44b93179f1d3325fa32259ccdd98b","ref":"refs/heads/iommufd_viommu_p1-v2","pushedAt":"2024-08-22T06:42:44.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-1)\n\nThis series introduces a new VIOMMU infrastructure and related ioctls.\n\nIOMMUFD has been using the HWPT infrastructure for all cases, including a\nnested IO page table support. Yet, there're limitations for an HWPT-based\nstructure to support some advanced HW-accelerated features, such as CMDQV\non NVIDIA Grace, and HW-accelerated vIOMMU on AMD. Even for a multi-IOMMU\nenvironment, it is not straightforward for nested HWPTs to share the same\nparent HWPT (stage-2 IO pagetable), with the HWPT infrastructure alone.\n\nThe new VIOMMU object is an additional layer, between the nested HWPT and\nits parent HWPT, to give to both the IOMMUFD core and an IOMMU driver an\nadditional structure to support HW-accelerated feature:\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested0 |--->| viommu0 ------------------\n ---------------- | | HW-accel feats |\n ----------------------------\n\nOn a multi-IOMMU system, the VIOMMU object can be instanced to the number\nof vIOMMUs in a guest VM, while holding the same parent HWPT to share the\nstage-2 IO pagetable. Each VIOMMU then just need to only allocate its own\nVMID to attach the shared stage-2 IO pagetable to the physical IOMMU:\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested0 |--->| viommu0 ------------------\n ---------------- | | VMID0 |\n ----------------------------\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested1 |--->| viommu1 ------------------\n ---------------- | | VMID1 |\n ----------------------------\n\nAs an initial part-1, add ioctls to support a VIOMMU-based invalidation:\n IOMMUFD_CMD_VIOMMU_ALLOC to allocate a VIOMMU object\n IOMMUFD_CMD_VIOMMU_SET/UNSET_VDEV_ID to set/clear device's virtual ID\n IOMMUFD_CMD_VIOMMU_INVALIDATE to flush cache by a given driver data\n\nWorth noting that the VDEV_ID is for a per-VIOMMU device list for drivers\nto look up the device's physical instance from its virtual ID in a VM. It\nis essential for a VIOMMU-based invalidation where the request contains a\ndevice's virtual ID for its device cache flush, e.g. ATC invalidation.\n\nAs for the implementation of the series, add an IOMMU_VIOMMU_TYPE_DEFAULT\ntype for a core-allocated-core-managed VIOMMU object, allowing drivers to\nsimply hook a default viommu ops for viommu-based invalidation alone. And\nprovide some viommu helpers to drivers for VDEV_ID translation and parent\ndomain lookup. Introduce an IOMMU_VIOMMU_INVALIDATE_DATA_ARM_SMMUV3 for a\nreal world use case. This adds supports of arm-smmuv-v3's CMDQ_OP_ATC_INV\nand CMDQ_OP_CFGI_CD/ALL commands, supplementing HWPT-based invalidations.\n\nIn the future, drivers will also be able to choose a driver-managed type\nto hold its own structure by adding a new type to enum iommu_viommu_type.\nMore VIOMMU-based structures and ioctls will be introduced in part-2/3 to\nsupport a driver-managed VIOMMU, e.g. VQUEUE object for a HW accelerated\nqueue, VIRQ (or VEVENT) object for IRQ injections. Although we repurposed\nthe VIOMMU object from an earlier RFC discussion, for a referece:\nhttps://lore.kernel.org/all/cover.1712978212.git.nicolinc@nvidia.com/\n\nThis series is on Github:\nhttps://github.com/nicolinc/iommufd/commits/iommufd_viommu_p1-v2\nParing QEMU branch for testing:\nhttps://github.com/nicolinc/qemu/commits/wip/for_iommufd_viommu_p1-v2\n\nChangelog\nv2\n * Limited vdev_id to one per idev\n * Added a rw_sem to protect the vdev_id list\n * Reworked driver-level APIs with proper lockings\n * Added a new viommu_api file for IOMMUFD_DRIVER config\n * Dropped useless iommu_dev point from the viommu structure\n * Added missing index numnbers to new types in the uAPI header\n * Dropped IOMMU_VIOMMU_INVALIDATE uAPI; Instead, reuse the HWPT one\n * Reworked mock_viommu_cache_invalidate() using the new iommu helper\n * Reordered details of set/unset_vdev_id handlers for proper lockings\nv1\n https://lore.kernel.org/all/cover.1723061377.git.nicolinc@nvidia.com/\n\nThanks!\nNicolin","shortMessageHtmlLink":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-1)"}},{"before":"417458dc0e06b9011f17df609eba4f0fcb11600c","after":"a00b46c7eca4788ce809c7bb32f9b3866cc65aa6","ref":"refs/heads/iommufd_viommu_p1-v2","pushedAt":"2024-08-22T06:25:34.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-1)\n\nThis series introduces a new VIOMMU infrastructure and related ioctls.\n\nIOMMUFD has been using the HWPT infrastructure for all cases, including a\nnested IO page table support. Yet, there're limitations for an HWPT-based\nstructure to support some advanced HW-accelerated features, such as CMDQV\non NVIDIA Grace, and HW-accelerated vIOMMU on AMD. Even for a multi-IOMMU\nenvironment, it is not straightforward for nested HWPTs to share the same\nparent HWPT (stage-2 IO pagetable), with the HWPT infrastructure alone.\n\nThe new VIOMMU object is an additional layer, between the nested HWPT and\nits parent HWPT, to give to both the IOMMUFD core and an IOMMU driver an\nadditional structure to support HW-accelerated feature:\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested0 |--->| viommu0 ------------------\n ---------------- | | HW-accel feats |\n ----------------------------\n\nOn a multi-IOMMU system, the VIOMMU object can be instanced to the number\nof vIOMMUs in a guest VM, while holding the same parent HWPT to share the\nstage-2 IO pagetable. Each VIOMMU then just need to only allocate its own\nVMID to attach the shared stage-2 IO pagetable to the physical IOMMU:\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested0 |--->| viommu0 ------------------\n ---------------- | | VMID0 |\n ----------------------------\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested1 |--->| viommu1 ------------------\n ---------------- | | VMID1 |\n ----------------------------\n\nAs an initial part-1, add ioctls to support a VIOMMU-based invalidation:\n IOMMUFD_CMD_VIOMMU_ALLOC to allocate a VIOMMU object\n IOMMUFD_CMD_VIOMMU_SET/UNSET_VDEV_ID to set/clear device's virtual ID\n IOMMUFD_CMD_VIOMMU_INVALIDATE to flush cache by a given driver data\n\nWorth noting that the VDEV_ID is for a per-VIOMMU device list for drivers\nto look up the device's physical instance from its virtual ID in a VM. It\nis essential for a VIOMMU-based invalidation where the request contains a\ndevice's virtual ID for its device cache flush, e.g. ATC invalidation.\n\nAs for the implementation of the series, add an IOMMU_VIOMMU_TYPE_DEFAULT\ntype for a core-allocated-core-managed VIOMMU object, allowing drivers to\nsimply hook a default viommu ops for viommu-based invalidation alone. And\nprovide some viommu helpers to drivers for VDEV_ID translation and parent\ndomain lookup. Introduce an IOMMU_VIOMMU_INVALIDATE_DATA_ARM_SMMUV3 for a\nreal world use case. This adds supports of arm-smmuv-v3's CMDQ_OP_ATC_INV\nand CMDQ_OP_CFGI_CD/ALL commands, supplementing HWPT-based invalidations.\n\nIn the future, drivers will also be able to choose a driver-managed type\nto hold its own structure by adding a new type to enum iommu_viommu_type.\nMore VIOMMU-based structures and ioctls will be introduced in part-2/3 to\nsupport a driver-managed VIOMMU, e.g. VQUEUE object for a HW accelerated\nqueue, VIRQ (or VEVENT) object for IRQ injections. Although we repurposed\nthe VIOMMU object from an earlier RFC discussion, for a referece:\nhttps://lore.kernel.org/all/cover.1712978212.git.nicolinc@nvidia.com/\n\nThis series is on Github:\nhttps://github.com/nicolinc/iommufd/commits/iommufd_viommu_p1-v2\n\nChangelog\nv2\n * Limited vdev_id to one per idev\n * Added a rw_sem to protect the vdev_id list\n * Reworked driver-level APIs with proper lockings\n * Added a new viommu_api file for IOMMUFD_DRIVER config\n * Dropped useless iommu_dev point from the viommu structure\n * Added missing index numnbers to new types in the uAPI header\n * Dropped IOMMU_VIOMMU_INVALIDATE uAPI; Instead, reuse the HWPT one\n * Reworked mock_viommu_cache_invalidate() using the new iommu helper\n * Reordered details of set/unset_vdev_id handlers for proper lockings\nv1\n https://lore.kernel.org/all/cover.1723061377.git.nicolinc@nvidia.com/\n\nThanks!\nNicolin","shortMessageHtmlLink":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-1)"}},{"before":"1d137f69ea1917cd52488b726078c099986cf944","after":"417458dc0e06b9011f17df609eba4f0fcb11600c","ref":"refs/heads/iommufd_viommu_p1-v2","pushedAt":"2024-08-22T06:12:28.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-1)\n\nThis series introduces a new VIOMMU infrastructure and related ioctls.\n\nIOMMUFD has been using the HWPT infrastructure for all cases, including a\nnested IO page table support. Yet, there're limitations for an HWPT-based\nstructure to support some advanced HW-accelerated features, such as CMDQV\non NVIDIA Grace, and HW-accelerated vIOMMU on AMD. Even for a multi-IOMMU\nenvironment, it is not straightforward for nested HWPTs to share the same\nparent HWPT (stage-2 IO pagetable), with the HWPT infrastructure alone.\n\nThe new VIOMMU object is an additional layer, between the nested HWPT and\nits parent HWPT, to give to both the IOMMUFD core and an IOMMU driver an\nadditional structure to support HW-accelerated feature:\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested0 |--->| viommu0 ------------------\n ---------------- | | HW-accel feats |\n ----------------------------\n\nOn a multi-IOMMU system, the VIOMMU object can be instanced to the number\nof vIOMMUs in a guest VM, while holding the same parent HWPT to share the\nstage-2 IO pagetable. Each VIOMMU then just need to only allocate its own\nVMID to attach the shared stage-2 IO pagetable to the physical IOMMU:\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested0 |--->| viommu0 ------------------\n ---------------- | | VMID0 |\n ----------------------------\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested1 |--->| viommu1 ------------------\n ---------------- | | VMID1 |\n ----------------------------\n\nAs an initial part-1, add ioctls to support a VIOMMU-based invalidation:\n IOMMUFD_CMD_VIOMMU_ALLOC to allocate a VIOMMU object\n IOMMUFD_CMD_VIOMMU_SET/UNSET_VDEV_ID to set/clear device's virtual ID\n IOMMUFD_CMD_VIOMMU_INVALIDATE to flush cache by a given driver data\n\nWorth noting that the VDEV_ID is for a per-VIOMMU device list for drivers\nto look up the device's physical instance from its virtual ID in a VM. It\nis essential for a VIOMMU-based invalidation where the request contains a\ndevice's virtual ID for its device cache flush, e.g. ATC invalidation.\n\nAs for the implementation of the series, add an IOMMU_VIOMMU_TYPE_DEFAULT\ntype for a core-allocated-core-managed VIOMMU object, allowing drivers to\nsimply hook a default viommu ops for viommu-based invalidation alone. And\nprovide some viommu helpers to drivers for VDEV_ID translation and parent\ndomain lookup. Introduce an IOMMU_VIOMMU_INVALIDATE_DATA_ARM_SMMUV3 for a\nreal world use case. This adds supports of arm-smmuv-v3's CMDQ_OP_ATC_INV\nand CMDQ_OP_CFGI_CD/ALL commands, supplementing HWPT-based invalidations.\n\nIn the future, drivers will also be able to choose a driver-managed type\nto hold its own structure by adding a new type to enum iommu_viommu_type.\nMore VIOMMU-based structures and ioctls will be introduced in part-2/3 to\nsupport a driver-managed VIOMMU, e.g. VQUEUE object for a HW accelerated\nqueue, VIRQ (or VEVENT) object for IRQ injections. Although we repurposed\nthe VIOMMU object from an earlier RFC discussion, for a referece:\nhttps://lore.kernel.org/all/cover.1712978212.git.nicolinc@nvidia.com/\n\nThis series is on Github:\nhttps://github.com/nicolinc/iommufd/commits/iommufd_viommu_p1-v2\n\nChangelog\nv2\n * Limited vdev_id to one per idev\n * Added a rw_sem to protect the vdev_id list\n * Reworked driver-level APIs with proper lockings\n * Added a new viommu_api file for IOMMUFD_DRIVER config\n * Dropped useless iommu_dev point from the viommu structure\n * Added missing index numnbers to new types in the uAPI header\n * Dropped IOMMU_VIOMMU_INVALIDATE uAPI; Instead, reuse the HWPT one\n * Reworked mock_viommu_cache_invalidate() using the new iommu helper\n * Reordered details of set/unset_vdev_id handlers for proper lockings\nv1\n https://lore.kernel.org/all/cover.1723061377.git.nicolinc@nvidia.com/\n\nThanks!\nNicolin","shortMessageHtmlLink":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-1)"}},{"before":null,"after":"1d137f69ea1917cd52488b726078c099986cf944","ref":"refs/heads/iommufd_viommu_p1-v2","pushedAt":"2024-08-22T06:09:37.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-1)\n\nThis series introduces a new VIOMMU infrastructure and related ioctls.\n\nIOMMUFD has been using the HWPT infrastructure for all cases, including a\nnested IO page table support. Yet, there're limitations for an HWPT-based\nstructure to support some advanced HW-accelerated features, such as CMDQV\non NVIDIA Grace, and HW-accelerated vIOMMU on AMD. Even for a multi-IOMMU\nenvironment, it is not straightforward for nested HWPTs to share the same\nparent HWPT (stage-2 IO pagetable), with the HWPT infrastructure alone.\n\nThe new VIOMMU object is an additional layer, between the nested HWPT and\nits parent HWPT, to give to both the IOMMUFD core and an IOMMU driver an\nadditional structure to support HW-accelerated feature:\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested0 |--->| viommu0 ------------------\n ---------------- | | HW-accel feats |\n ----------------------------\n\nOn a multi-IOMMU system, the VIOMMU object can be instanced to the number\nof vIOMMUs in a guest VM, while holding the same parent HWPT to share the\nstage-2 IO pagetable. Each VIOMMU then just need to only allocate its own\nVMID to attach the shared stage-2 IO pagetable to the physical IOMMU:\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested0 |--->| viommu0 ------------------\n ---------------- | | VMID0 |\n ----------------------------\n ----------------------------\n ---------------- | | paging_hwpt0 |\n | hwpt_nested1 |--->| viommu1 ------------------\n ---------------- | | VMID1 |\n ----------------------------\n\nAs an initial part-1, add ioctls to support a VIOMMU-based invalidation:\n IOMMUFD_CMD_VIOMMU_ALLOC to allocate a VIOMMU object\n IOMMUFD_CMD_VIOMMU_SET/UNSET_VDEV_ID to set/clear device's virtual ID\n IOMMUFD_CMD_VIOMMU_INVALIDATE to flush cache by a given driver data\n\nWorth noting that the VDEV_ID is for a per-VIOMMU device list for drivers\nto look up the device's physical instance from its virtual ID in a VM. It\nis essential for a VIOMMU-based invalidation where the request contains a\ndevice's virtual ID for its device cache flush, e.g. ATC invalidation.\n\nAs for the implementation of the series, add an IOMMU_VIOMMU_TYPE_DEFAULT\ntype for a core-allocated-core-managed VIOMMU object, allowing drivers to\nsimply hook a default viommu ops for viommu-based invalidation alone. And\nprovide some viommu helpers to drivers for VDEV_ID translation and parent\ndomain lookup. Introduce an IOMMU_VIOMMU_INVALIDATE_DATA_ARM_SMMUV3 for a\nreal world use case. This adds supports of arm-smmuv-v3's CMDQ_OP_ATC_INV\nand CMDQ_OP_CFGI_CD/ALL commands, supplementing HWPT-based invalidations.\n\nIn the future, drivers will also be able to choose a driver-managed type\nto hold its own structure by adding a new type to enum iommu_viommu_type.\nMore VIOMMU-based structures and ioctls will be introduced in part-2/3 to\nsupport a driver-managed VIOMMU, e.g. VQUEUE object for a HW accelerated\nqueue, VIRQ (or VEVENT) object for IRQ injections. Although we repurposed\nthe VIOMMU object from an earlier RFC discussion, for a referece:\nhttps://lore.kernel.org/all/cover.1712978212.git.nicolinc@nvidia.com/\n\nThis series is on Github:\nhttps://github.com/nicolinc/iommufd/commits/iommufd_viommu_p1-v2\n\nChangelog\nv2\n * Limited vdev_id to one per idev\n * Added a rw_sem to protect the vdev_id list\n * Reworked driver-level APIs with proper lockings\n * Added a new viommu_api file for IOMMUFD_DRIVER config\n * Dropped useless iommu_dev point from the viommu structure\n * Added missing index numnbers to new types in the uAPI header\n * Dropped IOMMU_VIOMMU_INVALIDATE uAPI; Instead, reuse the HWPT one\n * Reworked mock_viommu_cache_invalidate() using the new iommu helper\n * Reordered details of set/unset_vdev_id handlers for proper lockings\nv1\n https://lore.kernel.org/all/cover.1723061377.git.nicolinc@nvidia.com/\n\nThanks!\nNicolin","shortMessageHtmlLink":"cover-letter: iommufd: Add VIOMMU infrastructure (Part-1)"}},{"before":"e3bed0b5fc2db754f152aac07c27c8f04f1cb0df","after":"6bc1b56bd53f63528f90f6fc93b33fdd8b754375","ref":"refs/heads/vcmdq_in_kernel-v13","pushedAt":"2024-08-20T00:34:42.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"cover-letter: Add Tegra241 (Grace) CMDQV Support (part 1/2)\n\nNVIDIA's Tegra241 (Grace) SoC has a CMDQ-Virtualization (CMDQV) hardware\nthat extends standard ARM SMMUv3 to support multiple command queues with\nvirtualization capabilities. Though this is similar to the ECMDQ in SMMU\nv3.3, CMDQV provides additional Virtual Interfaces (VINTFs) allowing VMs\nto have their own VINTFs and Virtual Command Queues (VCMDQs). The VCMDQs\ncan only execute a limited set of commands, mainly invalidation commands\nwhen exclusively used by the VMs, compared to the standard SMMUv3 CMDQ.\n\nThus, there are two parts of patch series to add its support: the basic\nin-kernel support as part 1, and the user-space support as part 2.\n\nThe in-kernel support is to detect/configure the CMDQV hardware and then\nallocate a VINTF with some VCMDQs for the kernel/hypervisor to use. Like\nECMDQ, CMDQV also allows the kernel to use multiple VCMDQs, giving some\nlimited performance improvement: up to 20% reduction of TLB invalidation\ntime was measured by a multi-threaded DMA unmap benchmark, compared to a\nsingle queue.\n\nThe user-space support is to provide uAPIs (via IOMMUFD) for hypervisors\nin user space to passthrough VCMDQs to VMs, allowing these VMs to access\nthe VCMDQs directly without trappings, i.e. no VM Exits. This gives huge\nperformance improvements: 70% to 90% reductions of TLB invalidation time\nwere measured by various DMA unmap tests running in a guest OS, compared\nto a nested SMMU CMDQ (with trappings).\n\nThis is the part-1 series:\n - Preparatory changes to share the existing SMMU functions\n - A new CMDQV driver and extending the SMMUv3 driver to interact with\n the new driver\n - Limit the commands for a guest kernel.\n\nIt's available on Github:\nhttps://github.com/nicolinc/iommufd/commits/vcmdq_in_kernel-v13\n\nAnd the part-2 RFC series is also sent for discussion:\nhttps://lore.kernel.org/all/cover.1712978212.git.nicolinc@nvidia.com/\n\nNote that this in-kernel support isn't confined to host kernels running\non Grace-powered servers, but is also used by guest kernels running on\nVMs virtualized on those servers. So, those VMs must install the driver,\nideally before the part 2 is merged. So, later those servers would only\nneed to upgrade their host kernels without bothering the VMs.\n\nThank you!\n\nChangelog\nv13:\n * Fixed the lidx calculation in the isr()\n * Dropped the WARN_ON_ONCE in arm_smmu_cmdq_batch_init()\n * Switched to the open-code approach provided by Will, replacing\n the patch \"Enforce arm_smmu_cmdq_build_sync_cmd\"\n * Added a supports_cmd op in the struct arm_smmu_cmdq, so as to\n scan the command at each arm_smmu_cmdq_batch_add call\nv12:\n https://lore.kernel.org/all/cover.1723754745.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc3\n * Added Jason's Reviewed-by\n * Added an arm_smmu_impl_probe helper\n * Added an arm_smmu_get_iort_node helper\n * Slightly updated the CMDQV acpi probe()\n * Added a static_assert() for smmu in struct tegra241_cmdqv\nv11:\n https://lore.kernel.org/all/cover.1722993435.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc2\n * Fixed \"vtinfs\" typo in kdoc\n * Maxed out the max_n_shift to hardware allowed value\nv10:\n https://lore.kernel.org/all/cover.1722206275.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc1\n * Added impl design mimicing arm-smmu (v2) driver\n * Replaced the CS_NONE quirk with a new smmu option\n * Fixed misaligned 64-bit register reading in the isr()\n * Explicitly assign opcode to arm_smmu_cmdq_batch_init() where\n cmd/ent might potentially not be initialized.\nv9:\n https://lore.kernel.org/all/cover.1718228494.git.nicolinc@nvidia.com/\n * Rebased on 6.10-rc3\n * Replaced \"base + offset\" in write_config() with REG helpers\n * Added \"Reviewed-by\" line from Jason, to the remaining PATCH-5\nv8:\n https://lore.kernel.org/all/cover.1716883239.git.nicolinc@nvidia.com/\n * Added \"Reviewed-by\" lines from Jason\n * Replaced memset with a simple \"cmd[1] = 0\"\n * Replaced MMIO read/write helpers with REG_* macros\n * Dropped the racy static string in lvcmdq_error_header()\n * Added a few lines of comments to arm_smmu_get_cmdq at the line\n calling tegra241_cmdqv_get_cmdq()\nv7:\n https://lore.kernel.org/all/cover.1715147377.git.nicolinc@nvidia.com/\n * Moved all public symbols into one single patch\n * Enforced a command batch to use the same cmdq\n * Enforced the use of arm_smmu_cmdq_build_sync_cmd()\n * Reworked the tegra241-cmdqv driver patch\n - Dropped logging macros, cmdqv->dev, and atomic\n - Dropped devm_* and added tegra241_cmdqv_device_remove()\n - Moved all structure allocations to cmdqv's probe() from\n device_reset() where only register configurations remains\n - Switched the config macros to inline functions\n - Optimized ISR routine with 64-bit reading MMIO\n - Scan once per batch against command list\n - Reorganized function locations\n - Minor readability changes\nv6:\n https://lore.kernel.org/all/cover.1714451595.git.nicolinc@nvidia.com/\n * Reordered the patch sequence to fix git-bisect break\n * Added a status cache to cmdqv/vintf/vcmdq structure\n * Added gerror/gerrorn value match in hw_deinit()\n * Minimized changes in __arm_smmu_cmdq_skip_err()\n * Preallocated VCMDQs to VINTFs for stablility\nv5:\n https://lore.kernel.org/all/cover.1712977210.git.nicolinc@nvidia.com/\n * Improved print/mmio helpers\n * Added proper register reset routines\n * Reorganized init/deinit functions to share with VIOMMU callbacks in\n the upcoming part-2 user-space series (RFC)\nv4:\n https://lore.kernel.org/all/cover.1711690673.git.nicolinc@nvidia.com/\n * Rebased on v6.9-rc1\n * Renamed to \"tegra241-cmdqv\", following other Grace kernel patches\n * Added a set of print and MMIO helpers\n * Reworked the guest limitation patch\nv3:\n https://lore.kernel.org/all/20211119071959.16706-1-nicolinc@nvidia.com/\n * Dropped VMID and mdev patches to redesign later based on IOMMUFD\n * Separated HYP_OWN part for guest support into a new patch\n * Added new preparatory changes\nv2:\n https://lore.kernel.org/all/20210831025923.15812-1-nicolinc@nvidia.com/\n * Added mdev interface support for hypervisor and VMs\n * Added preparatory changes for mdev interface implementation\n * PATCH-12 Changed ->issue_cmdlist() to ->get_cmdq() for a better\n integration with recently merged ECMDQ-related changes\nv1:\n https://lore.kernel.org/all/20210723193140.9690-1-nicolinc@nvidia.com/","shortMessageHtmlLink":"cover-letter: Add Tegra241 (Grace) CMDQV Support (part 1/2)"}},{"before":"deda8a1c9d7821776172fee5d3c0abf4411ea282","after":"e3bed0b5fc2db754f152aac07c27c8f04f1cb0df","ref":"refs/heads/vcmdq_in_kernel-v13","pushedAt":"2024-08-20T00:23:26.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"nicolinc","name":null,"path":"/nicolinc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89113456?s=80&v=4"},"commit":{"message":"cover-letter: Add Tegra241 (Grace) CMDQV Support (part 1/2)\n\nNVIDIA's Tegra241 (Grace) SoC has a CMDQ-Virtualization (CMDQV) hardware\nthat extends standard ARM SMMUv3 to support multiple command queues with\nvirtualization capabilities. Though this is similar to the ECMDQ in SMMU\nv3.3, CMDQV provides additional Virtual Interfaces (VINTFs) allowing VMs\nto have their own VINTFs and Virtual Command Queues (VCMDQs). The VCMDQs\ncan only execute a limited set of commands, mainly invalidation commands\nwhen exclusively used by the VMs, compared to the standard SMMUv3 CMDQ.\n\nThus, there are two parts of patch series to add its support: the basic\nin-kernel support as part 1, and the user-space support as part 2.\n\nThe in-kernel support is to detect/configure the CMDQV hardware and then\nallocate a VINTF with some VCMDQs for the kernel/hypervisor to use. Like\nECMDQ, CMDQV also allows the kernel to use multiple VCMDQs, giving some\nlimited performance improvement: up to 20% reduction of TLB invalidation\ntime was measured by a multi-threaded DMA unmap benchmark, compared to a\nsingle queue.\n\nThe user-space support is to provide uAPIs (via IOMMUFD) for hypervisors\nin user space to passthrough VCMDQs to VMs, allowing these VMs to access\nthe VCMDQs directly without trappings, i.e. no VM Exits. This gives huge\nperformance improvements: 70% to 90% reductions of TLB invalidation time\nwere measured by various DMA unmap tests running in a guest OS, compared\nto a nested SMMU CMDQ (with trappings).\n\nThis is the part-1 series:\n - Preparatory changes to share the existing SMMU functions\n - A new CMDQV driver and extending the SMMUv3 driver to interact with\n the new driver\n - Limit the commands for a guest kernel.\n\nIt's available on Github:\nhttps://github.com/nicolinc/iommufd/commits/vcmdq_in_kernel-v13\n\nAnd the part-2 RFC series is also sent for discussion:\nhttps://lore.kernel.org/all/cover.1712978212.git.nicolinc@nvidia.com/\n\nNote that this in-kernel support isn't confined to host kernels running\non Grace-powered servers, but is also used by guest kernels running on\nVMs virtualized on those servers. So, those VMs must install the driver,\nideally before the part 2 is merged. So, later those servers would only\nneed to upgrade their host kernels without bothering the VMs.\n\nThank you!\n\nChangelog\nv13:\n * Dropped the WARN_ON_ONCE in arm_smmu_cmdq_batch_init()\n * Switched to the open-code approach provided by Will, replacing\n the patch \"Enforce arm_smmu_cmdq_build_sync_cmd\"\n * Added a supports_cmd op in the struct arm_smmu_cmdq, so as to\n scan the command at each arm_smmu_cmdq_batch_add call\nv12:\n https://lore.kernel.org/all/cover.1723754745.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc3\n * Added Jason's Reviewed-by\n * Added an arm_smmu_impl_probe helper\n * Added an arm_smmu_get_iort_node helper\n * Slightly updated the CMDQV acpi probe()\n * Added a static_assert() for smmu in struct tegra241_cmdqv\nv11:\n https://lore.kernel.org/all/cover.1722993435.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc2\n * Fixed \"vtinfs\" typo in kdoc\n * Maxed out the max_n_shift to hardware allowed value\nv10:\n https://lore.kernel.org/all/cover.1722206275.git.nicolinc@nvidia.com/\n * Rebased on 6.11-rc1\n * Added impl design mimicing arm-smmu (v2) driver\n * Replaced the CS_NONE quirk with a new smmu option\n * Fixed misaligned 64-bit register reading in the isr()\n * Explicitly assign opcode to arm_smmu_cmdq_batch_init() where\n cmd/ent might potentially not be initialized.\nv9:\n https://lore.kernel.org/all/cover.1718228494.git.nicolinc@nvidia.com/\n * Rebased on 6.10-rc3\n * Replaced \"base + offset\" in write_config() with REG helpers\n * Added \"Reviewed-by\" line from Jason, to the remaining PATCH-5\nv8:\n https://lore.kernel.org/all/cover.1716883239.git.nicolinc@nvidia.com/\n * Added \"Reviewed-by\" lines from Jason\n * Replaced memset with a simple \"cmd[1] = 0\"\n * Replaced MMIO read/write helpers with REG_* macros\n * Dropped the racy static string in lvcmdq_error_header()\n * Added a few lines of comments to arm_smmu_get_cmdq at the line\n calling tegra241_cmdqv_get_cmdq()\nv7:\n https://lore.kernel.org/all/cover.1715147377.git.nicolinc@nvidia.com/\n * Moved all public symbols into one single patch\n * Enforced a command batch to use the same cmdq\n * Enforced the use of arm_smmu_cmdq_build_sync_cmd()\n * Reworked the tegra241-cmdqv driver patch\n - Dropped logging macros, cmdqv->dev, and atomic\n - Dropped devm_* and added tegra241_cmdqv_device_remove()\n - Moved all structure allocations to cmdqv's probe() from\n device_reset() where only register configurations remains\n - Switched the config macros to inline functions\n - Optimized ISR routine with 64-bit reading MMIO\n - Scan once per batch against command list\n - Reorganized function locations\n - Minor readability changes\nv6:\n https://lore.kernel.org/all/cover.1714451595.git.nicolinc@nvidia.com/\n * Reordered the patch sequence to fix git-bisect break\n * Added a status cache to cmdqv/vintf/vcmdq structure\n * Added gerror/gerrorn value match in hw_deinit()\n * Minimized changes in __arm_smmu_cmdq_skip_err()\n * Preallocated VCMDQs to VINTFs for stablility\nv5:\n https://lore.kernel.org/all/cover.1712977210.git.nicolinc@nvidia.com/\n * Improved print/mmio helpers\n * Added proper register reset routines\n * Reorganized init/deinit functions to share with VIOMMU callbacks in\n the upcoming part-2 user-space series (RFC)\nv4:\n https://lore.kernel.org/all/cover.1711690673.git.nicolinc@nvidia.com/\n * Rebased on v6.9-rc1\n * Renamed to \"tegra241-cmdqv\", following other Grace kernel patches\n * Added a set of print and MMIO helpers\n * Reworked the guest limitation patch\nv3:\n https://lore.kernel.org/all/20211119071959.16706-1-nicolinc@nvidia.com/\n * Dropped VMID and mdev patches to redesign later based on IOMMUFD\n * Separated HYP_OWN part for guest support into a new patch\n * Added new preparatory changes\nv2:\n https://lore.kernel.org/all/20210831025923.15812-1-nicolinc@nvidia.com/\n * Added mdev interface support for hypervisor and VMs\n * Added preparatory changes for mdev interface implementation\n * PATCH-12 Changed ->issue_cmdlist() to ->get_cmdq() for a better\n integration with recently merged ECMDQ-related changes\nv1:\n https://lore.kernel.org/all/20210723193140.9690-1-nicolinc@nvidia.com/","shortMessageHtmlLink":"cover-letter: Add Tegra241 (Grace) CMDQV Support (part 1/2)"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEr4vVBAA","startCursor":null,"endCursor":null}},"title":"Activity · nicolinc/iommufd"}