WO2019119315A1

WO2019119315A1 - Input processing method and apparatus based on multiple operating systems, and electronic device

Info

Publication number: WO2019119315A1
Application number: PCT/CN2017/117557
Authority: WO
Inventors: 李岩刚
Original assignee: 深圳前海达闼云端智能科技有限公司
Priority date: 2017-12-20
Filing date: 2017-12-20
Publication date: 2019-06-27
Also published as: CN108235759B; CN108235759A

Abstract

The present application relates to the technical field of virtualization, in particular to an input processing method and apparatus based on multiple operating systems, and an electronic device. The method comprises: when it is monitored that a host operating system receives an input event, determining whether there is a guest operating system in a foreground running state at present; and if so, injecting, by means of a preset data transmission channel, the input event from a kernel space of the host operating system into a kernel space of the guest operating system in the foreground running state, so that the guest operating system in the foreground running state responds to the input event. By means of the implementation, the injection duration for an input event is shortened, thereby improving the performance of an input system in a guest operating system.

Description

Input processing method, device and electronic device based on multiple operating systems

Technical field

The present application relates to the field of virtualization technologies, and in particular, to an input processing method, apparatus, and electronic device based on multiple operating systems.

Background technique

Based on the virtualization technology, multiple operating systems or virtual machines can run on the electronic device at the same time, and the processors, memory, and input and output devices provided by the hardware devices are shared among multiple operating systems or virtual machines. When implementing a method based on multiple operating systems, the input device node is typically opened in the user space of the host operating system, receiving input events, and then determining whether the event needs to be forwarded to the guest operating system; if the event needs to be forwarded to the client The operating system injects the event into the guest operating system kernel input device module; the client operating system application obtains the injected input event by reading the input device node in its user space.

The inventor found that the related art has the following problem: the input event injected into the guest operating system is reported from the host operating system kernel space to the user space, and then transferred from the user space to the host operating system kernel space, and then injected into the guest operating system kernel space. One process, so that the process of input event injection is long, affects the performance of the guest operating system input system.

Summary of the invention

The embodiment of the present invention provides an input processing method, an apparatus, and an electronic device based on multiple operating systems, which are mainly used to solve the problem that the input event injection time is long when the input event is processed based on multiple operating systems.

To solve the above technical problem, a technical solution adopted by the embodiment of the present application is to provide a multi-operating system-based input processing method, where the operating system includes a host operating system and at least one guest operating system, and the method includes:

When it is detected that the host operating system receives an input event, it is determined whether there is currently a guest operating system in a foreground running state;

If present, injecting the input event from a kernel space of the host operating system into a kernel space of the guest operating system in a foreground running state through a preset data transmission channel, so as to be in the foreground running state The guest operating system responds to the input event.

To solve the above technical problem, another technical solution adopted by the embodiment of the present application is to provide an input processing device based on multiple operating systems, where the operating system includes a host operating system and at least one guest operating system, and the device includes determining Module and first processing module;

The determining module is configured to: when it is detected that the host operating system receives an input event, determine whether the guest operating system is currently in a foreground running state;

The first processing module is configured to: when the guest operating system is currently in a foreground running state, inject the input event from the kernel space of the host operating system into the client in a foreground running state through a preset data transmission channel; The kernel space of the operating system to cause the guest operating system in the foreground operating state to respond to the input event.

In order to solve the above technical problem, another technical solution adopted by the embodiment of the present application is to provide an electronic device, including: at least one processor; and a memory communicably connected to the at least one processor; wherein the memory An instruction program executable by the at least one processor is stored, the instruction program being executed by the at least one processor to cause the at least one processor to perform the method as described above.

In order to solve the above technical problem, another technical solution adopted by the embodiment of the present application is to provide a non-volatile computer readable storage medium, where the non-volatile computer readable storage medium stores computer-executable instructions. The computer executable instructions are for causing a computer to perform the method as described above.

In order to solve the above technical problem, another technical solution adopted by the embodiment of the present application is to provide a computer program product, the computer program product comprising a computer program stored on a non-transitory computer readable storage medium, the computer The program includes program instructions that, when executed by a computer, cause the computer to perform the method as described above.

The embodiment of the present application provides an input processing method and apparatus based on multiple operating systems. When the host operating system receives an input event, it determines whether the guest operating system is in the foreground running state, and if it exists in the foreground running state. The guest operating system injects input events from the host operating system into the kernel space of the guest operating system in the foreground running state through a preset data transmission channel, thereby causing the guest operating system to respond to the input event. Since the input event can be directly injected into the kernel space of the guest operating system from the kernel space of the host operating system, the injection time of the input event is shortened, and the performance of the input system in the guest operating system is improved.

DRAWINGS

The one or more embodiments are exemplified by the accompanying drawings in the accompanying drawings, and FIG. The figures in the drawings do not constitute a scale limitation unless otherwise stated.

1 is a schematic diagram of an application scenario of the method and apparatus of the present application;

2 is a schematic flowchart of an input processing method based on multiple operating systems according to an embodiment of the present application;

3 is a schematic flowchart of a method for determining whether a guest operating system is in a foreground running state in a multi-operating system based input processing method according to an embodiment of the present application;

4 is a schematic diagram showing the functional structure of a kernel accelerator in a host operating system kernel space in an input processing method based on multiple operating systems according to an embodiment of the present application;

FIG. 5 is a schematic flowchart of a multi-operating system based input processing method according to another embodiment of the present application; FIG.

6 is a schematic flowchart of a multi-operating system-based input processing method according to another embodiment of the present application;

7 is a schematic diagram showing the functional structure of a backend program of the guest operating system in an input processing method based on multiple operating systems according to an embodiment of the present application;

FIG. 8 is a schematic flowchart of a multi-operating system-based input processing method according to still another embodiment of the present application; FIG.

FIG. 9 is a schematic structural diagram of an input processing apparatus based on multiple operating systems according to an embodiment of the present application; FIG.

FIG. 10 is a schematic structural diagram of hardware of an electronic device according to an embodiment of the present application.

Detailed ways

In order to make the objects, technical solutions, and advantages of the present application more comprehensible, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It is understood that the specific embodiments described herein are merely illustrative of the application and are not intended to be limiting.

It should be noted that, if there is no conflict, the various features in the embodiments of the present application may be combined with each other, and are all within the protection scope of the present application. In addition, although the functional module division is performed in the device schematic, the logical sequence is shown in the flowchart, but in some cases, it may be performed in a different manner from the module in the device schematic, or in the order in the flowchart. The steps that are described or described.

FIG. 1 is a schematic diagram of an application scenario of an input processing method and apparatus based on multiple operating systems according to an embodiment of the present application. The application scenario may be a computer system environment running on a smart terminal. Specifically, as shown in FIG. 1 , the application scenario includes: a host operating system 10 , a guest operating system 11 , an emulator 12 , and a physical hardware device 13 .

The host operating system 10 and the guest operating system 11 belong to a computer program for managing and controlling the physical hardware device 13 and corresponding software resources, and are the most basic system software directly running on the "bare metal machine", and any other software must be in It can be run with the support of the host operating system 10 or the guest operating system 11. In the embodiment of the present application, the host operating system 10 and the guest operating system 11 may be any suitable type of operating system, such as: Linux, Unix, IOS, Android, Windows, etc., for receiving user instructions and outputting corresponding data accordingly. The processing results are shown to the user.

The physical hardware device 13 is shared between the host operating system 10 and the guest operating system 11. In actual operation, the host operating system 10 can directly use the hardware devices in the physical hardware device 13, and the guest operating system 11 uses the virtual devices provided by the virtual machines that drive the guest operating system 11. The “virtual machine” refers to a computer system that is simulated by software and has a complete hardware system function and runs in a completely isolated environment. The virtual machine may form a plurality of simulated hardware devices (such as the virtual input device described in the embodiment of the present application) for use by the guest operating system 11 based on the physical hardware device 13 or a software program. A virtual machine corresponds to a guest operating system 11, and each of the virtual machines can be run as one of the applications in the host operating system 10.

There is memory isolation between different operating systems, and even the host operating system 10 cannot access the memory space of the guest operating system 11. Thus, when there are two or more guest operating systems 11 in the computer system, if one of the guest operating systems 11 restarts due to an abnormality, the host operating system 10 and other guest operating systems 11 can also operate normally and be isolated from each other. However, since the virtual machine is running as an application in the host operating system 10, if the host operating system 10 restarts due to an abnormality, all of the guest operating systems 11 need to be restarted before they can run.

The simulator 12 can also be run as one of the applications in the host operating system 10. In the present embodiment, the simulator 12 corresponds to the guest operating system 11, and when a plurality of guest operating systems 11 are included, each guest operating system 11 corresponds to one simulator 12, respectively. In the present embodiment, the simulator 12 is used to run a backend program of the virtual input device, and the backend program of the virtual input device is the backend program of the guest operating system 11.

The physical hardware device 13 is a physically existing hardware device and may include any suitable device component that constitutes a complete computer system, including but not limited to: a processor, a storage medium, an input/output device, a communication module, and the like. Specifically, the processor may be any suitable type of processor having a certain logic operation capability, such as a CPU, a graphics processor, or the like. The processor may also include multiple cores for multi-threading or parallel processing. The storage medium may include a memory module such as a ROM, a RAM, a flash memory module, and a mass storage such as an optical disk and a hard disk. Computer programs are stored in the storage medium, and when the processor executes the computer programs, various corresponding method steps or processes can be implemented. The input/output device may be any suitable type of peripheral device that provides one or more modes of user interaction, such as a mouse, keyboard or touch input screen that receives user action instructions, a somatosensory camera for acquiring image information, A microphone that collects sound information or a display that presents image information to a user or a speaker that outputs audio. The input/output device can optionally connect to other physical hardware devices using wired or wireless peripherals. The communication module can include some network interface devices that establish connections through a wired or wireless communication network. For example, a network cable interface, a bus interface, a USB interface, a WiFi module, or a Bluetooth communication module.

In the actual application process, the physical hardware device 13 may also add or reduce one or more devices to meet different practical application requirements, such as adding a database or a server device.

In the embodiment of the present application, an input implementation method of multiple operating systems is implemented based on the host operating system 10, the guest operating system 11, the simulator 12, and the physical hardware device 13. Specifically, the host operating system 10 monitors whether it receives an input event, and if an input event is received, determines whether there is currently a guest operating system 11 in a foreground running state, and if so, the host operating system 10 injects the input event into the simulator. In 12, the input event is written into the kernel space of the guest operating system 11 by a backend program of the virtual input device in the simulator 12. It should be noted that after inputting the event injection simulator 12, the guest operating system 11 can also actively read the input events in the simulator 12.

Moreover, it can be understood that the host operating system 10 responds to the input event when all of the guest operating systems 11 in the computer system of the smart terminal are in a sleep state.

In addition, it should be noted that the multi-operating system-based input processing method provided by the embodiment of the present application can be further extended to other suitable application environments, and is not limited to the application environment shown in FIG. 1 . In the actual application process, the application environment may also include more guest operating systems and more or less physical hardware device types.

Based on the foregoing application scenario, a multi-operating system-based input processing method is provided. Specifically, FIG. 2 is a schematic flowchart of a multi-operating system-based input processing method according to an embodiment of the present application. Referring to FIG. 2, the method is include:

201: When it is detected that the host operating system receives an input event, determining whether the guest operating system is currently in a foreground running state;

The host operating system monitors whether it receives an input event through a preset program, and the input event refers to an operation instruction generated when an operator operates an input/output device such as a keyboard or a mouse, and an operation instruction It can correspond to an input event, which can be to open a page or enter a letter or delete a symbol, and so on. After the host operating system receives the input event, it is determined whether the guest operating system is in the foreground running state. Specifically, refer to FIG. 3, where it is determined whether the guest operating system is in the foreground running state, including:

2011: Read, from the virtual switching device corresponding to the at least one guest operating system, a front/back running state of the at least one guest operating system;

2012: Determine, according to the obtained front/back running state of the at least one guest operating system, whether the guest operating system is currently in the foreground running state.

In this embodiment, the host operating system communicates with the virtual switching device in the virtual machine, obtains the front/back running state of the guest operating system supported by the host operating system, and sets the front/back running state of the guest operating system to The kernel accelerator of the virtual input device in the host operating system kernel space, thereby causing the host operating system to acquire a guest operating system in a foreground running state.

The communication between the host operating system and the virtual switching device in the virtual machine is implemented by a backend program of the guest operating system, that is, a backend program of the virtual input device.

The virtual switching device is mainly used to control a front/back running state of the virtual machine. For example, the virtual switching device receives a handover request including the source virtual machine information, and determines whether the handover request is legal according to the source virtual machine information in the handover request, and if it is legal, the virtual machine corresponding to the handover request is The background running state is switched to the foreground running state. In addition, the virtual switching device can also switch the virtual machine in the sleep state to the foreground running state. Here, the switching virtual machine is also a switching client, and therefore, the virtual switching device can acquire the front/back running state of all the guest operating systems it supports. The background running state of the virtual machine refers to the virtual machine running, but the related service program of the human-computer interaction is closed, so the human-computer interaction interface is invisible to the user, that is, the virtual machine in the background running state can invoke the network. Modules such as communications, but can't call input and output modules that involve user interaction, such as keyboards or displays. The foreground running state of the virtual machine is the state opposite to the background running state. It should be noted that the specific process of the virtual switching device acquiring the front/back running state of the guest operating system supported by the virtual switching device may also refer to the description in the related art, and is not limited to the foregoing embodiment.

202: if present, injecting, by using a preset data transmission channel, the input event from a kernel space of the host operating system into a kernel space of the guest operating system in a foreground running state, so that the The guest operating system is responsive to the input event.

The preset data transmission channel is configured between the host operating system and the guest operating system in the foreground running state, specifically the backend program of the guest operating system running in the simulator (ie, the backend program of the virtual input device) ) to build. The backend program of the guest operating system transfers information of the data transmission channel to a kernel accelerator of a virtual input device in a host operating system kernel space, by using a kernel accelerator running in a kernel space of the host operating system The input event injects a backend program of the guest operating system running in a foreground running state from a kernel space of the host operating system, and the backend program writes the input event to a kernel of the guest operating system Space, thereby causing the guest operating system to respond to the input event. In this implementation manner, when the guest operating system is running in the foreground, the host operating system determines that the input event injected into the guest operating system is directly injected into the guest operating system by the accelerator in the host operating system kernel through the backend program of the virtual input device, thereby The event of input event injection into the guest operating system is shortened, so that the guest operating system can respond to the input event as soon as possible, thereby improving the performance of the guest operating system.

The kernel accelerator in the host operating system kernel space can implement two functions:

Function 1, after receiving the channel information of the data between the systems set by the backend program of the guest operating system, when the input subsystem in the host operating system kernel space has a new input event, if the input event needs to be delivered to the client The operating system injects the event into the guest operating system through the data transmission channel;

Function 2: When the guest operating system changes from the background to the foreground running state, the data transfer channel between the systems is enabled, and the kernel accelerator enters an active state; when the guest operating system is changed from the foreground running state to the background, the inter-system is not enabled. The data transfer channel, the kernel accelerator enters a sleep state. The guest operating system is in the background by default, so the data transfer channel is turned off by default. Its functional structure is shown in Figure 4.

It should be noted that, in the foregoing process, the backend program writes the input event to the kernel space of the guest operating system, and in other embodiments, the guest operating system may actively take the The input event is read into the kernel space in the end program.

In addition, when there are multiple guest operating systems, the preset data transmission channel can be established between each guest operating system and the host operating system. And adjusting the data transmission channel corresponding to the guest operating system in the foreground running state to the enabled state, and adjusting the data transmission channel corresponding to the guest operating system in the background running state or the background sleeping state to the closed state. Wherein, when switching between two guest operating systems, the virtual input device corresponding to the guest operating system switched to the background enters a sleep state, and the virtual input device corresponding to the guest operating system switched to the foreground enters an active state. .

In other embodiments, referring to FIG. 5, the method further includes:

203: After the input event is injected from a kernel space of the host operating system into a kernel space of the guest operating system in a foreground running state, the input event is cleared from an event list of the host operating system. The input event can be cleared from the event list by a preset program. By deleting the input event in the event list, it is not necessary to set the input device to be exclusive when the virtual machine program is operated, so that other applications in the user space can be prevented from reading the input event, thereby reducing the leakage of the input event. risk.

In some other embodiments, referring to FIG. 6, before performing the method shown in FIG. 2, the method further includes:

204: Read a device file of the input device in the host operating system;

205: Obtain configuration information of the input device according to the device file.

206: Send the configuration information to a kernel space of the guest operating system, so that a driver of the virtual input device corresponding to the input device in the guest operating system configures the virtual input according to the configuration information device.

The above steps are pre-configured with the virtual input device corresponding to the guest operating system before the input event is injected into the guest operating system. The input device is a physical input device corresponding to a host operating system, such as a keyboard, a mouse, or the like. In the host operating system, each input device has its corresponding device file, and the device file contains configuration information such as attributes of the input device, and the configuration information is transmitted to the kernel space of the guest operating system, thereby enabling the customer to operate. A driver of the virtual input device in the system registers corresponding virtual input devices in the guest operating system according to the configuration information, and sets configuration information of the virtual input devices. With this configuration, the host operating system and the guest operating system can share the same input device.

Wherein, configuring the virtual input device is also implemented by a backend program of the guest operating system, that is, a backend program of the virtual input device in the simulator. Based on the foregoing embodiment, referring to FIG. 7, the backend program of the guest operating system mainly implements three functions: function one, configuring a channel for transferring data between the host operating system and the guest operating system, and information of the channels. a kernel accelerator passed to the virtual input device in the host operating system kernel space; function 2, obtaining configuration information such as attributes of the input device through the input device in the device node in the host operating system, and transmitting the configuration information to the guest operating system Kernel space, the driver of the virtual input device in the guest operating system registers the corresponding input device in the guest operating system according to the configuration information, and sets corresponding configuration information; function three, communicates with the virtual switching device in the virtual machine, obtains It supports the front-end state of the guest operating system and sets the current front-end state to the kernel accelerator of the virtual input device in the host operating system kernel space.

In other embodiments, referring to FIG. 8, the method further includes:

207: The host operating system responds to the input event if the guest operating system does not currently exist in the foreground running state.

The embodiment of the present application provides an input processing method based on multiple operating systems. When the host operating system receives an input event, it determines whether the guest operating system is in the foreground running state, and if it exists in the foreground running state. The guest operating system injects input events from the host operating system into the kernel space of the guest operating system in the foreground running state through a preset data transmission channel, thereby causing the guest operating system to respond to the input event. Since the input event can be directly injected into the kernel space of the guest operating system from the kernel space of the host operating system, the injection time of the input event is shortened, and the performance of the input system in the guest operating system is improved. In addition, input events injected into the guest operating system are cleared from the event list, thereby reducing the risk of the input event being compromised.

Please refer to FIG. 9. FIG. 9 is a schematic structural diagram of an input processing apparatus based on multiple operating systems according to an embodiment of the present disclosure. The operating system includes a host operating system and at least one guest operating system, as shown in FIG. The device 30 includes a judging module 31 and a first processing module 32.

The determining module 31 is configured to: when it is detected that the host operating system receives an input event, determine whether the guest operating system is currently in a foreground running state; the first processing module 32 is configured to: if the client currently exists The operating system is in a foreground running state, and the input event is injected from a kernel space of the host operating system into a kernel space of the guest operating system in a foreground running state through a preset data transmission channel, so that the operation is in the foreground The guest operating system of the state responds to the input event.

The determining module 31 includes a data reading unit 311 and a state determining unit 312. The data reading unit 311 is configured to read a front/back running state of the at least one guest operating system from a virtual switching device corresponding to the at least one guest operating system; the state determining unit 312 is configured to: And determining, according to the obtained front/back running state of the at least one guest operating system, whether the guest operating system is currently in the foreground running state.

The first processing module 32 is specifically configured to: if the guest operating system is currently in the foreground running state, use the kernel accelerator running in the host operating system kernel space to input the input event from the host operating system. The kernel space injects a backend program of the guest operating system running in a foreground running state, and the backend program writes the input event into a kernel space of the guest operating system to make the foreground running state The guest operating system is responsive to the input event.

In other embodiments, referring also to FIG. 9, the apparatus 30 further includes a deletion module 33. The deleting module 33 is configured to: when the input event is injected from a kernel space of the host operating system into a kernel space of the guest operating system in a foreground running state, the input event is from the host operating system Cleared in the event list.

In other embodiments, referring also to FIG. 9 , the apparatus 30 further includes a first obtaining module 34 , a second acquiring module 35 , and a sending module 36 . The first obtaining module 34 is configured to read a device file of the input device in the host operating system, and the second acquiring module 35 is configured to acquire configuration information of the input device according to the device file; The sending module 36 is configured to send the configuration information to a kernel space of the guest operating system, so that a driver of the virtual input device corresponding to the input device in the guest operating system is configured according to the configuration information. The virtual input device is configured.

In other embodiments, referring also to FIG. 9, the apparatus 30 further includes a second processing module 37. The second processing module 37 is configured to respond to the input event if the guest operating system is not in the foreground running state.

It should be noted that, since the multi-operating system-based input processing device and the multi-operating system-based input processing method in the foregoing method embodiments are based on the same inventive concept, the corresponding content and beneficial effects of the foregoing method embodiments are also the same. Applicable to the embodiment of the device, and will not be described in detail herein.

The embodiment of the present application provides an input processing device based on multiple operating systems. When the host operating system receives an input event, it determines whether the guest operating system is in the foreground running state, and if it exists in the foreground running state. The guest operating system injects input events from the host operating system into the kernel space of the guest operating system in the foreground running state through a preset data transmission channel, thereby causing the guest operating system to respond to the input event. Since the input event can be directly injected into the kernel space of the guest operating system from the kernel space of the host operating system, the injection time of the input event is shortened, and the performance of the input system in the guest operating system is improved. In addition, input events injected into the guest operating system are cleared from the event list, thereby reducing the risk of the input event being compromised.

Please refer to FIG. 10. FIG. 10 is a schematic structural diagram of hardware of an electronic device according to an embodiment of the present application. The electronic device 40 can be any type of smart terminal, such as a mobile phone, tablet, laptop, desktop computer, server, robot, etc., capable of performing a multi-operating system based input processing method as described above. As shown in FIG. 10, the electronic device 40 includes:

One or more processors 41 and a memory 42 are exemplified by a processor 41 in FIG.

The processor 41 and the memory 42 can be connected by a bus or other means, as exemplified by a bus connection in FIG.

The electronic device that performs the multi-operating system based input processing method may further include: an input device 43 and an output device 44.

The memory 42 is a non-volatile computer readable storage medium for storing non-volatile software programs, non-volatile computer-executable programs, and modules, such as multi-operating system-based input processing in the embodiments of the present application. The corresponding program instructions/modules (e.g., the various modules shown in Figure 9). The processor 41 executes various functional applications and data processing of the server by executing non-volatile software programs, instructions, and modules stored in the memory 42, that is, implementing the input processing method based on multiple operating systems of the above method embodiments.

The memory 42 may include a storage program area and an storage data area, wherein the storage program area may store an operating system, an application required for at least one function; the storage data area may be stored according to use of the multi-operating system based input processing device Data, etc. Moreover, memory 42 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid state storage device. In some embodiments, memory 42 may optionally include memory remotely located relative to processor 41, which may be connected to a multi-operating system based input processing device over a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The input device 43 can receive input numeric or character information and generate key signal inputs related to user settings and function control of the multi-operating system based input processing device. Output device 44 may include a display device such as a display screen.

The one or more modules are stored in the memory 42 and, when executed by the one or more processors 41, perform a multi-operating system based input processing method in any of the above method embodiments, for example, performing the above Method step 201 to step 202 in FIG. 2, method step 2011 to step 2012 in FIG. 3, method step 201 to step 203 in FIG. 5, method step 201 to step 206 in FIG. 6, and in FIG. The method steps 201 to 207 implement the functions of the modules 31-37 and the units 311-312 in FIG.

The above products can perform the methods provided by the embodiments of the present application, and have the corresponding functional modules and beneficial effects of the execution method. For technical details that are not described in detail in this embodiment, reference may be made to the method provided by the embodiments of the present application.

The embodiment of the present application provides a non-transitory computer readable storage medium storing computer-executable instructions that are executed by an electronic device to perform any of the above method embodiments. The multi-operating system-based input processing method, for example, performs the method steps 201 to 202 in FIG. 2, the method steps 2011 to 2012 in FIG. 3, and the method steps 201 to 203 in FIG. The method steps 201 to 206 in FIG. 6 and the method steps 201 to 207 in FIG. 8 implement the functions of the modules 31-37 and the units 311-312 in FIG.

An embodiment of the present application provides a computer program product, including a computing program stored on a non-transitory computer readable storage medium, the computer program comprising program instructions, when the program instructions are executed by a computer, The computer executes the multi-operating system based input processing method in any of the above method embodiments, for example, performs the method steps 201 to 202 in FIG. 2 described above, the method steps 2011 to 2012 in FIG. 3, and the method in FIG. The method steps 201 to 203, the method steps 201 to 206 in FIG. 6, and the method steps 201 to 207 in FIG. 8 implement the functions of the modules 31-37 and the units 311-312 in FIG.

The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, ie may be located A place, or it can be distributed to multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the embodiment.

Through the description of the above embodiments, those skilled in the art can clearly understand that the various embodiments can be implemented by means of software plus a general hardware platform, and of course, by hardware. A person skilled in the art can understand that all or part of the process of implementing the above embodiments can be completed by a computer program to instruct related hardware, and the program can be stored in a computer readable storage medium. When executed, the flow of an embodiment of the methods as described above may be included. The storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, and are not limited thereto; in the idea of the present application, the technical features in the above embodiments or different embodiments may also be combined. The steps may be carried out in any order, and there are many other variations of the various aspects of the present application as described above, which are not provided in the details for the sake of brevity; although the present application has been described in detail with reference to the foregoing embodiments, The skilled person should understand that the technical solutions described in the foregoing embodiments may be modified, or some of the technical features may be equivalently replaced; and the modifications or substitutions do not deviate from the embodiments of the present application. The scope of the technical solution.

Claims

A multi-operating system based input processing method, the operating system comprising a host operating system and at least one guest operating system, wherein the method comprises:

When it is detected that the host operating system receives an input event, it is determined whether there is currently a guest operating system in a foreground running state;

If present, injecting the input event from a kernel space of the host operating system into a kernel space of the guest operating system in a foreground running state through a preset data transmission channel, so as to be in the foreground running state The guest operating system responds to the input event.
The method according to claim 1, wherein the determining whether the guest operating system is currently in a foreground running state comprises:

Reading, from the virtual switching device corresponding to the at least one guest operating system, a front/back running state of the at least one guest operating system;

And determining, according to the obtained front/back running state of the at least one guest operating system, whether the guest operating system is currently in the foreground running state.
The method according to claim 1, wherein the input event is injected from a kernel space of the host operating system into a kernel space of the guest operating system in a foreground running state through a preset data transmission channel. Specifically, including:

Passing the input event from a kernel space of the host operating system to a backend program of the guest operating system running in a foreground running state by a kernel accelerator running in a kernel space of the host operating system, The end program writes the input event to the kernel space of the guest operating system.
The method according to any one of claims 1 to 3, wherein the method further comprises:

The input event is cleared from the event list of the host operating system after the input event injects kernel space of the guest operating system in a foreground running state from a kernel space of the host operating system.
The method of claim 4, wherein the method further comprises:

Reading a device file of the input device in the host operating system;

Obtaining configuration information of the input device according to the device file;

Sending the configuration information to a kernel space of the guest operating system, so that a driver of the virtual input device corresponding to the input device in the guest operating system configures the virtual input device according to the configuration information.
The method of claim 1 further comprising:

If there is currently no guest operating system in the foreground running state, the host operating system responds to the input event.
An input processing device based on a multi-operating system, the operating system comprising a host operating system and at least one guest operating system, wherein the device comprises a judging module and a first processing module;

The determining module is configured to: when it is detected that the host operating system receives an input event, determine whether the guest operating system is currently in a foreground running state;

The first processing module is configured to: when the guest operating system is currently in a foreground running state, inject the input event from the kernel space of the host operating system into the client in a foreground running state through a preset data transmission channel; The kernel space of the operating system to cause the guest operating system in the foreground operating state to respond to the input event.
The apparatus according to claim 7, wherein said determining module comprises a data reading unit and a state determining unit;

The data reading unit is configured to read a front/back running state of the at least one guest operating system from a virtual switching device corresponding to the at least one guest operating system;

The state determining unit is configured to determine, according to the obtained front/back running state of the at least one guest operating system, whether the guest operating system is currently in a foreground running state.
The device according to claim 7, wherein the first processing module is specifically configured to:

If the guest operating system is currently in the foreground running state, the input event is injected from the kernel space of the host operating system into the client running in the foreground running state by a kernel accelerator running in the kernel space of the host operating system. a backend program of the operating system, the input event being written by the backend program to a kernel space of the guest operating system to cause the guest operating system of the foreground running state to respond to the input event.
The device according to any one of claims 7 to 9, wherein the device further comprises a deletion module;

The deleting module, configured to: when the input event is injected from a kernel space of the host operating system into a kernel space of the guest operating system in a foreground running state, the event of the input event from the host operating system Cleared in the list.
The device according to claim 10, wherein the device further comprises a first obtaining module, a second acquiring module, and a sending module;

The first obtaining module is configured to read a device file of the input device in the host operating system;

The second obtaining module is configured to acquire configuration information of the input device according to the device file;

The sending module is configured to send the configuration information to a kernel space of the guest operating system, so that a driver of the virtual input device corresponding to the input device in the guest operating system is configured according to the configuration information. The virtual input device is configured.
The method of claim 1 wherein said apparatus further comprises a second processing module;

The second processing module is configured to respond to the input event if the guest operating system is not in a foreground running state.
An electronic device, comprising:

At least one processor; and,

a memory communicatively coupled to the at least one processor; wherein

The memory stores an instruction program executable by the at least one processor, the instruction program being executed by the at least one processor to cause the at least one processor to perform the method of any one of claims 1 to 6. Methods.
A non-transitory computer readable storage medium, wherein the non-transitory computer readable storage medium stores computer-executable instructions for causing a computer to perform claims 1 to 6 The method of any of the preceding claims.
A computer program product, comprising: a computer program stored on a non-transitory computer readable storage medium, the computer program comprising program instructions, when the program instructions are executed by a computer, The computer is caused to perform the method of any one of claims 1 to 6.