From: Robin Murphy <robin.murphy@arm.com>
To: Chunyan Zhang <zhang.lyra@gmail.com>
Cc: DTML <devicetree@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Chunyan Zhang <chunyan.zhang@unisoc.com>,
Sheng Xu <sheng.xu@unisoc.com>,
iommu@lists.linux-foundation.org,
Rob Herring <robh+dt@kernel.org>,
Kevin Tang <kevin.tang@unisoc.com>,
Baolin Wang <baolin.wang7@gmail.com>,
Orson Zhai <orsonzhai@gmail.com>
Subject: Re: [RFC PATCH V2 2/2] iommu: add Unisoc iommu basic driver
Date: Wed, 20 Jan 2021 12:29:44 +0000 [thread overview]
Message-ID: <3a2561fc-65a6-4c68-fdb7-a5b670706f43@arm.com> (raw)
In-Reply-To: <CAAfSe-vd5eRopOBZMuTi8vq1FqY1qAVSdMHscVuA+uHtL2H=gw@mail.gmail.com>
On 2021-01-20 11:40, Chunyan Zhang wrote:
[...]
>>> + pgt_base_iova = dom->pgt_va +
>>> + ((iova - mdata->iova_start) >> SPRD_IOMMU_PAGE_SHIFT);
>>> +
>>> + spin_lock_irqsave(&dom->pgtlock, flags);
>>> + for (i = 0; i < page_num; i++) {
>>> + pgt_base_iova[i] = pabase >> SPRD_IOMMU_PAGE_SHIFT;
>>
>> Out of curiosity, is the pagetable walker cache-coherent, or is this
>> currently managing to work by pure chance and natural cache churn?
>
> ->iotlb_sync_map() was implemented in this driver, I guess that has
> done what you say here?
No, sync_map only ensures that the previous (invalid) PTE isn't held in
the IOMMU's TLB. If pgt_va is a regular page allocation then you're
writing the new PTE to normal kernel memory, with nothing to guarantee
that write goes any further than the CPU's L1 cache. Thus either the
IOMMU has capable of snooping the CPU caches in order to see the updated
PTE value (rather than refetching the stale value from DRAM), or you're
just incredibly lucky that by the time the IOMMU *does* go to fetch the
PTE for that address, that updated cache line has already been evicted
out to DRAM naturally.
This is not an issue if you use the proper DMA allocator, since that
will ensure you get a non-cacheable buffer if you need one.
Robin.
next prev parent reply other threads:[~2021-01-20 13:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-08 11:38 [RFC PATCH V2 0/2] Add " Chunyan Zhang
2021-01-08 11:38 ` [RFC PATCH V2 1/2] dt-bindings: iommu: add bindings for sprd iommu Chunyan Zhang
2021-01-08 11:38 ` [RFC PATCH V2 2/2] iommu: add Unisoc iommu basic driver Chunyan Zhang
2021-01-12 19:10 ` Robin Murphy
2021-01-20 11:40 ` Chunyan Zhang
2021-01-20 12:29 ` Robin Murphy [this message]
2021-01-21 7:42 ` Chunyan Zhang
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=3a2561fc-65a6-4c68-fdb7-a5b670706f43@arm.com \
--to=robin.murphy@arm.com \
--cc=baolin.wang7@gmail.com \
--cc=chunyan.zhang@unisoc.com \
--cc=devicetree@vger.kernel.org \
--cc=iommu@lists.linux-foundation.org \
--cc=kevin.tang@unisoc.com \
--cc=linux-kernel@vger.kernel.org \
--cc=orsonzhai@gmail.com \
--cc=robh+dt@kernel.org \
--cc=sheng.xu@unisoc.com \
--cc=zhang.lyra@gmail.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
all inboxes | Powered by JetHome®