1.. SPDX-License-Identifier: GPL-2.0
2
3====================
4DAX Driver Operation
5====================
6The `Direct Access Device` driver was originally designed to provide a
7memory-like access mechanism to memory-like block-devices.  It was
8extended to support CXL Memory Devices, which provide user-configured
9memory devices.
10
11The CXL subsystem depends on the DAX subsystem to either:
12
13- Generate a file-like interface to userland via :code:`/dev/daxN.Y`, or
14- Engage the memory-hotplug interface to add CXL memory to page allocator.
15
16The DAX subsystem exposes this ability through the `cxl_dax_region` driver.
17A `dax_region` provides the translation between a CXL `memory_region` and
18a `DAX Device`.
19
20DAX Device
21==========
22A `DAX Device` is a file-like interface exposed in :code:`/dev/daxN.Y`. A
23memory region exposed via dax device can be accessed via userland software
24via the :code:`mmap()` system-call.  The result is direct mappings to the
25CXL capacity in the task's page tables.
26
27Users wishing to manually handle allocation of CXL memory should use this
28interface.
29
30kmem conversion
31===============
32The :code:`dax_kmem` driver converts a `DAX Device` into a series of `hotplug
33memory blocks` managed by :code:`kernel/memory-hotplug.c`.  This capacity
34will be exposed to the kernel page allocator in the user-selected memory
35zone.
36
37The :code:`memmap_on_memory` setting (both global and DAX device local)
38dictates where the kernell will allocate the :code:`struct folio` descriptors
39for this memory will come from.  If :code:`memmap_on_memory` is set, memory
40hotplug will set aside a portion of the memory block capacity to allocate
41folios. If unset, the memory is allocated via a normal :code:`GFP_KERNEL`
42allocation - and as a result will most likely land on the local NUM node of the
43CPU executing the hotplug operation.
44