On 30.06.20 12:06, Michael S. Tsirkin wrote:
> On Fri, Jun 26, 2020 at 09:22:37AM +0200, David Hildenbrand wrote:
>> This is the very basic/initial version of virtio-mem. An introduction to
>> virtio-mem can be found in the Linux kernel driver [1]. While it can be
>> used in the current state for hotplug of a smaller amount of memory, it
>> will heavily benefit from resizeable memory regions in the future.
>>
>> Each virtio-mem device manages a memory region (provided via a memory
>> backend). After requested by the hypervisor ("requested-size"), the
>> guest can try to plug/unplug blocks of memory within that region, in order
>> to reach the requested size. Initially, and after a reboot, all memory is
>> unplugged (except in special cases - reboot during postcopy).
>>
>> The guest may only try to plug/unplug blocks of memory within the usable
>> region size. The usable region size is a little bigger than the
>> requested size, to give the device driver some flexibility. The usable
>> region size will only grow, except on reboots or when all memory is
>> requested to get unplugged. The guest can never plug more memory than
>> requested. Unplugged memory will get zapped/discarded, similar to in a
>> balloon device.
>>
>> The block size is variable, however, it is always chosen in a way such that
>> THP splits are avoided (e.g., 2MB). The state of each block
>> (plugged/unplugged) is tracked in a bitmap.
>>
>> As virtio-mem devices (e.g., virtio-mem-pci) will be memory devices, we now
>> expose "VirtioMEMDeviceInfo" via "query-memory-devices".
>>
>> --------------------------------------------------------------------------
>>
>> There are two important follow-up items that are in the works:
>> 1. Resizeable memory regions: Use resizeable allocations/RAM blocks to
>> grow/shrink along with the usable region size. This avoids creating
>> initially very big VMAs, RAM blocks, and KVM slots.
>> 2. Protection of unplugged memory: Make sure the gust cannot actually
>> make use of unplugged memory.
>>
>> Other follow-up items that are in the works:
>> 1. Exclude unplugged memory during migration (via precopy notifier).
>> 2. Handle remapping of memory.
>> 3. Support for other architectures.
>
> Question: I see that this does not check qemu_balloon_is_inhibited -
> is that because this works with VFIO, somehow?
> Or is this an oversight?
I use the new
if (ram_block_discard_require(true)) {
error_setg(errp, "Discarding RAM is disabled");
return;
}
in virtio_mem_device_realize. This will assure that incompatible
technologies (esp. VFIO) are inhibited and are not able to become active
as long as virtio-mem is around.
virtio_mem_is_busy() handles migration/postcopy, indicating "busy" while
migration is temporarily active.
(qemu_balloon_is_inhibited() is no more since "[PATCH v5 06/21]
virtio-balloon: Rip out qemu_balloon_inhibit()")
--
Thanks,
David / dhildenb
