> From: Jason Gunthorpe <jgg@xxxxxxxxxx>
> Sent: Thursday, September 23, 2021 7:27 PM
>
> On Thu, Sep 23, 2021 at 11:15:24AM +0100, Jean-Philippe Brucker wrote:
>
> > So we can only tell userspace "No_snoop is not supported" (provided we
> > even want to allow them to enable No_snoop). Users in control of stage-1
> > tables can create non-cacheable mappings through MAIR attributes.
>
> My point is that ARM is using IOMMU_CACHE to control the overall
> cachability of the DMA
>
> ie not specifying IOMMU_CACHE requires using the arch specific DMA
> cache flushers.
>
> Intel never uses arch specifc DMA cache flushers, and instead is
> abusing IOMMU_CACHE to mean IOMMU_BLOCK_NO_SNOOP on DMA that
> is always
> cachable.
it uses IOMMU_CACHE to force all DMAs to snoop, including those which
has non_snoop flag and wouldn't snoop cache if iommu is disabled. Nothing
is blocked.
but why do you call it abuse? IOMMU_CACHE was first introduced for
Intel platform:
commit 9cf0669746be19a4906a6c48920060bcf54c708b
Author: Sheng Yang <sheng@xxxxxxxxxxxxxxx>
Date: Wed Mar 18 15:33:07 2009 +0800
intel-iommu: VT-d page table to support snooping control bit
The user can request to enable snooping control through VT-d page table.
Signed-off-by: Sheng Yang <sheng@xxxxxxxxxxxxxxx>
Signed-off-by: David Woodhouse <David.Woodhouse@xxxxxxxxx>
>
> These are different things and need different bits. Since the ARM path
> has a lot more code supporting it, I'd suggest Intel should change
> their code to use IOMMU_BLOCK_NO_SNOOP and abandon IOMMU_CACHE.
I didn't fully get this point. The end result is same, i.e. making the DMA
cache-coherent when IOMMU_CACHE is set. Or if you help define the
behavior of IOMMU_CACHE, what will you define now?
>
> Which clarifies what to do here as uAPI - these things need to have
> different bits and Intel's should still have NO SNOOP in the
> name. What the no-snoop bit is called on other busses can be clarified
> in comments if that case ever arises.
>
> Jason
