[PATCH v13 06/19] iommu/exynos: add missing cache flush for removed page table entries
From: Cho KyongHo This commit adds cache flush for removed small and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. Reviewed-by: Tomasz Figa Tested-by: Grant Grundler Signed-off-by: Cho KyongHo Signed-off-by: Shaik Ameer Basha --- drivers/iommu/exynos-iommu.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c index 4fc31fc..6915235 100644 --- a/drivers/iommu/exynos-iommu.c +++ b/drivers/iommu/exynos-iommu.c @@ -904,6 +904,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, if (lv2ent_small(ent)) { *ent = 0; size = SPAGE_SIZE; + pgtable_flush(ent, ent + 1); priv->lv2entcnt[lv1ent_offset(iova)] += 1; goto done; } @@ -915,6 +916,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, } memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); size = LPAGE_SIZE; priv->lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v13 06/19] iommu/exynos: add missing cache flush for removed page table entries
From: Cho KyongHo pullip@samsung.com This commit adds cache flush for removed small and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. Reviewed-by: Tomasz Figa t.f...@samsung.com Tested-by: Grant Grundler grund...@chromium.org Signed-off-by: Cho KyongHo pullip@samsung.com Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com --- drivers/iommu/exynos-iommu.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c index 4fc31fc..6915235 100644 --- a/drivers/iommu/exynos-iommu.c +++ b/drivers/iommu/exynos-iommu.c @@ -904,6 +904,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, if (lv2ent_small(ent)) { *ent = 0; size = SPAGE_SIZE; + pgtable_flush(ent, ent + 1); priv-lv2entcnt[lv1ent_offset(iova)] += 1; goto done; } @@ -915,6 +916,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, } memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); size = LPAGE_SIZE; priv-lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v12 02/31] iommu/exynos: add missing cache flush for removed page table entries
From: Cho KyongHo This commit adds cache flush for removed small and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. Reviewed-by: Tomasz Figa Tested-by: Grant Grundler Signed-off-by: Cho KyongHo --- drivers/iommu/exynos-iommu.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c index 46f0ca1..34e4273 100644 --- a/drivers/iommu/exynos-iommu.c +++ b/drivers/iommu/exynos-iommu.c @@ -957,6 +957,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, if (lv2ent_small(ent)) { *ent = 0; size = SPAGE_SIZE; + pgtable_flush(ent, ent + 1); priv->lv2entcnt[lv1ent_offset(iova)] += 1; goto done; } @@ -965,6 +966,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, BUG_ON(size < LPAGE_SIZE); memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); size = LPAGE_SIZE; priv->lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v12 02/31] iommu/exynos: add missing cache flush for removed page table entries
From: Cho KyongHo pullip@samsung.com This commit adds cache flush for removed small and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. Reviewed-by: Tomasz Figa t.f...@samsung.com Tested-by: Grant Grundler grund...@chromium.org Signed-off-by: Cho KyongHo pullip@samsung.com --- drivers/iommu/exynos-iommu.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c index 46f0ca1..34e4273 100644 --- a/drivers/iommu/exynos-iommu.c +++ b/drivers/iommu/exynos-iommu.c @@ -957,6 +957,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, if (lv2ent_small(ent)) { *ent = 0; size = SPAGE_SIZE; + pgtable_flush(ent, ent + 1); priv-lv2entcnt[lv1ent_offset(iova)] += 1; goto done; } @@ -965,6 +966,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, BUG_ON(size LPAGE_SIZE); memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); size = LPAGE_SIZE; priv-lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v11 02/27] iommu/exynos: add missing cache flush for removed page table entries
Please apply this. It's way overdue. It fixes customer kernel crashes we've seen in the field. I'd also advocate for seeing this be applied to stable kernels. thanks, grant On Thu, Mar 13, 2014 at 10:02 PM, Cho KyongHo wrote: > This commit adds cache flush for removed small and large page entries > in exynos_iommu_unmap(). Missing cache flush of removed page table > entries can cause missing page fault interrupt when a master IP > accesses an unmapped area. > > Reviewed-by: Tomasz Figa > Tested-by: Grant Grundler > Signed-off-by: Cho KyongHo > --- > drivers/iommu/exynos-iommu.c |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c > index 4876d35..1c3a397 100644 > --- a/drivers/iommu/exynos-iommu.c > +++ b/drivers/iommu/exynos-iommu.c > @@ -958,6 +958,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain > *domain, > if (lv2ent_small(ent)) { > *ent = 0; > size = SPAGE_SIZE; > + pgtable_flush(ent, ent + 1); > priv->lv2entcnt[lv1ent_offset(iova)] += 1; > goto done; > } > @@ -966,6 +967,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain > *domain, > BUG_ON(size < LPAGE_SIZE); > > memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); > + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); > > size = LPAGE_SIZE; > priv->lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; > -- > 1.7.9.5 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v11 02/27] iommu/exynos: add missing cache flush for removed page table entries
Please apply this. It's way overdue. It fixes customer kernel crashes we've seen in the field. I'd also advocate for seeing this be applied to stable kernels. thanks, grant On Thu, Mar 13, 2014 at 10:02 PM, Cho KyongHo pullip@samsung.com wrote: This commit adds cache flush for removed small and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. Reviewed-by: Tomasz Figa t.f...@samsung.com Tested-by: Grant Grundler grund...@chromium.org Signed-off-by: Cho KyongHo pullip@samsung.com --- drivers/iommu/exynos-iommu.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c index 4876d35..1c3a397 100644 --- a/drivers/iommu/exynos-iommu.c +++ b/drivers/iommu/exynos-iommu.c @@ -958,6 +958,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, if (lv2ent_small(ent)) { *ent = 0; size = SPAGE_SIZE; + pgtable_flush(ent, ent + 1); priv-lv2entcnt[lv1ent_offset(iova)] += 1; goto done; } @@ -966,6 +967,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, BUG_ON(size LPAGE_SIZE); memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); size = LPAGE_SIZE; priv-lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v11 02/27] iommu/exynos: add missing cache flush for removed page table entries
This commit adds cache flush for removed small and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. Reviewed-by: Tomasz Figa Tested-by: Grant Grundler Signed-off-by: Cho KyongHo --- drivers/iommu/exynos-iommu.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c index 4876d35..1c3a397 100644 --- a/drivers/iommu/exynos-iommu.c +++ b/drivers/iommu/exynos-iommu.c @@ -958,6 +958,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, if (lv2ent_small(ent)) { *ent = 0; size = SPAGE_SIZE; + pgtable_flush(ent, ent + 1); priv->lv2entcnt[lv1ent_offset(iova)] += 1; goto done; } @@ -966,6 +967,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, BUG_ON(size < LPAGE_SIZE); memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); size = LPAGE_SIZE; priv->lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v11 02/27] iommu/exynos: add missing cache flush for removed page table entries
This commit adds cache flush for removed small and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. Reviewed-by: Tomasz Figa t.f...@samsung.com Tested-by: Grant Grundler grund...@chromium.org Signed-off-by: Cho KyongHo pullip@samsung.com --- drivers/iommu/exynos-iommu.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c index 4876d35..1c3a397 100644 --- a/drivers/iommu/exynos-iommu.c +++ b/drivers/iommu/exynos-iommu.c @@ -958,6 +958,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, if (lv2ent_small(ent)) { *ent = 0; size = SPAGE_SIZE; + pgtable_flush(ent, ent + 1); priv-lv2entcnt[lv1ent_offset(iova)] += 1; goto done; } @@ -966,6 +967,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, BUG_ON(size LPAGE_SIZE); memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); size = LPAGE_SIZE; priv-lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 02/20] iommu/exynos: add missing cache flush for removed page table entries
This commit adds cache flush for removed small and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. Reviewed-by: Tomasz Figa Tested-by: Grant Grundler Signed-off-by: Cho KyongHo --- drivers/iommu/exynos-iommu.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c index 4876d35..1c3a397 100644 --- a/drivers/iommu/exynos-iommu.c +++ b/drivers/iommu/exynos-iommu.c @@ -958,6 +958,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, if (lv2ent_small(ent)) { *ent = 0; size = SPAGE_SIZE; + pgtable_flush(ent, ent + 1); priv->lv2entcnt[lv1ent_offset(iova)] += 1; goto done; } @@ -966,6 +967,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, BUG_ON(size < LPAGE_SIZE); memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); size = LPAGE_SIZE; priv->lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; -- 1.7.2.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 02/20] iommu/exynos: add missing cache flush for removed page table entries
This commit adds cache flush for removed small and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. Reviewed-by: Tomasz Figa t.f...@samsung.com Tested-by: Grant Grundler grund...@chromium.org Signed-off-by: Cho KyongHo pullip@samsung.com --- drivers/iommu/exynos-iommu.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c index 4876d35..1c3a397 100644 --- a/drivers/iommu/exynos-iommu.c +++ b/drivers/iommu/exynos-iommu.c @@ -958,6 +958,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, if (lv2ent_small(ent)) { *ent = 0; size = SPAGE_SIZE; + pgtable_flush(ent, ent + 1); priv-lv2entcnt[lv1ent_offset(iova)] += 1; goto done; } @@ -966,6 +967,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, BUG_ON(size LPAGE_SIZE); memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); size = LPAGE_SIZE; priv-lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 02/16] iommu/exynos: add missing cache flush for removed page table entries
On Thu, 08 Aug 2013 15:44:09 +0200, Tomasz Figa wrote: > On Thursday 08 of August 2013 18:37:34 Cho KyongHo wrote: > > This commit adds cache flush for removed small and large page entries > > in exynos_iommu_unmap(). Missing cache flush of removed page table > > entries can cause missing page fault interrupt when a master IP > > accesses an unmapped area. > > > > Tested-by: Grant Grundler > > Signed-off-by: Cho KyongHo > > --- > > drivers/iommu/exynos-iommu.c |2 ++ > > 1 files changed, 2 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c > > index 233f382..d545a25 100644 > > --- a/drivers/iommu/exynos-iommu.c > > +++ b/drivers/iommu/exynos-iommu.c > > @@ -1002,6 +1002,7 @@ static size_t exynos_iommu_unmap(struct > > iommu_domain *domain, if (lv2ent_small(ent)) { > > *ent = 0; > > size = SPAGE_SIZE; > > + pgtable_flush(ent, ent + 1); > > priv->lv2entcnt[lv1ent_offset(iova)] += 1; > > goto done; > > } > > @@ -1010,6 +1011,7 @@ static size_t exynos_iommu_unmap(struct > > iommu_domain *domain, BUG_ON(size < LPAGE_SIZE); > > > > memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); > > + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); > > > > size = LPAGE_SIZE; > > priv->lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; > > Looks reasonable. > > Reviewed-by: Tomasz Figa > Thanks. KyongHo. > Best regards, > Tomasz > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 02/16] iommu/exynos: add missing cache flush for removed page table entries
On Thursday 08 of August 2013 18:37:34 Cho KyongHo wrote: > This commit adds cache flush for removed small and large page entries > in exynos_iommu_unmap(). Missing cache flush of removed page table > entries can cause missing page fault interrupt when a master IP > accesses an unmapped area. > > Tested-by: Grant Grundler > Signed-off-by: Cho KyongHo > --- > drivers/iommu/exynos-iommu.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c > index 233f382..d545a25 100644 > --- a/drivers/iommu/exynos-iommu.c > +++ b/drivers/iommu/exynos-iommu.c > @@ -1002,6 +1002,7 @@ static size_t exynos_iommu_unmap(struct > iommu_domain *domain, if (lv2ent_small(ent)) { > *ent = 0; > size = SPAGE_SIZE; > + pgtable_flush(ent, ent + 1); > priv->lv2entcnt[lv1ent_offset(iova)] += 1; > goto done; > } > @@ -1010,6 +1011,7 @@ static size_t exynos_iommu_unmap(struct > iommu_domain *domain, BUG_ON(size < LPAGE_SIZE); > > memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); > + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); > > size = LPAGE_SIZE; > priv->lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; Looks reasonable. Reviewed-by: Tomasz Figa Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 02/16] iommu/exynos: add missing cache flush for removed page table entries
This commit adds cache flush for removed small and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. Tested-by: Grant Grundler Signed-off-by: Cho KyongHo --- drivers/iommu/exynos-iommu.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c index 233f382..d545a25 100644 --- a/drivers/iommu/exynos-iommu.c +++ b/drivers/iommu/exynos-iommu.c @@ -1002,6 +1002,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, if (lv2ent_small(ent)) { *ent = 0; size = SPAGE_SIZE; + pgtable_flush(ent, ent + 1); priv->lv2entcnt[lv1ent_offset(iova)] += 1; goto done; } @@ -1010,6 +1011,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, BUG_ON(size < LPAGE_SIZE); memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); size = LPAGE_SIZE; priv->lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; -- 1.7.2.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 02/16] iommu/exynos: add missing cache flush for removed page table entries
This commit adds cache flush for removed small and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. Tested-by: Grant Grundler grund...@chromium.org Signed-off-by: Cho KyongHo pullip@samsung.com --- drivers/iommu/exynos-iommu.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c index 233f382..d545a25 100644 --- a/drivers/iommu/exynos-iommu.c +++ b/drivers/iommu/exynos-iommu.c @@ -1002,6 +1002,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, if (lv2ent_small(ent)) { *ent = 0; size = SPAGE_SIZE; + pgtable_flush(ent, ent + 1); priv-lv2entcnt[lv1ent_offset(iova)] += 1; goto done; } @@ -1010,6 +1011,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, BUG_ON(size LPAGE_SIZE); memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); size = LPAGE_SIZE; priv-lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 02/16] iommu/exynos: add missing cache flush for removed page table entries
On Thursday 08 of August 2013 18:37:34 Cho KyongHo wrote: This commit adds cache flush for removed small and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. Tested-by: Grant Grundler grund...@chromium.org Signed-off-by: Cho KyongHo pullip@samsung.com --- drivers/iommu/exynos-iommu.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c index 233f382..d545a25 100644 --- a/drivers/iommu/exynos-iommu.c +++ b/drivers/iommu/exynos-iommu.c @@ -1002,6 +1002,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, if (lv2ent_small(ent)) { *ent = 0; size = SPAGE_SIZE; + pgtable_flush(ent, ent + 1); priv-lv2entcnt[lv1ent_offset(iova)] += 1; goto done; } @@ -1010,6 +1011,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, BUG_ON(size LPAGE_SIZE); memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); size = LPAGE_SIZE; priv-lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; Looks reasonable. Reviewed-by: Tomasz Figa t.f...@samsung.com Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 02/16] iommu/exynos: add missing cache flush for removed page table entries
On Thu, 08 Aug 2013 15:44:09 +0200, Tomasz Figa wrote: On Thursday 08 of August 2013 18:37:34 Cho KyongHo wrote: This commit adds cache flush for removed small and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. Tested-by: Grant Grundler grund...@chromium.org Signed-off-by: Cho KyongHo pullip@samsung.com --- drivers/iommu/exynos-iommu.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c index 233f382..d545a25 100644 --- a/drivers/iommu/exynos-iommu.c +++ b/drivers/iommu/exynos-iommu.c @@ -1002,6 +1002,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, if (lv2ent_small(ent)) { *ent = 0; size = SPAGE_SIZE; + pgtable_flush(ent, ent + 1); priv-lv2entcnt[lv1ent_offset(iova)] += 1; goto done; } @@ -1010,6 +1011,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, BUG_ON(size LPAGE_SIZE); memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); size = LPAGE_SIZE; priv-lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; Looks reasonable. Reviewed-by: Tomasz Figa t.f...@samsung.com Thanks. KyongHo. Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 02/12] iommu/exynos: add missing cache flush for removed page table entries
On Fri, Jul 26, 2013 at 4:26 AM, Cho KyongHo wrote: > This commit adds cache flush for removed small and large page entries > in exynos_iommu_unmap(). Missing cache flush of removed page table > entries can cause missing page fault interrupt when a master IP > accesses an unmapped area. > > Signed-off-by: Cho KyongHo Tested-by: Grant Grundler I'm convinced this is a critical fix to apply. Any time we touch the IOMMU Page Table, we need to flush so the change is immediately visible to the IOMMU. thanks, grant > --- > drivers/iommu/exynos-iommu.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c > index 233f382..e3be3e5 100644 > --- a/drivers/iommu/exynos-iommu.c > +++ b/drivers/iommu/exynos-iommu.c > @@ -1002,6 +1002,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain > *domain, > if (lv2ent_small(ent)) { > *ent = 0; > size = SPAGE_SIZE; > + pgtable_flush(ent, ent +1); > priv->lv2entcnt[lv1ent_offset(iova)] += 1; > goto done; > } > @@ -1010,6 +1011,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain > *domain, > BUG_ON(size < LPAGE_SIZE); > > memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); > + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); > > size = LPAGE_SIZE; > priv->lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; > -- > 1.7.2.5 > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 02/12] iommu/exynos: add missing cache flush for removed page table entries
This commit adds cache flush for removed small and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. Signed-off-by: Cho KyongHo --- drivers/iommu/exynos-iommu.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c index 233f382..e3be3e5 100644 --- a/drivers/iommu/exynos-iommu.c +++ b/drivers/iommu/exynos-iommu.c @@ -1002,6 +1002,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, if (lv2ent_small(ent)) { *ent = 0; size = SPAGE_SIZE; + pgtable_flush(ent, ent +1); priv->lv2entcnt[lv1ent_offset(iova)] += 1; goto done; } @@ -1010,6 +1011,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, BUG_ON(size < LPAGE_SIZE); memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); size = LPAGE_SIZE; priv->lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; -- 1.7.2.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 02/12] iommu/exynos: add missing cache flush for removed page table entries
This commit adds cache flush for removed small and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. Signed-off-by: Cho KyongHo pullip@samsung.com --- drivers/iommu/exynos-iommu.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c index 233f382..e3be3e5 100644 --- a/drivers/iommu/exynos-iommu.c +++ b/drivers/iommu/exynos-iommu.c @@ -1002,6 +1002,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, if (lv2ent_small(ent)) { *ent = 0; size = SPAGE_SIZE; + pgtable_flush(ent, ent +1); priv-lv2entcnt[lv1ent_offset(iova)] += 1; goto done; } @@ -1010,6 +1011,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, BUG_ON(size LPAGE_SIZE); memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); size = LPAGE_SIZE; priv-lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 02/12] iommu/exynos: add missing cache flush for removed page table entries
On Fri, Jul 26, 2013 at 4:26 AM, Cho KyongHo pullip@samsung.com wrote: This commit adds cache flush for removed small and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. Signed-off-by: Cho KyongHo pullip@samsung.com Tested-by: Grant Grundler grund...@chromium.org I'm convinced this is a critical fix to apply. Any time we touch the IOMMU Page Table, we need to flush so the change is immediately visible to the IOMMU. thanks, grant --- drivers/iommu/exynos-iommu.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c index 233f382..e3be3e5 100644 --- a/drivers/iommu/exynos-iommu.c +++ b/drivers/iommu/exynos-iommu.c @@ -1002,6 +1002,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, if (lv2ent_small(ent)) { *ent = 0; size = SPAGE_SIZE; + pgtable_flush(ent, ent +1); priv-lv2entcnt[lv1ent_offset(iova)] += 1; goto done; } @@ -1010,6 +1011,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, BUG_ON(size LPAGE_SIZE); memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); size = LPAGE_SIZE; priv-lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 01/12] iommu/exynos: add missing cache flush for removed pagetable entries
On Mon, Jul 8, 2013 at 11:21 AM, Grant Grundler wrote: > On Thu, Jul 4, 2013 at 4:20 AM, Cho KyongHo wrote: > ... >> I am still working on the patch set when I am free. >> Implementation of the updated patch set has been finished but not tested yet. >> >> I will post the patches after simple test :) > > Ok - thanks Cho! > > If you'd like me to test, please post a "RFC" (request for comment) > version that hasn't yet been tested. You don't have to do everything > yourself. :) Nevermind...I'm catching on email in reverse and see that you've already posted the patches! I'll try to test those today. :) thanks! grant -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 01/12] iommu/exynos: add missing cache flush for removed pagetable entries
On Thu, Jul 4, 2013 at 4:20 AM, Cho KyongHo wrote: ... > I am still working on the patch set when I am free. > Implementation of the updated patch set has been finished but not tested yet. > > I will post the patches after simple test :) Ok - thanks Cho! If you'd like me to test, please post a "RFC" (request for comment) version that hasn't yet been tested. You don't have to do everything yourself. :) cheers, grant -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 01/12] iommu/exynos: add missing cache flush for removed pagetable entries
On Thu, Jul 4, 2013 at 4:20 AM, Cho KyongHo pullip@samsung.com wrote: ... I am still working on the patch set when I am free. Implementation of the updated patch set has been finished but not tested yet. I will post the patches after simple test :) Ok - thanks Cho! If you'd like me to test, please post a RFC (request for comment) version that hasn't yet been tested. You don't have to do everything yourself. :) cheers, grant -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 01/12] iommu/exynos: add missing cache flush for removed pagetable entries
On Mon, Jul 8, 2013 at 11:21 AM, Grant Grundler grund...@chromium.org wrote: On Thu, Jul 4, 2013 at 4:20 AM, Cho KyongHo pullip@samsung.com wrote: ... I am still working on the patch set when I am free. Implementation of the updated patch set has been finished but not tested yet. I will post the patches after simple test :) Ok - thanks Cho! If you'd like me to test, please post a RFC (request for comment) version that hasn't yet been tested. You don't have to do everything yourself. :) Nevermind...I'm catching on email in reverse and see that you've already posted the patches! I'll try to test those today. :) thanks! grant -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 2/9] iommu/exynos: add missing cache flush for removed page table entries
This commit adds cache flush for removed small and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. Signed-off-by: Cho KyongHo --- drivers/iommu/exynos-iommu.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c index 233f382..e3be3e5 100644 --- a/drivers/iommu/exynos-iommu.c +++ b/drivers/iommu/exynos-iommu.c @@ -1002,6 +1002,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, if (lv2ent_small(ent)) { *ent = 0; size = SPAGE_SIZE; + pgtable_flush(ent, ent +1); priv->lv2entcnt[lv1ent_offset(iova)] += 1; goto done; } @@ -1010,6 +1011,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, BUG_ON(size < LPAGE_SIZE); memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); size = LPAGE_SIZE; priv->lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; -- 1.7.2.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 2/9] iommu/exynos: add missing cache flush for removed page table entries
This commit adds cache flush for removed small and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. Signed-off-by: Cho KyongHo pullip@samsung.com --- drivers/iommu/exynos-iommu.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c index 233f382..e3be3e5 100644 --- a/drivers/iommu/exynos-iommu.c +++ b/drivers/iommu/exynos-iommu.c @@ -1002,6 +1002,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, if (lv2ent_small(ent)) { *ent = 0; size = SPAGE_SIZE; + pgtable_flush(ent, ent +1); priv-lv2entcnt[lv1ent_offset(iova)] += 1; goto done; } @@ -1010,6 +1011,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, BUG_ON(size LPAGE_SIZE); memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); size = LPAGE_SIZE; priv-lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v6 01/12] iommu/exynos: add missing cache flush for removed pagetable entries
> From: grund...@google.com [mailto:grund...@google.com] On Behalf Of Grant > Grundler > Sent: Thursday, July 04, 2013 5:44 AM > > Ping? Hi. Sorry for late update the patch set. I am still working on the patch set when I am free. Implementation of the updated patch set has been finished but not tested yet. I will post the patches after simple test :) Thank you. > > On Mon, Jul 1, 2013 at 6:49 PM, Grant Grundler wrote: > > On Tuesday, December 25, 2012 6:00:01 PM UTC-8, Cho KyongHo wrote: > >> This commit adds cache flush for removed small page and large page > >> entries in exynos_iommu_unmap(). Missing cache flush of removed page > >> table entries can cause missing page fault interrupt when a master IP > >> accesses an unmapped area. > > > > KyongHo, > > It appears this patch was never applied and got caught up in the > > device tree binding discussion. AFAICT, this patch is still necessary. > > Can you resubmit this patch separately. Or ok if I do? > > > > Original patch is here: > > https://patchwork.kernel.org/patch/1910261/ > > > > thanks, > > grant -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v6 01/12] iommu/exynos: add missing cache flush for removed pagetable entries
From: grund...@google.com [mailto:grund...@google.com] On Behalf Of Grant Grundler Sent: Thursday, July 04, 2013 5:44 AM Ping? Hi. Sorry for late update the patch set. I am still working on the patch set when I am free. Implementation of the updated patch set has been finished but not tested yet. I will post the patches after simple test :) Thank you. On Mon, Jul 1, 2013 at 6:49 PM, Grant Grundler grund...@chromium.org wrote: On Tuesday, December 25, 2012 6:00:01 PM UTC-8, Cho KyongHo wrote: This commit adds cache flush for removed small page and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. KyongHo, It appears this patch was never applied and got caught up in the device tree binding discussion. AFAICT, this patch is still necessary. Can you resubmit this patch separately. Or ok if I do? Original patch is here: https://patchwork.kernel.org/patch/1910261/ thanks, grant -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 01/12] iommu/exynos: add missing cache flush for removed pagetable entries
Ping? On Mon, Jul 1, 2013 at 6:49 PM, Grant Grundler wrote: > On Tuesday, December 25, 2012 6:00:01 PM UTC-8, Cho KyongHo wrote: >> This commit adds cache flush for removed small page and large page >> entries in exynos_iommu_unmap(). Missing cache flush of removed >> page table entries can cause missing page fault interrupt when a >> master IP accesses an unmapped area. > > KyongHo, > It appears this patch was never applied and got caught up in the > device tree binding discussion. AFAICT, this patch is still necessary. > Can you resubmit this patch separately. Or ok if I do? > > Original patch is here: > https://patchwork.kernel.org/patch/1910261/ > > thanks, > grant -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 01/12] iommu/exynos: add missing cache flush for removed pagetable entries
Ping? On Mon, Jul 1, 2013 at 6:49 PM, Grant Grundler grund...@chromium.org wrote: On Tuesday, December 25, 2012 6:00:01 PM UTC-8, Cho KyongHo wrote: This commit adds cache flush for removed small page and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. KyongHo, It appears this patch was never applied and got caught up in the device tree binding discussion. AFAICT, this patch is still necessary. Can you resubmit this patch separately. Or ok if I do? Original patch is here: https://patchwork.kernel.org/patch/1910261/ thanks, grant -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 01/12] iommu/exynos: add missing cache flush for removed pagetable entries
-linux-arm (wrong email address - sorry) On Mon, Jul 1, 2013 at 6:49 PM, Grant Grundler wrote: > On Tuesday, December 25, 2012 6:00:01 PM UTC-8, Cho KyongHo wrote: >> This commit adds cache flush for removed small page and large page >> entries in exynos_iommu_unmap(). Missing cache flush of removed >> page table entries can cause missing page fault interrupt when a >> master IP accesses an unmapped area. > > KyongHo, > It appears this patch was never applied and got caught up in the > device tree binding discussion. AFAICT, this patch is still necessary. > Can you resubmit this patch separately. Or ok if I do? > > Original patch is here: > https://patchwork.kernel.org/patch/1910261/ > > thanks, > grant -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 01/12] iommu/exynos: add missing cache flush for removed pagetable entries
On Tuesday, December 25, 2012 6:00:01 PM UTC-8, Cho KyongHo wrote: > This commit adds cache flush for removed small page and large page > entries in exynos_iommu_unmap(). Missing cache flush of removed > page table entries can cause missing page fault interrupt when a > master IP accesses an unmapped area. KyongHo, It appears this patch was never applied and got caught up in the device tree binding discussion. AFAICT, this patch is still necessary. Can you resubmit this patch separately. Or ok if I do? Original patch is here: https://patchwork.kernel.org/patch/1910261/ thanks, grant -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 01/12] iommu/exynos: add missing cache flush for removed pagetable entries
On Tuesday, December 25, 2012 6:00:01 PM UTC-8, Cho KyongHo wrote: This commit adds cache flush for removed small page and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. KyongHo, It appears this patch was never applied and got caught up in the device tree binding discussion. AFAICT, this patch is still necessary. Can you resubmit this patch separately. Or ok if I do? Original patch is here: https://patchwork.kernel.org/patch/1910261/ thanks, grant -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 01/12] iommu/exynos: add missing cache flush for removed pagetable entries
-linux-arm (wrong email address - sorry) On Mon, Jul 1, 2013 at 6:49 PM, Grant Grundler grund...@chromium.org wrote: On Tuesday, December 25, 2012 6:00:01 PM UTC-8, Cho KyongHo wrote: This commit adds cache flush for removed small page and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. KyongHo, It appears this patch was never applied and got caught up in the device tree binding discussion. AFAICT, this patch is still necessary. Can you resubmit this patch separately. Or ok if I do? Original patch is here: https://patchwork.kernel.org/patch/1910261/ thanks, grant -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 01/12] iommu/exynos: add missing cache flush for removed pagetable entries
This commit adds cache flush for removed small page and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. Signed-off-by: KyongHo Cho --- drivers/iommu/exynos-iommu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c index 7fe44f8..b96f3b9 100644 --- a/drivers/iommu/exynos-iommu.c +++ b/drivers/iommu/exynos-iommu.c @@ -1002,6 +1002,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, if (lv2ent_small(ent)) { *ent = 0; + pgtable_flush(ent, ent + 1); size = SPAGE_SIZE; priv->lv2entcnt[lv1ent_offset(iova)] += 1; goto done; @@ -1011,6 +1012,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, BUG_ON(size < LPAGE_SIZE); memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); size = LPAGE_SIZE; priv->lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 01/12] iommu/exynos: add missing cache flush for removed pagetable entries
This commit adds cache flush for removed small page and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. Signed-off-by: KyongHo Cho pullip@samsung.com --- drivers/iommu/exynos-iommu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c index 7fe44f8..b96f3b9 100644 --- a/drivers/iommu/exynos-iommu.c +++ b/drivers/iommu/exynos-iommu.c @@ -1002,6 +1002,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, if (lv2ent_small(ent)) { *ent = 0; + pgtable_flush(ent, ent + 1); size = SPAGE_SIZE; priv-lv2entcnt[lv1ent_offset(iova)] += 1; goto done; @@ -1011,6 +1012,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, BUG_ON(size LPAGE_SIZE); memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); size = LPAGE_SIZE; priv-lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; -- 1.8.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 01/14] iommu/exynos: add missing cache flush for removed pagetable entries
This commit adds cache flush for removed small page and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. Signed-off-by: KyongHo Cho --- drivers/iommu/exynos-iommu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c index 7fe44f8..b96f3b9 100644 --- a/drivers/iommu/exynos-iommu.c +++ b/drivers/iommu/exynos-iommu.c @@ -1002,6 +1002,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, if (lv2ent_small(ent)) { *ent = 0; + pgtable_flush(ent, ent + 1); size = SPAGE_SIZE; priv->lv2entcnt[lv1ent_offset(iova)] += 1; goto done; @@ -1011,6 +1012,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, BUG_ON(size < LPAGE_SIZE); memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); size = LPAGE_SIZE; priv->lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 01/14] iommu/exynos: add missing cache flush for removed pagetable entries
This commit adds cache flush for removed small page and large page entries in exynos_iommu_unmap(). Missing cache flush of removed page table entries can cause missing page fault interrupt when a master IP accesses an unmapped area. Signed-off-by: KyongHo Cho pullip@samsung.com --- drivers/iommu/exynos-iommu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c index 7fe44f8..b96f3b9 100644 --- a/drivers/iommu/exynos-iommu.c +++ b/drivers/iommu/exynos-iommu.c @@ -1002,6 +1002,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, if (lv2ent_small(ent)) { *ent = 0; + pgtable_flush(ent, ent + 1); size = SPAGE_SIZE; priv-lv2entcnt[lv1ent_offset(iova)] += 1; goto done; @@ -1011,6 +1012,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain, BUG_ON(size LPAGE_SIZE); memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE); + pgtable_flush(ent, ent + SPAGES_PER_LPAGE); size = LPAGE_SIZE; priv-lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE; -- 1.8.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
David S. Miller writes: > David Woodhouse writes: >>> Call it flush_ecache_full() or something. >> >> Strange name. Why? How about __flush_cache_range()? > > How about flush_cache_range_force() instead? > > I want something in the name that tells the reader "this flushes > the caches, even though under every other ordinary circumstance > you would not need to". "flush" means what to you? write-back write-back-and-invalidate discard-and-invalidate All 3 behaviors are useful to me, and a few more. I've been using chunks of PowerPC assembly. Using PowerPC mnemonics... dcba -- allocate a cache block with undefined content dcbf -- write to RAM, then invalidate ("data cache block flush") dcbi -- invalidate, discarding any data dcbst -- initiate write if dirty dcbt -- prefetch, hinting about future load instructions dcbtst -- prefetch, hinting about future store instructions dcbz -- allocate and zero a cache block (cacheable mem only!) So dcbf_range() and dcbi_range() sound good to me. :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
David S. Miller writes: David Woodhouse writes: Call it flush_ecache_full() or something. Strange name. Why? How about __flush_cache_range()? How about flush_cache_range_force() instead? I want something in the name that tells the reader this flushes the caches, even though under every other ordinary circumstance you would not need to. flush means what to you? write-back write-back-and-invalidate discard-and-invalidate All 3 behaviors are useful to me, and a few more. I've been using chunks of PowerPC assembly. Using PowerPC mnemonics... dcba -- allocate a cache block with undefined content dcbf -- write to RAM, then invalidate (data cache block flush) dcbi -- invalidate, discarding any data dcbst -- initiate write if dirty dcbt -- prefetch, hinting about future load instructions dcbtst -- prefetch, hinting about future store instructions dcbz -- allocate and zero a cache block (cacheable mem only!) So dcbf_range() and dcbi_range() sound good to me. :-) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
On Tuesday 05 June 2001 14:57, Chris Wedgwood wrote: > I don't know about the CRIS (never heard of it, what is it?) I wondered about that too. From Documentation/cris: What is CRIS ? -- CRIS is an acronym for 'Code Reduced Instruction Set'. It is the CPU architecture in Axis Communication AB's range of embeddedn etwork CPU's, called ETRAX. The latest CPU is called ETRAX 100LX, where LX stands for 'Linux' because the chip was designed to be a good host for the Linux operating system. Interesting, huh? -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
On Tue, Jun 05, 2001 at 10:29:28AM +0200, Ingo Molnar wrote: > > - even when it works, it is necessarily very very very slow. Not to be > >used lightly. As you can imagine, the work-around is even slower. > > i've measured it once, IIRC it was around 10-15 millisecs on normal > pentiums, so while it's indeed the slowest x86 instruction on the planet, > it's still perhaps acceptable for hot-swapping ECC RAM. I can already hear the realtime crowd bitch ... Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
On Wed, Jun 06, 2001 at 12:57:03AM +1200, Chris Wedgwood wrote: > I don't know about the CRIS (never heard of it, what is it?), but on > an Athlon when benchmarking stuff, I could still see L1 cache hits > from data that was 15 seconds old under certain work-loads (obviously > not gcc!). Does anyone know how old something may exisit in cache > before being written back to RAM? I know of no architecture that has a time limit that after which's expire caches get written back to memory. In other words cache lines may stay dirty for an indefinate time if things are just right. Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
Bjorn Wesen wrote: > > I'd agree that to be really certain, a "flush_dcache()" function > should be implemented and used when an erase finishes. Like David Miller > wrote somewhere in the thread, one way is to use your knowledge of the > arch's cache and do suitable dummy accesses to flush it, if there is no > explicit command to do it. But that's just up to the arch coders.. > Here's a stupid question: Are there any processors out there that have a cache but no explicit cache-flush command? If not (i.e. no such "funny" processors), then what's wrong with the arch dependent include through a define to execute the arch specific asm command? The only issue (besides knowing the cache size at run time) that I can think about the "dummy" eviction scheme is that you now need to xfer potentially 3 times the cache size data to and from memory: #1. The dummy read #2. The eviction of the entire cache data being evicted #3. The refilling of the cache with good data again, as the dummy data cannot really represent anything useful. Is my thinking here completely non coherent with others? ;) Vipin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
[EMAIL PROTECTED] said: > How about flush_cache_range_force() instead? > I want something in the name that tells the reader "this flushes the > caches, even though under every other ordinary circumstance you would > not need to". OL, then. I would have thought it made more sense to have the flush_dcache_range() unconditionally do what its name implies, and to have a separate flush_dcache_range_for_dma() function which is optional. But that decision was already made - I suppose we can't change the semantics now. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
David Woodhouse writes: > > Call it flush_ecache_full() or something. > > Strange name. Why? How about __flush_cache_range()? How about flush_cache_range_force() instead? I want something in the name that tells the reader "this flushes the caches, even though under every other ordinary circumstance you would not need to". Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
[EMAIL PROTECTED] said: > David Woodhouse writes: > > What shall we call this function? The intuitive "flush_dcache_range" > > appears to have already been taken. > Call it flush_ecache_full() or something. Strange name. Why? How about __flush_cache_range()? -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
Possibly saying something extremly stupid here, how about simply "fakewriting" 0xFF to the flash after an erase to update any caches? > 2. Flash. A few writes of magic data to magic addresses and a whole erase >block suddenly contains 0xFF. The CPU doesn't notice that either. do_erase_stuff(); /* While verifying, update cache */ for (address = adr; address < (adr + size); address++) { if ((verify = map->read8(map, address)) != 0xFF) { error = 1; break; } /* "Fake" write 0xFF's to the erased sector so that caches are updated * after we verified that uncached data is ok */ *(unsigned char*)CACHED(address) = 0xFF; } /Johan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
On Tue, 5 Jun 2001, David Woodhouse wrote: > The flash mapping driver arch/cris/drivers/axisflashmap.c uses a cached > mapping of the flash chips for bulk reads, but obviously an uncached mapping > for sending commands and reading status when we're actually writing to or > erasing parts of the chip. > > However, it fails to flush the dcache for the range used when the flash is > accessed through the uncached mapping. So after an erase or write, we may > read old data from the cache for the changed area. I'll start by saying that axisflashmap.c was not meant to be used by any other archs, that's why it's in arch/cris. But if anyone find it useful, that's great. Just be aware that it's not _designed_ for general use and something like this might be just what that might mean. CRIS is cache coherent just like the x86 cache and does not need any explicit cache flushes for the write case. Even when doing cache bypass writing, if a cacheline already exist with the referenced memory, the cacheline is updated. In the erase case though, yes there should be a flush. However during the 1-2 seconds it takes to erase a sector, you can with very high certainity guarantee that the direct-mapped unified 8 kB cache on the CRIS is flushed from any flash references at all.. I mean, it's one-way associative, during 1-2 seconds it executes potentially 200 million instructions. So we haven't really bothered to think about the problem.. For other CPU's it might be more dangerous, although I don't hold my breath.. 1-2 seconds is a long time when talking about L1 caches. > However, I can't see a cache operation which performs this function. > flush_dcache_page() is defined as a NOP on CRIS as, it seems, it is on most > architectures. On other architectures, there's dma_cache_wback_inv(), but > that also seems to be a NOP on i386, to pick a random example. I'd agree that to be really certain, a "flush_dcache()" function should be implemented and used when an erase finishes. Like David Miller wrote somewhere in the thread, one way is to use your knowledge of the arch's cache and do suitable dummy accesses to flush it, if there is no explicit command to do it. But that's just up to the arch coders.. -bw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
David Woodhouse writes: > What shall we call this function? The intuitive "flush_dcache_range" appears > to have already been taken. Call it flush_ecache_full() or something. Many architectures need to implement this anyways if they have parity error exception handling. Most platforms sadly do not. Sparc64 is one of the exceptions here... Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
On 4 Jun 2001, Linus Torvalds wrote: > - even when it works, it is necessarily very very very slow. Not to be >used lightly. As you can imagine, the work-around is even slower. i've measured it once, IIRC it was around 10-15 millisecs on normal pentiums, so while it's indeed the slowest x86 instruction on the planet, it's still perhaps acceptable for hot-swapping ECC RAM. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
On 4 Jun 2001, Linus Torvalds wrote: - even when it works, it is necessarily very very very slow. Not to be used lightly. As you can imagine, the work-around is even slower. i've measured it once, IIRC it was around 10-15 millisecs on normal pentiums, so while it's indeed the slowest x86 instruction on the planet, it's still perhaps acceptable for hot-swapping ECC RAM. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
On Tue, 5 Jun 2001, David Woodhouse wrote: The flash mapping driver arch/cris/drivers/axisflashmap.c uses a cached mapping of the flash chips for bulk reads, but obviously an uncached mapping for sending commands and reading status when we're actually writing to or erasing parts of the chip. However, it fails to flush the dcache for the range used when the flash is accessed through the uncached mapping. So after an erase or write, we may read old data from the cache for the changed area. I'll start by saying that axisflashmap.c was not meant to be used by any other archs, that's why it's in arch/cris. But if anyone find it useful, that's great. Just be aware that it's not _designed_ for general use and something like this might be just what that might mean. CRIS is cache coherent just like the x86 cache and does not need any explicit cache flushes for the write case. Even when doing cache bypass writing, if a cacheline already exist with the referenced memory, the cacheline is updated. In the erase case though, yes there should be a flush. However during the 1-2 seconds it takes to erase a sector, you can with very high certainity guarantee that the direct-mapped unified 8 kB cache on the CRIS is flushed from any flash references at all.. I mean, it's one-way associative, during 1-2 seconds it executes potentially 200 million instructions. So we haven't really bothered to think about the problem.. For other CPU's it might be more dangerous, although I don't hold my breath.. 1-2 seconds is a long time when talking about L1 caches. However, I can't see a cache operation which performs this function. flush_dcache_page() is defined as a NOP on CRIS as, it seems, it is on most architectures. On other architectures, there's dma_cache_wback_inv(), but that also seems to be a NOP on i386, to pick a random example. I'd agree that to be really certain, a flush_dcache() function should be implemented and used when an erase finishes. Like David Miller wrote somewhere in the thread, one way is to use your knowledge of the arch's cache and do suitable dummy accesses to flush it, if there is no explicit command to do it. But that's just up to the arch coders.. -bw - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
Possibly saying something extremly stupid here, how about simply fakewriting 0xFF to the flash after an erase to update any caches? 2. Flash. A few writes of magic data to magic addresses and a whole erase block suddenly contains 0xFF. The CPU doesn't notice that either. do_erase_stuff(); /* While verifying, update cache */ for (address = adr; address (adr + size); address++) { if ((verify = map-read8(map, address)) != 0xFF) { error = 1; break; } /* Fake write 0xFF's to the erased sector so that caches are updated * after we verified that uncached data is ok */ *(unsigned char*)CACHED(address) = 0xFF; } /Johan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
Bjorn Wesen wrote: I'd agree that to be really certain, a flush_dcache() function should be implemented and used when an erase finishes. Like David Miller wrote somewhere in the thread, one way is to use your knowledge of the arch's cache and do suitable dummy accesses to flush it, if there is no explicit command to do it. But that's just up to the arch coders.. Here's a stupid question: Are there any processors out there that have a cache but no explicit cache-flush command? If not (i.e. no such funny processors), then what's wrong with the arch dependent include through a define to execute the arch specific asm command? The only issue (besides knowing the cache size at run time) that I can think about the dummy eviction scheme is that you now need to xfer potentially 3 times the cache size data to and from memory: #1. The dummy read #2. The eviction of the entire cache data being evicted #3. The refilling of the cache with good data again, as the dummy data cannot really represent anything useful. Is my thinking here completely non coherent with others? ;) Vipin - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
On Wed, Jun 06, 2001 at 12:57:03AM +1200, Chris Wedgwood wrote: I don't know about the CRIS (never heard of it, what is it?), but on an Athlon when benchmarking stuff, I could still see L1 cache hits from data that was 15 seconds old under certain work-loads (obviously not gcc!). Does anyone know how old something may exisit in cache before being written back to RAM? I know of no architecture that has a time limit that after which's expire caches get written back to memory. In other words cache lines may stay dirty for an indefinate time if things are just right. Ralf - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
On Tue, Jun 05, 2001 at 10:29:28AM +0200, Ingo Molnar wrote: - even when it works, it is necessarily very very very slow. Not to be used lightly. As you can imagine, the work-around is even slower. i've measured it once, IIRC it was around 10-15 millisecs on normal pentiums, so while it's indeed the slowest x86 instruction on the planet, it's still perhaps acceptable for hot-swapping ECC RAM. I can already hear the realtime crowd bitch ... Ralf - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
On Tuesday 05 June 2001 14:57, Chris Wedgwood wrote: I don't know about the CRIS (never heard of it, what is it?) I wondered about that too. From Documentation/cris: What is CRIS ? -- CRIS is an acronym for 'Code Reduced Instruction Set'. It is the CPU architecture in Axis Communication AB's range of embeddedn etwork CPU's, called ETRAX. The latest CPU is called ETRAX 100LX, where LX stands for 'Linux' because the chip was designed to be a good host for the Linux operating system. Interesting, huh? -- Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
[EMAIL PROTECTED] said: How about flush_cache_range_force() instead? I want something in the name that tells the reader this flushes the caches, even though under every other ordinary circumstance you would not need to. OL, then. I would have thought it made more sense to have the flush_dcache_range() unconditionally do what its name implies, and to have a separate flush_dcache_range_for_dma() function which is optional. But that decision was already made - I suppose we can't change the semantics now. -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
[EMAIL PROTECTED] said: David Woodhouse writes: What shall we call this function? The intuitive flush_dcache_range appears to have already been taken. Call it flush_ecache_full() or something. Strange name. Why? How about __flush_cache_range()? -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
David Woodhouse writes: Call it flush_ecache_full() or something. Strange name. Why? How about __flush_cache_range()? How about flush_cache_range_force() instead? I want something in the name that tells the reader this flushes the caches, even though under every other ordinary circumstance you would not need to. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
David Woodhouse writes: What shall we call this function? The intuitive flush_dcache_range appears to have already been taken. Call it flush_ecache_full() or something. Many architectures need to implement this anyways if they have parity error exception handling. Most platforms sadly do not. Sparc64 is one of the exceptions here... Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
In article <[EMAIL PROTECTED]>, Chris Wedgwood <[EMAIL PROTECTED]> wrote: >On Mon, Jun 04, 2001 at 07:03:01PM -0700, David S. Miller wrote: > >The x86 doesn't have dumb caches, therefore it really doesn't >need to flush anything. Maybe a mb(), but that is it. > >What if the memory is erased underneath the CPU being aware of this? >In such a way ig generates to bus traffic... Doing bank switching etc is outside the scope of the current DMA cache flush macros - they are there only for "sane" cache coherency issues, not to be used as generic "we have to flush the cache because we went behind the back of the CPU and switched a bank of memory around". You will have to come up with some new primitive for this. The x86 has the "wbinval" instruction, although it should be noted that - it is buggy and will lock up some CPU's. Use with EXTREME CAUTION. Intel set a special field in the MP table for whether wbinval is usable or not, and you can probably find their errata on which CPU's it doesn't work on (I think it was some early PPro steppings). When wbinval doesn't work, there's another strategy to flush the cache, but I forget what it was. It was something ridiculous like reading in a few megabytes of memory from consecutive physical addresses to make sure that the cache has been replaced. - even when it works, it is necessarily very very very slow. Not to be used lightly. As you can imagine, the work-around is even slower. On the whole, I would suggest avoiding this like the plague, and just marking such memory to be non-cacheable, regardless of whether there is a performance impact or not. If you mark it write-combining and speculative, it's going to perform a bit better. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
David Woodhouse writes: > > What should it do on i386? mb()? > > For it to have any use in the situation I described, it would need to > writeback and invalidate the dcache for the affected range. It doesn't seem > to do so, so it seems that it isn't what I require. It only needs to do that on cpus where the cache is not consistent with the rest of the system. x86 caches are fully consistent with the rest of the system, thus no flushing necessary. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
Jeff Garzik writes: > David Woodhouse wrote: > > I was pointed at Documentation/DMA-mapping.txt but that doesn't seem very > > helpful - it's very PCI-specific, and a quick perusal of pci_dma_sync() on > > i386 shows that it doesn't do what's required anyway. > > What should it do on i386? mb()? The x86 doesn't have dumb caches, therefore it really doesn't need to flush anything. Maybe a mb(), but that is it. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
[EMAIL PROTECTED] said: > > I was pointed at Documentation/DMA-mapping.txt but that doesn't seem > > very helpful - it's very PCI-specific, and a quick perusal of > > pci_dma_sync() on i386 shows that it doesn't do what's required anyway. > What should it do on i386? mb()? For it to have any use in the situation I described, it would need to writeback and invalidate the dcache for the affected range. It doesn't seem to do so, so it seems that it isn't what I require. The situation is simple - I have a paged RAM setup and I need it cached. All I want to do is flush and invalidate the cache when I'm about to waggle whatever I/O ports I waggle to change pages. There are other situations in which I need the cache flushed, but the above is one of the simplest. Even flush_page_to_ram() doesn't seem to do what its name implies, on most architectures. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
David Woodhouse wrote: > I was pointed at Documentation/DMA-mapping.txt but that doesn't seem very > helpful - it's very PCI-specific, and a quick perusal of pci_dma_sync() on > i386 shows that it doesn't do what's required anyway. What should it do on i386? mb()? -- Jeff Garzik | Echelon words of the day, from The Register: Building 1024| FRU Lebed HALO Spetznaz Al Amn al-Askari Glock 26 MandrakeSoft | Steak Knife Kill the President anarchy echelon | nuclear assassinate Roswell Waco World Trade Center - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Missing cache flush.
The flash mapping driver arch/cris/drivers/axisflashmap.c uses a cached mapping of the flash chips for bulk reads, but obviously an uncached mapping for sending commands and reading status when we're actually writing to or erasing parts of the chip. However, it fails to flush the dcache for the range used when the flash is accessed through the uncached mapping. So after an erase or write, we may read old data from the cache for the changed area. All the mapping driver needs to do is invalidate the dcache for the affected area before the next copy_from() operation. No need to worry about writeback in this case, because we never write to flash chips through the cached mapping. However, I can't see a cache operation which performs this function. flush_dcache_page() is defined as a NOP on CRIS as, it seems, it is on most architectures. On other architectures, there's dma_cache_wback_inv(), but that also seems to be a NOP on i386, to pick a random example. I'm aware that some architectures can't handle having both cached and uncached mappings of the same physical range - so to prevent dismissal of the question out of hand by people assuming all the world's a PeeCee - consider the alternative situation where we have ROM or RAM chips in a paged mapping such that only a 64K 'page' is visible by the CPU at a time (remember XMS?). Using an uncached mapping is extremely suboptimal - all we want to do is invalidate the cache when we change the page, or writeback and invalidate in the case of RAM. I would have thought that's the function that dma_cache_wback_inv() is supposed to perform - but it seems not to do so. So how is this _supposed_ to be done? I was pointed at Documentation/DMA-mapping.txt but that doesn't seem very helpful - it's very PCI-specific, and a quick perusal of pci_dma_sync() on i386 shows that it doesn't do what's required anyway. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Missing cache flush.
The flash mapping driver arch/cris/drivers/axisflashmap.c uses a cached mapping of the flash chips for bulk reads, but obviously an uncached mapping for sending commands and reading status when we're actually writing to or erasing parts of the chip. However, it fails to flush the dcache for the range used when the flash is accessed through the uncached mapping. So after an erase or write, we may read old data from the cache for the changed area. All the mapping driver needs to do is invalidate the dcache for the affected area before the next copy_from() operation. No need to worry about writeback in this case, because we never write to flash chips through the cached mapping. However, I can't see a cache operation which performs this function. flush_dcache_page() is defined as a NOP on CRIS as, it seems, it is on most architectures. On other architectures, there's dma_cache_wback_inv(), but that also seems to be a NOP on i386, to pick a random example. I'm aware that some architectures can't handle having both cached and uncached mappings of the same physical range - so to prevent dismissal of the question out of hand by people assuming all the world's a PeeCee - consider the alternative situation where we have ROM or RAM chips in a paged mapping such that only a 64K 'page' is visible by the CPU at a time (remember XMS?). Using an uncached mapping is extremely suboptimal - all we want to do is invalidate the cache when we change the page, or writeback and invalidate in the case of RAM. I would have thought that's the function that dma_cache_wback_inv() is supposed to perform - but it seems not to do so. So how is this _supposed_ to be done? I was pointed at Documentation/DMA-mapping.txt but that doesn't seem very helpful - it's very PCI-specific, and a quick perusal of pci_dma_sync() on i386 shows that it doesn't do what's required anyway. -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
David Woodhouse wrote: I was pointed at Documentation/DMA-mapping.txt but that doesn't seem very helpful - it's very PCI-specific, and a quick perusal of pci_dma_sync() on i386 shows that it doesn't do what's required anyway. What should it do on i386? mb()? -- Jeff Garzik | Echelon words of the day, from The Register: Building 1024| FRU Lebed HALO Spetznaz Al Amn al-Askari Glock 26 MandrakeSoft | Steak Knife Kill the President anarchy echelon | nuclear assassinate Roswell Waco World Trade Center - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
[EMAIL PROTECTED] said: I was pointed at Documentation/DMA-mapping.txt but that doesn't seem very helpful - it's very PCI-specific, and a quick perusal of pci_dma_sync() on i386 shows that it doesn't do what's required anyway. What should it do on i386? mb()? For it to have any use in the situation I described, it would need to writeback and invalidate the dcache for the affected range. It doesn't seem to do so, so it seems that it isn't what I require. The situation is simple - I have a paged RAM setup and I need it cached. All I want to do is flush and invalidate the cache when I'm about to waggle whatever I/O ports I waggle to change pages. There are other situations in which I need the cache flushed, but the above is one of the simplest. Even flush_page_to_ram() doesn't seem to do what its name implies, on most architectures. -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
Jeff Garzik writes: David Woodhouse wrote: I was pointed at Documentation/DMA-mapping.txt but that doesn't seem very helpful - it's very PCI-specific, and a quick perusal of pci_dma_sync() on i386 shows that it doesn't do what's required anyway. What should it do on i386? mb()? The x86 doesn't have dumb caches, therefore it really doesn't need to flush anything. Maybe a mb(), but that is it. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
In article [EMAIL PROTECTED], Chris Wedgwood [EMAIL PROTECTED] wrote: On Mon, Jun 04, 2001 at 07:03:01PM -0700, David S. Miller wrote: The x86 doesn't have dumb caches, therefore it really doesn't need to flush anything. Maybe a mb(), but that is it. What if the memory is erased underneath the CPU being aware of this? In such a way ig generates to bus traffic... Doing bank switching etc is outside the scope of the current DMA cache flush macros - they are there only for sane cache coherency issues, not to be used as generic we have to flush the cache because we went behind the back of the CPU and switched a bank of memory around. You will have to come up with some new primitive for this. The x86 has the wbinval instruction, although it should be noted that - it is buggy and will lock up some CPU's. Use with EXTREME CAUTION. Intel set a special field in the MP table for whether wbinval is usable or not, and you can probably find their errata on which CPU's it doesn't work on (I think it was some early PPro steppings). When wbinval doesn't work, there's another strategy to flush the cache, but I forget what it was. It was something ridiculous like reading in a few megabytes of memory from consecutive physical addresses to make sure that the cache has been replaced. - even when it works, it is necessarily very very very slow. Not to be used lightly. As you can imagine, the work-around is even slower. On the whole, I would suggest avoiding this like the plague, and just marking such memory to be non-cacheable, regardless of whether there is a performance impact or not. If you mark it write-combining and speculative, it's going to perform a bit better. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
David Woodhouse writes: What should it do on i386? mb()? For it to have any use in the situation I described, it would need to writeback and invalidate the dcache for the affected range. It doesn't seem to do so, so it seems that it isn't what I require. It only needs to do that on cpus where the cache is not consistent with the rest of the system. x86 caches are fully consistent with the rest of the system, thus no flushing necessary. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/