[Qemu-devel] why guest memory size not equal to my setting?

[Qemu-devel] why guest memory size not equal to my setting?

[=?gb18030?B?xNA2wfrLq0E=?=]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 4477 bytes --]

Hello Qemu-devel,

Recently I'm trying to study vm memory allocation on qemu-kvm environment.
I found some interesting here:

I have create a 8GB(8388608 k) memory guest using Centos 7. but when I using dmesg to show the init memory,
it was 9437184 k,around 9216MB. I would like to know the gap?

I know qemu will init two memory region:
system_memory = g_malloc(sizeof(*system_memory));
and system_io = g_malloc(sizeof(*system_io));

Does those gap point to the region of system_io ?


Below is my environment.  


[root@qi-jiong-ming-test ~]# dmesg |grep Memory
[    0.000000] Memory: 7372140k/9437184k available (6244k kernel code, 1049100k absent, 1015944k reserved, 4178k data, 1604k init)


virsh # qemu-monitor-command 4 --hmp info version
2.1.2 (qemu-kvm-ev-2.1.2-23.el7.1)

qemu      201492       1  0 Jun02 ?        01:06:42 /usr/libexec/qemu-kvm -name instance-0000632f -S -machine pc-i440fx-rhel7.1.0,accel=kvm,usb=off -cpu Haswell,+abm,+pdpe1gb,+rdrand,+f16c,+osxsave,+dca,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme,-rtm,-hle -m 8192 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 75e1234c-6c56-42e1-ae45-190a090bfc04 -smbios type=1,manufacturer=Fedora Project,product=OpenStack Nova,version=12.0.5-2.el7.centos.ustack,serial=d83d324e-0a6c-4336-9d40-dd8f97783ede,uuid=75e1234c-6c56-42e1-ae45-190a090bfc04,family=Virtual Machine -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-instance-0000632f/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive file=rbd:pool-c261dc1709484e01b533156506aab091/75e1234c-6c56-42e1-ae45-190a090bfc04_disk.config:auth_supported=none:mon_host=55.3.53.19\:6789\;55.3.53.59\:6789\;55.3.53.99\:6789,if=none,id=drive-ide0-1-1,readonly=on,format=raw,cache=writeback -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 -drive file=rbd:pool-c261dc1709484e01b533156506aab091/volume-e2924c66-9815-46d5-9a01-af355a333975:auth_supported=none:mon_host=55.3.53.19\:6789\;55.3.53.59\:6789\;55.3.53.99\:6789,if=none,id=drive-virtio-disk0,format=raw,serial=e2924c66-9815-46d5-9a01-af355a333975,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=rbd:pool-c261dc1709484e01b533156506aab091/volume-e7e96136-ad57-44a0-925e-0c59f6bd878a:auth_supported=none:mon_host=55.3.53.19\:6789\;55.3.53.59\:6789\;55.3.53.99\:6789,if=none,id=drive-virtio-disk1,format=raw,serial=e7e96136-ad57-44a0-925e-0c59f6bd878a,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=rbd:pool-c261dc1709484e01b533156506aab091/volume-8cdf28d4-c4f7-4b9c-9dfc-8fc55d1b8692:auth_supported=none:mon_host=55.3.53.19\:6789\;55.3.53.59\:6789\;55.3.53.99\:6789,if=none,id=drive-virtio-disk2,format=raw,serial=8cdf28d4-c4f7-4b9c-9dfc-8fc55d1b8692,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk2,id=virtio-disk2 -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:a7:3d:de,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/var/lib/nova/instances/75e1234c-6c56-42e1-ae45-190a090bfc04/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/org.qemu.guest_agent.0.instance-0000632f.sock,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on


virsh # dominfo instance-0000632f
Id:             4
Name:           instance-0000632f
UUID:           75e1234c-6c56-42e1-ae45-190a090bfc04
OS Type:        hvm
State:          running
CPU(s):         4
CPU time:       4003.0s
Max memory:     8388608 KiB
Used memory:    8388608 KiB
Persistent:     yes
Autostart:      disable
Managed save:   no
Security model: none
Security DOI:   0


Thanks in advance.

Re: [Qemu-devel] why guest memory size not equal to my setting?

[Paolo Bonzini]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1235 bytes --]

On 10/06/2017 15:54, ÄÐ6ÁúË«A wrote:
> Hello Qemu-devel,
> 
> Recently I'm trying to study vm memory allocation on qemu-kvm environment.
> I found some interesting here:
> 
> I have create a 8GB(8388608 k) memory guest using Centos 7. but when I using dmesg to show the init memory,
> it was 9437184 k,around 9216MB. I would like to know the gap?

> I know qemu will init two memory region:
> system_memory = g_malloc(sizeof(*system_memory));
> and system_io = g_malloc(sizeof(*system_io));
> 
> Does those gap point to the region of system_io ?

No, these are two different address spaces.  Guest RAM is allocated by
memory_region_allocate_system_memory as a single region of the size you
specified.

The guest memory map doesn't place all the memory contiguously.  For the
"pc" machine type, from 3GB to 4GB there is a hole for memory mapped
registers of PCI devices.  Linux reports this hole as "absent" memory:

[    0.000000] Memory: 7372140k/9437184k available (6244k kernel code,
1049100k absent, 1015944k reserved, 4178k data, 1604k init)

Note that Linux 3.11 or newer doesn't report absent pages anymore
(commit 46a841329a6c, "mm/x86: prepare for removing num_physpages and
simplify mem_init()", 2013-07-03).

Thanks,

Paolo