Virtio back-end model, Virtio system and Virtio device access method
By introducing the OSAL layer into the virtio backend model, encapsulating the interfaces of different operating systems and accessing the virtio queues in a unified manner, the complex problem of porting virtio backend drivers between different operating systems is solved, and development efficiency is improved.
Patent Information
- Application Number
- CN202411790782.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-06
- Publication Date
- 2025-04-04
AI Technical Summary
In the Type1 virtualization solution, the porting of virtio back-end drivers is complex, especially due to the differences in virtqueue and operating system-related interfaces of different operating systems, which leads to a long adaptation time and is not necessarily compatible.
Provide a virtio backend model, which encapsulates the relevant interfaces of different operating systems into unified interfaces through the OSAL layer, and uses this unified interface to access the virtio queue in the virtio backend to achieve unified access to virtio devices.
When porting virtio backends between different operating systems, you only need to replace the corresponding OSAL layer, which improves the development efficiency of virtio backend of the operating system and simplifies the driver adaptation process.
Smart Images
Figure CN119759492A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of operating system technology, and in particular to a virtio backend model, a virtio system and a virtio device access method. Background Art
[0002] With the rapid development of virtualization technology, virtio, as a standardized virtual device interface, has been widely used.
[0003] At present, in the Type 1 virtualization solution, if the hypervisor is a microkernel, the virtio backend is implemented in the service virtual machine. Usually, the virtio front-end driver porting is relatively simple, while the virtio back-end driver porting is relatively complex. It is mostly customized for specific operating systems, which is very disadvantageous for the need to replace different types of service virtual machines. When porting the virtio back-end driver to a new service virtual machine, the main challenges are as follows:
[0004] 1. Virtqueue: Different operating systems have their own virtqueues, and the usage methods vary. It takes some time for the virtio backend driver to adapt to virtqueue, and they may not be compatible.
[0005] 2. Operating system related interfaces: Different operating systems have their own implementations of the same functions and different function names. The virtio backend driver needs to adapt to the operating system interface, such as memory application, lock, task, etc. Summary of the invention
[0006] In view of this, an embodiment of the present application provides a virtio backend model, a virtio system and a virtio device access method. The virtio backend model of the embodiment of the present application is used to encapsulate the relevant interfaces of different operating systems into a unified interface, and use the unified interface to access the corresponding virtio queue in the virtio backend to achieve access to the virtio device. When porting between different operating systems, only the corresponding OSAL layer needs to be replaced.
[0007] In a first aspect, an embodiment of the present application provides a virtio backend model, comprising: an OSAL layer, used to encapsulate relevant interfaces of different operating systems into a unified interface, wherein the operating system runs on a microkernel that implements type 1 virtualization, and the relevant interface is an interface used by the virtio backend model in the operating system kernel; a Virtio layer, including a Virtio queue module, and the Virtio queue module is used to use the unified interface to access the virtio queue of the virtio device in the virtio backend model; a driver layer, including drivers for each registered virtio device, used to use the unified interface to access the corresponding virtio device through the virtio queue of each registered virtio device.
[0008] As described above, by encapsulating the related interfaces of different operating systems into a unified interface, the corresponding virtio queue in the virtio backend model is accessed using the unified interface, thereby achieving access to virtio devices in a unified manner. When porting the virtio backend between different operating systems, only the corresponding OSAL layer needs to be replaced, thereby improving the virtio backend development efficiency of the operating system.
[0009] In a possible implementation of the first aspect, the Virtio layer further includes: a virtio device module, which is used to register and destroy each virtio device and its driver using the unified interface, and achieve matching between the registered virtio device and its driver based on the device ID.
[0010] From the above, by using a unified interface to register and destroy virtio devices and virtio device drivers, and matching registered virtio devices and virtio device drivers based on device IDs, virtio devices and virtio device drivers are registered, destroyed, and matched based on a mechanism independent of the operating system, further improving the virtio backend development efficiency of the operating system.
[0011] In a possible implementation manner of the first aspect, the virtio device module is further configured to manage the virtio device by using the unified interface according to the virtio protocol.
[0012] From the above, by using a unified interface to manage virtio devices according to the virtio protocol, virtio devices and virtio device drivers are managed based on a mechanism independent of the operating system, further improving the virtio backend development efficiency of the operating system.
[0013] In a possible implementation manner of the first aspect, the virtio device module includes: a virtio mmio module and / or a virtio pci module, and a virtio interface library; the virtio mmio module is used to manage virtio mmio devices according to the virtio protocol using the unified interface, and each virtio mmio device corresponds to an MMIO physical device; the virtio pci module is used to manage virtio pci devices according to the virtio protocol using the unified interface, and each virtio pci device corresponds to a pci physical device; the virtio interface library is used to encapsulate the interface of the virtio mmio module and / or the virtio pci module, and is used to register and destroy each virtio device and the driver of each virtio device, and perform the matching.
[0014] As described above, the interface of the virtio mmio module and / or the virtio pci module is encapsulated through the virtio interface library, so that the developer of the virtio device driver does not need to care about the specific management method of the virtio mmio module and / or the virtio pci module for the virtio device, further improving the virtio backend development efficiency of the operating system.
[0015] In a possible implementation manner of the first aspect, the relevant interface includes an interface to one of the following objects:
[0016] Memory, locks, semaphores, tasks, files, IO ports, and interrupts.
[0017] From the above, through the relevant interfaces including memory, lock, semaphore, task, file, IO port, and interrupt interface, the interface used by the virtio backend model in the operating system kernel is encapsulated to achieve a unified interface for different operating systems.
[0018] In a possible implementation of the first aspect, the virtio queue module is specifically used to implement one of the following operations: creating and deleting a virtio queue, determining whether a virtio queue is available, obtaining buffers from a virtio queue, reading and writing buffers, adding buffers to a used queue, enabling and disabling a virtio queue interrupt, and virtio queue notification.
[0019] From the above, various operations of the virtio queue defined by the virtio protocol are implemented through the virtio queue module. The names of the operations of the virtio queue of the operating system are not the same, but they correspond to the corresponding operations of the virtio queue of the operating system.
[0020] In a possible implementation manner of the first aspect, the management includes at least one of the following operations: creation and deletion of virtio queues, acquisition and setting of virtio status, acquisition and setting of virtio configuration, acquisition of characteristic parameters of virtio device drivers, and setting of characteristic parameters of virtio devices.
[0021] From the above, the above management operations include the operations of virtio device management of the virtio protocol. The names of the virtio device management operations of the operating system may be different, but they correspond to the virtio device management operations of the operating system, which not only realizes the device management requirements of the virtio front-end, but also isolates the influence of the operating system.
[0022] In a possible implementation manner of the first aspect, when implementing the matching between the registered virtio device and the driver of the virtio device, the virtio interface library is specifically used to implement the matching between the virtio device and the driver of the virtio device based on the device ID on the virtio bus using the unified interface.
[0023] From the above, a unified interface is used on the virtio bus based on the device ID to achieve matching between virtio devices and virtio device drivers, and the matching mechanisms of different operating systems are unified in the virtio backend.
[0024] In a second aspect, an embodiment of the present application provides a virtio system, including: a virtio front end, for receiving access requirements of an application of an operating system to a virtio device, the operating system running on a microkernel that implements type 1 virtualization; a virtio back end constructed based on the virtio back end model described in any implementation scheme of the first aspect, for accessing the virtio queue of the virtio device in the virtio back end according to the access requirements received by the virtio front end using the interface encapsulated by its OSAL layer, wherein the address of each virtio device's virtio queue in the virtio front end and the virtio queue in the virtio back end are the same.
[0025] In a third aspect, an embodiment of the present application provides a method for accessing a virtio device, using the virtio system described in the second aspect to access the virtio device, comprising: the virtio front end of the virtio system receives an access requirement of an application of an operating system to a virtio device, wherein the operating system runs on a microkernel that implements type 1 virtualization; the virtio back end of the virtio system uses an interface encapsulated by its OSAL layer to access the virtio queue of the virtio device in the virtio back end according to the access requirement received by the virtio front end, wherein the address of the virtio queue of the same virtio device in the virtio front end and the virtio queue in the virtio back end is the same; the virtio front end obtains an access result from the virtio queue of the virtio device in the virtio front end according to the access requirement.
[0026] In a fourth aspect, an embodiment of the present application provides a computing device, including:
[0027] bus;
[0028] A communication interface connected to the bus;
[0029] at least one processor connected to the bus; and
[0030] At least one memory is connected to the bus and stores program instructions, and when the program instructions are executed by the at least one processor, the at least one processor executes any implementation method of the third aspect of the present application.
[0031] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium having program instructions stored thereon, and when the program instructions are executed by a computer, the computer executes the implementation described in the third aspect. BRIEF DESCRIPTION OF THE DRAWINGS
[0032] Figure 1 This is a structural diagram of a virtio backend model embodiment 1 of the present application;
[0033] Figure 2 This is a structural diagram of a second embodiment of a virtio backend model of the present application;
[0034] Figure 3 A schematic diagram of mounting a virtio device and a virtio device driver on a virtio bus of a virtio backend model embodiment 2 of the present application;
[0035] Figure 4A flowchart of a virtio device access method embodiment 1 of the present application;
[0036] Figure 5 A flowchart of a second embodiment of a virtio device access method of the present application;
[0037] Figure 6 A schematic diagram of the structure of a computing device of each method embodiment of the present application. DETAILED DESCRIPTION
[0038] In the following description, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.
[0039] In the following description, the terms "first\second\third, etc." or module A, module B, module C, etc. are only used to distinguish similar objects, or to distinguish different embodiments, and do not represent a specific ordering of the objects. It can be understood that the specific order or sequence can be interchanged where permitted, so that the embodiments of the present application described here can be implemented in an order other than that illustrated or described here.
[0040] In the following description, the numbers representing the steps, such as S110, S120, etc., do not necessarily mean that the steps must be executed in this manner. If permitted, the order of the previous and next steps can be interchanged, or they can be executed simultaneously.
[0041] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.
[0042] The embodiment of the present application provides a virtio backend model, a virtio system and a virtio device access method, wherein the virtio backend model includes: an OSAL layer, which is used to encapsulate the relevant interfaces of different operating systems into a unified interface, wherein the operating system runs on a microkernel that implements type1 virtualization, and the relevant interface is the interface used by the virtio backend model in the operating system kernel; a Virtio layer, including a Virtio queue module, which is used to access the virtio queue of the virtio device in the virtio backend model using the unified interface; a driver layer, including the driver of each registered virtio device, which is used to access the corresponding virtio device through the virtio queue of each registered virtio device using the unified interface. The virtio system and virtio device access method of the embodiment of the present application are implemented based on the virtio front end of the embodiment of the present application.
[0043] The virtio backend model of the embodiment of the present application is used to encapsulate the relevant interfaces of different operating systems into a unified interface, and use the unified interface to access the corresponding virtio queue in the virtio backend model to achieve access to the virtio device. When porting the virtio backend between different operating systems, only the corresponding OSAL layer needs to be replaced.
[0044] The following describes various embodiments of the present application in conjunction with the accompanying drawings. Figure 1 A first embodiment of a virtio backend model of the present application is introduced.
[0045] Figure 1 The structure of a first embodiment of a virtio backend model of the present application is shown, including: an OSAL layer 10, a virtio layer 20 and a driver layer 30.
[0046] The OSAL layer 10 is used to encapsulate related interfaces of different operating systems into a unified interface.
[0047] The operating system runs on a microkernel that implements type 1 virtualization, and the operating system's related interfaces are interfaces used by the virtio backend model in the operating system's kernel. As described above, the unified interface can unify the function names of the related interfaces of different operating systems, and when the virtio backend uses the related interfaces, the unified interface is used to isolate problems caused by different function names of the related interfaces of different operating systems.
[0048] In some embodiments, the relevant interface of the operating system includes an interface to one of the following objects: memory, lock, semaphore, task, file, IO port, interrupt, and implements one of the following operations.
[0049] (1) Operations on memory:
[0050] Memory application and release;
[0051] Map physical addresses to virtual addresses and unmap virtual addresses;
[0052] Find virtual address through physical address, and find physical address through virtual address;
[0053] ●Refresh and invalidate dcache;
[0054] (2) Operations on locks and semaphores:
[0055] ●Creating, deleting, locking and unlocking locks;
[0056] Creation, deletion, acquisition, and release of semaphores;
[0057] (3) Operations on tasks, including the creation and deletion of tasks, that is, the creation and deletion of threads;
[0058] (4) Operations on files:
[0059] ·Open and close files;
[0060] ●Get the size of the file;
[0061] ●Reading and writing files;
[0062] (5) Operation on io port:
[0063] ●8-bit, 16-bit, 32-bit IO read;
[0064] ●8bit, 16bit, 32bit io write;
[0065] (6) Operations on interrupts
[0066] ●Getting and registering common interrupts;
[0067] · Acquisition and registration of msix interrupts.
[0068] The virtio layer 20 implements the functions of the virtio protocol, including a virtio queue module 210 (also called Virtqueuelib). The virtio queue module 210 is used to use the unified interface obtained by the OSAL layer 10 to implement access to the virtio queue of the virtio device in the virtio backend model according to the virtio protocol.
[0069] Among them, the operation name of the virtio queue in the virtio backend model of each embodiment of the present application does not change with the operation name of the virtio queue in the operating system, and may be different from the operation name of the virtio queue of the operating system itself, but corresponds to the operation corresponding to the virtio queue of the operating system. For example, the physical address of the virtio queue in the virtio backend model is the same as that of the virtio queue of the operating system. From the above, the virtio queue module 210 uses a unified interface and a unified operation name to isolate the influence of the operating system on the virtio queue in the virtio backend model.
[0070] In some embodiments, the virtio queue module 210 is specifically configured to implement one of the following operations:
[0071] ●virtio queue creation and deletion,
[0072] Determine whether the virtio queue is available.
[0073] ●Get buffers from the virtio queue,
[0074] Reading and writing buffers,
[0075] ●Add buffers to the used queue,
[0076] ●Enable and disable virtio queue interrupts,
[0077] Virtio queue notifications.
[0078] The above operations include operations on virtio queues defined by the virtio protocol, and the operation object virtio queue is a virtio queue in the virtio backend model.
[0079] The driver layer 30 includes drivers for various virtio devices. The driver for each virtio device is used to access the corresponding virtio device by accessing the virtio queue in the virtio backend model using the unified interface obtained by the OSAL layer 10 and the virtio queue module 210. The driver for each virtio device is also used to provide an access interface for the virtio device to the virtio front end.
[0080] For example, the virtio device driver includes virtio BLK (virtio block device driver), virtio NET (virtio network device driver), and virtio GPU (virtio GPU device driver).
[0081] In some embodiments, the virtio layer 20 further includes a virtio device module, which is used to register and destroy virtio devices and drivers of virtio devices using the unified interface obtained by the OSAL layer 10, and to match the registered virtio devices and drivers of virtio devices based on the device ID. As described above, the virtio device module uses the unified interface obtained by the OSAL layer 10 to register and destroy virtio devices and drivers of virtio devices, and the matching between the two based on the device ID, and a unified mechanism is used in different operating systems to register and destroy virtio devices and drivers of virtio devices, and the matching between the two, thereby isolating the influence of the operating system.
[0082] In some embodiments, the virtio device module is further used to manage the virtio device according to the virtio protocol using the unified interface obtained by the OSAL layer 10. In some embodiments, the virtio device module is specifically used to implement one of the following operations:
[0083] Creation and deletion of virtio queues (triggering creation and deletion of virtio queues by virtio queue module 210),
[0084] ·Get and set virtio status,
[0085] ·Virtio configuration acquisition and setting,
[0086] Acquisition of characteristic parameters of virtio device drivers,
[0087] ·Set the characteristic parameters of virtio devices.
[0088] The virtio queue operated by the virtio device module is the virtio queue in the virtio backend model, and the above operations are triggered by the virtio frontend and are all based on the virtio device. For example, when the virtio frontend driver registers the virtio device, the virtio device module is triggered to create the virtio queue of the virtio device registered by the backend and other operations.
[0089] In some embodiments, the virtio device module includes at least one of the following modules:
[0090] The virtio mmio module is used to manage the virtio mmio devices according to the virtio protocol using the unified interface obtained by the OSAL layer 10. Each virtio mmio device corresponds to an MMIO physical device.
[0091] The virtio pci module is used to manage the virtio pci devices according to the virtio protocol using the unified interface obtained by the OSAL layer 10, and each virtio pci device corresponds to a pci physical device.
[0092] In these embodiments, the virtio device module further includes:
[0093] The virtio interface library is used to encapsulate the interfaces of the virtio mmio module and / or the virtio pci module, and to register and destroy virtio devices and virtio device drivers, as well as to match the two.
[0094] Among them, virtio mmio module and virtio pci module
[0095] In some embodiments, when the virtio interface library implements the matching between the registered virtio device and the driver of the virtio device, it is specifically used to implement the matching between the virtio device and the driver of the virtio device based on the device ID on the virtio bus using the unified interface obtained by the OSAL layer 10.
[0096] In summary, a virtio backend model implementation example encapsulates related interfaces of different operating systems into a unified interface, and uses the unified interface to access the corresponding virtio queue in the virtio backend model to achieve access to virtio devices. When porting the virtio backend between different operating systems, only the corresponding OSAL layer needs to be replaced.
[0097] Combine the following Figure 2 and Figure 3 A second embodiment of a virtio backend model of the present application is introduced.
[0098] A second embodiment of a virtio backend model is a detailed implementation of the first embodiment of a virtio backend model, having all its advantages, and adding a virtio device module to the virtio layer 20, and using the unified interface obtained by the OSAL layer to uniformly manage the virtio devices.
[0099] Figure 2 The structure of a second embodiment of a virtio backend model is shown. Figure 1 A virtiommio module 220, a virtio pci module 230 and a virtio interface library 240 (also called virtio lib) are added to the virtio layer 20 to form a virtio device module.
[0100] The virtio mmio module 220 is used to manage the virtio mmio devices according to the virtio protocol using the unified interface obtained by the OSAL layer 10, and each virtio mmio device corresponds to an mmio physical device.
[0101] The virtio pci module 230 is used to manage the virtio pci devices according to the virtio protocol using the unified interface obtained by the OSAL layer 10, and each virtio pci device corresponds to a pci physical device.
[0102] The virtio interface library 240 is used to encapsulate the interfaces of the virtio mmio module 220 and the virtio pci module 230, and to register and destroy virtio devices and drivers of virtio devices, and to match the two.
[0103] The operations encapsulated by the virtio interface library 240 specifically include one of the following operations:
[0104] Creation and deletion of virtio queues (triggering creation and deletion of virtio queues by virtio queue module 210),
[0105] ·Get and set virtio status,
[0106] ·Get and set virtio configuration (virtio config),
[0107] ●Get the characteristic parameters of the virtio device driver (virtio driver features),
[0108] ·Set the characteristic parameters of virtio devices (virtio device features).
[0109] Among them, when implementing the matching between the registered virtio device and the driver of the virtio device, the virtio interface library 240 is specifically used to implement the matching between the virtio device and the driver of the virtio device based on the device ID on the virtio bus using the unified interface obtained by the OSAL layer 10.
[0110] The virtio bus includes the virtio mmio bus and the virtio pci bus, and the virtio device driver includes the irtio mmio device driver and the virtio pci device driver. The virtio mmio bus mounts the virtio mmio device and the virtio mmio device driver, and the virtio pci bus mounts the virtio pci device and the virtio pci device driver.
[0111] Figure 3 A schematic diagram of mounting virtio devices and virtio device drivers on a virtio bus is shown, where virtio devices exemplarily include device0, device1, device2, ..., and their corresponding device IDs are 0, 1, 2, and so on;) virtio device drivers exemplarily include driver0, driver1, driver2, ..., and their corresponding device IDs are 0, 1, 2, and so on.
[0112] When registering virtio devices and virtio device drivers, the device or driver on the virtio bus will be traversed. If the device ID is the same, the match is successful.
[0113] When the virtio device driver is loaded, the virtio mmio module 220 or the virtio pci module 230 is loaded first, the corresponding virtio device is registered in the virtio lib, and the virtio device driver is matched. After successfully matching the corresponding driver, virtqueue lib is used to transmit data. In this way, when the service virtual machine needs to be replaced (that is, the operating system needs to be replaced), only the osal layer 10 needs to be adapted, so that the virtio backend model can be quickly and flexibly adapted to different types of service virtual machines.
[0114] In summary, a second embodiment of a virtio backend model not only uses a unified interface to access the corresponding virtio queues in the virtio backend model in a unified form, but also uses a unified mechanism to manage virtio devices and match them with virtio devices. When replacing the service virtual machine, only the osal layer 10 needs to be adapted to enable the virtio backend model to quickly and flexibly adapt to different types of service virtual machines.
[0115] A virtio system embodiment of the present application is introduced below.
[0116] A virtio system embodiment embodiment 1 includes: a virtio front end and a virtio back end constructed based on the virtio back end model described in embodiment 1 of a virtio back end model, and has all the advantages of embodiment 1 of a virtio back end model.
[0117] The virtio front end is used to receive access requirements of an application of an operating system to a virtio device, and the operating system runs on a microkernel that implements type 1 virtualization.
[0118] The virtio backend is used to access the virtio queue of the virtio device in the virtio backend according to the access demand received by the virtio frontend by utilizing the interface encapsulated by its OSAL layer 10.
[0119] Among them, the addresses of the virtio queues in the virtio front end and the virtio queues in the virtio back end of the same virtio device are the same, but the operation methods are different. The operation of the virtio queue in the virtio back end refers to a virtio back end model embodiment 1. The operation of the virtio queue in the virtio front end is the operation of the virtio queue defined by the operating system itself.
[0120] The virtio front end is also used to obtain an access result of the virtio device from the virtio queue of the virtio device in the virtio front end.
[0121] A virtio system embodiment, embodiment 2, includes: a virtio front end and a virtio back end constructed based on the virtio back end model described in embodiment 2 of a virtio back end model, and has all the advantages of embodiment 2 of a virtio back end model.
[0122] Among them, the virtio front-end is the same as the virtio front-end in the first embodiment of the virtio system embodiment. The second embodiment of the virtio system embodiment can also be considered to be a virtio system embodiment in which the management function of the virtio device of the second virtio back-end model is added on the basis of the first embodiment. It has all the advantages of the first embodiment of the virtio system embodiment, and manages the virtio device and matches the virtio device with a unified mechanism in the virtio back-end. When replacing the service virtual machine, it only needs to adapt the osal layer to realize the virtio back-end to quickly and flexibly adapt to different types of service virtual machines.
[0123] Combine the following Figure 4 and Figure 5An embodiment of a virtio device access method of the present application is introduced.
[0124] A virtio device access method embodiment 1 uses a virtio system embodiment embodiment 1. The virtio system described in embodiment 1 accesses the virtio device and has all the advantages of the virtio system embodiment embodiment 1.
[0125] Figure 4 The flowchart of a first embodiment of a virtio device access method is shown, including steps S410 to S430.
[0126] S410: The virtio front end receives a request from an application of the operating system for accessing the virtio device.
[0127] The operating system runs on a microkernel that implements type 1 virtualization, and the operating system's application virtio front end accesses the virtio device. The virtio front end sets the virtio queue provided by the operating system of the virtio device.
[0128] S420: The virtio backend uses the unified interface encapsulated by its OSAL layer 10 to access the virtio queue of the virtio device in the virtio backend according to the access demand received by the virtio frontend.
[0129] The virtio queue access in the virtio backend is accessed by the virtio queue module 210 in the virtio backend using a unified interface encapsulated by the vOSAL layer 10, and is independent of the operating system.
[0130] S430: The virtio front end obtains an access result from the virtio queue of the virtio device in the virtio front end according to the received access request.
[0131] The access method of the virtio queue in the virtio front end is provided by the operating system. The addresses of the same virtio device in the virtio queue in the virtio front end and the virtio queue in the virtio back end are the same. The access result obtained from the virtio queue in the virtio front end is the access result of the virtio back end to the virtio device, that is, the real access result to the physical device corresponding to the virtio device.
[0132] A virtio device access method embodiment 2 uses a virtio system embodiment embodiment 2 to access the virtio device, which has all the advantages of the virtio system embodiment embodiment 2.
[0133] Figure 5 The flowchart of Embodiment 2 of a virtio device access method includes steps S510 to S540.
[0134] S510: The virtio backend registers the virtio device and the virtio device driver and matches the two.
[0135] Among them, this step is triggered when the operating system registers the virtio device, which specifically includes:
[0136] (1) Loading a virtio mmio module 220 or a virtio pci module 230 of the second embodiment of the virtio backend model, wherein the specific module is related to the type of the registered virtio device.
[0137] (2) The virtio interface library 240 registers the virtio device and the virtio device driver on the corresponding virtio bus, and manages the registered virtio device and the virtio device driver based on a unified mechanism, including the virtio queue of the virtio device in the virtio backend.
[0138] (3) The virtio interface library 240 matches the registered virtio device and the driver of the virtio device based on the device ID on the corresponding virtio bus.
[0139] S520: The virtio front end receives a request from an application of the operating system for accessing the virtio device.
[0140] The method of this step is the same as step S410 of the first embodiment of a virtio device access method.
[0141] S530: The virtio backend uses the unified interface encapsulated by its OSAL layer 10 to access the virtio queue of the virtio device according to the access demand received by the virtio front end.
[0142] The method of this step is the same as step S420 of the first embodiment of a virtio device access method.
[0143] S540: The virtio front end obtains an access result from the virtio queue of the virtio device in the virtio front end according to the received access request.
[0144] The method of this step is the same as step S430 of the first embodiment of a virtio device access method.
[0145] The present application embodiment also provides a computing device, Figure 6 Detailed introduction.
[0146] The computing device 600 includes a processor 610 , a memory 620 , a communication interface 630 , and a bus 640 .
[0147] It should be understood that the communication interface 630 in the computing device 600 shown in this figure can be used to communicate with other devices.
[0148] The processor 610 may be connected to a memory 620. The memory 620 may be used to store the program code and data. Therefore, the memory 620 may be a storage unit inside the processor 610, or an external storage unit independent of the processor 610, or a component including a storage unit inside the processor 610 and an external storage unit independent of the processor 610.
[0149] Optionally, the computing device 600 may further include a bus 640. The memory 620 and the communication interface 630 may be connected to the processor 610 via the bus 640. The bus 640 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus 640 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the figure is represented by only one line, but it does not mean that there is only one bus or one type of bus.
[0150] It should be understood that in the embodiment of the present application, the processor 610 may adopt a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. Alternatively, the processor 610 may adopt one or more integrated circuits to execute relevant programs to implement the technical solutions provided in the embodiment of the present application.
[0151] The memory 620 may include a read-only memory and a random access memory, and provides instructions and data to the processor 610. A portion of the processor 610 may also include a nonvolatile random access memory. For example, the processor 610 may also store information on the device type.
[0152] When the computing device 600 is running, the processor 610 executes the computer-executable instructions in the memory 620 to perform the operation steps of each method embodiment.
[0153] It should be understood that the computing device 600 according to the embodiment of the present application can correspond to the corresponding subjects in the methods according to the embodiments of the present application, and the above-mentioned and other operations and / or functions of each module in the computing device 600 are respectively for implementing the corresponding processes of each method of the present embodiment. For the sake of brevity, they will not be repeated here.
[0154] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.
[0155] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.
[0156] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as 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 devices or units, which can be electrical, mechanical or other forms.
[0157] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
[0158] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
[0159] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium and includes several 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 methods described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.
[0160] The embodiment of the present application also provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, it is used to execute the operating steps of each method embodiment.
[0161] The computer storage medium of the embodiment of the present application can adopt any combination of one or more computer-readable media.Computer-readable media can be computer-readable signal media or computer-readable storage media.Computer-readable storage media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or devices, or any combination of the above.More specific examples (non-exhaustive lists) of computer-readable storage media include, electrical connections with one or more wires, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above.In this document, computer-readable storage media can be any tangible medium containing or storing programs, which can be used by instruction execution systems, devices or devices or used in combination with them.
[0162] Computer-readable signal media may include data signals transmitted in baseband or as part of a carrier wave, which carry computer-readable program code. Such transmitted data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, transmit, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.
[0163] The program code embodied on the computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
[0164] Computer program code for performing the operation of the present application can be written in one or more programming languages or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., using an Internet service provider to connect through the Internet).
[0165] Note that the above are only preferred embodiments of the present application and the technical principles used. Those skilled in the art will understand that the present application is not limited to the specific embodiments described herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present application. Therefore, although the present application is described in more detail through the above embodiments, the present application is not limited to the above embodiments, and may also include more other equivalent embodiments without departing from the concept of the present application, all of which belong to the scope of protection of the present application.
Claims
1. A virtio backend model, characterized in that: include: The OSAL layer is used to encapsulate the related interfaces of different operating systems into a unified interface, wherein the operating system runs on a microkernel that implements type 1 virtualization, and the related interface is an interface used by the virtio backend model in the operating system kernel; The Virtio layer includes a Virtio queue module, wherein the Virtio queue module is used to access the virtio queue of the virtio device in the virtio backend model by using the unified interface; The driver layer includes drivers for each registered virtio device, and is used to access the corresponding virtio device through the virtio queue of each registered virtio device by using the unified interface.
2. The virtio backend model according to claim 1, characterized in that: The Virtio layer also includes: The virtio device module is used to register and destroy each virtio device and its driver by using the unified interface, and to match the registered virtio device with its driver based on the device ID.
3. The virtio backend model according to claim 2, characterized in that: The virtio device module is also used to manage the virtio device using the unified interface.
4. The virtio backend model according to claim 2, characterized in that: The virtio device module includes: a virtio mmio module and / or a virtio pci module, and a virtio interface library; The virtio mmio module is used to manage the virtio mmio devices using the unified interface, each virtio mmio device corresponds to an MMIO physical device; The virtio pci module is used to manage virtio pci devices using the unified interface, and each virtio pci device corresponds to a pci physical device; The virtio interface library is used to encapsulate the interface of the virtio mmio module and / or the virtio pci module, and is used to register and destroy virtio devices and corresponding drivers, and perform the matching.
5. The virtio backend model according to claim 1, characterized in that: The relevant interface includes an interface to one of the following objects: Memory, locks, semaphores, tasks, files, IO ports, and interrupts.
6. The virtio backend model according to claim 1, characterized in that: The virtio queue module is specifically used to implement one of the following operations: Create and delete virtio queues, determine whether virtio queues are available, obtain buffers from virtio queues, read and write buffers, add buffers to the used queue, turn on and off virtio queue interrupts, and notify virtio queues.
7. The virtio backend model according to claim 3, characterized in that: The management includes at least one of the following operations: Creation and deletion of virtio queues, acquisition and setting of virtio status, acquisition and setting of virtio configuration, acquisition of characteristic parameters of virtio device drivers, and setting of characteristic parameters of virtio devices.
8. The virtio backend model according to claim 4, characterized in that: When implementing the matching between the registered virtio device and the corresponding driver, the virtio interface library is specifically used to implement the matching between the virtio device and the corresponding driver based on the device ID using the unified interface on the virtio bus.
9. A virtio system, characterized in that: include: A virtio front end, for receiving access requirements of an application of an operating system to a virtio device, wherein the operating system runs on a microkernel implementing type 1 virtualization; A virtio backend constructed based on the virtio backend model of any one of claims 1 to 8, for accessing the virtio queue of the virtio device in the virtio backend according to the access demand received by the virtio frontend using the interface encapsulated by its OSAL layer, wherein the address of each virtio device's virtio queue in the virtio frontend and the virtio queue in the virtio backend are the same.
10. A method for accessing a virtio device, characterized in that: Using the virtio system described in claim 9 to access the virtio device comprises: The virtio front end of the virtio system receives the access demand of the application program of the operating system to the virtio device; The virtio backend of the virtio system uses a unified interface encapsulated by its OSAL layer to access the virtio queue of the virtio device in the virtio backend according to the access demand received by the virtio frontend; The virtio front end obtains an access result from a virtio queue of the virtio device in the virtio front end according to the access requirement.
11. A computing device, characterized in that: include, bus; A communication interface connected to the bus; at least one processor connected to the bus; as well as At least one memory is connected to the bus and stores program instructions, and when the program instructions are executed by the at least one processor, the at least one processor executes the method of claim 10.
12. A computer-readable storage medium, characterized in that: Program instructions are stored thereon, and when the program instructions are executed by a computer, the computer is caused to execute the method of claim 10 .