解决qemu虚拟机中内存偏小的问题

问题描述：
最近测试部报了一个问题，云平台中设置大于4GB的内存并设置numa，启动linux2.6.32内核的客户机，之后操作系统中查看实际内存是1.9G，比设置内存小了大概2.1GB。

使用版本信息如下：
QEMU version: 3.0.0
guest os kernel version: 2.6.32
host kernel version: 4.9.0

问题排查如下：
1）在系统中排查问题
通过如下命令查看60系统下内存槽硬件信息，说明内存卡硬件识别正常：

$ dmidecode -t memory

通过$ free -m查看，系统识别出来却有问题：

通过测试如下命令启动QEMU虚拟机必然复现该问题：

$ qemu-system-x86_64 -enable-kvm -name guest=vm1,debug-threads=on -machine pc-i440fx-2.6,accel=kvm,usb=off,dump-guest-core=off -cpu Westmere -m size=4194304k,slots=16,maxmem=16777216k -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -numa node,nodeid=0,cpus=0 -uuid fd3535db-2558-43e9-b067-314f48211343 -no-user-config -rtc base=localtime -no-shutdown -boot menu=on,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/opt/issue32/generic.qcow2,format=raw,if=none,id=drive-ide0-0-0 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -spice port=5900,addr=0.0.0.0,disable-ticketing,seamless-migration=on -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x4 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 -msg timestamp=on

(这里的slots为16，所以先抛下一个问题：“为什么实测slots为3的时候不会出现2.1G的内存占用？”)
2）接下来在2.6.32内核源码中排查该问题：
通过debug发现是bootmem释放未占用的内存到buddy内存系统的时候少了2.1G，接下来继续研究bootmem的内存分配。

setup_node_bootmem->init_bootmem_node->free_boot_mem_with_active_regions->early_res_to_bootmem(这里干的好事)

bootmem是系统初始化期间的临时内存分配系统，通过位图来标识内存占用，bootmem自身的初始化很简单，首先将位图所有位置1，表示所有页已保留，之后通过free_boot_mem_with_active_regions将可用页帧置0，而free_boot_mem_with_active_regions中会调用early_res_to_bootmem将early_res分配器占用的内存页继承到bootmem中来，early_res是在bootmem之前更早的内存分配器，排查发现是early_res分配器使用过程中占用了2.1G的内存页，而bootmem继承了它导致未释放至buddy子系统。
因此继续向前排查，在这里发现了问题：

start_kernel->setup_arch->initmem_init->acpi_scan_nodes->compute_hash_shift->allocate_cachealigned_memnodemap->reserve_early

CONFIG_ACPI_NUMA确定此选项后内核会编译acpi_numa_init函数，获取numa支持，从硬件系统的acpi表中得到物理硬件的nodes信息，ACPI是在系统启动阶段由BIOS/UEFI收集各方面信息并创建的。而2.1G的内存分配正是在allocate_cachealigned_memnodemap中通过reserve_early完成的。
allocate_cachealigned_memnodemap分配的大小计算如下：

static int __init allocate_cachealigned_memnodemap(void)
{
	。。。
	nodemap_size = roundup(sizeof(s16) * memnodemapsize, L1_CACHE_BYTES);
	。。。
	reserve_early(nodemap_addr, nodemap_addr + nodemap_size, "MEMNODEMAP");
	。。。
}

memnodemapsize定义如下：

#define memnodemapsize memnode.mapsize

而memnode.mapsize的计算和设置是在compute_hash_shift->extract_lsb_from_nodes中完成的：

/*
 * The LSB of all start and end addresses in the node map is the value of the
 * maximum possible shift.
 */
static int __init extract_lsb_from_nodes(const struct bootnode *nodes,
					 int numnodes)
{
	int i, nodes_used = 0;
	unsigned long start, end;
	unsigned long bitfield = 0, memtop = 0;

	for (i = 0; i < numnodes; i++) {
		start = nodes[i].start;
		end = nodes[i].end;
		if (start >= end)
			continue;
		bitfield |= start;
		nodes_used++;
		if (end > memtop)
			memtop = end;
	}
	if (nodes_used <= 1)
		i = 63;
	else
		i = find_first_bit(&bitfield, sizeof(unsigned long)*8);
	memnodemapsize = (memtop >> i)+1;
	return i;
}

extract_lsb_from_nodes中将所有内存节点的start值进行了一个位或。之前埋下过一个问题也可以解释了“为什么slots为3的时候不会出现2.1G的内存reserve？”其实答案在于最后memnodemapsize = (memtop >> i)+1中，将unsigned long转换成了unsigned int，而i=0，直接导致了高32位的精度丢失，而在slot=3的时候恰好1全在高32位上面，导致mapsize=1，因此没有内存占用。所以这里又可以抛出一个问题了 ;）
(为什么内存区域会随着slots个数而变化？)

node区域范围有如下四个：
a） 0-655,360
b）1,048,576-3,221,225,472
c）4,200,000,000-5,300,000,000
d）35,433,480,192-35,433,480,191
最后一个区域范围恰好是hotplug的内存区域范围，很明显这里的hotplug区域范围有问题，怎么可能只有1。由于start只比end小1,也就直接导致了根据start位与计算的memnodemapsize值偏大，并且还出现了精度丢失！

好了，现在知道问题的直接导致是热插拔内存区设置的有问题，但是为什么会有问题？ hotplug内存区参数是怎么读取的，之后想起开机启动的时候好像也报了和hotplug区相关的问题：

系统启动过程报hotplug区的过小，而hotplug参数也是来自于SRAT表的解析，SRAT(静态资源亲和性表)是ACPI规范的一部分，SRAT表解析流程如下：

start_kernel->setup_arch()->acpi_numa_init()->acpi_table_parse_srat()->acpi_table_parse_entries()
->acpi_parse_memory_affinity()->acpi_numa_memory_affinity_init()->update_nodes_add()

update_nodes_add函数中：

    if ((signed long)(end - start) < NODE_MIN_SIZE) {
        printk(KERN_ERR "SRAT: Hotplug area too small\n");
        return;
    }

这里的SRAT表是前期BIOS存放在内存中的，其根本来源还是qemu。

3）因此就开始了在qemu源码中排查问题的旅途
qemu中建立SRAT表的流程：

main->qemu_run_machine_init_done_notifiers->notifier_list_notify->pc_machine_done->acpi_setup->acpi_build->build_srat

build_srat是构建SRAT表的函数，其中有：

    if (hotplugabble_address_space_size) {
        build_srat_hotpluggable_memory(table_data, machine->device_memory->base,
                                       hotplugabble_address_space_size,
                                       pcms->numa_nodes - 1);
    }

这里的hotplug memory的基址是machine->device_memory->base=5,368,709,120，这个数值从前面的区域范围表中看起来是合理的，为什么这个base addr进入虚拟机后就变成
35,433,480,191了？

    ram_addr_t hotplugabble_address_space_size =
            object_property_get_int(OBJECT(pcms), PC_MACHINE_DEVMEM_REGION_SIZE,
                                		   NULL);

往前看，前面获取的hotplugaable_address_space_size=30064771072恰好是(35,433,480,192 - 5,368,709,120)，也就是说end地址传入虚拟机是正确的。

最终在如下代码段找到了问题所在，在info为null是，build_srat_memory设置的start=end-1，size=1，和虚拟机中读取到的完全相符，看来是这里导致的该bug。

static void build_srat_hotpluggable_memory(GArray *table_data, uint64_t base,
                                           uint64_t len, int default_node)
{
    MemoryDeviceInfoList *info_list = qmp_memory_device_list();
    MemoryDeviceInfoList *info;
。。。
    for (cur = base, info = info_list;
         cur < end;
         cur += size, info = info->next) {
        numamem = acpi_data_push(table_data, sizeof *numamem);

        if (!info) {
            build_srat_memory(numamem, end - 1, 1, default_node,
                              MEM_AFFINITY_HOTPLUGGABLE | MEM_AFFINITY_ENABLED);
            break;
        }
。。。

通过参考最新版的的代码以及老版本(2.x)的代码稍作修改即可。

PS：这里其实也可以通过设置device模型为pc-dimm，让info不为null，比如如下：

-numa node -object memory-backend-ram,policy=default,size=4G,id=mem-mem1 -device pc-dimm,node=0,id=dimm-mem1,memdev=mem-mem1

#）
这里最后再解释下为什么内存区域会随着slots个数而变化：
hotplugin内存区域初始化流程如下：

main->machine_run_board_init->pc_init_v3_0->pc_init1->pc_memory_init

如下可知device_mem_size = max_size - ram_size + 1G * slots

device_mem_size = machine->maxram_size - machine->ram_size
        if (pcmc->enforce_aligned_dimm) {
            /* size device region assuming 1G page max alignment per slot */
            device_mem_size += (1 * GiB) * machine->ram_slots;
        }

device_mem_size = 12G(16G-4G) + 1G * 16(slots) = 28G(30064771072)。这里的1G * slots是考虑到大页对齐的问题，支持单页最大1G。所以hotplug区域也会随着slots而变化。