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.