From: Will Deacon <will@kernel.org>
To: Benjamin Gaignard <benjamin.gaignard@collabora.com>
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
Subject: Re: [PATCH v11 3/7] iommu: Add verisilicon IOMMU driver
Date: Fri, 23 Jan 2026 17:14:30 +0000 [thread overview]
Message-ID: <aXOsdlGMVzhHOrUr@willie-the-truck> (raw)
In-Reply-To: <4b33b50f-f0c3-4db8-b394-dd2d4d6e3a55@collabora.com>
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
All IOMMUs tend to work like that and I don't think this one is any
different.
Will
next prev parent reply other threads:[~2026-01-23 17:14 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-07 10:09 [PATCH v11 0/7] Add support for Verisilicon IOMMU used by media Benjamin Gaignard
2026-01-07 10:09 ` [PATCH v11 1/7] dt-bindings: vendor-prefixes: Add Verisilicon Benjamin Gaignard
2026-01-07 10:09 ` [PATCH v11 2/7] dt-bindings: iommu: verisilicon: Add binding for VSI IOMMU Benjamin Gaignard
2026-01-07 10:09 ` [PATCH v11 3/7] iommu: Add verisilicon IOMMU driver Benjamin Gaignard
2026-01-13 16:10 ` Will Deacon
2026-01-13 16:25 ` Benjamin Gaignard
2026-01-14 12:59 ` Will Deacon
2026-01-14 13:10 ` Benjamin Gaignard
2026-01-19 12:32 ` Will Deacon
2026-01-19 14:03 ` Benjamin Gaignard
2026-01-21 12:51 ` Will Deacon
2026-01-21 13:50 ` Benjamin Gaignard
2026-01-23 17:14 ` Will Deacon [this message]
2026-01-26 9:03 ` Benjamin Gaignard
2026-01-26 14:19 ` Will Deacon
2026-01-26 14:46 ` Benjamin Gaignard
2026-02-16 10:03 ` Benjamin Gaignard
2026-01-18 9:41 ` Jörg Rödel
2026-01-19 7:51 ` Benjamin Gaignard
2026-01-19 8:56 ` Jörg Rödel
2026-01-19 10:28 ` Benjamin Gaignard
2026-01-19 14:06 ` Jörg Rödel
2026-01-07 10:09 ` [PATCH v11 4/7] MAINTAINERS: Add entry for Verisilicon " Benjamin Gaignard
2026-01-07 10:09 ` [PATCH v11 5/7] media: verisilicon: AV1: Restore IOMMU context before decoding a frame Benjamin Gaignard
2026-01-07 10:09 ` [PATCH v11 6/7] arm64: dts: rockchip: Add verisilicon IOMMU node on RK3588 Benjamin Gaignard
2026-01-07 10:09 ` [PATCH v11 7/7] arm64: defconfig: enable Verisilicon IOMMU for Rockchip RK3588 Benjamin Gaignard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aXOsdlGMVzhHOrUr@willie-the-truck \
--to=will@kernel.org \
--cc=benjamin.gaignard@collabora.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=kernel@collabora.com \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mchehab@kernel.org \
--cc=nicolas.dufresne@collabora.com \
--cc=p.zabel@pengutronix.de \
--cc=robh@kernel.org \
--cc=robin.murphy@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox