On 1/22/21 4:54 PM, David Hildenbrand wrote:
Am 22.01.2021 um 19:53 schrieb Daniel Henrique Barboza <danielhb413@xxxxxxxxx>:
On 1/22/21 9:50 AM, 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
Code LGTM:
Reviewed-by: Daniel Henrique Barboza <danielhb413@xxxxxxxxx>
Hi,
Let me answer your questions.
Thanks for the reply!
A few questions about the overall design:
- it is mentioned that 'requested-size' should respect the granularity
of the block unit, but later on the 'actual' attribute is added to track
the size that the device was expanded/shrunk. What happens if we forfeit
the granularity check of the memory increments? Will QEMU error out because
we're requesting an invalid value or it will silently size the device to a
plausible size?
QEMU will error out, stating that the request-size has to be properly aligned to the block-size.
'requested-size' granularity check stays then :)
- Reading the lwn article I understood that David implemented this support
for s390x as well. If that's the case, then I believe you should double
check later on what's the THP size that Z uses to be sure that it's the
same 2MiB value you're considering in patch 03.
In the near future we might see arm64 and s390x support. The latter might probably take a bit longer. Both are not supported yet in QEMU/kernel.
Out of curiosity: are you aware of anyone working in enabling virtio-mem
for pseries/ppc64? I'm wondering if there's some kind of architecture
limitation in Power or if it's just a lack of interest.
The QEMU code has an advanced block-size auto-detection code - e.g., querying from the kernel but limiting it to sane values (e.g., 512 MB on some arm64 configurations). Maybe we can borrow some of that or even sense the block size via QEMU? Borrowing might be easier. :)
I guess it's a good candidate for a fancy QMP API.
On x86-64 we are good to go with a 2MB default.
- in patch 03 it is mentioned that:
"If it wants to give more memory to the guest it changes 'requested-size' to
a bigger value, and if it wants to shrink guest memory it changes the
'requested-size' to a smaller value. Note, value of zero means that guest
should release all memory offered by the device."
Does size zero implicates the virtio-mem device unplug? Will the device still
exist in the guest even with zeroed memory, acting as a sort of 'deflated
virtio-balloon'?
Yes, the device will still exist, to be grown again later. Hotunplugging the device itself is not supported (yet, and also not in the near future).
Assuming that virtio-mem has low overhead in the guest when it's 'deflated',
I don't see any urgency into implementing hotunplug for this device TBH.
Thanks,
DHB
Thanks!
