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>

devicemodel/core/main.c

@@ -64,6 +64,8 @@
 #include "atomic.h"
 #include "vmcfg_config.h"
 #include "vmcfg.h"
+#include "usb.h"
+#include "xhci.h"
 
 #define GUEST_NIO_PORT		0x488	/* guest upcalls via i/o port */
 
@@ -625,6 +627,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);

devicemodel/hw/pci/xhci.c

@@ -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)

devicemodel/include/xhci.h

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