On 06/18/2015 11:16 PM, Thibaut Collet wrote: > 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
AFAIK, this function sends resume event to qemu monitor not 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. A question here is did vhost-user code pass status to the backend? If not, how can userspace backend detect DRIVER_OK? > > 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. >
