在 2021/7/21 下午7:43, Max Gurtovoy 写道:
Right, vp_vdpa fit naturally for this. But I don't see the much value
of a dedicated migration driver, do you?
I don't know how VDPA device advertise migration capability to QEMU.
This is done by vhost-vDPA via advertising vhost feature
VHOST_F_LOG_ALL, otherwise qemu will block the migration.
vhost-vDPA inherits the vhost uAPI, so at the uAPI level we had:
1) VHOST_SET_VRING_BASE/VHOST_GET_VRING_BASE for syncing index
2) VHOST_SET_LOG_BASE for setting the address of the dirty page bitmap
3) VHOST_VDPA_SET_STATUS for setting the device status
Note that, vhost-vDPA doesn't implement 2) since we're not sure the
dirty page bitmap is the way we need to go for hardware, it would just
take few lines for introducing them in vDPA bus level.
So from vDPA point of view, it's a vhost device. And the vDPA networking
device is driven by the qemu vhost-vDPA module.
Without VHOST_SET_LOG_BASE, Eugenio is working on the shadow virtqueue
for tracking dirty pages in software to live migrate a vDPA device.
Assuming the VHOST_SET_LOG_BASE or other dirty logging mechanism is
implemented, we can live migrate a networking vDPA device with the
hardware assisted dirty page tracking.
For the device state like filters, mac, qemu will intercept the control
command so we don't need any API for querying those states from the
devices. So the above three uAPIs are sufficient for live migrating a
virtio-net vDPA device, and the migration compatibility is kept
perfectly since it was seamlessly integrated with the current vhost
protocol.
When the device/virtio specific mechanism for device state
synchronization is invented, we can introduce uAPI for them.
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
