If we use DRIVER_OK status bit to send the RARP by the backend I am afraid that some legacy guest are not supported. Moreover the vhost user backend is not aware of the change of the DRIVER_OK status bit. If this solution is chosen as event to send the RARP a message between QEMU and vhost user backend must be added. If there is a solution to avoid to add a message, i.e a IOCTL, to vhost user backend it will be better (no kernel update). Your solution with the kick on virtual queue seems OK in any case and does not need the add of a message. Except if there are a case where this solution does not work (today I have not found a case) I will prefer to implement this solution.
On Mon, Jun 15, 2015 at 2:45 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Mon, Jun 15, 2015 at 02:12:40PM +0200, Thibaut Collet wrote: >> After a resume operation the guest always kicks the backend for each >> virtual queues. >> A live migration does a suspend operation on the old host and a resume >> operation on the new host. So the backend has a kick after migration. >> >> I have checked this point with a legacy guest (redhat 6-5 with kernel >> version 2.6.32-431.29.2) and the kick occurs after migration or >> resume. >> >> Jason have you an example of legacy guest that will not kick the >> virtual queue after a resume ? > > In practice with sufficiently modern guests you can look > at DRIVER_OK status bit. Process rings if that bit is set. > > -- > MST
