
I did some test for virtio-mem with libvirt upstream version v7.0.0-153-g5ea3ecd07d & qemu-kvm-5.2.0-0.7.rc2.fc34.x86_64 S1. Start domain with memory device 1. Domain configuration- <maxMemory slots='16' unit='KiB'>10485760</maxMemory> <memory unit='KiB'>1572864</memory> <currentMemory unit='KiB'>1572864</currentMemory> ... <cpu mode='host-model' check='partial'> <numa> <cell id='0' cpus='0-3' memory='1048576' unit='KiB'/> </numa> </cpu> ... <memory model='virtio-mem'> <target> <size unit='KiB'>524288</size> <node>0</node> <block unit='KiB'>2048</block> <requested unit='KiB'>393216</requested> </target> <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> </memory> #virsh start pc Domain 'pc' started 2. The domain is started and check mem status, the actual size is "1048576" #virsh dommemstat pc actual 1048576 swap_in 0 swap_out 0 major_fault 257 minor_fault 130540 unused 604064 available 761328 usable 578428 last_update 1612325471 disk_caches 49632 hugetlb_pgalloc 0 hugetlb_pgfail 0 rss 460260 3. Then, check the active xml - # virsh dumpxml pc ... <memory unit='KiB'>1572864</memory> <currentMemory unit='KiB'>1048576</currentMemory> .... <memory model='virtio-mem'> <target> <size unit='KiB'>524288</size> <node>0</node> <block unit='KiB'>2048</block> <requested unit='KiB'>393216</requested> <actual unit='KiB'>0</actual> </target> <alias name='virtiomem0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> </memory> Question1 : the value of actual is "0". Is it expected? S2. Also, tried to use hugepage to start the domain - <memory model='virtio-mem'> <target> <size unit='KiB'>524288</size> <node>0</node> <block unit='KiB'>2048</block> <requested unit='KiB'>393216</requested> <actual unit='KiB'>0</actual> </target> <alias name='virtiomem0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> </memory> #virsh start pc error: Failed to start domain 'pc' error: internal error: process exited while connecting to monitor: 2021-02-03T05:50:33.157836Z qemu-system-x86_64: -object memory-backend-file,id=memvirtiomem0,mem-path=/dev/hugepages/libvirt/qemu/9-pc,size=536870912,host-nodes=0,policy=bind: can't open backing store /dev/hugepages/libvirt/qemu/9-pc for guest RAM: Permission denied Question 2: any bug here? On Tue, Feb 2, 2021 at 9:44 PM Peter Krempa <pkrempa@redhat.com> wrote:
On Fri, Jan 22, 2021 at 13:50:21 +0100, Michal Privoznik wrote:
Technically, this is another version of:
https://www.redhat.com/archives/libvir-list/2020-December/msg00199.html
But since virtio-pmem part is pushed now, I've reworked virtio-mem a bit and sending it as a new series.
For curious ones, David summarized behaviour well when implementing virtio-mem support in kernel:
https://lwn.net/Articles/755423/
For less curious ones:
# virsh update-memory $dom --requested-size 4G
adds additional 4GiB of RAM to guest;
# virsh update-memory $dom --requested-size 0
removes those 4GiB added earlier.
Patches are also available on my GitLab:
https://gitlab.com/MichalPrivoznik/libvirt/-/tree/virtio_mem_v3
Patches 1-7,9-10 (but observe some individual comments, including the rename of the virsh commands):
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Patch 8 has severe semantic problems.
-- Thanks & Regards, Jing,Qi