On Tue, Jun 16, 2015 at 10:05 AM, Jason Wang <jasow...@redhat.com> wrote:
>
>
> On 06/16/2015 03:24 PM, Thibaut Collet wrote:
>> If my understanding is correct, on a resume operation, we have the
>> following callback trace:
>> 1. virtio_pci_restore function that calls all restore call back of
>> virtio devices
>> 2. virtnet_restore that calls try_fill_recv function for each virtual queues
>> 3. try_fill_recv function kicks the virtual queue (through
>> virtqueue_kick function)
>
> Yes, but this happens only after pm resume not migration. Migration is
> totally transparent to guest.
>
Hi Jason,
After a deeper look in the migration code of QEMU a resume event is
always sent when the live migration is finished.
On a live migration we have the following callback trace:
1. The VM on the new host is set to the state RUN_STATE_INMIGRATE, the
autostart boolean to 1 and calls the qemu_start_incoming_migration
function (see function main of vl.c)
.....
2. call of process_incoming_migration function in
migration/migration.c file whatever the way to do the live migration
(tcp:, fd:, unix:, exec: ...)
3. call of process_incoming_migration_co function in migration/migration.c
4. call of vm_start function in vl.c (otherwise the migrated VM stay
in the pause state, the autostart boolean is set to 1 by the main
function in vl.c)
5. call of vm_start function that sets the VM is the RUN_STATE_RUNNING state.
6. call of qapi_event_send_resume function that ends a resume event to the VM
So when a live migration is ended:
1. a resume event is sent to the guest
2. On the reception of this resume event the virtual queue are kicked
by the guest
3. Backend vhost user catches this kick and can emit a RARP to guest
that does not support GUEST_ANNOUNCE
This solution, as solution based on detection of DRIVER_OK status
suggested by Michael, allows backend to send the RARP to legacy guest
without involving QEMU and add ioctl to vhost-user.
Vhost user backend is free to implement one of this two solutions.
The single drawback of these two solutions is useless RARP sending in
some case (reboot, ...). These messages are harmless and probably not
blocking for a "light" patch to support live migration with vhost
user.
If you agree
1. The first patch must be updated by:
- removing the warning trace
- setting the error trace inside a static bool flag to only
print this once
- removing the vhost_net_inject_rarp function (no more useful)
2. The second patch can be removed. Management of legacy guest for
rarp sending can be done by modifications in backend without any
change in QEMU.
Best regards.
Thibaut.
