Re: [Qemu-devel] [PATCH] usb-host: insert usb device into hostdevs to be scaned

[linzhecheng]

> -----Original Message-----
> From: gerd hoffmann [mailto:address@hidden
> Sent: Friday, August 17, 2018 2:08 PM
> To: CheneyLin <address@hidden>
> Cc: linzhecheng <address@hidden>; wangxin (U)
> <address@hidden>; address@hidden
> Subject: Re: [Qemu-devel] [PATCH] usb-host: insert usb device into hostdevs to
> be scaned
> 
> > > Why live-migrate to localhost?  That is rather tricky due to both
> > > source and target qemu accessing host resources at the same time,
> > > and I guess this is the reason you are seeing the problems here.
> > Thanks for your reply, but I'm still confused about these issues:
> > 1. If local live migration is not supported for host-usb device, why
> > we have to detach it and rescan it in usb_host_post_load_bh? If a
> > device's property *needs_autoscan* is false, how can we scan it(because we
> have detached it)?
> 
> autoscan is for hotplug.  You can un-plug and re-plug a usb device on the
> physical host, and the guest will see these un-plugs and re-plugs.
> 
> autoscan is turned off in case the usb device is specified using
> hostbus+hostaddr attributes, because hostaddr is a moving target.
> Each time the device is plugged in it gets a different address, for hotplug to
> work properly you must specify the device using attributes which don't change.
> You can use hostport instead of hostaddr for example.
> 
> > 2. Normal live migration between two remote hostes makes a vm access
> > differnt host usb devices, how can we copy states and data of them?
> 
> We don't copy any state.  It is rather pointless, even for save/resume on the
> same machine we don't know what state the usb device has and whenever it is
> still in the state the guest has left it.
I have tried stop/cont a vm with host-usb device during coping large 
files(makes usb device busy woking), 
but usb device was not detached/attached and coping task was completed properly.
 It seems that we can restart it where we left it off.

> 
> So instead we virtually un-plug and re-plug the device, to make the guest 
> driver
> re-initialize the device.
> 
> HTH,
>   Gerd