Suppose process A has been preempted to allow process B to run. If system memory is low and the kernel needs to reclaim memory for process B, is it possible for the page tables of process A to be swapped out to disk? I understand that when a page belonging to a process is swapped out, the corresponding page table entry (PTE) must be updated to indicate that the page has been swapped. But if the page tables of process A were already swapped out before its pages are selected for swapping, how does the kernel update the PTEs to reflect this? In such a scenario, will the kernel swap the page tables of process A back into memory just to update the PTEs? Or is there some alternative mechanism used? Just tried reading other sources from the internet, didn't find much

I am working on a laptop with 16 GB of non-upgradable RAM on Linux Mint 22, kernel 6.8.0-63-generic #66-Ubuntu. I created a 32 GB swap partition on my NVMe drive with a high swappiness value [note1] and disabled overcommit (vm.overcommit_memory=2). This usually works fine, even with several very hungry processes running (Firefox, Thunderbird, Zotero, VSCode, Element). Linux keeps around 5 GB of RAM for cache and 5-10 GB in swap. Slowdown when switching programs is minimal due to the fast NVMe swap. Now Firefox just died and the dmesg log is full of lines like this:

[77152.624112] __vm_enough_memory: pid: 4107, comm: IPC Launch, not enough memory for the allocation
[77152.624979] __vm_enough_memory: pid: 4612, comm: WebExtensions, not enough memory for the allocation
[77152.624986] __vm_enough_memory: pid: 4612, comm: WebExtensions, not enough memory for the allocation
[77156.091496] __vm_enough_memory: pid: 4107, comm: IPC Launch, not enough memory for the allocation
[77227.513600] __vm_enough_memory: pid: 203606, comm: Sandbox Forked, not enough memory for the allocation
[77227.514500] __vm_enough_memory: pid: 4612, comm: WebExtensions, not enough memory for the allocation
[77227.514509] __vm_enough_memory: pid: 4612, comm: WebExtensions, not enough memory for the allocation
[77227.529083] __vm_enough_memory: pid: 4007, comm: firefox-bin, not enough memory for the allocation
Sandbox Forked: segfault at 0 ip 00007d4850861bd9 sp 00007d482b7fc1f0 error 6 in libxul.so[7d484dcdb000+6bb3000] likely on CPU 7 (core 3, socket 0)
[77227.562043] Code: 48 89 01 31 c0 b9 ca 02 00 00 48 89 08 e8 3f 25 02 04 48 8d 05 f2 66 82 fb 48 8b 0d 79 8a 53 04 48 89 01 31 c0 b9 ae 02 00 00  89 08 e8 1f 25 02 04 e8 3a c1 02 04 48 8d 35 6e d9 8a fb 48 8d

However, there were about 4 GB of RAM and more than 26 GB of swap available. **Does anyone have any idea how this could happen? I doubt that Firefox tried to allocate 30 GB at once and exhausted both RAM and Swap at the same time.** Here's a screenshot from System Monitor, which happened to be running, where you can see how much was free and how much it dropped when Firefox died: --- Just for completeness, here is my kernel vm configuration and contents of /proc/meminfo:

$ sudo sysctl vm
vm.admin_reserve_kbytes = 8192
vm.compact_unevictable_allowed = 1
vm.compaction_proactiveness = 20
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 1500
vm.dirty_ratio = 20
vm.dirty_writeback_centisecs = 1500
vm.dirtytime_expire_seconds = 43200
vm.extfrag_threshold = 500
vm.hugetlb_optimize_vmemmap = 0
vm.hugetlb_shm_group = 0
vm.laptop_mode = 0
vm.legacy_va_layout = 0
vm.lowmem_reserve_ratio = 256	256	32	0	0
vm.max_map_count = 1048576
vm.memfd_noexec = 0
vm.memory_failure_early_kill = 0
vm.memory_failure_recovery = 1
vm.min_free_kbytes = 67584
vm.min_slab_ratio = 5
vm.min_unmapped_ratio = 1
vm.mmap_min_addr = 65536
vm.mmap_rnd_bits = 32
vm.mmap_rnd_compat_bits = 16
vm.nr_hugepages = 0
vm.nr_hugepages_mempolicy = 0
vm.nr_overcommit_hugepages = 0
vm.numa_stat = 1
vm.numa_zonelist_order = Node
vm.oom_dump_tasks = 1
vm.oom_kill_allocating_task = 0
vm.overcommit_kbytes = 0
vm.overcommit_memory = 2
vm.overcommit_ratio = 50
vm.page-cluster = 0
vm.page_lock_unfairness = 5
vm.panic_on_oom = 0
vm.percpu_pagelist_high_fraction = 0
vm.stat_interval = 1
vm.swappiness = 180
vm.unprivileged_userfaultfd = 0
vm.user_reserve_kbytes = 131072
vm.vfs_cache_pressure = 100
vm.watermark_boost_factor = 0
vm.watermark_scale_factor = 125
vm.zone_reclaim_mode = 0

$ cat /proc/meminfo 
MemTotal:       16024252 kB
MemFree:         2941612 kB
MemAvailable:    5504264 kB
Buffers:          346236 kB
Cached:          4639316 kB
SwapCached:       979904 kB
Active:          7280640 kB
Inactive:        2468760 kB
Active(anon):    6426732 kB
Inactive(anon):   529828 kB
Active(file):     853908 kB
Inactive(file):  1938932 kB
Unevictable:     1809680 kB
Mlocked:             592 kB
SwapTotal:      33554428 kB
SwapFree:       29745344 kB
Zswap:                 0 kB
Zswapped:              0 kB
Dirty:              3088 kB
Writeback:             0 kB
AnonPages:       6473408 kB
Mapped:           996316 kB
Shmem:           2192712 kB
KReclaimable:     839736 kB
Slab:            1131764 kB
SReclaimable:     839736 kB
SUnreclaim:       292028 kB
KernelStack:       33728 kB
PageTables:       100528 kB
SecPageTables:         0 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    41566552 kB
Committed_AS:   35867360 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      114112 kB
VmallocChunk:          0 kB
Percpu:             9280 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
ShmemHugePages:  1144832 kB
ShmemPmdMapped:        0 kB
FileHugePages:         0 kB
FilePmdMapped:         0 kB
Unaccepted:            0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB
DirectMap4k:      408748 kB
DirectMap2M:    11821056 kB
DirectMap1G:     4194304 kB

Despite having a data bus size of 64 bit, the address bus size of modern AMD64-compatible CPUs is/was 48 bit for some time which allows using 48-bit long virtual memory addresses with a maximum of addressable virtual memory of 2^48 => 256 TB. Intel says that since the Ice Lake CPU architecture, their CPUs support 5-Level Paging with 57-bit long virtual memory addresses. Linux supports this since Kernel 4.14 . Does this mean that CPUs that support 5-Level Paging with 57-bit long virtual memory addresses implement a 57-bit long address bus? The background of my question is that around 10-15 years ago, it was not a problem to learn about the address bus and data bus size of modern CPUs, but since approximately ten years, it is not simple to find information about the address bus size. https://software.intel.com/content/www/us/en/develop/download/5-level-paging-and-5-level-ept-white-paper.html https://www.kernel.org/doc/html/latest/arch/x86/x86_64/5level-paging.html

According to Linux Kernel Development by Robert Love, p. 233: > Because of hardware limitations, the kernel cannot treat all pages as identical. Some pages, because of their physical address in memory, cannot be used for certain tasks. Because of this limitation, the kernel divides pages into different *zones*. The kernel uses the zones to group pages of similar properties. In particular, Linux has to deal with two shortcomings of hardware with respect to memory addressing: > * Some hardware devices can perform DMA (direct memory access) to only certain memory addresses. > * **Some architectures can physically addressing [sic] larger amounts of memory than they can virtually address.** Consequently, some memory is not permanently mapped into the kernel address space. The bold face is added by me. What does this statement mean? Love goes on to say: > What an architecture can and cannot directly map varies. On 32-bit x86 systems, ZONE_HIGHMEM is all memory above the physical 896MB mark. On other architectures, ZONE_HIGHMEM is empty because all memory is directly mapped. Could this mean that the MMU on 32-bit x86 can't map more than 896MiB or so of physical addresses at one time? In other words, the MMU can handle a page table with up to 896MiB/4KiB = 229,376 entries? [This answer](https://unix.stackexchange.com/a/98229/703626) says that Love is talking about Physical Address Extension (PAE). If my mental model of the whole situation is correct, it is saying that if the kernel were to ever need to take up more than 4GiB of physical memory on a system with PAE, then it would not be able to fit enough entries in the page table at once (because there's not enough virtual address space to address it at once), so it would need to bring pages in and out (hence "Dynamically mapped pages" in Love's table on p. 234). But then why is the mark so low at 896MiB? Why can't it be somewhere higher, like 4096-128MiB? Then, on any system where the physical address space *does* fit within the virtual address space (<4GiB), almost all of the memory would be ZONE_NORMAL, and could be mapped in the kernel's virtual address space without needing to dynamically map and unmap memory. This is the current situation on x86_64.

I was looking at the /proc//maps file for an aarch64 process running on an Android (10). This section caught my interest:

72582d2000-72582f6000 --xp 00012000 07:20 93        /apex/com.android.runtime/lib64/bionic/libm.so

According to readelf, that corresponds, as expected, to the .text section. What does it mean for a memory section to be executable but not readable? I didn't think that was possible.

I see in the web many conflicting or unclear descriptions of the memory layout of a Linux process. Usually the [common diagram]( https://stackoverflow.com/q/64038876/8529284) looks like: And a common [description](https://www.quora.com/Is-the-data-segment-is-part-of-the-heap-or-the-heap-is-part-of-it/answer/Sudarshan-43?ch=15&oid=30002660&share=af08bbcb&srid=2KkSm&target_type=answer) would say that: > The data segment contains only global or static variable which have a > predefined value and can be modified. Heap contains the dynamically > allocated data that is stored in a memory section we refer that as > heap section and this section typically starts where data segments > ends. And [also](https://stackoverflow.com/a/14954147/8529284) : > The heap is, generally speaking, one specific memory region created by > the C runtime, and managed by malloc (which in turn uses the brk > and sbrk system calls to grow and shrink). > > mmap is a way of creating new memory regions, independently of > malloc (and so independently of the heap). munmap is simply its > inverse, it releases these regions. Many of the those explanations seem outdated, and I find many discrepancies. For instance, many articles - as the answer above - claim that the heap is used my malloc, but this is actualy a library call that's using either sbrk or mmap, as the malloc [man page](https://man7.org/linux/man-pages/man3/malloc.3.html) says: > Normally, malloc() allocates memory from the heap, and adjusts > the size of the heap as required, using sbrk(2). When allocating > blocks of memory larger than **MMAP_THRESHOLD** bytes, the glibc > malloc() implementation allocates the memory as a private > anonymous mapping using mmap(2). So if malloc in many cases in implemented by mmap, what's the difference between the heap and and the mmap area? Another thing that seems like a contradiction is that many articles (as the malloc man page itself) claim that brk/sbrk adjust the size of the heap, but their [man page](https://man7.org/linux/man-pages/man2/brk.2.html) says it actually adjust the size of the **data segment**: > brk() and sbrk() change the location of the **program break**, > which > defines the end of the process's data segment (i.e., the program > break is the first location after the end of the uninitialized > data segment). So I'm trying to get a clear, up-to-date overall explanation of the memory layout of processes nowadays with the different segments, that also addresses those questions: 1. What is the difference between the heap and the mmap areas? (From some tests I was attempting, by looking at the addresses I got from mmap and comparing to the range of the heap in /proc/self/maps, it seems that some mmap allocated pages are actually allocated inside the heap segment.) 2. Does the **break** signifies the end of the **data segment**, or the end of the **heap**? Other related questions: * [how brk pointer grow after calling malloc](https://unix.stackexchange.com/q/610939/273579) * [When is the heap used for dynamic memory allocation?](https://unix.stackexchange.com/q/411408/273579)

I've a qemu/kvm VM started with the option -overcommit mem-lock=on at qemu-system_x86_64 command line on a Linux Ubuntu system. From QEMU documentation and Intel tuning , my understanding is that, as result of that option, the Linux host allocates host *resident* memory for that VM if the host system is not overcommitted. In other words it allocates RAM *resident* pages to support what the guest thinks to be its (guest) physical address space including the memory needed to store the host paging-structures devoted to map such a qemu process's virtual memory. On the Intel based host system supporting VT-x, EPT nested translation is enabled hence the host system builds/maintains a set of EPT paging-structures to map the VM's guest physical addresses (GPA) to machine addresses (HPA). By using trace-cmd on Linux host, I can see many VM-exits due to EPT violations. root@eve-ng62:~# trace-cmd record -e kvm_page_fault -P 1060614 Hit Ctrl^C to stop recording ...... root@eve-ng62:~# trace-cmd report CPU 0 is empty CPU 47 is empty cpus=48 qemu-system-x86-1060614 2316032.840657: kvm_page_fault: vcpu 3 rip 0x7f80ed32638b address 0x00000003f7369712 error_code 0x181 qemu-system-x86-1060614 2316033.325844: kvm_page_fault: vcpu 3 rip 0x7f80ed32638b address 0x00000003f9ce5a12 error_code 0x181 qemu-system-x86-1060614 2316033.709713: kvm_page_fault: vcpu 3 rip 0x7f80ed3251d6 address 0x00000003f72089d0 error_code 0x182 root@eve-ng62:~# I believe the error_code 0x181 and 0x182 actually indicate that the host is loading EPT paging-structures (e.g. PML4, PDPT, PD or PT in case of 4-level EPT) in RAM to map guest accesses to its GPAs. Do you think it could be actually the case ?

Virt Manager configuration: Guest memory usage right after booting (nothing is running): I'm running virt-manager on a standard Ubuntu 17.10 system. In Proxmox, the same general configuration (with ballooning enabled) would allocate 8GB of the host but the guest would have roughly 1-2GB used out of 16GB instead of this. I'm pretty sure I have all the guest drivers installed. (qemu guest, virtio stuff, balloon driver & service) This is not my first QEMU VM, but the only one outside of Proxmox (which I'm assuming does some extra stuff that virt-manager doesn't). What really exacerbates this issue is if I set the **Current allocation** to 2GB, the guest has about 15.6GB compressed and most software won't launch or run correctly because there's no free system memory... ---------- Host: :~$ free -m total used free shared buff/cache available Mem: 32163 20273 8949 176 2940 11325 Swap: 2047 2 2045 Hardly anything is running on the host. It looks like the entire 16GB is getting claimed but simultaneously most of that memory is inaccessible to the guest.

I'm working on a C++ application on Ubuntu 20.04 that uses PCIe DMA to transfer data from a user-space buffer to hardware. The buffer is mapped to a fixed 1K physical memory region via a custom library (plib->copyDataToBuffer). After calling fork() and running a child process (which just calls an external program and exits), I notice that subsequent writes to the buffer by the parent process do not reflect in physical memory—the kernel still sees the old data from before the fork. **Key Details:** The 1K buffer is mapped specifically for DMA; it’s pinned and mapped to a known physical address. Before the fork(), a call to plib->copyDataToBuffer correctly updates physical memory. After the fork(), the parent process calls plib->copyDataToBuffer again with new data, and msync returns success, but the physical memory contents remain unchanged. The child process does not touch the buffer; it only runs an unrelated command via execvp. **My Assumptions & Concerns:** fork() causes COW (Copy-on-Write), but since only the parent writes to the buffer, I expected the updated contents to reflect in physical memory. Could the COW behavior or memory remapping post-fork be interfering with DMA-mapped memory regions? I confirmed that plib->copyDataToBuffer performs the write correctly from a software perspective, but the actual physical memory contents (verified from kernel space) remain stale. **Question:** Why does the physical memory backing my DMA buffer retain stale data after a fork() + exec in a child process, even though the parent writes new data afterward? What are the best practices to ensure consistent physical memory updates for DMA buffers across fork() calls?

I want to obtain the beginning of a memory page, a page that contains a function. In my case I try to achieve the page beginning of main function. Which lies in 0x400a80, I think it is in code section of memory. I would appreciate if you can verify whether it is true or not. As far as I understood, adress 0x400a80 lies in a page. When I show memory segments of my process with pmap, it shows a segment starting with 0x400000 with size 8K, and the next portion goes with 0x601000 with size 4K. I want to obtain adress 0x400000 because it has the address of the main() function. How can I achieve starting adress of a page when I have an adress that resides in that page? Is there any built-in way to do in linux ?

If an allocator requires paging to have been set up already, that means that paging must be setup without an allocator, no? So where is the page table put?

I wrote a simple Python script to scan /proc/{pid}/maps for regions that are writable and executable on my computer. It came up with a few hits surprisingly, all private anonymous. Wondering why a program would ever need writable executable region these days? What are these being used for?

/proc/1286/maps
	 ['/usr/lib/xorg/Xorg\x00:0\x00-seat\x00seat0\x00-auth\x00/var/run/lightdm/root/:0\x00-nolisten\x00tcp\x00vt7\x00-novtswitch\x00']
	 7f5860c03000-7f5860c04000 rwxp 00000000 00:00 0
/proc/2659/maps
	 ['xfwm4\x00--display\x00:0.0\x00--sm-client-id\x002c1781f72-47a5-494a-a3e7-32424563\x00']
	 7ffb7d804000-7ffb7d805000 rwxp 00000000 00:00 0
/proc/404436/maps
	 ['xfce4-terminal\x00--geometry=180x56-0-0\x00']
	 7f44aa15a000-7f44aa18a000 rwxp 00000000 00:00 0
/proc/404436/maps
	 ['xfce4-terminal\x00--geometry=180x56-0-0\x00']
	 7f44aa19b000-7f44aa1fb000 rwxp 00000000 00:00 0
/proc/404436/maps
	 ['xfce4-terminal\x00--geometry=180x56-0-0\x00']
	 7f44aaa5c000-7f44aaa7c000 rwxp 00000000 00:00 0
/proc/404436/maps
	 ['xfce4-terminal\x00--geometry=180x56-0-0\x00']
	 7f44aabba000-7f44aabca000 rwxp 00000000 00:00 0
/proc/404436/maps
	 ['xfce4-terminal\x00--geometry=180x56-0-0\x00']
	 7f44ac736000-7f44ac766000 rwxp 00000000 00:00 0
/proc/407109/maps
	 ['/usr/lib/firefox-esr/firefox-esr\x00-contentproc\x00-childID\x001\x00-isForBrowser\x00-prefsLen\x0037585\x00-prefMapSize\x00265304...']
	 10737c04c000-10737c05c000 rwxp 00000000 00:00 0

Script:

#!/usr/bin/env python3
import sys
import os
import re
import glob
from os.path import dirname, join

def main():
    map_files = list(filter(lambda f: re.match(r'^\d+$', f.split('/')), glob.glob('/proc/*/maps')))
    for map_file in map_files:
        with open(map_file, 'r') as map_f:
            for line in map_f.readlines():  # for each mapped region
                [start, end, perms, offset, dev, inode, pathname] = parse_maps_line(line)
                if 'x' in perms and 'w' in perms:
                    print(map_file)
                    with open(join(dirname(map_file), 'cmdline'), 'r') as cmd_f:
                        print('\t', cmd_f.readlines())
                    print('\t', line.strip())



def parse_maps_line(line):
    ''' The format of the file is:
    address           perms offset  dev   inode       pathname
    00400000-00452000 r-xp 00000000 08:02 173521      /usr/bin/dbus-daemon
    '''
    [address, perms, offset, dev, inode, pathname] = re.split(r'\s+', line, 5)
    [start, end] = address.split('-')
    return [int(start, 16), int(end, 16), perms, int(offset, 16), dev, inode, pathname]


if __name__ == "__main__":
    main()

**UPDATE:** ChatGPT gave a pretty good answer: While generally avoided and discouraged, a region may be writable and executable to support: 1. JIT. 2. Self modifying code. 3. Dynamically loaded code. I'm still interested in understanding specifically why all these processes - Xorg, xfwm4, xfce4-terminal and firefox-esr would need executable regions.

On what basis the size of User and kernel virtual memory is decided in Linux? (32-bit, if that's relevant.) Is it configurable? If we have 512 MB RAM What will be the size of user and kernel virtual address?

When memory is allocated via **kmalloc** (i.e., slab cache allocation like slab_alloc_node), it returns a virtual memory address. Presumably, when accessing this virtual address, the corresponding PTE (which translates the virtual address to a physical address) already exists, enabling address translation because kernel address don't allow page fault. Who creates this PTE, and when is it created? I am using a 64-bit system, not a 32-bit one. In 32-bit systems, I understand that there is a “low memory” region (typically within 1GiB), and that this low memory is pre-mapped to physical memory during boot. However, I’m curious about how this works on 64-bit systems. According to this StackOverflow post (https://stackoverflow.com/questions/30541036/will-physical-addresses-of-all-paging-structures-in-linux-be-mapped-in-the-page) , it says that on 64-bit systems, > “all physical addresses are always mapped with a Supervisor mapping in > the kernel half of the address space.” , And here (https://unix.stackexchange.com/questions/527430/which-processes-page-table-does-vmalloc-allocate-new-memory-in) said > the page table entries for kmalloc have already been allocated. I want to verify whether this is actually true. Here’s why I’m skeptical: suppose my machine has 128GiB of DRAM, and each PTE is 8 bytes. Then, just the page table itself would require 256MiB (128GiB/4KiB * 8Byte). But when I run numastat -m after boot, the size of the PageTable doesn’t appear to be that large. So I wonder what’s really going on.

I have some questions on the Kernel mapping of a Linux process' higher virtual address: 1. Is that maps to the kernel text segment which is stored in the RAM(I read the

will be extracted to the RAM)? 2. What is the use of it? 3. The pmap of a process shows it's mapping to the exe's segments, shared memory,stack,heap. Can I see the higher address kernel mapped also?

I have started to learn about Virtual Address Space (VAS) and I have few questions: 1. How much of VAS is created for each process depending on the architecture (32-bit and 64-bit)? 2. Is VAS for each process created on hard disk? If so, what happens if there is not enough space? 3. What are the contents stored in VAS like text, data, BSS ?

I'm reading a textbook which shows virtual memory as: >Linux also maps a set of contiguousvirtual pages (equal in size to the total amount of DRAM in the system) to the corresponding set of contiguous physical pages. This provides the kernel with a convenient way to access any specific location in physical memory I am a little bit confused here. I think it refers to the second section "Physical memory". but what does it mean by it i is a convenient way to access any specific location in physical memory? if you want to access a specific location, cpu will still have to issue an instruction that has virtual address which can be used by TLB and then a physical address will be produced to access physical memory, so what the "physical memory" section is really for?

I came upon this question : https://unix.stackexchange.com/questions/472223/whats-the-use-of-having-a-kernel-part-in-the-virtual-memory-space-of-linux-proc and based on the answer and the comments on the answer : >the kernel memory map includes a direct mapping of all physical memory, so everything in memory appears there; it also includes separate mappings for the kernel, modules etc., so the physical addresses containing the kernel appear in at least two different mappings Is this true? I couldn't find any source or reference for this, and why would it include a map of the entire physical memory and then again have a separate mapping of kernel modules? Isn't that redundant? Can someone explain in a simple manner what is inside the kernel part of virtual memory of processes in 64-bit Linux? and **please provide a source for the answer**! because I couldn't find anything related to this in any book or paper.

Need to understand virtual memory concept. When a process requesting for 2GB mapping onto the virutal memory in Linux environment of 4GB ( 1GB Kernel : 3GB Userspace), when already another process already holds the mapping for 2 GB. How does the mapping of the stack, heap, data segments all going to happen? I am not able to find any example for my understanding. Text book only mentions separately for each mapping but not a practical approach.

Assumed with a 1 TiB NVMe SSD, I am wondering if it's possible to map its entire capacity (1 TiB) into PCIe BAR for memory-mapped I/O (MMIO). My understanding is that typically only device registers and doorbell registers of an NVMe SSD are mapped to PCIe BAR space, allowing MMIO access. Once the doorbell is triggered, data transfers occur via DMA between system memory and the NVMe SSD. It makes me thinking if is possible to open up the limited size of devices memory/registers for large range MMIO. ALso in this post, NVMe SSDs's CMB (Controller Memory Buffer) is excluded. Given the disparity between the small size of the NVMe SSD's PCIe BAR space and its overall storage capacity, I'm unsure whether the entire SSD can be exposed to the PCIe BAR or physical memory. I'm seeking guidance or clarification on my understanding of PCIe, BAR, and NVMe. --- Here is an example of 1 TiB Samsung 980Pro SSD with only 16K in PCIe BAR:

# lspci -s 3b:00.0 -v
3b:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller PM9A1/PM9A3/980PRO (prog-if 02 [NVM Express])
	Subsystem: Samsung Electronics Co Ltd NVMe SSD Controller PM9A1/PM9A3/980PRO
	Flags: bus master, fast devsel, latency 0, IRQ 116, NUMA node 0, IOMMU group 11
	Memory at b8600000 (64-bit, non-prefetchable) [size=16K]
	Capabilities:  Power Management version 3
	Capabilities:  MSI: Enable- Count=1/32 Maskable- 64bit+
	Capabilities:  Express Endpoint, MSI 00
	Capabilities: [b0] MSI-X: Enable+ Count=130 Masked-
	Capabilities:  Advanced Error Reporting
	Capabilities:  Alternative Routing-ID Interpretation (ARI)
	Capabilities:  Secondary PCI Express
	Capabilities:  Physical Layer 16.0 GT/s 
	Capabilities: [1bc] Lane Margining at the Receiver 
	Capabilities:  Latency Tolerance Reporting
	Capabilities: [21c] L1 PM Substates
	Capabilities: [3a0] Data Link Feature 
	Kernel driver in use: nvme
	Kernel modules: nvme