Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2700237pxb; Tue, 23 Feb 2021 13:23:08 -0800 (PST) X-Google-Smtp-Source: ABdhPJyFEKsDAbXMaa+9IMp5GNAdWWId6clsTWtCVjOha+Uv4XUILCMI5jRiSFOkHNa38kEGAdzy X-Received: by 2002:a17:906:c30e:: with SMTP id s14mr12791249ejz.253.1614115388226; Tue, 23 Feb 2021 13:23:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614115388; cv=none; d=google.com; s=arc-20160816; b=EPGo3BnBOh2MB4DcXuA2wqlVeo5Tsu7fLfeUu9HDLoc1znQn++DD2s+Wd0Chdp2lsN Me2dnHHApSD34RKM8l+4/L+GZBLw8dWuesnF3ClivBlJE2OWjy18L1KURC9b+AeNTb+Z XS/cfBV8pwKfsZeX9io+a2ffTeVb0+HjmzIk/2TyIBT0uLLpfWFAKeKk/w433Tnc3xcZ lvv4AQ8WJ94pg6xKHK6W+VK9E4pS1w/U2JdKykJPWvMn4rcrnonk3PSWOjc6LFAxiqQu VPrm1e/RWXD7jN7/gG88G5KxNx62qlPDBia4DlgV4dz90HJfUcH8EhDYUh2fTJ95puUB WOOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=Rtjtw1poVfgkNxDSJEk53QVG2EcVM1YLyFA8X3R621o=; b=v59cyYSHUaBSKzRX7NgNJCHcdDY6/f7Tr4+2rLBfkhrfsP1z75nbgkK+Gu5QjZwBe/ lpUx1kECtQeaRxjQEiY2tyKabzpz/0HqcYRu1drItiwHefvxU+xePNmwT2yYV8UcIwOu tm9NR4nNEzqV8/z6Iq/cPhpbM8i1c9ubWlz1aF6/cDrFT7KtyyTnt7ydLMVLHdHfNywP /+3CRMS2aCEKeQBRYXi2pgEmy/5aT4CtL/4yxmMnpkCFYLrZgykhUIPKn8m1qLBScNqN RRQcYKSNq4wC9sxvwP1+tyRjDAZsX4F2M+QNCxRaOYCLql5/5NTb0o/QhJv8S0mAMnGF PJIQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=app+rctd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h19si15299857edt.159.2021.02.23.13.22.26; Tue, 23 Feb 2021 13:23:08 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=app+rctd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234610AbhBWVLX (ORCPT + 99 others); Tue, 23 Feb 2021 16:11:23 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:46776 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234263AbhBWVJO (ORCPT ); Tue, 23 Feb 2021 16:09:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1614114467; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=Rtjtw1poVfgkNxDSJEk53QVG2EcVM1YLyFA8X3R621o=; b=app+rctdlAuzytsODCLYmO3mfRrj80O/g2hbLbseYCcwS/MqJVSl+ydI72UyHJS6Dpf2uO Jd9c1Cs3t3oOxzgvU9BYRgaxEaLmxRzmAYqLEBRaemENGu96sGbvCUV4UP/asYv3sYLr++ EGtEyOMC1JP6VOQlA2RWJt3grEhc4co= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-47-bzSJvXt6NHOnRIBkfNXl-g-1; Tue, 23 Feb 2021 16:06:37 -0500 X-MC-Unique: bzSJvXt6NHOnRIBkfNXl-g-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AA46ECC620; Tue, 23 Feb 2021 21:06:33 +0000 (UTC) Received: from laptop.redhat.com (ovpn-114-34.ams2.redhat.com [10.36.114.34]) by smtp.corp.redhat.com (Postfix) with ESMTP id B69535D9D0; Tue, 23 Feb 2021 21:06:27 +0000 (UTC) From: Eric Auger To: eric.auger.pro@gmail.com, eric.auger@redhat.com, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, will@kernel.org, maz@kernel.org, robin.murphy@arm.com, joro@8bytes.org, alex.williamson@redhat.com, tn@semihalf.com, zhukeqian1@huawei.com Cc: jacob.jun.pan@linux.intel.com, yi.l.liu@intel.com, wangxingang5@huawei.com, jiangkunkun@huawei.com, jean-philippe@linaro.org, zhangfei.gao@linaro.org, zhangfei.gao@gmail.com, vivek.gautam@arm.com, shameerali.kolothum.thodi@huawei.com, yuzenghui@huawei.com, nicoleotsuka@gmail.com, lushenming@huawei.com, vsethi@nvidia.com Subject: [PATCH v12 00/13] SMMUv3 Nested Stage Setup (VFIO part) Date: Tue, 23 Feb 2021 22:06:12 +0100 Message-Id: <20210223210625.604517-1-eric.auger@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This series brings the VFIO part of HW nested paging support in the SMMUv3. This is a rebase on top of v5.11 The series depends on: [PATCH v14 00/13] SMMUv3 Nested Stage Setup (IOMMU part) 3 new IOCTLs are introduced that allow the userspace to 1) pass the guest stage 1 configuration 2) pass stage 1 MSI bindings 3) invalidate stage 1 related caches They map onto the related new IOMMU API functions. We introduce the capability to register specific interrupt indexes (see [1]). A new DMA_FAULT interrupt index allows to register an eventfd to be signaled whenever a stage 1 related fault is detected at physical level. Also two specific regions allow to - expose the fault records to the user space and - inject page responses. This latter functionality is not exercised in this series but is provided as a POC for further vSVA activities (Shameer's input). Best Regards Eric This series can be found at: https://github.com/eauger/linux/tree/v5.11-stallv12-2stage-v14 The series series includes Tina's patch steming from [1] "[RFC PATCH v2 1/3] vfio: Use capability chains to handle device specific irq" plus patches originally contributed by Yi. History: v11 -> v12: - numerous fixes following feedbacks. Many thanks to all of you - See individual history log. v10 -> v11: - rebase on top of v5.10-rc4 - adapt to changes on the IOMMU API (compliant with the doc written by Jacob/Yi) - addition of the page response region - Took into account Zenghui's comments - In this version I have kept the ioctl separate. Since Yi's series [2] is currently stalled, I've just rebased here. [2] [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs v9 -> v10 - rebase on top of 5.6.0-rc3 (no change versus v9) v8 -> v9: - introduce specific irq framework - single fault region - iommu_unregister_device_fault_handler failure case not handled yet. v7 -> v8: - rebase on top of v5.2-rc1 and especially 8be39a1a04c1 iommu/arm-smmu-v3: Add a master->domain pointer - dynamic alloc of s1_cfg/s2_cfg - __arm_smmu_tlb_inv_asid/s1_range_nosync - check there is no HW MSI regions - asid invalidation using pasid extended struct (change in the uapi) - add s1_live/s2_live checks - move check about support of nested stages in domain finalise - fixes in error reporting according to the discussion with Robin - reordered the patches to have first iommu/smmuv3 patches and then VFIO patches v6 -> v7: - removed device handle from bind/unbind_guest_msi - added "iommu/smmuv3: Nested mode single MSI doorbell per domain enforcement" - added few uapi comments as suggested by Jean, Jacop and Alex v5 -> v6: - Fix compilation issue when CONFIG_IOMMU_API is unset v4 -> v5: - fix bug reported by Vincent: fault handler unregistration now happens in vfio_pci_release - IOMMU_FAULT_PERM_* moved outside of struct definition + small uapi changes suggested by Kean-Philippe (except fetch_addr) - iommu: introduce device fault report API: removed the PRI part. - see individual logs for more details - reset the ste abort flag on detach v3 -> v4: - took into account Alex, jean-Philippe and Robin's comments on v3 - rework of the smmuv3 driver integration - add tear down ops for msi binding and PASID table binding - fix S1 fault propagation - put fault reporting patches at the beginning of the series following Jean-Philippe's request - update of the cache invalidate and fault API uapis - VFIO fault reporting rework with 2 separate regions and one mmappable segment for the fault queue - moved to PATCH v2 -> v3: - When registering the S1 MSI binding we now store the device handle. This addresses Robin's comment about discimination of devices beonging to different S1 groups and using different physical MSI doorbells. - Change the fault reporting API: use VFIO_PCI_DMA_FAULT_IRQ_INDEX to set the eventfd and expose the faults through an mmappable fault region v1 -> v2: - Added the fault reporting capability - asid properly passed on invalidation (fix assignment of multiple devices) - see individual change logs for more info Eric Auger (10): vfio: VFIO_IOMMU_SET_MSI_BINDING vfio/pci: Add VFIO_REGION_TYPE_NESTED region type vfio/pci: Register an iommu fault handler vfio/pci: Allow to mmap the fault queue vfio/pci: Add framework for custom interrupt indices vfio: Add new IRQ for DMA fault reporting vfio/pci: Register and allow DMA FAULT IRQ signaling vfio: Document nested stage control vfio/pci: Register a DMA fault response region vfio/pci: Inject page response upon response region fill Liu, Yi L (2): vfio: VFIO_IOMMU_SET_PASID_TABLE vfio: VFIO_IOMMU_CACHE_INVALIDATE Tina Zhang (1): vfio: Use capability chains to handle device specific irq Documentation/driver-api/vfio.rst | 77 +++++ drivers/vfio/pci/vfio_pci.c | 447 ++++++++++++++++++++++++++-- drivers/vfio/pci/vfio_pci_intrs.c | 62 ++++ drivers/vfio/pci/vfio_pci_private.h | 33 ++ drivers/vfio/pci/vfio_pci_rdwr.c | 84 ++++++ drivers/vfio/vfio_iommu_type1.c | 178 +++++++++++ include/uapi/linux/vfio.h | 141 ++++++++- 7 files changed, 1002 insertions(+), 20 deletions(-) -- 2.26.2