VirtIO interface-based ubiquitous hardware equipment virtualization support method

Abstract

The invention provides a VirtIO interface-based ubiquitous hardware equipment virtualization supporting method and system, according to a VirtIO interface standard, bottom layer physical hardware is abstracted into virtual equipment, a VirtIO virtual equipment driver is divided into a front end and a rear end, data interaction is carried out through a sharing mechanism to form a virtual hardware abstraction layer, and the virtual hardware abstraction layer is used for supporting virtual hardware. Upwards providing state information of virtual equipment and interface information of operation equipment for an application program, shielding heterogeneity of bottom-layer physical equipment, and downwards butting local and / or far-end physical equipment to carry out actual I / O operation; and calling a migration interface through the virtual hardware abstraction layer, establishing a link with a far-end virtual device driver, transmitting the state of the local virtual device to a far end, and recovering and reconstructing the virtual device by the far-end driver. According to the method, heterogeneous hardware in a ubiquitous scene can obtain more efficient resource abstraction and management, the resource utilization rate is improved, and meanwhile the resource dynamic configuration and flexible expansion capacity is provided.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer virtualization, ubiquitous computing and device driving, in particular to a ubiquitous hardware device virtualization support method based on VirtIO interface standard for heterogeneous hardware devices in ubiquitous scenarios, and relates to a corresponding system, computer terminal and computer readable storage medium. BACKGROUND

[0002] Ubiquitous Operating Systems (UOS) is a new type of operating system proposed for the "human-machine integration" ubiquitous computing environment, including robot operating system, Internet of Things operating system, artificial intelligence operating system, smart city operating system and industrial control operating system, etc. UOS retains the core elements of traditional operating systems: resource virtualization and functional programmability, and is generalized and extended in the ubiquitous computing scenario. One of the prominent features of the ubiquitous scenario is that it covers a variety of processors, memories, and various performance and power-constrained sensors and actuators, etc. hardware devices, with characteristics of wide distribution, resource constraints, high heterogeneity and fragmentation, which also brings challenges to the current ubiquitous operating system. On the one hand, the hardware resources are diverse and the computing scenarios are complex in the ubiquitous computing environment, and there is still a lack of effective resource abstraction methods and technologies, which limits the full use of heterogeneous hardware resources. On the other hand, the numerous devices in the ubiquitous environment are generally different from the traditional computing environment in terms of performance, power consumption and real-time performance, which also puts forward new demands for the resource abstraction technology and method of the ubiquitous operating system.

[0003] Virtualization technology is a technology that abstracts physical hardware resources into virtual form. Its advantage is to realize flexible sharing and management of resources and improve hardware utilization. Heterogeneous resource virtualization is the extension and extension of virtualization technology in ubiquitous computing environment. The introduction of virtualization technology provides a possible solution for efficient resource abstraction and management in ubiquitous computing scenarios. Its resource abstraction and flexible expansion characteristics are also suitable for the needs of ubiquitous computing scenarios. Traditional device virtualization technology is aimed at traditional operating systems and mainly abstracts and virtualizes the management of resources such as block devices, network devices, and PCI buses. In the ubiquitous scenario, virtualization technology is applied to industrial internet, embedded devices, and vehicle systems, which need to face complex heterogeneous hardware resources, including I2C, CAN bus protocols widely used in industrial and vehicle scenarios, various GPIO devices in embedded scenarios, and programmable logic controllers (PLC) in industrial control scenarios. The diversity of ubiquitous scenarios puts forward differentiated needs for virtualization technology, and the heterogeneity of hardware resources makes it difficult for traditional virtualization technology to establish a unified, generalized, and flexible virtualization support method. Existing solutions mostly use static configuration, abstract bus, and hardware-assisted virtualization technologies to realize virtualization support for heterogeneous hardware resources, but still face many challenges in scalability, flexibility, and cloud-edge collaboration.

[0004] VirtIO interface is a set of virtual device driver implementation standards proposed to optimize the performance of traditional I / O virtualization. VirtIO interface decouples device drivers into front-end and back-end, with the front-end running in the guest and the back-end running in the host, and the two interacting through shared memory space and shared queue Virtqueue. VirtIO interface modifies the guest kernel, sacrificing part of the isolation to gain better I / O performance, and has become the current mainstream device virtualization scheme. VirtIO interface is almost available for common devices in ubiquitous scenarios (such as VirtIO-GPU / VirtIO-keyboard / VirtIO-i2c / VirtIO-SPI / VirtIO-camera / VirtIO-GPIO, etc.), and even high-level infrastructure such as file systems and memory systems (such as VirtIO-fs / VirtIO-mem, etc.), with broad adaptability. The introduction of VirtIO interface standard can make the implementation of ubiquitous operating system virtualization more unified and standardized.

[0005] Most of the existing resource virtualization technologies of ubiquitous hardware devices still do not use VirtIO standard for implementation, and have some deficiencies in uniformity, universality and scalability. Meanwhile, the existing virtualization abstraction methods of ubiquitous hardware resources still focus on the abstraction and management of local resources, and less hardware resources in remote and cloud are included in the unified management level, and the migration and dynamic aggregation of virtual devices are not concerned, and the existing VirtIO standard interface does not concern the migration of devices and other cross-border operations, which limits the capability range of ubiquitous computing applications. SUMMARY

[0006] The present application provides a ubiquitous hardware device virtualization support method based on VirtIO interface, and simultaneously provides a corresponding system, computer terminal and computer readable storage medium.

[0007] According to one aspect of the present application, a ubiquitous hardware device virtualization support method based on VirtIO interface is provided, comprising:

[0008] According to VirtIO interface standard, the underlying physical hardware is abstracted as a virtual device, and VirtIO virtual device driver is divided into a front end and a back end, the front end and the back end are located in the same operating system, are divided into virtual operating system and host operating system, or are divided into local operating system and remote or cloud operating system, and data interaction is performed between the two through a sharing mechanism;

[0009] Based on the front end and the back end, a virtual hardware abstraction layer across the system boundary of a VirtIO driving level is formed, the virtual hardware abstraction layer provides state information of a virtual device and interface information of an operating device for an application program upwardly, and hides the heterogeneity of the underlying physical device; the virtual hardware abstraction layer downwardly connects the local and / or remote or cloud physical device to perform actual I / O operation;

[0010] Through a migration interface of the virtual hardware abstraction layer, a link with a remote or cloud virtual device driver is established, and the state of a local virtual device is transmitted to the remote or cloud, and the remote or cloud virtual device driver restores and reconstructs the virtual device.

[0011] Preferably, according to VirtIO interface standard, the underlying physical hardware is abstracted as a virtual device, and VirtIO virtual device driver is divided into a front end and a back end, the front end and the back end are located in the same operating system, are divided into virtual operating system and host operating system, or are divided into local operating system and remote or cloud operating system, and data interaction is performed between the two through a sharing mechanism, comprising:

[0012] Initialize the physical device driver and its related data structure and the backend of the VirtIO virtual device driver, and bind and establish mapping with the corresponding physical device driver, and abstract the physical device;

[0013] According to the VirtIO interface standard, configure the device information and state information of the virtual device for the backend of the VirtIO virtual device driver;

[0014] According to the device information and state information, create and initialize the frontend of the VirtIO virtual device driver, and bind with the backend of the VirtIO virtual device driver, negotiate the device attributes, and determine the used device attributes;

[0015] Determine the data interaction mode of the frontend and the backend, and constitute a frontend and backend architecture conforming to the VirtIO interface standard, and the frontend and backend architecture performs data interaction between the frontend and the backend through a shared memory mechanism.

[0016] Preferably, the related data structure includes: a data structure determined by a device driver model of an operating system, including information of storing the name of a physical device, a bus, and a protocol type, functional characteristics, read-write permissions, operation interfaces, and a running state.

[0017] Preferably, the device information of the virtual device includes: a corresponding device number, a maximum shared queue size, and functional information supported by the device; and / or

[0018] The state information of the virtual device includes: identified, initialized, ready, characteristic negotiation completed, and failed states.

[0019] Preferably, the device attributes include: the number of shared queues used, the size of shared queues used, and the enabled device unique characteristics.

[0020] Preferably, the frontend and backend architecture performs data interaction between the frontend and the backend through a shared memory mechanism, including:

[0021] An upper application program initiates an operation on the VirtIO virtual device using a normal I / O interface, and enters the processing logic of the frontend;

[0022] The frontend processes and packages the I / O request of the upper application program according to the device type, and adds it to the queue of the shared memory area in the form of a VirtIO request, and when the backend is located remotely or in the cloud, synchronizes the VirtIO request to the shared queue of the remote or cloud, and notifies the backend to process;

[0023] The backend receives the processing notification of the frontend, extracts the specific VirtIO request from the shared queue, obtains the I / O request therefrom, and hands over the I / O request to the corresponding physical device for I / O operation;

[0024] After the I / O operation is completed, the backend places the operation result into the virtual queue, and notifies the frontend that the operation is completed;

[0025] After the frontend receives the notification that the operation is completed, the frontend extracts the result of the I / O operation from the queue and returns to the upper-layer application.

[0026] Preferably, the migration interface of the virtual hardware abstraction layer is used to establish a link with a remote or cloud virtual device driver, and transmit the local virtual device state to the remote or cloud, so that the remote or cloud virtual device driver recovers and reconstructs the virtual device, including:

[0027] The upper-layer application calls the migration interface of the source system virtual device, specifies a migration target system, and initiates a migration instruction; network connection between the source system and the target system is established, the sender and the receiver of the virtual device migration and the migration device information are determined;

[0028] The target system enters a migration receiving state and waits for the migration request of the sender cyclically;

[0029] The source system packs the migration device information and necessary memory data structure to form a data packet;

[0030] The source system sends the data packet;

[0031] The target system receives the data packet;

[0032] After the source system finishes sending the data packet, a signal of ending migration is sent, and the target system receives the signal and ends the migration process;

[0033] The target system recovers the migration device information and necessary memory data structure from the received data packet, constructs a virtual device identical to the virtual device in the source system in the memory of the target system, and binds the virtual device with the physical device of the target system;

[0034] After the migration is completed, the virtual device continues to be used in the target system and retains the state information of the virtual device in the source system, the source system unbinds the virtual device and the physical device, and destroys the virtual device.

[0035] According to another aspect of the present application, a ubiquitous hardware device virtualization support system based on a VirtIO interface is provided, including:

[0036] A Virtio-based virtual hardware device driving module is used to abstract underlying physical hardware into virtual devices according to a VirtIO interface standard, and divide a VirtIO virtual device driver into a front end and a back end, which are located in the same operating system, are located on a virtual operating system and a host operating system, or are located on a local operating system and a remote or cloud operating system, and perform data interaction through a sharing mechanism;

[0037] A virtual hardware abstraction layer design module is used to form a unified VirtIO driving layer cross-system boundary virtual hardware abstraction layer based on the front end and the back end, which provides state information of virtual devices and interface information of operating devices for an application program, and shields heterogeneity of underlying physical devices; and the virtual hardware abstraction layer is connected to a local and / or remote or cloud physical device to perform actual I / O operation.

[0038] A virtual hardware migration module based on the virtual hardware abstraction layer is used to support an upper application to establish a link with a remote virtual device driver by calling a migration interface of the virtual hardware abstraction layer, and transmit a local virtual device state to a remote or cloud device, so that the remote or cloud virtual device driver restores and reconstructs a virtual device.

[0039] According to a third aspect of the present application, a computer terminal is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor is configured to execute the computer program to perform the method according to any one of the preceding aspects, or to run the system according to the preceding aspects.

[0040] According to a fourth aspect of the present application, a computer readable storage medium is provided, which stores a computer program executable by a processor to perform the method according to any one of the preceding aspects, or to run the system according to the preceding aspects.

[0041] Thanks to the above technical solutions, the present application has at least one of the following beneficial effects compared with the prior art:

[0042] The present application is directed to heterogeneous hardware devices in a ubiquitous computing scenario, and a hardware resource virtualization supporting method is designed based on VirtIO interface technology, so that heterogeneous hardware in a ubiquitous scenario can be more efficiently abstracted and managed, resource utilization is improved, and dynamic resource configuration and flexible expansion are provided.

[0043] The application utilizes VirtIO interface technology, provides efficient resource abstraction and flexible dynamic management for heterogeneous hardware devices and complex service requirements in ubiquitous scenes, and realizes heterogeneous resource normalization, resource dynamic decoupling, multi-resource on-demand flow and other characteristics.

[0044] In the application, the VirtIO-based virtual hardware device driver realizes a virtual device abstraction of physical hardware devices in the system, and realizes the function of the virtual device driver based on the VirtIO interface standard, which shields the details of the underlying heterogeneous hardware from the upper application while maintaining certain performance.

[0045] In the application, the design of the virtual hardware abstraction layer solves the problem of the heterogeneity of the underlying hardware in the ubiquitous computing scene, and through the introduction of an additional abstraction layer, the application program is decoupled from the underlying hardware, which creates conditions for dynamic resource management and resource reuse, and improves the resource utilization.

[0046] In the application, the virtual hardware migration based on the virtual hardware abstraction layer completes the migration of the virtual device based on the virtual hardware abstraction layer, realizes the dynamic on-demand deployment of the virtual device, and makes the resource utilization in the ubiquitous computing scene more efficient and flexible. BRIEF DESCRIPTION OF DRAWINGS

[0047] Other features, objects and advantages of the application will become more apparent through reading the following detailed description of the non-limiting embodiments with reference to the accompanying drawings:

[0048] Figure 1 The figure is a work flow chart of the ubiquitous hardware device virtualization support method based on the VirtIO interface in a preferred embodiment of the application.

[0049] Figure 2 The figure is a work schematic diagram of the implementation method of the VirtIO-based virtual hardware device driver in a preferred embodiment of the application.

[0050] Figure 3 The figure is a work schematic diagram of the implementation method of the design of the virtual hardware abstraction layer in a preferred embodiment of the application.

[0051] Figure 4 The figure is a work schematic diagram of the implementation method of the virtual hardware migration based on the virtual hardware abstraction layer in a preferred embodiment of the application.

[0052] Figure 5 The figure is a component module schematic diagram of the ubiquitous hardware device virtualization support system based on the VirtIO interface in a preferred embodiment of the application. DETAILED DESCRIPTION

[0053] The following will make a detailed description of the embodiments of the present application: the embodiments are implemented on the premise of the technical solutions of the present application, and give detailed implementation manners and specific operation processes. It should be pointed out that, for those skilled in the art, without departing from the concept of the present application, a number of modifications and improvements can be made, which are all within the protection scope of the present application.

[0054] In view of the problems in the prior art, an embodiment of the present application provides a VirtIO interface-based ubiquitous hardware device virtualization support method for heterogeneous hardware resources in a ubiquitous computing scenario. The VirtIO interface standard technology is used to provide efficient resource abstraction and flexible dynamic management for the heterogeneous hardware devices and complex service requirements in the ubiquitous scenario, and to realize the normalization of heterogeneous resources, dynamic decoupling of resources, on-demand flow of multiple resources and other characteristics.

[0055] Specifically, as shown in the figure, Figure 1 The VirtIO interface-based ubiquitous hardware device virtualization support method provided by the embodiment can include the following operations:

[0056] S1, according to the VirtIO interface standard, abstract the underlying physical hardware into a virtual device, and divide the VirtIO virtual device driver into a front end and a back end. The front end and the back end can be located in the same operating system, be located on a virtual operating system and a host operating system, or be located on a local operating system and a remote / cloud operating system. Data interaction is performed between the front end and the back end through a sharing mechanism;

[0057] S2, based on the front end and the back end, form a unified VirtIO driving level virtual hardware abstraction layer across the system boundary. The virtual hardware abstraction layer provides the application program with the state information of the virtual device and the interface information of the operating device, and shields the heterogeneity of the underlying physical device. The virtual hardware abstraction layer downwardly connects the local and / or remote / cloud physical device to perform actual I / O operation;

[0058] S3, through the migration interface of the virtual hardware abstraction layer, establish a link with the remote / cloud virtual device driver, and transmit the local virtual device state to the remote end. The remote / cloud virtual device driver restores and reconstructs the virtual device.

[0059] In some preferred embodiments, the above-mentioned S1, according to the VirtIO interface standard, abstracts the underlying physical hardware into a virtual device, and divides the VirtIO virtual device driver into a front end and a back end. The front end and the back end can be located in the same operating system, be located on a virtual operating system and a host operating system, or be located on a local operating system and a remote / cloud operating system. Data interaction is performed between the front end and the back end through a sharing mechanism. Further, it can further include:

[0060] S11, initialize the physical device driver and its related data structure and the backend of the VirtIO virtual device driver, and bind and establish mapping corresponding to the physical device driver, and abstract the physical device;

[0061] S12, according to the VirtIO interface standard, configure the device information and state attributes of the virtual device for the backend of the VirtIO virtual device driver;

[0062] S13, according to the device information and state information, create and initialize the front end of the VirtIO virtual device driver, and bind with the backend of the VirtIO virtual device driver, negotiate the device attributes, and determine the used device information;

[0063] S14, determine the data interaction mode of the front end and the backend, constitute the front-end and back-end architecture conforming to the VirtIO interface standard, and the front-end and back-end architecture performs data interaction between the front-end and the back-end through shared memory mechanism.

[0064] In some preferred embodiments, the above S11, the related data structure, can further include: the data structure determined by the device driver model of the operating system, including: the information of storing the name of the physical device, the bus and its protocol type, the function characteristics, the read-write permission, the operation interface and the running state, etc.

[0065] In some preferred embodiments, the above S12, the device information of the virtual device, can further include: the corresponding device number, the maximum shared queue size and the function information supported by the device.

[0066] The state attributes of the virtual device can further include: the states of identified, initialized, ready, characteristic negotiation completed and failed, etc.

[0067] In some preferred embodiments, the above S13, the device attributes, can further include: the number of shared queues used, the size of shared queues used, and the enabled device unique characteristics, etc.

[0068] In some preferred embodiments, the above S14, the front-end and back-end architecture performs data interaction between the front-end and the back-end through shared memory mechanism, can further include:

[0069] S141, the upper application program initiates operation to the VirtIO virtual device using the normal I / O interface, and enters the processing logic of the front end;

[0070] S142, the front end processes and packages the I / O request of the upper-layer application according to the device type, and adds the VirtIO request into the queue of the shared memory area, when the back end is located at the remote / cloud, synchronizes the VirtIO request to the shared queue at the remote / cloud through the network, and notifies the back end to process;

[0071] S143, the back end receives the processing notification of the front end, extracts the specific VirtIO request from the shared queue, obtains the I / O request from the VirtIO request, and delivers the I / O request to the corresponding physical device for I / O operation;

[0072] S144, after the I / O operation is completed, the back end puts the operation result into the virtual queue, and notifies the front end that the operation is completed;

[0073] S145, after the front end receives the notification that the operation is completed, extracts the result of the I / O operation from the queue and returns to the upper-layer application.

[0074] In some preferred embodiments, the S2 based on the front end and the back end forms a unified VirtIO driving layer virtual hardware abstraction layer, which can further include:

[0075] The virtual hardware abstraction layer is based on the VirtIO virtual device driver and is the integration of various virtual device drivers, which is the virtualization abstraction of the bottom heterogeneous hardware.

[0076] The virtual hardware abstraction layer is based on the VirtIO interface standard and decouples the virtual device driver into the front end and the back end; wherein: the front end and the back end can be located in the same operating system, be located in the virtual operating system and the host operating system, or be located in the local operating system and the remote / cloud operating system, and the front end and the back end exchange data and control according to the VirtIO standard through the shared memory area and the notification mechanism; the front end interfaces with the application program upward, and provides the upper-layer with the operation interface similar to the ordinary device driver and the virtual device state information synchronization; the back end interfaces with the physical hardware downward, and delivers the I / O request of the front end to the hardware for processing, and returns the result.

[0077] The virtual hardware abstraction layer shields the heterogeneity of the physical device end, and the upper-layer application does not need to pay attention to the physical state and execution of the bottom hardware, and does not need to distinguish the local device and the remote / cloud device, so that the dynamic expansion and migration of the resources can be realized. Meanwhile, the bottom resources can be mapped to different virtual devices, the low-load hardware resources can be reused, and the overall utilization of the resources can be improved.

[0078] In some preferred embodiments, S3, through the migration interface of the virtual hardware abstraction layer, establishes a link with the remote / cloud virtual device driver and transmits the local virtual device state to the remote / cloud, and the remote / cloud virtual device driver restores and reconstructs the virtual device, and can further include:

[0079] S31, the upper application calls the migration interface of the source system virtual device, specifies the migration target system and initiates the migration instruction; establishes the network connection between the source system and the target system, determines the sender and the receiver of the virtual device migration and the migration device information;

[0080] S32, the target system enters the migration receiving state and waits for the migration request of the sender cyclically;

[0081] S33, the source system packs the migration device information and the necessary memory data structure to form a data packet;

[0082] S34, the source system sends the data packet;

[0083] S35, the target system receives the data packet;

[0084] S36, after the source system finishes sending the data packet, a signal of ending migration is sent, and after the target system receives the signal, the migration process is ended;

[0085] S37, the target system restores the migration device information and the necessary memory data structure through the received data packet, constructs a virtual device identical to the virtual device in the source system in the memory of the target system, and binds the virtual device with the physical device of the target system;

[0086] S38, the migration is completed, the virtual device continues to be used in the target system and retains the state information of the virtual device in the source system, the source system unbinds the virtual device and the physical device and destroys the virtual device.

[0087] The above-mentioned embodiment of the present application provides a ubiquitous hardware device virtualization support method based on the VirtIO interface, which is designed for heterogeneous hardware devices in the ubiquitous computing scenario, and is based on the VirtIO interface technology, so that the heterogeneous hardware in the ubiquitous scenario can be more efficiently abstracted and managed, and the resource utilization rate is improved while the dynamic resource configuration and flexible expansion capability are provided.

[0088] The technical solutions provided by the above-mentioned embodiment of the present application will be described in further detail below in combination with a preferred embodiment and the accompanying drawings.

[0089] The ubiquitous hardware device virtualization support method based on the VirtIO interface provided by the preferred embodiment mainly includes the following three parts:

[0090] a Virtio-based virtual hardware device driver part;

[0091] a virtual hardware abstraction layer design part;

[0092] a virtual hardware migration part based on the virtual hardware abstraction layer.

[0093] wherein:

[0094] In a preferred embodiment, the implementation method of the Virtio-based virtual hardware device driver part is as shown in Figure 2 According to the VirtIO interface standard, the underlying physical hardware is abstracted as a virtual device, and the driver is divided into a front end and a back end. The front end and the back end can be located in the same operating system, be located on a virtual operating system and a host operating system, or be located on a local operating system and a remote / cloud operating system. Data interaction is performed between the two through shared memory and the like, and control interaction is performed through a notification mechanism.

[0095] Further, as shown in Figure 2 the implementation method includes the following steps:

[0096] Step 1: When the system starts, the physical device driver and its related data structure are initialized, and at the same time, the back end of the VirtIO virtual device driver needs to be initialized and bound and mapped with the physical device driver to achieve the abstraction of the physical device.

[0097] Step 2: According to the different device types and business needs, referring to the VirtIO interface standard, the VirtIO back end will configure virtual device information such as the corresponding device number, the maximum shared queue size, and the supported functions of the device, and maintain device-specific state information.

[0098] Step 3: According to the system configuration, the front end of the VirtIO virtual device driver will be created and initialized, and bound with the VirtIO virtual device driver back end to negotiate device properties, determine the shared queue size, and the supported functions of the device, etc.

[0099] Step 4, since the front-end and the back-end are designed according to the VirtIO standard, the specific implementation manner does not affect the interaction between the front-end and the back-end. For example, the front-end and the back-end can be located in the operating system under the same physical machine environment, and data interaction is performed through memory, and synchronization and communication are performed through signals, interrupts and other mechanisms; or the front-end and the back-end can be located in a virtualized environment, and are located in a virtual operating system and a host operating system respectively, data interaction is performed through shared memory, and communication is performed through Hyper-call and other forms; or the front-end and the back-end can be located in different physical machines of a local operating system and a remote / cloud operating system respectively, and data interaction is performed through remote memory technology, and communication is performed through a network and other ways. Regardless of the carrier technology actually implemented, the essence is to form a front-end and a back-end architecture that conforms to the VirtIO standard.

[0100] Further, the data interaction of Step 4 further includes the following steps:

[0101] Step 4.1, when the application program needs to use the device, the VirtIO virtual device is initiated for reading, writing, control and other operations through the same I / O interface as the ordinary device, and the processing logic of the front-end driver is entered.

[0102] Step 4.2, the front-end driver processes and packages the I / O request of the upper layer according to the different types of devices, and adds the VirtIO request into the Virtqueue of the shared memory area, and notifies the back-end for processing through signals and other forms.

[0103] Step 4.3, the back-end receives the VirtIO request of the front-end, takes out the specific request from the Virtqueue of the shared memory area, and performs I / O operation on the corresponding physical device.

[0104] Step 4.4, after the I / O operation is completed, the back-end places the operation result into the Virtqueue of the shared memory area, and notifies the front-end that the operation is completed through interrupts and other forms.

[0105] Step 4.5, after the front-end receives the notification that the operation is completed, the I / O operation result is taken out from the Virtqueue and returned to the upper layer application.

[0106] Thus, the VirtIO-based virtual hardware device driver implementation is completed, a virtual device abstraction of the physical hardware device is implemented in the system, and the function of the virtual device driver is implemented based on the VirtIO interface standard, which shields the details of the underlying heterogeneous hardware from the upper layer application while maintaining certain performance.

[0107] In a preferred embodiment, the implementation method of the virtual hardware abstraction layer design part is as follows: Figure 3As shown in the figure, virtual device drivers form a unified layer, providing device status information and interfaces for operating devices to applications, while shielding the details of the underlying hardware. They connect to local and / or remote physical devices to complete actual I / O operations, and are internally implemented through the VirtIO interface standard, improving the efficiency and flexibility of device drivers.

[0108] Furthermore, if Figure 3 As shown, the implementation method includes the following contents:

[0109] The virtual hardware abstraction layer is implemented based on virtual device drivers. It is the integration of various virtual device drivers in the system and the virtualization abstraction of the underlying heterogeneous hardware.

[0110] The virtual hardware abstraction layer is designed based on the VirtIO interface standard, decoupling the virtual device driver into the front-end and back-end. The front-end and back-end interact with each other through a shared memory area in accordance with the VirtIO standard.

[0111] The front end connects to the application and provides the upper layer with an operation interface similar to that of an ordinary device driver and synchronization of virtual device status information.

[0112] The backend connects to the physical hardware, passes the frontend I / O requests to the hardware for processing, and returns the results.

[0113] The virtual hardware abstraction layer shields the heterogeneity of physical devices. Upper-layer applications no longer need to monitor the physical state and performance of the underlying hardware, nor differentiate between local and remote / cloud devices. This allows for dynamic resource expansion and migration. Furthermore, underlying resources can be mapped to different virtual devices, enabling the reuse of low-load hardware resources and improving overall resource utilization.

[0114] The design of the virtual hardware abstraction layer solves problems such as the heterogeneity of the underlying hardware in ubiquitous computing scenarios. By introducing an additional abstraction layer, it decouples applications from the underlying hardware, creates conditions for dynamic resource management and resource reuse, and improves resource utilization.

[0115] In a preferred embodiment, the implementation method of the virtual hardware migration part based on the virtual hardware abstraction layer is as follows Figure 4 As shown, the application layer establishes a link with the remote virtual device driver by calling the migration interface, saves the local virtual device state, and transmits it to the remote end through serialization, network protocol, etc., and the remote driver restores and reconstructs the virtual device.

[0116] Furthermore, if Figure 4 As shown, the implementation method includes the following steps:

[0117] Step 1, the upper user / system administrator calls the migration interface of the source system virtual device, specifies the migration target system and initiates the migration instruction. The two systems are connected through Ethernet, high-speed network cable and the like, and information such as the sender and receiver of the virtual device migration and the type of the migration device is determined.

[0118] Step 2, the target system enters the migration receiving state and waits for the migration request of the sender.

[0119] Step 3, the source system packs the state, configuration, attribute and necessary memory data structure (such as the content of the shared queue) of the virtual device, organizes them into the form of data packet through serialization and the like.

[0120] Step 4, the source system sends the data packet through the network interface and the like.

[0121] Step 5, the target system receives the data packet through the network interface and the like.

[0122] Step 6, after the source system finishes the data sending, the signal of the end of migration is sent, and the target system can end the migration process after receiving the signal.

[0123] Step 7, the target system recovers the state, configuration, attribute and necessary memory data structure of the virtual device through the received data packet, constructs the virtual device which is completely the same as the virtual device in the source system in the memory of the target system, and binds the virtual device with the physical device of the target system.

[0124] Step 8, the migration is completed, the virtual device can continue to be used in the target system and the device state information of the original virtual device is reserved. The source system can unbind the virtual device and the physical device and destroy the virtual device.

[0125] Through the above mechanism, the migration of the virtual device based on the virtual hardware abstraction layer is completed, the dynamic on-demand deployment of the virtual device is realized, and the resource utilization in the ubiquitous computing scenario is more efficient and flexible.

[0126] The technical solutions provided by the above embodiments of the application are further described in detail in combination with a specific application example.

[0127] The VirtIO interface-based ubiquitous hardware device virtualization support method provided in the specific application example is implemented based on the industrial control Internet of Things operating system Silicium, so as to achieve virtual resource management of ubiquitous hardware. The underlying hardware used by the industrial control Internet of Things operating system is a 64-bit RISC-V architecture embedded development board terminal, which has a built-in K210 MCU and supports multiple bus protocols / peripherals such as I2C, CAN, UART, GPIO, and supports Ethernet connection. The operating system used is the XiUOS Silicium operating system, which provides basic functions of the operating system for ubiquitous scenarios, and implements device drivers for part of the hardware resources and a network module based on Lwip. In addition, some necessary physical peripherals are also used in the specific application example.

[0128] On the above system platform, the specific application example implements front-end and back-end drivers of the VirtIO interface-based virtual hardware device based on its hardware interface, replaces the I / O operation interface provided by the original device driver, and completes I / O operations by calling actual physical hardware interfaces such as a data structure, a shared memory area, and the like that meet the VirtIO standard, as shown in Figure 1 The device driver implemented based on the application can complete normal device I / O operations such as I2C sensor temperature measurement and GPIO output. Based on the foregoing various VirtIO virtual device drivers, including VirtIO-gpio, VirtIO-i2c, VirtIO-serial, etc., a virtual hardware abstraction layer is constituted, which adds an abstraction layer on the basis of the original device driver model, shields the details of the underlying hardware, and efficiently and flexibly completes I / O operations of an application program through the VirtIO interface, as shown in Figure 2 Based on the foregoing VirtIO virtual device driver and virtual hardware abstraction layer, the application connects two terminals in an Ethernet manner by using a network interface provided by the system, and completes migration of a virtual device between different terminals, including establishment of a connection, state saving of the virtual device driver, data serialization processing and transmission, and restoration of the virtual device driver, and the migrated device can also operate normally, and its logic is as shown in Figure 3 Through the above method, the technical scheme of the VirtIO interface-based ubiquitous hardware device virtualization support method proposed in the above embodiments of the application is implemented.

[0129] The preferred embodiments of the application are described in detail above. It should be understood that those of ordinary skill in the art can make many modifications and changes to the application without creative labor based on the concept of the application. Therefore, any technical scheme obtained by logical analysis, reasoning or limited experiments based on the prior art according to the concept of the application shall be within the protection scope defined by the claims.

[0130] An embodiment of the present application provides a VirtIO interface-based ubiquitous hardware device virtualization support system.

[0131] Specifically, as shown in the figure, Figure 5 the VirtIO interface-based ubiquitous hardware device virtualization support system provided by the embodiment can include:

[0132] a VirtIO-based virtual hardware device driving module, which is used for abstracting underlying physical hardware into a virtual device according to a VirtIO interface standard, and dividing a VirtIO virtual device driver into a front end and a back end, the front end and the back end can be located in the same operating system, be located on a virtual operating system and a host operating system respectively, or be located on a local operating system and a remote or cloud operating system respectively, and data interaction is performed between the front end and the back end through a sharing mechanism; for example, a working schematic diagram as shown in the figure can be referred to; Figure 2

[0133] a virtual hardware abstraction layer design module, which is used for forming a unified VirtIO driving layer cross-system boundary virtual hardware abstraction layer based on the front end and the back end, the virtual hardware abstraction layer providing state information of a virtual device and interface information of an operating device for an application program, and shielding heterogeneity of underlying physical devices; the virtual hardware abstraction layer performing actual I / O operations on local and / or remote / cloud physical devices; for example, a working schematic diagram as shown in the figure can be referred to; Figure 3

[0134] a virtual hardware migration module based on the virtual hardware abstraction layer, which is used for supporting migration of an upper-layer application through an interface of the virtual hardware abstraction layer, establishing a link with a remote virtual device driver, and transmitting a local virtual device state to a remote / cloud, so that the remote / cloud virtual device driver restores and reconstructs the virtual device; for example, a working schematic diagram as shown in the figure can be referred to. Figure 4

[0135] It should be noted that the steps in the method provided by the present application can be implemented by corresponding modules, devices, units, etc. in the system, and those skilled in the art can refer to the technical solutions of the method to realize the composition of the system, that is, the embodiments in the method can be understood as preferred examples of constructing the system, which will not be described here.

[0136] An embodiment of the present application provides a computer terminal, including a memory, a processor, and a computer program stored in the memory and capable of running on the processor, when the processor executes the computer program, the computer program can be used to execute the method of any one of the above embodiments of the present application, or run the system of any one of the above embodiments of the present application.

[0137] ​​​Optionally, the memory is configured to store a program; the memory can include volatile memory (e.g., random-access memory (RAM), such as static random-access memory (SRAM), Double Data Rate SDRAM (DDR SDRAM), etc.), and / or non-volatile memory (e.g., flash memory). The memory is configured to store computer programs (e.g., application programs, functional modules, etc. for implementing the above-described methods), computer instructions, etc. The computer programs, computer instructions, etc. described above can be stored in one or more memories in a partitioned manner. Moreover, the computer programs, computer instructions, data, etc. described above can be invoked by the processor.

[0138] The computer programs, computer instructions, etc. described above can be stored in one or more memories in a partitioned manner. Moreover, the computer programs, computer instructions, data, etc. described above can be invoked by the processor.

[0139] The processor is configured to execute the computer programs stored in the memory to implement each step in the methods or each module of the systems described above in the embodiments. Details can be referred to the related descriptions in the above method and system embodiments.

[0140] The processor and the memory can be independent structures or integrated structures. When the processor and the memory are independent structures, the memory and the processor can be coupled by a bus.

[0141] An embodiment of the present application further provides a computer readable storage medium, which stores a computer program. The computer program is configured to be executed by a processor to implement the method of any one of the above-mentioned embodiments of the present application, or to run the system of any one of the above-mentioned embodiments of the present application.

[0142] The method and system for virtualizing ubiquitous hardware devices based on a VirtIO interface provided by the above-mentioned embodiments of the present application enable more efficient resource abstraction and management of heterogeneous hardware in a ubiquitous scenario through the design of a VirtIO-based virtual hardware device driver, a virtual hardware abstraction layer and virtual hardware migration based on the virtual hardware abstraction layer, improve resource utilization, and provide the ability of dynamic resource configuration and flexible expansion.

[0143] The details of the above embodiments of the present application are not exhaustive of the technology known in the art.

[0144] The above describes specific embodiments of the present application. It should be understood that the present application is not limited to the specific embodiments described above, and various modifications or changes can be made by those skilled in the art within the scope of the claims, which do not affect the essential content of the present application.

Claims

1. A method for supporting virtualization of ubiquitous hardware devices based on VirtIO interface, characterized in that, The application relates to a method for realizing a cross-system boundary virtual hardware abstraction layer based on a VirtIO interface standard. The method comprises the following steps: According to the VirtIO interface standard, bottom physical hardware is abstracted into a virtual device, and a VirtIO virtual device driver is divided into a front end and a back end, the front end and the back end are located in the same operating system, are divided into a virtual operating system and a host operating system or are divided into a local operating system and a remote or cloud operating system, and data interaction is carried out between the front end and the back end through a sharing mechanism; Based on the front end and the back end, a cross-system boundary virtual hardware abstraction layer of a VirtIO driving level is formed, the virtual hardware abstraction layer provides state information of a virtual device and interface information of an operating device for an application program, and the heterogeneity of bottom physical devices is shielded; The virtual hardware abstraction layer is connected with a remote or cloud virtual device driver through a migration interface of the virtual hardware abstraction layer, and local virtual device state is transmitted to the remote or cloud, so that the remote or cloud virtual device driver recovers and reconstructs the virtual device.

2. The VirtIO interface based ubiquitous hardware device virtualization support method according to claim 1, wherein, The method comprises the following steps: The method comprises the following steps: According to the VirtIO interface standard, bottom physical hardware is abstracted into a virtual device, and a VirtIO virtual device driver is divided into a front end and a back end, the front end and the back end are located in the same operating system, are divided into a virtual operating system and a host operating system or are divided into a local operating system and a remote or cloud operating system, and data interaction is carried out between the front end and the back end through a sharing mechanism, including: Initializing a physical device driver and related data structures and a back end of a VirtIO virtual device driver, and binding and mapping the physical device driver, so as to abstract the physical device; According to the VirtIO interface standard, device information and state information of the virtual device are configured for the back end of the VirtIO virtual device driver; 3. The VirtIO interface based ubiquitous hardware device virtualization support method according to claim 2, wherein, According to the device information and the state information, a front end of the VirtIO virtual device driver is created and initialized, is bound with the back end of the VirtIO virtual device driver, device properties are negotiated, and the used device properties are determined; 4. The VirtIO interface based ubiquitous hardware device virtualization support method according to claim 2, wherein, The data interaction mode of the front end and the back end is determined, a front-back end architecture conforming to the VirtIO interface standard is constituted, and the front-back end architecture carries out data interaction between the front end and the back end through a shared memory mechanism. The related data structures comprise data structures determined by a device driver model of an operating system, and the data structures comprise information of a name, a bus, a protocol type, a function characteristic, a read-write permission, an operation interface and a running state of a physical device.

5. The VirtIO interface based ubiquitous hardware device virtualization support method according to claim 2, wherein, The device information of the virtual device comprises corresponding device numbers, maximum shared queue sizes and function information supported by the device.

6. The VirtIO interface based ubiquitous hardware device virtualization support method according to claim 2, wherein, The state information of the virtual device comprises states of having been identified, having been initialized, having been ready, having completed characteristic negotiation and having failed. The device properties comprise the number of used shared queues, the size of used shared queues and enabled device unique characteristics. The front-back end architecture carries out data interaction between the front end and the back end through a shared memory mechanism, and the front-back end architecture comprises the following steps: The upper application program initiates operation to the VirtIO virtual device by using a common I / O interface, and enters the processing logic of the front end; The front end processes and packages the I / O request of the upper application program according to the device type, and adds the VirtIO request into the queue of the shared memory area, and when the back end is located at a remote end or a cloud end, synchronizes the VirtIO request to the shared queue at the remote end or the cloud end, and notifies the back end to process; The back end receives the processing notification of the front end, extracts the specific VirtIO request from the shared queue, obtains the I / O request therefrom, and delivers the I / O operation to the corresponding physical device; After the I / O operation is completed, the back end places the operation result into the virtual queue, and notifies the front end that the operation is completed; The front end receives the notification that the operation is completed, extracts the result of the I / O operation from the queue, and returns the upper application program.

7. The VirtIO interface based ubiquitous hardware device virtualization support method according to claim 1, wherein, The migration interface of the virtual hardware abstraction layer is used to establish a link with the virtual device driver at the remote end or the cloud end, and to transmit the state of the local virtual device to the remote end or the cloud end, so that the virtual device is recovered and reconstructed by the virtual device driver at the remote end or the cloud end, including: The upper application program calls the migration interface of the source system virtual device, specifies the migration target system, and initiates the migration instruction; network connection is established between the source system and the target system, the sender and the receiver of the virtual device migration are determined, and the migration device information is determined; The target system enters the migration receiving state and waits for the migration request from the sender; The source system packages the migration device information and the necessary memory data structure to form a data packet; The source system sends the data packet; The target system receives the data packet; After the source system finishes sending the data packet, a signal of ending migration is sent, and the target system receives the signal and ends the migration process; The target system recovers the migration device information and the necessary memory data structure by receiving the data packet, constructs a virtual device identical to the virtual device in the source system in the memory of the target system, and binds the virtual device with the physical device of the target system; After the migration is completed, the virtual device continues to be used in the target system and retains the state information of the virtual device in the source system, the source system unbinds the virtual device and the physical device, and destroys the virtual device.

8. A VirtIO interface based ubiquitous hardware device virtualization support system, characterized by, The migration interface of the virtual hardware abstraction layer is used to establish a link with the virtual device driver at the remote end or the cloud end, and to transmit the state of the local virtual device to the remote end or the cloud end, so that the virtual device is recovered and reconstructed by the virtual device driver at the remote end or the cloud end, including: A Virtio-based virtual hardware device driver module is used to abstract the underlying physical hardware as a virtual device according to the VirtIO interface standard, and divide the VirtIO virtual device driver into a front end and a back end, the front end and the back end being located in the same operating system, being located above the virtual operating system and the host operating system, or being located above the local operating system and the remote or cloud operating system, and performing data interaction through a shared mechanism; A virtual hardware abstraction layer design module is configured to form a unified VirtIO driver level virtual hardware abstraction layer across system boundaries based on the front end and the back end, which provides application with virtual device state information and interface information for operating the device and masks the heterogeneity of the underlying physical device; The virtual hardware abstraction layer is connected to the local and / or remote or cloud physical device to perform actual I / O operations; A virtual hardware migration module based on the virtual hardware abstraction layer is configured to support the upper application to establish a link with a remote or cloud virtual device driver by calling a migration interface of the virtual hardware abstraction layer, and to transmit the local virtual device state to the remote device to be recovered and reconstructed by the remote or cloud virtual device driver.

9. A computer terminal comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that, The computer program is executed by the processor to execute the method of any one of claims 1-7, or run the system of claim 8.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to execute the method of any one of claims 1-7, or run the system of claim 8.

Images