...

                     a. The device MUST set reserved and reserved1 to zero.
                     b. The device MUST set undefined flags to zero.
                     c. The device MUST write a valid endpoint ID in endpoint.
                     d. If a buffer is too small to contain the fault report (this would happen for example if the device implements a more recent version of this specification than the driver, whose fault report contains additional fields) , the device SHALL NOT use multiple buffers to describe it. The device MUST fall back to using an older fault report format that fits in the buffer.

3.5 USB Device

The working group and industry consensus seems to be that it is difficult to give concurrent access to USB hardware from more than one operating system instance.  In other words, to create multiple virtual USB devices that somehow map to a single host role on a single USB port, (or perhaps some kind partitioning of the tree of devices provided when USB hubs are involved).  The host (master) / device (slave) design of the USB protocol makes it challenging to have more than one software stack playing the host role.  Considering how this might be done could be an interesting theoretical exercise but value trade-off does not seem to be there, despite some potential ways it might be used if it were possible (see use-case section).

[VIRTIO] does not in its current version mention USB devices.

After deliberation we have decided also in this specification to assume that hypervisors will provide only pass-through access to USB hardware.

The ability for one VM to request dedicated access to the USB device during runtime is a potential improvement and it ought to be considered when choosing a hypervisor.   With such a feature, VMs could even alternate their access to the USB port with a simpler acquire/release protocol than a true full virtualization would use (note Use-case section for caveats).

USB On-The-Go(tm) is left out of scope, since most automotive systems implement the USB host role only, and in the case a system ever needs to have the device role it would surely have a dedicated port and a single operating system instance handling it.

 The configuration of pass-through for USB is yet not standardized and for the moment considered a proprietary API.  This is a potential for future improvement.

Hardware support for virtualization

It seems likely that trying to implement special support for splitting a single host port, between multiple guests is more complicated than just approaching it as multiple ports.  This applies also  if the hardware implements not only host controllers but also a USB-hub.  In other words, SoCs are likely better off simply providing support for more separate USBs at the same time than to build in special virtualization features.

 Is there anything in particular the hardware should do to facilitate pass-through?

Requirements

Configurable pass-through access to USB devices.

 REQ-3.5-1:   The hypervisor shall provide statically configurable pass-through access to all hardware USB devices

Resource API for USB devices

 REQ-3.5-2:   The hypervisor may optionally provide an API/protocol to request USB access from the virtual machine, during normal runtime.

Use Case discussion

There is a case to be made for more than one VM needing access to a single USB device.  For example, a single mass-storage device (USB memory) may be required to provide files to.  There are many potential use cases but just as an example, consider software/data update files that need to be applied to more than one VM/guest, or media files being played by one guest system whereas navigation data is needed in another.

In the previous chapter, the idea of alternating/reconfiguring pass-through access was raised without defining it further.  It should be noted of course that it raises many considerations about reliability and one system starving the other of access.  Such a solution would only apply if policies, security and other considerations are met for the particular system.

The most likely remaining solution, considering that virtualized USB access is not a promoted solution, is that one VM is assigned to be the USB master and provide access to the filesystem (or part of it) by means of VM-to-VM communication.  For example, a network file system such as NFS or any equivalent solution could be used.

4. Special Virtual Device categories

...

For digital I/O pins, refer to standard pinmux specification ( need clarification) 

4.x Audio

4.x Media codec 

...