Re: [PATCH 00/10] Introduce virtio-mem <memory/> model
On 1/22/21 6:19 PM, David Hildenbrand wrote:
> 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.
I remember there is interest, however:
- arm64 and x86-64 is used more frequently in applicable (cloud?) setups, so it has high
prio
- s390x doesn‘t have any proper memory hot(un)plug, and as I have a strong s399x
background, it‘s rather easy for me to implement
- ppc64 at least supports hot(un)plug of DIMMs
There is nothing fundamental speaking against ppc64 support AFAIR.
That's good to hear.
A block size of 16MB should be possible. I‘m planning on looking into
it, however, there are a lot of other things on my todo list for virtio-mem.
I'm not familiar with the 'block size' concept of the virtio-mem device that
would
allow for 16MB increments. My knowledge of the pseries kernel/QEMU is that the
guest visible memory must always be 256MiB aligned due to PAPR mechanics that
forces a memory block to be at least this size. Albeit I believe that there is
no constraints of the memory this device is providing being counted as
non-hotplugable, then in this case the alignment shouldn't be needed.
But I digress. Thanks for the insights. I'll ping some people inside IBM and
see if we have a more immediate use case for virtio-mem in Power. Perhaps
we can do some sort of collaboration with your work.
Thanks,
DHB
>
>
>> 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.
>
One can at least query the block-size via „qom-get“, but that requires to spin up an QEMU
instance with a virtio-mem device.
>
>> 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.
There are still things to be optimized in QEMU regarding virtual memory consumption, but
that‘s more general work to be tackled within the next months. After that, not too much
speaks against just letting the device stick around to provide more nemory later on
demand.
Thanks!