[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH 00/27] vDPA software assisted live migration

From: Stefano Garzarella
Subject: Re: [RFC PATCH 00/27] vDPA software assisted live migration
Date: Fri, 27 Nov 2020 16:44:05 +0100

On Fri, Nov 20, 2020 at 07:50:38PM +0100, Eugenio Pérez wrote:
This series enable vDPA software assisted live migration for vhost-net
devices. This is a new method of vhost devices migration: Instead of
relay on vDPA device's dirty logging capability, SW assisted LM
intercepts dataplane, forwarding the descriptors between VM and device.

In this migration mode, qemu offers a new vring to the device to
read and write into, and disable vhost notifiers, processing guest and
vhost notifications in qemu. On used buffer relay, qemu will mark the
dirty memory as with plain virtio-net devices. This way, devices does
not need to have dirty page logging capability.

This series is a POC doing SW LM for vhost-net devices, which already
have dirty page logging capabilities. None of the changes have actual
effect with current devices until last two patches (26 and 27) are
applied, but they can be rebased on top of any other. These checks the
device to meet all requirements, and disable vhost-net devices logging
so migration goes through SW LM. This last patch is not meant to be
applied in the final revision, it is in the series just for testing

For use SW assisted LM these vhost-net devices need to be instantiated:
* With IOMMU (iommu_platform=on,ats=on)
* Without event_idx (event_idx=off)

Just the notification forwarding (with no descriptor relay) can be
achieved with patches 7 and 9, and starting migration. Partial applies
between 13 and 24 will not work while migrating on source, and patch
25 is needed for the destination to resume network activity.

It is based on the ideas of DPDK SW assisted LM, in the series of
DPDK's https://patchwork.dpdk.org/cover/48370/ .

Comments are welcome.

Hi Eugenio,
I took a look and the idea of the shadow queue I think is the right way.
It's very similar to what we thought with Stefan for io_uring passthrough and vdpa-blk.

IIUC, when the migrations starts, the notifications from the guest to vhost are disabled, so QEMU starts to intercept them through the custom_handler installed in virtio-net (we need to understand how to generalize this). At this point QEMU starts to use the shadows queues and exposes them to vhost. The opposite is done for vhost to guest notifications, where vhost_handle_call is installed to masked_notifier to intercept the notification.

I hope to give better feedback when I get a complete overview ;-)

Anyway, as Jason suggested, we should split this series, so maybe we can merge some preparations patches (e.g. 1, 11, 21, 22) regardless the other patches.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]