From: Jason Gunthorpe <jgg@ziepe.ca>
To: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Cc: joro@8bytes.org, will@kernel.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 3/5] iommu: Add verisilicon IOMMU driver
Date: Wed, 18 Jun 2025 10:27:59 -0300 [thread overview]
Message-ID: <20250618132759.GO1376515@ziepe.ca> (raw)
In-Reply-To: <ff32d7c1-d811-46b8-8d3d-458dfebd14f8@collabora.com>
On Wed, Jun 18, 2025 at 02:04:19PM +0200, Benjamin Gaignard wrote:
>
> Le 17/06/2025 à 18:32, Jason Gunthorpe a écrit :
> > > + vsi_domain->dt_dma = dma_map_single(dma_dev, vsi_domain->dt,
> > > + SPAGE_SIZE, DMA_TO_DEVICE);
> > > + if (dma_mapping_error(dma_dev, vsi_domain->dt_dma)) {
> > > + dev_err(dma_dev, "DMA map error for DT\n");
> > > + goto err_free_dt;
> > > + }
> > > +
> > > + vsi_domain->pta = iommu_alloc_pages_sz(GFP_KERNEL | GFP_DMA32,
> > > + SPAGE_SIZE);
> > > + if (!vsi_domain->pta)
> > > + goto err_unmap_dt;
> > > +
> > > + vsi_domain->pta_dma = dma_map_single(dma_dev, vsi_domain->pta,
> > > + SPAGE_SIZE, DMA_TO_DEVICE);
> > > + if (dma_mapping_error(dma_dev, vsi_domain->pta_dma)) {
> > > + dev_err(dma_dev, "DMA map error for PTA\n");
> > > + goto err_free_pta;
> > > + }
> > > + vsi_domain->pta[0] = vsi_mk_pta(vsi_domain->dt_dma);
> > > +
> > > + vsi_table_flush(vsi_domain, vsi_domain->pta_dma, 1024);
> > > + vsi_table_flush(vsi_domain, vsi_domain->dt_dma, NUM_DT_ENTRIES);
> > dma_map_single already flushes, put things in the write order and no
> > need to double flush.
>
> I don't get your point here, for me it flush two different pieces of memory.
dma_map_single() already flushes the cache, you don't need to do it
again.
Do your memory writes then call dma_map_signle().
> > > + dte_index = vsi_iova_dte_index(iova);
> > > + dte_addr = &vsi_domain->dt[dte_index];
> > > + dte = *dte_addr;
> > > + if (vsi_dte_is_pt_valid(dte))
> > > + goto done;
> > > +
> > > + page_table = (u32 *)get_zeroed_page(GFP_ATOMIC | GFP_DMA32);
> > > + if (!page_table)
> > > + return ERR_PTR(-ENOMEM);
> > Don't use get_zeroed_page for page table memory.
>
> I will use kmem_cache in v2
I mean you are supposed to iommu-pages.h for page table memory.
> > > + pt_dma = dma_map_single(dma_dev, page_table, SPAGE_SIZE, DMA_TO_DEVICE);
> > > + if (dma_mapping_error(dma_dev, pt_dma)) {
> > > + dev_err(dma_dev, "DMA mapping error while allocating page table\n");
> > > + free_page((unsigned long)page_table);
> > > + return ERR_PTR(-ENOMEM);
> > > + }
> > > +
> > > + dte = vsi_mk_dte(pt_dma);
> > > + *dte_addr = dte;
> > > +
> > > + vsi_table_flush(vsi_domain, pt_dma, NUM_PT_ENTRIES);
> > > + vsi_table_flush(vsi_domain,
> > > + vsi_domain->dt_dma + dte_index * sizeof(u32), 1);
> > Double flushing again.
>
> Same here, for me I flushing two different memory area.
write to the page-table, then call dma_map_single(), don't flush it again.
> > > +static int vsi_iommu_map_iova(struct vsi_iommu_domain *vsi_domain, u32 *pte_addr,
> > > + dma_addr_t pte_dma, dma_addr_t iova,
> > > + phys_addr_t paddr, size_t size, int prot)
> > > +{
> > > + unsigned int pte_count;
> > > + unsigned int pte_total = size / SPAGE_SIZE;
> > > + phys_addr_t page_phys;
> > > +
> > > + assert_spin_locked(&vsi_domain->dt_lock);
> > > +
> > > + for (pte_count = 0; pte_count < pte_total; pte_count++) {
> > > + u32 pte = pte_addr[pte_count];
> > > +
> > > + if (vsi_pte_is_page_valid(pte))
> > > + goto unwind;
> > > +
> > > + pte_addr[pte_count] = vsi_mk_pte(paddr, prot);
> > So why is this:
> >
> > #define VSI_IOMMU_PGSIZE_BITMAP 0x007ff000
> >
> > If the sizes don't become encoded in the PTE? The bits beyond 4k
> > should reflect actual ability to store those sizes in PTEs, eg using
> > contiguous bits or something.
>
> The iommu use arrays to store up to 1024 4k pages indexes so the size
> isn't coded in the PTE bits but the numbers of used indexes for each arrays.
That isn't how it works, if the PTE bits don't code the size then you
don't set the VSI_IOMMU_PGSIZE_BITMAP. You just want SZ_4K for the way
this driver is written.
Jason
next prev parent reply other threads:[~2025-06-18 13:28 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-16 14:55 [PATCH 0/5] Add support for Verisilicon IOMMU used by media codec blocks Benjamin Gaignard
2025-06-16 14:55 ` [PATCH 1/5] dt-bindings: vendor-prefixes: Add Verisilicon Benjamin Gaignard
2025-06-16 15:15 ` Conor Dooley
2025-06-16 14:55 ` [PATCH 2/5] dt-bindings: iommu: verisilicon: Add binding for VSI IOMMU Benjamin Gaignard
2025-06-16 15:14 ` Conor Dooley
2025-06-16 15:30 ` Benjamin Gaignard
2025-06-16 15:42 ` Conor Dooley
2025-06-16 15:50 ` Benjamin Gaignard
2025-06-16 15:58 ` Conor Dooley
2025-06-16 16:06 ` Benjamin Gaignard
2025-06-16 21:19 ` Nicolas Dufresne
2025-06-16 14:55 ` [PATCH 3/5] iommu: Add verisilicon IOMMU driver Benjamin Gaignard
2025-06-17 13:04 ` Diederik de Haas
2025-06-17 13:48 ` Benjamin Gaignard
2025-06-17 16:32 ` Jason Gunthorpe
2025-06-18 12:04 ` Benjamin Gaignard
2025-06-18 13:27 ` Jason Gunthorpe [this message]
2025-06-18 4:53 ` kernel test robot
2025-06-16 14:55 ` [PATCH 4/5] arm64: dts: rockchip: Add verisilicon IOMMU node on RK3588 Benjamin Gaignard
2025-06-16 14:55 ` [PATCH 5/5] media: verisilicon: Flush IOMMU before decoding a frame Benjamin Gaignard
2025-06-17 15:58 ` Jason Gunthorpe
2025-06-17 16:01 ` Benjamin Gaignard
2025-06-17 16:04 ` Robin Murphy
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=20250618132759.GO1376515@ziepe.ca \
--to=jgg@ziepe.ca \
--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 \
--cc=will@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).