All of lore.kernel.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: Will Deacon <will.deacon@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>,
	linux-kernel@vger.kernel.org,
	Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>,
	Zhang Lei <zhang.lei@jp.fujitsu.com>
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.

WARNING: multiple messages have this Message-ID (diff)
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: 18+ 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 ` 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 15:17   ` Masayoshi Mizuma
2019-06-11 18:00   ` Catalin Marinas
2019-06-11 18:00     ` Catalin Marinas
2019-06-11 22:02     ` Masayoshi Mizuma
2019-06-11 22:02       ` Masayoshi Mizuma
2019-06-13 15:54       ` Catalin Marinas
2019-06-13 15:54         ` Catalin Marinas
2019-06-13 17:10         ` Robin Murphy [this message]
2019-06-13 17:10           ` Robin Murphy
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:17   ` Masayoshi Mizuma
2019-06-11 15:41   ` Catalin Marinas
2019-06-11 15:41     ` Catalin Marinas
2019-06-11 16:18     ` Masayoshi Mizuma
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.