Maximum memory is the memory the guest is booted on - but it can't use all of it if current memory is capped at a lower value.
Some examples:
- maximum memory = current memory = 4G: the guest is booted with 4G attached, and can use all of it (minus some RAM which is mapped/excluded by the emulated platform itself)
- maximum memory = 8G, current memory = 4G: the guest is booted with 8G attached, but it find that 4G (max-cur) is actually reserved by the kernel (via the virt-balloon driver), so it can only use 4G (cur) at most.
This kind of reservation is to avoid hot-adding memory, which is more difficult than booting with more memory and claiming back / mark as no-use some part of the memory itself.
When observing your qemu-system-x86_64 processes from task manager (or ps or top) you only see the memory actually used by the guest (plus some memory needed for the emulator itself): for example, booting a basic linux kernel + userspace can be done with ~256M and, if no process are running inside the guest, you will see such low memory utilization for the emulator process itself (even if the guest has 4G of current / maximum memory assigned). In other words, linux kernel allocation is a copy-on-write affair: it is not done one-shot, but on actual demand by the kernel/userspace.
Caveat: Windows guests zeroes all memory at startup, effectively forcing a complete host-side memory allocation (up to current memory) at guest startup.
