From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C9933C88E78 for ; Mon, 26 Jan 2026 09:03:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Szw4w1kPWz+z204rfjqE2SzFPSa+7l4i9w+mPzkshVs=; b=wJrnzNMRsk23HolmJgAoxe5DxA bcl0rzjTP65b2yRJSSeSUbsu4ZNtrmaAeXbcf7M+WbkH45Qjy4gBfL5jnwHB7B62yxbuG51rgAo9L hc59rBClhFnASsfbORP/PLHLK5G/kMqWXUUZ70ZPdHBciG7BbUJRdKMBjIc6zWDPFJxhuthg7Fhx6 mutQmwaqFXz4lezSx2H1EpdOc5mhVzNMh1WIXztgMqQxCfpTw5q3fOZ0SVSQZB7uA8l1GR2170hGK mOBARRgUKGS8NRWgm+jvrg7kuS4vAaiKsUIezbwzBmufbImaNcYHKzIZwGu/rTKTaO47c5D+Ee1vu UJ+Rzh0A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vkIVf-0000000C9LU-1cDO; Mon, 26 Jan 2026 09:03:47 +0000 Received: from sender4-pp-f112.zoho.com ([136.143.188.112]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vkIVc-0000000C9L0-2IG9; Mon, 26 Jan 2026 09:03:45 +0000 ARC-Seal: i=1; a=rsa-sha256; t=1769418206; cv=none; d=zohomail.com; s=zohoarc; b=Lfh/eRNm7h3SKUFm2ewA6a/EsO2tqg1/xGQ+4lMYt1NSSKBmFa5Yo7Y0T98Fohkna4IETqDWDFUGU6JlBuzIGWRBeTuXqaUcejl+G06NT+cw+t6j2WcgdhtNfuMC+98o5/k6OJ7PGTbF6LPRaZurovzQTNKEilwh54OxdWzw4rY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1769418206; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=Szw4w1kPWz+z204rfjqE2SzFPSa+7l4i9w+mPzkshVs=; b=HS+DgwvModzf5uvt0IgC5Gzq2xsRBnKY56Vb9GkgQOvXigBYCvEjIyhhohOsVUeRg54tcKh2LemWXFt7OTcO7nM9qefvhFi2zh4+ucq4VEIfz4jS3e8SN/S8SaAKA763hppE4FRhgnPH47hdlrV1+Mr3ddwj6n/1mnbOzn7IPB4= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=collabora.com; spf=pass smtp.mailfrom=benjamin.gaignard@collabora.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1769418206; s=zohomail; d=collabora.com; i=benjamin.gaignard@collabora.com; h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=Szw4w1kPWz+z204rfjqE2SzFPSa+7l4i9w+mPzkshVs=; b=k+ETJadj+tQfi4J6Ht/P5SsTGGRtFvu9K2hXalxlFZNnQJSLk9grhNLWdip5NIwC S1UYSrbLFgKI/53E7laWLIsCv2TSNC8htoWjQHbF8dFzxz0r5xvbbY55GSGQlEzHUw8 OyROJfVgetbJCMyPXxdlEpb+3AO+h+1jPwiALJGc= Received: by mx.zohomail.com with SMTPS id 1769418204273347.0095929584735; Mon, 26 Jan 2026 01:03:24 -0800 (PST) Message-ID: <8fd2c508-cbe9-4050-ba02-85b22fcff10d@collabora.com> Date: Mon, 26 Jan 2026 10:03:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v11 3/7] iommu: Add verisilicon IOMMU driver To: Will Deacon Cc: joro@8bytes.org, robin.murphy@arm.com, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, heiko@sntech.de, nicolas.dufresne@collabora.com, p.zabel@pengutronix.de, mchehab@kernel.org, iommu@lists.linux.dev, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-media@vger.kernel.org, kernel@collabora.com References: <20260107101005.84039-1-benjamin.gaignard@collabora.com> <20260107101005.84039-4-benjamin.gaignard@collabora.com> <68a49f8b-178c-4fa2-b4a9-315ad602271d@collabora.com> <4b33b50f-f0c3-4db8-b394-dd2d4d6e3a55@collabora.com> Content-Language: en-US From: Benjamin Gaignard In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260126_010344_628242_04758DAB X-CRM114-Status: GOOD ( 25.01 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Le 23/01/2026 à 18:14, Will Deacon a écrit : > On Wed, Jan 21, 2026 at 02:50:18PM +0100, Benjamin Gaignard wrote: >> Le 21/01/2026 à 13:51, Will Deacon a écrit : >>> On Mon, Jan 19, 2026 at 03:03:44PM +0100, Benjamin Gaignard wrote: >>>>>>>>>> +static const struct iommu_ops vsi_iommu_ops = { >>>>>>>>>> + .identity_domain = &vsi_identity_domain, >>>>>>>>>> + .release_domain = &vsi_identity_domain, >>>>>>>>>> + .domain_alloc_paging = vsi_iommu_domain_alloc_paging, >>>>>>>>>> + .of_xlate = vsi_iommu_of_xlate, >>>>>>>>>> + .probe_device = vsi_iommu_probe_device, >>>>>>>>>> + .release_device = vsi_iommu_release_device, >>>>>>>>>> + .device_group = generic_single_device_group, >>>>>>>>>> + .owner = THIS_MODULE, >>>>>>>>>> + .default_domain_ops = &(const struct iommu_domain_ops) { >>>>>>>>>> + .attach_dev = vsi_iommu_attach_device, >>>>>>>>>> + .map_pages = vsi_iommu_map, >>>>>>>>>> + .unmap_pages = vsi_iommu_unmap, >>>>>>>>>> + .flush_iotlb_all = vsi_iommu_flush_tlb_all, >>>>>>>>> This has no callers and so your unmap routine appears to be broken. >>>>>>>> It is a leftover of previous attempt to allow video decoder to clean/flush >>>>>>>> the iommu by using a function from the API. >>>>>>>> Now it is using vsi_iommu_restore_ctx(). >>>>>>>> I while remove it in version 12. >>>>>>> Don't you still need some invalidation on the unmap path? >>>>>> In vsi_iommu_unmap_iova() page is invalided by calling vsi_mk_pte_invalid(). >>>>> But that just writes an invalid descriptor and doesn't appear to invalidate >>>>> the TLB at all. >>>>> >>>>>> That clear BIT(0) so the hardware knows the page is invalid. >>>>>> Do I have miss something here ? >>>>> Yes, the TLB structure needs to be invalidated so that the page-table >>>>> walker sees the new value that you have written in memory. >>>>> >>>>> The rockchip driver gets this correct... >>>> Rockchip hardware have a ZAP_ONE_LINE register which didn't exist on Verisilicon >>>> hardware. >>> Presumably you have some sort of Verisilicon datasheet or downstream driver >>> from which you can infer the TLB invalidation runes? >> I have only this downstream driver: >> https://github.com/rockchip-linux/kernel/blob/develop-6.1/drivers/iommu/rockchip-iommu-av1d.c >> No datasheet... >> >>>> I have tried to use VSI_MMU_BIT_FLUSH on VSI driver after unmapping iova >>>> but it doesn't work. >>> What do you mean by "doesn't work"? If it works without doing any >>> invalidation at all, then it's very peculiar that adding the invalidation >>> would introduce issues. >> I mean VSI_MMU_BIT_FLUSH register can't be used to invalid the TLB. >> I think the hardware iterates over the pages tables in memory and >> check the valid/invalid bit. > I bet it doesn't: that would be horrible for performance. > > The hardware clearly has TLB invalidation support, as the downstream driver > that you linked above implements av1_iommu_flush_tlb_all() to poke it. > If the hardware has a TLB, then unmapping a page-table means you need to: > > 1. Clear the valid bit from the descriptor in memory > 2. Have some sort of memory barrier > 3. Invalidate the TLB > 4. Wait for the invalidation to complete That exactly what I had tried to do by calling vsi_iommu_flush_tlb_all() (minux the lock) after calling vsi_iommu_unmap_iova() in vsi_iommu_unmap() but that doesn't work and even make the system crash sometimes. Benjamin > > All IOMMUs tend to work like that and I don't think this one is any > different. > > Will >