public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Catalin Marinas <catalin.marinas@arm.com>,
	Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>,
	Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>,
	Will Deacon <will.deacon@arm.com>,
	linux-kernel@vger.kernel.org,
	Zhang Lei <zhang.lei@jp.fujitsu.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] arm64/mm: check cpu cache line size with non-coherent device
Date: Thu, 13 Jun 2019 18:10:17 +0100	[thread overview]
Message-ID: <d832009b-93b5-8ac3-03eb-8e6e92a5b206@arm.com> (raw)
In-Reply-To: <20190613155434.GW28951@C02TF0J2HF1T.local>

On 13/06/2019 16:54, Catalin Marinas wrote:
> On Tue, Jun 11, 2019 at 06:02:47PM -0400, Masayoshi Mizuma wrote:
>> On Tue, Jun 11, 2019 at 07:00:07PM +0100, Catalin Marinas wrote:
>>> On Tue, Jun 11, 2019 at 11:17:30AM -0400, Masayoshi Mizuma wrote:
>>>> --- a/arch/arm64/mm/dma-mapping.c
>>>> +++ b/arch/arm64/mm/dma-mapping.c
>>>> @@ -91,10 +91,6 @@ static int __swiotlb_mmap_pfn(struct vm_area_struct *vma,
>>>>   
>>>>   static int __init arm64_dma_init(void)
>>>>   {
>>>> -	WARN_TAINT(ARCH_DMA_MINALIGN < cache_line_size(),
>>>> -		   TAINT_CPU_OUT_OF_SPEC,
>>>> -		   "ARCH_DMA_MINALIGN smaller than CTR_EL0.CWG (%d < %d)",
>>>> -		   ARCH_DMA_MINALIGN, cache_line_size());
>>>>   	return dma_atomic_pool_init(GFP_DMA32, __pgprot(PROT_NORMAL_NC));
>>>>   }
>>>>   arch_initcall(arm64_dma_init);
>>>> @@ -473,6 +469,11 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
>>>>   			const struct iommu_ops *iommu, bool coherent)
>>>>   {
>>>>   	dev->dma_coherent = coherent;
>>>> +
>>>> +	if (!coherent && (cache_line_size() > ARCH_DMA_MINALIGN))
>>>> +		dev_WARN(dev, "ARCH_DMA_MINALIGN smaller than CTR_EL0.CWG (%d < %d)",
>>>> +				ARCH_DMA_MINALIGN, cache_line_size());
>>>
>>> I'm ok in principle with this patch, with the minor issue that since
>>> commit 7b8c87b297a7 ("arm64: cacheinfo: Update cache_line_size detected
>>> from DT or PPTT") queued for 5.3 cache_line_size() gets the information
>>> from DT or ACPI. The reason for this change is that the information is
>>> used for performance tuning rather than DMA coherency.
>>>
>>> You can go for a direct cache_type_cwg() check in here, unless Robin
>>> (cc'ed) has a better idea.
>>
>> Got it, thanks.
>> I believe coherency_max_size is zero in case of coherent is false,
>> so I'll modify the patch as following. Does it make sense?
> 
> The coherency_max_size gives you the largest cache line in the system,
> independent of whether a device is coherent or not. You may have a
> device that does not snoop L1/L2 but there is a transparent L3 (system
> cache) with a larger cache line that the device may be able to snoop.
> The coherency_max_size and therefore cache_line_size() would give you
> this L3 value but the device would work fine since CWG <=
> ARCH_DMA_MINALIGN.
> 
>>
>> @@ -57,6 +53,11 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
>>                          const struct iommu_ops *iommu, bool coherent)
>>   {
>>          dev->dma_coherent = coherent;
>> +
>> +       if (!coherent && (cache_line_size() > ARCH_DMA_MINALIGN))
>> +               dev_WARN(dev, "ARCH_DMA_MINALIGN smaller than CTR_EL0.CWG (%d < %d)",
>> +                               ARCH_DMA_MINALIGN, (4 << cache_type_cwg()));
>> +
>>          if (iommu)
>>                  iommu_setup_dma_ops(dev, dma_base, size);
> 
> I think the easiest here is to add a local variable:
> 
> 	int cls = 4 << cache_type_cwg();
> 
> and check it against ARCH_DMA_MINALIGN.
> 

Agreed, and I'd say we should keep the taint too, since if this 
situation ever was hit the potential crashes would be weird and random 
and not obviously DMA-related.

Robin.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-06-13 17:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-11 15:17 [PATCH 0/2] Correct the cache line size warning Masayoshi Mizuma
2019-06-11 15:17 ` [PATCH 1/2] arm64/mm: check cpu cache line size with non-coherent device Masayoshi Mizuma
2019-06-11 18:00   ` Catalin Marinas
2019-06-11 22:02     ` Masayoshi Mizuma
2019-06-13 15:54       ` Catalin Marinas
2019-06-13 17:10         ` Robin Murphy [this message]
2019-06-11 15:17 ` [PATCH 2/2] arm64/mm: show TAINT_CPU_OUT_OF_SPEC warning if the cache size is over the spec Masayoshi Mizuma
2019-06-11 15:41   ` Catalin Marinas
2019-06-11 16:18     ` Masayoshi Mizuma

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=d832009b-93b5-8ac3-03eb-8e6e92a5b206@arm.com \
    --to=robin.murphy@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.mizuma@jp.fujitsu.com \
    --cc=msys.mizuma@gmail.com \
    --cc=seto.hidetoshi@jp.fujitsu.com \
    --cc=will.deacon@arm.com \
    --cc=zhang.lei@jp.fujitsu.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