All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Christoph Hellwig <hch@lst.de>,
	Jim Quinlan <james.quinlan@broadcom.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	bcm-kernel-feedback-list@broadcom.com, jim2101024@gmail.com,
	Russell King <linux@armlinux.org.uk>,
	Arnd Bergmann <arnd@arndb.de>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	"Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Sebastian Reichel <sebastian.reichel@collabora.com>,
	"Mike Rapoport (IBM)" <rppt@kernel.org>,
	Eric DeVolder <eric.devolder@oracle.com>,
	Nathan Chancellor <nathan@kernel.org>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	"moderated list:ARM PORT" <linux-arm-kernel@lists.infradead.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 1/1] ARM: Select DMA_DIRECT_REMAP to fix restricted DMA
Date: Mon, 23 Oct 2023 08:16:01 +0200	[thread overview]
Message-ID: <20231023061601.GA12056@lst.de> (raw)
In-Reply-To: <3515448c-8a4b-4669-9f80-2f55c5100674@samsung.com>

On Fri, Oct 20, 2023 at 10:16:46AM +0200, Marek Szyprowski wrote:
> For historical reasons (performance and limitations of the pre-ARM v7 
> cores), on the 32bit ARM the whole kernel's direct mapping is done using 
> so called 'sections' (1MiB size afair). Those sections are created in 
> the per-process MMU page tables (there are no separate MMU table for the 
> kernel mappings), so altering those mappings requires updating bits in 
> all processes in the system. Practically this means that those mappings 
> has to be static once created during boot time.

That's actually the same on many architetures, and matches the
explanation I heard from Russell before.

> That's why when no CMA 
> is selected, the whole dma_alloc_coherent() allocations are limited to 
> rather small region, which is already remapped as non-cached during boot.

But this does not match my understanding of the code:

 - arch_dma_alloc calls __dma_alloc with is_coherent set to false
 - __dma_alloc then selects cma_allocator if CMA is supported for
   the device / allocation, else remap_allocator if the allocation
   is allowed to block and only if blocking is not allowed pool_allocator
   to allocate from the boot-time pool

This very match matches the dma-direct flow with DMA_DIRECT_REMAP
selected.  The major exception is the direct mapping of the CMA
allocations done by arm32.

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

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Christoph Hellwig <hch@lst.de>,
	Jim Quinlan <james.quinlan@broadcom.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	bcm-kernel-feedback-list@broadcom.com, jim2101024@gmail.com,
	Russell King <linux@armlinux.org.uk>,
	Arnd Bergmann <arnd@arndb.de>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	"Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Sebastian Reichel <sebastian.reichel@collabora.com>,
	"Mike Rapoport (IBM)" <rppt@kernel.org>,
	Eric DeVolder <eric.devolder@oracle.com>,
	Nathan Chancellor <nathan@kernel.org>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	"moderated list:ARM PORT" <linux-arm-kernel@lists.infradead.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 1/1] ARM: Select DMA_DIRECT_REMAP to fix restricted DMA
Date: Mon, 23 Oct 2023 08:16:01 +0200	[thread overview]
Message-ID: <20231023061601.GA12056@lst.de> (raw)
In-Reply-To: <3515448c-8a4b-4669-9f80-2f55c5100674@samsung.com>

On Fri, Oct 20, 2023 at 10:16:46AM +0200, Marek Szyprowski wrote:
> For historical reasons (performance and limitations of the pre-ARM v7 
> cores), on the 32bit ARM the whole kernel's direct mapping is done using 
> so called 'sections' (1MiB size afair). Those sections are created in 
> the per-process MMU page tables (there are no separate MMU table for the 
> kernel mappings), so altering those mappings requires updating bits in 
> all processes in the system. Practically this means that those mappings 
> has to be static once created during boot time.

That's actually the same on many architetures, and matches the
explanation I heard from Russell before.

> That's why when no CMA 
> is selected, the whole dma_alloc_coherent() allocations are limited to 
> rather small region, which is already remapped as non-cached during boot.

But this does not match my understanding of the code:

 - arch_dma_alloc calls __dma_alloc with is_coherent set to false
 - __dma_alloc then selects cma_allocator if CMA is supported for
   the device / allocation, else remap_allocator if the allocation
   is allowed to block and only if blocking is not allowed pool_allocator
   to allocate from the boot-time pool

This very match matches the dma-direct flow with DMA_DIRECT_REMAP
selected.  The major exception is the direct mapping of the CMA
allocations done by arm32.

  reply	other threads:[~2023-10-23  6:16 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-26 17:52 RFC: ARM && restricted DMA apparently not working Jim Quinlan
2023-09-26 17:52 ` Jim Quinlan
2023-09-26 17:52 ` [PATCH v1 1/1] ARM: Select DMA_DIRECT_REMAP to fix restricted DMA Jim Quinlan
2023-09-26 17:52   ` Jim Quinlan
2023-09-27  7:13   ` kernel test robot
2023-09-27  7:13     ` kernel test robot
2023-09-27 23:10   ` Linus Walleij
2023-09-27 23:10     ` Linus Walleij
2023-09-28 12:07     ` Jim Quinlan
2023-09-28 12:07       ` Jim Quinlan
2023-09-28 13:09       ` Jim Quinlan
2023-09-28 13:09         ` Jim Quinlan
2023-09-28 13:32       ` Arnd Bergmann
2023-09-28 13:32         ` Arnd Bergmann
2023-09-28 14:00         ` Jim Quinlan
2023-09-28 14:00           ` Jim Quinlan
2023-09-28 14:01           ` Jim Quinlan
2023-09-28 14:01             ` Jim Quinlan
2023-09-28 15:16           ` Arnd Bergmann
2023-09-28 15:16             ` Arnd Bergmann
2023-09-28 15:33             ` Robin Murphy
2023-09-28 15:33               ` Robin Murphy
2023-09-28 16:20               ` Arnd Bergmann
2023-09-28 16:20                 ` Arnd Bergmann
2023-09-29 19:24             ` Jim Quinlan
2023-09-29 19:24               ` Jim Quinlan
2023-09-29 19:52               ` Arnd Bergmann
2023-09-29 19:52                 ` Arnd Bergmann
2023-09-29 21:13                 ` Jim Quinlan
2023-09-29 21:13                   ` Jim Quinlan
2023-10-01 12:48                 ` Jim Quinlan
2023-10-01 12:48                   ` Jim Quinlan
2023-09-28 15:47       ` Robin Murphy
2023-09-28 15:47         ` Robin Murphy
2023-10-02 12:33         ` Jim Quinlan
2023-10-02 12:33           ` Jim Quinlan
2023-10-02 15:08           ` Robin Murphy
2023-10-02 15:08             ` Robin Murphy
2023-10-02  6:16     ` Christoph Hellwig
2023-10-02  6:16       ` Christoph Hellwig
2023-10-05 17:53       ` Jim Quinlan
2023-10-05 17:53         ` Jim Quinlan
2023-10-06  7:40         ` Christoph Hellwig
2023-10-06  7:40           ` Christoph Hellwig
2023-10-20  8:16           ` Marek Szyprowski
2023-10-20  8:16             ` Marek Szyprowski
2023-10-23  6:16             ` Christoph Hellwig [this message]
2023-10-23  6:16               ` Christoph Hellwig
2023-09-28 16:24   ` Christophe Leroy
2023-09-28 16:24     ` Christophe Leroy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231023061601.GA12056@lst.de \
    --to=hch@lst.de \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=corbet@lwn.net \
    --cc=eric.devolder@oracle.com \
    --cc=geert+renesas@glider.be \
    --cc=james.quinlan@broadcom.com \
    --cc=jim2101024@gmail.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=m.szyprowski@samsung.com \
    --cc=nathan@kernel.org \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=rppt@kernel.org \
    --cc=sebastian.reichel@collabora.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.