Re: [virtio-comment] [PATCH V2 2/2] virtio: introduce STOP status bit

[Jason Wang <jasowang@redhat.com>]

å 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