[{"id":1763315,"web_url":"http://patchwork.ozlabs.org/comment/1763315/","msgid":"<81fe1ebd-4197-56ce-13c1-24bb2ce858c0@arm.com>","list_archive_url":null,"date":"2017-09-05T12:52:47","subject":"Re: [RFC PATCH 1/6] dt-bindings: document stall and PASID properties\n\tfor IOMMU masters","submitter":{"id":68357,"url":"http://patchwork.ozlabs.org/api/people/68357/","name":"Jean-Philippe Brucker","email":"Jean-Philippe.Brucker@arm.com"},"content":"On 31/08/17 09:20, Yisheng Xie wrote:\n> From: Jean-Philippe Brucker \n> \n> Document the bindings for stall and PASID capable platform devices.\n> \n> Signed-off-by: Jean-Philippe Brucker \n\nHuh? No, I don't think I did. Please leave the patch as you found it, and\nask me for a version I consider clean next time.\n\nThanks,\nJean","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"knVT4wHz\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xmmlC04wxz9sRV\n\tfor ;\n\tTue, 5 Sep 2017 22:49:59 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpDIh-0006HW-6y; Tue, 05 Sep 2017 12:49:55 +0000","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]\n\thelo=foss.arm.com)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpDId-0006BA-Cl for linux-arm-kernel@lists.infradead.org;\n\tTue, 05 Sep 2017 12:49:52 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 19B2E165C;\n\tTue, 5 Sep 2017 05:49:31 -0700 (PDT)","from [10.1.211.72] (e106794-lin.cambridge.arm.com [10.1.211.72])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t87EFE3F3E1; Tue, 5 Sep 2017 05:49:27 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=s6R7Qu+ZSEk4REmG1kdNpgJjJBgs9S+EcS0ND3OI9E4=;\n\tb=knVT4wHzQwvims\n\tAYVXBea2Ta0QIU3esf7HEUZ2IJ/lodk3dFFGkIU9DQvnPQos5WXbvQvrmBJU1I4tbrxtlX0SkSkb5\n\tG1ODP7ripdP9s/pmHLDoU5XbL80WCxI+HL9UtTKUCKIERbKFSbXqG5L8/FPE8PiaMjwUrddjp2lA7\n\t54KfSXBIALEcQAIwBJMSBSYAD5Cp6x7iaw6oQCae/wdtAHnF/ddlX8fsZwDZv+gnAV9M+NiBWylLH\n\tAA+dUWz77ap5CdN6NrXBoPqxcfXU3yS4Z36HHT9+g4H4S/6nsdiFNgilrIUzxKayF/o6hHw8OTtM5\n\tAwlisFqrzOE9OCNtXSaA==;","Subject":"Re: [RFC PATCH 1/6] dt-bindings: document stall and PASID properties\n\tfor IOMMU masters","To":"Yisheng Xie ","References":"<1504167642-14922-1-git-send-email-xieyisheng1@huawei.com>\n\t<1504167642-14922-2-git-send-email-xieyisheng1@huawei.com>","From":"Jean-Philippe Brucker ","Message-ID":"<81fe1ebd-4197-56ce-13c1-24bb2ce858c0@arm.com>","Date":"Tue, 5 Sep 2017 13:52:47 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<1504167642-14922-2-git-send-email-xieyisheng1@huawei.com>","Content-Language":"en-US","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170905_054951_455399_A25A280B ","X-CRM114-Status":"UNSURE ( 6.11 )","X-CRM114-Notice":"Please train this message.","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, devicetree@vger.kernel.org,\n\tlorenzo.pieralisi@arm.com, \n\tlv.zheng@intel.com, will.deacon@arm.com, joro@8bytes.org,\n\tliubo95@huawei.com, rjw@rjwysocki.net, robert.moore@intel.com,\n\tlinux-kernel@vger.kernel.org, \n\tlinux-acpi@vger.kernel.org, iommu@lists.linux-foundation.org,\n\trobh+dt@kernel.org, hanjun.guo@linaro.org, xieyisheng@huawei.com,\n\tsudeep.holla@arm.com, chenjiankang1@huawei.com, devel@acpica.org,\n\trobin.murphy@arm.com, linux-arm-kernel@lists.infradead.org,\n\tlenb@kernel.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1763320,"web_url":"http://patchwork.ozlabs.org/comment/1763320/","msgid":"<923f307b-17f4-db04-9586-f27a949ce943@arm.com>","list_archive_url":null,"date":"2017-09-05T12:52:56","subject":"Re: [RFC PATCH 2/6] iommu/of: Add stall and pasid properties to\n\tiommu_fwspec","submitter":{"id":68357,"url":"http://patchwork.ozlabs.org/api/people/68357/","name":"Jean-Philippe Brucker","email":"Jean-Philippe.Brucker@arm.com"},"content":"On 31/08/17 09:20, Yisheng Xie wrote:\n> From: Jean-Philippe Brucker \n> \n> Add stall and pasid properties to iommu_fwspec.\n> \n> Signed-off-by: Jean-Philippe Brucker \n\nNo. This is a draft, I didn't sign it off.\n\nThanks,\nJean","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"EezftGr4\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xmmnN5SXqz9sRm\n\tfor ;\n\tTue, 5 Sep 2017 22:51:52 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpDKT-0008KU-Ue; Tue, 05 Sep 2017 12:51:45 +0000","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]\n\thelo=foss.arm.com)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpDIi-0006Da-9l for linux-arm-kernel@lists.infradead.org;\n\tTue, 05 Sep 2017 12:49:58 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 87D952B;\n\tTue, 5 Sep 2017 05:49:39 -0700 (PDT)","from [10.1.211.72] (e106794-lin.cambridge.arm.com [10.1.211.72])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\tDD4243F3E1; Tue, 5 Sep 2017 05:49:35 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=UUQ2tdlORxuCWGPWvJ3HhaXle0W4Os1InRCtfHmG5ZE=;\n\tb=EezftGr4jinFwP\n\tUnL9/ACn4rQVHKPasBGYJujQYPrHNuOOOEfcbHCigU1M145ldowCDAGgh2fPu4fra0o8Hl1BnCXFe\n\tF1DG2st88keeZtAgUV7yyfns33I40fz3wq5d2xJQ7C0XcHgzH12NdtC9T3Wuaa+STko9UKIKY0iD+\n\tJSa3lXzYsjBDW/lJ+0lpxTNdURVK8WQibhVhGoPr8sd617g0KcKWaNz21x2dEdEyQxtuDYKCQ1lIE\n\tQ8rStA96WwJuVq6kTl+kPdrwA7hPgjxjzksdgfuYvlasDJSAuwCh2b5mjjZzzA+p+eCF0w78b2p/b\n\tt5FDYdjf+hu9gIFFqesw==;","Subject":"Re: [RFC PATCH 2/6] iommu/of: Add stall and pasid properties to\n\tiommu_fwspec","To":"Yisheng Xie ","References":"<1504167642-14922-1-git-send-email-xieyisheng1@huawei.com>\n\t<1504167642-14922-3-git-send-email-xieyisheng1@huawei.com>","From":"Jean-Philippe Brucker ","Message-ID":"<923f307b-17f4-db04-9586-f27a949ce943@arm.com>","Date":"Tue, 5 Sep 2017 13:52:56 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<1504167642-14922-3-git-send-email-xieyisheng1@huawei.com>","Content-Language":"en-US","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170905_054956_423498_6750BF1F ","X-CRM114-Status":"UNSURE ( 5.75 )","X-CRM114-Notice":"Please train this message.","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, devicetree@vger.kernel.org,\n\tlorenzo.pieralisi@arm.com, \n\tlv.zheng@intel.com, will.deacon@arm.com, joro@8bytes.org,\n\tliubo95@huawei.com, rjw@rjwysocki.net, robert.moore@intel.com,\n\tlinux-kernel@vger.kernel.org, \n\tlinux-acpi@vger.kernel.org, iommu@lists.linux-foundation.org,\n\trobh+dt@kernel.org, hanjun.guo@linaro.org, xieyisheng@huawei.com,\n\tsudeep.holla@arm.com, chenjiankang1@huawei.com, devel@acpica.org,\n\trobin.murphy@arm.com, linux-arm-kernel@lists.infradead.org,\n\tlenb@kernel.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1763321,"web_url":"http://patchwork.ozlabs.org/comment/1763321/","msgid":"<039adc54-00f5-bf4e-e509-ffdc67baa15e@arm.com>","list_archive_url":null,"date":"2017-09-05T12:53:17","subject":"Re: [RFC PATCH 4/6] iommu/arm-smmu-v3: Add SVM support for platform\n\tdevices","submitter":{"id":68357,"url":"http://patchwork.ozlabs.org/api/people/68357/","name":"Jean-Philippe Brucker","email":"Jean-Philippe.Brucker@arm.com"},"content":"On 31/08/17 09:20, Yisheng Xie wrote:\n> From: Jean-Philippe Brucker \n> \n> Platform device can realise SVM function by using the stall mode. That\n> is to say, when device access a memory via iova which is not populated,\n> it will stalled and when SMMU try to translate this iova, it also will\n> stall and meanwhile send an event to CPU via MSI.\n> \n> After SMMU driver handle the event and populated the iova, it will send\n> a RESUME command to SMMU to exit the stall mode, therefore the platform\n> device can contiue access the memory.\n> \n> Signed-off-by: Jean-Philippe Brucker \n\nNo. Please don't forge a signed-off-by under a commit message you wrote,\nit's rude. I didn't sign it, didn't consider it fit for mainline or even\nas an RFC, and wanted to have another read before sending. My mistake,\nI'll think twice before sharing prototypes in the future.\n\nThanks,\nJean","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"Kj8wPJfY\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xmmng16xLz9sRV\n\tfor ;\n\tTue, 5 Sep 2017 22:52:07 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpDKm-0000FA-WF; Tue, 05 Sep 2017 12:52:05 +0000","from foss.arm.com ([217.140.101.70])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpDJ2-0006KZ-Br for linux-arm-kernel@lists.infradead.org;\n\tTue, 05 Sep 2017 12:50:17 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6BC402B;\n\tTue, 5 Sep 2017 05:50:00 -0700 (PDT)","from [10.1.211.72] (e106794-lin.cambridge.arm.com [10.1.211.72])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\tD49613F3E1; Tue, 5 Sep 2017 05:49:56 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=J1BbnvfgRmnKPAQ+FGIym6ppwKDNqff/mo6vzmdoZFk=;\n\tb=Kj8wPJfYjfSTif\n\toPloImNVzD5NuAnPbq2npubj/QTOl/H3+5rnLK1+ZuZmjSexAg3dWBNDuGpKVkyXhCXNUSDsW3bca\n\tZbHjeGDXOe9XvVZVYB0suS77yB6koqf+u32OwMkGpytO2mICT2+kdv71egH2ch+yxB9xgvUEVg4cm\n\tq4AGTCVrIodKAT5hgWACRJiqcEqla0uEc0hNivdMZTYpEHoWZ6T7tCp+XRRngQrDCKOoWq2A+wqiu\n\tJbNebaykv68+b2w5RdNTGmlX1dvOKnnJURu438pFszplHB9biq8x6MnQM5k6ySWi08cDfGIKHSvWy\n\t4I0j8lq1LtDAv8Sta8Eg==;","Subject":"Re: [RFC PATCH 4/6] iommu/arm-smmu-v3: Add SVM support for platform\n\tdevices","To":"Yisheng Xie ","References":"<1504167642-14922-1-git-send-email-xieyisheng1@huawei.com>\n\t<1504167642-14922-5-git-send-email-xieyisheng1@huawei.com>","From":"Jean-Philippe Brucker ","Message-ID":"<039adc54-00f5-bf4e-e509-ffdc67baa15e@arm.com>","Date":"Tue, 5 Sep 2017 13:53:17 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<1504167642-14922-5-git-send-email-xieyisheng1@huawei.com>","Content-Language":"en-US","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170905_055016_430047_C3BCF2C1 ","X-CRM114-Status":"UNSURE ( 9.19 )","X-CRM114-Notice":"Please train this message.","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, devicetree@vger.kernel.org,\n\tlorenzo.pieralisi@arm.com, \n\tlv.zheng@intel.com, will.deacon@arm.com, joro@8bytes.org,\n\tliubo95@huawei.com, rjw@rjwysocki.net, robert.moore@intel.com,\n\tlinux-kernel@vger.kernel.org, \n\tlinux-acpi@vger.kernel.org, iommu@lists.linux-foundation.org,\n\trobh+dt@kernel.org, hanjun.guo@linaro.org, xieyisheng@huawei.com,\n\tsudeep.holla@arm.com, chenjiankang1@huawei.com, devel@acpica.org,\n\trobin.murphy@arm.com, linux-arm-kernel@lists.infradead.org,\n\tlenb@kernel.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1763323,"web_url":"http://patchwork.ozlabs.org/comment/1763323/","msgid":"<738977bb-4cd7-7d86-0ea0-0c88b6af721c@arm.com>","list_archive_url":null,"date":"2017-09-05T12:54:19","subject":"Re: [RFC PATCH 6/6] iommu/arm-smmu-v3: Avoid ILLEGAL setting of\n\tSTE.S1STALLD and CD.S","submitter":{"id":68357,"url":"http://patchwork.ozlabs.org/api/people/68357/","name":"Jean-Philippe Brucker","email":"Jean-Philippe.Brucker@arm.com"},"content":"On 31/08/17 09:20, Yisheng Xie wrote:\n> It is ILLEGAL to set STE.S1STALLD if STALL_MODEL is not 0b00, which\n> means we should not disable stall mode if stall/terminate mode is not\n> configuable.\n> \n> Meanwhile, it is also ILLEGAL when STALL_MODEL==0b10 && CD.S==0 which\n> means if stall mode is force we should always set CD.S.\n> \n> This patch add ARM_SMMU_FEAT_TERMINATE feature bit for smmu, and use\n> TERMINATE feature checking to ensue above ILLEGAL cases from happening.\n> \n> Signed-off-by: Yisheng Xie \n> ---\n> drivers/iommu/arm-smmu-v3.c | 22 ++++++++++++++++------\n> 1 file changed, 16 insertions(+), 6 deletions(-)\n> \n> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c\n> index dbda2eb..0745522 100644\n> --- a/drivers/iommu/arm-smmu-v3.c\n> +++ b/drivers/iommu/arm-smmu-v3.c\n> @@ -55,6 +55,7 @@\n> #define IDR0_STALL_MODEL_SHIFT\t\t24\n> #define IDR0_STALL_MODEL_MASK\t\t0x3\n> #define IDR0_STALL_MODEL_STALL\t\t(0 << IDR0_STALL_MODEL_SHIFT)\n> +#define IDR0_STALL_MODEL_NS\t\t(1 << IDR0_STALL_MODEL_SHIFT)\n> #define IDR0_STALL_MODEL_FORCE\t\t(2 << IDR0_STALL_MODEL_SHIFT)\n> #define IDR0_TTENDIAN_SHIFT\t\t21\n> #define IDR0_TTENDIAN_MASK\t\t0x3\n> @@ -766,6 +767,7 @@ struct arm_smmu_device {\n> #define ARM_SMMU_FEAT_SVM\t\t(1 << 15)\n> #define ARM_SMMU_FEAT_HA\t\t(1 << 16)\n> #define ARM_SMMU_FEAT_HD\t\t(1 << 17)\n> +#define ARM_SMMU_FEAT_TERMINATE\t\t(1 << 18)\n\nI'd rather introduce something like \"ARM_SMMU_FEAT_STALL_FORCE\" instead.\nTerminate model has another meaning, and is defined by a different bit in\nIDR0.\n\nThanks,\nJean","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"IOs16H8k\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xmmp71w2Yz9sRV\n\tfor ;\n\tTue, 5 Sep 2017 22:52:31 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpDL7-0000bU-9s; Tue, 05 Sep 2017 12:52:25 +0000","from foss.arm.com ([217.140.101.70])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpDK6-00082s-HK for linux-arm-kernel@lists.infradead.org;\n\tTue, 05 Sep 2017 12:51:28 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6D79B2B;\n\tTue, 5 Sep 2017 05:51:02 -0700 (PDT)","from [10.1.211.72] (e106794-lin.cambridge.arm.com [10.1.211.72])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\tE22E03F3E1; Tue, 5 Sep 2017 05:50:58 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=lt3rs8AsID5FSpLgHkBO/LBtvylVdSyeP92/9w/d3IQ=;\n\tb=IOs16H8kv3yWjh\n\tYEa07yhZcfyDd108J/aZ9J1kQsmeMQOWcxusXpJJ4QpWjFa+akYByc0J0NKzJnRSmzh4BwFppPBu5\n\tmMZ/3bG+FOCId3ODRE9+d1J4tsXL00FaUd6/jtRo2mjcdcJ0ehP1zxx0SX65dqpqZdLZYUrXN9JPP\n\t9ahVXeWDgUTTuBv4fnrCT/0Fst7hTTj6y9vHU0iY4G8/UPcEylMp307/UPAML10QPsX+QC9GJBP0m\n\tJL4qIccJ0hq6XBSOAyqinW5aeaNsskRtfHAwWy+bWrHEjf92kCmC0MepHejUbmZf8H4N1Yl6fiBFz\n\tLuPM9ZvBCCUhzGIWWT9w==;","Subject":"Re: [RFC PATCH 6/6] iommu/arm-smmu-v3: Avoid ILLEGAL setting of\n\tSTE.S1STALLD and CD.S","To":"Yisheng Xie ","References":"<1504167642-14922-1-git-send-email-xieyisheng1@huawei.com>\n\t<1504167642-14922-7-git-send-email-xieyisheng1@huawei.com>","From":"Jean-Philippe Brucker ","Message-ID":"<738977bb-4cd7-7d86-0ea0-0c88b6af721c@arm.com>","Date":"Tue, 5 Sep 2017 13:54:19 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<1504167642-14922-7-git-send-email-xieyisheng1@huawei.com>","Content-Language":"en-US","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170905_055123_103431_8B7E3E56 ","X-CRM114-Status":"GOOD ( 10.85 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, devicetree@vger.kernel.org,\n\tlorenzo.pieralisi@arm.com, \n\tlv.zheng@intel.com, will.deacon@arm.com, joro@8bytes.org,\n\tliubo95@huawei.com, rjw@rjwysocki.net, robert.moore@intel.com,\n\tlinux-kernel@vger.kernel.org, \n\tlinux-acpi@vger.kernel.org, iommu@lists.linux-foundation.org,\n\trobh+dt@kernel.org, hanjun.guo@linaro.org, xieyisheng@huawei.com,\n\tsudeep.holla@arm.com, chenjiankang1@huawei.com, devel@acpica.org,\n\trobin.murphy@arm.com, linux-arm-kernel@lists.infradead.org,\n\tlenb@kernel.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1763328,"web_url":"http://patchwork.ozlabs.org/comment/1763328/","msgid":"<95d1a9e2-1816-ff7d-9a8d-98406a6c2c22@arm.com>","list_archive_url":null,"date":"2017-09-05T12:56:00","subject":"Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3","submitter":{"id":68357,"url":"http://patchwork.ozlabs.org/api/people/68357/","name":"Jean-Philippe Brucker","email":"Jean-Philippe.Brucker@arm.com"},"content":"On 31/08/17 09:20, Yisheng Xie wrote:\n> Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM SMMUv3:\n> https://www.spinics.net/lists/arm-kernel/msg565155.html\n> \n> But for some platform devices(aka on-chip integrated devices), there is also\n> SVM requirement, which works based on the SMMU stall mode.\n> Jean-Philippe has prepared a prototype patchset to support it:\n> git://linux-arm.org/linux-jpb.git svm/stall\n\nOnly meant for testing at that point, and unfit even for an RFC.\n\n> We tested this patchset with some fixes on a on-chip integrated device. The\n> basic function is ok, so I just send them out for review, although this\n> patchset heavily depends on the former patchset (PCIe SVM support for ARM\n> SMMUv3), which is still under discussion.\n> \n> Patch Overview:\n> *1 to 3 prepare for device tree or acpi get the device stall ability and pasid bits\n> *4 is to realise the SVM function for platform device\n> *5 is fix a bug when test SVM function while SMMU donnot support this feature\n> *6 avoid ILLEGAL setting of STE and CD entry about stall\n> \n> Acctually here, I also have a question about SVM on SMMUv3:\n> \n> 1. Why the SVM feature on SMMUv3 depends on BTM feature? when bind a task to device,\n> it will register a mmu_notify. Therefore, when a page range is invalid, we can\n> send TLBI or ATC invalid without BTM?\n\nWe could, but the end goal for SVM is to perfectly mirror the CPU page\ntables. So for platform SVM we would like to get rid of MMU notifiers\nentirely.\n\n> 2. According to ACPI IORT spec, named component specific data has a node flags field\n> whoes bit0 is for Stall support. However, it do not have any field for pasid bit.\n> Can we use other 5 bits[5:1] for pasid bit numbers, so we can have 32 pasid bit for\n> a single platform device which should be enough, because SMMU only support 20 bit pasid\n> \n> 3. Presently, the pasid is allocate for a task but not for a context, if a task is trying\n> to bind to 2 device A and B:\n> a) A support 5 pasid bits\n> b) B support 2 pasid bits\n> c) when the task bind to device A, it allocate pasid = 16\n> d) then it must be fail when trying to bind to task B, for its highest pasid is 4.\n> So it should allocate a single pasid for a context to avoid this?\n\nIdeally yes, but the model chosen for the IOMMU API was one PASID per\ntask, so I implemented this model (the PASID allocator will be common to\nIOMMU core in the future).\n\nTherefore the PASID allocation will fail in your example, and there is no\nway around it. If you do (d) then (c), the task will have PASID 4.\n\nThanks,\nJean","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org header.b=\"Y8ryB8Tu\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=infradead.org header.i=@infradead.org\n\theader.b=\"ITsSmUQi\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xmmsc25Zcz9t16\n\tfor ;\n\tTue, 5 Sep 2017 22:55:32 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpDO3-00037j-TH; Tue, 05 Sep 2017 12:55:27 +0000","from casper.infradead.org ([2001:8b0:10b:1236::1])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpDO2-0002rw-24 for linux-arm-kernel@bombadil.infradead.org;\n\tTue, 05 Sep 2017 12:55:26 +0000","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]\n\thelo=foss.arm.com)\n\tby casper.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpDLj-00029T-LT for linux-arm-kernel@lists.infradead.org;\n\tTue, 05 Sep 2017 12:53:05 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D993A2B;\n\tTue, 5 Sep 2017 05:52:42 -0700 (PDT)","from [10.1.211.72] (e106794-lin.cambridge.arm.com [10.1.211.72])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t65B1B3F3E1; Tue, 5 Sep 2017 05:52:39 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=iActBmQphl27Oa+y/hhprhD05hDVGyMBtgQKX+uC1bE=;\n\tb=Y8ryB8TuoK9cPP\n\toW8sUw7+o/M/Jjs0nyDOD71cKOVQu5ath5h5efN4MNBRQI6ePN7WXDuZqEhhBrBhr48iVAGxwqHt+\n\trNhSBkb3I16et9rsiabU3DschPiHfaEtfMfYRPgEySLzAK/oGtQvfyIi3mpmiGUklY9XLL+fBdJlD\n\t2TQTVMzFF/BxF8I0NPtxoXdM3VVDSS9ihKG8SrVvGmza7YzwJYBIQ8MXhY69ttt+Rqh/yAAY1Pytk\n\t3jsiAcgB3STDW/7AgkO0Pf88Rlz0NN1nxXPVoLyKjQWuWyxbEEZCOMgK4I4wXByZf/qfu2yTZcVl2\n\tdHg1754cXriPNBmV+qvA==;","v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=infradead.org; s=casper.20170209;\n\th=Content-Transfer-Encoding:Content-Type:\n\tIn-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender\n\t:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:\n\tResent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:\n\tList-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;\n\tbh=Kw2X+foPAttzkVMcyPFr3pPPFsiaEvmBOvtzcl845hI=;\n\tb=ITsSmUQiM0k8d7ZMXJ/puvrUhU\n\tI4dv2zANs09kGFZJ4EOEJGbTgQZmmFPdGxVcCBbCsqPqjUjhi1YJxhUbQERJCmqmuOUdOVwcKE06x\n\tXr4SztcsLVbE6TAKGnR4vR7kXCdt0P4HGPxIHRMcuE1IVzbSpjUepTITJZ2nqeKmjVUFj4V+aUHH6\n\t13Hqqf/tIISAV27MIhFbntVBZ4n1J3g+Je9pAJzWvCSyHHfwHFRxv64DjFlVZbsSc5sj3kXRVS383\n\tViXQfMPOIZvqJjcWrxF8r/mFSVwcsnMItBeTZ3Mc2KBLnB1DUyEnmavE8/tMGnxjqgqjkkCQuM/YT\n\teEe4WocA==;"],"Subject":"Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3","To":"Yisheng Xie ","References":"<1504167642-14922-1-git-send-email-xieyisheng1@huawei.com>","From":"Jean-Philippe Brucker ","Message-ID":"<95d1a9e2-1816-ff7d-9a8d-98406a6c2c22@arm.com>","Date":"Tue, 5 Sep 2017 13:56:00 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<1504167642-14922-1-git-send-email-xieyisheng1@huawei.com>","Content-Language":"en-US","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170905_135303_992790_22D27B45 ","X-CRM114-Status":"GOOD ( 25.24 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on casper.infradead.org summary:\n\tContent analysis details: (-6.9 points, 5.0 required)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, devicetree@vger.kernel.org,\n\tlorenzo.pieralisi@arm.com, \n\tlv.zheng@intel.com, will.deacon@arm.com, joro@8bytes.org,\n\tliubo95@huawei.com, rjw@rjwysocki.net, robert.moore@intel.com,\n\tlinux-kernel@vger.kernel.org, \n\tlinux-acpi@vger.kernel.org, iommu@lists.linux-foundation.org,\n\trobh+dt@kernel.org, hanjun.guo@linaro.org, xieyisheng@huawei.com,\n\tsudeep.holla@arm.com, chenjiankang1@huawei.com, devel@acpica.org,\n\trobin.murphy@arm.com, linux-arm-kernel@lists.infradead.org,\n\tlenb@kernel.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1763329,"web_url":"http://patchwork.ozlabs.org/comment/1763329/","msgid":"<50b249e6-8224-26fe-364f-c63b78601c6f@arm.com>","list_archive_url":null,"date":"2017-09-05T12:53:53","subject":"Re: [RFC PATCH 5/6] iommu/arm-smmu-v3: fix panic when handle stall\n\tmode irq","submitter":{"id":68357,"url":"http://patchwork.ozlabs.org/api/people/68357/","name":"Jean-Philippe Brucker","email":"Jean-Philippe.Brucker@arm.com"},"content":"On 31/08/17 09:20, Yisheng Xie wrote:\n> When SMMU do not support SVM feature, however the master support SVM,\n> which means matser can stall and with mult-pasid number, then the user\n> can bind a task to device using API like iommu_bind_task(). however,\n> when device trigger a stall mode fault i will cause panic:\n> \n> [ 106.996087] Unable to handle kernel NULL pointer dereference at virtual address 00000100\n> [ 106.996122] user pgtable: 4k pages, 48-bit VAs, pgd = ffff80003e023000\n> [ 106.996150] [0000000000000100] *pgd=000000003e04a003, *pud=000000003e04b003, *pmd=0000000000000000\n> [ 106.996201] Internal error: Oops: 96000006 [#1] PREEMPT SM\n> [ 106.996224] Modules linked in:\n> [ 106.996256] CPU: 0 PID: 916 Comm: irq/14-arm-smmu Not tainted 4.13.0-rc5-00035-g1235ddd-dirty #67\n> [ 106.996288] Hardware name: Hisilicon PhosphorHi1383 ESL (DT)\n> [ 106.996317] task: ffff80003adc1c00 task.stack: ffff80003a9f8000\n> [ 106.996347] PC is at __queue_work+0x30/0x3a8\n> [ 106.996374] LR is at queue_work_on+0x60/0x78\n> [ 106.996401] pc : [] lr : [] pstate: 40c001c9\n> [ 106.996430] sp : ffff80003a9fbc20\n> [ 106.996451] x29: ffff80003a9fbc20 x28: ffff80003adc1c00\n> [ 106.996488] x27: ffff000008d05080 x26: ffff80003ab0e028\n> [ 106.996526] x25: ffff80003a9900ac x24: 0000000000000001\n> [ 106.996562] x23: 0000000000000040 x22: 0000000000000000\n> [ 106.996598] x21: 0000000000000000 x20: 0000000000000140\n> [ 106.996634] x19: ffff80003ab0e028 x18: 0000000000000010\n> [ 106.996670] x17: 0000ffffa52a5040 x16: ffff00000820f260\n> [ 106.996708] x15: 00000018e97629e0 x14: ffff80003fb89468\n> [ 106.996744] x13: 0000000000000000 x12: ffff80003abb0600\n> [ 106.996781] x11: 0000000000000000 x10: 0000010100000100\n> [ 106.996817] x9 : 0000ffff85de5010 x8 : 00000000e4830001\n> [ 106.996854] x7 : ffff80003a9fbcf8 x6 : 0000000fffffffe0\n> [ 106.996890] x5 : 0000000000000000 x4 : 0000000000000001\n> [ 106.996926] x3 : 0000000000000000 x2 : ffff80003ab0e028\n> [ 106.996962] x1 : 0000000000000000 x0 : 00000000000001c0\n> [ 106.997002] Process irq/14-arm-smmu (pid: 916, stack limit =0xffff80003a9f8000)\n> [ 106.997035] Stack: (0xffff80003a9fbc20 to 0xffff80003a9fc000)\n> [...]\n> [ 106.998366] Call trace:\n> [ 106.998842] [] __queue_work+0x30/0x3a8\n> [ 106.998874] [] queue_work_on+0x60/0x78\n> [ 106.998912] [] arm_smmu_handle_stall+0x104/0x138\n> [ 106.998952] [] arm_smmu_evtq_thread+0xc0/0x158\n> [ 106.998989] [] irq_thread_fn+0x28/0x68\n> [ 106.999025] [] irq_thread+0x128/0x1d0\n> [ 106.999060] [] kthread+0xfc/0x128\n> [ 106.999093] [] ret_from_fork+0x10/0x50\n> [ 106.999130] Code: a90153f3 a90573fb d53b4220 363814c0 (b94102a0)\n> [ 106.999159] ---[ end trace 7e5c9f0cb1f2fecd ]---\n> \n> And the resean is we donot init fault_queue while the fault handle need\n> to use it. \n>\n> Fix by return -EINVAL in arm_smmu_bind_task() when smmu do not\n> support the feature of SVM.\n> \n> Signed-off-by: Yisheng Xie \n> ---\n> drivers/iommu/arm-smmu-v3.c | 2 ++\n> 1 file changed, 2 insertions(+)\n> \n> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c\n> index d44256a..dbda2eb 100644\n> --- a/drivers/iommu/arm-smmu-v3.c\n> +++ b/drivers/iommu/arm-smmu-v3.c\n> @@ -2922,6 +2922,8 @@ static int arm_smmu_bind_task(struct device *dev, struct task_struct *task,\n> \t\treturn -EINVAL;\n> \n> \tsmmu = master->smmu;\n> +\tif (!(smmu->features & ARM_SMMU_FEAT_SVM))\n> +\t\treturn -EINVAL;\n\nFEAT_SVM is set when the SMMU supports the same page table format as the\nMMU, it doesn't say anything about PRI/stall ability. To fix the above\nsplat we should either instantiate fault_queue even when !FEAT_SVM, or\navoid enabling master->can_fault and can_stall if !FEAT_SVM. I prefer the\nlatter.\n\nThanks,\nJean","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org header.b=\"Wbb8oqYz\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=infradead.org header.i=@infradead.org\n\theader.b=\"pAq5myzK\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xmmsx3F5xz9t16\n\tfor ;\n\tTue, 5 Sep 2017 22:55:49 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpDOL-0003Vc-Ix; Tue, 05 Sep 2017 12:55:45 +0000","from casper.infradead.org ([2001:8b0:10b:1236::1])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpDOH-0002rw-93 for linux-arm-kernel@bombadil.infradead.org;\n\tTue, 05 Sep 2017 12:55:41 +0000","from foss.arm.com ([217.140.101.70])\n\tby casper.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpDJh-00023m-9z for linux-arm-kernel@lists.infradead.org;\n\tTue, 05 Sep 2017 12:51:00 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 571B82B;\n\tTue, 5 Sep 2017 05:50:36 -0700 (PDT)","from [10.1.211.72] (e106794-lin.cambridge.arm.com [10.1.211.72])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\tCC3C93F3E1; Tue, 5 Sep 2017 05:50:32 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=LZXUMN0fxocPQeXTy8eZe7nDsXkh5fe68d41D8856J8=;\n\tb=Wbb8oqYzRjNw6P\n\t2/mMR9x7kCETOZINoFDKpMFSe/sBh/lVBJI5eVv7PeiLZ/Ev7MqFsqoJLWLd4PzspRehokc5czvnz\n\t6RC7BajUNKThp3cSLvBphKtO1sfvEqNjXax/immHyldTryupC/e0Jv25qvwv2O5OVRSo1fOwMcdiC\n\tMeSO2ff/HGq9rpGPf1SAvaZ0M3RaPdUn3JMiOV7LVSmze9ZG16JuawBX6fA1F0kku8Kj49wA+t38Y\n\tJzx7k6+sjYCnfIBGy9ApVT3yTIiMRn3lteqXUdtadPsPuUtmOMo8LasNl7qxK198CaUlNywJetCIz\n\tVq8PDFyBlWLKKTcN5rew==;","v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=infradead.org; s=casper.20170209;\n\th=Content-Transfer-Encoding:Content-Type:\n\tIn-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender\n\t:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:\n\tResent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:\n\tList-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;\n\tbh=MR7NUTMN2Vd6jeiDIH5Xjuc56LGoqDplC9kwVvOy7ZM=;\n\tb=pAq5myzKlY0j/SG4IQauSZjPbj\n\tzjxfBRpZvlIQ8MOxL9SUhnJ9loDEZOgLR+ISvw6Cq+bZMPsWcomXTsEXw2YGDdA5ukRtv4A1AwElT\n\t0oxzs540+/mWrREJF3mQB0HTKmzti4EIb2i/VeRvQasGBvRV2m9a9viWXc0UkSeKqumaLoOSk9j0z\n\tV1NJaRuOGjzOpX9ZwibAOFxTyBHbtzw+IHaAl+Zu5unZRO/mln0cX6ta079WnUnEhyLM4OkcH4iYS\n\tQatWO2GmBegHCBsFlgIyFR1pmNfGT4aTZ2rMkw7JCNTn3NfVGi8jXzlQgOHxrrJa4B6Y62VhCq5eE\n\tObUFmQWg==;"],"Subject":"Re: [RFC PATCH 5/6] iommu/arm-smmu-v3: fix panic when handle stall\n\tmode irq","To":"Yisheng Xie ","References":"<1504167642-14922-1-git-send-email-xieyisheng1@huawei.com>\n\t<1504167642-14922-6-git-send-email-xieyisheng1@huawei.com>","From":"Jean-Philippe Brucker ","Message-ID":"<50b249e6-8224-26fe-364f-c63b78601c6f@arm.com>","Date":"Tue, 5 Sep 2017 13:53:53 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<1504167642-14922-6-git-send-email-xieyisheng1@huawei.com>","Content-Language":"en-US","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170905_135057_709429_4E36B84A ","X-CRM114-Status":"GOOD ( 20.09 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on casper.infradead.org summary:\n\tContent analysis details: (-6.9 points, 5.0 required)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, devicetree@vger.kernel.org,\n\tlorenzo.pieralisi@arm.com, \n\tlv.zheng@intel.com, will.deacon@arm.com, joro@8bytes.org,\n\tliubo95@huawei.com, rjw@rjwysocki.net, robert.moore@intel.com,\n\tlinux-kernel@vger.kernel.org, \n\tlinux-acpi@vger.kernel.org, iommu@lists.linux-foundation.org,\n\trobh+dt@kernel.org, hanjun.guo@linaro.org, xieyisheng@huawei.com,\n\tsudeep.holla@arm.com, chenjiankang1@huawei.com, devel@acpica.org,\n\trobin.murphy@arm.com, linux-arm-kernel@lists.infradead.org,\n\tlenb@kernel.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1763753,"web_url":"http://patchwork.ozlabs.org/comment/1763753/","msgid":"<3f4e17fa-dcd0-5692-099a-73105e0e0095@huawei.com>","list_archive_url":null,"date":"2017-09-06T00:51:05","subject":"Re: [RFC PATCH 4/6] iommu/arm-smmu-v3: Add SVM support for platform\n\tdevices","submitter":{"id":72301,"url":"http://patchwork.ozlabs.org/api/people/72301/","name":"Bob Liu","email":"liubo95@huawei.com"},"content":"On 2017/9/5 20:53, Jean-Philippe Brucker wrote:\n> On 31/08/17 09:20, Yisheng Xie wrote:\n>> From: Jean-Philippe Brucker \n>>\n>> Platform device can realise SVM function by using the stall mode. That\n>> is to say, when device access a memory via iova which is not populated,\n>> it will stalled and when SMMU try to translate this iova, it also will\n>> stall and meanwhile send an event to CPU via MSI.\n>>\n>> After SMMU driver handle the event and populated the iova, it will send\n>> a RESUME command to SMMU to exit the stall mode, therefore the platform\n>> device can contiue access the memory.\n>>\n>> Signed-off-by: Jean-Philippe Brucker \n> \n> No. Please don't forge a signed-off-by under a commit message you wrote,\n\nReally sorry for that.\nWe sent out the wrong version, I should take more careful review.\n\nRegards,\nLiubo\n\n> it's rude. I didn't sign it, didn't consider it fit for mainline or even\n> as an RFC, and wanted to have another read before sending. My mistake,\n> I'll think twice before sharing prototypes in the future.\n> \n> Thanks,\n> Jean\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"BH/Vil+u\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xn4mc57B0z9sCZ\n\tfor ;\n\tWed, 6 Sep 2017 10:52:16 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpOZh-0005sm-9Q; Wed, 06 Sep 2017 00:52:13 +0000","from szxga04-in.huawei.com ([45.249.212.190])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpOZd-0005ng-8r for linux-arm-kernel@lists.infradead.org;\n\tWed, 06 Sep 2017 00:52:11 +0000","from 172.30.72.60 (EHLO DGGEMS413-HUB.china.huawei.com)\n\t([172.30.72.60])\n\tby dggrg04-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id DGP10990; Wed, 06 Sep 2017 08:51:20 +0800 (CST)","from [127.0.0.1] (10.142.83.150) by DGGEMS413-HUB.china.huawei.com\n\t(10.3.19.213) with Microsoft SMTP Server id 14.3.301.0;\n\tWed, 6 Sep 2017 08:51:07 +0800"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=qG1qC6yVFXvMDRqFM4fPgbnU75DeB9jtifE5PpWj27U=;\n\tb=BH/Vil+uuN/w6o\n\tprWF2jFi8VuyQWp9/m0RCp2rJiihWXFslBBmgc66gf20EWVKmpcUVVndCesAD1bfwJQd4dZGEFtSG\n\tt+lmZMwwO0ziIKQau2Ed5Bw6exIA2mnvxnyUzFT0JL/P55J7etfPofEPuj94Y41LFw3XJzJKDuzEb\n\tLjupuk9Hs811ve0bIlS/FqoLuiykh12yqlolrB1pnwK8A9n+aAlj65r/X5I1k+uC/5wmUGHxuBAUV\n\t/jChamAkfbe8tQiq3ZZ1ZLhLH0Pkql+hQbDjKW2TmrhrSMrhLApNpxtHCDW/ELlQM6fNwXS7jd5VS\n\tWe48jvOjL/oXNxl///Xg==;","Subject":"Re: [RFC PATCH 4/6] iommu/arm-smmu-v3: Add SVM support for platform\n\tdevices","To":"Jean-Philippe Brucker , Yisheng Xie\n\t","References":"<1504167642-14922-1-git-send-email-xieyisheng1@huawei.com>\n\t<1504167642-14922-5-git-send-email-xieyisheng1@huawei.com>\n\t<039adc54-00f5-bf4e-e509-ffdc67baa15e@arm.com>","From":"Bob Liu ","Message-ID":"<3f4e17fa-dcd0-5692-099a-73105e0e0095@huawei.com>","Date":"Wed, 6 Sep 2017 08:51:05 +0800","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101\n\tThunderbird/45.8.0","MIME-Version":"1.0","In-Reply-To":"<039adc54-00f5-bf4e-e509-ffdc67baa15e@arm.com>","X-Originating-IP":"[10.142.83.150]","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A090206.59AF4689.00D7, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"24a9ec2911777dee5e4fad9c696703e0","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170905_175209_672465_EE6B8D13 ","X-CRM114-Status":"UNSURE ( 8.43 )","X-CRM114-Notice":"Please train this message.","X-Spam-Score":"-1.9 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, devicetree@vger.kernel.org,\n\tlorenzo.pieralisi@arm.com, \n\tlv.zheng@intel.com, will.deacon@arm.com, joro@8bytes.org,\n\trjw@rjwysocki.net, robert.moore@intel.com, linux-kernel@vger.kernel.org,\n\tlinux-acpi@vger.kernel.org, iommu@lists.linux-foundation.org,\n\trobh+dt@kernel.org, hanjun.guo@linaro.org, xieyisheng@huawei.com,\n\tsudeep.holla@arm.com, chenjiankang1@huawei.com, devel@acpica.org,\n\trobin.murphy@arm.com, linux-arm-kernel@lists.infradead.org,\n\tlenb@kernel.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1763758,"web_url":"http://patchwork.ozlabs.org/comment/1763758/","msgid":"","list_archive_url":null,"date":"2017-09-06T01:02:59","subject":"Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3","submitter":{"id":72301,"url":"http://patchwork.ozlabs.org/api/people/72301/","name":"Bob Liu","email":"liubo95@huawei.com"},"content":"On 2017/9/5 20:56, Jean-Philippe Brucker wrote:\n> On 31/08/17 09:20, Yisheng Xie wrote:\n>> Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM SMMUv3:\n>> https://www.spinics.net/lists/arm-kernel/msg565155.html\n>>\n>> But for some platform devices(aka on-chip integrated devices), there is also\n>> SVM requirement, which works based on the SMMU stall mode.\n>> Jean-Philippe has prepared a prototype patchset to support it:\n>> git://linux-arm.org/linux-jpb.git svm/stall\n> \n> Only meant for testing at that point, and unfit even for an RFC.\n> \n\nSorry for the misunderstanding.\nThe PRI mode patches is in RFC even no hardware for testing, so I thought it's fine for \"Stall mode\" patches sent as RFC.\nWe have tested the Stall mode on our platform.\nAnyway, I should confirm with you in advance.\n\nBtw, Would you consider the \"stall mode\" upstream at first? Since there is no hardware for testing the PRI mode.\n(We can provide you the hardware which support SMMU stall mode if necessary.)\n\n>> We tested this patchset with some fixes on a on-chip integrated device. The\n>> basic function is ok, so I just send them out for review, although this\n>> patchset heavily depends on the former patchset (PCIe SVM support for ARM\n>> SMMUv3), which is still under discussion.\n>>\n>> Patch Overview:\n>> *1 to 3 prepare for device tree or acpi get the device stall ability and pasid bits\n>> *4 is to realise the SVM function for platform device\n>> *5 is fix a bug when test SVM function while SMMU donnot support this feature\n>> *6 avoid ILLEGAL setting of STE and CD entry about stall\n>>\n>> Acctually here, I also have a question about SVM on SMMUv3:\n>>\n>> 1. Why the SVM feature on SMMUv3 depends on BTM feature? when bind a task to device,\n>> it will register a mmu_notify. Therefore, when a page range is invalid, we can\n>> send TLBI or ATC invalid without BTM?\n> \n> We could, but the end goal for SVM is to perfectly mirror the CPU page\n> tables. So for platform SVM we would like to get rid of MMU notifiers\n> entirely.\n> \n>> 2. According to ACPI IORT spec, named component specific data has a node flags field\n>> whoes bit0 is for Stall support. However, it do not have any field for pasid bit.\n>> Can we use other 5 bits[5:1] for pasid bit numbers, so we can have 32 pasid bit for\n>> a single platform device which should be enough, because SMMU only support 20 bit pasid\n>>\n\nAny comment on this?\nThe ACPI IORT spec may need be updated?\n\nRegards,\nLiubo\n\n>> 3. Presently, the pasid is allocate for a task but not for a context, if a task is trying\n>> to bind to 2 device A and B:\n>> a) A support 5 pasid bits\n>> b) B support 2 pasid bits\n>> c) when the task bind to device A, it allocate pasid = 16\n>> d) then it must be fail when trying to bind to task B, for its highest pasid is 4.\n>> So it should allocate a single pasid for a context to avoid this?\n> \n> Ideally yes, but the model chosen for the IOMMU API was one PASID per\n> task, so I implemented this model (the PASID allocator will be common to\n> IOMMU core in the future).\n> \n> Therefore the PASID allocation will fail in your example, and there is no\n> way around it. If you do (d) then (c), the task will have PASID 4.\n> \n> Thanks,\n> Jean\n> \n> .\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"CC0XqV4i\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xn52M5YZ6z9s7h\n\tfor ;\n\tWed, 6 Sep 2017 11:04:11 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpOlE-0003XP-T6; Wed, 06 Sep 2017 01:04:08 +0000","from szxga05-in.huawei.com ([45.249.212.191])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpOlA-0003Rn-Gt for linux-arm-kernel@lists.infradead.org;\n\tWed, 06 Sep 2017 01:04:06 +0000","from 172.30.72.60 (EHLO DGGEMS404-HUB.china.huawei.com)\n\t([172.30.72.60])\n\tby dggrg05-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id DGR13790; Wed, 06 Sep 2017 09:03:12 +0800 (CST)","from [127.0.0.1] (10.142.83.150) by DGGEMS404-HUB.china.huawei.com\n\t(10.3.19.204) with Microsoft SMTP Server id 14.3.301.0;\n\tWed, 6 Sep 2017 09:03:01 +0800"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=p6uh67dibt7CwPsel8wX6SM/5wywJq96LM3Yi0np2R8=;\n\tb=CC0XqV4i1pJGzk\n\tUIYRMR5SVYVm/HzcT8F0wb36jBDGMdliPI4xd962OrAHeMqZGJMW1dd+7MY029CUfOD0cnHaSAibc\n\tj5wuFhDpOuZIWukQeem3yfk+fcTJfKNh54MWLuiVW7X8RFXpz/CLuy9QbBfVVFB3dxOE3SrkmmclU\n\te6jhSi8T4VSH4UeREZnUH3WBKMi6AvrDVCT54YVHPgO4nO4Q4fQwPI+GwiGsIStBmOOyUK/j/uZUd\n\tkWuaNvGBPXmaWzA8xwPtj6i8tOaBas2OIR/Hg9RvS9fAMWMogBpxp+ZLifqkKD6zMx25MVBlWuyZR\n\tPjBBK5DelEuoB30wJ3Cg==;","Subject":"Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3","To":"Jean-Philippe Brucker , Yisheng Xie\n\t","References":"<1504167642-14922-1-git-send-email-xieyisheng1@huawei.com>\n\t<95d1a9e2-1816-ff7d-9a8d-98406a6c2c22@arm.com>","From":"Bob Liu ","Message-ID":"","Date":"Wed, 6 Sep 2017 09:02:59 +0800","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101\n\tThunderbird/45.8.0","MIME-Version":"1.0","In-Reply-To":"<95d1a9e2-1816-ff7d-9a8d-98406a6c2c22@arm.com>","X-Originating-IP":"[10.142.83.150]","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A020204.59AF4951.0196, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"d7765235516df6b4b4b943d0efef56cd","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170905_180404_897896_03813C23 ","X-CRM114-Status":"GOOD ( 17.79 )","X-Spam-Score":"-1.9 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, devicetree@vger.kernel.org,\n\tlorenzo.pieralisi@arm.com, \n\tlv.zheng@intel.com, will.deacon@arm.com, joro@8bytes.org,\n\trjw@rjwysocki.net, robert.moore@intel.com, linux-kernel@vger.kernel.org,\n\tlinux-acpi@vger.kernel.org, iommu@lists.linux-foundation.org,\n\trobh+dt@kernel.org, hanjun.guo@linaro.org, xieyisheng@huawei.com,\n\tsudeep.holla@arm.com, chenjiankang1@huawei.com, devel@acpica.org,\n\trobin.murphy@arm.com, linux-arm-kernel@lists.infradead.org,\n\tlenb@kernel.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1763766,"web_url":"http://patchwork.ozlabs.org/comment/1763766/","msgid":"","list_archive_url":null,"date":"2017-09-06T01:16:38","subject":"Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3","submitter":{"id":72263,"url":"http://patchwork.ozlabs.org/api/people/72263/","name":"Yisheng Xie","email":"xieyisheng1@huawei.com"},"content":"Hi Jean-Philippe,\n\nOn 2017/9/5 20:56, Jean-Philippe Brucker wrote:\n> On 31/08/17 09:20, Yisheng Xie wrote:\n>> Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM SMMUv3:\n>> https://www.spinics.net/lists/arm-kernel/msg565155.html\n>>\n>> But for some platform devices(aka on-chip integrated devices), there is also\n>> SVM requirement, which works based on the SMMU stall mode.\n>> Jean-Philippe has prepared a prototype patchset to support it:\n>> git://linux-arm.org/linux-jpb.git svm/stall\n> \n> Only meant for testing at that point, and unfit even for an RFC.\n\nSorry about that, I should ask you before send it out. It's my mistake. For I also\nhave some question about this patchset.\n\nWe have related device, and would like to do some help about it. Do you have\nany plan about upstream ?\n\n> \n>> We tested this patchset with some fixes on a on-chip integrated device. The\n>> basic function is ok, so I just send them out for review, although this\n>> patchset heavily depends on the former patchset (PCIe SVM support for ARM\n>> SMMUv3), which is still under discussion.\n>>\n>> Patch Overview:\n>> *1 to 3 prepare for device tree or acpi get the device stall ability and pasid bits\n>> *4 is to realise the SVM function for platform device\n>> *5 is fix a bug when test SVM function while SMMU donnot support this feature\n>> *6 avoid ILLEGAL setting of STE and CD entry about stall\n>>\n>> Acctually here, I also have some questions about SVM on SMMUv3:\n>>\n>> 1. Why the SVM feature on SMMUv3 depends on BTM feature? when bind a task to device,\n>> it will register a mmu_notify. Therefore, when a page range is invalid, we can\n>> send TLBI or ATC invalid without BTM?\n> \n> We could, but the end goal for SVM is to perfectly mirror the CPU page\n> tables. So for platform SVM we would like to get rid of MMU notifiers\n> entirely.\n\nI see, but for some SMMU which do not support BTM, it cannot benefit from SVM.\n\nMeanwhile, do you mean even with BTM feature, the PCI-e device also need to send a\nATC invalid by MMU notify? It seems not fair, why not hardware do the entirely work\nin this case? It may costly for send ATC invalid and sync.\n\n> \n>> 2. According to ACPI IORT spec, named component specific data has a node flags field\n>> whoes bit0 is for Stall support. However, it do not have any field for pasid bit.\n>> Can we use other 5 bits[5:1] for pasid bit numbers, so we can have 32 pasid bit for\n>> a single platform device which should be enough, because SMMU only support 20 bit pasid\n>>\n>> 3. Presently, the pasid is allocate for a task but not for a context, if a task is trying\n>> to bind to 2 device A and B:\n>> a) A support 5 pasid bits\n>> b) B support 2 pasid bits\n>> c) when the task bind to device A, it allocate pasid = 16\n>> d) then it must be fail when trying to bind to task B, for its highest pasid is 4.\n>> So it should allocate a single pasid for a context to avoid this?\n> \n> Ideally yes, but the model chosen for the IOMMU API was one PASID per\n> task, so I implemented this model (the PASID allocator will be common to\n> IOMMU core in the future).\nIt is fair, for each IOMMU need PASID allocator to support SVM.\n\nThanks\nYisheng Xie\n\n> \n> Therefore the PASID allocation will fail in your example, and there is no\n> way around it. If you do (d) then (c), the task will have PASID 4.\n> \n> Thanks,\n> Jean\n> \n> .\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"bzV85ZbX\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xn5LD1g0Tz9t3f\n\tfor ;\n\tWed, 6 Sep 2017 11:17:56 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpOyW-0001Bs-UJ; Wed, 06 Sep 2017 01:17:52 +0000","from szxga05-in.huawei.com ([45.249.212.191])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpOyS-00017K-JN for linux-arm-kernel@lists.infradead.org;\n\tWed, 06 Sep 2017 01:17:51 +0000","from 172.30.72.58 (EHLO DGGEMS407-HUB.china.huawei.com)\n\t([172.30.72.58])\n\tby dggrg05-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id DGR16375; Wed, 06 Sep 2017 09:17:00 +0800 (CST)","from [127.0.0.1] (10.177.29.40) by DGGEMS407-HUB.china.huawei.com\n\t(10.3.19.207) with Microsoft SMTP Server id 14.3.301.0;\n\tWed, 6 Sep 2017 09:16:51 +0800"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=niMUs1jj5GacTF/Z1SK7qCD4QQ8Ppop97HfELfzalO4=;\n\tb=bzV85ZbXSTcdLd\n\tgcXcWt4mvHG4KYscS0er4kmyyuAW2e0petX7zT/c9lk2kc1ntdoYmDdp4pboXKVzfIzMTpQJBpebX\n\tIqy3Y28G+R1lb9dF5AWupgBFRx/KJ3hAEgRNzVuLZ7kp9v4/G86bVE5nlSmqEmzTAB7Ixo9PCnF2Q\n\tfcCZBeGuCaXR0n9e6XE8qvXJhMt0ZutBO8DVCwqGhsQfEewku7hQ1wyosV0/Mzd49HOjlVGCazzlN\n\tad5FO5ePml6RlZmBw1uPaxG9ZOyzqq3o3zNpDIoPe3p0pN+JpXXlJ2oQSZKh+jB5EYAb6mfa50EU5\n\tj70aCIvNNx8z1Sohq99Q==;","Subject":"Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3","To":"Jean-Philippe Brucker ","References":"<1504167642-14922-1-git-send-email-xieyisheng1@huawei.com>\n\t<95d1a9e2-1816-ff7d-9a8d-98406a6c2c22@arm.com>","From":"Yisheng Xie ","Message-ID":"","Date":"Wed, 6 Sep 2017 09:16:38 +0800","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101\n\tThunderbird/45.1.0","MIME-Version":"1.0","In-Reply-To":"<95d1a9e2-1816-ff7d-9a8d-98406a6c2c22@arm.com>","X-Originating-IP":"[10.177.29.40]","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A020206.59AF4C8D.003D, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"d7765235516df6b4b4b943d0efef56cd","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170905_181748_980084_BFDE6C81 ","X-CRM114-Status":"GOOD ( 20.16 )","X-Spam-Score":"-1.9 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, devicetree@vger.kernel.org,\n\tlorenzo.pieralisi@arm.com, \n\tlv.zheng@intel.com, will.deacon@arm.com, joro@8bytes.org,\n\tliubo95@huawei.com, rjw@rjwysocki.net, robert.moore@intel.com,\n\tlinux-kernel@vger.kernel.org, \n\tlinux-acpi@vger.kernel.org, iommu@lists.linux-foundation.org,\n\trobh+dt@kernel.org, hanjun.guo@linaro.org, xieyisheng@huawei.com,\n\tsudeep.holla@arm.com, chenjiankang1@huawei.com, devel@acpica.org,\n\trobin.murphy@arm.com, linux-arm-kernel@lists.infradead.org,\n\tlenb@kernel.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1763768,"web_url":"http://patchwork.ozlabs.org/comment/1763768/","msgid":"","list_archive_url":null,"date":"2017-09-06T01:20:32","subject":"Re: [RFC PATCH 4/6] iommu/arm-smmu-v3: Add SVM support for platform\n\tdevices","submitter":{"id":72263,"url":"http://patchwork.ozlabs.org/api/people/72263/","name":"Yisheng Xie","email":"xieyisheng1@huawei.com"},"content":"Hi Jean-Philippe,\n\nOn 2017/9/6 8:51, Bob Liu wrote:\n> On 2017/9/5 20:53, Jean-Philippe Brucker wrote:\n>> On 31/08/17 09:20, Yisheng Xie wrote:\n>>> From: Jean-Philippe Brucker \n>>>\n>>> Platform device can realise SVM function by using the stall mode. That\n>>> is to say, when device access a memory via iova which is not populated,\n>>> it will stalled and when SMMU try to translate this iova, it also will\n>>> stall and meanwhile send an event to CPU via MSI.\n>>>\n>>> After SMMU driver handle the event and populated the iova, it will send\n>>> a RESUME command to SMMU to exit the stall mode, therefore the platform\n>>> device can contiue access the memory.\n>>>\n>>> Signed-off-by: Jean-Philippe Brucker \n>>\n>> No. Please don't forge a signed-off-by under a commit message you wrote,\n\nSorry about that, it is my mistake.\n\n> \n> Really sorry for that.\n> We sent out the wrong version, I should take more careful review.\n> \n> Regards,\n> Liubo\n> \n>> it's rude. I didn't sign it, didn't consider it fit for mainline or even\n>> as an RFC, and wanted to have another read before sending. My mistake,\n>> I'll think twice before sharing prototypes in the future.\n>>\n>> Thanks,\n>> Jean\n>>\n> \n> \n> \n> \n> .\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"KqDggukz\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xn5QY1mSmz9s8J\n\tfor ;\n\tWed, 6 Sep 2017 11:21:41 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpP29-00038N-TK; Wed, 06 Sep 2017 01:21:37 +0000","from szxga05-in.huawei.com ([45.249.212.191])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpP25-00031a-Jo for linux-arm-kernel@lists.infradead.org;\n\tWed, 06 Sep 2017 01:21:35 +0000","from 172.30.72.60 (EHLO DGGEMS410-HUB.china.huawei.com)\n\t([172.30.72.60])\n\tby dggrg05-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id DGR17097; Wed, 06 Sep 2017 09:20:54 +0800 (CST)","from [127.0.0.1] (10.177.29.40) by DGGEMS410-HUB.china.huawei.com\n\t(10.3.19.210) with Microsoft SMTP Server id 14.3.301.0;\n\tWed, 6 Sep 2017 09:20:45 +0800"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=lhTMWpyzsHbGhy2BaoKAiPoOywy/minknhUsP3iRREw=;\n\tb=KqDggukziG1Xj7\n\tAxiiqxBdP7Yng67RvVIO0SwYVjZWscHxEcMCZHXlPedzHdGk9FuZ6eyJU1jqWRyj7C9IOYbDoMYRk\n\thrtjrVJvBYtnky7QA/tSL5tj19ncPyTx/aPzXf0QPe2IzJfwl5zX0ieNN5/MVz1ifvM0NywunaCYd\n\tTsBpA1OC4YqDPRa2OInldWB9Nu4l8/+nK5uyOynKwm0pj/olokRpt/HNKBay49pzw7bz160Gzk6IK\n\tcgm/Yyk+S1RV8WXipZiZxlrrS0zhOEBiPOQqkoFUIp0pDq1LvGjEXg0v4GZlwZ3xoX3l88Q1CsFVK\n\tgaiyNM7fynJAVHh7xqSQ==;","Subject":"Re: [RFC PATCH 4/6] iommu/arm-smmu-v3: Add SVM support for platform\n\tdevices","To":"Bob Liu , Jean-Philippe Brucker\n\t","References":"<1504167642-14922-1-git-send-email-xieyisheng1@huawei.com>\n\t<1504167642-14922-5-git-send-email-xieyisheng1@huawei.com>\n\t<039adc54-00f5-bf4e-e509-ffdc67baa15e@arm.com>\n\t<3f4e17fa-dcd0-5692-099a-73105e0e0095@huawei.com>","From":"Yisheng Xie ","Message-ID":"","Date":"Wed, 6 Sep 2017 09:20:32 +0800","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101\n\tThunderbird/45.1.0","MIME-Version":"1.0","In-Reply-To":"<3f4e17fa-dcd0-5692-099a-73105e0e0095@huawei.com>","X-Originating-IP":"[10.177.29.40]","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A020205.59AF4D76.0053, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"49fbd273253cce5d78dd53395dbcdca1","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170905_182134_003766_E12D138D ","X-CRM114-Status":"UNSURE ( 9.46 )","X-CRM114-Notice":"Please train this message.","X-Spam-Score":"-1.9 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, devicetree@vger.kernel.org,\n\tlorenzo.pieralisi@arm.com, \n\tlv.zheng@intel.com, will.deacon@arm.com, joro@8bytes.org,\n\trjw@rjwysocki.net, robert.moore@intel.com, linux-kernel@vger.kernel.org,\n\tlinux-acpi@vger.kernel.org, iommu@lists.linux-foundation.org,\n\trobh+dt@kernel.org, hanjun.guo@linaro.org, xieyisheng@huawei.com,\n\tsudeep.holla@arm.com, chenjiankang1@huawei.com, devel@acpica.org,\n\trobin.murphy@arm.com, linux-arm-kernel@lists.infradead.org,\n\tlenb@kernel.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1763770,"web_url":"http://patchwork.ozlabs.org/comment/1763770/","msgid":"<1bd8a485-d915-5d82-1ffe-0754b32a7656@linaro.org>","list_archive_url":null,"date":"2017-09-06T01:24:23","subject":"Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3","submitter":{"id":47236,"url":"http://patchwork.ozlabs.org/api/people/47236/","name":"Hanjun Guo","email":"hanjun.guo@linaro.org"},"content":"On 2017/8/31 16:20, Yisheng Xie wrote:\n> Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM SMMUv3:\n> https://www.spinics.net/lists/arm-kernel/msg565155.html\n> \n> But for some platform devices(aka on-chip integrated devices), there is also\n> SVM requirement, which works based on the SMMU stall mode.\n> Jean-Philippe has prepared a prototype patchset to support it:\n> git://linux-arm.org/linux-jpb.git svm/stall\n> \n> We tested this patchset with some fixes on a on-chip integrated device. The\n> basic function is ok, so I just send them out for review, although this\n> patchset heavily depends on the former patchset (PCIe SVM support for ARM\n> SMMUv3), which is still under discussion.\n> \n> Patch Overview:\n> *1 to 3 prepare for device tree or acpi get the device stall ability and pasid bits\n> *4 is to realise the SVM function for platform device\n> *5 is fix a bug when test SVM function while SMMU donnot support this feature\n> *6 avoid ILLEGAL setting of STE and CD entry about stall\n> \n> Acctually here, I also have a question about SVM on SMMUv3:\n> \n> 1. Why the SVM feature on SMMUv3 depends on BTM feature? when bind a task to device,\n> it will register a mmu_notify. Therefore, when a page range is invalid, we can\n> send TLBI or ATC invalid without BTM?\n> \n> 2. According to ACPI IORT spec, named component specific data has a node flags field\n> whoes bit0 is for Stall support. However, it do not have any field for pasid bit.\n> Can we use other 5 bits[5:1] for pasid bit numbers, so we can have 32 pasid bit for\n> a single platform device which should be enough, because SMMU only support 20 bit pasid\n\nI think we can propose something similar, it's a missing function in\nIORT.\n\nThanks\nHanjun","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org header.b=\"ieHaAJaA\"; \n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=linaro.org header.i=@linaro.org\n\theader.b=\"FKjiz7z2\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xn5VM55tWz9s8J\n\tfor ;\n\tWed, 6 Sep 2017 11:24:59 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpP5M-0003zJ-Kl; Wed, 06 Sep 2017 01:24:56 +0000","from mail-pf0-x22e.google.com ([2607:f8b0:400e:c00::22e])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpP5I-0003sw-OM for linux-arm-kernel@lists.infradead.org;\n\tWed, 06 Sep 2017 01:24:54 +0000","by mail-pf0-x22e.google.com with SMTP id g13so10458988pfm.2\n\tfor ;\n\tTue, 05 Sep 2017 18:24:31 -0700 (PDT)","from [10.229.34.244] ([119.145.15.121])\n\tby smtp.gmail.com with ESMTPSA id 62sm286183pfu.4.2017.09.05.18.24.26\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 05 Sep 2017 18:24:30 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type:\n\tContent-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive:\n\tList-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From:\n\tReferences:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date:\n\tResent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner;\n\tbh=sNq3hpW2cTZ9PT4QH0oCD4MYioktXfH7ySkTJglquVA=;\n\tb=ieHaAJaAdXkMkxmvKAQEoA/+p\n\tZGePSNqaIpT5V7lho8KWE9jAObMj/lnPi9+RGKjhx3t3qgaM5kRwnjXj+qq1KUfn1sETPRgrQtGMF\n\tLMigBO8wZD8APl+mS7W0vHEwSiXg7Wrw2Wvc9UTgJ2rdk2qY1FPxSSE21xFSKtovQESTTYmdeW3/C\n\tYiN/rt76570uF8UBgu/pV1tAgt9Tiybv3+/tu83DDV4fE7Q/TXQQvb08OeVVMaen04ECiyo/ribbu\n\tiuU486Myl8IwW5xEYqw/q26XxAcKN1Oco1/li8KE3EYzcKyOI57quatDaooJdZ2vJcjCfqOPP7Hfd\n\tr1DZuhPzA==;","v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=9b6mbM+s4HYlcrEfDKoX0eH+us7cnxqoqLR2u6bfA04=;\n\tb=FKjiz7z2iqB5KKD0ye3p3j14cyy++76aoFHe9ab24rq/1Ov2etEY9QezzylahVp+iH\n\tSSK3TEN7XcaBmWb96muzN1eADAF3mtpRYF43KP+cUjGNznm/WY+Hw8Brjh6/nCimTAMz\n\tvFaR+VFTYDoHTVd5RnfK8D91K6OKsWRoIkNBc="],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=9b6mbM+s4HYlcrEfDKoX0eH+us7cnxqoqLR2u6bfA04=;\n\tb=R296XOGuR2A2hHszu7uvbJhFfQ5l0nzOWMjCAFeFoVxnkXfPMvg6d0kVrxQLD6vHw6\n\tLoAU5iolQ+BZOqMRk8wziqKlTw++YDf0c6sS9YLr6OC8jbmZocLHM4+vW3LdYAjqWbNu\n\txToIyjmnBc8iCkpl8lijzp437LWMIDrzApcby4AYa8lgW7OL/hA9rcRJMhLtRe2qCeYH\n\tuxK+78pPSL4VAKVjaFzETpWLbmqcKQYmYFzkRR1+S8JweFJrkvMGo5MXQKoHKKZWYa/K\n\tJIjnvn+XE7jMcSKPVYyHsvNEmnWuFO85s2j8nn0Abwc+kExbc91y+mCgT1UBP+S3HxQd\n\tMyUQ==","X-Gm-Message-State":"AHPjjUhGRiBOGcVjNMNRE2c6EsWk6JZnh/wK0qp/0Rw4diFKv97ajOwu\n\tM4iwkSSQt2pS8H4V","X-Google-Smtp-Source":"ADKCNb6GVnu2tDBtKEhMHcGmVvyTnbDTDxCVEgdb6YrwGuj6fgXu6pyOXPTVZy+jNbjufiiwiE+eqw==","X-Received":"by 10.84.210.39 with SMTP id z36mr6475883plh.343.1504661071164; \n\tTue, 05 Sep 2017 18:24:31 -0700 (PDT)","Subject":"Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3","To":"Yisheng Xie , jean-philippe.brucker@arm.com","References":"<1504167642-14922-1-git-send-email-xieyisheng1@huawei.com>","From":"Hanjun Guo ","Message-ID":"<1bd8a485-d915-5d82-1ffe-0754b32a7656@linaro.org>","Date":"Wed, 6 Sep 2017 09:24:23 +0800","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<1504167642-14922-1-git-send-email-xieyisheng1@huawei.com>","Content-Language":"en-US","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170905_182452_879142_99121230 ","X-CRM114-Status":"GOOD ( 17.19 )","X-Spam-Score":"-2.0 (--)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-2.0 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,\n\tno\n\ttrust [2607:f8b0:400e:c00:0:0:0:22e listed in] [list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]\n\t-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature\n\t0.1 DKIM_SIGNED Message has a DKIM or DK signature,\n\tnot necessarily valid\n\t-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from\n\tauthor's domain","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, devicetree@vger.kernel.org,\n\tlorenzo.pieralisi@arm.com, \n\twill.deacon@arm.com, joro@8bytes.org, liubo95@huawei.com,\n\trjw@rjwysocki.net, robert.moore@intel.com, linux-kernel@vger.kernel.org,\n\tlinux-acpi@vger.kernel.org, iommu@lists.linux-foundation.org,\n\trobh+dt@kernel.org, lv.zheng@intel.com, xieyisheng@huawei.com,\n\tsudeep.holla@arm.com, chenjiankang1@huawei.com, devel@acpica.org,\n\trobin.murphy@arm.com, linux-arm-kernel@lists.infradead.org,\n\tlenb@kernel.org","Content-Transfer-Encoding":"7bit","Content-Type":"text/plain; charset=\"us-ascii\"; Format=\"flowed\"","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1763788,"web_url":"http://patchwork.ozlabs.org/comment/1763788/","msgid":"","list_archive_url":null,"date":"2017-09-06T02:23:00","subject":"Re: [RFC PATCH 6/6] iommu/arm-smmu-v3: Avoid ILLEGAL setting of\n\tSTE.S1STALLD and CD.S","submitter":{"id":72263,"url":"http://patchwork.ozlabs.org/api/people/72263/","name":"Yisheng Xie","email":"xieyisheng1@huawei.com"},"content":"Hi Jean-Philippe,\n\nOn 2017/9/5 20:54, Jean-Philippe Brucker wrote:\n> On 31/08/17 09:20, Yisheng Xie wrote:\n>> It is ILLEGAL to set STE.S1STALLD if STALL_MODEL is not 0b00, which\n>> means we should not disable stall mode if stall/terminate mode is not\n>> configuable.\n>>\n>> Meanwhile, it is also ILLEGAL when STALL_MODEL==0b10 && CD.S==0 which\n>> means if stall mode is force we should always set CD.S.\n>>\n>> This patch add ARM_SMMU_FEAT_TERMINATE feature bit for smmu, and use\n>> TERMINATE feature checking to ensue above ILLEGAL cases from happening.\n>>\n>> Signed-off-by: Yisheng Xie \n>> ---\n>> drivers/iommu/arm-smmu-v3.c | 22 ++++++++++++++++------\n>> 1 file changed, 16 insertions(+), 6 deletions(-)\n>>\n>> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c\n>> index dbda2eb..0745522 100644\n>> --- a/drivers/iommu/arm-smmu-v3.c\n>> +++ b/drivers/iommu/arm-smmu-v3.c\n>> @@ -55,6 +55,7 @@\n>> #define IDR0_STALL_MODEL_SHIFT\t\t24\n>> #define IDR0_STALL_MODEL_MASK\t\t0x3\n>> #define IDR0_STALL_MODEL_STALL\t\t(0 << IDR0_STALL_MODEL_SHIFT)\n>> +#define IDR0_STALL_MODEL_NS\t\t(1 << IDR0_STALL_MODEL_SHIFT)\n>> #define IDR0_STALL_MODEL_FORCE\t\t(2 << IDR0_STALL_MODEL_SHIFT)\n>> #define IDR0_TTENDIAN_SHIFT\t\t21\n>> #define IDR0_TTENDIAN_MASK\t\t0x3\n>> @@ -766,6 +767,7 @@ struct arm_smmu_device {\n>> #define ARM_SMMU_FEAT_SVM\t\t(1 << 15)\n>> #define ARM_SMMU_FEAT_HA\t\t(1 << 16)\n>> #define ARM_SMMU_FEAT_HD\t\t(1 << 17)\n>> +#define ARM_SMMU_FEAT_TERMINATE\t\t(1 << 18)\n> \n> I'd rather introduce something like \"ARM_SMMU_FEAT_STALL_FORCE\" instead.\n> Terminate model has another meaning, and is defined by a different bit in\n> IDR0.\n\nOk, sound more reasonable.\n\nThanks\nYisheng Xie\n\n> \n> Thanks,\n> Jean\n> \n> .\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"b5urINUT\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xn6pn4T7Sz9t3f\n\tfor ;\n\tWed, 6 Sep 2017 12:24:17 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpQ0j-0001cM-F8; Wed, 06 Sep 2017 02:24:13 +0000","from szxga04-in.huawei.com ([45.249.212.190])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpQ0d-0001Xs-Vo for linux-arm-kernel@lists.infradead.org;\n\tWed, 06 Sep 2017 02:24:10 +0000","from 172.30.72.59 (EHLO DGGEMS407-HUB.china.huawei.com)\n\t([172.30.72.59])\n\tby dggrg04-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id DGP26697; Wed, 06 Sep 2017 10:23:22 +0800 (CST)","from [127.0.0.1] (10.177.29.40) by DGGEMS407-HUB.china.huawei.com\n\t(10.3.19.207) with Microsoft SMTP Server id 14.3.301.0;\n\tWed, 6 Sep 2017 10:23:12 +0800"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=q0cmcK8YRu3t2RJXWATGBY/kwm+2BWZdBFeY1k0PoSY=;\n\tb=b5urINUTWLB+FC\n\tTjnDmrUYfrmEPv0cbkKJ0xqdMwdg66TTIX3X2f0TQAEEqmIPUjdNLrdCljcYtw0igeBJ1J5QDkJdu\n\tjlx1LeUw8vc8p8AWZqJ6vs9v7L6fduCdcdWRzNtqVBOiLVBBxJ1HjvGT028dz0Wrn+4/flWDI08IE\n\tNsI/PDxNHzUwWxZ5xeHsElE0S7WPb4Hp2LaIthjLiyib+/xwmdaGru//RMRY4UD5nW+lThxoaB9wD\n\tMQBK3m8je32rAATbkpUJZ2SdszxTUgPJ4B/XwsdA/ETV/oMLCvee9tXkdPHPnQHeYqBQ6bDt5kWie\n\t9wW7wMH560oe7GnvdSWg==;","Subject":"Re: [RFC PATCH 6/6] iommu/arm-smmu-v3: Avoid ILLEGAL setting of\n\tSTE.S1STALLD and CD.S","To":"Jean-Philippe Brucker ","References":"<1504167642-14922-1-git-send-email-xieyisheng1@huawei.com>\n\t<1504167642-14922-7-git-send-email-xieyisheng1@huawei.com>\n\t<738977bb-4cd7-7d86-0ea0-0c88b6af721c@arm.com>","From":"Yisheng Xie ","Message-ID":"","Date":"Wed, 6 Sep 2017 10:23:00 +0800","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101\n\tThunderbird/45.1.0","MIME-Version":"1.0","In-Reply-To":"<738977bb-4cd7-7d86-0ea0-0c88b6af721c@arm.com>","X-Originating-IP":"[10.177.29.40]","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A020201.59AF5C1A.00C2, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"eaac97f5f94b6b047243d4909bd1c3ff","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170905_192408_419245_B7884B7A ","X-CRM114-Status":"UNSURE ( 6.86 )","X-CRM114-Notice":"Please train this message.","X-Spam-Score":"-1.9 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, devicetree@vger.kernel.org,\n\tlorenzo.pieralisi@arm.com, \n\tlv.zheng@intel.com, will.deacon@arm.com, joro@8bytes.org,\n\tliubo95@huawei.com, rjw@rjwysocki.net, robert.moore@intel.com,\n\tlinux-kernel@vger.kernel.org, \n\tlinux-acpi@vger.kernel.org, iommu@lists.linux-foundation.org,\n\trobh+dt@kernel.org, hanjun.guo@linaro.org, xieyisheng@huawei.com,\n\tsudeep.holla@arm.com, chenjiankang1@huawei.com, devel@acpica.org,\n\trobin.murphy@arm.com, linux-arm-kernel@lists.infradead.org,\n\tlenb@kernel.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1763972,"web_url":"http://patchwork.ozlabs.org/comment/1763972/","msgid":"<2874a1f3-22f1-20d4-4009-50add127a10f@arm.com>","list_archive_url":null,"date":"2017-09-06T09:57:34","subject":"Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3","submitter":{"id":68357,"url":"http://patchwork.ozlabs.org/api/people/68357/","name":"Jean-Philippe Brucker","email":"Jean-Philippe.Brucker@arm.com"},"content":"On 06/09/17 02:02, Bob Liu wrote:\n> On 2017/9/5 20:56, Jean-Philippe Brucker wrote:\n>> On 31/08/17 09:20, Yisheng Xie wrote:\n>>> Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM SMMUv3:\n>>> https://www.spinics.net/lists/arm-kernel/msg565155.html\n>>>\n>>> But for some platform devices(aka on-chip integrated devices), there is also\n>>> SVM requirement, which works based on the SMMU stall mode.\n>>> Jean-Philippe has prepared a prototype patchset to support it:\n>>> git://linux-arm.org/linux-jpb.git svm/stall\n>>\n>> Only meant for testing at that point, and unfit even for an RFC.\n>>\n> \n> Sorry for the misunderstanding.\n> The PRI mode patches is in RFC even no hardware for testing, so I thought it's fine for \"Stall mode\" patches sent as RFC.\n> We have tested the Stall mode on our platform.\n> Anyway, I should confirm with you in advance.\n> \n> Btw, Would you consider the \"stall mode\" upstream at first? Since there is no hardware for testing the PRI mode.\n> (We can provide you the hardware which support SMMU stall mode if necessary.)\n\nYes. What's blocking the ATS, PRI and PASID patches at the moment is the\nlack of endpoints for testing. There has been lots of discussion on the\nAPI side since my first RFC and I'd like to resubmit the API changes soon.\nIt is the same API for ATS+PRI+PASID and SSID+Stall, so the backend\ndoesn't matter.\n\nI'm considering upstreaming SSID+Stall first if it can be tested on\nhardware (having direct access to it would certainly speed things up).\nThis would require some work in moving the PCI bits at the end of the\nseries. I can reserve some time in the coming months to do it, but I need\nto know what to focus on. Are you able to test SSID as well?\n\n>>> We tested this patchset with some fixes on a on-chip integrated device. The\n>>> basic function is ok, so I just send them out for review, although this\n>>> patchset heavily depends on the former patchset (PCIe SVM support for ARM\n>>> SMMUv3), which is still under discussion.\n>>>\n>>> Patch Overview:\n>>> *1 to 3 prepare for device tree or acpi get the device stall ability and pasid bits\n>>> *4 is to realise the SVM function for platform device\n>>> *5 is fix a bug when test SVM function while SMMU donnot support this feature\n>>> *6 avoid ILLEGAL setting of STE and CD entry about stall\n>>>\n>>> Acctually here, I also have a question about SVM on SMMUv3:\n>>>\n>>> 1. Why the SVM feature on SMMUv3 depends on BTM feature? when bind a task to device,\n>>> it will register a mmu_notify. Therefore, when a page range is invalid, we can\n>>> send TLBI or ATC invalid without BTM?\n>>\n>> We could, but the end goal for SVM is to perfectly mirror the CPU page\n>> tables. So for platform SVM we would like to get rid of MMU notifiers\n>> entirely.\n>>\n>>> 2. According to ACPI IORT spec, named component specific data has a node flags field\n>>> whoes bit0 is for Stall support. However, it do not have any field for pasid bit.\n>>> Can we use other 5 bits[5:1] for pasid bit numbers, so we can have 32 pasid bit for\n>>> a single platform device which should be enough, because SMMU only support 20 bit pasid\n>>>\n> \n> Any comment on this?\n> The ACPI IORT spec may need be updated?\n\nI suppose that the Named Component Node could be used for SSID and stall\ncapability bits. Can't the ACPI namespace entries be extended to host\nthese capabilities in a more generic way? Platforms with different IOMMUs\nmight also need this information some day.\n\nThanks,\nJean","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"VdF+fRCF\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xnJpW1VjSz9sCZ\n\tfor ;\n\tWed, 6 Sep 2017 19:54:43 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpX2d-0007wb-UN; Wed, 06 Sep 2017 09:54:39 +0000","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]\n\thelo=foss.arm.com)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpX2Z-0007qy-Vb for linux-arm-kernel@lists.infradead.org;\n\tWed, 06 Sep 2017 09:54:38 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C151515AD;\n\tWed, 6 Sep 2017 02:54:15 -0700 (PDT)","from [10.1.211.72] (e106794-lin.cambridge.arm.com [10.1.211.72])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t3B2CD3F3E1; Wed, 6 Sep 2017 02:54:12 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=AmlsPfObrq9605dowveVLS5w2FOQ4FCDydwTs3GYn5w=;\n\tb=VdF+fRCFNT5kRQ\n\ttk8iwHBnWqB+h84It+r0kbN2gNMBz2nsqY+Y9JwN6kC+OW1OVSZHjuvgGb4VIgsr7TndqfUyNJi5R\n\tGkJEACODyN2tG2iW2lhS6pa0RVIE5eVpiePXkvl4OHILOSXV5nqhLvN770t8R2c9SFz8W6Ded++vQ\n\tYG1uAi+xzvBE6fnbTr2xFvKuL58oxCFlB+ujsXXhdJmxb3lggnQ8OI2zZV/ASQmQoi3kuTaYk6bDp\n\toJQUMAykkqLD3kQA33NwnMmPvRgCenSJXWzxd9Kw4Secwhz+g1ncg16rYTMWnvqzZc69vrKTCnv2h\n\tRR+NR7oJyO3oHr6L2m5g==;","Subject":"Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3","To":"Bob Liu , Yisheng Xie ","References":"<1504167642-14922-1-git-send-email-xieyisheng1@huawei.com>\n\t<95d1a9e2-1816-ff7d-9a8d-98406a6c2c22@arm.com>\n\t","From":"Jean-Philippe Brucker ","Message-ID":"<2874a1f3-22f1-20d4-4009-50add127a10f@arm.com>","Date":"Wed, 6 Sep 2017 10:57:34 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.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-20170906_025436_167566_22A4BDC3 ","X-CRM114-Status":"GOOD ( 21.60 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, devicetree@vger.kernel.org,\n\tlorenzo.pieralisi@arm.com, \n\tlv.zheng@intel.com, will.deacon@arm.com, joro@8bytes.org,\n\trjw@rjwysocki.net, robert.moore@intel.com, linux-kernel@vger.kernel.org,\n\tlinux-acpi@vger.kernel.org, iommu@lists.linux-foundation.org,\n\trobh+dt@kernel.org, hanjun.guo@linaro.org, xieyisheng@huawei.com,\n\tsudeep.holla@arm.com, chenjiankang1@huawei.com, devel@acpica.org,\n\trobin.murphy@arm.com, linux-arm-kernel@lists.infradead.org,\n\tlenb@kernel.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1763975,"web_url":"http://patchwork.ozlabs.org/comment/1763975/","msgid":"","list_archive_url":null,"date":"2017-09-06T09:59:43","subject":"Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3","submitter":{"id":68357,"url":"http://patchwork.ozlabs.org/api/people/68357/","name":"Jean-Philippe Brucker","email":"Jean-Philippe.Brucker@arm.com"},"content":"On 06/09/17 02:16, Yisheng Xie wrote:\n> Hi Jean-Philippe,\n> \n> On 2017/9/5 20:56, Jean-Philippe Brucker wrote:\n>> On 31/08/17 09:20, Yisheng Xie wrote:\n>>> Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM SMMUv3:\n>>> https://www.spinics.net/lists/arm-kernel/msg565155.html\n>>>\n>>> But for some platform devices(aka on-chip integrated devices), there is also\n>>> SVM requirement, which works based on the SMMU stall mode.\n>>> Jean-Philippe has prepared a prototype patchset to support it:\n>>> git://linux-arm.org/linux-jpb.git svm/stall\n>>\n>> Only meant for testing at that point, and unfit even for an RFC.\n> \n> Sorry about that, I should ask you before send it out. It's my mistake. For I also\n> have some question about this patchset.\n> \n> We have related device, and would like to do some help about it. Do you have\n> any plan about upstream ?\n> \n>>\n>>> We tested this patchset with some fixes on a on-chip integrated device. The\n>>> basic function is ok, so I just send them out for review, although this\n>>> patchset heavily depends on the former patchset (PCIe SVM support for ARM\n>>> SMMUv3), which is still under discussion.\n>>>\n>>> Patch Overview:\n>>> *1 to 3 prepare for device tree or acpi get the device stall ability and pasid bits\n>>> *4 is to realise the SVM function for platform device\n>>> *5 is fix a bug when test SVM function while SMMU donnot support this feature\n>>> *6 avoid ILLEGAL setting of STE and CD entry about stall\n>>>\n>>> Acctually here, I also have some questions about SVM on SMMUv3:\n>>>\n>>> 1. Why the SVM feature on SMMUv3 depends on BTM feature? when bind a task to device,\n>>> it will register a mmu_notify. Therefore, when a page range is invalid, we can\n>>> send TLBI or ATC invalid without BTM?\n>>\n>> We could, but the end goal for SVM is to perfectly mirror the CPU page\n>> tables. So for platform SVM we would like to get rid of MMU notifiers\n>> entirely.\n> \n> I see, but for some SMMU which do not support BTM, it cannot benefit from SVM.\n> \n> Meanwhile, do you mean even with BTM feature, the PCI-e device also need to send a\n> ATC invalid by MMU notify? It seems not fair, why not hardware do the entirely work\n> in this case? It may costly for send ATC invalid and sync.\n\nIt will certainly be costly. But there are major problems with\ntransforming broadcast TLB maintenance into ATC invalidations in HW:\n\n* VMID:ASID to SID:SSID conversion. TLBIs use VMID:ASID, while ATCIs use\nSID:SSID.\n\n* Most importantly, ATC invalidations accounting. Each endpoint has a\nlimited number of in-flight ATC invalidate requests. The conversion module\nwould have to buffer incoming invalidations and wait for in-flight ATC\ninvalidation to complete before sending the next ones. In case of\noverflow, either we lose invalidation (which opens security holes) or we\nsomehow put back-pressure on the interconnect (no idea how feasible this\nis, I suspect really hard).\n\nSolving the last one is also quite difficult in software, but at least we\ncan still invalidate a range. In hardware we would invalidate the ATC\npage-by-page and quickly jam the bus.\n\nThanks,\nJean","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"D+SAwm3C\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xnJs16LlHz9sNc\n\tfor ;\n\tWed, 6 Sep 2017 19:56:53 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpX4i-0001LP-A1; Wed, 06 Sep 2017 09:56:48 +0000","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]\n\thelo=foss.arm.com)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpX4d-0001HM-VL for linux-arm-kernel@lists.infradead.org;\n\tWed, 06 Sep 2017 09:56:45 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D960A13D5;\n\tWed, 6 Sep 2017 02:56:23 -0700 (PDT)","from [10.1.211.72] (e106794-lin.cambridge.arm.com [10.1.211.72])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t6B4E03F3E1; Wed, 6 Sep 2017 02:56:20 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=MAUjMSYRSKJKo9KdoH7rsV9ep3uA+CJOPUFp1sO0COk=;\n\tb=D+SAwm3C0V8vZ3\n\t5GF91yefCIibCfM2R7stzAlnXOCexzpP2TG3NDO/vXcBpHI7/NkT/hODNsG3sqiZtlR000Tt8Uk6k\n\t949p0OUz9C8JQRmNxIR9VyO5xXif5K1PHyT+jv93pAWW94xpGl8GLWHOT184GUFCN7ghodPWcyTaS\n\tlB5hDOaNQJ5UvGYsGtIBop9igllbgAXBnrCRD7fp4myvTZ0K6YHmn9vYHd4dARmBqErtssPLRtcsu\n\t+li8NrP009uvo4mbavrJJMxnODsRr2WBWXwdK0mL1iOf+x+GjKFNmfxUWAfp9IsXd5VzOMSgumiWy\n\tE+Co5CFbQ4OC9CZ6PP3A==;","Subject":"Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3","To":"Yisheng Xie ","References":"<1504167642-14922-1-git-send-email-xieyisheng1@huawei.com>\n\t<95d1a9e2-1816-ff7d-9a8d-98406a6c2c22@arm.com>\n\t","From":"Jean-Philippe Brucker ","Message-ID":"","Date":"Wed, 6 Sep 2017 10:59:43 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.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-20170906_025644_035263_B6E2E63C ","X-CRM114-Status":"GOOD ( 20.48 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, devicetree@vger.kernel.org,\n\tlorenzo.pieralisi@arm.com, \n\tlv.zheng@intel.com, will.deacon@arm.com, joro@8bytes.org,\n\tliubo95@huawei.com, rjw@rjwysocki.net, robert.moore@intel.com,\n\tlinux-kernel@vger.kernel.org, \n\tlinux-acpi@vger.kernel.org, iommu@lists.linux-foundation.org,\n\trobh+dt@kernel.org, hanjun.guo@linaro.org, xieyisheng@huawei.com,\n\tsudeep.holla@arm.com, chenjiankang1@huawei.com, devel@acpica.org,\n\trobin.murphy@arm.com, linux-arm-kernel@lists.infradead.org,\n\tlenb@kernel.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1764463,"web_url":"http://patchwork.ozlabs.org/comment/1764463/","msgid":"<1d358989-48bb-ccde-d7d9-36e004bc2d78@huawei.com>","list_archive_url":null,"date":"2017-09-07T01:41:42","subject":"Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3","submitter":{"id":72301,"url":"http://patchwork.ozlabs.org/api/people/72301/","name":"Bob Liu","email":"liubo95@huawei.com"},"content":"On 2017/9/6 17:57, Jean-Philippe Brucker wrote:\n> On 06/09/17 02:02, Bob Liu wrote:\n>> On 2017/9/5 20:56, Jean-Philippe Brucker wrote:\n>>> On 31/08/17 09:20, Yisheng Xie wrote:\n>>>> Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM SMMUv3:\n>>>> https://www.spinics.net/lists/arm-kernel/msg565155.html\n>>>>\n>>>> But for some platform devices(aka on-chip integrated devices), there is also\n>>>> SVM requirement, which works based on the SMMU stall mode.\n>>>> Jean-Philippe has prepared a prototype patchset to support it:\n>>>> git://linux-arm.org/linux-jpb.git svm/stall\n>>>\n>>> Only meant for testing at that point, and unfit even for an RFC.\n>>>\n>>\n>> Sorry for the misunderstanding.\n>> The PRI mode patches is in RFC even no hardware for testing, so I thought it's fine for \"Stall mode\" patches sent as RFC.\n>> We have tested the Stall mode on our platform.\n>> Anyway, I should confirm with you in advance.\n>>\n>> Btw, Would you consider the \"stall mode\" upstream at first? Since there is no hardware for testing the PRI mode.\n>> (We can provide you the hardware which support SMMU stall mode if necessary.)\n> \n> Yes. What's blocking the ATS, PRI and PASID patches at the moment is the\n> lack of endpoints for testing. There has been lots of discussion on the\n> API side since my first RFC and I'd like to resubmit the API changes soon.\n> It is the same API for ATS+PRI+PASID and SSID+Stall, so the backend\n> doesn't matter.\n> \n\nIndeed!\n\n> I'm considering upstreaming SSID+Stall first if it can be tested on\n> hardware (having direct access to it would certainly speed things up).\n\nGlad to hear that.\n\n> This would require some work in moving the PCI bits at the end of the\n> series. I can reserve some time in the coming months to do it, but I need\n> to know what to focus on. Are you able to test SSID as well?\n> \n\nYes, but the difficulty is our devices are on-chip integrated hardware accelerators which requires complicate driver.\nYou may need much time to understand the driver.\nThat's the same case as intel/amd SVM, the current user is their GPU :-(\n\nBtw, what kind of device/method do you think is ideal for testing arm-SVM?\n\n>>>> We tested this patchset with some fixes on a on-chip integrated device. The\n>>>> basic function is ok, so I just send them out for review, although this\n>>>> patchset heavily depends on the former patchset (PCIe SVM support for ARM\n>>>> SMMUv3), which is still under discussion.\n>>>>\n>>>> Patch Overview:\n>>>> *1 to 3 prepare for device tree or acpi get the device stall ability and pasid bits\n>>>> *4 is to realise the SVM function for platform device\n>>>> *5 is fix a bug when test SVM function while SMMU donnot support this feature\n>>>> *6 avoid ILLEGAL setting of STE and CD entry about stall\n>>>>\n>>>> Acctually here, I also have a question about SVM on SMMUv3:\n>>>>\n>>>> 1. Why the SVM feature on SMMUv3 depends on BTM feature? when bind a task to device,\n>>>> it will register a mmu_notify. Therefore, when a page range is invalid, we can\n>>>> send TLBI or ATC invalid without BTM?\n>>>\n>>> We could, but the end goal for SVM is to perfectly mirror the CPU page\n>>> tables. So for platform SVM we would like to get rid of MMU notifiers\n>>> entirely.\n>>>\n>>>> 2. According to ACPI IORT spec, named component specific data has a node flags field\n>>>> whoes bit0 is for Stall support. However, it do not have any field for pasid bit.\n>>>> Can we use other 5 bits[5:1] for pasid bit numbers, so we can have 32 pasid bit for\n>>>> a single platform device which should be enough, because SMMU only support 20 bit pasid\n>>>>\n>>\n>> Any comment on this?\n>> The ACPI IORT spec may need be updated?\n> \n> I suppose that the Named Component Node could be used for SSID and stall\n> capability bits. Can't the ACPI namespace entries be extended to host\n> these capabilities in a more generic way? Platforms with different IOMMUs\n> might also need this information some day.\n> \n\nHmm, that would be better.\nBut in anyway, it depends on the ACPI IORT Spec would be extended in next version.\n\n--\nThanks,\nBob Liu","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"Ma/TCvoP\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xnjtl6VMrz9ryk\n\tfor ;\n\tThu, 7 Sep 2017 11:44:45 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dplrz-0000wa-TC; Thu, 07 Sep 2017 01:44:39 +0000","from szxga04-in.huawei.com ([45.249.212.190])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dplrv-0000ol-MV for linux-arm-kernel@lists.infradead.org;\n\tThu, 07 Sep 2017 01:44:38 +0000","from 172.30.72.60 (EHLO DGGEMS407-HUB.china.huawei.com)\n\t([172.30.72.60])\n\tby dggrg04-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id DGQ99641; Thu, 07 Sep 2017 09:43:38 +0800 (CST)","from [127.0.0.1] (10.142.83.150) by DGGEMS407-HUB.china.huawei.com\n\t(10.3.19.207) with Microsoft SMTP Server id 14.3.301.0;\n\tThu, 7 Sep 2017 09:43:29 +0800"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=PZHC5oFKWbcx3OlZyROEk3dHaJUz/f1SzJ9FKe3lyU8=;\n\tb=Ma/TCvoPTaYt+t\n\tUxz/qz4N1k4gBlrJcN9Da5wtk+oiZNtseQ/WN5u88nDkgPccSAoQsSsaPtDEjPXoalFR0cz7s6U7O\n\tooAUD/vx72qlOGbgGlwg17YaAKZEZsd/xB1LciZPdy3GrwQVZO68YpZ48muGaW3BcOlOFYtqzV8Nq\n\te4KrVaSspuLb2WtZY2iPcXkhZ5CifDUzTKi5Cvpjz7OCY/jiAtlbj38c3s85hLFXs1zqQ2zg8Eaqh\n\tC9mWIl1ZWjGA6604bmU/FJ7KXw14ISTyT4jas+1OtJ7xgC+b38trSg11uibyTtbwWth7DqglaX3Hi\n\tgSr6qx1FazCpH4s2xPiw==;","Subject":"Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3","To":"Jean-Philippe Brucker , Yisheng Xie\n\t","References":"<1504167642-14922-1-git-send-email-xieyisheng1@huawei.com>\n\t<95d1a9e2-1816-ff7d-9a8d-98406a6c2c22@arm.com>\n\t\n\t<2874a1f3-22f1-20d4-4009-50add127a10f@arm.com>","From":"Bob Liu ","Message-ID":"<1d358989-48bb-ccde-d7d9-36e004bc2d78@huawei.com>","Date":"Thu, 7 Sep 2017 09:41:42 +0800","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101\n\tThunderbird/45.8.0","MIME-Version":"1.0","In-Reply-To":"<2874a1f3-22f1-20d4-4009-50add127a10f@arm.com>","X-Originating-IP":"[10.142.83.150]","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A090204.59B0A44A.0112, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"1fbf0095867358040b476e1df2032556","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170906_184436_123998_4E8750D3 ","X-CRM114-Status":"GOOD ( 23.45 )","X-Spam-Score":"-1.9 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, devicetree@vger.kernel.org,\n\tlorenzo.pieralisi@arm.com, \n\tlv.zheng@intel.com, will.deacon@arm.com, joro@8bytes.org,\n\trjw@rjwysocki.net, robert.moore@intel.com, linux-kernel@vger.kernel.org,\n\tlinux-acpi@vger.kernel.org, iommu@lists.linux-foundation.org,\n\trobh+dt@kernel.org, hanjun.guo@linaro.org, xieyisheng@huawei.com,\n\tsudeep.holla@arm.com, chenjiankang1@huawei.com, devel@acpica.org,\n\trobin.murphy@arm.com, linux-arm-kernel@lists.infradead.org,\n\tlenb@kernel.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1764473,"web_url":"http://patchwork.ozlabs.org/comment/1764473/","msgid":"<8e4764f5-0e5d-7fd6-529b-35914e1e3668@huawei.com>","list_archive_url":null,"date":"2017-09-07T01:55:49","subject":"Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3","submitter":{"id":72301,"url":"http://patchwork.ozlabs.org/api/people/72301/","name":"Bob Liu","email":"liubo95@huawei.com"},"content":"On 2017/9/6 17:59, Jean-Philippe Brucker wrote:\n> On 06/09/17 02:16, Yisheng Xie wrote:\n>> Hi Jean-Philippe,\n>>\n>> On 2017/9/5 20:56, Jean-Philippe Brucker wrote:\n>>> On 31/08/17 09:20, Yisheng Xie wrote:\n>>>> Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM SMMUv3:\n>>>> https://www.spinics.net/lists/arm-kernel/msg565155.html\n>>>>\n>>>> But for some platform devices(aka on-chip integrated devices), there is also\n>>>> SVM requirement, which works based on the SMMU stall mode.\n>>>> Jean-Philippe has prepared a prototype patchset to support it:\n>>>> git://linux-arm.org/linux-jpb.git svm/stall\n>>>\n>>> Only meant for testing at that point, and unfit even for an RFC.\n>>\n>> Sorry about that, I should ask you before send it out. It's my mistake. For I also\n>> have some question about this patchset.\n>>\n>> We have related device, and would like to do some help about it. Do you have\n>> any plan about upstream ?\n>>\n>>>\n>>>> We tested this patchset with some fixes on a on-chip integrated device. The\n>>>> basic function is ok, so I just send them out for review, although this\n>>>> patchset heavily depends on the former patchset (PCIe SVM support for ARM\n>>>> SMMUv3), which is still under discussion.\n>>>>\n>>>> Patch Overview:\n>>>> *1 to 3 prepare for device tree or acpi get the device stall ability and pasid bits\n>>>> *4 is to realise the SVM function for platform device\n>>>> *5 is fix a bug when test SVM function while SMMU donnot support this feature\n>>>> *6 avoid ILLEGAL setting of STE and CD entry about stall\n>>>>\n>>>> Acctually here, I also have some questions about SVM on SMMUv3:\n>>>>\n>>>> 1. Why the SVM feature on SMMUv3 depends on BTM feature? when bind a task to device,\n>>>> it will register a mmu_notify. Therefore, when a page range is invalid, we can\n>>>> send TLBI or ATC invalid without BTM?\n>>>\n>>> We could, but the end goal for SVM is to perfectly mirror the CPU page\n>>> tables. So for platform SVM we would like to get rid of MMU notifiers\n>>> entirely.\n>>\n>> I see, but for some SMMU which do not support BTM, it cannot benefit from SVM.\n>>\n>> Meanwhile, do you mean even with BTM feature, the PCI-e device also need to send a\n>> ATC invalid by MMU notify? It seems not fair, why not hardware do the entirely work\n>> in this case? It may costly for send ATC invalid and sync.\n> \n> It will certainly be costly. But there are major problems with\n> transforming broadcast TLB maintenance into ATC invalidations in HW:\n> \n> * VMID:ASID to SID:SSID conversion. TLBIs use VMID:ASID, while ATCIs use\n> SID:SSID.\n> \n> * Most importantly, ATC invalidations accounting. Each endpoint has a\n> limited number of in-flight ATC invalidate requests. The conversion module\n> would have to buffer incoming invalidations and wait for in-flight ATC\n> invalidation to complete before sending the next ones. In case of\n> overflow, either we lose invalidation (which opens security holes) or we\n> somehow put back-pressure on the interconnect (no idea how feasible this\n> is, I suspect really hard).\n> \n> Solving the last one is also quite difficult in software, but at least we\n> can still invalidate a range. In hardware we would invalidate the ATC\n> page-by-page and quickly jam the bus.\n> \n\nSpeak to the invalidation, I have one more question.\n\nThere is a time window between 1) modify page table; 2) tlb invalidate;\n\nARM-CPU Device\n\n1. modify page table\n\n ^^^^^\n Can still write data through smmu tlb even page table was already modified.\n (At this point, the same virtual addr may not point to the same thing for CPU and device!!!\n I'm afraid there may be some data-loss or other potential problems if this situation happens.)\n\n2. tlb invalidate range\n\n--\nThanks,\nBob","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"ewGtXa9j\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xnkCZ4H8sz9s4s\n\tfor ;\n\tThu, 7 Sep 2017 11:59:22 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpm6A-0008BV-Hv; Thu, 07 Sep 2017 01:59:18 +0000","from szxga05-in.huawei.com ([45.249.212.191])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpm65-00085d-Hc for linux-arm-kernel@lists.infradead.org;\n\tThu, 07 Sep 2017 01:59:15 +0000","from 172.30.72.59 (EHLO DGGEMS407-HUB.china.huawei.com)\n\t([172.30.72.59])\n\tby dggrg05-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id DGT01547; Thu, 07 Sep 2017 09:58:20 +0800 (CST)","from [127.0.0.1] (10.142.83.150) by DGGEMS407-HUB.china.huawei.com\n\t(10.3.19.207) with Microsoft SMTP Server id 14.3.301.0;\n\tThu, 7 Sep 2017 09:58:07 +0800"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=PaV1EomrviBt0n+lrmKi8BwlDzgE06SCQ+3qj2ik6w8=;\n\tb=ewGtXa9jTizOw9\n\tJinrEBpi2zuT8wQwzE7p4y2haA8st6LUxsB2DjoDQOWR009px4CgScaO+Wg5rT1BUBQzZZZaYvNXs\n\tqc4vUfxQsTxd9E7bz3YuLUHEvGtXGa87Slg0TXXX1Ed3j+m+H9i+/pH0s4QETcK8bHNRza2pfL1G+\n\tKJBJoPGLEq+ryBosyircRpSxGPWuC3jpcnCQMVl5vwXMk9HmwG8xsEEueKucq0CVB+hlVmSAnO5Xn\n\tCaEe1/tix20t7lirBELkth6Z8UNJDoxXeKhXoB//3YJVVTo2mXRh3jZTNepU9Pr4ZXEwZbHu/el0u\n\tATs9vay62LYGNy5u81jw==;","Subject":"Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3","To":"Jean-Philippe Brucker , Yisheng Xie\n\t","References":"<1504167642-14922-1-git-send-email-xieyisheng1@huawei.com>\n\t<95d1a9e2-1816-ff7d-9a8d-98406a6c2c22@arm.com>\n\t\n\t","From":"Bob Liu ","Message-ID":"<8e4764f5-0e5d-7fd6-529b-35914e1e3668@huawei.com>","Date":"Thu, 7 Sep 2017 09:55:49 +0800","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101\n\tThunderbird/45.8.0","MIME-Version":"1.0","In-Reply-To":"","X-Originating-IP":"[10.142.83.150]","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A020201.59B0A7BD.00D2, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"d7765235516df6b4b4b943d0efef56cd","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170906_185913_929230_632D217D ","X-CRM114-Status":"GOOD ( 20.01 )","X-Spam-Score":"-1.9 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, devicetree@vger.kernel.org,\n\tlorenzo.pieralisi@arm.com, \n\tlv.zheng@intel.com, will.deacon@arm.com, joro@8bytes.org,\n\trjw@rjwysocki.net, robert.moore@intel.com, linux-kernel@vger.kernel.org,\n\tlinux-acpi@vger.kernel.org, iommu@lists.linux-foundation.org,\n\trobh+dt@kernel.org, hanjun.guo@linaro.org, xieyisheng@huawei.com,\n\tsudeep.holla@arm.com, chenjiankang1@huawei.com, devel@acpica.org,\n\trobin.murphy@arm.com, linux-arm-kernel@lists.infradead.org,\n\tlenb@kernel.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1764816,"web_url":"http://patchwork.ozlabs.org/comment/1764816/","msgid":"<24e7e405-ad4a-4847-6177-987966182cbd@arm.com>","list_archive_url":null,"date":"2017-09-07T16:30:37","subject":"Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3","submitter":{"id":68357,"url":"http://patchwork.ozlabs.org/api/people/68357/","name":"Jean-Philippe Brucker","email":"Jean-Philippe.Brucker@arm.com"},"content":"On 07/09/17 02:55, Bob Liu wrote:\n> Speak to the invalidation, I have one more question.\n> \n> There is a time window between 1) modify page table; 2) tlb invalidate;\n> \n> ARM-CPU Device\n> \n> 1. modify page table\n> \n> ^^^^^\n> Can still write data through smmu tlb even page table was already modified.\n> (At this point, the same virtual addr may not point to the same thing for CPU and device!!!\n> I'm afraid there may be some data-loss or other potential problems if this situation happens.)\n> \n> 2. tlb invalidate range\n\nThe mm code serializes map/unmap operations with mm->mmap_sem, and at a\nlower level I think the pte lock is used to prevent more subtle races.\nDon't take my word for it though, mm/ is still very obscure to me. So the\nkernel shouldn't be able to reuse the VA for something else before the tlb\ninvalidation completes. Even if you're using the CMDQ to invalidate\ninstead of TLBI instructions, you're still called by a notifier from the\nmm code so there is no problem.\n\nThanks,\nJean","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"MlAFV0+j\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xp5TV3hPjz9sQl\n\tfor ;\n\tFri, 8 Sep 2017 02:27:42 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpzeU-00031n-Vb; Thu, 07 Sep 2017 16:27:38 +0000","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]\n\thelo=foss.arm.com)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpzeS-0002y9-1N for linux-arm-kernel@lists.infradead.org;\n\tThu, 07 Sep 2017 16:27:37 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 42D3515AD;\n\tThu, 7 Sep 2017 09:27:14 -0700 (PDT)","from [10.1.211.72] (e106794-lin.cambridge.arm.com [10.1.211.72])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\tC34343F483; Thu, 7 Sep 2017 09:27:10 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=vxWP6NvWSSUX8KGYwkksixMBHJqV4FwWlZDoTXrDyVI=;\n\tb=MlAFV0+jwiDzzk\n\tIhVMPeitkHCgizUWW/fXFrXKzOXVbo/tGGsyXdqaC7F18npJoH2bKWD37pDOU6KzFRoto44HAh2BZ\n\tmhQTLl/DefFFf9vHoJ3Vc1stTigsXCe05nv40jtCax+iIMspPqkmnKF16d2kbipjc6aoehPlPHH/J\n\tVfXnQ2oIyemiDyMH7S+Rrd5+X5T/dYjS6Q8xI7yGevDKcccWteqQbPnMbZqF5gFybnQPXVjmsb7Q7\n\tD982yXQ7x2DRlVabnCwr63eQoyyzZQOb27jxwXVjE5p26so826VF4jEcDYTlBFXL/LZSbkbCgfUgH\n\tPD6PtMPo4wZ9ObOJKyxQ==;","Subject":"Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3","To":"Bob Liu , Yisheng Xie ","References":"<1504167642-14922-1-git-send-email-xieyisheng1@huawei.com>\n\t<95d1a9e2-1816-ff7d-9a8d-98406a6c2c22@arm.com>\n\t\n\t\n\t<8e4764f5-0e5d-7fd6-529b-35914e1e3668@huawei.com>","From":"Jean-Philippe Brucker ","Message-ID":"<24e7e405-ad4a-4847-6177-987966182cbd@arm.com>","Date":"Thu, 7 Sep 2017 17:30:37 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<8e4764f5-0e5d-7fd6-529b-35914e1e3668@huawei.com>","Content-Language":"en-US","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170907_092736_103959_1B3AEEF0 ","X-CRM114-Status":"GOOD ( 10.88 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, devicetree@vger.kernel.org,\n\tlorenzo.pieralisi@arm.com, \n\tlv.zheng@intel.com, will.deacon@arm.com, joro@8bytes.org,\n\trjw@rjwysocki.net, robert.moore@intel.com, linux-kernel@vger.kernel.org,\n\tlinux-acpi@vger.kernel.org, iommu@lists.linux-foundation.org,\n\trobh+dt@kernel.org, hanjun.guo@linaro.org, xieyisheng@huawei.com,\n\tsudeep.holla@arm.com, chenjiankang1@huawei.com, devel@acpica.org,\n\trobin.murphy@arm.com, linux-arm-kernel@lists.infradead.org,\n\tlenb@kernel.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1764818,"web_url":"http://patchwork.ozlabs.org/comment/1764818/","msgid":"","list_archive_url":null,"date":"2017-09-07T16:32:13","subject":"Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3","submitter":{"id":68357,"url":"http://patchwork.ozlabs.org/api/people/68357/","name":"Jean-Philippe Brucker","email":"Jean-Philippe.Brucker@arm.com"},"content":"On 07/09/17 02:41, Bob Liu wrote:\n>> This would require some work in moving the PCI bits at the end of the\n>> series. I can reserve some time in the coming months to do it, but I need\n>> to know what to focus on. Are you able to test SSID as well?\n>>\n> \n> Yes, but the difficulty is our devices are on-chip integrated hardware accelerators which requires complicate driver.\n> You may need much time to understand the driver.\n> That's the same case as intel/amd SVM, the current user is their GPU :-(\n> \n> Btw, what kind of device/method do you think is ideal for testing arm-SVM?\n\nA simple, bare DMA engine would be ideal. Something just capable of\nperforming memcpy with parameters (PASID, input IOVA, output IOVA, size)\ncan be used for validating SVM and virtualization. You could easily create\nreproducible unit tests and userspace drivers. If it supports isolated\nchannels (as in SR-IOV), even better.\n\nAs you said, having a useful device like a full GPU/accelerator as opposed\nto a dummy validation engine makes it difficult to fully test the SMMU.\nHowever it can be helpful for evaluating driver performances and is still\ngood enough for confirming that the IOMMU works.\n\nThanks,\nJean","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"nLhTNsEP\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xp5WK0vJbz9sQl\n\tfor ;\n\tFri, 8 Sep 2017 02:29:17 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpzg2-0003Wp-Cc; Thu, 07 Sep 2017 16:29:14 +0000","from foss.arm.com ([217.140.101.70])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpzfy-0003Sh-KW for linux-arm-kernel@lists.infradead.org;\n\tThu, 07 Sep 2017 16:29:12 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 47E2615AD;\n\tThu, 7 Sep 2017 09:28:50 -0700 (PDT)","from [10.1.211.72] (e106794-lin.cambridge.arm.com [10.1.211.72])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\tD3DCB3F483; Thu, 7 Sep 2017 09:28:46 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:References:To:Subject:From:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=GKtBkgsikZTRbB/5yI30KY2cyvefFFZ51+E+F522CjQ=;\n\tb=nLhTNsEPK9s0Yy\n\thvpMbKw7KGhBr1cMfWwyDFeXQkA6qaIWk4Osuw+ttNwXp7xDcky4MtlS2PAIEWdfmw+7xvXeJiPx+\n\t5T8mkLAf0AGz1Q8GuI0HNMFdWag6DEnteGB+BBdG68p6lIjy4ruXsDYlUz/LGBJK0eFH3PHUabe+o\n\tjcga/WCKPGmkS/EMafK3M4O7TMsGkUepp9VvCbQzBSootrSPBXKFDAAPoB9b2fEUiPPsg1s6HtZSS\n\tIpISoIXzrbPUtbd/daW4vOCXEEV/vkgTKuQMm/Ghr1JKZTKGCHjdm8Ovo4qBsESOn5z7zz7shV1tI\n\tIHoafuoDqXfaCPlDUrNw==;","From":"Jean-Philippe Brucker ","Subject":"Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3","To":"Bob Liu , Yisheng Xie ","References":"<1504167642-14922-1-git-send-email-xieyisheng1@huawei.com>\n\t<95d1a9e2-1816-ff7d-9a8d-98406a6c2c22@arm.com>\n\t\n\t<2874a1f3-22f1-20d4-4009-50add127a10f@arm.com>\n\t<1d358989-48bb-ccde-d7d9-36e004bc2d78@huawei.com>","Message-ID":"","Date":"Thu, 7 Sep 2017 17:32:13 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<1d358989-48bb-ccde-d7d9-36e004bc2d78@huawei.com>","Content-Language":"en-US","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170907_092910_778069_A36DA2CF ","X-CRM114-Status":"GOOD ( 10.81 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, devicetree@vger.kernel.org,\n\tlorenzo.pieralisi@arm.com, \n\tlv.zheng@intel.com, will.deacon@arm.com, joro@8bytes.org,\n\trjw@rjwysocki.net, robert.moore@intel.com, linux-kernel@vger.kernel.org,\n\tlinux-acpi@vger.kernel.org, iommu@lists.linux-foundation.org,\n\trobh+dt@kernel.org, hanjun.guo@linaro.org, xieyisheng@huawei.com,\n\tsudeep.holla@arm.com, chenjiankang1@huawei.com, devel@acpica.org,\n\trobin.murphy@arm.com, linux-arm-kernel@lists.infradead.org,\n\tlenb@kernel.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1767445,"web_url":"http://patchwork.ozlabs.org/comment/1767445/","msgid":"<9d7083a7-fc67-26a3-0d3d-f1a5a4942eaf@huawei.com>","list_archive_url":null,"date":"2017-09-13T01:11:03","subject":"Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3","submitter":{"id":72301,"url":"http://patchwork.ozlabs.org/api/people/72301/","name":"Bob Liu","email":"liubo95@huawei.com"},"content":"On 2017/9/6 17:57, Jean-Philippe Brucker wrote:\n> On 06/09/17 02:02, Bob Liu wrote:\n>> On 2017/9/5 20:56, Jean-Philippe Brucker wrote:\n>>> On 31/08/17 09:20, Yisheng Xie wrote:\n>>>> Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM SMMUv3:\n>>>> https://www.spinics.net/lists/arm-kernel/msg565155.html\n>>>>\n>>>> But for some platform devices(aka on-chip integrated devices), there is also\n>>>> SVM requirement, which works based on the SMMU stall mode.\n>>>> Jean-Philippe has prepared a prototype patchset to support it:\n>>>> git://linux-arm.org/linux-jpb.git svm/stall\n>>>\n>>> Only meant for testing at that point, and unfit even for an RFC.\n>>>\n>>\n>> Sorry for the misunderstanding.\n>> The PRI mode patches is in RFC even no hardware for testing, so I thought it's fine for \"Stall mode\" patches sent as RFC.\n>> We have tested the Stall mode on our platform.\n>> Anyway, I should confirm with you in advance.\n>>\n>> Btw, Would you consider the \"stall mode\" upstream at first? Since there is no hardware for testing the PRI mode.\n>> (We can provide you the hardware which support SMMU stall mode if necessary.)\n> \n> Yes. What's blocking the ATS, PRI and PASID patches at the moment is the\n> lack of endpoints for testing. There has been lots of discussion on the\n> API side since my first RFC and I'd like to resubmit the API changes soon.\n> It is the same API for ATS+PRI+PASID and SSID+Stall, so the backend\n> doesn't matter.\n> \n> I'm considering upstreaming SSID+Stall first if it can be tested on\n> hardware (having direct access to it would certainly speed things up).\n> This would require some work in moving the PCI bits at the end of the\n> series. I can reserve some time in the coming months to do it, but I need\n> to know what to focus on. Are you able to test SSID as well?\n> \n\nUpdate:\nOur current platform device has only one SSID register, so that have to do manually \nswitch(write different ssid to that register) if want to use by different processes.\n\nBut we're going to have an new platform who's platform device can support multi ssid.\n\nRegards,\nBob\n\n>>>> We tested this patchset with some fixes on a on-chip integrated device. The\n>>>> basic function is ok, so I just send them out for review, although this\n>>>> patchset heavily depends on the former patchset (PCIe SVM support for ARM\n>>>> SMMUv3), which is still under discussion.\n>>>>\n>>>> Patch Overview:\n>>>> *1 to 3 prepare for device tree or acpi get the device stall ability and pasid bits\n>>>> *4 is to realise the SVM function for platform device\n>>>> *5 is fix a bug when test SVM function while SMMU donnot support this feature\n>>>> *6 avoid ILLEGAL setting of STE and CD entry about stall\n>>>>\n>>>> Acctually here, I also have a question about SVM on SMMUv3:\n>>>>\n>>>> 1. Why the SVM feature on SMMUv3 depends on BTM feature? when bind a task to device,\n>>>> it will register a mmu_notify. Therefore, when a page range is invalid, we can\n>>>> send TLBI or ATC invalid without BTM?\n>>>\n>>> We could, but the end goal for SVM is to perfectly mirror the CPU page\n>>> tables. So for platform SVM we would like to get rid of MMU notifiers\n>>> entirely.\n>>>\n>>>> 2. According to ACPI IORT spec, named component specific data has a node flags field\n>>>> whoes bit0 is for Stall support. However, it do not have any field for pasid bit.\n>>>> Can we use other 5 bits[5:1] for pasid bit numbers, so we can have 32 pasid bit for\n>>>> a single platform device which should be enough, because SMMU only support 20 bit pasid\n>>>>\n>>\n>> Any comment on this?\n>> The ACPI IORT spec may need be updated?\n> \n> I suppose that the Named Component Node could be used for SSID and stall\n> capability bits. Can't the ACPI namespace entries be extended to host\n> these capabilities in a more generic way? Platforms with different IOMMUs\n> might also need this information some day.\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"fawja6+7\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xsNtz6g0Mz9t4V\n\tfor ;\n\tWed, 13 Sep 2017 11:12:42 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1drwEJ-000828-12; Wed, 13 Sep 2017 01:12:39 +0000","from szxga04-in.huawei.com ([45.249.212.190])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1drwEE-0007vc-2F for linux-arm-kernel@lists.infradead.org;\n\tWed, 13 Sep 2017 01:12:36 +0000","from 172.30.72.59 (EHLO DGGEMS410-HUB.china.huawei.com)\n\t([172.30.72.59])\n\tby dggrg04-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id DHC62917; Wed, 13 Sep 2017 09:11:43 +0800 (CST)","from [127.0.0.1] (10.142.83.150) by DGGEMS410-HUB.china.huawei.com\n\t(10.3.19.210) with Microsoft SMTP Server id 14.3.301.0;\n\tWed, 13 Sep 2017 09:11:31 +0800"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=siia4ic7VaQCaRy4qD6L6yVUNXu1V1Fn+JP/hx910PM=;\n\tb=fawja6+7mB/Szj\n\tjS49mEi2AhCbi6w/gppUgIjueAio5FEfp7KnBmiOlDG4oUilWlkX++P+rl8P1dIbAa99aKazSuo9w\n\tqzgQ7G4JNXpEaqC3CicyNft1Mi/XSvcq7pxT+MMJ6RD8dMx4+4zDSqzMMxpNBeo/AjJ57t69c0i9p\n\tpZUR3XzlOaTuym+7Rex/vL6uOIXiqu8t5klNQkfSHYEV9L0KgfUmNxoC4CAaOqRosScNNPjFGFbKW\n\tOvbHSp0QAcg7QHdeydCrhvUPVFTgiARixxlVYjz4tZn5wRNBNy7GFTsXRX4XjYzmPyDApix2p8BrO\n\t2E9KFgJkPm+rZl2DLwEw==;","Subject":"Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3","To":"Jean-Philippe Brucker , Yisheng Xie\n\t","References":"<1504167642-14922-1-git-send-email-xieyisheng1@huawei.com>\n\t<95d1a9e2-1816-ff7d-9a8d-98406a6c2c22@arm.com>\n\t\n\t<2874a1f3-22f1-20d4-4009-50add127a10f@arm.com>","From":"Bob Liu ","Message-ID":"<9d7083a7-fc67-26a3-0d3d-f1a5a4942eaf@huawei.com>","Date":"Wed, 13 Sep 2017 09:11:03 +0800","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101\n\tThunderbird/45.8.0","MIME-Version":"1.0","In-Reply-To":"<2874a1f3-22f1-20d4-4009-50add127a10f@arm.com>","X-Originating-IP":"[10.142.83.150]","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A020206.59B885D1.0080, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"1fbf0095867358040b476e1df2032556","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170912_181234_445100_E9B1B52B ","X-CRM114-Status":"GOOD ( 22.47 )","X-Spam-Score":"-1.9 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, devicetree@vger.kernel.org,\n\tlorenzo.pieralisi@arm.com, \n\tlv.zheng@intel.com, will.deacon@arm.com, joro@8bytes.org,\n\trjw@rjwysocki.net, robert.moore@intel.com, linux-kernel@vger.kernel.org,\n\tlinux-acpi@vger.kernel.org, iommu@lists.linux-foundation.org,\n\trobh+dt@kernel.org, hanjun.guo@linaro.org, xieyisheng@huawei.com,\n\tsudeep.holla@arm.com, chenjiankang1@huawei.com, devel@acpica.org,\n\trobin.murphy@arm.com, linux-arm-kernel@lists.infradead.org,\n\tlenb@kernel.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1767522,"web_url":"http://patchwork.ozlabs.org/comment/1767522/","msgid":"<20170913030643.GD12411@arm.com>","list_archive_url":null,"date":"2017-09-13T03:06:44","subject":"Re: [RFC PATCH 6/6] iommu/arm-smmu-v3: Avoid ILLEGAL setting of\n\tSTE.S1STALLD and CD.S","submitter":{"id":7916,"url":"http://patchwork.ozlabs.org/api/people/7916/","name":"Will Deacon","email":"will.deacon@arm.com"},"content":"On Tue, Sep 05, 2017 at 01:54:19PM +0100, Jean-Philippe Brucker wrote:\n> On 31/08/17 09:20, Yisheng Xie wrote:\n> > It is ILLEGAL to set STE.S1STALLD if STALL_MODEL is not 0b00, which\n> > means we should not disable stall mode if stall/terminate mode is not\n> > configuable.\n> > \n> > Meanwhile, it is also ILLEGAL when STALL_MODEL==0b10 && CD.S==0 which\n> > means if stall mode is force we should always set CD.S.\n> > \n> > This patch add ARM_SMMU_FEAT_TERMINATE feature bit for smmu, and use\n> > TERMINATE feature checking to ensue above ILLEGAL cases from happening.\n> > \n> > Signed-off-by: Yisheng Xie \n> > ---\n> > drivers/iommu/arm-smmu-v3.c | 22 ++++++++++++++++------\n> > 1 file changed, 16 insertions(+), 6 deletions(-)\n> > \n> > diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c\n> > index dbda2eb..0745522 100644\n> > --- a/drivers/iommu/arm-smmu-v3.c\n> > +++ b/drivers/iommu/arm-smmu-v3.c\n> > @@ -55,6 +55,7 @@\n> > #define IDR0_STALL_MODEL_SHIFT\t\t24\n> > #define IDR0_STALL_MODEL_MASK\t\t0x3\n> > #define IDR0_STALL_MODEL_STALL\t\t(0 << IDR0_STALL_MODEL_SHIFT)\n> > +#define IDR0_STALL_MODEL_NS\t\t(1 << IDR0_STALL_MODEL_SHIFT)\n> > #define IDR0_STALL_MODEL_FORCE\t\t(2 << IDR0_STALL_MODEL_SHIFT)\n> > #define IDR0_TTENDIAN_SHIFT\t\t21\n> > #define IDR0_TTENDIAN_MASK\t\t0x3\n> > @@ -766,6 +767,7 @@ struct arm_smmu_device {\n> > #define ARM_SMMU_FEAT_SVM\t\t(1 << 15)\n> > #define ARM_SMMU_FEAT_HA\t\t(1 << 16)\n> > #define ARM_SMMU_FEAT_HD\t\t(1 << 17)\n> > +#define ARM_SMMU_FEAT_TERMINATE\t\t(1 << 18)\n> \n> I'd rather introduce something like \"ARM_SMMU_FEAT_STALL_FORCE\" instead.\n> Terminate model has another meaning, and is defined by a different bit in\n> IDR0.\n\nYes. What we need to do is:\n\n- If STALL_MODEL is 0b00, then set S1STALLD\n- If STALL_MODEL is 0b01, then we're ok (in future, avoiding trying to use\n stalls, even for masters that claim to support it)\n- If STALL_MODEL is 0b10, then force all PCI devices and any platform\n devices that don't claim to support stalls into bypass (depending on\n disable_bypass).\n\nReasonable? We could actually knock up a fix for mainline to do most of\nthis already.\n\nWill","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"GY96HDVN\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xsRRS0ntpz9sPk\n\tfor ;\n\tWed, 13 Sep 2017 13:07:30 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dry0y-0008Li-Cb; Wed, 13 Sep 2017 03:07:00 +0000","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]\n\thelo=foss.arm.com)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dry0t-0008Gr-Ow for linux-arm-kernel@lists.infradead.org;\n\tWed, 13 Sep 2017 03:06:57 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3D14B1596;\n\tTue, 12 Sep 2017 20:06:35 -0700 (PDT)","from edgewater-inn.cambridge.arm.com\n\t(usa-sjc-imap-foss1.foss.arm.com [10.72.51.249])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id\n\t0A3073F483; Tue, 12 Sep 2017 20:06:35 -0700 (PDT)","by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000)\n\tid 7AC791AE37A8; Wed, 13 Sep 2017 04:06:44 +0100 (BST)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:\n\tMessage-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=xziur7cY9N1mkBURU5avGBusLfFZ4+mc/KwAs+05jzQ=;\n\tb=GY96HDVNqm9iK+\n\tQQVSMWeA6seQRBZEVehdx/oKjXoQV9ivjXh2zI7jONr4+3Bh0gjCoF5p80twsHzHOIoJOwV5FvtUT\n\tK/HyBmxOEIqlnoooxE28g+IaLTLMWor9K+xtX59JxFEzCDIhB25afaWl9uRz2ntMGBrMRjh6zLAFT\n\tRsAr3bYfU6SRosz7SkRwgDDL0LbVjDt6eKxCuLaa3ZkJAIPRt+F89zwDl59p6wSGUKhSrBLgpch1v\n\t21xbgxi5kwhBpflGJv3u5GEat8RRNyQHY9r8IgwqbC6teh1u3YgYWQ8vWGiTDXGxlVIGXrNB1X9Ua\n\t3abxQX0+koru5eMuKWUg==;","Date":"Wed, 13 Sep 2017 04:06:44 +0100","From":"Will Deacon ","To":"Jean-Philippe Brucker ","Subject":"Re: [RFC PATCH 6/6] iommu/arm-smmu-v3: Avoid ILLEGAL setting of\n\tSTE.S1STALLD and CD.S","Message-ID":"<20170913030643.GD12411@arm.com>","References":"<1504167642-14922-1-git-send-email-xieyisheng1@huawei.com>\n\t<1504167642-14922-7-git-send-email-xieyisheng1@huawei.com>\n\t<738977bb-4cd7-7d86-0ea0-0c88b6af721c@arm.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<738977bb-4cd7-7d86-0ea0-0c88b6af721c@arm.com>","User-Agent":"Mutt/1.5.23 (2014-03-12)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170912_200655_820731_548DF03C ","X-CRM114-Status":"GOOD ( 15.08 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Yisheng Xie , mark.rutland@arm.com,\n\tlorenzo.pieralisi@arm.com, lv.zheng@intel.com,\n\tdevicetree@vger.kernel.org, \n\tjoro@8bytes.org, liubo95@huawei.com, rjw@rjwysocki.net,\n\trobert.moore@intel.com, \n\tlinux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,\n\tiommu@lists.linux-foundation.org, robh+dt@kernel.org,\n\thanjun.guo@linaro.org, \n\txieyisheng@huawei.com, sudeep.holla@arm.com, chenjiankang1@huawei.com,\n\tdevel@acpica.org, robin.murphy@arm.com,\n\tlinux-arm-kernel@lists.infradead.org, lenb@kernel.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1767755,"web_url":"http://patchwork.ozlabs.org/comment/1767755/","msgid":"<2f952821-afc3-46dd-17eb-40e8626bd6e5@huawei.com>","list_archive_url":null,"date":"2017-09-13T10:11:13","subject":"Re: [RFC PATCH 6/6] iommu/arm-smmu-v3: Avoid ILLEGAL setting of\n\tSTE.S1STALLD and CD.S","submitter":{"id":72263,"url":"http://patchwork.ozlabs.org/api/people/72263/","name":"Yisheng Xie","email":"xieyisheng1@huawei.com"},"content":"Hi Will,\n\nOn 2017/9/13 11:06, Will Deacon wrote:\n> On Tue, Sep 05, 2017 at 01:54:19PM +0100, Jean-Philippe Brucker wrote:\n>> On 31/08/17 09:20, Yisheng Xie wrote:\n>>> It is ILLEGAL to set STE.S1STALLD if STALL_MODEL is not 0b00, which\n>>> means we should not disable stall mode if stall/terminate mode is not\n>>> configuable.\n>>>\n>>> Meanwhile, it is also ILLEGAL when STALL_MODEL==0b10 && CD.S==0 which\n>>> means if stall mode is force we should always set CD.S.\n>>>\n>>> This patch add ARM_SMMU_FEAT_TERMINATE feature bit for smmu, and use\n>>> TERMINATE feature checking to ensue above ILLEGAL cases from happening.\n>>>\n>>> Signed-off-by: Yisheng Xie \n>>> ---\n>>> drivers/iommu/arm-smmu-v3.c | 22 ++++++++++++++++------\n>>> 1 file changed, 16 insertions(+), 6 deletions(-)\n>>>\n>>> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c\n>>> index dbda2eb..0745522 100644\n>>> --- a/drivers/iommu/arm-smmu-v3.c\n>>> +++ b/drivers/iommu/arm-smmu-v3.c\n>>> @@ -55,6 +55,7 @@\n>>> #define IDR0_STALL_MODEL_SHIFT\t\t24\n>>> #define IDR0_STALL_MODEL_MASK\t\t0x3\n>>> #define IDR0_STALL_MODEL_STALL\t\t(0 << IDR0_STALL_MODEL_SHIFT)\n>>> +#define IDR0_STALL_MODEL_NS\t\t(1 << IDR0_STALL_MODEL_SHIFT)\n>>> #define IDR0_STALL_MODEL_FORCE\t\t(2 << IDR0_STALL_MODEL_SHIFT)\n>>> #define IDR0_TTENDIAN_SHIFT\t\t21\n>>> #define IDR0_TTENDIAN_MASK\t\t0x3\n>>> @@ -766,6 +767,7 @@ struct arm_smmu_device {\n>>> #define ARM_SMMU_FEAT_SVM\t\t(1 << 15)\n>>> #define ARM_SMMU_FEAT_HA\t\t(1 << 16)\n>>> #define ARM_SMMU_FEAT_HD\t\t(1 << 17)\n>>> +#define ARM_SMMU_FEAT_TERMINATE\t\t(1 << 18)\n>>\n>> I'd rather introduce something like \"ARM_SMMU_FEAT_STALL_FORCE\" instead.\n>> Terminate model has another meaning, and is defined by a different bit in\n>> IDR0.\n> \n> Yes. What we need to do is:\n> \n> - If STALL_MODEL is 0b00, then set S1STALLD\n\nYes, and within this case, we can only set the S1STALLD for masters which can\nnot stall in the future?\n\n> - If STALL_MODEL is 0b01, then we're ok (in future, avoiding trying to use\n> stalls, even for masters that claim to support it)\n> - If STALL_MODEL is 0b10, then force all PCI devices and any platform\n> devices that don't claim to support stalls into bypass (depending on\n> disable_bypass).\n> \n> Reasonable? We could actually knock up a fix for mainline to do most of\n> this already.\nThis sound reasonable to me. And I can be a volunteer to prepare this patch if\nJean-Philippe do not oppose :)\n\nThanks\nYisheng Xie\n\n> \n> Will\n> \n> .\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"f2f4w2np\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xsctK4YPHz9s9Y\n\tfor ;\n\tWed, 13 Sep 2017 20:12:57 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1ds4f8-0003Wt-FZ; Wed, 13 Sep 2017 10:12:54 +0000","from szxga04-in.huawei.com ([45.249.212.190])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1ds4f3-0003T1-RD for linux-arm-kernel@lists.infradead.org;\n\tWed, 13 Sep 2017 10:12:52 +0000","from 172.30.72.59 (EHLO DGGEMS414-HUB.china.huawei.com)\n\t([172.30.72.59])\n\tby dggrg04-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id DHD39825; Wed, 13 Sep 2017 18:11:27 +0800 (CST)","from [127.0.0.1] (10.177.29.40) by DGGEMS414-HUB.china.huawei.com\n\t(10.3.19.214) with Microsoft SMTP Server id 14.3.301.0;\n\tWed, 13 Sep 2017 18:11:18 +0800"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:References:To:Subject:From:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=QZ1CvMHIN6ltZfkuDVdOE6PZBTexRoN9hOPrLzwScC4=;\n\tb=f2f4w2np+D+Som\n\tWo8g05FlWLkJe/Gj94Iq76X2GHgCOj9kxwA1pCUonyEreeDgWSQ0lIFCBJan1mzC1pRdL9HSNZGkd\n\t0IB00kkBBonswP+qL/RFCwIWJF4CuGz+30xouTZb/xle9YqZQjOysx2TFORhDMaSZgmOtNZCmuOo2\n\tboMssi9HoZ64UqCaAczLk1ov5QpCB6/GBjyfsetbsyvjAK+WlzM//waxQoqHF9HqvO6lx32LcKh/G\n\tizQPXfWK+L+xdn7I9Xhn8MkxJ0TwTsRgifgz84TEtIhirMPlmpjnScwGlOX1PYFyBnu4KLQo0/S8Y\n\tK6fc+HXrVzZv5PQgYvLQ==;","From":"Yisheng Xie ","Subject":"Re: [RFC PATCH 6/6] iommu/arm-smmu-v3: Avoid ILLEGAL setting of\n\tSTE.S1STALLD and CD.S","To":"Will Deacon , Jean-Philippe Brucker\n\t","References":"<1504167642-14922-1-git-send-email-xieyisheng1@huawei.com>\n\t<1504167642-14922-7-git-send-email-xieyisheng1@huawei.com>\n\t<738977bb-4cd7-7d86-0ea0-0c88b6af721c@arm.com>\n\t<20170913030643.GD12411@arm.com>","Message-ID":"<2f952821-afc3-46dd-17eb-40e8626bd6e5@huawei.com>","Date":"Wed, 13 Sep 2017 18:11:13 +0800","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101\n\tThunderbird/45.1.0","MIME-Version":"1.0","In-Reply-To":"<20170913030643.GD12411@arm.com>","X-Originating-IP":"[10.177.29.40]","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A090202.59B90450.002D, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"eaac97f5f94b6b047243d4909bd1c3ff","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170913_031250_200171_5D63C0DB ","X-CRM114-Status":"GOOD ( 12.54 )","X-Spam-Score":"-1.9 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, devicetree@vger.kernel.org, xieyisheng1@huawei.com,\n\tlorenzo.pieralisi@arm.com, lv.zheng@intel.com, joro@8bytes.org,\n\tliubo95@huawei.com, rjw@rjwysocki.net, robert.moore@intel.com,\n\tlinux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,\n\tiommu@lists.linux-foundation.org, robh+dt@kernel.org,\n\thanjun.guo@linaro.org, \n\tsudeep.holla@arm.com, chenjiankang1@huawei.com, devel@acpica.org,\n\trobin.murphy@arm.com, linux-arm-kernel@lists.infradead.org,\n\tlenb@kernel.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1767978,"web_url":"http://patchwork.ozlabs.org/comment/1767978/","msgid":"","list_archive_url":null,"date":"2017-09-13T15:47:27","subject":"Re: [RFC PATCH 6/6] iommu/arm-smmu-v3: Avoid ILLEGAL setting of\n\tSTE.S1STALLD and CD.S","submitter":{"id":68357,"url":"http://patchwork.ozlabs.org/api/people/68357/","name":"Jean-Philippe Brucker","email":"Jean-Philippe.Brucker@arm.com"},"content":"On 13/09/17 11:11, Yisheng Xie wrote:\n> Hi Will,\n> \n> On 2017/9/13 11:06, Will Deacon wrote:\n>> On Tue, Sep 05, 2017 at 01:54:19PM +0100, Jean-Philippe Brucker wrote:\n>>> On 31/08/17 09:20, Yisheng Xie wrote:\n>>>> It is ILLEGAL to set STE.S1STALLD if STALL_MODEL is not 0b00, which\n>>>> means we should not disable stall mode if stall/terminate mode is not\n>>>> configuable.\n>>>>\n>>>> Meanwhile, it is also ILLEGAL when STALL_MODEL==0b10 && CD.S==0 which\n>>>> means if stall mode is force we should always set CD.S.\n>>>>\n>>>> This patch add ARM_SMMU_FEAT_TERMINATE feature bit for smmu, and use\n>>>> TERMINATE feature checking to ensue above ILLEGAL cases from happening.\n>>>>\n>>>> Signed-off-by: Yisheng Xie \n>>>> ---\n>>>>  drivers/iommu/arm-smmu-v3.c | 22 ++++++++++++++++------\n>>>>  1 file changed, 16 insertions(+), 6 deletions(-)\n>>>>\n>>>> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c\n>>>> index dbda2eb..0745522 100644\n>>>> --- a/drivers/iommu/arm-smmu-v3.c\n>>>> +++ b/drivers/iommu/arm-smmu-v3.c\n>>>> @@ -55,6 +55,7 @@\n>>>>  #define IDR0_STALL_MODEL_SHIFT             24\n>>>>  #define IDR0_STALL_MODEL_MASK              0x3\n>>>>  #define IDR0_STALL_MODEL_STALL             (0 << IDR0_STALL_MODEL_SHIFT)\n>>>> +#define IDR0_STALL_MODEL_NS                (1 << IDR0_STALL_MODEL_SHIFT)\n>>>>  #define IDR0_STALL_MODEL_FORCE             (2 << IDR0_STALL_MODEL_SHIFT)\n>>>>  #define IDR0_TTENDIAN_SHIFT                21\n>>>>  #define IDR0_TTENDIAN_MASK         0x3\n>>>> @@ -766,6 +767,7 @@ struct arm_smmu_device {\n>>>>  #define ARM_SMMU_FEAT_SVM          (1 << 15)\n>>>>  #define ARM_SMMU_FEAT_HA           (1 << 16)\n>>>>  #define ARM_SMMU_FEAT_HD           (1 << 17)\n>>>> +#define ARM_SMMU_FEAT_TERMINATE            (1 << 18)\n>>>\n>>> I'd rather introduce something like \"ARM_SMMU_FEAT_STALL_FORCE\" instead.\n>>> Terminate model has another meaning, and is defined by a different bit in\n>>> IDR0.\n>> \n>> Yes. What we need to do is:\n>> \n>> - If STALL_MODEL is 0b00, then set S1STALLD\n> \n> Yes, and within this case, we can only set the S1STALLD for masters which can\n> not stall in the future?\n> \n>> - If STALL_MODEL is 0b01, then we're ok (in future, avoiding trying to use\n>>   stalls, even for masters that claim to support it)\n>> - If STALL_MODEL is 0b10, then force all PCI devices and any platform\n>>   devices that don't claim to support stalls into bypass (depending on\n>>   disable_bypass).\n>> \n>> Reasonable? We could actually knock up a fix for mainline to do most of\n>> this already.\n> This sound reasonable to me. And I can be a volunteer to prepare this patch if\n> Jean-Philippe do not oppose :)\n\nSure go ahead, I'll rebase the platform SVM work on top of it.\n\nThanks,\nJean","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"BiMsVtHz\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xsmJM5Xzkz9sMN\n\tfor ;\n\tThu, 14 Sep 2017 01:47:31 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1ds9su-0000lZ-Ib; Wed, 13 Sep 2017 15:47:28 +0000","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]\n\thelo=foss.arm.com)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1ds9sq-0000iZ-KM for linux-arm-kernel@lists.infradead.org;\n\tWed, 13 Sep 2017 15:47:26 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 166351596;\n\tWed, 13 Sep 2017 08:47:03 -0700 (PDT)","from [172.20.189.210] (usa-sjc-mx-foss1.foss.arm.com\n\t[217.140.101.70])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t8CF3D3F578; Wed, 13 Sep 2017 08:47:02 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=JUkpQsK4722HW9vR9bIbQATtN33/lA3bQBWfvA5mka0=;\n\tb=BiMsVtHzE2Wxjc\n\tAw9FReWxMIXPZ+mUtsvAYOboTUCmQlvVhg20psNiqRoH07FMBnHdcYV11P2CNx5jVb8YFnzQBwhcL\n\thpGJNYIRaBEprp6K8401MhbkI5Nr2vBESVx0nnZc6un3/2EAWHv3ZW/Rya49hlEyIzqsee7g1916t\n\tIrKekG8+ELGQ6ul/zFTvoAK55Wd6s9Xik+kjIVshvddl45nF0nzGQea8pLUP9Kveqk0kcAiSce15m\n\tY/aDyVZFDMFnSYUjafLoTn7BBmiXLSAWUNV8PkAjTdpreN5hn/KIcqxE10EQs17xvRarWejUy2HPc\n\t6QIGIpUyKY5TZ/WhiPYQ==;","Subject":"Re: [RFC PATCH 6/6] iommu/arm-smmu-v3: Avoid ILLEGAL setting of\n\tSTE.S1STALLD and CD.S","To":"Yisheng Xie , Will Deacon ","References":"<1504167642-14922-1-git-send-email-xieyisheng1@huawei.com>\n\t<1504167642-14922-7-git-send-email-xieyisheng1@huawei.com>\n\t<738977bb-4cd7-7d86-0ea0-0c88b6af721c@arm.com>\n\t<20170913030643.GD12411@arm.com>\n\t<2f952821-afc3-46dd-17eb-40e8626bd6e5@huawei.com>","From":"Jean-Philippe Brucker ","Message-ID":"","Date":"Wed, 13 Sep 2017 16:47:27 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<2f952821-afc3-46dd-17eb-40e8626bd6e5@huawei.com>","Content-Language":"en-US","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170913_084724_686989_C8FE6503 ","X-CRM114-Status":"GOOD ( 14.62 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Mark Rutland ,\n\t\"devicetree@vger.kernel.org\" ,\n\tLorenzo Pieralisi ,\n\t\"lv.zheng@intel.com\" ,\n\t\"joro@8bytes.org\" , \n\t\"liubo95@huawei.com\" ,\n\t\"rjw@rjwysocki.net\" ,\n\t\"robert.moore@intel.com\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\t\"linux-acpi@vger.kernel.org\" ,\n\t\"iommu@lists.linux-foundation.org\" ,\n\t\"robh+dt@kernel.org\" ,\n\t\"hanjun.guo@linaro.org\" ,\n\tSudeep Holla ,\n\t\"chenjiankang1@huawei.com\" ,\n\t\"devel@acpica.org\" ,\n\tRobin Murphy , \n\t\"linux-arm-kernel@lists.infradead.org\"\n\t, \n\t\"lenb@kernel.org\" ","Content-Type":"text/plain; charset=\"windows-1252\"","Content-Transfer-Encoding":"quoted-printable","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1768038,"web_url":"http://patchwork.ozlabs.org/comment/1768038/","msgid":"<20170913171159.GB14955@arm.com>","list_archive_url":null,"date":"2017-09-13T17:11:59","subject":"Re: [RFC PATCH 6/6] iommu/arm-smmu-v3: Avoid ILLEGAL setting of\n\tSTE.S1STALLD and CD.S","submitter":{"id":7916,"url":"http://patchwork.ozlabs.org/api/people/7916/","name":"Will Deacon","email":"will.deacon@arm.com"},"content":"On Wed, Sep 13, 2017 at 06:11:13PM +0800, Yisheng Xie wrote:\n> On 2017/9/13 11:06, Will Deacon wrote:\n> > On Tue, Sep 05, 2017 at 01:54:19PM +0100, Jean-Philippe Brucker wrote:\n> >> On 31/08/17 09:20, Yisheng Xie wrote:\n> >>> It is ILLEGAL to set STE.S1STALLD if STALL_MODEL is not 0b00, which\n> >>> means we should not disable stall mode if stall/terminate mode is not\n> >>> configuable.\n> >>>\n> >>> Meanwhile, it is also ILLEGAL when STALL_MODEL==0b10 && CD.S==0 which\n> >>> means if stall mode is force we should always set CD.S.\n> >>>\n> >>> This patch add ARM_SMMU_FEAT_TERMINATE feature bit for smmu, and use\n> >>> TERMINATE feature checking to ensue above ILLEGAL cases from happening.\n> >>>\n> >>> Signed-off-by: Yisheng Xie \n> >>> ---\n> >>> drivers/iommu/arm-smmu-v3.c | 22 ++++++++++++++++------\n> >>> 1 file changed, 16 insertions(+), 6 deletions(-)\n> >>>\n> >>> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c\n> >>> index dbda2eb..0745522 100644\n> >>> --- a/drivers/iommu/arm-smmu-v3.c\n> >>> +++ b/drivers/iommu/arm-smmu-v3.c\n> >>> @@ -55,6 +55,7 @@\n> >>> #define IDR0_STALL_MODEL_SHIFT\t\t24\n> >>> #define IDR0_STALL_MODEL_MASK\t\t0x3\n> >>> #define IDR0_STALL_MODEL_STALL\t\t(0 << IDR0_STALL_MODEL_SHIFT)\n> >>> +#define IDR0_STALL_MODEL_NS\t\t(1 << IDR0_STALL_MODEL_SHIFT)\n> >>> #define IDR0_STALL_MODEL_FORCE\t\t(2 << IDR0_STALL_MODEL_SHIFT)\n> >>> #define IDR0_TTENDIAN_SHIFT\t\t21\n> >>> #define IDR0_TTENDIAN_MASK\t\t0x3\n> >>> @@ -766,6 +767,7 @@ struct arm_smmu_device {\n> >>> #define ARM_SMMU_FEAT_SVM\t\t(1 << 15)\n> >>> #define ARM_SMMU_FEAT_HA\t\t(1 << 16)\n> >>> #define ARM_SMMU_FEAT_HD\t\t(1 << 17)\n> >>> +#define ARM_SMMU_FEAT_TERMINATE\t\t(1 << 18)\n> >>\n> >> I'd rather introduce something like \"ARM_SMMU_FEAT_STALL_FORCE\" instead.\n> >> Terminate model has another meaning, and is defined by a different bit in\n> >> IDR0.\n> > \n> > Yes. What we need to do is:\n> > \n> > - If STALL_MODEL is 0b00, then set S1STALLD\n> \n> Yes, and within this case, we can only set the S1STALLD for masters which can\n> not stall in the future?\n\nYeah, something like that. I'd probably predicate it on having afault\nhandler registered too.\n\nWill","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"S7bKilUx\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xspBD4sqZz9sNV\n\tfor ;\n\tThu, 14 Sep 2017 03:12:18 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dsBCw-0001yp-E7; Wed, 13 Sep 2017 17:12:14 +0000","from foss.arm.com ([217.140.101.70])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dsBCs-0001w9-QT for linux-arm-kernel@lists.infradead.org;\n\tWed, 13 Sep 2017 17:12:12 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 17B131435;\n\tWed, 13 Sep 2017 10:11:50 -0700 (PDT)","from edgewater-inn.cambridge.arm.com\n\t(usa-sjc-imap-foss1.foss.arm.com [10.72.51.249])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id\n\tD90C13F483; Wed, 13 Sep 2017 10:11:49 -0700 (PDT)","by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000)\n\tid 871231AE0DCE; Wed, 13 Sep 2017 18:11:59 +0100 (BST)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:\n\tMessage-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=P4qvKa3nujToNh7qghDuQ0IJRUTh2XWi+t3DapOCNvk=;\n\tb=S7bKilUx4YLgI7\n\t5olkC4M9TbtE10iRpSRnxcag5RqX9rLB17D28WhUFKAuW0BCIJIePSO/hGT9oCT3igzpERoR/UaE+\n\tBKIJg6pJ5PmoOakO46HUM7OoYQf9iAcSTt5/5nbIfj5ey4GXNgiW6Hv2wC7R+MBbqDrA7GoOHl6nE\n\tYy3h38QtHHQUf4vcirq8WxP2FpH0B+uG3EcprEJEhURelh2WmszwSlLTmH5Sgd08iVmr9BPZsA5No\n\tDwOcU6KqLaCZAxr2yYCaCYUCAVJnXJ5IWurq0LehelOEFsteD3UW+m39LIPS7LxPakIUkKELtHTvc\n\tfsM0rQe48kiTiZvhWB+g==;","Date":"Wed, 13 Sep 2017 18:11:59 +0100","From":"Will Deacon ","To":"Yisheng Xie ","Subject":"Re: [RFC PATCH 6/6] iommu/arm-smmu-v3: Avoid ILLEGAL setting of\n\tSTE.S1STALLD and CD.S","Message-ID":"<20170913171159.GB14955@arm.com>","References":"<1504167642-14922-1-git-send-email-xieyisheng1@huawei.com>\n\t<1504167642-14922-7-git-send-email-xieyisheng1@huawei.com>\n\t<738977bb-4cd7-7d86-0ea0-0c88b6af721c@arm.com>\n\t<20170913030643.GD12411@arm.com>\n\t<2f952821-afc3-46dd-17eb-40e8626bd6e5@huawei.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<2f952821-afc3-46dd-17eb-40e8626bd6e5@huawei.com>","User-Agent":"Mutt/1.5.23 (2014-03-12)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170913_101210_876710_BBD8B37C ","X-CRM114-Status":"GOOD ( 16.80 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, devicetree@vger.kernel.org,\n\tlorenzo.pieralisi@arm.com, lv.zheng@intel.com,\n\tJean-Philippe Brucker , \n\tjoro@8bytes.org, liubo95@huawei.com, rjw@rjwysocki.net,\n\trobert.moore@intel.com, \n\tlinux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,\n\tiommu@lists.linux-foundation.org, robh+dt@kernel.org,\n\thanjun.guo@linaro.org, \n\tsudeep.holla@arm.com, chenjiankang1@huawei.com, devel@acpica.org,\n\trobin.murphy@arm.com, linux-arm-kernel@lists.infradead.org,\n\tlenb@kernel.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}}]