How Linux Detects Physical Memory: Inside the E820 BIOS Interface

Firmware Overview

Physical memory appears as DIMM modules with gold fingers, but the kernel discovers them through firmware. The firmware, stored in SPI NOR flash, sits between hardware and the operating system and exposes the ACPI (Advanced Configuration and Power Interface) specification. The latest ACPI version is 6.5 (2022) and can be downloaded from https://uefi.org/sites/default/files/resources/ACPI_Spec_6_5_Aug29.pdf.

Reading Memory Layout from Firmware

During early boot the kernel invokes BIOS interrupt 0x15 with function E820h. The firmware returns a list of physical address ranges, which the kernel stores in boot_params.e820_table. The relevant source files are:

// file: arch/x86/boot/main.c
void main(void)
{
    detect_memory();
    ...
}

// file: arch/x86/boot/memory.c
void detect_memory(void)
{
    detect_memory_e820();
    ...
}

static void detect_memory_e820(void)
{
    struct boot_e820_entry *desc = boot_params.e820_table;
    initregs(&ireg);
    ireg.ax = 0xe820;
    do {
        intcall(0x15, &ireg, &oreg);
        *desc++ = buf;
        count++;
    } while (ireg.ebx && count < ARRAY_SIZE(boot_params.e820_table));
    boot_params.e820_entries = count;
}

After the early boot phase the data are copied into the global e820_table structure defined in arch/x86/kernel/e820.c and printed by e820__print_table. The kernel log can be inspected with dmesg to see entries marked “usable”, “reserved”, “ACPI NVS”, etc.

Global e820 Table and Printing

// file: arch/x86/kernel/e820.c
static struct e820_table e820_table_init __initdata;
struct e820_table *e820_table __refdata = &e820_table_init;

struct e820_table {
    __u32 nr_entries;
    struct e820_entry entries[E820_MAX_ENTRIES];
};

void __init e820__memory_setup(void)
{
    char *who = x86_init.resources.memory_setup();
    pr_info("BIOS-provided physical RAM map:
");
    e820__print_table(who);
}

void __init e820__print_table(char *who)
{
    int i;
    for (i = 0; i < e820_table->nr_entries; i++) {
        pr_info("%s: [mem %#018Lx-%#018Lx] ", who,
                e820_table->entries[i].addr,
                e820_table->entries[i].addr + e820_table->entries[i].size - 1);
        e820_print_type(e820_table->entries[i].type);
        pr_cont("
");
    }
}

Typical dmesg output (truncated) shows the BIOS‑provided map:

BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000002fffffff] usable
BIOS-e820: [mem 0x0000000030000000-0x0000000030041fff] ACPI NVS
... (additional ranges omitted for brevity) ...
BIOS-e820: [mem 0x0000000100000000-0x000000104fefffff] usable

Subsequent Memory Management

The “usable” entries are handed to the early allocator memblock, which reserves the memory during kernel initialization. Once the system is up, memblock transfers the free pages to the buddy allocator. The buddy system manages free memory in power‑of‑two blocks (4 KB, 8 KB, 16 KB, …) and satisfies page‑allocation requests from processes. When a process accesses a virtual address that has no backing physical page, a page‑fault interrupt triggers the buddy allocator to provide a page.