From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F1484C433E0 for ; Sat, 16 Jan 2021 03:56:01 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A9ABC23A55 for ; Sat, 16 Jan 2021 03:56:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A9ABC23A55 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:Subject: From:References:To:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=mmebx6C3680Nw1UYduL8Zuc//v4TW0iM8Rz9870/6Ew=; b=CyPrFGT8HDOTAjDgNQYyD2r8h dvnRiHxS+k75Ee2jrJEZfceOSsXkpUi8KS3osgL5UoRkV5I0IrCtU2Id0RWNwG/AONWkowZ38BUws UF9lU23Cog1lvw9g7f8+6Mx/wE3IvKSR/jI5TCgCVvJ8f1vaybQA6R+zqK9Rq9/DZGv0A0SvjrGxj HSqxNTrgTbICaJHI2zYeZmG9H+89T/oWuRevmaIZ1yk6pM5/w7/iBfR6/VUXmsLmBIlGP1NbVuHPm xljtqK5ofjXqRs3OzUOAM0nxmlhN1KdQFMSqrgMlMtW2pLclCAjmLxvCFBlliUVsNil8oWPfDwbp/ 7YAng56vQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l0cfM-0001KJ-Qp; Sat, 16 Jan 2021 03:54:20 +0000 Received: from mga04.intel.com ([192.55.52.120]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l0cfK-0001Je-Cq for linux-arm-kernel@lists.infradead.org; Sat, 16 Jan 2021 03:54:19 +0000 IronPort-SDR: omK5Kanr1JdMrmufSGUyLgJyzeuI8s3tFoubAmOzFbPDQ20kDFt01dIVtbL8GTTno+rHf6NEEe gI0PF7uSY4Lw== X-IronPort-AV: E=McAfee;i="6000,8403,9865"; a="176062736" X-IronPort-AV: E=Sophos;i="5.79,351,1602572400"; d="scan'208";a="176062736" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jan 2021 19:54:09 -0800 IronPort-SDR: 7RhNQTovQFrnfgsrcED9MhwANujPxOXtWf4Cq1X9OVAbauLpkRRAXSUed/tegFsW9b4aiT9/qz us0wXXg3dWaA== X-IronPort-AV: E=Sophos;i="5.79,351,1602572400"; d="scan'208";a="382896643" Received: from blu2-mobl3.ccr.corp.intel.com (HELO [10.249.175.94]) ([10.249.175.94]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jan 2021 19:54:03 -0800 To: Jean-Philippe Brucker , "Tian, Kevin" References: <20210108145217.2254447-1-jean-philippe@linaro.org> <20210108145217.2254447-4-jean-philippe@linaro.org> <4de8ef03-a2ed-316e-d3e3-6b8474e20113@linux.intel.com> From: Lu Baolu Subject: Re: [PATCH v9 03/10] iommu: Separate IOMMU_DEV_FEAT_IOPF from IOMMU_DEV_FEAT_SVA Message-ID: <636814a9-7dea-06f6-03ec-6a98dd30b7e3@linux.intel.com> Date: Sat, 16 Jan 2021 11:54:00 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210115_225418_636756_0A26CC1F X-CRM114-Status: GOOD ( 19.58 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Greg Kroah-Hartman , "vivek.gautam@arm.com" , "guohanjun@huawei.com" , "will@kernel.org" , "lorenzo.pieralisi@arm.com" , "joro@8bytes.org" , Zhou Wang , "linux-acpi@vger.kernel.org" , "zhangfei.gao@linaro.org" , "lenb@kernel.org" , "devicetree@vger.kernel.org" , Arnd Bergmann , "eric.auger@redhat.com" , "robh+dt@kernel.org" , "Jonathan.Cameron@huawei.com" , "linux-arm-kernel@lists.infradead.org" , David Woodhouse , "rjw@rjwysocki.net" , "shameerali.kolothum.thodi@huawei.com" , "iommu@lists.linux-foundation.org" , "sudeep.holla@arm.com" , "robin.murphy@arm.com" , "linux-accelerators@lists.ozlabs.org" , baolu.lu@linux.intel.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Jean, On 2021/1/15 0:41, Jean-Philippe Brucker wrote: > I guess detailing what's needed for nested IOPF can help the discussion, > although I haven't seen any concrete plan about implementing it, and it > still seems a couple of years away. There are two important steps with > nested IOPF: > > (1) Figuring out whether a fault comes from L1 or L2. A SMMU stall event > comes with this information, but a PRI page request doesn't. The IOMMU > driver has to first translate the IOVA to a GPA, injecting the fault > into the guest if this translation fails by using the usual > iommu_report_device_fault(). > > (2) Translating the faulting GPA to a HVA that can be fed to > handle_mm_fault(). That requires help from KVM, so another interface - > either KVM registering GPA->HVA translation tables or IOMMU driver > querying each translation. Either way it should be reusable by device > drivers that implement IOPF themselves. > > (1) could be enabled with iommu_dev_enable_feature(). (2) requires a more > complex interface. (2) alone might also be desirable - demand-paging for > level 2 only, no SVA for level 1. > > Anyway, back to this patch. What I'm trying to convey is "can the IOMMU > receive incoming I/O page faults for this device and, when SVA is enabled, > feed them to the mm subsystem? Enable that or return an error." I'm stuck > on the name. IOPF alone is too vague. Not IOPF_L1 as Kevin noted, since L1 > is also used in virtualization. IOPF_BIND and IOPF_SVA could also mean (2) > above. IOMMU_DEV_FEAT_IOPF_FLAT? > > That leaves space for the nested extensions. (1) above could be > IOMMU_FEAT_IOPF_NESTED, and (2) requires some new interfacing with KVM (or > just an external fault handler) and could be used with either IOPF_FLAT or > IOPF_NESTED. We can figure out the details later. What do you think? I agree that we can define IOPF_ for current usage and leave space for future extensions. IOPF_FLAT represents IOPF on first-level translation, currently first level translation could be used in below cases. 1) FL w/ internal Page Table: Kernel IOVA; 2) FL w/ external Page Table: VFIO passthrough; 3) FL w/ shared CPU page table: SVA We don't need to support IOPF for case 1). Let's put it aside. IOPF handling of 2) and 3) are different. Do we need to define different names to distinguish these two cases? Best regards, baolu _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel