David Hildenbrand <da...@redhat.com> wrote: > On 06.07.23 10:15, Juan Quintela wrote: >> David Hildenbrand <da...@redhat.com> wrote: >>> Already when starting QEMU we perform one system reset that ends up >>> triggering virtio_mem_unplug_all() with no actual memory plugged yet. >>> That, in turn will trigger ram_block_discard_range() and perform some >>> other actions that are not required in that case. >>> >>> Let's optimize virtio_mem_unplug_all() for the case that no memory is >>> plugged. This will be beneficial for x-ignore-shared support as well. >>> >>> Tested-by: Mario Casquero <mcasq...@redhat.com> >>> Signed-off-by: David Hildenbrand <da...@redhat.com> >> It works, so ... >> Reviewed-by: Juan Quintela <quint...@redhat.com> > > Thanks! > > [...] > >>> + bitmap_clear(vmem->bitmap, 0, vmem->bitmap_size); >>> vmem->size = 0; >>> notifier_list_notify(&vmem->size_change_notifiers, &vmem->size); >>> } >>> + >>> trace_virtio_mem_unplugged_all(); >>> virtio_mem_resize_usable_region(vmem, vmem->requested_size, true); >>> return 0; >> Once that we are here. Do you remember _why_ do we allow virtio-mem >> plug/unplug in the middle of a migration. >> We forbid to plug/unplug everything else. Why do we need to >> plug/unplug >> virtio-mem during migration? > > With virtio-mem you tell the VM the desired size for the device > (requested-size), and the VM will select blocks to (un)plug and send > (un)plug requests to the hypervisor in order to reach the requested > size. > > So changing the requested size in the hypervisor (by the QEMU user) > and the VM processing that resize request is asynchronous -- similar > to memory ballooning. > > As the VM can send these (un)plug requests any time, and we exactly > don't want to allow (un)plug during migration, we have > virtio_mem_is_busy() to reject any such requests to tell the VM > "please try again later".
Ahh. I see it now. Thanks, Juan.
