USB method and apparatus in a virtualization environment with multi-VM

Apparatuses, methods and storage medium associated with virtualizing a USB device controller of a SoC in a computing platform hosting multiple VMs, are disclosed herein. In some embodiments, a CRM includes instructions to implement a USB driver stack in a SOS of a SVM on the computing platform. The USB driver stack of the SOS includes a SOS device controller driver to communicate with one or more USB devices of the computing platform, via a USB device controller of the SoC; and a SOS function virtualization driver to communicate with one or more corresponding UVM function virtualization drivers of the UVMs to paravirtualize the SOS device controller driver to the UVMs. Other embodiments are also described and claimed.

TECHNICAL FIELD

The present disclosure relates to the field of computing. More particularly, the present disclosure relates to Universal Serial Bus (USB) method and apparatus for a virtualization environment with multi-virtual machines (VMs).

BACKGROUND

Universal Serial Bus (USB) has evolved over more than a decade as a ubiquitous interface for connecting peripherals to a computing system. The evolution of USB bus speed in these years started from to 1.5 Mbps in USB 1.1 specification, and evolved to 10 Gbps in the current USB 3.1 specification. With the introduction of USB Type-C port and USB Power Delivery specifications, the USB-C port has extended the USB port functionality to power and display. The USB-C port has been enabled to expand the bandwidth of USB to 20 Gbps with the introduction of USB 3.2 specification, which uses addition signal lines made available by the USB-C ports. USB Class specifications, which define the functionalities above the USB bus also evolved to take advantage of this USB bandwidth increase to provide better user experience and leveraging the capability of the USB bus. Resultantly, USB devices have become ubiquitous in computing.

Virtualization, in computing, is the technology to create virtual versions of hardware and/or software resources to allow the actual hardware and/or software resources to be shared across applications. Increasingly, virtualized platforms are used in many popular applications. For example, emerging automotive systems increasingly employ virtualized platforms. Such a virtualized platform often includes a hardware platform hosting a service virtual machine (VM) and a number of user VMs. The service VM hosts a service operating system (OS) to manage execution of secure and critical functions of the automotive system. Each user VM in turn hosts a user OS to manage execution of any one of a number of non-critical applications, such as infotainment, head unit, dashboard display functions, and so forth. Often the hardware platform employs a system on chip (SoC) having integrated processor, memory, and input/output (I/O) interfaces/ports, including a USB controller supporting one or more USB ports.

In these platforms, at any point in time, the USB controller would be passed through to a particular one of the multitude of OS. When the USB controller is passed through to a particular OS, it limits the possibility of having a reliable high bandwidth plug and play transport for other OS. Further, very often, the USB port is the primary medium for debugging. Limiting the availability of the USB port to a particular OS would limit the debugging capability of such complicated system. In turn, it leads to an almost non-debuggable complicated system. Still further, in some applications, the OS are isolated in different run zones based on the criticality of the functions the OS host, to ensure high availability of resources for the critical functions. One of the key functionality with USB device mode is screen projection (e.g., for Apple Car Play), where USB is used to project a hand held screen to the car's dashboard. With the USB device mode made pass through onto a particular OS supporting critical functionalities, load imbalances may arise.

DETAILED DESCRIPTION

To address challenges discussed in the background section, apparatuses, methods and storage medium associated with provision and operation of USB devices in a virtualization environment having multi-VMs, are disclosed herein. In some embodiments, at least one computer-readable medium (CRM) has stored there in a plurality of instructions to implement a universal serial bus (USB) driver stack in a service operating system (SOS) of a service virtual machine (SVM) on a computing platform having a SoC hosting the SVM and a number of user virtual machines (UVMs), each UVM having a user operating system (UOS). The USB driver stack of the SOS includes at least a SOS device controller driver and a SOS function virtualization driver. The SOS device controller driver is configured to communicate with one or more USB devices of the computing platform, via a USB device controller of the SoC. The SOS function virtualization driver is coupled to the SOS device controller driver to communicate with one or more corresponding UOS function virtualization drivers of the UVMs to paravirtualize the SOS device controller driver to the UVMs. As a result, an application of any one of the UVMs may receive inputs from, or provide outputs to, one of the one or more USB devices, via the UOS function virtualization driver of the one UVM, the SOS function virtualization driver, the SOS device controller driver, and the USB device controller.

In some embodiments, the SOS function virtualization driver is arranged to expose one or more function interfaces to the one or more corresponding UOS function virtualization drivers of the UVMs, in response to exposure of the USB device controller driver into user space of the SOS by the SOS, on enumeration of the USB device controller by the SOS. Additionally, the SOS function virtualization driver is further arranged to accept attachment of one or more functions to the one or more function interfaces from the one or more corresponding UOS function virtualization drivers of the UVMs, in response to exposure of the one or more function interfaces to the one or more corresponding UOS function virtualization drivers of the UVMs. Still further, the SOS function virtualization driver is arranged to propagate the one or more functions attached from the one or more UVMs, to the SOS, on attachment of the one or more functions to the one or more function interfaces exposed by the SOS function virtualization driver.

In some embodiments, the USB driver stack of the SOS further includes one or more SOS USB function drivers, each to provide function-specific support for a function of one of the one or more USB devices in the SOS, and a SOS core composite binder driver coupled to the SOS USB function driver, the SOS function virtualization driver, and the SOS device controller driver to provide cross function support to the SOS USB function drivers and the SOS function virtualization driver in their interactions with the SOS device controller driver.

Aspects of the disclosure are disclosed in the accompanying description. Alternate embodiments of the present disclosure and their equivalents may be devised without parting from the spirit or scope of the present disclosure. It should be noted that like elements disclosed below are indicated by like reference numbers in the drawings.

For the purposes of the present disclosure, the phrase “A and/or B” means (A), (B), or (A and B). For the purposes of the present disclosure, the phrase “A, B, and/or C” means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B and C). The description may use the phrases “in an embodiment,” or “In some embodiments,” which may each refer to one or more of the same or different embodiments. Furthermore, the terms “comprising,” “including,” “having,” and the like, as used with respect to embodiments of the present disclosure, are synonymous.

Referring now toFIG. 1, wherein an overview of an example virtualization environment with multi-VMs having the USB technology of the present disclosure, in accordance with various embodiments, is illustrated. As shown, for the illustrated embodiments, virtualization environment100includes hardware101and software110. Hardware101includes in particular, SoC102and a number of USB devices150coupled to each other as shown. Software110includes hypervisor112hosting a number of VMs, in particular, SVM122having a SOS, and a number of UVMs124a-124b, each having a UOS.

SoC102includes USB device controller130configured to facilitate inclusion of USB devices150in virtualization environment100. In particular, USB device controller130is configured to handle physical layer communications to and from USB devices150to enumerate USB devices150, assign addresses to USB devices150, establish communication pipes (logical channels) with function endpoints of USB devices150, exchange communications over the pipes, and so forth. In embodiments, USB device controller130is configured to handle physical layer communications to and from USB devices150, in accordance with USB Specification 3.x (i.e., 3.2 released September 2017, 3.1 released July 2013, or 3.0 released November 2008) or USB Specification 2.0, released April 2000.

Hypervisor112is configured to virtualize SoC102, and host VM122,124aand124b. Hypervisor112may be any one of a number of hypervisor known in the art, including, but are not limited to, KVM, an open source hypervisor, Xen, available from Citrix Inc., of Fort Lauderdale, Fla., or VMware, available from VMware Inc. of Palo Alto, Calif., and so forth.

Each VM122,124aor124b, more specifically, its OS, includes a USB driver stack to facilitate interaction with USB device controller130, to make available USB devices150in the corresponding VM122,124aor124b. Except for the teaching incorporated in the USB software stack, each OS may be any otherwise be any one of a number of OS known in the art, such as Linux, available e.g., from Red Hat Enterprise of Raleigh, N.C., or Android, available from Google of Mountain View, Calif.

Each USB driver stack includes teachings of the present disclosure, to allow USB device controller130to be virtualized, and thus accessible to VMs122,124aand124b, at the same time, to interact with USB devices150, in a shared/arbitrated manner. In particular, for the illustrated embodiments, each USB driver stack is provided with a function virtualization driver, i.e., SOS function virtualization driver138in the case SOS of SVM122, and UOS function virtualization drivers148aand148bfor UOS of UVM124aand124b, to collaborate to allow USB device controller130to be virtualized, and thus accessible to VMs122,124aand124b, at the same time, to interact with USB devices150, in the shared/arbitrated manner. These and other aspects of the USB technology for virtualization environment with multi-VMs will be further described below with additional references toFIG. 1and references to remainingFIGS. 2-5, after further describing elements of virtualization environment100.

As described earlier, hardware101of virtualization environment100includes SoC102and USB devices150. SoC102includes USB device controller130to facilitate provision of USB devices150to virtualization environment100. Examples of USB devices150may include, but are not limited to, audio devices, communication devices, human interface devices, physical devices, still imaging devices, printer devices, mass storage devices, hubs, smart card devices, content security devices, video devices, personal health care devices, billboard devices, and so forth.

In various embodiments, each USB device150is accessed by a USB address that is assigned when the USB device is attached and enumerated. All USB devices150support a specially designated pipe at endpoint zero to which the USB device's USB control pipe will be attached. All USB devices150support a common access mechanism for accessing information through this control pipe. Associated with the control pipe at endpoint zero is the information required to completely describe the USB device.

This information falls into the following categories:Standard: This is information whose definition is common to all USB devices and includes items such as vendor identification, device class, and power management capability. Device, configuration, interface, and endpoint descriptions carry configuration-related information about the device.Class: The definition of this information varies, depending on the device class of the USB device.USB Vendor: The vendor of the USB device is free to put any information desired here.

USB devices150report their attributes using descriptors. Each descriptor is a tree like data structure with a defined format. A device descriptor describes general information about a USB device150. It includes information that applies globally to the USB device150and all of the device's configurations. A USB device150has only one device descriptor. A configuration descriptor describes information about a specific device configuration. A USB device150may have one or more configuration descriptors. Each configuration has one or more interfaces and each interface may have zero or more endpoints. An endpoint is not shared among interfaces within a single configuration unless the endpoint is used by alternate settings of the same interface. Endpoints may be shared among interfaces that are part of different configurations without this restriction. An interface descriptor describes a specific function within a configuration. An interface may include alternate settings that allow the endpoints and/or their characteristics to be varied after the device has been configured. The default setting for an interface is always alternate setting zero. Each endpoint used for an interface has its own descriptor. This descriptor contains the information required by the host to determine the bandwidth requirements of each endpoint. It should be noted that USB functions are clearly separated from the underlying USB logical or bus activities thus allowing a USB device150to implement multiple function in the same device called a composite USB device. Example of composite devices including, but are not limited to, consumer electronic devices like cameras, printers, mobile phones, and so forth, which uses single USB port to share multiple functions.

Continuing to refer toFIG. 1, in addition to USB device controller130, SoC102may include other embedded components (also referred to as intellectual property, or IP) (not shown). Examples of embedded components may include, but are not limited to, central processing units (CPUs)103, which may be single or multi-core, graphics engine, computer vision (CV) or decision logic (DL) accelerators, flash or other persistent storage, wired or wireless networking controllers, general purpose input/output (GPIO) controllers, storage controllers, memory controller, memory104and so forth. Various portions of memory104may be respectively allocated to the various VMs. In some embodiments, a portion of memory104may be used as shared memory, accessible to all VMs.

In various embodiments, in addition to SoC102and USB devices150, hardware101may include other non-USB hardware elements, e.g., industry standard architecture (ISA) devices, serial advanced technology attachment (SATA) devices, peripheral component interface (PCI) or PCI-express (PCIe) devices, and so forth, with corresponding controllers provided as discrete elements outside of SoC102, or embedded with SoC102. Examples of ISA, SATA and/or PCI/PCIe devices may include, but are not limited to volatile memory devices, mass storage devices, displays, sensors, wired or wireless networking transceivers, and so forth. Examples of sensors may include, but are not limited to, global positioning system (GPS) sensors, gyroscopes, accelerometers, temperature sensors, humidity sensors, light detection and ranging (LiDAR) sensors, and so forth. Wired or wireless networking transceivers may include, but are not limited to, Ethernet, Bluetooth®, WiFi, Long Term Evolution LTE 4G/5G transceivers. Examples of displays may include, but are not limited to, liquid crystal displays (LCD) or light emitting diodes (LED displays. The displays may also be touch sensitive.

It should be noted that the example USB devices and non-USB devices listed are not meant to be mutually exclusive. Various example devices could be implemented with USB support or non-USB support.

Still referring toFIG. 1, in addition to SOS function virtualization driver138, the USB driver stack in SOS of SVM122further includes USB device controller driver132configured to operate USB device controller130. In particular, USB device controller driver132is configured to enumerate USB devices150, assign addresses to USB devices150, establish communication pipes (logical channels) with function endpoints of USB devices150, exchange communications with endpoints of USB devices150over the pipes, and so forth, using USB device controller130. In embodiments, as noted earlier, USB device controller driver132operates USB device controller130in accordance with the protocols of USB Specification 3.x (i.e., 3.2 released September 2017, 3.1 released July 2013, or 3.0 released November 2008) or USB Specification 2.0, released April 2000.

Additionally, each of the USB driver stacks in SOS of SVM122and UOS of UVM124aand124b, includes one or more SOS or UOS function drivers136,148aor148b, and a SOS or UOS core composite binder driver134,144aor144b, communicatively coupled to each other, and to SOS or UOS function drivers136,148aor148band USB device controller driver132(in the case of SOS), as shown. Each SOS or UOS function drivers136,148aor148bis configured to provide function specific support for a specific function of USB devices150in SOS of SVM122or UOS of UVM124a/124b, making the specific function available to the SOS/UOS and applications executed under the control of the SOS/UOS. Examples of specific functions may include, but are not limited, audio functions, video functions, storage functions, printing functions, and so forth. Each SOS or UOS core composite binder driver134,144aor144bis configured to provide cross function support for the functions supported by SOS or UOS function drivers136,148aor148b, to lighten the requirements on SOS or UOS function drivers136,148aand148bto support the corresponding functions. Example of cross function supports may include, but are not limited to, function independent read or write operations.

In various embodiments, SOS function virtualization driver138is configured to communicate with corresponding UOS function virtualization drivers of the UVMs to paravirtualize USB device controller driver132to UVMs124a-124b. More specifically, SOS function virtualization driver138is arranged to expose one or more function interfaces to the one or more corresponding UOS function virtualization drivers148aand148bof the UVMs124a-124b, in response to exposure of USB device controller driver132into user space of the SOS by the SOS, on enumeration of the USB device controller130by the SOS. Additionally, SOS function virtualization driver138is further arranged to accept attachment of one or more functions to the one or more function interfaces from the one or more corresponding UOS function virtualization drivers148a-148b, in response to exposure of the one or more function interfaces to the one or more corresponding UOS function virtualization drivers148a-148b. Still further, SOS function virtualization driver138is arranged to propagate the one or more functions attached from the one or more UVMs124a-124b, to the SOS, on attachment of the one or more functions to the one or more function interfaces exposed by SOS function virtualization driver138. In various embodiments, exposure of the functional interfaces from SVM122to UVM124a-124b, and attachment of functions of UVM124a-124bto the exposed function interfaces may be effectuated via any one of a number of known programmatic techniques, including e.g., but not limited to, via shared memory.

As a result, an application (not shown) of any one of the UVMs124a-124bmay receive inputs from, or provide outputs to, one of the one or more USB devices150, via the UOS function virtualization driver148aor148bof the one UVM124aor124b, SOS function virtualization driver138, USB device controller driver132, and USB device controller130.

Before further describing the USB technology for virtualization environment with multi-VMs, it should be noted that, while for ease of understanding, only two UVM124a-124bare illustrated inFIG. 1, the present disclosure is not so limited. Embodiments of the USB technology ofFIG. 1for virtualization environment with multi-VMs of the present disclosure may be practiced in virtualization environment with any number of multi-VMs, subject only to the ability of the underlying hardware processing power in supporting the number of VMs.

FIG. 2illustrates an overview of another example virtualization environment with multi-VMs having the USB technology of the present disclosure, according to other embodiments. For the illustrated embodiments, virtualization environment200, similar to virtualization environment100, includes hardware201and software210. Similar to hardware101, hardware201includes in particular, SoC202and a number of USB devices250coupled to each other as shown. Similar to software110, software210includes hypervisor212hosting a number of VMs, in particular, SVM222having a SOS, and a number of UVMs224a-224b, each having a UOS.

SoC202, similar to SoC102, includes USB device controller230configured, similar to USB device controller130, to facilitate inclusion of USB devices250in virtualization environment200. In embodiments, USB device controller230, like USB device controller130, is configured to handle physical layer communications to and from USB devices250, in accordance with USB Specification 3.x (i.e., 3.2 released September 2017, 3.1 released July 2013, or 3.0 released November 2008) or USB Specification 2.0, released April 2000.

Hypervisor212, for the illustrated embodiments, includes a number of virtual USB device methods232configured to collectively provide functionalities similar to those provided by USB device controller driver132to control operation USB device controller230, to interact with USB devices250. In various embodiments, virtual USB device methods232include methods for enumerating USB devices250, assign addresses to USB devices250, establish communication pipes (logical channels) with function endpoints of USB devices250, exchange communications with endpoints of USB devices250over the pipes, and so forth. Except for inclusion of virtual USB device methods232, hypervisor212, like hypervisor112, may be any one of a number of hypervisor known in the art, including, but are not limited to, KVM, an open source hypervisor, Xen, available from Citrix Inc., of Fort Lauderdale, Fla., or VMware, available from VMware Inc. of Palo Alto, Calif., and so forth.

Each VM222,224aor224b, more specifically, its OS, like OS of VM122,124aor124b, includes a USB driver stack to facilitate interaction with USB device controller230, to make available USB devices250in the corresponding VM222,224aor224b. Each OS, similar to OS of VM122,124aor124b, may be any one of a number of OS known in the art, such as Linux, available e.g., from Red Hat Enterprise of Raliegh, N.C., or Android, available from Google of Mountain View, Calif.

Each USB driver stack includes teachings of the present disclosure, to allow virtual USB device methods232, to be accessible to VMs222,224aand224b, at the same time, to interact with USB devices250, in a shared/arbitrated manner. In particular, for the illustrated embodiments, similar to the embodiments ofFIG. 1, each USB driver stack is provided with a function virtualization driver, i.e., SOS function virtualization driver238in the case SOS of SVM222, and UOS function virtualization drivers248aand248bfor UOS of UVM224aand224b, to collaborate to allow virtual USB device methods232to be accessible to VMs222,224aand224b, at the same time, to interact with USB devices250, in the shared/arbitrated manner. These and other aspects of the USB technology for virtualization environment with multi-VMs will be further described below with additional references toFIG. 2and references to remainingFIGS. 3-5, after further describing elements of virtualization environment200.

As described earlier, hardware201of virtualization environment200includes SoC202and USB devices250. SoC202, similar to SoC102, includes USB device controller230to facilitate provision of USB devices250to virtualization environment200. Like USB devices150, USB devices250may be any one of a number of USB devices known in the art, in particular, those earlier described example USB devices.

SoC202, similar to SoC102, may include other embedded components (IP) (not shown), in addition to USB device controller230. These embedded components (IP) may likewise be any one of the earlier described example embedded components, in particular, CPU203and memory204. Similar to memory104, various portions of memory204may be respectively allocated to the various VMs. In some embodiments, a portion of memory204may be used as shared memory, accessible to all VMs. In various embodiments, in addition to SoC202and USB devices250, hardware201, like hardware101, may include other non-USB hardware elements, in particular, the earlier described examples.

Continue to refer toFIG. 2, each of the USB driver stacks in SOS of SVM222and UOS of UVM224aand224b, includes one or more SOS or UOS function drivers236,248aor248b, and a SOS or UOS core composite binder driver234,244aor244b, communicatively coupled to each other, and to SOS or UOS function drivers236,248aor248b, as shown. Each SOS or UOS function drivers236,248aor248b, similar to SOS or UOS function drivers136,148aor148b, is configured to provide function specific support for a specific function of USB devices250in SOS of SVM222or UOS of UVM224a/224b, making the specific function available to the SOS/UOS and applications executed under the control of the SOS/UOS. Examples of specific functions may include, but are not limited, to the earlier described examples for USB devices150. Each SOS or UOS core composite binder driver234,244aor244b, similar to SOS or UOS core composite binder driver134,144aor144bis configured to provide cross function support for the functions supported by SOS or UOS function drivers236,248aor248b, to lighten the requirements on SOS or UOS function drivers236,248aand248bto support the corresponding functions. Example of cross function supports may include, the earlier described cross function supports for SOS or UOS core composite binder driver134,144aor144b.

In various embodiments, SOS function virtualization driver238, similar to SOS function virtualization driver138, is configured to communicate with corresponding UOS function virtualization drivers of the UVMs to paravirtualize virtual USB device methods232to UVMs224a-224b. More specifically, SOS function virtualization driver238, similar to SOS function virtualization driver138, is arranged to expose one or more function interfaces to the one or more corresponding UOS function virtualization drivers248aand248bof the UVMs224a-224b, in response to exposure of virtual USB device methods232into user space of the SOS by the SOS, on enumeration of the USB device controller230by the SOS. Additionally, SOS function virtualization driver238is further arranged to accept attachment of one or more functions to the one or more function interfaces from the one or more corresponding UOS function virtualization drivers248a-248b, in response to exposure of the one or more function interfaces to the one or more corresponding UOS function virtualization drivers248a-248b. Still further, SOS function virtualization driver238, similar to SOS function virtualization driver138, is arranged to propagate the one or more functions attached from the one or more UVMs224a-224b, to the SOS, on attachment of the one or more functions to the one or more function interfaces exposed by SOS function virtualization driver238. In various embodiments, exposure of the functional interfaces from SVM222to UVM224a-224b, and attachment of functions of UVM224a-224bto the exposed function interfaces may likewise be effectuated via any one of a number of known programmatic techniques, including e.g., but not limited to, via shared memory.

As a result, an application (not shown) of any one of the UVMs224a-224bmay receive inputs from, or provide outputs to, one of the one or more USB devices250, via the UOS function virtualization driver248aor248bof the one UVM224aor224b, SOS function virtualization driver238, virtual USB device methods232, and USB device controller130.

Similar to the embodiments ofFIG. 1, while for ease of understanding, only two UVM224a-224bare illustrated inFIG. 2, the present disclosure is not so limited. Embodiments of the USB technology ofFIG. 2for virtualization environment with multi-VMs of the present disclosure, may be practiced in virtualization environments with any number multi-VMs, subject only to the capability of the underlying hardware processing power in supporting the number of VMs. Further, in some embodiments, some or all of virtual USB device methods232may be disposed with SoC202instead, as denoted by the dotted line box labelled232.

Referring now toFIG. 3, wherein an example USB process for a virtualization environment with multi-VMs, according to various embodiments, is illustrated. As shown, for the illustrated embodiments, process300for facilitating inclusion of USB devices in a virtualization environment with multi-VMs, allowing the USB devices to be shared and available to all VMs in the virtualization environment, in an arbitrated manner, includes operations at blocks302-312. As will be described, the operations may be performed e.g., by the OS of SVM110/210, SOS USB function virtualization driver138/238, USB device controller driver132and/or virtual USB device methods232.

As shown, for the illustrated embodiments, process300starts at block302. At block302, the USB device controller of the SoC is enumerated, e.g., by the SOS of the SVM, in particular, by the earlier described USB device controller driver of a USB software stack of a SOS of a SVM in the virtualization environment. Next, at block304, the enumerated USB device controller is exposed to the user space (or USB function/class drivers) of the SVM, e.g., by the USB device controller driver of the USB software stack of the SOS to the user space of SOS (or to function/class drivers of the earlier described core composite binder driver of the USB software stack of the SOS).

At block306, a virtualization USB function interface is exposed from the SVM to the UVMs, in response to the exposure of the USB device controller to the user space (or class drivers) of the SVM. For example, a virtualization function interface may be exposed by the earlier described SOS USB function virtualization driver of a USB software stack of the SOS to the earlier described counterpart corresponding UOS USB function virtualization drivers of USB software stacks of the UOS of the UVMs.

At block308, USB functions supported in the UVMs are attached to the virtualization USB function interface, in response to its exposure to the UVMs. For example, the USB functions supported in the UVMs may be attached to the virtualization USB function interface, by the corresponding UOS USB function virtualization drivers of the USB software stacks of the UOS of the UVMs.

At block310, the attached USB functions supported in the UVM are propagated from the virtualization USB function interface to the lower layers of the USB software stack in the SOS of the SVM, in response to their attachments. For example, the earlier described SOS USB function virtualization driver of the USB software stack of the SOS may propagate the attached USB functions supported in the UVM to the core composite binder driver of the USB software stack of the SOS.

At block312, the propagated USB functions supported in the UVM are bound in the USB software stack of the SOS, thus making the USB devices of the virtualization environment available to the UVMs concurrently, in an arbitrated manner. For example, the earlier described core composite binder driver of the USB software stack of the SOS may bind the propagated USB functions supported in the UVM, and couple the propagated USB functions supported in the UVM to the USB device controller driver of the USB software stack of the SOS, or to the earlier described virtual USB device methods of a hypervisor managing the SOS.

Referring now toFIG. 4, wherein an example computing platform that may be suitable for use to practice the present disclosure, according to various embodiments, is illustrated. As shown, computing platform400, which may be hardware101or102ofFIG. 1 or 2, may include one or more system-on-chips (SoCs)402, ROM403and system memory404. Each SoCs402, which may be SoC102or202, may include one or more processor cores (CPUs), one or more graphics processor units (GPUs), one or more accelerators, such as computer vision (CV) and/or deep learning (DL) accelerators. ROM403may include basic input/output system services (BIOS)405. CPUs, GPUs, and CV/DL accelerators may be any one of a number of these elements known in the art. Similarly, ROM403and BIOS405may be any one of a number of ROM and BIOS known in the art, and system memory404may be any one of a number of volatile storage known in the art.

Additionally, computing platform400may include persistent storage devices406. Example of persistent storage devices406may include, but are not limited to, flash drives, hard drives, compact disc read-only memory (CD-ROM) and so forth. Further, computing platform400may include one or more input/output (I/O) interfaces408to interface with one or more I/O devices, such as USB devices420, which may be USB devices150or250. Other example I/O devices may include, but are not limited to, display, keyboard, cursor control and so forth. Computing platform400may also include one or more communication interfaces410(such as network interface cards, modems and so forth). Communication devices may include any number of communication and I/O devices known in the art. Examples of communication devices may include, but are not limited to, networking interfaces for Bluetooth®, Near Field Communication (NFC), WiFi, Cellular communication (such as LTE 4G/5G) and so forth. The elements may be coupled to each other via system bus411, which may represent one or more buses. In the case of multiple buses, they may be bridged by one or more bus bridges (not shown).

Each of these elements may perform its conventional functions known in the art. In particular, ROM403may include BIOS405having a boot loader. System memory404and mass storage devices406may be employed to store a working copy and a permanent copy of the programming instructions implementing the operations associated with hypervisor112/212, service/user OS of service/user VM122/222,124a-124b, and224a-224b, and components of the USB technology of the present disclosure (such as, SOS/UOS USB function drivers136and146a-146b, SOS/UOS function virtualization drivers138/238,148a-148band248a-248b, SOS/UOS USB core composite binder drivers134/234,144a-144band244a-244b, USB driver controller132, and virtual USB device methods230), collectively referred to as computational logic422. The various elements may be implemented by assembler instructions supported by processor core(s) of SoCs402or high-level languages, such as, for example, C, that can be compiled into such instructions.

As will be appreciated by one skilled in the art, the present disclosure may be embodied as methods or computer program products. Accordingly, the present disclosure, in addition to being embodied in hardware as earlier described, may take the form of an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to as a “circuit,” “module” or “system.” Furthermore, the present disclosure may take the form of a computer program product embodied in any tangible or non-transitory medium of expression having computer-usable program code embodied in the medium.FIG. 5illustrates an example computer-readable non-transitory storage medium that may be suitable for use to store instructions that cause an apparatus, in response to execution of the instructions by the apparatus, to practice selected aspects of the present disclosure. As shown, non-transitory computer-readable storage medium502may include a number of programming instructions1204. Programming instructions504may be configured to enable a device, e.g., computing platform400, in response to execution of the programming instructions, to implement (aspects of) hypervisor112/212, service/user OS of service/user VM122/222,124a-124band224a-224b, and components of the USB technology of the present disclosure (such as SOS/UOS USB function drivers136and146a-146b, SOS/UOS function virtualization drivers138/238,148a-148band248a-248b, SOS/UOS USB core composite binder drivers134/234,144a-144band244a-244b, USB driver controller132, and virtual USB device methods232). In alternate embodiments, programming instructions504may be disposed on multiple computer-readable non-transitory storage media502instead. In still other embodiments, programming instructions504may be disposed on computer-readable transitory storage media502, such as, signals.

Thus various example embodiments of the present disclosure have been described including, but are not limited to:

Example 1 is at least one computer-readable medium (CRM) having stored there in a plurality of instructions to implement a universal serial bus (USB) driver stack in a service operating system (SOS) of a service virtual machine (SVM) on a computing platform having a system-on-chip (SoC) hosting the SVM and a number of user virtual machines (UVMs), each UVM having a user operating system (UOS), the USB driver stack of the SOS comprising: a SOS device controller driver to communicate with one or more USB devices of the computing platform, via a USB device controller of the SoC; and a SOS function virtualization driver coupled to the SOS device controller driver to communicate with one or more corresponding UOS function virtualization drivers of the UVMs to paravirtualize the SOS device controller driver to the UVMs; wherein an application of one of the UVMs receives inputs from, or provides outputs to, one of the one or more USB devices, via the UOS function virtualization driver of the one UVM, the SOS function virtualization driver, the SOS device controller driver, and the USB device controller.

Example 2 is example 1, wherein the SOS function virtualization driver is arranged to expose one or more function interfaces to the one or more corresponding UOS function virtualization drivers of the UVMs, in response to exposure of the USB device controller driver into user space of the SOS by the SOS, on enumeration of the USB device controller by the SOS.

Example 3 is example 2, wherein the SOS function virtualization driver is further arranged to accept attachment of one or more functions to the one or more function interfaces from the one or more corresponding UOS function virtualization drivers of the UVMs, in response to exposure of the one or more function interfaces to the one or more corresponding UOS function virtualization drivers of the UVMs.

Example 4 is example 3, wherein the SOS function virtualization driver is further arranged to propagate the one or more functions attached from the one or more UVMs, to the SOS, on attachment of the one or more functions to the one or more function interfaces exposed by the SOS function virtualization driver.

Example 5 is any one of examples 1-4, wherein the USB driver stack of the SOS further comprises: a SOS USB function driver to provide function-specific support for a function of one of the one or more USB devices in the SOS; and a SOS core composite binder driver coupled to the SOS USB function driver, the SOS function virtualization driver, and the SOS device controller driver to provide cross function support to the SOS USB function driver and the SOS function virtualization driver in their interactions with the SOS device controller driver.

Example 6 is example 5, wherein the USB driver stack of the SOS further comprises a USB device controller driver coupled to the SOS core composite binder driver, and arranged to enumerate the one or more USB devices, assign addresses to the one or more USB devices, establish communication pipes with function endpoints of the one or more USB devices, or exchange communications with endpoints of USB devices over the communication pipes.

Example 7 is at least one computer-readable medium (CRM) having stored there in a plurality of instructions to implement a universal serial bus (USB) driver stack in a service operating system (SOS) of a service virtual machine (SVM) on a computing platform having a system-on-chip (SoC), the USB driver stack of the SOS comprising: a SOS function virtualization driver coupled to a SOS device controller driver to communicate with one or more corresponding user operating system (UOS) function virtualization drivers of user virtual machines (UVMs) to paravirtualize a plurality of virtual methods of a USB device controller of the SoC to the UVMs; wherein an application of one of the UVMs receives inputs from, or provides outputs to, one of one or more USB devices, via the UOS function virtualization driver of the one UVM, the SOS function virtualization driver, and the virtual methods of the USB device controller.

Example 8 is example 7, wherein the SOS function virtualization driver is arranged to expose one or more function interfaces to the one or more corresponding UOS function virtualization drivers of the UVMs, in response to exposure of the plurality of virtual methods of the USB device controller of the SoC into user space of the SOS by the SOS, on enumeration of the USB device controller driver by the SOS.

Example 9 is example 8, wherein the SOS function virtualization driver is further arranged to accept attachment of one or more functions to the one or more function interfaces by the one or more corresponding UOS function virtualization drivers of the UVMs, in response to exposure of the one or more function interfaces to the one or more corresponding UOS function virtualization drivers of the UVMs.

Example 10 is example 9, wherein the SOS function virtualization driver is further arranged to propagate the one or more functions attached from the UVMs, to the SOS, on attachment of the one or more functions to the one or more function interfaces exposed by the SOS function virtualization driver.

Example 11 is any one of examples 7-10, wherein the USB driver stack of the SOS further comprises: one or more SOS USB function drivers to provide respective function-specific support for one or more functions of the one or more USB devices in the SOS; and a SOS core composite binder driver coupled to the one or more SOS USB function drivers to provide cross function support to the one or more SOS USB function drivers in their interactions with the SOS function virtualization driver.

Example 12 is an apparatus comprising: a central processing unit (CPU); a universal serial bus (USB) device controller to control one or more USB devices; and a plurality of virtual methods associated with the USB device controller to virtualize the USB device controller for a service virtual machine (SVM) and one or more user virtual machines (UVMs); wherein the USB device controller is virtualized to the one or more UVMs via the SVM, through usage of the virtual methods.

Example 13 is example 12, wherein the plurality of virtual methods include a method for enumerating the one or more USB devices, a method for assigning addresses to the one or more USB devices, a method for establishing communication pipes with function endpoints of the one or more USB devices, or a method for exchanging communications with endpoints of USB devices over the communication pipes.

Example 14 is example 12, wherein the apparatus is a system-on-chip (SoC) and hosts a hypervisor that hosts the SVM and the one or more UVMs, and the USB devices are coupled to a computing platform having the SoC.

Example 15 is example 12, wherein the apparatus is a computing platform having a system-on-chip (SoC) with the CPU, and a hypervisor having the plurality of virtual methods, and hosts the SVM and the one or more UVMs.

Example 16 is a method for operating on a computing platform having a service virtual machine (SVM), one or more user machines (UVMs), and one or more universal serial bus (USB) devices, comprising: exposing, from the SVM, one or more USB function interfaces to the one or more UVMs to paravirtualize a USB device controller disposed on a system-on-chip (SoC) of the computing platform to the one or more UVMs; and accepting attachment of one or more USB functions supported in the UVMs to the one or more USB function interfaces exposed from the SVM; wherein an application of one of the UVMs receives inputs from, or provides outputs to, one of the one or more USB devices, via the one or more USB function interfaces exposed from the SVM, and the USB device controller of the SoC.

Example 17 is example 16, wherein the exposing is performed in response to exposure of the USB device controller into user space of a service operating system (SOS).

Example 18 is example 17, further comprising exposing the USB device controller into the user space of the SOS, on enumeration of the USB device controller.

Example 19 is example 18, further comprising enumerating the USB device controller.

Example 20 is any one of examples 16-19, further comprising propagating the one or more USB functions attached from the one or more UVMs, to the SOS, on attachment of the one or more USB functions to the one or more USB function interfaces exposed.