Virtualization method of USB (Universal Serial Bus) equipment, in-vehicle infotainment device, medium and product

By adopting the USB device virtualization method based on the Virtio protocol in multi-system devices and using a virtual queue for data transmission, the problem of insufficient USB virtualization performance and flexibility in the prior art is solved, and efficient USB virtualization and zero-copy data transmission are achieved.

CN119987937APending Publication Date: 2025-05-13ZEBRED NETWORK TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411960683.5
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-12-27
Publication Date
2025-05-13

AI Technical Summary

Technical Problem

Existing USB virtualization technologies have shortcomings in performance and flexibility, especially in full virtualization methods and USB over IP-based methods, resulting in performance attenuation and CPU performance loss.

Method used

Using the USB device virtualization method based on the Virtio protocol, a virtual USB front-end driver and a virtual USB back-end are established between the host system and the client system, and a virtual queue mechanism is used to transmit data, realizing a zero-copy data transmission process.

Benefits of technology

Improves the performance of USB virtualization, reduces the loss of CPU performance, and improves system flexibility, supporting hot plugging of USB devices and zero copy of data transmission.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119987937A_ABST
    Figure CN119987937A_ABST
Patent Text Reader

Abstract

The invention discloses a USB device virtualization method, a vehicle, a medium and a product, the method is applied to a multi-system device, the multi-system device comprises a host machine system and a client machine system, the client machine system comprises a virtual USB front-end driver, the host machine system comprises a virtual USB rear end, the virtual USB front-end driver and the virtual USB rear end are constructed based on a Virtio protocol, and the virtual USB front-end driver is connected with the virtual USB rear end. Comprising the following steps: if a USB host driver in a host system identifies a target event for target USB equipment, a virtual USB back end determines whether the target USB equipment is equipment allocated to a client system; if the target USB device is the device allocated to the client system, the virtual USB rear end notifies a virtual USB front end driver of the target event through a virtual queue; and after the virtual USB front-end driver receives the target event, executing a processing step corresponding to the target event. In the scheme, the client system and the host system do not need memory copying during data transmission, so that zero copying of data transmission is realized, and the performance is effectively improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the technical field of virtualization, and in particular to a virtualization method, vehicle, medium and product of a USB device. Background Art

[0002] As virtualization technology becomes more and more popular, many devices already have corresponding virtualization solutions. USB virtualization technology is a technology that virtualizes USB devices into a host or virtual machine, allowing multiple hosts or virtual machines to share devices on the same USB HUB, realizing remote access and sharing of USB devices.

[0003] In the related technology, USB virtualization is usually implemented by full virtualization or USB over IP. Among them, the full virtualization method is to use standard hardware drivers on the virtual machine side and implement USB hardware simulation on the host side, but this method will lead to a large performance degradation. At the same time, due to a large amount of memory access, there is also a certain loss of CPU performance. The USB over IP method is based on TCP / IP network transmission, and its own transmission performance will be affected by network bandwidth. The data of the virtual machine is sent to the host machine, and multiple copies need to be made, which will cause loss of CPU performance and poor flexibility. Therefore, how to better perform USB virtualization is a technical problem that needs to be solved urgently. Summary of the invention

[0004] The embodiments of the present invention provide a virtualization method, a vehicle, a medium and a product of a USB device.

[0005] In a first aspect, an embodiment of the present invention provides a method for virtualizing a USB device, which is applied to a multi-system device, wherein the multi-system device includes a host system and a client system, wherein the client system includes a virtual USB front-end driver, and the host system includes a virtual USB back-end, wherein the virtual USB front-end driver and the virtual USB back-end are constructed based on the Virtio protocol, and the method includes:

[0006] If the USB host driver in the host system identifies a target event for the target USB device, the virtual USB backend determines whether the target USB device is a device assigned to the client system;

[0007] If the target USB device is a device assigned to the client system, the virtual USB backend notifies the virtual USB front-end driver of the target event through a virtual queue;

[0008] After receiving the target event, the virtual USB front-end driver executes processing steps corresponding to the target event.

[0009] In some implementations, the virtual USB backend includes a virtual USB backend service and a virtual host USB driver.

[0010] In some implementations, if the target event is an insertion event of the target USB device, the method further includes:

[0011] If the target USB device is a device assigned to the client system, the virtual USB backend service unbinds the target USB device from the corresponding current USB device driver through the virtual file system interface, and binds the target USB device to the virtual host USB driver;

[0012] The virtual file system is used to provide device information and driver information corresponding to the device information.

[0013] In some implementations, if the target event is an insertion event of the target USB device, after receiving the target event, the virtual USB front-end driver executes processing steps corresponding to the target event, including:

[0014] The virtual USB front-end driver obtains the device description of the target USB device through the virtual queue, and loads the driver of the target USB device to complete the insertion of the target USB device.

[0015] In some implementations, if the target event is an unplugging event of the target USB device, after receiving the target event, the virtual USB front-end driver executes processing steps corresponding to the target event, including:

[0016] After receiving the target event, the virtual USB front-end driver uninstalls the target USB device to complete the removal of the target USB device.

[0017] In some implementations, after the virtual USB front-end driver receives the target event and executes a processing step corresponding to the target event, the method further includes:

[0018] If the virtual USB front-end driver receives a URB data request for the inserted target USB device, the URB data request is placed in the target linked list, and a data sending thread is awakened;

[0019] The client system traverses the target linked list through the data sending thread, puts the URB data corresponding to the traversed URB data request into the virtual queue, and notifies the host system through the interface provided by the virtio-based memory mapping input / output driver.

[0020] In some implementations, after notifying the host system through the interface provided by the virtio-based memory-mapped input / output driver, the method further includes:

[0021] The virtual host USB driver reads the target URB data from the virtual queue, converts the target URB data into a corresponding target URB data request, and submits the target URB data request to the USB subsystem of the host system;

[0022] The USB subsystem of the host system submits the target URB data request to the USB host driver;

[0023] The USB host driver communicates with the target USB device based on the target URB data request.

[0024] In a second aspect, an embodiment of the present invention provides a vehicle computer, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps in the above-mentioned USB device virtualization method when executing the program.

[0025] In a third aspect, an embodiment of the present invention provides a computer-readable storage medium having a computer program stored thereon, which implements the steps in the above-mentioned USB device virtualization method when executed by a processor.

[0026] In a fourth aspect, an embodiment of the present invention provides a computer program product, wherein the computer program product includes a computer program, and when the computer program is executed by a processor, the computer program is used to load and execute the steps in the virtualization method of the USB device mentioned above.

[0027] The above one or at least one technical solution in the embodiments of the present application has at least the following technical effects:

[0028] The USB device virtualization method provided in the embodiment of this specification is applied to a multi-system device, wherein the multi-system device includes a host system and a client system, wherein the client system includes a virtual USB front-end driver, and the host system includes a virtual USB back-end, wherein the virtual USB front-end driver and the virtual USB back-end are constructed based on the Virtio protocol, and when the USB host driver in the host system recognizes a target event for a target USB device, the virtual USB back-end determines whether the target USB device is a device assigned to the client system; if the target USB device is a device assigned to the client system, the virtual USB back-end notifies the virtual USB front-end driver of the target event through a virtual queue; after receiving the target event, the virtual USB front-end driver executes the processing steps corresponding to the target event. This solution implements USB device virtualization based on the Virtio protocol, and since Virtio adopts a mechanism based on a virtual queue for data transmission, no memory copy is required between the client system and the host system, that is, zero copy can be achieved during data transmission, which effectively improves the performance of USB virtualization. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 A schematic diagram of a multi-system device provided in an embodiment of this specification;

[0030] Figure 2 A flowchart of a method for virtualizing a USB device provided in an embodiment of this specification;

[0031] Figure 3 A schematic diagram of allocation of a USB device provided in an embodiment of this specification;

[0032] Figure 4 A flowchart of a target USB device insertion process provided in an embodiment of this specification;

[0033] Figure 5 A flowchart of a process of removing a target USB device provided in an embodiment of this specification;

[0034] Figure 6 A flowchart of a data processing process of a target USB device provided in an embodiment of this specification;

[0035] Figure 7 A schematic diagram of a vehicle computer provided in an embodiment of this specification. DETAILED DESCRIPTION

[0036] The overall idea of ​​the technical solution of the embodiment of the present application is as follows: the multi-system device includes a host system and a client system, the client system includes a virtual USB front-end driver, the host system includes a virtual USB back-end, the virtual USB front-end driver and the virtual USB back-end are constructed based on the Virtio protocol, if the USB host driver in the host system recognizes a target event for a target USB device, the virtual USB back-end determines whether the target USB device is a device assigned to the client system; if the target USB device is a device assigned to the client system, the virtual USB back-end notifies the virtual USB front-end driver of the target event through a virtual queue; after receiving the target event, the virtual USB front-end driver executes processing steps corresponding to the target event.

[0037] The solution of the embodiments of this specification implements USB device virtualization based on the Virtio protocol. Since Virtio adopts a virtual queue-based mechanism for data transmission, no memory copy is required between the client system and the host system, that is, zero copy can be achieved during data transmission, effectively improving the performance of USB virtualization.

[0038] In order to better understand the above technical scheme, the technical scheme of the embodiments of this specification is described in detail below through the accompanying drawings and specific embodiments. It should be understood that the embodiments of this specification and the specific features in the embodiments are detailed descriptions of the technical scheme of the embodiments of this specification, rather than limitations on the technical scheme of this specification. In the absence of conflict, the embodiments of this specification and the technical features in the embodiments can be combined with each other.

[0039] First of all, the term "and / or" in this article is only a description of the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship.

[0040] The USB device virtualization method provided in the embodiments of this specification can be applied to multi-system devices, such as car computers, servers, etc. In order to better understand the USB device virtualization method provided in the embodiments of this specification, the multi-system devices involved in this method are first described. Please refer to Figure 1 , is a schematic diagram of a multi-system device provided in an embodiment of this specification. Figure 1 As shown, the multi-system device includes a host system (Host VM) and a client system (GuestVM). The host system can be a Linux system, and the client system can be a Linux system or an Android system.

[0041] Multi-system devices can adopt the multi-system USB device virtualization solution architecture of Type-1 Hypervisor. Among them, Hypervisor, also known as Virtual Machine Monitor, is an intermediate software layer running between physical hardware and operating system, which can allow multiple operating systems to share a set of basic physical hardware. The types of Hypervisors include Type-1 and Type-2. Type-1 is a bare metal or native Hypervisor, which runs directly on physical hardware and does not depend on the host operating system. Type-2 is a host-type Hypervisor, which runs on the host operating system. The virtualization method of USB devices provided in the embodiments of this specification can adopt Type-1 Hypervisor or Type-2 Hypervisor. For the sake of convenience of explanation, Type-1 Hypervisor is taken as an example in the embodiments of this specification.

[0042] like Figure 1 As shown, the host system includes a virtual USB backend 111, and the client system includes a virtual USB front-end driver (Virtio-USB driver) 121, wherein the virtual USB backend 111 and the virtual USB front-end driver 121 are constructed based on the Virtio protocol. Virtio is a semi-virtualized device simulation standard, which can improve the I / O performance between the client and the host by communicating through the standard Virtio protocol. In some embodiments, the virtual USB backend 111 may include a virtual USB backend service (Virtio-USB backend) 1111 and a virtual host USB driver (vhost USB driver) 1112.

[0043] It should be noted that the virtual USB backend service 1111 can be responsible for the management of USB devices and configure whether the corresponding USB devices are shared with the Guest VM through the configuration file. The virtual USB backend service 1111 can also be responsible for initializing communication with the virtual USB front-end driver 121 and loading the virtual host USB driver 1112.

[0044] The virtual host USB driver 1112 may be a kernel module in the Host VM, and may be responsible for data communication with the virtual USB front-end driver 121 . When the USB device is shared with the Guest VM, all data communication may be processed by the virtual host USB driver 1112 .

[0045] The virtual USB front-end driver 121 is a virtual USB controller driver of the Guest VM. It can establish a virtual roothub and mount all USB devices assigned to the Guest VM on the virtual root hub. When all USB devices mounted on the Guest VM perform data communication, the virtual USB front-end driver 121 can be responsible for docking with the Host VM.

[0046] In addition, if Figure 1 As shown, the Host VM may further include a USB subsystem (USB core driver) 112, a USB host driver (USB Host driver) 113, and a virtual machine monitor module (HYP module) 114. The Guest VM may further include a USB device driver (USB device driver) 122 and a USB subsystem (USB core driver) 123.

[0047] The multi-system device also includes a virtual machine monitor (Hypervisor) 130 and a physical hardware layer (Hardware) 140 .

[0048] like Figure 2 As shown in FIG. 1 , a flowchart of a method for virtualizing a USB device provided in an embodiment of the present specification is applied to a multi-system device, such as a car computer. The multi-system device may include a host system and a client system, the client system includes a virtual USB front-end driver, the host system may include a virtual USB back-end, and the virtual USB front-end driver and the virtual USB back-end may be constructed based on the Virtio protocol. In some embodiments, the architecture of the multi-system device can refer to Figure 1 The USB device virtualization method in the embodiment of this specification may include the following steps:

[0049] Step S201: if the USB host driver in the host system identifies a target event for a target USB device, the virtual USB backend determines whether the target USB device is a device assigned to the client system;

[0050] Step S202: if the target USB device is a device assigned to the client system, the virtual USB backend notifies the virtual USB front-end driver of the target event through a virtual queue;

[0051] Step S203: After receiving the target event, the virtual USB front-end driver executes processing steps corresponding to the target event.

[0052] In step S201, the number of target USB devices can be one or more, such as Figure 3 The figure is a schematic diagram of the allocation of USB devices corresponding to the embodiment of this specification. Figure 3 In the example, there are three USB ports on a USB hub: port0, port1, and port2. The USB device corresponding to port0 is a USB flash drive, the USB device corresponding to port1 is a mouse, and the USB device corresponding to port2 is a keyboard. The USB flash drive is assigned to the host system HostVM, and the mouse and keyboard are assigned to the client system GuestVM. Of course, the allocation of USB devices can be set according to actual needs, and there is no limitation here.

[0053] The target event of the target USB device may include an insertion event, a removal event, etc. In the embodiment of this specification, if the USB host driver in the host system, i.e., the USB Host driver, monitors the target event of the target USB device, it can be reported to the virtual USB backend. In some embodiments, when the USB host driver monitors the target event, it can first send it to the USB subsystem, and the USB subsystem then reports it to the virtual USB backend.

[0054] After the virtual USB backend receives the target event, it can be determined whether the target USB device is a device assigned to the client system. In some embodiments, the virtual USB backend can determine whether the target USB device is a device assigned to the client system through a pre-written configuration file. For example, the configuration file can contain USB device information assigned to each system. By matching the device information of the target USB device with the USB device information in the configuration file, the system to which the target USB device is assigned can be determined. If the target USB device is a device assigned to the client system, the subsequent steps can be continued. If the target USB device is not a device assigned to the client system, such as the target USB device is a device assigned to the host system, the target USB device is processed by the host system.

[0055] It should be noted that the virtual USB backend includes a virtual USB backend service and a virtual host USB driver, and reporting the target event to the virtual USB backend may be reporting the target event to the virtual USB backend service.

[0056] In step S202, when the target USB device is a device assigned to the client system, the target event can be notified to the virtual USB front-end driver in the client system through the virtual queue. The virtual queue (virtqueue) is used for data transmission between the client system and the host system. The virtual queue is a circular queue based on the Ring buffer mechanism. Therefore, no memory copy is required between the client system and the host system, and the performance is better when processing large amounts of data.

[0057] In step S203, after receiving the target event, the virtual USB front-end driver executes the processing steps corresponding to the target event. For example, when the target event is an insertion event, the processing steps corresponding to the insertion event are executed, and when the target event is a removal event, the processing steps corresponding to the removal event are executed. The processing steps corresponding to the target event can be pre-set according to actual needs and are not limited here.

[0058] In some embodiments, if the target event is an insertion event of a target USB device, when the target USB device is a device assigned to a client system, the following steps may also be performed: the virtual USB backend service unbinds the target USB device from the corresponding current USB device driver through a virtual file system interface, and binds the target USB device to the virtual host USB driver; wherein the virtual file system is used to provide device information and driver information corresponding to the device information.

[0059] Specifically, the virtual file system, namely Sysfs provided by Linux, can be used to view the device information of the hardware device, such as driver information, device attributes, etc. In the embodiment of the present specification, the virtual USB backend service unbinds the target USB device from the current USB device driver through the virtual file system interface operation. For example, the target USB device can be written into the unbinding file of the current USB device driver to unbind the target USB device from the current USB device driver, and then the target USB device is written into the binding file of the virtual host USB driver to bind the target USB device to the virtual host USB driver.

[0060] In some embodiments, after the target USB device is bound to the virtual host USB driver, the virtual USB backend service notifies the virtual USB front-end driver of the client system through the virtual queue that a new device has been inserted.

[0061] In some embodiments, when the target event is an insertion event of a target USB device, step S203 can be implemented by the following steps: the virtual USB front-end driver obtains the device description of the target USB device through the virtual queue, and loads the driver of the target USB device to complete the insertion of the target USB device.

[0062] Specifically, the virtual USB front-end driver can obtain information such as the device type and device identification of the target device through the virtual queue, and finally load the driver corresponding to the target USB device, such as the USB device driver, to complete the USB insertion process.

[0063] When the target event is a removal event of the target USB device, step S203 can be implemented by the following steps: after receiving the target event, the virtual USB front-end driver uninstalls the target USB device to complete the removal of the target USB device.

[0064] In an embodiment of the present specification, after the target USB device completes the insertion process, the client system can communicate with the target USB device. In some embodiments, if the virtual USB front-end driver receives a URB data request for the inserted target USB device, the URB data request is placed in a target linked list and a data sending thread is awakened; the client system traverses the target linked list through the data sending thread, places the URB data corresponding to the traversed URB data request into the virtual queue, and notifies the host system through an interface provided by a virtio-based memory mapped input / output driver.

[0065] It should be noted that when the client system needs to read data from the target USB device or write data to the target USB device, it can actively generate a URB (USB Request Block) data request. URB is a data structure used for communication between the USB driver and the USB subsystem. The data processing of the USB device can include four types: control transfer, bulk transfer, interrupt transfer, and isochronous transfer. These data processing types can all be described by URB.

[0066] In some embodiments, when the USB device driver in the client system has data to process, it submits a URB data request to the USB subsystem in the client system, which is then submitted to the virtual USB front-end driver by the USB subsystem. After receiving the URB data request, the virtual USB front-end driver puts it into a target linked list, where the target linked list can be regarded as a local cache that can be used to store URB data requests. At the same time, the virtual USB front-end driver also wakes up the sending thread.

[0067] Furthermore, the virtual USB front-end driver sending thread traverses the target linked list and puts the traversed URB data into the virtual queue. In some embodiments, the URB data is put into the Ring queue of virtqueue, and then the HostVM is notified through the interface provided by the virtio MMIO (virtio Memory Mapped Input / Output, based on virtio memory mapped input / output) driver.

[0068] In an embodiment of the present specification, the virtual host USB driver reads the target URB data from the virtual queue, converts the target URB data into a corresponding target URB data request, and submits the target URB data request to the USB subsystem of the host system; the USB subsystem of the host system submits the target URB data request to the USB host driver; and the USB host driver communicates with the target USB device based on the target URB data request.

[0069] Specifically, the host system can receive the interrupt notification sent by the GuestVM through the HYP module, and notify the virtual host USB driver through a preset event notification mechanism, such as eventfd in the Linux system. Further, the virtual host USB driver processes the Ring queue in the virtqueue, parses the target URB data, converts it into a target URB data request, and submits the URB data request to the USB subsystem. The USB subsystem then sends the target URB data request to the USB host driver, and the USB host driver communicates with the target USB device through the hardware controller.

[0070] In order to better understand the USB device virtualization method provided in the embodiments of this specification, the insertion, removal and data processing process of the target USB device are respectively described below.

[0071] like Figure 4 FIG. 1 is a flowchart of a target USB device insertion process, which includes the following steps:

[0072] Step S401: insert the target USB device;

[0073] Step S402: The USB host driver in the Host VM recognizes an insertion event of the target USB device;

[0074] Step S403: The USB subsystem in the Host VM reports the target USB device insertion event;

[0075] Step S404: the virtual USB backend service in the Host VM determines whether the target USB device needs to be allocated to the Guest VM;

[0076] If yes, execute step S405, if no, execute step S410;

[0077] Step S405: the virtual USB backend service unbinds the target USB device from the current USB device driver through the Sysfs interface, and binds the virtual host USB driver;

[0078] Step S406: the virtual USB backend service notifies the virtual USB front-end driver in the Guest VM through virtqueue that a new device has been inserted;

[0079] Step S407: the virtual USB front-end driver identifies the target USB device;

[0080] Step S408: The virtual USB front-end driver obtains the target USB device description through virtqueue and identifies the specific USB device type:

[0081] Step S409: Load the corresponding USB device driver to complete the USB insertion process;

[0082] Step S410: The Host VM processes the target USB device.

[0083] like Figure 5 FIG. 1 is a flowchart of a process of removing a target USB device, and the process includes the following steps:

[0084] Step S501: unplug the target USB device;

[0085] Step S502: The USB host driver on the HostVM receives a target USB device removal event;

[0086] Step S503: the USB subsystem in the Host VM reports the event of removing the target USB device;

[0087] Step S504: the virtual USB backend service in the HostVM determines whether the target USB device needs to be allocated to the GuestVM;

[0088] If yes, execute step S505, if no, execute step S507;

[0089] Step S505: the virtual USB backend service notifies the virtual USB front-end driver in the Guest VM to remove the target USB device through virtqueue;

[0090] Step S506: the virtual USB front-end driver receives the target USB device removal event and uninstalls the target USB device;

[0091] Step S507: The Host VM uninstalls the target USB device.

[0092] like Figure 6 FIG. 1 is a flowchart of a data processing process of a target USB device, and the process includes the following steps:

[0093] Step S601: The USB device driver in the Guest VM submits a URB data request;

[0094] Step S602: The USB subsystem in the GuestVM sends the URB data request to the virtual USB front-end driver;

[0095] Step S603: the virtual USB front-end driver receives the URB data request, stores it in a linked list, and wakes up the sending thread;

[0096] Step S604: the sending thread of the virtual USB front-end driver traverses the linked list and puts the URB data into the Ring queue of virtqueue;

[0097] Step S605: The Virtio MMIO driver notifies the Host VM;

[0098] Step S606: the HYP module of HostVM receives the interrupt notification of GuestVM and notifies the virtual host USB driver through eventfd;

[0099] Step S607: the virtual host USB driver processes the Ring queue in virtqueue, converts it into a URB data request, and submits it to the USB subsystem in HostVM;

[0100] Step S608: The USB subsystem in the HostVM sends the URB data request to the USB host driver;

[0101] Step S609: The USB host driver communicates with the target device.

[0102] In summary, this specification is a method provided by an embodiment, which performs USB device virtualization based on the Virtio protocol, and uses the Hypervisor to provide a mechanism for sharing memory and interrupt notification between multiple systems, which can ensure that the virtualization solution implemented by the Host VM and the Guest VM is zero-copy during the data transmission process, effectively improving performance. In addition, this solution can filter devices on the Host VM through a configuration file, and only share the USB devices allocated to the Guest VM with the Guest Vm for use. On this basis, hot plugging of USB devices on the Guest VM can also be achieved, which is more flexible.

[0103] Based on the same inventive concept, the embodiment of the present invention further provides a vehicle computer, such as Figure 7 The method comprises a memory 704, a processor 702 and a computer program stored in the memory 704 and executable on the processor 702. When the processor 702 executes the program, any one of the above-mentioned USB device virtualization methods is implemented.

[0104] Among them, Figure 7In the embodiment of the present invention, a bus architecture (represented by bus 700) is shown, which may include any number of interconnected buses and bridges, and bus 700 links various circuits including one or more processors represented by processor 702 and memory represented by memory 704. Bus 700 may also link various other circuits such as peripherals, voltage regulators, and power management circuits, which are well known in the art and are therefore not further described herein. Bus interface 705 provides an interface between bus 700 and receiver 701 and transmitter 703. Receiver 701 and transmitter 703 may be the same element, namely a transceiver, providing a unit for communicating with various other devices over a transmission medium. Processor 702 is responsible for managing bus 700 and general processing, while memory 704 may be used to store data used by processor 702 when performing operations.

[0105] Based on the same inventive concept, an embodiment of the present specification provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the steps of the virtualization method of the USB device are implemented.

[0106] Based on the same inventive concept, an embodiment of this specification provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it is used to load and execute the virtualization method steps of a USB device.

[0107] The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions may be stored as one or more instructions or codes on a computer-readable medium or transmitted via a computer-readable medium. Other examples and implementations are within the scope and spirit of the present invention and the appended claims. For example, due to the nature of software, the functions described above may be implemented using software executed by a processor, hardware, firmware, hard wiring, or a combination of any of these. In addition, each functional unit may be integrated into a processing unit, each unit may exist physically separately, or two or more units may be integrated into one unit.

[0108] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0109] The units described as separate components may or may not be physically separated, and the components of the control device may or may not be physical units, that is, they may be located in one place or distributed in multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0110] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, RandomAccess Memory), mobile hard disk, magnetic disk or optical disk and other media that can store program codes.

[0111] The above description is only an embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and variations. Any modification, equivalent substitution, improvement, etc. made within the spirit and principle of the present invention shall be included in the scope of the claims of the present invention.

Claims

1. A method for virtualizing a USB device, characterized in that: Applied to a multi-system device, the multi-system device includes a host system and a client system, the client system includes a virtual USB front-end driver, the host system includes a virtual USB back-end, the virtual USB front-end driver and the virtual USB back-end are constructed based on the Virtio protocol, and the method includes: If the USB host driver in the host system identifies a target event for the target USB device, the virtual USB backend determines whether the target USB device is a device assigned to the client system; If the target USB device is a device assigned to the client system, the virtual USB backend notifies the virtual USB front-end driver of the target event through a virtual queue; After receiving the target event, the virtual USB front-end driver executes processing steps corresponding to the target event.

2. The method according to claim 1, characterized in that The virtual USB backend includes a virtual USB backend service and a virtual host USB driver.

3. The method according to claim 2, characterized in that If the target event is an insertion event of the target USB device, the method further includes: If the target USB device is a device assigned to the client system, the virtual USB backend service unbinds the target USB device from the corresponding current USB device driver through the virtual file system interface, and binds the target USB device to the virtual host USB driver; The virtual file system is used to provide device information and driver information corresponding to the device information.

4. The method according to claim 1, characterized in that If the target event is an insertion event of the target USB device, after receiving the target event, the virtual USB front-end driver executes processing steps corresponding to the target event, including: The virtual USB front-end driver obtains the device description of the target USB device through the virtual queue, and loads the driver of the target USB device to complete the insertion of the target USB device.

5. The method according to claim 1, characterized in that If the target event is an event of removing the target USB device, after receiving the target event, the virtual USB front-end driver executes processing steps corresponding to the target event, including: After receiving the target event, the virtual USB front-end driver uninstalls the target USB device to complete the removal of the target USB device.

6. The method according to claim 3, characterized in that After the virtual USB front-end driver receives the target event and executes a processing step corresponding to the target event, the method further includes: If the virtual USB front-end driver receives a URB data request for the inserted target USB device, the URB data request is placed in the target linked list, and a data sending thread is awakened; The client system traverses the target linked list through the data sending thread, puts the URB data corresponding to the traversed URB data request into the virtual queue, and notifies the host system through the interface provided by the virtio-based memory mapping input / output driver.

7. The method according to claim 6, characterized in that After notifying the host system through the interface provided by the virtio-based memory-mapped input / output driver, the method further includes: The virtual host USB driver reads the target URB data from the virtual queue, converts the target URB data into a corresponding target URB data request, and submits the target URB data request to the USB subsystem of the host system; The USB subsystem of the host system submits the target URB data request to the USB host driver; The USB host driver communicates with the target USB device based on the target URB data request.

8. A vehicle computer, characterized in that: The method comprises a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the method according to any one of claims 1 to 7 when executing the program.

9. A computer-readable storage medium, characterized in that: A computer program is stored thereon, and when the program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the computer program is used to load and execute the method according to any one of claims 1 to 7.