What Is the Linux Kernel Virtual Address Space?

Every process running on Linux sees two regions in its virtual address space: the user space and the kernel space. The user space is where your program’s code, data, heap, and stack live. The kernel space is where the Linux kernel itself resides — its code, data structures, driver memory, and mapped hardware registers.

The kernel virtual address space (kernel VAS), sometimes called the kernel segment, is the portion of the address space reserved exclusively for the kernel. On a 32-bit system, user space and kernel space together must fit within 4 GB. On a 64-bit system this constraint effectively disappears because the address space is astronomically large (128 TB per side on x86-64).

Understanding the kernel VAS is critical if you are writing Linux device drivers or kernel modules as part of your free Linux kernel development journey, because any memory your driver allocates or maps comes from inside this kernel segment.

The VM Split on 32-bit Systems — Why It Matters for Linux Kernel Development

On a 32-bit processor, the entire virtual address space is only 4 GB. The Linux kernel must share this limited space with user processes. This sharing is controlled by a compile-time constant called PAGE_OFFSET (also referred to as CONFIG_PAGE_OFFSET). Everything at or above PAGE_OFFSET is kernel space; everything below is user space.

The classic split on 32-bit x86 and ARM systems is 3 GB user / 1 GB kernel, where PAGE_OFFSET = 0xC000 0000. Some embedded boards (Raspberry Pi 3B+ running 32-bit Linux, for example) use a 2 GB / 2 GB split because they need more kernel-addressable RAM, setting PAGE_OFFSET = 0x8000 0000. The split you use affects how much physical RAM the kernel can directly address without tricks like highmem.

Inside the Kernel Segment — Key Memory Regions

The kernel segment is not one flat blob of memory. It is divided into distinct regions, each serving a different purpose. Knowing these regions is essential for anyone studying our free Linux device drivers course, because different kernel APIs for memory allocation come from different regions.

Deep Dive — Each Kernel Segment Region Explained

1. Lowmem — The Direct-Mapped RAM Region

The lowmem region is the most important part of the kernel segment. It is a direct, linear mapping of physical RAM into the kernel’s virtual address space. Every physical page of RAM in lowmem has a corresponding kernel virtual address (called a kernel logical address) that is simply PAGE_OFFSET + physical_address.

Because the mapping is fixed and simple, the kernel can instantly convert between a physical address and a kernel logical address. This is why kmalloc() and kzalloc() — the most common kernel memory allocators you will use in your Linux device drivers — allocate from this region. The memory they give you is physically contiguous, which is required for DMA on many platforms.

/* Converting between kernel logical address and physical address */
/* These macros work ONLY in the lowmem region */

virt_to_phys(kva)   /* kernel logical address → physical address */
phys_to_virt(pa)    /* physical address → kernel logical address */

/* Example */
void *ptr = kmalloc(64, GFP_KERNEL);
phys_addr_t pa = virt_to_phys(ptr);  /* get physical address of your allocation */

2. Highmem Region — Only on 32-bit

On 32-bit systems where physical RAM exceeds the lowmem size (e.g., more than 896 MB of RAM on a 3:1 split kernel), the excess physical pages cannot be permanently mapped into the kernel’s limited virtual address space. This overflow zone is called highmem.

To access highmem pages, the kernel uses temporary mappings (via kmap() and kmap_atomic()) that borrow fixmap or pkmap slots. This is slow and complex. Modern 64-bit kernels have no highmem at all — all physical RAM is directly mapped.

3. Vmalloc Region — Virtually Contiguous, Not Physically Contiguous

The vmalloc region provides virtually contiguous memory that may be scattered across many non-contiguous physical pages. When the kernel (or a driver) needs a large allocation that does not need to be physically contiguous, it uses vmalloc() to draw from this region.

This region is also used by ioremap() — one of the most commonly used functions in Linux device driver development. When you write a driver for a memory-mapped peripheral (like a UART, SPI controller, or custom FPGA), you call ioremap() to map the hardware’s physical register base address into the kernel’s vmalloc region so your driver code can access it.

/* ioremap — mapping hardware registers in a device driver */
/* This is from the vmalloc region, NOT lowmem              */

#define MY_UART_BASE  0x48020000UL   /* physical base of UART registers */
#define MY_UART_SIZE  0x1000         /* 4 KB register block */

void __iomem *base;

base = ioremap(MY_UART_BASE, MY_UART_SIZE);
if (!base) {
    pr_err("ioremap failed\n");
    return -ENOMEM;
}

/* Read/write registers using readl/writel, NOT direct pointer deref */
u32 val = readl(base + 0x00);
writel(0x01, base + 0x04);

iounmap(base);  /* always unmap in driver remove/exit */

4. Kernel Modules Region

When you run insmod mydriver.ko, the kernel loads your module’s code and data into the kernel modules region. On ARM-32, this region sits just below PAGE_OFFSET and is typically 16 MB in size. On x86-64, modules have their own dedicated region near the kernel text.

The reason modules get their own region (rather than just loading into vmalloc) is that on 32-bit ARM, the branch instruction’s reach is limited — a module too far from the core kernel text cannot branch to kernel functions. Keeping modules close to the kernel text, just below PAGE_OFFSET, ensures all branch distances stay within range.

5. Fixmap Region

The fixmap region holds a set of fixed virtual addresses — virtual addresses that the kernel reserves at compile time for special purposes. These include boot-time console output mappings, kmap slots for highmem page access, and early hardware mappings needed before the full memory subsystem is initialised. As a driver developer you will rarely interact with the fixmap region directly.

Kernel VAS on Modern 64-bit Linux (Kernel v6.x)

Today almost all production Linux systems run 64-bit kernels. The memory layout is fundamentally more generous and simpler. Here is how the kernel segment looks on a modern x86-64 system running Linux 6.x:

Inspecting the Kernel VAS on Your Own Linux System

You do not need to write a kernel module to get a first look at your kernel’s memory layout. The Linux kernel exposes some information through /proc on most configurations.

Using /proc/iomem

/proc/iomem shows the physical address ranges that the system has reserved for RAM, device registers, BIOS, and so on. This is not the virtual layout, but it tells you how much physical RAM and which I/O regions exist.

# View physical memory and IO regions
$ cat /proc/iomem

# Sample output on x86-64 (simplified):
00000000-00000fff : Reserved
00001000-0009fbff : System RAM
00100000-bfffffff : System RAM
100000000-23fffffff : System RAM   ← RAM above 4 GB
fee00000-fee00fff : Local APIC

Using /proc/vmallocinfo

/proc/vmallocinfo shows all current allocations in the vmalloc region, including ioremap mappings made by drivers. This is extremely useful when debugging a driver — you can verify that your ioremap() call actually created a mapping and see its virtual address range.

# Show all vmalloc/ioremap allocations
$ sudo cat /proc/vmallocinfo

# Each line: virtual_start-virtual_end  size  caller  flags
0xffffa12300000000-0xffffa12300002000    8192 ioremap+0x... phys=0xfe000000 ioremap

Using /proc/buddyinfo and /proc/meminfo

/proc/meminfo gives you a high-level picture of overall memory usage including MemTotal, MemFree, Cached, and importantly VmallocTotal, VmallocUsed, and VmallocChunk.

$ grep -i vmalloc /proc/meminfo

VmallocTotal:   34359738367 kB   ← Total vmalloc region size (huge on 64-bit)
VmallocUsed:        45312 kB    ← Currently used by drivers/kernel
VmallocChunk:           0 kB    ← Largest free contiguous chunk

Writing a Kernel Module to Display Memory Layout — Free Linux Kernel Development Exercise

The most educational exercise in our free Linux kernel development course is writing a small LKM (Loadable Kernel Module) that prints the kernel’s own segment boundaries. Below is a complete, working example that compiles on modern kernels (tested on 5.15 LTS and 6.x). This uses only standard kernel headers — no dependency on any book-specific code.

// vas_info.c — Print kernel virtual address space boundaries
// Works on Linux kernel 5.15+ (LTS) and 6.x
// Free Linux Kernel Development Course — EmbeddedPathashala

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/mm.h>
#include <linux/vmalloc.h>
#include <asm/pgtable.h>

MODULE_LICENSE("GPL");
MODULE_AUTHOR("EmbeddedPathashala");
MODULE_DESCRIPTION("Print Kernel VAS boundaries");
MODULE_VERSION("1.0");

static int __init vas_info_init(void)
{
    pr_info("=== Kernel VAS Info (EmbeddedPathashala) ===\n");

    /* PAGE_OFFSET: start of kernel direct-mapped RAM (lowmem start) */
    pr_info("PAGE_OFFSET (lowmem start)  : 0x%016lx\n", PAGE_OFFSET);

    /* TASK_SIZE: top of user virtual address space */
    pr_info("TASK_SIZE (user VAS top)    : 0x%016lx\n", TASK_SIZE);

#ifdef CONFIG_X86_64
    pr_info("VMALLOC_START               : 0x%016lx\n", VMALLOC_START);
    pr_info("VMALLOC_END                 : 0x%016lx\n", VMALLOC_END);
#endif

    pr_info("MODULES_VADDR               : 0x%016lx\n", MODULES_VADDR);
    pr_info("MODULES_END                 : 0x%016lx\n", MODULES_END);

    pr_info("Kernel text start           : 0x%016lx\n",
            (unsigned long)_text);
    pr_info("Kernel text end             : 0x%016lx\n",
            (unsigned long)_etext);
    pr_info("Kernel data end (BSS end)   : 0x%016lx\n",
            (unsigned long)_end);

    pr_info("=== End of VAS Info ===\n");
    return 0;
}

static void __exit vas_info_exit(void)
{
    pr_info("vas_info: module removed\n");
}

module_init(vas_info_init);
module_exit(vas_info_exit);

Makefile for the Module

# Makefile — for vas_info.c
obj-m += vas_info.o

KDIR := /lib/modules/$(shell uname -r)/build

all:
	make -C $(KDIR) M=$(PWD) modules

clean:
	make -C $(KDIR) M=$(PWD) clean

Build and Test

# Install kernel headers first
$ sudo apt install linux-headers-$(uname -r)

# Build the module
$ make

# Insert the module
$ sudo insmod vas_info.ko

# Read the output
$ dmesg | tail -20

# Remove the module
$ sudo rmmod vas_info

Common Mistakes When Working with Kernel Memory

void *vp = vmalloc(4096);
phys_addr_t pa = virt_to_phys(vp);  /* WRONG — undefined result */

void *kp = kmalloc(4096, GFP_KERNEL);
phys_addr_t pa = virt_to_phys(kp);  /* CORRECT — kmalloc gives lowmem addr */

Key Takeaways — Linux Kernel Virtual Address Space

Frequently Asked Questions — Linux Kernel Memory Layout

Conclusion

Understanding the Linux kernel virtual address space is not just academic — it directly shapes every memory-related decision you make when writing Linux device drivers or kernel modules. Knowing that kmalloc() gives you physically contiguous lowmem (great for DMA), while vmalloc() and ioremap() live in the vmalloc region (great for large or hardware-register mappings), is the difference between a correct driver and a subtly broken one.

In our next tutorial from this free Linux kernel development course, we will go deeper into the user-space side of the VAS — Virtual Memory Areas (VMAs), how the kernel tracks them in the mm_struct, and how to walk a process’s memory map from inside a kernel module. If you found this tutorial helpful, share it with others who are learning Linux kernel programming or taking our free Linux device drivers course on EmbeddedPathashala.