| Message ID | 20181207061620.107881-3-drinkcat@chromium.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | iommu/io-pgtable-arm-v7s: Use DMA32 zone for page tables | expand |
On Fri, Dec 07, 2018 at 02:16:19PM +0800, Nicolas Boichat wrote: > +#ifdef CONFIG_ZONE_DMA32 > +#define ARM_V7S_TABLE_GFP_DMA GFP_DMA32 > +#define ARM_V7S_TABLE_SLAB_CACHE SLAB_CACHE_DMA32 This name doesn't make any sense. Why not ARM_V7S_TABLE_SLAB_FLAGS ? > +#else > +#define ARM_V7S_TABLE_GFP_DMA GFP_DMA > +#define ARM_V7S_TABLE_SLAB_CACHE SLAB_CACHE_DMA Can you remind me again why it is, on machines which don't support ZONE_DMA32, why we have to allocate from ZONE_DMA? My understanding is that 64-bit machines have ZONE_DMA32 and 32-bit machines don't. So shouldn't this rather be GFP_KERNEL? Actually, maybe we could centralise this in gfp.h: #ifdef CONFIG_64BIT # ifdef CONFIG_ZONE_DMA32 #define GFP_32BIT GFP_DMA32 # else #define GFP_32BIT GFP_DMA #else /* 32-bit */ #define GFP_32BIT GFP_KERNEL #endif
On Fri, Dec 7, 2018 at 4:05 PM Matthew Wilcox <willy@infradead.org> wrote: > > On Fri, Dec 07, 2018 at 02:16:19PM +0800, Nicolas Boichat wrote: > > +#ifdef CONFIG_ZONE_DMA32 > > +#define ARM_V7S_TABLE_GFP_DMA GFP_DMA32 > > +#define ARM_V7S_TABLE_SLAB_CACHE SLAB_CACHE_DMA32 > > This name doesn't make any sense. Why not ARM_V7S_TABLE_SLAB_FLAGS ? Sure, will fix in v6 then. > > +#else > > +#define ARM_V7S_TABLE_GFP_DMA GFP_DMA > > +#define ARM_V7S_TABLE_SLAB_CACHE SLAB_CACHE_DMA > > Can you remind me again why it is, on machines which don't support > ZONE_DMA32, why we have to allocate from ZONE_DMA? My understanding > is that 64-bit machines have ZONE_DMA32 and 32-bit machines don't. > So shouldn't this rather be GFP_KERNEL? Sorry I mean to reply on the v4 thread, Christoph raised the same question (https://patchwork.kernel.org/patch/10713025/). I don't know, and I don't have all the hardware needed to test this ,-( Robin and Will both didn't seem sure. I'd rather not introduce a new regression, this patch series tries to fix a known arm64 regression, where we _need_ tables to be in DMA32. If we want to change 32-bit hardware to use GFP_KERNEL, and we're sure it works, that's fine by me, but it should be in another patch set. Hope this makes sense, Thanks, > Actually, maybe we could centralise this in gfp.h: > > #ifdef CONFIG_64BIT > # ifdef CONFIG_ZONE_DMA32 > #define GFP_32BIT GFP_DMA32 > # else > #define GFP_32BIT GFP_DMA > #else /* 32-bit */ > #define GFP_32BIT GFP_KERNEL > #endif >
On 12/7/18 7:16 AM, Nicolas Boichat wrote: > IOMMUs using ARMv7 short-descriptor format require page tables > (level 1 and 2) to be allocated within the first 4GB of RAM, even > on 64-bit systems. > > For level 1/2 pages, ensure GFP_DMA32 is used if CONFIG_ZONE_DMA32 > is defined (e.g. on arm64 platforms). > > For level 2 pages, allocate a slab cache in SLAB_CACHE_DMA32. Note > that we do not explicitly pass GFP_DMA[32] to kmem_cache_zalloc, > as this is not strictly necessary, and would cause a warning > in mm/sl*b.c, as we did not update GFP_SLAB_BUG_MASK. > > Also, print an error when the physical address does not fit in > 32-bit, to make debugging easier in the future. > > Fixes: ad67f5a6545f ("arm64: replace ZONE_DMA with ZONE_DMA32") Also, CC stable? > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c index 445c3bde04800c..f311fe1dfa47b7 100644 --- a/drivers/iommu/io-pgtable-arm-v7s.c +++ b/drivers/iommu/io-pgtable-arm-v7s.c @@ -161,6 +161,14 @@ #define ARM_V7S_TCR_PD1 BIT(5) +#ifdef CONFIG_ZONE_DMA32 +#define ARM_V7S_TABLE_GFP_DMA GFP_DMA32 +#define ARM_V7S_TABLE_SLAB_CACHE SLAB_CACHE_DMA32 +#else +#define ARM_V7S_TABLE_GFP_DMA GFP_DMA +#define ARM_V7S_TABLE_SLAB_CACHE SLAB_CACHE_DMA +#endif + typedef u32 arm_v7s_iopte; static bool selftest_running; @@ -198,13 +206,16 @@ static void *__arm_v7s_alloc_table(int lvl, gfp_t gfp, void *table = NULL; if (lvl == 1) - table = (void *)__get_dma_pages(__GFP_ZERO, get_order(size)); + table = (void *)__get_free_pages( + __GFP_ZERO | ARM_V7S_TABLE_GFP_DMA, get_order(size)); else if (lvl == 2) - table = kmem_cache_zalloc(data->l2_tables, gfp | GFP_DMA); + table = kmem_cache_zalloc(data->l2_tables, gfp); phys = virt_to_phys(table); - if (phys != (arm_v7s_iopte)phys) + if (phys != (arm_v7s_iopte)phys) { /* Doesn't fit in PTE */ + dev_err(dev, "Page table does not fit in PTE: %pa", &phys); goto out_free; + } if (table && !(cfg->quirks & IO_PGTABLE_QUIRK_NO_DMA)) { dma = dma_map_single(dev, table, size, DMA_TO_DEVICE); if (dma_mapping_error(dev, dma)) @@ -737,7 +748,7 @@ static struct io_pgtable *arm_v7s_alloc_pgtable(struct io_pgtable_cfg *cfg, data->l2_tables = kmem_cache_create("io-pgtable_armv7s_l2", ARM_V7S_TABLE_SIZE(2), ARM_V7S_TABLE_SIZE(2), - SLAB_CACHE_DMA, NULL); + ARM_V7S_TABLE_SLAB_CACHE, NULL); if (!data->l2_tables) goto out_free_data;
IOMMUs using ARMv7 short-descriptor format require page tables (level 1 and 2) to be allocated within the first 4GB of RAM, even on 64-bit systems. For level 1/2 pages, ensure GFP_DMA32 is used if CONFIG_ZONE_DMA32 is defined (e.g. on arm64 platforms). For level 2 pages, allocate a slab cache in SLAB_CACHE_DMA32. Note that we do not explicitly pass GFP_DMA[32] to kmem_cache_zalloc, as this is not strictly necessary, and would cause a warning in mm/sl*b.c, as we did not update GFP_SLAB_BUG_MASK. Also, print an error when the physical address does not fit in 32-bit, to make debugging easier in the future. Fixes: ad67f5a6545f ("arm64: replace ZONE_DMA with ZONE_DMA32") Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> --- Changes since v2: - Commit message (v3 used the page_frag approach) Changes since v4: - Do not pass ARM_V7S_TABLE_GFP_DMA to kmem_cache_zalloc, as this is unnecessary, and would trigger a warning. drivers/iommu/io-pgtable-arm-v7s.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-)