I did some research regarding max VM memory allocation. Finding is that the memory limitation for KVM VMs is min(mmap can give, 1T). So in general, that's going to be the amount of virtual memory mmap can give unless the host has huge amount of physical memory/turns on blind memory overcommitment/has huge swap space. Below is some technical details on how this limitation is determined.
The amount of physical memory that can be allocated to a guest is capped by the amount of virtual memory that the associated qemu process can obtain - https://github.com/qemu/qemu/blob/stable-2.0/util/oslib-posix.c#L119 (pc_init -> pc_memory_init -> memory_region_init_ram -> qemu_ram_alloc -> qemu_ram_alloc_from_ptr -> qemu_anon_ram_alloc). So the problem comes to how much memory mmap can allocate before it gives ENOMEM, which is determined by the overcommit setting, physical memory size, swap size, and current memory usage.
On the other side, the guest physical address space size also affects the total amount of memory the VM can consume. The guest OS will find a vcpu’s physical address width by executing CPUID with 80000008H in EAX. With KVM this is set to be 40 bits for x86-64 cpus, even though EPT supports 48 bits guest physical address width. So the guest can address up to 1T memory in its physical address space.
For all the x86 cpus that kvm supports - https://github.com/qemu/qemu/blob/stable-2.0/target-i386/cpu.c#L592, if it's 64 bits, the cpu will have 48 bits virtual, 40 bits physical address width - https://github.com/qemu/qemu/blob/stable-2.0/target-i386/cpu.c#L2344. For 32 bits cpus, they can have 36 bits or 32 bits physical address width depending on the presence of PAE, but I think the customer will not be interested in the information about 32 bits cpus.
Qemu passes the cpuid information to the kernel - https://github.com/qemu/qemu/blob/stable-2.0/target-i386/kvm.c#L706, and the cpuid information will eventually be used to emulate cpuid instruction by KVM - https://github.com/torvalds/linux/blob/v3.13/arch/x86/kvm/emulate.c#L3279 (em_cpuid -> emulator_get_cpuid -> emulator_get_cpuid -> kvm_find_cpuid_entry).
Note, above information applies to linux kernel 3.13 and qemu 2.0.
The amount of physical memory that can be allocated to a guest is capped by the amount of virtual memory that the associated qemu process can obtain - https://github.com/qemu/qemu/blob/stable-2.0/util/oslib-posix.c#L119 (pc_init -> pc_memory_init -> memory_region_init_ram -> qemu_ram_alloc -> qemu_ram_alloc_from_ptr -> qemu_anon_ram_alloc). So the problem comes to how much memory mmap can allocate before it gives ENOMEM, which is determined by the overcommit setting, physical memory size, swap size, and current memory usage.
On the other side, the guest physical address space size also affects the total amount of memory the VM can consume. The guest OS will find a vcpu’s physical address width by executing CPUID with 80000008H in EAX. With KVM this is set to be 40 bits for x86-64 cpus, even though EPT supports 48 bits guest physical address width. So the guest can address up to 1T memory in its physical address space.
For all the x86 cpus that kvm supports - https://github.com/qemu/qemu/blob/stable-2.0/target-i386/cpu.c#L592, if it's 64 bits, the cpu will have 48 bits virtual, 40 bits physical address width - https://github.com/qemu/qemu/blob/stable-2.0/target-i386/cpu.c#L2344. For 32 bits cpus, they can have 36 bits or 32 bits physical address width depending on the presence of PAE, but I think the customer will not be interested in the information about 32 bits cpus.
Qemu passes the cpuid information to the kernel - https://github.com/qemu/qemu/blob/stable-2.0/target-i386/kvm.c#L706, and the cpuid information will eventually be used to emulate cpuid instruction by KVM - https://github.com/torvalds/linux/blob/v3.13/arch/x86/kvm/emulate.c#L3279 (em_cpuid -> emulator_get_cpuid -> emulator_get_cpuid -> kvm_find_cpuid_entry).
Note, above information applies to linux kernel 3.13 and qemu 2.0.
2984
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
