WO2020147544A1 - 应用程序恢复运行的方法、装置及计算机 - Google Patents

应用程序恢复运行的方法、装置及计算机 Download PDF

Info

Publication number
WO2020147544A1
WO2020147544A1 PCT/CN2019/128560 CN2019128560W WO2020147544A1 WO 2020147544 A1 WO2020147544 A1 WO 2020147544A1 CN 2019128560 W CN2019128560 W CN 2019128560W WO 2020147544 A1 WO2020147544 A1 WO 2020147544A1
Authority
WO
WIPO (PCT)
Prior art keywords
context
virtual machine
application program
operating system
application
Prior art date
Application number
PCT/CN2019/128560
Other languages
English (en)
French (fr)
Inventor
肖威
江洋洋
林子畅
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP19910376.3A priority Critical patent/EP3846028A4/en
Publication of WO2020147544A1 publication Critical patent/WO2020147544A1/zh
Priority to US17/369,546 priority patent/US20210334125A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/301—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is a virtual computing platform, e.g. logically partitioned systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45541—Bare-metal, i.e. hypervisor runs directly on hardware
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45545—Guest-host, i.e. hypervisor is an application program itself, e.g. VirtualBox
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/461—Saving or restoring of program or task context
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45579—I/O management, e.g. providing access to device drivers or storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45591—Monitoring or debugging support
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/815—Virtual

Definitions

  • This application relates to the field of computer technology, and in particular to a method, device and computer for restoring operation of an application program.
  • Virtualization technology is a technology that abstracts hardware resources such as the processor and memory of a computer (or physical host) into multiple virtual resources for use by multiple virtual machines, thereby effectively improving the resource utilization of the physical host.
  • the physical host adopting the virtualization architecture mainly includes: a hardware layer composed of hardware resources, a host operating system (host OS) running on the hardware layer, and a virtual machine monitor (host OS) running on the host OS. virtual machine monitor, VMM), and multiple virtual CPUs (virtual CPUs, VCPUs) running on the VMM.
  • one or more VCPUs run on a virtual machine (virtual machine, VM), and each VM may include a guest operating system (guest operating system, guest OS) and applications running on the guest OS (application program). , APP).
  • the APP when the APP triggers a system call or exception, or receives an interrupt, if the physical host needs to trap from the guest OS to the VMM for processing, the guest OS stores the APP context and the guest OS traps to the VMM. Then the VMM stores the context of the guest OS and performs related processing.
  • the physical host needs to resume running the APP, the context of the guest OS can be restored through the VMM and the VMM will fall into the guest OS. After that, you can restore the APP context through the guest OS and continue to run the APP.
  • trapping means that the system control of the physical host is switched from guest OS to VMM, and trapping means that the system control right of the physical host is switched from VMM to guest OS. It can be seen that when trapping or sinking occurs from the physical host, restoring the operation of the APP requires many operations such as context saving and restoring, which results in slow restoration of the APP.
  • This application provides a method, a device and a computer for resuming operation of an application program to speed up the resuming operation of an application program.
  • this application provides a method for resuming operation of an application program, which can be applied to a computer (or called a physical host) that adopts a virtualization architecture.
  • the computer may include: a virtual machine monitor, a guest operating system running on the virtual machine monitor, and an application program running on the guest operating system.
  • the method may include: suspending the running of the application program and trapping the guest operating system to the virtual machine monitor, and then the virtual machine monitor stores the recovery information of the application program.
  • the recovery information may include the context of the application program or the virtual machine monitor. The storage address of the context.
  • the virtual machine monitor restores the context of the application program based on the recovery information and sinks into the guest operating system, so that the application program can resume running, that is, the application program can resume running in the state when it was last suspended.
  • the virtual machine monitor can directly restore the context of the application during the process of restoring the running application without first restoring the context of the guest operating system and then restoring the context of the application through the guest operating system, which effectively speeds up The application resumes operation.
  • the running of the application in response to the trap request, is suspended, that is, the running of the application is suspended when the trap request is detected.
  • the trap request may be triggered by any of the following events: a system call triggered by the application; an exception triggered by the application; and an interrupt reported by the hardware layer of the physical host. It can also be understood this way: system calls, exceptions, or interrupts themselves are trapped requests or part of trapped requests.
  • the operation of the application program is resumed in response to the application program's recovery request, that is, when the application program's recovery request is detected, the execution of the application context recovery operation is triggered.
  • the recovery request can be triggered by a signal sent by other processes in the virtual machine monitor that needs to be processed by the application program, or it can be triggered automatically after the virtual machine monitor has processed the operation indicated by the trap request, or, It can be triggered when the virtual machine scheduler in the virtual machine monitor detects that the virtual machine to which the application belongs needs to be scheduled according to the scheduling algorithm, or it can be triggered by manual configuration or sending instructions.
  • VMM virtual machine monitor
  • hypervisor hypervisor
  • the method may further include: the guest operating system obtains the recovery information of the application, and transmits the recovery information of the application to The virtual machine monitor.
  • the guest operating system obtains the recovery information of the application, and transmits the recovery information of the application to The virtual machine monitor.
  • the recovery information when transferring the recovery information to the virtual machine monitor, it can be transferred in a shared register mode or in a call interface mode. The above two methods are more efficient in transferring recovery information, and can ensure the efficiency of application recovery.
  • the method may further include: the guest operating system transfers the storage address of the context of the guest operating system to the virtual machine monitor; correspondingly
  • the process of storing the recovery information of the application by the virtual machine monitor may include: the storage address of the virtual machine monitor based on the context of the guest operating system, and the storage address of the context of the guest operating system and the context of the application The relationship between the storage address of the context determines the storage address of the context of the application; the virtual machine monitor stores the storage address of the context of the application, or stores the context of the application according to the storage address of the context of the application .
  • the storage address of the context of the guest operating system is transferred to the virtual machine monitor through the guest operating system, and the virtual machine monitor stores the recovery information of the application program through the storage address, which improves the storage application of the virtual machine monitor The flexibility of the program's recovery information.
  • the virtual machine monitor when the recovery information is the context of the application, stores the context of the application in at least one of the following storage locations: the control structure of the virtual machine to which the application belongs; the application The management structure of the process corresponding to the virtual processor to which the program belongs; and the storage location in the memory of the physical host excluding the control structure and the management structure.
  • the virtual machine monitor can also store the context of the application in any other storage location such as the hard disk of the physical host.
  • the control structure may be a virtual machine management structure (VM control structures, VMCS).
  • the management structure may be a task structure (task_struct).
  • the method may further include: when a debugging instruction for the application is detected, a debugging tool installed in the host operating system is based on the The storage address of the application context in the management structure is used to debug the application. Since the application context is stored in the management structure of the process corresponding to the virtual processor to which the application program belongs, when the virtual machine monitor detects a debugging instruction for the application program, the management structure can be based on the context of the application program. The storage address in the body, the application can be debugged directly by the debugging tool. The debugging process does not need to adapt the debugging tool, which effectively improves the debugging efficiency of the application program.
  • the process of the virtual machine monitor recovering the context of the application program may include: the virtual machine monitor stores the context of the application program in a corresponding register. Store the context of the application program in the corresponding register, and the application program can continue to run from the state when it was last suspended.
  • the trap request can be triggered by any of the following requests: a system call triggered by the application program; an exception triggered by the application program; and an interrupt reported by the hardware layer of the physical host. It can also be understood this way: system calls, exceptions, or interrupts themselves are trapped requests or part of trapped requests.
  • the present application provides a computer.
  • the computer (or physical host) may include: a hardware layer, a virtual machine monitor running on the hardware layer, and client operations running on the virtual machine monitor The system, and the applications running on the client operating system.
  • the components in the computer can be used to implement the method for restoring operation of the application program provided in the foregoing aspect. These components can be hardware, software, or a combination of hardware and software.
  • the present application provides a device for restoring the operation of an application program.
  • the device includes a plurality of modules, and the plurality of modules are used to implement the method for restoring operation of the application program provided in the foregoing aspect.
  • the device can be deployed on a computer and run by the computer to implement the aforementioned method.
  • the computer (or physical host) includes a virtual machine monitor, a guest operating system running on the virtual machine monitor, and an application program running on the guest operating system.
  • the various modules of the device can be distributed in the guest operating system and virtual machine monitor.
  • this application provides a computer-readable storage medium or a computer program (product).
  • the computer-readable storage medium or the computer program stores instructions.
  • the processor reads the computer-readable storage medium Or the instruction line stored in the computer program causes the processor to execute the method for resuming operation of the application program provided in the above aspect.
  • the present application provides a device for resuming operation of an application program.
  • the device may include a memory, a processor, and a computer program stored in the memory and running on the processor, and the processor executes the computer program.
  • the program implements the method for restoring operation of the application as provided in the above aspects.
  • the embodiments of the present invention provide a method, device, and computer for resuming operation of an application program.
  • the solution can store the context of the application program or the context of the application program through a virtual machine monitor after the operation of the application program is suspended.
  • the address is stored, so that the context of the application program can be directly restored through the virtual machine monitor when the operation of the application program needs to be restored.
  • FIG. 1 is an architecture diagram of a physical host using virtualization technology provided by an embodiment of the present invention
  • Figure 2 is an architecture diagram of another physical host using virtualization technology provided by an embodiment of the present invention.
  • FIG. 3 is a flowchart of a method for resuming operation of an application program provided by an embodiment of the present invention
  • FIG. 4 is an execution flowchart of a method for resuming operation of an application program according to an embodiment of the present invention
  • FIG. 5 is an architecture diagram of another physical host using virtualization technology provided by an embodiment of the present invention.
  • FIG. 6 is a flowchart of another method for resuming operation of an application program provided by an embodiment of the present invention.
  • FIG. 7 is an execution flowchart of another application program resume operation provided by an embodiment of the present invention.
  • FIG. 8 is a flowchart of another method for resuming operation of an application program according to an embodiment of the present invention.
  • FIG. 9 is an execution flow chart of another application program resume operation provided by an embodiment of the present invention.
  • FIG. 10 is a flowchart of another method for resuming operation of an application program according to an embodiment of the present invention.
  • FIG. 11 is an execution flow chart of yet another application program resume operation provided by an embodiment of the present invention.
  • FIG. 12 is a schematic structural diagram of a device for resuming operation of an application program according to an embodiment of the present invention.
  • FIG. 13 is a schematic structural diagram of another apparatus for resuming operation of an application program according to an embodiment of the present invention.
  • FIG. 14 is a schematic structural diagram of another apparatus for resuming operation of an application program according to an embodiment of the present invention.
  • FIG. 1 is an architecture diagram of a physical host using virtualization technology provided by an embodiment of the present invention.
  • the physical host can also be called a computer.
  • a physical host may include: a hardware layer 10, a host operating system (host OS) 20 running on the hardware layer 10, a VMM 30 running on the host OS 20, and a host operating on the VMM 30.
  • VCPU 40 For example, Figure 1 shows two VCPUs: VCPUa and VCPUb.
  • each VCPU 40 runs a VM 41
  • each VM 41 includes a guest operating system (guest OS) 42 and at least one APP 43 running on the guest OS 42.
  • guest OS guest operating system
  • each VM 41 includes an APP 43.
  • at least one may refer to one or more, and multiple may refer to two or more.
  • the hardware layer 10 may include one or more physical processors (physical CPUs), physical storage devices (such as memory and hard disks), network interfaces, peripherals and other hardware devices.
  • the host OS 20 can be a Linux operating system.
  • VMM 30, also called hypervisor, is a software middleware that runs between the hardware layer 10 and each VCPU 40, and is used to coordinate the hardware resources of the hardware layer 10 to each VCPU 40 for the guest operating system 42 and application 43 run.
  • the VMM 30 may coordinate the processing resources of the physical CPUs to provide each VCPU 40.
  • the VMM 30 can run on the host OS 20.
  • the VMM 30 may also be deployed independently of the host OS 20, that is, the VMM 30 may directly run on the hardware layer 10.
  • the host OS 20 may not be deployed in the physical host.
  • the embodiment of the present invention does not limit the architecture of the physical host.
  • the guest OS 42 can be a library operating system (library OS, LibOS).
  • library OS LibOS
  • LibOS is also called unikernel, which is a lightweight virtualization technology that uses the OS outer core architecture to abstract the functions of the OS into libraries. Provides library files, joint file system, common file system and functions to perform various operations and interact with other modules.
  • VMM 30 performs processing, and the context of APP 43 can be stored by guest OS 42 in VM 40, and the context of APP 43 can be trapped from guest OS 42 to VMM 30. After that, the context of the guest OS 42 can be stored through the VMM 30 and related processing can be performed.
  • the context of the guest OS 42 can be restored through the VMM 30 and the VMM 30 will fall into the guest OS 42. Finally, the context of APP 43 can be restored through guest OS 42 and continue to run APP 43.
  • the method in the related technology needs to restore the context of guest OS 42 through VMM 30 first, and then restore the context of APP 43 through guest OS 42 in the process of resuming the operation of the APP , The efficiency of resuming the operation of APP 43 is low.
  • the embodiment of the present invention provides a method for resuming operation of an application program.
  • the method can be applied to the physical host shown in FIG. 1 or FIG. 2. This method can solve the problem of low efficiency when the physical host resumes running APP in related technologies. Problems can be used to speed up the speed of application recovery.
  • the method may include:
  • Step 101 In response to the trap request, the client operating system suspends running the application program.
  • the trap request can be triggered by any of the following events: a system call triggered by an application, an exception triggered by an application, and an interrupt reported by the hardware layer of the physical host. It can also be understood this way: system calls, exceptions, or interrupts themselves are trapped requests or part of trapped requests.
  • the system call can be a service request sent by the application program to the client operating system.
  • the exception may be a processing request sent to the client operating system due to an execution failure of the current instruction of the application program (due to an illegal instruction or a memory page shortage).
  • Interrupts can be input/output (I/O) interrupts sent by peripherals of the hardware layer to the guest operating system, or inter-processor interrupts sent by the physical CPU to the guest operating system. , IPI). That is, when the physical host detects a system call or an exception sent by the application program or an interrupt request sent by the hardware layer while the application program is running in the guest operating system, the application program can be suspended. At this time, the system control right of the physical host is switched from the application to the guest operating system, that is, the application is trapped to the guest operating system.
  • Step 102 The client operating system obtains the recovery information of the application.
  • the physical host can obtain the recovery information of the application program through the guest operating system.
  • the recovery information may include the context of the application program or the storage address of the context, and the storage address may be the storage address of the context in the memory.
  • the context of the application program may include information required to resume running the application program, for example, may include related data of the application program recorded in the register when the application program is suspended.
  • resuming operation of the application program may refer to restoring the operation of the application program to the state when it was last suspended.
  • the storage address of the context of APP 43 in the memory can be obtained through guest OS 42.
  • the physical host after the physical host obtains the recovery information of the application program through the guest operating system, it can first determine whether the system call, exception, or interrupt that triggered the trap request can be operated by the client. The system processes. If it can be processed by the client operating system, the client operating system can directly restore the context of the application program and resume running the application program after performing related processing. If processing cannot be performed by the guest operating system, the physical host can continue to perform the following step 103.
  • the physical host can also store the recovery information of the application program through the guest operating system, for example, in a memory, so that after relevant processing is performed through the guest operating system, it can be processed through the guest operating system.
  • the machine operating system directly restores the context of the application.
  • the guest operating system cannot be used for processing, the guest operating system does not need to store the recovery information, but the obtained recovery information can be directly transmitted to the virtual machine monitor through the guest operating system .
  • Step 103 The guest operating system transmits the recovery information of the application program to the virtual machine monitor.
  • the guest operating system when it transmits the recovery information to the virtual machine monitor, it may adopt a register transfer mode or a call interface transfer mode.
  • the way of register transfer can refer to: the guest operating system writes the recovery information of the application program to a register that can be accessed by a virtual machine monitor, and sends the address of the register to the virtual machine monitor.
  • the virtual machine monitor reads the recovery information of the application program from the register indicated by the received address.
  • Calling interface transfer may refer to: the guest operating system directly calls the interface of the virtual machine monitor to transfer the recovery information of the application.
  • Step 104 The guest operating system is trapped to the virtual machine monitor.
  • the guest operating system can be trapped to the virtual machine monitor, that is, the system control of the physical host is controlled by the guest operating system Switch to the virtual machine monitor.
  • the address of the context of APP 43 can be transferred to the VMM 30 through the interface of the guest OS 42 calling the VMM 30, and the guest OS 42 can be trapped to the VMM 30.
  • Step 105 The virtual machine monitor stores the recovery information of the application program.
  • the physical host can store the context of the application through the virtual machine monitor in at least one of the following storage locations: the control structure of the VM to which the application belongs, and the application to which the application belongs
  • the virtual processor corresponds to the management structure of the process and the storage location in the memory of the physical host excluding the control structure and the management structure.
  • each VM in the physical host corresponds to a control structure
  • the control structure may be a virtual machine control structure (VM control structure, VMCS).
  • VM control structure VMCS
  • the process corresponding to each VCPU corresponds to a management structure for managing the process, and the management structure may also be called a process control block (processing control block, PCB).
  • the management structure may be a task structure (task_struct).
  • the physical host can store the context of the application program in the virtual machine control structure, the process management structure, and the memory of the physical host through the virtual machine monitor.
  • the context of the application program can also be stored in multiple storage locations of the foregoing storage locations through the virtual machine monitor.
  • the context of the APP 43 is stored in the VMCS of the VM to which the APP 43 belongs, and the context of the APP 43 is stored in the task_struct of the process corresponding to the VCPU to which the APP 43 belongs.
  • the storage address of the context of the application program can be directly stored through the virtual machine monitor, for example, the storage address can be stored in the memory.
  • the virtual machine monitor can obtain the context of the application from the storage location indicated by the storage address according to the storage address of the context of the application, and store the obtained context of the application.
  • the acquired context of the application can be stored in at least one of the following storage locations through the virtual machine monitor: the control structure of the VM to which the application belongs, the management structure of the process corresponding to the VCPU to which the application belongs, and the physical The storage location in the host's memory except for the control structure and management structure.
  • step 103 can also be replaced by the following step 103a:
  • Step 103a The guest operating system transfers the storage address of the context of the guest operating system to the virtual machine monitor.
  • the guest operating system may also transfer the storage address of the guest operating system's own context to the virtual machine monitor.
  • the storage address of the context of the guest operating system may also refer to the storage address in the memory.
  • the manner of transferring the storage address of the context of the client operating system can refer to the above-mentioned manner of transferring the recovery information of the application program, which will not be repeated here.
  • step 105 may include:
  • Step 1051 The virtual machine monitor determines the context of the application based on the storage address of the context of the guest operating system and the relationship between the storage address of the context of the guest operating system and the context of the application. The storage address.
  • the growth mode of the stack refers to the growth mode of the address of the stack, and the growth mode generally includes upward growth and downward growth.
  • Upward growth means that the address of the stack gradually increases from the bottom of the stack to the top of the stack, that is, the top of the stack is the high address.
  • Increasing downward means that the address of the stack gradually increases from the top of the stack to the bottom of the stack, that is, the bottom of the stack is the high address.
  • the physical host can directly obtain the length of the context of the guest operating system through the virtual machine monitor. If the length of the context of the guest operating system is not a fixed value, when the storage address of the context of the guest operating system is transferred to the virtual machine monitor through the guest operating system, the context of the guest operating system can be synchronously transmitted length.
  • Step 1052 The virtual machine monitor stores the storage address of the context of the application, or stores the context of the application according to the storage address of the context of the application.
  • the virtual machine monitor can directly store the storage address of the application context.
  • the virtual machine monitor may obtain the context of the application from the storage location indicated by the storage address according to the storage address of the context of the application, and store the obtained context of the application.
  • the architecture of the virtual machine monitor and the architecture of the guest operating system may be different.
  • the virtual machine monitor may have a 64-bit architecture
  • the guest operating system may have a 32-bit architecture.
  • recovery information when the recovery information is stored through the virtual machine monitor, in addition to the control structure, management structure and other storage locations in the memory described above, it can also be stored in the physical host. Other arbitrary storage locations such as hard disks are not limited in this embodiment of the present invention.
  • Step 106 In response to the recovery request of the application program, the virtual machine monitor restores the context of the application program, and the virtual machine monitor falls into the guest operating system.
  • the recovery request may be triggered by a signal sent by other processes in the virtual machine monitor that needs to be processed by the application program, or the operation indicated by the trap request may be completed by the virtual machine monitor. Later, it can be triggered automatically, or, it can be triggered when the virtual machine scheduler in the virtual machine monitor detects that the virtual machine to which the application belongs needs to be scheduled according to the scheduling algorithm.
  • Restoring the context of the application program through the virtual machine monitor may refer to: storing (ie copying) the context of the application program from the original storage location to the register corresponding to the application program through the virtual machine monitor so as to resume running the application program.
  • the register corresponding to the application program may refer to the register used when the physical host runs the application program.
  • the context of the application can be directly restored through the virtual machine monitor, without the need to restore the context of the guest operating system by the virtual machine monitor first, and then the context of the application by the guest operating system , It reduces a switch and jump of the client operating system, and effectively improves the efficiency of restoring running applications.
  • improving the efficiency of resuming the running application program also improves the switching efficiency between the VCPUs.
  • the context of the APP 43 can be copied from the task_struct of the process corresponding to the VCPU to which the APP 43 belongs to the register corresponding to the APP 43 through the VMM 30, so that the APP 43 can resume operation.
  • the architecture of the virtual machine monitor and the architecture of the guest operating system may be different. If the context of the application is stored through the virtual machine monitor, the data format of the context of the application is also converted, then when the context of the application is restored, the data format of the context of the application needs to be restored again Perform conversion (for example, a zero removal operation can be performed on the context of the application) to restore the data format of the context of the application, so that the context of the restored application can meet the architectural requirements of the client operating system.
  • conversion for example, a zero removal operation can be performed on the context of the application
  • the host operating system 20 of the physical host may also be equipped with a debugging tool, for example, GNU ("GNU is Not Unix" recursive abbreviation ) Debugger (GNU debugger, GDB) and performance analysis tools (Perf), etc.
  • GNU GNU is Not Unix" recursive abbreviation
  • Debugger GNU debugger, GDB
  • Perf performance analysis tools
  • This debugging tool can debug processes in VMM 30 and APP 43 in VM 40.
  • the context of APP 43 in VM 40 of the related technology is stored in guest OS 42, when APP 43 needs to be debugged through the debugging tool installed in VMM 30, the debugging tool cannot directly know the storage of the context of the application. Therefore, the debugging tool needs to be adapted before APP 43 can be debugged, which results in low debugging efficiency of the application.
  • the method may further include:
  • Step 107 When a debugging instruction for the application program is detected, the debugging tool installed in the host operating system is used, based on the storage address of the application program context in the management structure of the process corresponding to the VCPU to which the application program belongs. The application is debugged.
  • the management structure can be based on the context of the application. Debug the application program directly through the debugging tool. The debugging process does not need to adapt the debugging tool, which effectively improves the debugging efficiency of the application program.
  • each VCPU 40 may correspond to one physical CPU, and the physical CPUs corresponding to different VCPUs 40 may be the same or different. Therefore, each physical CPU may correspond to one or more VCPUs 40.
  • the VMM 30 can coordinate the processing resources of each physical CPU to provide one or more VCPUs 40 corresponding to the physical CPU. Among them, each physical CPU can be a physical core.
  • Each VCPU can correspond to a thread in VMM 30. For example, as shown in Figure 5, VCPUa corresponds to thread a, and VCPUb corresponds to thread b.
  • the VMM 30 can schedule different threads in a physical CPU through a thread scheduling strategy, so that multiple VCPUs 40 corresponding to the same physical CPU can switch and run.
  • the time required for the switching process of the VCPU may include: the time to save the context of the application running in VCPUa, the time to restore the context of the application in VCPUb, and the time to switch from thread a to thread b. The time required.
  • multiple VCPUs 40 corresponding to the same physical CPU can be managed as a VCPU queue, and the VCPU queue can be bound to an agent thread in the VMM 30.
  • thread switching is no longer required, thereby effectively improving the switching efficiency of VCPUs.
  • the switching time of its VCPU is generally about 5 microseconds (us). After the method provided by the embodiment of the present invention is adopted, the time for restoring the context of the application in the VCPU can be effectively increased when the VCPU is switched, so that the switching efficiency of the VCPU can be further improved. For example, the switching time of VCPU can be shortened from 5us to less than 1us.
  • the physical host may be a base station or a server.
  • the application program in the virtual machine running on the physical host may be a mobile communication service application program.
  • the application program in the virtual machine running on the physical host may include the fourth generation mobile communication technology (4G) application program and the fifth generation mobile communication technology 5G application program.
  • 4G fourth generation mobile communication technology
  • 5G fifth generation mobile communication technology
  • step 102 can be deleted according to the situation
  • step 103 can be replaced by step 103a.
  • step 107 can be deleted according to the situation. Any person familiar with the technical field can easily think of a method of change within the technical scope disclosed in this application, which should be covered by the protection scope of this application, and therefore will not be repeated.
  • the embodiment of the present invention provides a method for resuming operation of an application program, which can store the context of the application program or the storage address of the context through the virtual machine monitor after the operation of the application program is suspended, thereby The context of the application can be restored directly through the virtual machine monitor when the operation of the application needs to be restored.
  • the process of restoring running applications there is no need to restore the context of the guest operating system through the virtual machine monitor, and then restore the context of the application through the guest operating system, which reduces the operation of restoring the context, thereby effectively improving the application. Resume the efficiency of operation.
  • FIG. 6 is a flowchart of another method for resuming operation of an application program provided by an embodiment of the present invention. Taking the trap request triggered by an interrupt as an example, the method for resuming operation of the application program is introduced. Referring to Figure 6, the method may include:
  • Step 201 When an interrupt reported by the hardware layer is detected, the guest operating system suspends running the application program.
  • Step 202 The client operating system obtains the recovery information of the application.
  • step 202 For the implementation process of this step 202, refer to the foregoing step 102, which will not be repeated here.
  • Step 203 The guest operating system determines whether the interrupt is handled by the guest operating system.
  • an interrupt distribution list may be stored in the guest operating system, and the interrupt distribution list may record a VCPU corresponding to each interrupt.
  • the guest operating system can determine the VCPU corresponding to the currently detected interrupt according to the interrupt distribution list, and determine whether the VCPU corresponding to the interrupt is a VCPU supporting the operation of the guest operating system (that is, the VCPU to which the guest operating system belongs).
  • step 204 can be executed. If the VCPU corresponding to the interrupt is not the VCPU to which the guest operating system belongs, it can be determined that the interrupt is not handled by the guest operating system, and therefore the following step 205 can be continued.
  • Step 204 The guest operating system processes the interrupt, restores the context of the application program after the processing is completed, and resumes running the application program.
  • the interrupt can be processed directly through the guest operating system, and after the processing is completed, the application program can be restored directly through the guest operating system. Context, and resume running the application.
  • Step 205 The guest operating system transmits the recovery information of the application program to the virtual machine monitor, and the guest operating system traps it to the virtual machine monitor.
  • Step 206 The virtual machine monitor stores the recovery information of the application program.
  • step 205 and step 206 For the implementation process of the foregoing step 205 and step 206, reference may be made to the relevant description of the foregoing step 103 to step 105, which will not be repeated here.
  • Step 207 Switch to the virtual processor corresponding to the interrupt, and process the interrupt through the guest operating system running on the corresponding virtual processor.
  • the virtual machine monitor when the trap request is triggered by an interrupt, after the system control of the physical host is trapped by the guest operating system to the virtual machine monitor, the virtual machine monitor can determine which interrupt corresponds to The virtual processor is switched to the corresponding virtual processor, so that the interrupt is processed through the guest operating system running on the corresponding virtual processor.
  • the physical host may determine the virtual processor corresponding to the interrupt according to the interrupt distribution list through the virtual machine monitor. Or, when the guest operating system is trapped in the virtual machine monitor, the identifier of the virtual processor corresponding to the interrupt can be directly transferred to the virtual machine monitor through the guest operating system, so that the virtual machine monitor can directly Switch to the virtual processor indicated by the logo.
  • VMM 30 can switch to run VCPUb, and process the interrupt through guest OS 42 running on VCPUb.
  • Step 208 When the recovery request of the application program is detected, the virtual machine monitor restores the context of the application program, and the virtual machine monitor falls into the guest operating system.
  • the physical host when the physical host detects through the VMM 30 that the guest OS 42 running on the VCPUb has completed the interrupt processing, it can trigger the recovery request of the APP 43 in the VCPUa and restore the context of the APP 43 through the VMM 30.
  • the VMM 30 Fall into the guest OS 42, so that the APP 43 can be resumed.
  • FIG. 8 is a flowchart of another method for resuming operation of an application program provided by an embodiment of the present invention. Taking the trap request being triggered by a system call or an exception as an example, the method for resuming operation of the application program is introduced. Referring to Figure 8, the method may include:
  • Step 301 When a system call or abnormality triggered by an application program is detected, the client operating system stops running the application program.
  • APP 43 triggers a system call during the process of running APP 43 in the VCPUa
  • the operation of APP 43 can be suspended through the VCPUa, and the APP 43 can be trapped to the guest OS 42.
  • Step 302 The client operating system obtains the context of the application.
  • step 302 For the implementation process of this step 302, refer to the foregoing step 102, which will not be repeated here.
  • Step 303 The guest operating system determines whether the system call or exception is handled by the guest operating system.
  • the client operating system may store a processing function list, and the processing function list may record the types of system calls or exceptions that it can handle.
  • the physical host can determine whether the system call or exception can be directly processed by the guest operating system according to the processing function list through the guest operating system.
  • step 304 can be executed; if the guest operating system determines that the system call or exception cannot be handled by the guest operating system Processing, you can continue to perform the following step 305.
  • Step 304 The client operating system processes the system call or exception, restores the context of the application program after the processing is completed, and resumes running the application program.
  • the system call or exception can be processed directly through the guest operating system, and the client can operate after the processing is completed.
  • the system restores the context of the application and resumes running the application.
  • Step 305 The guest operating system transmits the recovery information of the application program to the virtual machine monitor, and the guest operating system traps it to the virtual machine monitor.
  • the recovery information of the application program can be transferred to the virtual machine monitor through the guest operating system, and the guest operating system can operate it The system is stuck to the virtual machine monitor.
  • Step 306 The virtual machine monitor stores the recovery information of the application program.
  • step 305 and step 306 For the implementation process of the foregoing step 305 and step 306, reference may be made to the relevant description in the foregoing step 103 to step 105, which will not be repeated here.
  • Step 307 The virtual machine monitor processes the system call or exception.
  • the virtual machine monitor can handle the system call or exception.
  • Step 308 When the recovery request of the application program is detected, the virtual machine monitor restores the context of the application program, and the virtual machine monitor falls into the guest operating system.
  • the physical host when the physical host completes the processing of the system call through the VMM 30, it can trigger the recovery request of the APP 43 in the VCPUa, and restore the context of the APP 43 through the VMM 30, and the VMM 30 falls into the guest OS 42.
  • the APP can be resumed to run 43.
  • step 308 For the implementation process of the foregoing step 308, reference may be made to the related description of step 106, which will not be repeated here.
  • FIG. 10 is a flowchart of another method for resuming operation of an application program provided by an embodiment of the present invention. Taking the signal sent by the restoring request for other processes as an example, the method for restoring the running of the application is introduced. Referring to FIG. 10, the method may include:
  • Step 401 When a signal sent by another process that requires the application to be processed is detected, the virtual machine monitor restores the context of the application, and the virtual machine monitor sinks into the guest operating system.
  • the APP 43 can be restored through the VMM 30
  • the VMM 30 falls into the guest OS 42, so that the APP 43 can be resumed.
  • the context of the APP 43 may be stored through the VMM 30 when the APP 43 was suspended last time.
  • step 401 For the implementation process of the foregoing step 401, reference may be made to the related description of step 106, which will not be repeated here.
  • Step 402 The application program performs related processing.
  • the APP 43 in the VCPUa can perform related processing on the signal that triggers its resumption.
  • Step 403 When a trap request is detected, the client operating system stops running the application program.
  • Step 404 The client operating system obtains the recovery information of the application program.
  • Step 405 The guest operating system transmits the recovery information of the application program to the virtual machine monitor, and the guest operating system traps it to the virtual machine monitor.
  • Step 406 The virtual machine monitor stores the recovery information of the application program.
  • step 403 to step 406 For the implementation process of the foregoing step 403 to step 406, reference may be made to the relevant description in the foregoing step 101 to step 105, which will not be repeated here.
  • the embodiment of the present invention provides a method for resuming operation of an application program, which can store the context of the application program or the storage address of the context through the virtual machine monitor after the operation of the application program is suspended, thereby The context of the application can be restored directly through the virtual machine monitor when the operation of the application needs to be restored.
  • the process of restoring running applications there is no need to restore the context of the guest operating system through the virtual machine monitor, and then restore the context of the application through the guest operating system, which reduces the operation of restoring the context, thereby effectively improving the application. Resume the efficiency of operation.
  • the embodiment of the present invention also provides a physical host.
  • the physical host may include: a hardware layer 10, a virtual machine monitor 30 running on the hardware layer 10, and running on the virtual machine.
  • the guest operating system 42 may be used to suspend the running of the application program 43 in response to a trap request and trap to the virtual machine monitor 30.
  • the virtual machine monitor 30 may be used to store the recovery information of the application 43, and the recovery information includes the context of the application 43 or the storage address of the context.
  • the virtual machine monitor 30 is also used to respond to the recovery request of the application 43, recover the context of the application 43 based on the recovery information, and sink into the guest operating system 42, so that the application 43 can be recovered run.
  • the guest operating system 42 can also be used to:
  • the recovery information of the application program 43 is acquired; the recovery information of the application program 43 is transferred to the virtual machine monitor 30.
  • the guest operating system 42 can be used to write the recovery information to a register accessible by the virtual machine monitor or call the interface of the virtual machine monitor, and transfer the recovery information of the application 43 to the virtual machine monitor.
  • Machine monitor 30 can be used to write the recovery information to a register accessible by the virtual machine monitor or call the interface of the virtual machine monitor, and transfer the recovery information of the application 43 to the virtual machine monitor.
  • the guest operating system 42 is also used to transfer the storage address of the context of the guest operating system 42 to the virtual machine monitor 30.
  • the virtual machine monitor 30 can be used for:
  • the storage address of the context of the application 43 is determined ;
  • the storage address of the context of the application 43 is stored, or the context of the application 43 is stored according to the storage address of the context of the application 43.
  • the recovery information is the context of the application 43; the virtual machine monitor 30 is used to store the context of the application 43 in at least one of the following storage locations: the memory of the physical host; the application The control structure of the virtual machine to which 43 belongs; and the management structure of the process corresponding to the virtual processor to which the application 43 belongs.
  • the context of the application program 43 is stored in the management structure.
  • the physical host may further include: a host operating system 20 running on the hardware layer 10, and a debugging tool installed in the host operating system 20 (not shown in FIG. 1).
  • the debugging tool may be used to debug the application 43 based on the storage address of the context of the application 43 in the management structure when a debugging instruction for the application 43 is detected.
  • the virtual machine monitor 30 may be used to store the context of the application program 43 in a corresponding register.
  • the trap request is triggered by any of the following requests: a system call triggered by the application 43; an exception triggered by the application 43; and an interrupt reported by the hardware layer 10 of the physical host.
  • the embodiment of the present invention provides a physical host, and the guest operating system in the physical host can store the context of the application or the storage of the context through the virtual machine monitor after the operation of the application is suspended. Address, so that the context of the application can be directly restored through the virtual machine monitor when the running of the application needs to be restored. In the process of restoring running applications, there is no need to restore the context of the guest operating system through the virtual machine monitor, and then restore the context of the application through the guest operating system, which reduces the operation of restoring the context, thereby effectively improving the application. Resume the efficiency of operation.
  • FIG. 12 is a schematic structural diagram of another apparatus for resuming operation of an application program provided by an embodiment of the present invention.
  • the apparatus may be applied to the physical host shown in FIG. 1, FIG. 2 or FIG.
  • the device may include:
  • the suspension module 501 deployed in the guest operating system is used to respond to the trap request, suspend running the application program and trap the guest operating system to the virtual machine monitor.
  • the storage module 502 deployed in the virtual machine monitor is used to store the recovery information of the application, and the recovery information includes the context of the application or the storage address of the context.
  • the recovery module 503 deployed in the virtual machine monitor is used to respond to the recovery request of the application program, recover the context of the application program based on the recovery information, and sink the guest operating system into the guest operating system.
  • the apparatus may further include:
  • the acquiring module 504 deployed in the guest operating system is used to acquire the recovery information of the application before being trapped in the virtual machine monitor.
  • the delivery module 505 deployed in the client operating system is used to deliver the recovery information of the application to the virtual machine monitor.
  • the transfer module 505 can be used to: write the recovery information to a register accessible by the virtual machine monitor or call the interface of the virtual machine monitor, and transfer the recovery information of the application to the virtual machine monitor. Device.
  • the transfer module 505 may be used to transfer the storage address of the context of the guest operating system to the virtual machine monitor before being trapped by the guest operating system to the virtual machine monitor.
  • the storage module 502 may be used to determine the storage address of the context of the guest operating system based on the relationship between the storage address of the context of the guest operating system and the storage address of the context of the application program.
  • the recovery information is the context of the application; the storage module 502 can be used to:
  • the context of the application program is stored in at least one of the following storage locations: the memory of the physical host; the control structure of the virtual machine to which the application program belongs; and the management structure of the process corresponding to the virtual processor to which the application program belongs.
  • the context of the application program may be stored in the management structure; as shown in FIG. 13, the device may further include:
  • the debugging module 506 deployed in the host operating system is used to debug the application based on the storage address of the context of the application in the management structure when a debugging instruction for the application is detected.
  • the restoration module 503 may be used to store the context of the application program in a corresponding register.
  • the trap request is triggered by any of the following requests: a system call triggered by the application program; an exception triggered by the application program; and an interrupt reported by the hardware layer of the physical host.
  • the embodiment of the present invention provides a device for resuming operation of an application program.
  • the guest operating system in the device can store the context or the context of the application program through the virtual machine monitor after suspending the operation of the application program.
  • the storage address of the context so that the context of the application can be directly restored through the virtual machine monitor when the running of the application needs to be restored.
  • ASIC application-specific integrated circuit
  • PLD programmable logic device
  • ASIC application-specific integrated circuit
  • PLD programmable logic device
  • It is a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof.
  • CPLD complex programmable logical device
  • FPGA field-programmable gate array
  • GAL generic array logic
  • the method for resuming operation of the application program provided in the above method embodiment can also be implemented by software.
  • each module in the device for resuming operation of the application program may also be Software module.
  • FIG. 14 is a schematic structural diagram of another computer provided by an embodiment of the present invention.
  • the computer may include: a processor 1201, a memory 1202, a network interface 1203, and a bus 1204.
  • the bus 1204 is used to connect the processor 1201, the memory 1202, and the network interface 1203.
  • the communication connection with other devices can be realized through the network interface 1203 (which can be wired or wireless).
  • a computer program 12021 is stored in the memory 1202, and the computer program 12021 is used to implement various application functions.
  • the processor 1201 may be a CPU, and the processor 1201 may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays ( FPGA), GPU or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
  • DSP digital signal processors
  • ASIC application-specific integrated circuits
  • FPGA field programmable gate arrays
  • GPU GPU or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
  • the general-purpose processor may be a microprocessor or other types of processors.
  • the memory 1202 may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memory.
  • the non-volatile memory can be read-only memory (read-only memory, ROM), programmable read-only memory (programmable ROM, PROM), erasable programmable read-only memory (erasable PROM, EPROM), electronically Erasable programmable read-only memory (electrically EPROM, EEPROM) or flash memory.
  • Volatile memory can be random access memory (random access memory, RAM), which acts as an external cache.
  • RAM random access memory
  • SRAM static random access memory
  • DRAM dynamic random access memory
  • SDRAM synchronous dynamic random access memory
  • Double data rate synchronous dynamic random access memory double data date SDRAM, DDR SDRAM
  • enhanced SDRAM enhanced synchronous dynamic random access memory
  • SLDRAM synchronous connection dynamic random access memory
  • direct rambus RAM direct rambus RAM
  • bus 1204 may also include a power bus, a control bus, and a status signal bus. However, for clear description, various buses are marked as bus 1204 in the figure.
  • the processor 1201 is configured to execute a computer program stored in the memory 1202, and the processor 1201 executes the computer program 12021 to implement the steps in any of the foregoing method embodiments.
  • the software program in the memory can be divided into multiple modules using the module division method provided in the foregoing embodiment, or other module division methods can also be used.
  • the embodiment of the present invention also provides a computer-readable storage medium, the computer-readable storage medium stores instructions, and when the processor reads the instructions stored in the computer-readable storage medium, the processor is caused to execute the above-mentioned method Steps in the embodiment.
  • the embodiment of the present invention also provides a computer program product containing instructions.
  • the processor reads the instructions contained in the computer program product, the processor is caused to execute the steps in the foregoing method embodiments.
  • the above embodiments can be implemented in whole or in part by software, hardware, firmware, or any other combination.
  • the above-described embodiments may be fully or partially implemented in the form of computer program products.
  • the computer program product includes one or more computer instructions.
  • the computer program instructions When the computer program instructions are loaded or executed on the computer, the processes or functions according to the embodiments of the present invention are generated in whole or in part.
  • the computer may be a general-purpose computer, a dedicated computer, a computer network, or other programmable devices.
  • the computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be from a website site, computer, server or data center Transmission to another website, computer, server or data center via wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.).
  • the computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or a data center that contains one or more collections of available media.
  • the usable medium may be a magnetic medium (for example, a floppy disk, a hard disk, and a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium.
  • the semiconductor medium may be a solid state drive (SSD).

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Quality & Reliability (AREA)
  • Mathematical Physics (AREA)
  • Computer Hardware Design (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Stored Programmes (AREA)
  • Debugging And Monitoring (AREA)

Abstract

一种应用程序恢复运行的方法、装置及计算机，涉及虚拟化技术。该方法可以在应用程序被中止运行之后，通过该虚拟机监视器存储该应用程序的上下文，从而可以在检测到该应用程序的恢复请求时，直接通过该虚拟机监视器恢复该应用程序的上下文，即恢复该应用程序的运行。由于该恢复运行应用程序的过程中无需先通过虚拟机监视器恢复客户机操作系统的上下文，再通过客户机操作系统恢复应用程序的上下文，减少了一次恢复上下文的操作，从而加快了应用程序恢复运行的速度。

Description

应用程序恢复运行的方法、装置及计算机
本申请要求于2019年01月18日提交的申请号为201910049860.7、发明名称为“应用程序恢复运行的方法、装置及计算机”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及计算机技术领域，特别涉及一种应用程序恢复运行的方法、装置及计算机。
背景技术
虚拟化技术是一种将计算机(或称物理主机)的处理器和存储器等硬件资源抽象为多份虚拟资源供多个虚拟机使用，从而有效提高物理主机资源利用率的技术。采用虚拟化架构的物理主机的主要包括：由硬件资源组成的硬件层，运行于该硬件层上的主机操作系统(host operating system，host OS)，运行于该host OS中的虚拟机监视器(virtual machine monitor，VMM)，以及运行于该VMM上的多个虚拟CPU(virtual CPU，VCPU)。其中，一个或多个VCPU上运行有一个虚拟机(virtual machine，VM)，每个VM可以包括一个客户机操作系统(guest operating system，guest OS)以及运行于该guest OS上的应用程序(application，APP)。
相关技术中，当APP触发系统调用或异常，或者收到中断时，物理主机如果需要从guest OS中陷出到VMM进行处理，则由guest OS存储APP的上下文并由guest OS陷出到VMM。然后VMM存储guest OS的上下文并进行相关处理。当物理主机需要恢复运行该APP时，可以通过VMM恢复guest OS的上下文并由VMM陷入guest OS。之后，可以通过guest OS恢复APP的上下文并继续运行APP。其中，陷出是指物理主机的系统控制权由guest OS切换至VMM，陷入是指物理主机的系统控制权由VMM切换至guest OS。可以看出，当从物理主机发生陷出和陷入时，恢复APP的运行需要涉及上下文保存和恢复等较多的操作，导致APP的恢复速度慢。
发明内容
本申请提供了一种应用程序恢复运行的方法、装置及计算机，用以加快应用程序恢复运行的速度。
一方面，本申请提供了一种应用程序恢复运行的方法，该方法可以应用于采用虚拟化架构的计算机(或称为物理主机)。该计算机可以包括：虚拟机监视器，运行于该虚拟机监视器上的客户机操作系统，以及运行于该客户机操作系统上的应用程序。该方法可以包括：中止运行应用程序并由该客户机操作系统陷出至虚拟机监视器，然后该虚拟机监视器存储该应用程序的恢复信息，该恢复信息可以包括该应用程序的上下文或该上下文的存储地址。之后该虚拟机监视器基于该恢复信息恢复该应用程序的上下文，并陷入到该客户机操作系统，从而该应用程序可以恢复运行，即应用程序可以恢复至上一次中止时的状态继续运行。
可见，由于该恢复运行应用程序的过程中可以直接由虚拟机监视器恢复应用程序的上下文，而无需先恢复客户机操作系统的上下文再通过客户机操作系统恢复应用程序的 上下文，从而有效加快了应用程序的恢复运行。
在一些实现方式中，响应于陷出请求，中止运行应用程序，即当检测到陷出请求时中止运行该应用程序。该陷出请求可以由以下任一种事件触发：该应用程序触发的系统调用；该应用程序触发的异常；以及该物理主机的硬件层上报的中断。也可以这样理解：系统调用、异常或中断本身即是陷出请求或陷出请求的一部分。
在一些实现方式中，响应于应用程序的恢复请求，恢复应用程序的运行，即当检测到该应用程序的恢复请求时，触发执行恢复应用上下文的操作。该恢复请求可以由虚拟机监视器中其他进程发送的需要由该应用程序处理的信号触发，或者也可以在该虚拟机监视器处理完前述陷出请求指示的操作后自动触发，又或者，还可以由虚拟机监视器中的虚拟机调度器根据调度算法检测到需要调度该应用程序所属虚拟机时触发，又或者人工配置或发送指令触发。
需要说明的是，“虚拟机监视器”在一些虚拟化架构中可以理解为VMM，在另一些虚拟化架构中也可以理解为hypervisor。
在一些实现方式中，在由该客户机操作系统陷出至虚拟机监视器之前，该方法还可以包括：客户机操作系统获取该应用程序的恢复信息，并将该应用程序的恢复信息传递至该虚拟机监视器。其中，在向虚拟机监视器传递恢复信息时，可以采用共享寄存器的方式传递或者调用接口的方式传递。上述两种方式传递恢复信息的效率较高，可以确保应用程序恢复运行的效率。
在一些实现方式中，在虚拟机监视器存储该应用程序的恢复信息之前，该方法还可以包括：客户机操作系统将该客户机操作系统的上下文的存储地址传递至该虚拟机监视器；相应的，虚拟机监视器存储该应用程序的恢复信息的过程可以包括：虚拟机监视器基于该客户机操作系统的上下文的存储地址，以及该客户机操作系统的上下文的存储地址与该应用程序的上下文的存储地址之间的关系，确定该应用程序的上下文的存储地址；虚拟机监视器存储该应用程序的上下文的存储地址，或者根据该应用程序的上下文的存储地址，存储该应用程序的上下文。
其中，该客户机操作系统的上下文的存储地址与该应用程序的上下文的存储地址之间的关系可以满足：应用程序的上下文的存储地址＝客户机操作系统的上下文的存储地址-客户机操作系统的上下文所占的存储容量。或者，该客户机操作系统的上下文的存储地址与该应用程序的上下文的存储地址之间的关系也可以满足：应用程序的上下文的存储地址＝客户机操作系统的上下文的存储地址+客户机操作系统的上下文所占的存储容量。
通过客户机操作系统将该客户机操作系统的上下文的存储地址传递至该虚拟机监视器，并由虚拟机监视器通过该存储地址存储该应用程序的恢复信息，提高了虚拟机监视器存储应用程序的恢复信息的灵活性。
在一些实现方式中，该恢复信息为该应用程序的上下文时，该虚拟机监视器将该应用程序的上下文存储至以下至少一种存储位置：该应用程序所属虚拟机的控制结构体；该应用程序所属虚拟处理器对应进程的管理结构体；以及物理主机的内存中除该控制结构体和管理结构体之外的存储位置。当然，虚拟机监视器也可以将该应用程序的上下文存储至物理主机的硬盘等其他任意存储位置。通过虚拟机监视器存储应用程序的上下文，可以便于在需要恢复运行应用程序时，虚拟机监视器能够直接恢复该应用程序的上下文。其中，该控制结构体可以为虚拟机管理结构体(VM control structures，VMCS)。该管理结构体可以为任务结构体(task_struct)。
在一些实现方式中，当该应用程序的上下文存储在该管理结构体中时，该方法还可以包括：当检测到针对该应用程序的调试指令时，主机操作系统中安装的调试工具，基于该应用程序的上下文在该管理结构体中的存储地址，对该应用程序进行调试。由于该应用程序所属虚拟处理器对应进程的管理结构体中存储有应用程序的上下文，因此当虚拟机监视器检测到针对该应用程序的调试指令时，可以基于该应用程序的上下文在该管理结构体中的存储地址，直接通过该调试工具对该应用程序进行调试。该调试过程无需再对该调试工具进行适配，有效提高了对应用程序的调试效率。
在一些实现方式中，虚拟机监视器恢复该应用程序的上下文的过程可以包括：虚拟机监视器将该应用程序的上下文存储至对应的寄存器。将应用程序的上下文存储至对应的寄存器，即可使该应用程序从上一次中止时的状态继续开始运行。
在一些实现方式中，该陷出请求可以由以下任一种请求触发：该应用程序触发的系统调用；该应用程序触发的异常；以及该物理主机的硬件层上报的中断。也可以这样理解：系统调用、异常或中断本身即是陷出请求或陷出请求的一部分。
另一方面，本申请提供了一种计算机，该计算机(或称物理主机)可以包括：硬件层，运行于该硬件层上的虚拟机监视器，运行于该虚拟机监视器上的客户机操作系统，以及运行于该客户机操作系统上的应用程序。该计算机中的各组件可以用于实现上述方面所提供的应用程序恢复运行的方法。这些组件可以是硬件，软件，或者，是硬件和软件的组合。
又一方面，本申请提供了一种恢复应用程序运行的装置，该装置包括多个模块，且该多个模块用于实现上述方面所提供应用程序恢复运行的方法。该装置可以部署在计算机上，由该计算机运行以实现前述方法。该计算机(或称物理主机)包括：虚拟机监视器，运行于该虚拟机监视器上的客户机操作系统，以及运行于该客户机操作系统上的应用程序。该装置的各个模块可以分散部署在客户机操作系统和虚拟机监视器内部。
再一方面，本申请提供了一种计算机可读存储介质或一种计算机程序(产品)，该计算机可读存储介质或该计算机程序中存储有指令，当处理器读取该计算机可读存储介质或该计算机程序中存储的指令行时，使得处理器执行如上述方面所提供的应用程序恢复运行的方法。
再一方面，本申请提供了一种应用程序恢复运行的装置，该装置可以包括：存储器，处理器及存储在该存储器上并可在该处理器上运行的计算机程序，该处理器执行该计算机程序时实现如上述方面所提供的应用程序恢复运行的方法。
综上所述，本发明实施例提供了一种应用程序恢复运行的方法、装置及计算机，该方案可以在中止应用程序的运行之后，通过虚拟机监视器存储该应用程序的上下文或该上下文的存储地址，从而可以在需要恢复应用程序的运行时直接通过该虚拟机监视器恢复该应用程序的上下文。由于该恢复运行应用程序的过程中无需先通过虚拟机监视器恢复客户机操作系统的上下文，再通过客户机操作系统恢复应用程序的上下文，减少了一次恢复上下文的操作，从而有效加快了应用程序的恢复运行。
附图说明
图1是本发明实施例提供的一种采用虚拟化技术的物理主机的架构图；
图2是本发明实施例提供的另一种采用虚拟化技术的物理主机的架构图；
图3是本发明实施例提供的一种应用程序恢复运行的方法的流程图；
图4是本发明实施例提供的一种应用程序恢复运行的方法的执行流程图；
图5是本发明实施例提供的又一种采用虚拟化技术的物理主机的架构图；
图6是本发明实施例提供的另一种应用程序恢复运行的方法的流程图；
图7是本发明实施例提供的另一种应用程序恢复运行的执行流程图；
图8是本发明实施例提供的又一种应用程序恢复运行的方法的流程图；
图9是本发明实施例提供的又一种应用程序恢复运行的执行流程图；
图10是本发明实施例提供的再一种应用程序恢复运行的方法的流程图；
图11是本发明实施例提供的再一种应用程序恢复运行的执行流程图；
图12是本发明实施例提供的一种应用程序恢复运行的装置的结构示意图；
图13是本发明实施例提供的另一种应用程序恢复运行的装置的结构示意图；
图14是本发明实施例提供的又一种应用程序恢复运行的装置的结构示意图。
具体实施方式
下面结合附图详细介绍本申请实施例提供的应用程序恢复运行的方法。
图1是本发明实施例提供的一种采用虚拟化技术的物理主机的架构图。如图1所示，该物理主机也可以称为计算机。参考图1，物理主机可以包括：硬件层10，运行于该硬件层10上的主机操作系统(host OS)20，运行于该host OS 20中的VMM 30，以及运行于该VMM 30上的多个VCPU 40。例如图1中示出了两个VCPU：VCPUa和VCPUb。其中，每个VCPU 40上运行有一个VM 41，每个VM 41包括一个客户机操作系统(guest OS)42以及运行于该guest OS 42上的至少一个APP 43。例如，图1所示的架构中，每个VM 41中包括一个APP 43。在本发明实施例中，至少一个可以是指一个或多个，多个可以是指两个或两个以上。
其中，该硬件层10可以包括一个或多个物理处理器(物理CPU)、物理存储设备(例如内存和硬盘)、网络接口以及外设等硬件设备。host OS 20可以为Linux操作系统。VMM 30也称为hypervisor，是一种运行在硬件层10和各VCPU 40之间的软件中间件，用于将硬件层的10的硬件资源协调提供给各个VCPU 40，以供该客户机操作系统42和应用程序43运行。例如，VMM 30可以将物理CPU的处理资源协调提供给各个VCPU 40。
参考图1，该VMM 30可以运行在host OS 20中。或者，该VMM 30也可以独立于该host OS 20部署，即该VMM 30可以直接运行在硬件层10上。又或者，如图2所示，该物理主机中也可以无需部署该host OS 20。本发明实施例对该物理主机的架构不做限定。
该guest OS 42可以为库操作系统(library OS，LibOS)，该LibOS也称为unikernel，是一种轻量级的虚拟化技术，其采用了OS外核架构，把OS的功能抽象成库，提供了库文件、联合文件系统、普通文件系统以及执行各种操作、与其他模块进行交互的功能。
通常，物理主机在某个VM 40的guest OS 42中运行APP 43的过程中，当该APP 43触发系统调用、出现异常或硬件层10上报中断时，物理主机如果需要由guest OS 42陷出到VMM 30进行处理，则可以通过该VM 40中的guest OS 42存储APP 43的上下文，并由guest OS 42陷出到VMM 30。之后可以通过VMM 30存储guest OS 42的上下文并进行相关处理。当需要恢复运行该APP 43时，可以通过VMM 30恢复guest OS 42的上下文并由VMM 30陷入guest OS 42。最后，可以通过guest OS 42恢复APP 43的上下文并继续运行APP 43。
但是，由于APP 43的上下文保存在guest OS 42，因此相关技术中的方法在恢复运行APP的过程中，需要先通过VMM 30恢复guest OS 42的上下文，然后再通过guest OS 42恢 复APP 43的上下文，该恢复运行APP 43的效率较低。
本发明实施例提供了一种应用程序恢复运行的方法，该方法可以应用于图1或图2所示的物理主机中，该方法可以解决相关技术中的物理主机恢复运行APP时效率较低的问题，可以用以加快应用程序恢复运行的速度。参考图3，该方法可以包括：
步骤101、响应于陷出请求，客户机操作系统中止运行应用程序。
该陷出请求可以由以下任一种事件触发：应用程序触发的系统调用、应用程序触发的异常，以及物理主机的硬件层上报的中断。也可以这样理解：系统调用、异常或中断本身即是陷出请求或陷出请求的一部分。
其中，系统调用可以是应用程序主动向客户机操作系统发出的服务请求。异常可以是应用程序当前指令执行失败(由于非法指令或者内存缺页等原因导致)而向客户机操作系统发送的处理请求。中断可以是由硬件层的外设发送至客户机操作系统的输入/输出(input/output，I/O)中断，或者由物理CPU发送至客户机操作系统的处理器间中断(inter-processor interrupt，IPI)。也即是，当物理主机在应用程序运行在客户机操作系统的过程中，当检测到应用程序发送的系统调用或异常，或者检测到硬件层发送的中断请求时，即可中止运行应用程序。此时，物理主机的系统控制权由应用程序切换至客户机操作系统，即由应用程序陷出至客户机操作系统。
示例的，参考图4，以VMM 30上运行的VCPUa为例，假设该VCPUa上运行的VM 41中的APP 43在运行过程中向guest OS 42发送了系统调用，则物理主机通过该guest OS 42中止该APP 43的运行。
步骤102、客户机操作系统获取该应用程序的恢复信息。
通过客户机操作系统中止运行该应用程序后，物理主机可以通过该客户机操作系统获取该应用程序的恢复信息。该恢复信息可以包括应用程序的上下文(context)或该上下文的存储地址，该存储地址可以为该上下文在内存中的存储地址。其中，应用程序的上下文可以包括恢复运行该应用程序所需的信息，例如可以包括该应用程序中止运行时，寄存器中所记录的该应用程序的相关数据。其中，恢复运行应用程序可以是指使得该应用程序恢复运行至上一次中止时的状态。
示例的，如图4所示，可以通过guest OS 42获取APP 43的上下文在内存中的存储地址。
需要说明的是，在本发明实施例中，物理主机通过客户机操作系统获取该应用程序的恢复信息后，还可以先判断触发该陷出请求的系统调用、异常或中断是否可以由客户机操作系统进行处理。若可以由客户机操作系统进行处理，则可以通过该客户机操作系统进行相关处理后，直接恢复应用程序的上下文并恢复运行该应用程序。若无法通过该客户机操作系统进行处理，则物理主机可以继续执行下述步骤103。
在一些实现方式中，在上述步骤102之后，物理主机还可以通过该客户机操作系统存储该应用程序的恢复信息，例如存储在内存中，以便通过客户机操作系统进行相关处理后，能够通过客户机操作系统直接恢复应用程序的上下文。当然，若无法通过该客户机操作系统进行处理，则也可以无需通过该客户机操作系统存储该恢复信息，而是可以直接通过该客户机操作系统将获取到的恢复信息传递至虚拟机监视器。
步骤103、客户机操作系统将该应用程序的恢复信息传递至该虚拟机监视器。
在本发明实施例中，客户机操作系统向虚拟机监视器传递恢复信息时，可以采用寄存器传递的方式或者调用接口传递的方式。其中，寄存器传递的方式可以是指：客户机操作系统将应用程序的恢复信息写入至某个虚拟机监视器能够访问的寄存器，并将该寄 存器的地址发送至虚拟机监视器，然后由该虚拟机监视器从接收到的地址指示的寄存器中读取应用程序的恢复信息。调用接口传递可以是指：客户机操作系统直接调用虚拟机监视器的接口传递该应用程序的恢复信息。
步骤104、由该客户机操作系统陷出至虚拟机监视器。
通过该客户机操作系统将该应用程序的恢复信息传递至该虚拟机监视器后，即可由该客户机操作系统陷出至虚拟机监视器，即物理主机的系统控制权由该客户机操作系统切换至虚拟机监视器。
示例的，参考图4，可以通过该guest OS 42调用VMM 30的接口将APP 43的上下文的地址传递至VMM 30，并由该guest OS 42陷出至该VMM 30。
步骤105、虚拟机监视器存储该应用程序的恢复信息。
当该恢复信息为该应用程序的上下文时，物理主机可以通过该虚拟机监视器将该应用程序的上下文存储至以下至少一种存储位置：该应用程序所属VM的控制结构体、该应用程序所属虚拟处理器(VCPU)对应进程的管理结构体以及该物理主机的内存中除该控制结构体和管理结构体之外的存储位置。
在本发明实施例中，物理主机中每个VM都对应有一个控制结构体，该控制结构体可以为虚拟机控制结构体(VM control structures，VMCS)。每个VCPU对应的进程都对应有一个用于对该进程进行管理的管理结构体，该管理结构体也可以称为进程控制块(processing control block，PCB)。例如该管理结构体可以为任务结构体(task_struct)。
在一些实现方式中，物理主机可以通过该虚拟机监视器将该应用程序的上下文存储至虚拟机的控制结构体、进程的管理结构体和物理主机的内存中任一存储位置。或者，也可以通过该虚拟机监视器将该应用程序的上下文同时存储在上述存储位置中的多个存储位置。例如，通过该VMM 30将该APP 43的上下文存储至APP 43所属VM的VMCS，并将该APP 43的上下文存储至该APP 43所属VCPU对应进程的task_struct。
当该恢复信息为应用程序的上下文的存储地址时，一方面，可以通过该虚拟机监视器直接存储该应用程序的上下文的存储地址，例如可以将该存储地址存储在内存中。另一方面，可以通过该虚拟机监视器根据该应用程序的上下文的存储地址，从该存储地址指示的存储位置获取该应用程序的上下文，并存储该获取到的应用程序的上下文。例如，可以通过该虚拟机监视器将获取到的应用程序的上下文存储至以下至少一种存储位置：该应用程序所属VM的控制结构体、该应用程序所属VCPU对应进程的管理结构体以及该物理主机的内存中除该控制结构体和管理结构体之外的存储位置。
在一些实现方式中，上述步骤103也可以通过下述步骤103a替换：
步骤103a、客户机操作系统将该客户机操作系统的上下文的存储地址传递至该虚拟机监视器。
在本发明实施例中，在中止运行应用程序之后，由客户机操作系统陷出至虚拟机监视器之前，客户机操作系统还可以将该客户机操作系统自身的上下文的存储地址传递至该虚拟机监视器。其中，该客户机操作系统的上下文的存储地址也可以是指在内存中的存储地址。传递该客户机操作系统的上下文的存储地址的方式可以参考上述传递应用程序的恢复信息的方式，此处不再赘述。
相应的，上述步骤105可以包括：
步骤1051、虚拟机监视器基于该客户机操作系统的上下文的存储地址，以及该客户机操作系统的上下文的存储地址与该应用程序的上下文的存储地址之间的关系，确定该 应用程序的上下文的存储地址。
由于该客户机操作系统的上下文和应用程序的上下文一般采用压栈的方式存储，且一般先存储应用程序的上下文，然后存储客户机操作系统的上下文。因此，可以根据用于存储该客户机操作系统的上下文和应用程序的上下文的堆栈的增长方式，确定客户机操作系统的存储地址与该应用程序的上下文的存储地址之间的关系。其中，堆栈的增长方式是指堆栈的地址的增长方式，该增长方式一般包括向上增长和向下增长。向上增长是指堆栈的地址从栈底到栈顶逐渐增大，即栈顶为高地址。向下增长是指堆栈的地址从栈顶到栈底逐渐增大，即栈底为高地址。
当该堆栈的增长方式为向上增长时，该客户机操作系统的上下文的存储地址与该应用程序的上下文的存储地址之间的关系可以满足：应用程序的上下文的存储地址＝客户机操作系统的上下文的存储地址-该客户机操作系统的上下文所占的存储容量(也可以称为长度)。也即是，可以将该客户机操作系统的上下文的存储地址与该客户机操作系统的上下文的长度的差值确定为该应用程序的上下文的存储地址。
当该堆栈的增长方式为向下增长时，该客户机操作系统的上下文的存储地址与该应用程序的上下文的存储地址之间的关系可以满足：应用程序的上下文的存储地址＝客户机操作系统的上下文的存储地址+该客户机操作系统的上下文所占的存储容量(也可以称为长度)。也即是，可以将该客户机操作系统的上下文的存储地址与该客户机操作系统的上下文的长度之和确定为该应用程序的上下文的存储地址。
其中，若客户机操作系统的上下文的长度为固定值，则物理主机可以通过虚拟机监视器直接获取到客户机操作系统的上下文的长度。若客户机操作系统的上下文的长度不为固定值，则在通过该客户机操作系统向虚拟机监视器传递该客户机操作系统的上下文的存储地址时，可以同步传输该客户机操作系统的上下文的长度。
步骤1052、虚拟机监视器存储该应用程序的上下文的存储地址，或者根据该应用程序的上下文的存储地址，存储该应用程序的上下文。
该虚拟机监视器确定该应用程序的上下文的存储地址后，可以通过该虚拟机监视器直接存储该应用程序的上下文的存储地址。或者，也可以通过该虚拟机监视器根据该应用程序的上下文的存储地址，从该存储地址指示的存储位置获取该应用程序的上下文，并存储获取到的该应用程序的上下文。通过该虚拟机监视器存储该应用程序的上下文或者上下文的存储地址的方式可以参考上文描述，此处不再赘述。
需要说明的是，在上述步骤105中，若通过该虚拟机监视器存储的恢复信息为该应用程序的上下文，则由于该虚拟机监视器的架构和该客户机操作系统的架构可能不同。例如，该虚拟机监视器可以是64位架构，而该客户机操作系统可能是32位架构，则通过该虚拟机监视器存储该应用程序的上下文时，还需要对该应用程序的上下文的数据格式进行转换(例如可以对该应用程序的上下文进行补零操作)，以使得该转换后的应用程序的上下文可以满足该虚拟机监视器的架构要求。
还需要说明的是，通过该虚拟机监视器存储恢复信息时，除了可以存储至上文所述的控制结构体、管理结构体和内存中的其他存储位置之外，还可以存储至物理主机中的硬盘等其他任意存储位置，本发明实施例对此不做限定。
步骤106、响应于该应用程序的恢复请求时，虚拟机监视器恢复该应用程序的上下文，并由虚拟机监视器陷入到该客户机操作系统。
在本发明实施例中，该恢复请求可以由虚拟机监视器中其他进程发送的需要由该应 用程序处理的信号触发，或者也可以在通过该虚拟机监视器处理完成该陷出请求指示的操作后自动触发，又或者，还可以是虚拟机监视器中的虚拟机调度器根据调度算法检测到需要调度该应用程序所属虚拟机时触发的。通过该虚拟机监视器恢复该应用程序的上下文可以是指：通过该虚拟机监视器将该应用程序的上下文从原存储位置存储至(即拷贝至)该应用程序对应的寄存器，以便恢复运行该应用程序。其中，应用程序对应的寄存器可以是指物理主机运行该应用程序时所用的寄存器。通过该虚拟机监视器恢复该应用程序的上下文，并由虚拟机监视器陷入到该客户机操作系统后，该应用程序即可恢复运行，即应用程序可以恢复至上一次中止时的状态并继续运行。
由于该恢复运行应用程序的过程中，可以通过虚拟机监视器直接恢复应用程序的上下文，而无需先由虚拟机监视器恢复客户机操作系统的上下文，再由客户机操作系统恢复应用程序的上下文，减少了客户机操作系统的一次切换和跳转，有效提升了恢复运行应用程序的效率。又由于该物理主机中的各个应用程序均运行在VCPU上，因此提高恢复运行应用程序的效率也即是提高了各VCPU之间的切换效率。
示例的，可以通过VMM 30将APP 43的上下文，从该APP 43所属VCPU对应进程的task_struct拷贝至该APP 43对应的寄存器，从而使得该APP 43可以恢复运行。
需要说明的是，由于该虚拟机监视器的架构和该客户机操作系统的架构可能不同。若通过该虚拟机监视器存储应用程序的上下文时，还对该应用程序的上下文的数据格式进行了转换，则在恢复该应用程序的上下文时，还需要再次对该应用程序的上下文的数据格式进行转换(例如可以对该应用程序的上下文进行去零操作)，以恢复该应用程序的上下文的数据格式，使得恢复后的应用程序的上下文可以满足该客户机操作系统的架构要求。
在一些实现方式中，若该物理主机的架构中还包括主机操作系统20，则该物理主机的主机操作系统20中还可以安装有调试工具，例如，GNU(“GNU is Not Unix”的递归缩写)调试器(GNU debugger，GDB)和性能分析工具(performance，Perf)等。该调试工具可以对VMM 30中的进程，以及VM 40中的APP 43进行调试。但是，由于相关技术VM 40中的APP 43的上下文保存在guest OS 42中，当需要通过VMM 30中安装的调试工具对APP 43进行调试时，该调试工具无法直接获知该应用程序的上下文的存储地址，因此需要先对该调试工具进行适配才能对APP 43进行调试，导致应用程序的调试效率较低。
在本发明实施例中，若在上述步骤105中，虚拟机监视器将该应用程序的上下文存储在该管理结构体中，则该方法还可以包括：
步骤107、当检测到针对该应用程序的调试指令时，通过主机操作系统中安装的调试工具，基于该应用程序的上下文在该应用程序所属VCPU对应进程的管理结构体中的存储地址，对该应用程序进行调试。
由于该应用程序所属VCPU对应进程的管理结构体中存储有应用程序的上下文，因此当通过虚拟机监视器检测到针对该应用程序的调试指令时，可以基于该应用程序的上下文在该管理结构体中的存储地址，直接通过该调试工具对该应用程序进行调试。该调试过程无需再对该调试工具进行适配，有效提高了对应用程序的调试效率。
在本发明实施例中，每个VCPU 40可以对应一个物理CPU，不同VCPU 40对应的物理CPU可以相同也可以不同，因此每个物理CPU可以对应一个或多个VCPU 40。VMM 30可以将每个物理CPU的处理资源协调提供给该物理CPU对应的一个或多个VCPU 40。其中，每个物理CPU可以为一个物理核。每个VCPU可以与VMM 30中的一个线程对应，例如图 5所示，VCPUa与线程a对应，VCPUb与线程b对应。VMM 30可以通过线程调度策略在物理CPU中调度不同线程，进而使得同一物理CPU对应的多个VCPU 40可以切换运行。以VCPUa切换至VCPUb为例，该VCPU的切换过程所需的时间可以包括：保存VCPUa中运行的应用程序的上下文的时间、恢复VCPUb中应用程序的上下文的时间以及由线程a切换至线程b所需的时间。
相关技术中为了提高VCPU 40的切换效率，参考图5，可以将同一物理CPU对应的多个VCPU 40作为一个VCPU队列进行管理，并将该一个VCPU队列与VMM 30中一个代理线程绑定。当需要在该VCPU队列中的各VCPU之间进行VCPU切换时，不再需进行线程切换，因而有效提高了VCPU的切换效率。其VCPU的切换用时一般为5微秒(us)左右。而在采用本发明实施例提供的方法后，由于在进行VCPU的切换时，可以有效提高恢复VCPU中应用程序的上下文的时间，从而可以进一步提高VCPU的切换效率。例如，VCPU的切换用时可以从5us缩短至1us以下。
在一些实现方式中，在本发明实施例中，该物理主机可以为基站或者服务器等。该物理主机中运行的虚拟机中的应用程序可以为移动通信业务应用程序。例如该物理主机中运行的虚拟机中的应用程序可以包括第四代移动通信技术(the 4th generation mobile communication technology，4G)应用程序和第五代移动通信技术5G应用程序。当该4G应用程序所属VM所运行的VCPU，与5G应用程序所属VM所运行的VCPU对应同一个物理CPU时，需要实现4G应用程序和5G应用程序的快速切换。本发明实施例提供的应用程序恢复运行的方法可以满足该4G应用程序和5G应用程序的快速切换的需求。
需要说明的是，本发明实施例提供的应用程序恢复运行的方法的步骤的先后顺序可以进行适当调整，步骤也可以根据情况进行相应增减。例如，步骤102可以根据情况删除，步骤103可以由步骤103a替代。或者，步骤107可以根据情况进行删除。任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化的方法，都应涵盖在本申请的保护范围之内，因此不再赘述。
综上所述，本发明实施例提供了一种应用程序恢复运行的方法，该方法可以在中止应用程序的运行之后，通过虚拟机监视器存储该应用程序的上下文或该上下文的存储地址，从而可以在需要恢复应用程序的运行时直接通过该虚拟机监视器恢复该应用程序的上下文。由于该恢复运行应用程序的过程中无需先通过虚拟机监视器恢复客户机操作系统的上下文，再通过客户机操作系统恢复应用程序的上下文，减少了一次恢复上下文的操作，从而有效提高了应用程序恢复运行的效率。
图6是本发明实施例提供的另一种应用程序恢复运行的方法流程图，以该陷出请求由中断触发为例，对该应用程序恢复运行的方法进行介绍。参考图6，该方法可以包括：
步骤201、当检测到硬件层上报的中断时，客户机操作系统中止运行该应用程序。
示例的，参考图7，假设当通过该VCPUa运行APP 43的过程中，收到了硬件层10上报的中断，则可以通过该VCPUa中止该APP 43的运行，并由APP 43陷出至guest OS 42。
步骤202、客户机操作系统获取该应用程序的恢复信息。
该步骤202的实现过程可以参考上述步骤102，此处不再赘述。
步骤203、客户机操作系统判断该中断是否由该客户机操作系统处理。
在本发明实施例中，该客户机操作系统中可以存储有中断分发列表，该中断分发列表中可以记录有每个中断对应的VCPU。客户机操作系统可以根据该中断分发列表确定当 前检测到的中断对应的VCPU，并判断该中断对应的VCPU是否为支撑该客户机操作系统运行的VCPU(即该客户机操作系统所属的VCPU)。
若该中断对应的VCPU为该客户机操作系统所属的VCPU，则可以确定该中断是由该客户机操作系统处理，因此可以执行步骤204。若该中断对应的VCPU不为该客户机操作系统所属的VCPU，则可以确定该中断不由该客户机操作系统处理，因此可以继续执行下述步骤205。
步骤204、客户机操作系统对该中断进行处理，处理完成后恢复应用程序的上下文，并恢复运行该应用程序。
若通过该客户机操作系统判断该中断是由该客户机操作系统处理，则可以直接通过该客户机操作系统对该中断进行处理，处理完成后即可直接通过该客户机操作系统恢复应用程序的上下文，并恢复运行该应用程序。
步骤205、客户机操作系统将该应用程序的恢复信息传递至该虚拟机监视器，并由该客户机操作系统陷出至虚拟机监视器。
步骤206、虚拟机监视器存储该应用程序的恢复信息。
上述步骤205和步骤206的实现过程可以参考上述步骤103至步骤105的相关描述，此处不再赘述。
步骤207、切换至该中断对应的虚拟处理器，并通过该对应的虚拟处理器上运行的客户机操作系统对该中断进行处理。
在本发明实施中，当该陷出请求是由中断触发时，物理主机的系统控制权由客户机操作系统陷出至虚拟机监视器后，即可通过该虚拟机监视器确定该中断对应的虚拟处理器，并切换至该对应的虚拟处理器，以便通过该对应的虚拟处理器上运行的客户机操作系统对中断进行处理。
在一些实现方式中，物理主机可以通过该虚拟机监视器根据中断分发列表确定该中断对应的虚拟处理器。或者，由该客户机操作系统陷出至虚拟机监视器时，可以通过该客户机操作系统直接将该中断对应的虚拟处理器的标识传递至虚拟机监视器，以便该虚拟机监视器可以直接切换至该标识指示的虚拟处理器。
示例的，参考图7，假设该中断对应的虚拟处理器为VCPUb，则VMM 30可以切换运行VCPUb，并通过VCPUb上运行的guest OS 42对该中断进行处理。
步骤208、当检测到该应用程序的恢复请求时，虚拟机监视器恢复该应用程序的上下文，并由虚拟机监视器陷入到该客户机操作系统。
示例的，当物理主机通过VMM 30检测到该VCPUb上运行的guest OS 42完成中断处理时，可以触发该VCPUa中的APP 43的恢复请求，并通过VMM 30恢复该APP 43的上下文，由VMM 30陷入到guest OS 42，从而可以恢复运行该APP 43。
上述步骤208的实现过程可以参考上述步骤106中的相关描述，此处不再赘述。
图8是本发明实施例提供的另一种应用程序恢复运行的方法流程图，以该陷出请求由系统调用或异常触发为例，对该应用程序恢复运行的方法进行介绍。参考图8，该方法可以包括：
步骤301、当检测到应用程序触发的系统调用或异常时，客户机操作系统中止运行该应用程序。
示例的，参考图9，假设在该VCPUa中运行APP 43的过程中，APP 43触发了系统调用， 则可以通过该VCPUa中止该APP 43的运行，并由APP 43陷出至guest OS 42。
步骤302、客户机操作系统获取该应用程序的上下文。
该步骤302的实现过程可以参考上述步骤102，此处不再赘述。
步骤303、客户机操作系统判断该系统调用或异常是否由该客户机操作系统处理。
在本发明实施例中，该客户机操作系统中可以存储有处理功能列表，该处理功能列表中可以记录有其所能够处理的系统调用或异常的类型。物理主机可以通过该客户机操作系统根据该处理功能列表判断该系统调用或异常是否可以由该客户机操作系统直接进行处理。
若通过该客户机操作系统判断该系统调用或异常可以由该客户机操作系统直接进行处理，则可以执行步骤304；若通过该客户机操作系统判断该系统调用或异常无法由该客户机操作系统处理，则可以继续执行下述步骤305。
步骤304、客户机操作系统对该系统调用或异常进行处理，处理完成后恢复应用程序的上下文，并恢复运行该应用程序。
若通过该客户机操作系统判断该系统调用或异常可以由该客户机操作系统处理，则可以直接通过该客户机操作系统对该系统调用或异常进行处理，处理完成后即可通过该客户机操作系统恢复应用程序的上下文，并恢复运行该应用程序。
步骤305、客户机操作系统将该应用程序的恢复信息传递至该虚拟机监视器，并由该客户机操作系统陷出至虚拟机监视器。
通过该客户机操作系统判断该系统调用或异常无法由该客户机操作系统处理时，可以通过该客户机操作系统将该应用程序的恢复信息传递至该虚拟机监视器，并由该客户机操作系统陷出至虚拟机监视器。
步骤306、虚拟机监视器存储该应用程序的恢复信息。
上述步骤305和步骤306的实现过程可以参考上述步骤103至步骤105中的相关描述，此处不再赘述。
步骤307、虚拟机监视器对该系统调用或异常进行处理。
在本发明实施中，物理主机的系统控制权由客户机操作系统陷出至虚拟机监视器后，即可由该虚拟机监视器对该系统调用或异常进行处理。
步骤308、当检测到该应用程序的恢复请求时，虚拟机监视器恢复该应用程序的上下文，并由虚拟机监视器陷入到该客户机操作系统。
示例的，当物理主机通过VMM 30完成对该系统调用的处理时，可以触发该VCPUa中的APP 43的恢复请求，并通过VMM 30恢复该APP 43的上下文，由VMM 30陷入到guest OS 42，从而可以恢复运行该APP 43。
上述步骤308的实现过程可以参考步骤106的相关描述，此处不再赘述。
图10是本发明实施例提供的另一种应用程序恢复运行的方法流程图。以该恢复请求为其他进程发送的信号为例，对该应用程序恢复运行的方法进行介绍。参考图10，该方法可以包括：
步骤401、当检测到其他进程发送的需要该应用程序进行处理的信号时，虚拟机监视器恢复该应用程序的上下文，并由虚拟机监视器陷入至客户机操作系统。
示例的，参考图11，假设当前VCPUa不在位(即未运行)，物理主机通过VMM 30收到了其他进程发送的需要该VCPUa中的APP 43处理的信号，则可以通过该VMM 30恢 复该APP 43的上下文，由VMM 30陷入到guest OS 42，从而可以恢复运行该APP 43。该APP 43的上下文可以是上一次中止APP 43运行时，通过该VMM 30存储的。
上述步骤401的实现过程可以参考步骤106的相关描述，此处不再赘述。
步骤402、应用程序进行相关处理。
示例的，该VCPUa中的APP 43可以对触发其恢复运行的信号进行相关处理。
步骤403、当检测到陷出请求时，客户机操作系统中止运行该应用程序。
步骤404、客户机操作系统获取该应用程序的恢复信息。
步骤405、客户机操作系统将该应用程序的恢复信息传递至该虚拟机监视器，并由该客户机操作系统陷出至虚拟机监视器。
步骤406、虚拟机监视器存储该应用程序的恢复信息。
上述步骤403至步骤406的实现过程可以参考上述步骤101至步骤105中的相关描述，此处不再赘述。
综上所述，本发明实施例提供了一种应用程序恢复运行的方法，该方法可以在中止应用程序的运行之后，通过虚拟机监视器存储该应用程序的上下文或该上下文的存储地址，从而可以在需要恢复应用程序的运行时直接通过该虚拟机监视器恢复该应用程序的上下文。由于该恢复运行应用程序的过程中无需先通过虚拟机监视器恢复客户机操作系统的上下文，再通过客户机操作系统恢复应用程序的上下文，减少了一次恢复上下文的操作，从而有效提高了应用程序恢复运行的效率。
需要说明的是，在本申请中，“通过”guest OS或VMM等执行某项操作，可以理解为物理主机做执行主体，该物理主机“通过”该物理主机上部署的VMM或guest OS来执行该操作。这种描述相当于：guest OS或VMM等“执行”某项操作”，即将guest OS或VMM等直接理解为执行主体。不论是哪种描述方法，其本质均是处理器运行软件程序(guest OS或VMM)以执行该项操作。
本发明实施例还提供了一种物理主机，参考图1、图2以及图5，该物理主机可以包括：硬件层10，运行于该硬件层10上的虚拟机监视器30，运行于该虚拟机监视器30上的客户机操作系统42，以及运行于该客户机操作系统42上的应用程序43。
该客户机操作系统42，可以用于响应于陷出请求，中止运行该应用程序43并陷出至该虚拟机监视器30。
该虚拟机监视器30，可以用于存储该应用程序43的恢复信息，该恢复信息包括该应用程序43的上下文或该上下文的存储地址。
该虚拟机监视器30，还用于响应于该应用程序43的恢复请求，基于该恢复信息恢复该应用程序43的上下文，并陷入至该客户机操作系统42，从而使得该应用程序43可以恢复运行。
在一些实现方式中，该客户机操作系统42，还可以用于：
在陷出至虚拟机监视器30之前，获取该应用程序43的恢复信息；将该应用程序43的恢复信息传递至该虚拟机监视器30。
在一些实现方式中，该客户机操作系统42可以用于将该恢复信息写入虚拟机监视器能够访问的寄存器或者调用虚拟机监视器的接口，将该应用程序43的恢复信息传递至该 虚拟机监视器30。
在一些实现方式中，该客户机操作系统42，还用于将该客户机操作系统42的上下文的存储地址传递至该虚拟机监视器30。相应的，该虚拟机监视器30，可以用于：
基于该客户机操作系统42的上下文的存储地址，以及该客户机操作系统42的上下文的存储地址与该应用程序43的上下文的存储地址之间的关系，确定该应用程序43的上下文的存储地址；
存储该应用程序43的上下文的存储地址，或者根据该应用程序43的上下文的存储地址，存储该应用程序43的上下文。
在一些实现方式中，该恢复信息为该应用程序43的上下文；该虚拟机监视器30，用于将该应用程序43的上下文存储至以下至少一种存储位置：物理主机的内存；该应用程序43所属虚拟机的控制结构体；以及该应用程序43所属虚拟处理器对应进程的管理结构体。
在一些实现方式中，该应用程序43的上下文存储在该管理结构体中。参考图1，该物理主机还可以包括：运行在该硬件层10上的主机操作系统20，以及安装在该主机操作系统20中的调试工具(图1中未示出)。
该调试工具，可以用于当检测到针对该应用程序43的调试指令时，基于该应用程序43的上下文在该管理结构体中的存储地址，对该应用程序43进行调试。
在一些实现方式中，该虚拟机监视器30可以用于将该应用程序43的上下文存储至对应的寄存器。
在一些实现方式中，该陷出请求由以下任一种请求触发：该应用程序43触发的系统调用；该应用程序43触发的异常；以及该物理主机的硬件层10上报的中断。
综上所述，本发明实施例提供了一种物理主机，该物理主机中的客户机操作系统可以在中止应用程序的运行之后，通过虚拟机监视器存储该应用程序的上下文或该上下文的存储地址，从而可以在需要恢复应用程序的运行时直接通过该虚拟机监视器恢复该应用程序的上下文。由于该恢复运行应用程序的过程中无需先通过虚拟机监视器恢复客户机操作系统的上下文，再通过客户机操作系统恢复应用程序的上下文，减少了一次恢复上下文的操作，从而有效提高了应用程序恢复运行的效率。
图12是本发明实施例提供的另一种应用程序恢复运行的装置的结构示意图，该装置可以应用于图1、图2或图5所示的物理主机中。参考图12，该装置可以包括：
部署在客户机操作系统内的中止模块501，用于响应于陷出请求，中止运行该应用程序并由该客户机操作系统陷出至虚拟机监视器。
部署在虚拟机监视器内的存储模块502，用于存储该应用程序的恢复信息，该恢复信息包括该应用程序的上下文或该上下文的存储地址。
部署在虚拟机监视器内的恢复模块503，用于响应于该应用程序的恢复请求，基于该恢复信息恢复该应用程序的上下文，并由客户机操作系统陷入至客户机操作系统。
在一些实现方式中，参考图13，该装置还可以包括：
部署在客户机操作系统内的获取模块504，用于在陷出至虚拟机监视器之前，获取该应用程序的恢复信息。
部署在客户机操作系统内的传递模块505，用于将该应用程序的恢复信息传递至该虚 拟机监视器。
在一些实现方式中，该传递模块505可以用于：将该恢复信息写入虚拟机监视器能够访问的寄存器或者调用虚拟机监视器的接口，将该应用程序的恢复信息传递至该虚拟机监视器。
在一些实现方式中，该传递模块505，可以用于在由客户机操作系统陷出至虚拟机监视器之前，将该客户机操作系统的上下文的存储地址传递至该虚拟机监视器。
相应的，该存储模块502可以用于：基于该客户机操作系统的上下文的存储地址，以及该客户机操作系统的上下文的存储地址与该应用程序的上下文的存储地址之间的关系，确定该应用程序的上下文的存储地址；以及存储该应用程序的上下文的存储地址，或者根据该应用程序的上下文的存储地址，存储该应用程序的上下文。
在一些实现方式中，该恢复信息为该应用程序的上下文；该存储模块502可以用于：
将该应用程序的上下文存储至以下至少一种存储位置：物理主机的内存；该应用程序所属虚拟机的控制结构体；以及该应用程序所属虚拟处理器对应进程的管理结构体。
在一些实现方式中，该应用程序的上下文可以存储在该管理结构体中；如图13所示，该装置还可以包括：
部署在主机操作系统内的调试模块506，用于当检测到针对该应用程序的调试指令时，基于该应用程序的上下文在该管理结构体中的存储地址，对该应用程序进行调试。
在一些实现方式中，该恢复模块503可以用于：将该应用程序的上下文存储至对应的寄存器。
在一些实现方式中，该陷出请求由以下任一种请求触发：该应用程序触发的系统调用；该应用程序触发的异常；以及该物理主机的硬件层上报的中断。
综上所述，本发明实施例提供了一种应用程序恢复运行的装置，该装置中的客户机操作系统可以在中止应用程序的运行之后，通过虚拟机监视器存储该应用程序的上下文或该上下文的存储地址，从而可以在需要恢复应用程序的运行时直接通过该虚拟机监视器恢复该应用程序的上下文。由于该恢复运行应用程序的过程中无需先通过虚拟机监视器恢复客户机操作系统的上下文，再通过客户机操作系统恢复应用程序的上下文，减少了一次恢复上下文的操作，从而有效提高了应用程序恢复运行的效率。
应理解的是，本发明实施例的应用程序恢复运行的装置还可以用专用集成电路(application-specific integrated circuit，ASIC)实现，或可编程逻辑器件(programmable logic device，PLD)实现，上述PLD可以是复杂程序逻辑器件(complex programmable logical device，CPLD)，现场可编程门阵列(field-programmable gate array，FPGA)，通用阵列逻辑(generic array logic，GAL)或其任意组合。也可以通过软件实现上述方法实施例提供的应用程序恢复运行的方法，当通过软件实现上述方法实施例提供的应用程序恢复运行的方法时，该应用程序恢复运行的装置中的各个模块也可以为软件模块。
图14是本发明实施例提供的再一种计算机的结构示意图，参考图14，该计算机可以包括：处理器1201、存储器1202、网络接口1203和总线1204。其中，总线1204用于连接处理器1201、存储器1202和网络接口1203。通过网络接口1203(可以是有线或者无线)可以实现与其他设备之间的通信连接。存储器1202中存储有计算机程序12021，该计算机程序12021用于实现各种应用功能。
应理解，在本发明实施例中，处理器1201可以是CPU，该处理器1201还可以是其他通 用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、GPU或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者是其它类型的处理器等。
存储器1202可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data date SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。
总线1204除包括数据总线之外，还可以包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见，在图中将各种总线都标为总线1204。
处理器1201被配置为执行存储器1202中存储的计算机程序，处理器1201通过执行该计算机程序12021来实现上述任意一个方法实施例中的步骤。存储器中的软件程序可以采用前述实施例提供的模块划分方式划分为多个模块，也可以采用其它的模块划分方式。
本发明实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当处理器读取该计算机可读存储介质中存储的指令时，使得处理器执行如上述方法实施例中的步骤。
本发明实施例还提供了一种包含指令的计算机程序产品，当处理器读取该计算机程序产品包含的指令时，使得处理器执行上述方法实施例中的步骤。
上述实施例，可以全部或部分地通过软件、硬件、固件或其他任意组合来实现。当使用软件实现时，上述实施例可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载或执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以为通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集合的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质。半导体介质可以是固态硬盘(solid state drive，SSD)。
以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (20)

  1. 一种应用程序恢复运行的方法，其特征在于，应用于计算机，所述计算机包括：虚拟机监视器，运行于所述虚拟机监视器上的客户机操作系统，以及运行于所述客户机操作系统上的应用程序，所述方法包括：
    响应于陷出请求，所述客户机操作系统中止运行所述应用程序，并陷出至所述虚拟机监视器；
    所述虚拟机监视器存储所述应用程序的恢复信息，所述恢复信息包括所述应用程序的上下文或所述上下文的存储地址；
    响应于所述应用程序的恢复请求，所述虚拟机监视器基于所述恢复信息恢复所述应用程序的上下文。
  2. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    所述客户机操作系统获取所述应用程序的所述恢复信息；
    所述客户机操作系统将所述恢复信息传递至所述虚拟机监视器。
  3. 根据权利要求2所述的方法，其特征在于，所述客户机操作系统将所述恢复信息传递至所述虚拟机监视器，包括：
    将所述恢复信息写入所述虚拟机监视器能够访问的寄存器或调用所述虚拟机监视器的接口将所述恢复信息传递至所述虚拟机监视器。
  4. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    所述客户机操作系统将所述客户机操作系统的上下文的存储地址传递至所述虚拟机监视器；
    所述虚拟机监视器存储所述应用程序的恢复信息，包括：
    所述虚拟机监视器基于所述客户机操作系统的上下文的存储地址，以及所述客户机操作系统的上下文的存储地址与所述应用程序的上下文的存储地址之间的关系，确定所述应用程序的上下文的存储地址；
    所述虚拟机监视器存储所述应用程序的上下文的存储地址，或者根据所述应用程序的上下文的存储地址，存储所述应用程序的上下文。
  5. 根据权利要求1至4任一所述的方法，其特征在于，所述恢复信息为所述应用程序的上下文；所述虚拟机监视器存储所述应用程序的恢复信息，包括：
    所述虚拟机监视器将所述应用程序的上下文存储至以下至少一种存储位置：
    所述应用程序所属虚拟机的控制结构体；
    所述应用程序所属虚拟处理器对应进程的管理结构体；
    所述计算机的内存中除所述控制结构体和所述管理结构体之外的存储位置。
  6. 根据权利要5所述的方法，其特征在于，所述计算机还包括：主机操作系统，以及安装在所述主机操作系统中的调试工具；所述应用程序的上下文存储在所述管理结构 体中；所述方法还包括：
    当检测到针对所述应用程序的调试指令时，通过所述调试工具基于所述应用程序的上下文在所述管理结构体中的存储地址，对所述应用程序进行调试。
  7. 根据权利要求1至6任一所述的方法，其特征在于，所述虚拟机监视器恢复所述应用程序的上下文，包括：
    所述虚拟机监视器将所述应用程序的上下文存储至对应的寄存器。
  8. 根据权利要求1至7任一所述的方法，其特征在于，所述陷出请求由以下任一种事件触发：
    所述应用程序触发的系统调用；
    所述应用程序触发的异常；
    所述计算机的硬件层上报的中断。
  9. 一种计算机，其特征在于，所述计算机包括：硬件层，运行于所述硬件层上的虚拟机监视器，运行于所述虚拟机监视器上的客户机操作系统，以及运行于所述客户机操作系统上的应用程序；
    所述客户机操作系统，用于响应于陷出请求，中止运行所述应用程序并陷出至所述虚拟机监视器；
    所述虚拟机监视器，用于存储所述应用程序的恢复信息，所述恢复信息包括所述应用程序的上下文或所述上下文的存储地址；
    所述虚拟机监视器，还用于响应于所述应用程序的恢复请求，基于所述恢复信息恢复所述应用程序的上下文。
  10. 根据权利要求9所述的计算机，其特征在于，所述客户机操作系统，还用于：在陷出至所述虚拟机监视器之前，获取所述应用程序的恢复信息；并将所述应用程序的恢复信息传递至所述虚拟机监视器。
  11. 根据权利要求10所述的计算机，其特征在于，所述客户机操作系统用于：将所述恢复信息写入所述虚拟机监视器能够访问的寄存器或调用所述虚拟机监视器的接口将所述恢复信息传递至所述虚拟机监视器。
  12. 根据权利要求9所述的计算机，其特征在于，
    所述客户机操作系统，还用于将所述客户机操作系统的上下文的存储地址传递至所述虚拟机监视器；
    所述虚拟机监视器，用于：
    基于所述客户机操作系统的上下文的存储地址，以及所述客户机操作系统的上下文的存储地址与所述应用程序的上下文的存储地址之间的关系，确定所述应用程序的上下文的存储地址；
    存储所述应用程序的上下文的存储地址，或者根据所述应用程序的上下文的存储地 址，存储所述应用程序的上下文。
  13. 根据权利要求9至12任一所述的计算机，其特征在于，所述恢复信息为所述应用程序的上下文；所述虚拟机监视器，用于将所述应用程序的上下文存储至以下至少一种存储位置：
    所述应用程序所属虚拟机的控制结构体；
    所述应用程序所属虚拟处理器对应进程的管理结构体；
    所述计算机的内存中除所述控制结构体和所述管理结构体之外的存储位置。
  14. 根据权利要13所述的计算机，其特征在于，所述应用程序的上下文存储在所述管理结构体中；所述计算机还包括：运行在所述硬件层上的主机操作系统，以及安装在所述主机操作系统中的调试工具；
    所述调试工具，用于当检测到针对所述应用程序的调试指令时，基于所述应用程序的上下文在所述管理结构体中的存储地址，对所述应用程序进行调试。
  15. 根据权利要求9至14任一所述的计算机，其特征在于，
    所述虚拟机监视器，用于将所述应用程序的上下文存储至对应的寄存器。
  16. 根据权利要求9至15任一所述的计算机，其特征在于，所述陷出请求由以下任一种事件触发：
    所述应用程序触发的系统调用；
    所述应用程序触发的异常；
    所述计算机的硬件层上报的中断。
  17. 一种应用程序恢复运行的装置，应用于计算机，所述计算机包括：虚拟机监视器，运行于所述虚拟机监视器上的客户机操作系统，以及运行于所述客户机操作系统上的应用程序，其特征在于，所述装置包括：
    部署在所述客户机操作系统内的中止模块，用于响应于陷出请求，中止运行所述应用程序并由所述客户机操作系统陷出至所述虚拟机监视器；
    部署在所述虚拟机监视器内的存储模块，用于存储所述应用程序的恢复信息，所述恢复信息包括所述应用程序的上下文或所述上下文的存储地址；
    部署在所述虚拟机监视器内的恢复模块，用于响应于所述应用程序的恢复请求，基于所述恢复信息恢复所述应用程序的上下文。
  18. 根据权利要求17所述的装置，其特征在于，所述装置还包括：
    部署在所述客户机操作系统内的获取模块，用于在陷出至所述虚拟机监视器之前，获取所述应用程序的恢复信息；
    部署在所述客户机操作系统内的传递模块，用于将所述应用程序的恢复信息传递至所述虚拟机监视器。
  19. 一种计算机，其特征在于，所述计算机包括：存储器，处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如权利要求1至8任一所述的应用程序恢复运行的方法。
  20. 一种计算机程序产品，其特征在于，所述计算机程序产品中存储有指令，当所述计算机程序产品在计算机上运行时，使得计算机执行如权利要求1至8任一所述的应用程序恢复运行的方法。
PCT/CN2019/128560 2019-01-18 2019-12-26 应用程序恢复运行的方法、装置及计算机 WO2020147544A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP19910376.3A EP3846028A4 (en) 2019-01-18 2019-12-26 APPLICATION EXECUTION RESUME METHOD AND DEVICE, AND COMPUTER
US17/369,546 US20210334125A1 (en) 2019-01-18 2021-07-07 Method and Apparatus for Resuming Running of Application, and Computer

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910049860.7 2019-01-18
CN201910049860.7A CN111459623B (zh) 2019-01-18 2019-01-18 应用程序恢复运行的方法、装置及计算机

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/369,546 Continuation US20210334125A1 (en) 2019-01-18 2021-07-07 Method and Apparatus for Resuming Running of Application, and Computer

Publications (1)

Publication Number Publication Date
WO2020147544A1 true WO2020147544A1 (zh) 2020-07-23

Family

ID=71613687

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/128560 WO2020147544A1 (zh) 2019-01-18 2019-12-26 应用程序恢复运行的方法、装置及计算机

Country Status (4)

Country Link
US (1) US20210334125A1 (zh)
EP (1) EP3846028A4 (zh)
CN (1) CN111459623B (zh)
WO (1) WO2020147544A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115145688A (zh) * 2022-06-29 2022-10-04 科东(广州)软件科技有限公司 一种用户态虚拟机虚拟核的暂停方法及装置

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114077519B (zh) * 2020-08-21 2022-11-18 荣耀终端有限公司 一种系统服务恢复方法、装置和电子设备
CN112596921A (zh) * 2020-12-17 2021-04-02 海光信息技术股份有限公司 系统调用处理方法及处理装置
CN113238832A (zh) * 2021-05-20 2021-08-10 元心信息科技集团有限公司 虚拟处理器的调度方法、装置、设备及计算机存储介质
CN114296915B (zh) * 2021-12-22 2024-07-05 中汽创智科技有限公司 一种操作系统调度方法、装置、设备及存储介质
CN116795557B (zh) * 2022-03-15 2024-07-23 华为技术有限公司 通信方法、电子设备及可读存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120042034A1 (en) * 2010-08-13 2012-02-16 Vmware, Inc. Live migration of virtual machine during direct access to storage over sr iov adapter
US20140366017A1 (en) * 2013-06-05 2014-12-11 Cisco Technology, Inc. Techniques for Virtualization as Interprocess Communication, Synchronization and Code Obfuscation
CN105700826A (zh) * 2015-12-31 2016-06-22 华为技术有限公司 虚拟化方法和装置
CN107239320A (zh) * 2017-04-11 2017-10-10 中国科学院信息工程研究所 基于虚拟化技术的实时保存客户机中进程状态的方法
CN109144679A (zh) * 2017-06-27 2019-01-04 华为技术有限公司 中断请求的处理方法、装置及虚拟化设备

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8261265B2 (en) * 2007-10-30 2012-09-04 Vmware, Inc. Transparent VMM-assisted user-mode execution control transfer
JP2010211526A (ja) * 2009-03-10 2010-09-24 Fujitsu Ltd プログラム、コンピュータ及び制御方法
US20120089972A1 (en) * 2010-10-08 2012-04-12 Microsoft Corporation Image Based Servicing Of A Virtual Machine
US8639984B2 (en) * 2011-08-09 2014-01-28 International Business Machines Corporation Checkpoint debugging using mirrored virtual machines
US9971616B2 (en) * 2013-02-26 2018-05-15 Red Hat Israel, Ltd. Virtual machine suspension
US9996378B2 (en) * 2013-10-09 2018-06-12 International Business Machines Corporation Managing a check-point based high-availability backup virtual machine
US9274823B1 (en) * 2014-12-24 2016-03-01 Parallels IP Holdings GmbH Thin hypervisor for native execution of unsafe code
US9715403B2 (en) * 2015-02-27 2017-07-25 Red Hat, Inc. Optimized extended context management for virtual machines
CN107885748B (zh) * 2016-09-30 2021-10-26 华为技术有限公司 虚拟化实例的文件分层访问方法和装置
US10698713B2 (en) * 2016-11-29 2020-06-30 Red Hat Israel, Ltd. Virtual processor state switching virtual machine functions

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120042034A1 (en) * 2010-08-13 2012-02-16 Vmware, Inc. Live migration of virtual machine during direct access to storage over sr iov adapter
US20140366017A1 (en) * 2013-06-05 2014-12-11 Cisco Technology, Inc. Techniques for Virtualization as Interprocess Communication, Synchronization and Code Obfuscation
CN105700826A (zh) * 2015-12-31 2016-06-22 华为技术有限公司 虚拟化方法和装置
CN107239320A (zh) * 2017-04-11 2017-10-10 中国科学院信息工程研究所 基于虚拟化技术的实时保存客户机中进程状态的方法
CN109144679A (zh) * 2017-06-27 2019-01-04 华为技术有限公司 中断请求的处理方法、装置及虚拟化设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3846028A4

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115145688A (zh) * 2022-06-29 2022-10-04 科东(广州)软件科技有限公司 一种用户态虚拟机虚拟核的暂停方法及装置

Also Published As

Publication number Publication date
CN111459623B (zh) 2024-04-12
CN111459623A (zh) 2020-07-28
EP3846028A1 (en) 2021-07-07
US20210334125A1 (en) 2021-10-28
EP3846028A4 (en) 2022-05-25

Similar Documents

Publication Publication Date Title
WO2020147544A1 (zh) 应用程序恢复运行的方法、装置及计算机
US10859289B2 (en) Generating and using checkpoints in a virtual computer system
US10073713B2 (en) Virtual machine migration
US9396013B2 (en) Method for controlling a virtual machine and a virtual machine system
US10621010B2 (en) Information processing apparatus and migration method
US9996401B2 (en) Task processing method and virtual machine
US8352933B2 (en) Concurrent patching of operating systems
US10289684B2 (en) Live migration of virtual machine persistent data using mirrored input-output operations
US8694828B2 (en) Using virtual machine cloning to create a backup virtual machine in a fault tolerant system
US7412702B1 (en) System software displacement in a virtual computer system
US10152409B2 (en) Hybrid in-heap out-of-heap ballooning for java virtual machines
US20100332722A1 (en) Virtual machine system and control method thereof
WO2020157599A1 (en) Engine pre-emption and restoration
US20040194086A1 (en) Suspend and resume method of computer job
JP2011243012A (ja) 仮想計算機システムのメモリダンプ取得方法
US20240202122A1 (en) Memory coherency in application-level virtualization
JP2022055002A (ja) 情報処理装置、情報処理方法および情報処理プログラム
JP2022107229A (ja) 情報処理装置、制御方法及び制御プログラム
WO2019052643A1 (en) STORAGE I / O PROJECTED IN MEMORY
CN113918272A (zh) 分离式虚拟机及其虚拟机架构、构建方法和优化方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19910376

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019910376

Country of ref document: EP

Effective date: 20210330

NENP Non-entry into the national phase

Ref country code: DE