Re: [PATCH 00/10] Introduce virtio-mem <memory/> model
Am 22.01.2021 um 19:53 schrieb Daniel Henrique Barboza
<danielhb413(a)gmail.com>:
> 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(a)gmail.com>
Hi,
Let me answer your questions.
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.
- 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.
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. :)
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).
Thanks!