DM USB: add some preparing time for xHCI emulation before resuming.

If the USB kernel drives and devices of SOS are not available and
functional ready after UOS is resumed from frozen state, the comming
USB command from UOS will cause a disaster because the DM has no
resourse to to emulation.

This patch add a dynamic time span (could change according to number
of native USB devices attached) to give USB drivers and devices of
SOS an opportunity to be ready.

Tracked-On: #1893
Signed-off-by: Xiaoguang Wu <xiaoguang.wu@intel.com>
Reviewed-by: Liang Yang <liang3.yang@intel.com>
Acked-by: Yu Wang <yu1.wang@intel.com>
This commit is contained in:
Xiaoguang Wu 2018-11-20 17:08:32 +08:00 committed by wenlingz
parent b159d66fb3
commit 9d4b5d7e1b
3 changed files with 23 additions and 0 deletions

View File

@ -66,6 +66,8 @@
#include "vmcfg.h"
#include "tpm.h"
#include "virtio.h"
#include "usb.h"
#include "xhci.h"
#define GUEST_NIO_PORT 0x488 /* guest upcalls via i/o port */
@ -631,6 +633,7 @@ vm_suspend_resume(struct vmctx *ctx)
vm_stop_watchdog(ctx);
wait_for_resume(ctx);
wait_for_xhci_resume();
pm_backto_wakeup(ctx);
vm_reset_watchdog(ctx);

View File

@ -485,6 +485,24 @@ static struct pci_xhci_option_elem xhci_option_table[] = {
{"cap", pci_xhci_parse_extcap}
};
void
wait_for_xhci_resume()
{
/* The reason of waiting for resuming is USB virtualization
* needs do TWO PASS SEQUENTIAL enumerations: one for SOS and
* the other for UOS after SOS USB resuming work is completely
* done. So, theoretically, virtual USB resuming MUST use more
* time than its native counterpart.
*/
/* FIXME: will substitute it by dynamic way. The thought is
* waiting time is calculated by the number of USB devices
* attached. More devices, more waiting time, no device no
* waiting.
*/
sleep(5);
}
static int
pci_xhci_get_free_vport(struct pci_xhci_vdev *xdev,
struct usb_native_devinfo *di)

View File

@ -377,4 +377,6 @@ struct xhci_event_ring_seg {
volatile uint32_t dwEvrsReserved;
};
void wait_for_xhci_resume();
#endif /* _XHCI_H_ */