WO2020244369A1 - 进程间通信的方法、装置以及计算机设备 - Google Patents

进程间通信的方法、装置以及计算机设备 Download PDF

Info

Publication number
WO2020244369A1
WO2020244369A1 PCT/CN2020/090559 CN2020090559W WO2020244369A1 WO 2020244369 A1 WO2020244369 A1 WO 2020244369A1 CN 2020090559 W CN2020090559 W CN 2020090559W WO 2020244369 A1 WO2020244369 A1 WO 2020244369A1
Authority
WO
WIPO (PCT)
Prior art keywords
context
caller
register
callee
memory
Prior art date
Application number
PCT/CN2020/090559
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 CA3142633A priority Critical patent/CA3142633A1/en
Priority to EP20818952.2A priority patent/EP3968160A4/en
Publication of WO2020244369A1 publication Critical patent/WO2020244369A1/zh
Priority to US17/540,948 priority patent/US20220091911A1/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/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/54—Interprogram communication
    • G06F9/544—Buffers; Shared memory; Pipes

Definitions

  • This application relates to computer technology, in particular to a method, device, and computer equipment for inter-process communication.
  • Microkernel-based operating system architecture (microkernel architecture for short) is widely used in cloud platforms, embedded devices, mobile devices, unmanned driving and other scenarios.
  • the micro-kernel architecture reduces its true core functions to very few, and puts many components in the traditional operating system kernel (such as the macro-kernel architecture Linux), such as the file system and network protocol stack, in a user-mode process. .
  • the microkernel architecture can ensure that any module that undertakes complex functions can be placed in a user-mode process, and can make different processes run in isolation. This method can greatly enhance the isolation and reliability of the operating system.
  • the file system is only an application in the microkernel architecture.
  • a malicious application attacks a file system
  • only the files that can be accessed by this file system may be accessed by the malicious application, while other file systems and Other system components (such as memory management components) are still in a protected state.
  • a certain file system triggers an internal vulnerability and causes the file system to crash, it will only affect the file system itself, but not the correctness of the entire operating system. And the administrator can easily restart a file system to continue providing services. This also provides better reliability than traditional operating system kernels.
  • the microkernel architecture also brings a huge performance loss.
  • IPC Inter-Process Communication
  • the file system as the callee is deployed in the kernel state.
  • a caller that is, a database application
  • the database application needs to communicate with the file system through IPC.
  • the performance overhead of IPC comes from many aspects, among which the more critical is the context switch (sometimes referred to as "switch" in this application) overhead.
  • context switch sometimes referred to as "switch” in this application
  • the interaction between application programs and system services is implemented through system calls, which are operations directly supported by hardware, which makes a single system call very efficient.
  • privileged instructions for context switching such as switching page tables, can only be completed in the kernel mode, and the caller and the callee are running in the user mode, so they must trap to the kernel mode to perform the switch , The intervention of the kernel leads to a greatly increased communication overhead relative to the macro kernel.
  • Direct Process Switch Direct Process Switch
  • This kind of scheme still needs the kernel to carry on IPC processing, just carry on the simplest IPC processing logic, only include the necessary stage.
  • the kernel skips other stages and directly switches to the corresponding context, so that IPC communication is accelerated to a certain extent.
  • this solution still requires kernel intervention to complete the context switch, and the overhead of the context switch is still relatively large, resulting in a relatively long IPC communication duration.
  • This application provides a method for inter-process communication, and provides a device, computer program product (such as an operating system), storage medium, and computer equipment that implement the method, so as to shorten the communication duration of IPC.
  • the present application will be introduced from multiple aspects below. It is easy to understand that the following multiple aspects can be implemented individually, or any two or more of them can be implemented in combination. The specific implementation and beneficial effects of the following aspects can be referred to each other.
  • the present application provides a method of inter-process communication, which is applied to a computer device, and the computer device includes a hardware layer and an operating system running on the hardware layer.
  • the operating system may be a system based on a micro-kernel architecture or a system based on a macro-kernel architecture.
  • the operating system runs the caller and the callee to be communicated.
  • the computer device also includes a communication engine, which is called an XPC engine in the embodiment, and is used to implement inter-process communication.
  • the communication engine can be set on the processor at the hardware layer, or can be used as an independent hardware device.
  • the communication engine can also be implemented by software simulation.
  • the method includes: the caller calls a first instruction (for example, xcall), and the first instruction is executed by the communication engine to switch directly from the context of the caller to the context of the callee. Further, the callee invokes a second instruction (for example, xret), and the second instruction is executed by the communication engine to realize a direct switch from the context of the callee to the context of the caller.
  • a first instruction for example, xcall
  • the callee invokes a second instruction (for example, xret)
  • the second instruction is executed by the communication engine to realize a direct switch from the context of the callee to the context of the caller.
  • the first instruction and the second instruction may not be implemented at the same time.
  • the caller and the callee can be threads (or processes).
  • the context of a thread (or process) is the various states of the thread maintained in the operating system, usually including general registers, page tables, thread private spaces, and threads used by the thread. Metadata and other parts. Since the definition and use of context may be different in different computer systems, the context content of the above examples should not be used as the basis for limiting the solution of this application. In addition, the context mentioned in this application can refer to the entire context or part of the context. The caller and the callee can also be understood as applications in some other embodiments.
  • the caller and the callee When the operating system is a microkernel architecture, the caller and the callee usually run in a user mode. In traditional IPC communication, the caller and the callee need the participation of the kernel to complete the context switch, which brings overheads such as the switch between the user mode and the kernel mode, which leads to a longer communication time.
  • the caller and the callee can realize direct context switching by calling the first instruction and the second instruction, which avoids the intervention of the kernel to a certain extent, thereby shortening the communication duration of IPC .
  • running this method under the macro-kernel architecture can also increase the communication speed.
  • the communication engine when it executes the first instruction, it further includes: acquiring capability information of the caller, where the capability information is used to indicate whether the caller has the authority to call the callee
  • the callee's context is determined according to the callee identifier in the first instruction; the context of the caller is saved ; Switch to the context of the callee.
  • the capability check is performed by the kernel. In this application, the capability check is also performed in the communication engine, which further reduces the intervention of the kernel, thereby further shortening the communication duration of the IPC.
  • the communication engine further includes one or more of the following detections when executing the first instruction: detecting whether the callee ID is legal, detecting whether the callee is legal, or It is detected whether the storage space for storing the context of the caller is sufficient.
  • detections such as legitimacy and the enablement of kernel processing exceptions make the communication engine provided in this application more secure and reliable.
  • the method further includes: saving the context of the caller, where the context is part of the context of the caller.
  • the saving context mentioned in this application can refer to saving all contexts or saving part of the context, which is determined according to system requirements. Part of the context is the key and core context information required by the system, so saving can reduce the amount of storage, thereby reducing the storage space occupation, and further shortening the communication duration of the IPC.
  • operations such as accessing capability information and saving context information can be implemented by accessing registers.
  • the registers store the storage addresses of corresponding information to indicate the location of these information. .
  • the method further includes: the caller applies for a memory area, and sets the address of the memory area in a register included in the communication engine; and the caller transmits to the target
  • the data of the caller is stored in the memory area, and the callee is used to access the memory area through the address stored in the register to obtain the data.
  • the caller applies for a memory area and records the address information of the memory area in a register (seg-reg), and then the callee can access the register to obtain data.
  • This type of memory area is referred to as a relay segment or relay segment memory in the specific embodiment of the present application. In this way, the callee can directly read the data that the caller needs to pass from the memory area pointed to by the register, avoiding the copying of data between the caller and the callee, and further shortening the IPC communication duration .
  • the area may not be a memory, but may be another type of storage area.
  • the method further includes: the caller calls a third instruction (for example, swapseg), and the third instruction is executed by the communication engine to realize the conversion of the data in the first register (for example, seg-reg)
  • the address is updated to the address in the second register (for example, seg-list-reg).
  • this application provides a method for implementing inter-process communication.
  • This method can be applied to the communication engine (for example, XPC engine) of the aforementioned first aspect.
  • the communication engine can be used as an extension unit of the current processor, can also be used as an independent processing unit, or can be implemented by program simulation.
  • the method includes: receiving a first instruction (for example, xcall#register) sent by a caller, and the first instruction contains the identity of the callee (#register); according to the callee’s identity in the first register (for example, xcall#register) -entry-table-reg) indicates the context of the callee in the service set (for example, x-entry table) indicated, the first register is used to store the memory address of the service set, and the service set includes one Or multiple callee’s context information; save the caller’s context in the return information set (such as link stack) indicated by the second register (such as link-reg), and the second register is used to store the The memory address of the return information set, the return information set includes the context information of one or more callers; switch to the context of the callee.
  • the first register and the second register are both readable and writable by the kernel, so this extension can still provide the kernel with a security configuration interface, such as service registration, permission authorization, or exception handling, etc. Allow the kernel to limit the switching behavior, and realize the guarantee of safety and performance in the case of direct switching in user mode.
  • the method before the determining the context of the callee in the service set indicated by the first register according to the callee identifier, the method further includes: according to a third register (for example, xcall-cap -reg) indicated capability information (for example, xcall cap bitmap) determines that the caller is authorized to call the callee, the third register is used to store the address of the capability information, and the capability information is used to indicate all Whether the caller has the authority to call the callee.
  • the capability check is also implemented in the extended communication engine, which further reduces the intervention of the kernel, shortens the communication time and also ensures the security of the call.
  • the method further includes: prefetching any one or two of the following information into the cache: context information of one or more callees included in the service set, or the Ability information.
  • the cache is a storage medium that the communication engine can read and write more quickly. Since the service collection, return information collection, capability information collection, etc. are stored in the memory, the memory access mechanism is required to read and write these information, and the cache access speed is faster than the memory, so by setting the cache and the above prefetching process, The efficiency of data access can be further improved, thereby further shortening the communication duration of IPC.
  • the following steps are performed in an asynchronous manner: saving the context of the caller in the return information set indicated by the second register.
  • the so-called asynchronous mode here means that the subsequent operations of this step do not need to wait for the completion of this step. This can further improve the operating efficiency of the method, thereby further shortening the communication duration of the IPC.
  • the step of determining the context of the callee or the step of saving the context of the caller is implemented by using a tagged conversion detection buffer TLB.
  • the above steps may involve page table switching in memory access.
  • Using the tagged TLB mechanism can avoid the TLB refresh operation in page table switching, and improve the operating efficiency of the method.
  • the method further includes: granting the callee the access right of the memory area indicated by a fourth register (for example, seg-reg), wherein the fourth register is used to store the memory area
  • the memory area (referred to as the relay segment memory in the embodiment) is requested by the caller, and the memory area is used to store data to be transmitted by the caller to the callee.
  • the callee can access the caller's data, avoiding the copying of data between the caller and the callee, and further shortening the IPC communication duration.
  • This method can also be called "register transfer".
  • the method further includes: granting access rights to the second memory area indicated by the fourth register (for example, seg-reg) and the fifth register (for example, seg-mask) to the callee, wherein The fourth register is used to store address information of the first memory area, the fifth register stores information used to reduce the first memory area, and the second memory area is the reduced first memory area. In this way, the memory area accessible to the callee is restricted, which improves the flexibility and security of data transmission.
  • the fourth register for example, seg-reg
  • the fifth register for example, seg-mask
  • the access authority of the register may be pre-configured, and the access authority may include user mode read/write, or kernel read/write, etc.
  • the fourth register and the fifth register can be configured as user mode read/write, so that the caller and callee running in the user mode can access these two registers.
  • the operating system opens an access interface to user-mode applications, similar to shared memory, where users access registers through the interface.
  • the method further includes: receiving a second instruction (for example, xret) sent by the callee, where the second instruction is used to instruct to return to the context of the caller; and from the second register Acquire the context of the caller from the return information set (such as link stack) indicated by (for example, link-reg); switch to the context of the caller.
  • a second instruction for example, xret
  • the second instruction is used to instruct to return to the context of the caller
  • the saved context of the caller is part of the context of the selected caller.
  • the caller and the callee can be threads (or processes).
  • the context of a thread (or process) is the various states of the thread maintained in the operating system, usually including general registers, page tables, thread private spaces, and threads used by the thread. Metadata and other parts can be fully saved when the context is saved, or partly saved as in this implementation, which saves storage space and improves storage speed, thereby further shortening the communication duration of the IPC.
  • context switching and relay segment memory provides a basic mechanism for the rapid communication of IPC.
  • the operating system especially the kernel, can also configure and manage the above mechanisms.
  • this application also provides a method for managing inter-process communication, which can be executed by the operating system, and specifically, can be executed by the operating system kernel layer or the user-mode library layer.
  • the method includes: receiving a service registration request from a server, where the service registration request is used to request a registration service; and storing the context information of the service in the first register (for example, x-entry-table-reg) according to address information A storage area, the address information indicates the first storage area.
  • This method implements the registration process of service information and provides a basis for the call of customers.
  • the method further includes: receiving an authorization request for the client, the authorization request is used to request the authorization of the service call authority to the client; when it is determined that the client has the authority to call the service, The capability information of the client is set to indicate that the client has the authority to call the service, the capability information is stored in a third storage area, and the address information of the third storage area is stored in a third register (for example, xcall-cap- reg).
  • the kernel sets the capability information pointed to by the address information according to the address information stored in the third register.
  • the method further includes: receiving an exception; when it is determined that the exception is a communication exception in the communication between the client and the server, reading the context information of the client from the returned information set, the returned information set including Context information of one or more callers (also called clients), the returned information set is stored in a second storage area, and the address information of the second storage area is stored in a second register (for example, link-reg) ; Perform a recovery operation based on the client's context information.
  • the kernel finds and reads the context information corresponding to the client in the returned information set according to the address information stored in the second register. Through this method, the kernel can correctly handle the abnormalities in the IPC communication process.
  • the present application also provides a memory allocation method, which is used to allocate relay segment memory, and the method can be executed by the kernel.
  • the method includes: in response to a memory application request, determining whether the physical memory area to be allocated has an intersection with the allocated physical memory area; when it is determined that the physical memory area to be allocated does not have an intersection with the allocated physical memory area When, mark the physical memory area to be allocated as allocated; allocate a virtual memory area, and save the mapping relationship between the physical memory area to be allocated and the virtual memory area in the fourth register (for example, seg-reg) Medium; returns the address of the virtual memory area.
  • This "allocated physical memory area" includes allocated relay segment memory and normal memory. In this way, the allocation of the relay segment memory by the kernel is realized, and the uniqueness of the relay segment memory is guaranteed.
  • marking the physical memory area to be allocated as allocated includes: When there is no intersection between the allocated physical memory area and the allocated physical memory area, and it is determined that there is no intersection between the currently used physical memory area and the allocated physical memory area, mark the physical memory area to be allocated Is assigned. Determining that it does not overlap with the relay segment memory currently in use can effectively avoid memory leaks.
  • the step further includes: clearing the fourth register in response to a memory release request. Timely memory release can improve memory utilization.
  • this application also provides a memory management method as an extension of a memory management unit (MMU).
  • the method includes: receiving a virtual address, which may be derived from a memory access request; and determining the virtual address Whether it is in the virtual address range of the relay segment memory, the mapping relationship between the virtual address range of the relay segment memory and the corresponding physical address range is stored in the relay segment register (for example, seg-reg); when it is determined that the virtual address is at all When the virtual address is in the range, the physical address corresponding to the virtual address is determined according to the mapping relationship stored in the relay segment register.
  • This method realizes the translation of the virtual address of the relay segment memory through the register by simply extending the MMU , Improve the access speed of relay segment memory.
  • the present application also provides a method, which includes: the kernel receives an exception or a system call; the kernel obtains the runtime context of the thread from the state maintained by the communication engine, and processes the thread according to the runtime context. Exception or system call.
  • This application proposes a separation context model: runtime context and scheduling context. The scheduling context is maintained by the kernel, and the runtime context is maintained by the communication engine provided by this application, such as the register xcall-cap-reg.
  • the separated context model extends the context management of the existing kernel.
  • the present application also provides a method for dynamically expanding service threads.
  • the method includes: when it is determined that the same service receives requests from multiple clients, creating multiple worker threads corresponding to the multiple clients one-to-one And creating multiple running contexts of the multiple worker threads, the context of one worker thread includes the scheduling context of the corresponding client and the created running context.
  • This method is based on the separated context model, which realizes the dynamic expansion of server threads and can reuse the scheduling context of blocked clients.
  • the cross-core interaction can be turned into a single-core interaction, avoiding cross-core cross-core interrupts and other overheads.
  • this application also implements the device, computer storage medium, and computer program product of the method.
  • the present application provides a computer device that includes a hardware layer and an operating system running on the hardware layer.
  • the operating system runs the caller and the callee to be communicated, and the computer
  • the device further includes a communication engine for executing the method according to any one of the foregoing second aspect.
  • the communication engine is integrated on the existing processor of the computer device, it can be used as an extension of the processor core.
  • the communication engine refers to the "processor".
  • the communication engine refers to another processing unit that has independent processing capabilities and can be used as an accelerator for the existing processor.
  • the present application provides a device for inter-process communication.
  • the device includes one or more modules for implementing the method provided in any one of the foregoing first to seventh aspects.
  • the device may be a communication engine for implementing the method described in the foregoing second aspect or any one of its implementation manners.
  • the present application provides an inter-process communication device, which may be a chip.
  • the device includes a processor core and a plurality of registers, wherein the processor core is used to execute the method described in any one of the second aspect.
  • this application provides a memory management unit MMU.
  • the memory management unit includes one or more modules for implementing the method provided in any one of the foregoing fifth aspects.
  • this application provides a computer storage medium for storing a computer program, and when the computer program is executed by one or more processors, any one of the first aspect to the seventh aspect is implemented Provided method.
  • this application provides a computer program product, the computer program product is used to store a computer program, and when the computer program is executed by one or more processors, any one of the first aspect to the seventh aspect is realized Provided method.
  • this application provides a computer device.
  • the computer device may be a terminal device, such as a smart phone.
  • the computer device may also be a smart device used in unmanned driving, or virtual reality/augmented reality/mixed reality.
  • the terminal equipment includes any of the foregoing inter-process communication devices or any type of MMU.
  • the computer device can also be a server.
  • the information stored in two or more registers in the device can also be combined into one register.
  • the number of devices is not limited.
  • Figure 1 shows the comparison of the file system used by the micro-kernel and the macro-kernel
  • FIG. 2 is a schematic diagram of the structure of an XPC system provided by this application.
  • FIG. 3 is a schematic diagram of relevant parts of context switching in an XPC system provided by this application.
  • Figure 4 is a schematic flow diagram of the xcall and xret instructions provided by this application.
  • FIG. 5 is a schematic diagram of related parts of the relay segment memory in an XPC system provided by this application.
  • FIG. 6 is a schematic diagram of a memory management method provided by this application.
  • FIG. 7 is a schematic structural diagram of a kernel layer in an XPC system provided by this application.
  • Figure 8 is a schematic diagram of the concept and application of the separated context model provided by this application.
  • Figure 9 is a schematic diagram of part of the process of the kernel to realize the management and configuration of the XPC engine
  • FIG. 10 is a schematic diagram of the process of application and release of relay segment memory by the kernel
  • FIG. 11 is a schematic diagram of the overall flow of the IPC communication solution for inter-process communication provided by this application.
  • Figure 12 is a comparison between traditional inter-process communication and XPC communication provided by this application.
  • Figure 13 is a schematic diagram of the application of the XPC solution provided by this application on the Sqlite3 database
  • Figure 14 is a schematic diagram of the test results of the Sqlite3 database after applying the XPC solution provided by this application;
  • FIG. 15 is a schematic diagram of the dynamic expansion of the server thread provided by this application.
  • Figure 16 is a schematic diagram of the application of the solution provided by this application on Linux;
  • Figure 17 is a schematic diagram of the test results of the solution provided by this application after being applied on Linux;
  • FIG. 18 is a schematic structural diagram of a terminal device provided by this application.
  • the performance overhead of IPC mainly comes from two aspects.
  • context switching which can be referred to the description in the background technology section.
  • the context appearing in this application generally refers to the thread (or process) context. Specifically, it refers to the various states of a thread (or process) maintained in an operating system, usually including the registers, page tables, and Thread private storage space, thread metadata, etc.
  • the second is the overhead of data transmission.
  • copy or shared memory solutions are usually used. Using copy will bring a lot of performance overhead, especially for some applications with relatively large data circulation; while the shared memory solution can achieve zero copy in theory, but there is a time of Check to Time of Use, TOCTTOU) security issues.
  • the solution provided by this application is a software-hardware collaboration solution.
  • this application designs a set of hardware architecture for cross-process calls.
  • This solution provides support for context switching in the underlying hardware. Context switching needs to switch various states and information of the two process spaces (the caller and the callee).
  • the call information will be recorded in a hardware-controlled data structure, and the information in this data structure will be used in the check when the process returns.
  • the solution also provides support for fast data transmission in hardware. By simply extending the hardware, such as TLB, the solution supports zero-copy data transmission.
  • this application provides a software design solution of the kernel system on the basis of the above hardware architecture to ensure the safety and performance of direct process calling and zero copy.
  • cross-process communication system is named XPC (cross-process call), but XPC is only a name and should not be used as a limitation to this application.
  • FIG. 2 is a schematic diagram of the structure of the XPC system provided by this embodiment.
  • the system includes application layer, user mode library layer, kernel layer and hardware layer.
  • Application layer Run a variety of multiple applications: application-1 to application-n.
  • the optimization of inter-process communication provided by this solution is transparent to this layer to ensure compatibility.
  • User mode library layer contains two modules, the switching interface module 301 and the relay segment memory interface module 302. These two modules will provide the inter-process communication call interface required by the application, and will encapsulate the relay segment memory to provide an interface similar to the shared memory.
  • Kernel layer contains four modules, switching management module 201, relay segment memory management module 202, XPC hardware management module 203, and separation context management module 204.
  • the hardware management module 203 is responsible for directly operating the new instructions provided by the hardware layer to implement context switching between processes.
  • the switching management module 201 and the relay segment memory management module 202 are respectively responsible for the security maintenance and management of context switching and data transmission at the software layer.
  • the separated context module 204 is responsible for the runtime security of the kernel management user mode based on the new hardware primitives.
  • Hardware layer It includes two hardware modules, the switcher 101 and the data transmitter 102, so as to realize the inter-process communication capabilities such as context switching and data transmission together with the software layer.
  • the switcher 101 is responsible for realizing functions such as context switching and permission checking, and the data transmitter is responsible for realizing data transmission.
  • the switch 101 and the data transmitter 102 can be set on an existing processor, as an extension unit of the processor, using the computing power of the existing processor, or as one or more hardware independent of the existing processor Unit, to accelerate the existing processor.
  • the switch 101 and the data transmitter 102 can also be implemented by software simulation.
  • the two modules of the switch 101 and the data transmitter 102 are functionally and logically divided, and it is not limited that they must be two independent hardware units. These two functions will be introduced in detail in the hardware design of the XPC engine introduced next.
  • the switcher 101, the switch management module 201, and the separated context management module 204 provide a fast context switch interface to the user mode library layer and the application layer.
  • the data transmitter 102 and the relay segment memory management module 202 provide a safe, zero-copy cross-process data transmission interface to the user mode library layer and the application layer.
  • the hardware layer provides the ability to communicate between processes, including capability checking, context switching, and a safe and effective data transmission mechanism
  • the kernel layer is implemented through operations such as the configuration of the hardware layer Management and control of process communication.
  • this application mainly proposes an XPC engine and relay segment memory, thereby providing a hardware basis for solving two problems: fast cross-process switching and zero-copy secure data transmission.
  • this application mainly proposes an XPC engine and relay segment memory, thereby providing a hardware basis for solving two problems: fast cross-process switching and zero-copy secure data transmission.
  • Caller It can also be called a client or a client, which refers to the party that uses the service in the traditional IPC communication or the XPC communication provided by this application.
  • the caller can be a process, thread, or application, depending on the context in which it appears.
  • Callee It can also be called a server, which refers to the party that provides services in traditional IPC communication or XPC communication provided by this application.
  • the callee can be a process, thread, or application, depending on the context in which it appears.
  • caller and the callee are only role names and do not point to a specific process, thread, or application.
  • call chain When multiple callees exist, it is also called a call chain. For example, A calls B and B calls C, then A, B, and C form a call chain.
  • x-entry means: a process can create one or more x-entry.
  • An x-entry is used to represent a process that can be invoked by other processes (invoked).
  • Each x-entry has a unique identifier (identifier, ID or id).
  • Call capability It is the abbreviation of "XPC call capability", used to record the capabilities of each caller. In this embodiment, it is represented by a bitmap pointed to by a register.
  • Relay segment memory in this embodiment refers to a memory area with a continuous address space, or can be understood as a continuous virtual address space to a continuous physical address space Mapping.
  • the virtual address to physical address mapping (or address translation) is implemented by a newly added register in this embodiment. This register can be transferred from the caller to the callee, so the callee can directly access the Data in the virtual address space indicated by the register.
  • the relay segment Before the relay segment is transferred to the callee, it can also be covered, that is, only part of the memory space is transferred (refer to Figure 3(b)). It should be noted that in other embodiments, by introducing a page table (page table) design, the relay segment memory proposed in this application can also support discontinuous memory space.
  • the program model of XPC hardware design (which can also be understood as the basic principle of use) is: the server registers the x-entry by passing the procedure handler, the handle thread, and a maximum context number.
  • the maximum context number is used to indicate the maximum number of simultaneous callers.
  • the handle thread is used to provide the client with runtime state, and the handle thread can be shared by multiple x-entries.
  • the server enters the waiting state.
  • the client usually obtains an x-entry ID and its own XPC call capability from the parent process or a naming service. Then, the client can implement a call to the aforementioned x-entry by executing a specific instruction (xcall in this embodiment).
  • xcall can carry a parameter, which is used to indicate the ID of the x-entry to be called.
  • ID is stored in any general register, so the identifier #reg of the register can be used to identify the parameter.
  • xcall and xret are two hardware-level instructions provided by the XPC engine. Calling these two instructions bypasses the kernel and directly allows the hardware to participate in the context switching, thereby greatly improving the efficiency of context switching. Further, the data transmission between the client and the server is realized through relay segment memory and newly added registers, thus avoiding data copy.
  • Instructions, commands, functions, or function interfaces refer to the names of methods and procedures implemented by software or hardware that are displayed and callable.
  • Figure 3(a) is a schematic structural diagram of the XPC engine provided by this embodiment.
  • the XPC engine is set on an existing processor core as an extension of the existing processor core.
  • the XPC engine includes multiple registers and XPC logic.
  • the XPC engine can be used as a processing unit independent of the existing processor to accelerate the existing processor.
  • the XPC engine can also be implemented by software simulation.
  • the software runs in a higher-level mode, such as RISC-V, a permission-level machine with higher authority than supervisor mode. Mode (machine mode), then you can use software to implement the XPC engine and run in this machine mode.
  • Figure 3(c) further shows the meaning of the registers related to context switching on the basis of Figure 3(a).
  • the register x-entry-table-reg is used to store the physical address.
  • the physical address is used as the base address and points to a memory area that stores information about the services that the server can provide, and this information can be stored in the form of x-entry table shown in the figure.
  • the "base address" is the start address of an address range.
  • Each row in the x-entry table indicates an x-entry.
  • the ID of each x-entry can be identified by the row number of the row, or a column can be added to the table to store the ID of the x-entry.
  • Each x-entry includes attributes such as a page table pointer (page table pointer), a capability pointer (capability pointer), an entry address (entry address), and a valid bit (valid).
  • the page table pointer is the page table base address, that is, the value stored in the page table register for page table translation in the prior art.
  • the capability pointer is also the base address, which is the value stored in the new register xcall-cap-reg introduced in this embodiment, and points to a data structure.
  • the entry address refers to the address of the function executed by the processor after switching to the server context.
  • the valid bit indicates whether an x-entry is legal. It should be noted that the content of the table can be customized to be reduced or expanded under different architectures, and the figure is only an example.
  • the register x-entry-table-size is used to store the size information of the data structure. Specifically, this register is used to store the size of the aforementioned x-entry-table.
  • the register xcall-cap-reg is used to store the physical address.
  • the physical address is used as the base address and points to a memory area where the bitmap (bitmap) xcall-cap bitmap shown in the figure is stored.
  • This bitmap represents the ability or authority of a caller to perform XPC. Only when the bit specified in the bitmap is correctly set, can the process XPC communication be performed. In other words, the context switch can only be performed if the process has the appropriate permissions.
  • the size of the bitmap can also be stored in x-entry-table-size. Specifically, the value of each bit identified as i in the bitmap represents whether the caller can call the x-entry with id i.
  • the bitmap can be stored in the private memory region (per-thread memory region) of thread m. If the value of the bit marked as 2 in the bitmap is 1, it means the thread m can call x-entry with id 2; if the value of the bit identified as 2 is 0, it means that thread m cannot call x-entry with id 2.
  • the meaning of each digit value can also be opposite to the above example.
  • the bitmap is maintained by the kernel, but is checked by the hardware when executing xcall.
  • each flag in the bitmap is The value of the bit of i represents whether the callee can be called by the caller with id i.
  • the register link-reg is used to store the physical address.
  • the physical address is used as the base address and points to a memory area in which the stack link stack shown in the figure is stored.
  • the link stack is responsible for saving the information used to return the context of the caller (this information may also be referred to as call information), which is used to restore the state of the caller when a specific instruction (such as xret) is executed and returned to the caller.
  • the information of each row in the link stack can be called a link (linkage) record, including the caller page table pointer, caller capability, return address, Caller relay segment and valid bits.
  • the format of the information stored in these columns is similar to the x-entry table, and will not be repeated. It should be noted that the contents of the stack can be customized to be reduced or expanded under different architectures, such as increasing the memory list of the caller's relay segment.
  • the link stack is actually used to save the context of the caller so that it can be restored after the service is completed.
  • the context saving is divided into two parts.
  • One part is saved on the link stack when the hardware executes the xcall instruction.
  • the content of this part is saved on the link stack; the other part is the context saving at the software level.
  • the software can call xcall Some states are saved in the software memory before the instruction. These states can be all contexts or partial contexts.
  • the selection strategy of full preservation or partial preservation can be determined according to system requirements, which is not limited in this application.
  • the context can be saved according to the trustworthiness of the callee. If the callee is trustworthy, a small amount of context information is saved; if the callee is not trustworthy, then all the context information is saved.
  • the above four registers are related to direct context switching, and in this embodiment are mainly used to implement the context switching process without kernel intervention.
  • the above four registers mainly maintain three data structures, namely x-entry table, link stack, and xcall-cap bitmap.
  • First 1 check whether switching is allowed through xcall-cap bitmap, then 2 switch to the server context through x-entry table. After the service execution is completed, 3 according to the link stack record The information is returned to the caller context.
  • these three data structures are not indispensable. In this embodiment, these three data structures all allow kernel access but not user mode access. It should be noted that these three data structures are only examples. In specific implementation, the information they contain can also be stored in other forms.
  • the information stored in the xcall-cap bitmap can also use the root tree (radix tree). Form storage, the root tree is similar to a page table, which has better scalability than bitmaps.
  • the solution provided in this embodiment directly supports inter-process calls in the hardware.
  • the hardware layer Based on the design of the aforementioned XPC engine, the hardware layer provides two instructions to the user mode: xcall and xret, which are used as call instructions and return instructions for inter-process calls, respectively. xcall will complete permission checking and jump logic at the hardware layer, and xret will return to the previous process environment through the stack maintained by the hardware (the aforementioned link stack).
  • xcall and xret are implemented by hardware circuits in the XPC logic.
  • xcall and xret can also be implemented partly by hardware circuits, partly by software programs, or all by software programs.
  • xcall mainly includes 5 steps shown in the figure.
  • the caller will also send the callee's id when using xcall. Obtain the corresponding bit from the xcall-cap bitmap according to the id.
  • 2Check xcall permissions If the value of the acquired bit is 1, it means that it has permission to switch; if the bit is 0, it means that it does not have permission, which will trigger an exception or return an error.
  • this step can also be put after 4 and combined with 5.
  • the page table pointer refers to the value of the page table register
  • the relay segment refers to the value in the relay segment register
  • the capability refers to the value in xcall-cap-reg
  • the return address refers to the program counter (PC)
  • PC program counter
  • step 4 can be implemented in an asynchronous manner, such as a non-blocking method of Linux, which avoids the hardware having to wait for the completion of this step before executing the next step, further reducing the switching time.
  • the solution provided in this application may further include a cache for prefetching x-entry.
  • This design is mainly based on two considerations: 1. For each caller, especially when the caller is a thread, IPC has a high temporal locality; 2. IPC is predictable. Based on these two considerations, this application can design a software-managed cache for the XPC engine, and use the cache to store one or more x-entries. Based on this design, user-mode applications can store some x-entry in the cache in advance, further shortening the communication duration of IPC.
  • xret mainly includes the 2 steps shown in the figure. During the xcall process, the caller's information will be recorded in the link stack. During xret, read the information from the top of the link stack (1). Modify the page table pointer, capability, entry address, etc. to the information read from the link stack (2), so that the context of the caller is restored.
  • it can also include checking whether the link stack is empty, checking the valid bits read from the link stack, and whether the current relay segment register matches the value recorded in the link stack, etc. If it is empty, invalid or A mismatch will trigger an exception or return an error.
  • inspection measures can be selected and implemented according to the actual situation, not implemented, fully implemented or partially implemented, which is not limited in this application.
  • the generated exceptions or errors can be reported to the kernel for processing.
  • a tagged conversion detection buffer Translation Lookaside
  • Buffer, TLB Buffer, TLB
  • ASID is used to indicate which process this TLB belongs to. This method can make it unnecessary to refresh the entire TLB during context switching between processes.
  • the relay segment memory mechanism provided in this application may not be used, for example, a shared memory mechanism is used. If the relay segment memory mechanism is not used, there is no need to consider the content related to the relay segment in the xcall or xret process. For example, if the shared memory mechanism is used, the caller and the callee can use the shared memory interface. The implementation of the shared memory can refer to the prior art, which will not be repeated in this application.
  • the hardware exposes a series of configurable registers to the kernel based on the above XPC engine, and gives two instructions xcall and xret for context switching. Based on this design, user-mode applications can complete context switching without falling into the kernel, which improves the efficiency of context switching, thereby improving the efficiency of IPC.
  • the hardware provided in this application also supports zero-copy IPC data transmission, and at the same time can ensure the security of data transmission.
  • the XPC engine also includes three registers: the relay segment register seg-reg, the relay segment selector seg-mask, and the relay segment list register seg-list-reg.
  • seg-reg represents the mapping between a segment of virtual memory and physical memory. When IPC is switched, the intersection of the memory intervals stored in seg-reg and seg-mask will be taken as the relay segment memory accessible to the callee.
  • the seg-reg contains four pieces of information: virtual memory base address VA base, physical memory base address PA base, length, and permission.
  • the memory of the relay segment corresponds to the memory whose length is length starting from the VA base, and the physical memory corresponding to this virtual memory is determined by the PA base and length. Permissions can include illegal, read, write, and execute permissions.
  • address translation seg-reg has a higher priority than the existing page table.
  • the seg-mask contains two pieces of information: offset (offset) and length (length).
  • offset offset
  • length length
  • the hardware will update the base address and length in the seg-reg according to the information in the seg-mask.
  • the application cannot directly change the mapping in the seg-reg, but it can use the seg-mask to narrow the range of the current relay segment memory, and then pass the reduced relay segment memory to the callee. This capability is useful when some data cannot be transferred, especially when multiple subjects form a call chain. For example, A calls B, and B calls C. Part of the data of A cannot be passed to B or C. At this time, part of the memory in the relay segment can be passed to B through the seg-mask.
  • this embodiment also provides a register seg-list-reg, which stores a physical address that points to a data structure in the memory, that is, the table relay in the figure segment list.
  • Each row of this table contains a piece of information in seg-reg.
  • the information contained in each line of seg-list-reg is the same as seg-reg, which also points to a piece of relay segment memory, so the address information of one or more pieces of relay segment memory can be stored in seg-list-reg.
  • the application can create multiple relay segment memories, and switch the relay segment memory when necessary, making the use of the relay segment memory more flexible.
  • this embodiment also provides a new instruction: swapseg.
  • the hardware layer can atomically switch the content in the seg-reg and a line in the relay segment list, thereby realizing the switching of the relay segment memory.
  • swapseg can also be used to atomically switch the contents of two relay segment registers, or to overwrite an address in the relay segment register, and so on.
  • the relay segment list can be stored in the private memory space of the process or thread that created it and managed by the kernel.
  • This embodiment also extends the memory management unit (MMU), as shown in FIG. 6.
  • the traditional translation also called mapping
  • mapping translation
  • TLB Translation Lookside Buffer
  • the extension of this embodiment lies in the flow shown in black in the figure.
  • VA virtual address
  • the access to the seg-reg of the MMU register can be realized through a hardware line, and the XPC engine can pass the value of the seg-reg register to the MMU through this line.
  • other methods may also be used, which are not limited in this application.
  • the kernel will ensure that each relay segment can only be used by one core at the same time, that is, it can only belong to one thread at the same time. This ownership will be transferred along with the call chain. For example, A calls B, and B calls C, then the relay segment memory will be transferred from A to B, and then to C, which can be transferred in whole or in part.
  • the XPC engine can also check whether the seg-reg median value is consistent with the intersection of the seg-reg and seg-mask stored in the link stack. If they are inconsistent, an exception or error will be triggered, and the kernel will handle the exception or error; if Consistent before continuing. This can prevent malicious callees from modifying the memory of the caller's relay segment.
  • the above mainly describes the hardware design of this embodiment.
  • the above design provides applications with XPC engine-based context switching capabilities without kernel interference, capability checking capabilities, and security based on relay segment memory. , Zero-copy data transmission capability.
  • the design of the hardware layer provides new hardware primitives for the software layer, including context switching primitives and relay segment memory primitives.
  • the context switch primitive includes two new instructions: xcall and xret; the relay segment memory primitive includes a new instruction swapseg.
  • the primitive in this embodiment refers to a process of completing a specific function, which is indivisible, and the hardware primitive is a primitive realized through the hardware layer.
  • the solution provided in this application may not be implemented through primitives, and a certain degree of functional division may be accepted.
  • FIG. 7 is a schematic diagram of the software modules included in the kernel part of the operating system of this embodiment.
  • the hardware management module 203, the handover management module 201, and the relay segment memory management module 202, these three modules are offline configuration modules, and the separated context management module 204 is a runtime module.
  • the hardware management module 203 directly operates the new hardware primitives provided in this embodiment.
  • the switching management module 201 and the relay segment memory management module 202 are respectively based on hardware primitives and provide configuration for context switching and data transmission in the kernel, including the configuration of security and policy.
  • the switching management module 201 and the relay segment memory management module 202 rely on the hardware management module 203 for hardware manipulation. These three modules all configure the hardware, so they are positioned as offline configuration modules.
  • the separation context management module 204 is responsible for providing thread or process runtime state maintenance and IPC information maintenance. It should be noted that the above module division is only an example, not indispensable. Those of ordinary skill in the art can also classify software modules through other classification methods, which is not limited in this application.
  • the separate context management module 204, the handover management module 201, and the relay segment memory management module 202 are described in detail below.
  • the hardware management module 203 is the management code in the kernel responsible for the aforementioned XPC engine, which can be understood as a driver. The implementation is similar to the existing hardware management, which will not be repeated in this application.
  • Thread (or process) context refers to various states of a thread, usually including general registers, page tables, thread private space, thread metadata, etc. used by the thread.
  • This threading model can work in traditional IPC communication centered on the core.
  • the traditional thread model may cause the kernel to fail to identify the current user mode thread.
  • this embodiment proposes a "separated context model", as shown in Figure 8(a), which separates the traditional thread context into two abstractions: runtime context and scheduling context.
  • the runtime context allows the user mode to be switched through the XPC engine, and the scheduling context is only maintained by the kernel.
  • the separated context model can extend the existing kernel thread model to support the exceptions and system calls of user-mode processes under XPC.
  • the kernel determines the runtime context of the current thread through additional registers (such as xcall-cap-reg), and determines the scheduling context through the state maintained by the kernel.
  • This separate management approach provides greater flexibility and allows user mode to reuse a scheduling context while supporting different runtime contexts.
  • Figure 8(b) shows the application process of the separated context model.
  • the user mode process triggers an exception (such as a page fault) or calls a system call, which sinks to the kernel (1).
  • the kernel first restores its own context, such as the kernel's stack (2).
  • the kernel obtains the thread scheduling context from the restored state (3).
  • the kernel obtains the runtime context of the user mode thread from the current hardware state (that is, xcall-cap-reg).
  • the kernel handles exceptions or system calls according to the runtime context, such as using page tables in the runtime context to handle page fault exceptions or handling system calls through the capability table in the runtime context (5).
  • the kernel performs scheduling according to the scheduling context (such as time slice information) (6).
  • the scheduling context such as time slice information
  • the scheduling strategy and scheduling process of the operating system can refer to the prior art, which is not limited in this application.
  • the separated context model extends the context management of the existing kernel.
  • xcall-cap-reg is unique for each thread, so it can serve as an index to locate the runtime context of a thread.
  • another memory page can be allocated near the memory of xcall-cap-reg to record the runtime context of the thread, such as the page table base address, etc.; then the kernel directly accesses that memory page according to xcall-cap-reg The recorded runtime context.
  • the kernel may obtain the runtime context through other registers or other methods.
  • the handover management module 201 needs to process hardware, and needs hardware primitive support provided by the XPC engine. As shown in Figure 9, the handover management module 201 is mainly used to implement three processes of service registration, call authorization, and exception handling. The black background step in the figure is the core related process of the solution proposed in this application.
  • An application as a server, registers its own service through the interface provided by the kernel before providing services: 1The kernel checks the registration request to determine whether it is legal; 2Then records the service information in the kernel; 3The service The information is converted into an x-entry, including the page table, entry address and other information of the server (refer to the introduction of x-entry table above), and the x-entry is added to the x-entry through the interface provided by the hardware management module 203 table. Finally, the kernel will return an id to the user, indicating the index position of the corresponding service in the x-entry table, and the id can be used by the caller as the identity of the service.
  • An application as a client, needs the kernel to authorize it before obtaining the service.
  • the realization of this authorization includes: 1The kernel first checks whether the client has obtained the calling authority of a certain service through various means is legal; 2Then updates the client’s IPC Call permission information; 3The kernel will set the corresponding bit in the xcall-cap bitmap corresponding to the client to 1, which means that the client is allowed to directly call the corresponding service (refer to the introduction of xcall-cap bitmap above).
  • the kernel part can set a variety of security policies, based on the security policy to determine whether or not to authorize, this application does not limit the security policy.
  • the kernel In the process of IPC calling, user mode programs may trigger exceptions or errors, and the kernel needs to deal with these exceptions or errors in the IPC process. 1Firstly, the kernel obtains the exception type to determine whether the exception is an IPC related exception; 2The kernel obtains the current IPC call chain information by reading the link stack information when the exception is triggered, and restores the status of the IPC call chain accordingly; 3 Terminate abnormal threads and recover related resources.
  • the relay segment memory management module 202 mainly implements two functions of application and release of the relay segment memory, and exposes interfaces for implementing these two functions to the application layer.
  • Relay segment memory application includes: 1The kernel checks whether the physical memory has been allocated/mapped to ensure that the newly allocated relay segment memory will not exist in other existing relay segment memory and user mode memory; 2The kernel checks whether it is currently in use To avoid memory leaks caused by overwriting; 3After the first two checks are passed, the kernel marks the physical memory segment as "allocated relay segment" status; 4The kernel allocates a virtual memory space, and combines this physical memory with the virtual The memory is written into the relay segment register seg-reg. Finally, the kernel returns the address of the allocated virtual memory, and returns an error value if there is an abnormal situation such as a failed check or insufficient memory during the application process.
  • the virtual memory allocated in step 4 will be allocated in a specific interval. This interval will only be used to map the relay segment memory, but not to map ordinary memory.
  • the ordinary memory here refers to the memory other than the relay segment memory provided in this application.
  • Relay segment memory release includes: 1The kernel first checks the legitimacy of the relay segment memory; 2If the check is legal, then release the corresponding physical memory and mark the physical memory as free; 3Clear the relay segment register seg-reg; 4Yes Released physical memory allocation capacity (or authority). Finally, the kernel returns the released physical memory and its capabilities.
  • the solution provided in this embodiment can realize the uniqueness of the relay segment memory by maintaining the ownership transfer of the relay segment memory.
  • this segment of relay segment memory can only be used by the corresponding thread, even other threads in the same process cannot access this memory, so the TOCTTOU attack can be effectively avoided.
  • the inter-process communication flow is shown in FIG. 11, which is mainly divided into three stages, the first is the service stage. 1
  • the server initializes its own operating environment to ensure that it is in a state that can accept requests.
  • 2 The server registers the IPC service, including the IPC service port configuration in the microkernel and the status of the microkernel setting hardware.
  • the specific realization of the registration process can refer to the realization of service registration in the aforementioned IPC management module.
  • 3 begins to enter the state of waiting to process the request.
  • the second stage is the client stage. 4
  • the client obtains the ability to call the service, and how to obtain it can refer to the implementation of the call authorization in the handover management module 201 described above.
  • the customer stores the data in the relay segment memory. Before applying for relay segment memory, please refer to Figure 10 for the application method.
  • 6 The client calls xcall to make IPC calls. The third stage is the service stage. 7After the xcall command is executed by the XPC engine, the switch from the client process to the service process is realized, and then the server obtains the client's data through the relay segment memory and starts to execute the service logic. 8 After the server has processed the request, it will return the service result to the client through the xret command. After the IPC is completed, the customer can release the relay segment memory, the release method can refer to Figure 10.
  • the XPC engine can check whether the customer has the authority to perform the call operation. If the check fails, an exception will be triggered. If the check succeeds, it will switch to the context of the service, and the relay segment memory will also be transferred to the service through registers. end.
  • the execution order of steps 1-8 can be adjusted according to requirements.
  • the order of the aforementioned steps 5 and other steps can be adjusted.
  • the customer's application for relay segment memory can be executed earlier, or for relay segment Both memory and storage data can be implemented earlier.
  • the software is responsible for ensuring the safety mechanism
  • the hardware is responsible for accelerating the switching during operation, so as to realize fast switching and safe zero-copy data transmission.
  • the software maintains the uniqueness of the relay segment memory and the security of the virtual address
  • the hardware provides run-time register transfer data transfer to achieve safe zero-copy data transmission.
  • Figure 12 shows the comparison between the process of this embodiment and the traditional IPC.
  • Traditional IPC relies on the kernel to complete inter-process communication (1-5), including operating mode switching, cache pollution, permission checking, context switching, address space switching, and core checking logic complexity.
  • Traditional IPC has at least two copy processes during data transmission and there is a risk of TOCTTOU attack.
  • the solution provided by this application implements permission checking and context switching by hardware by calling xcall, successfully bypassing the kernel (1-3) and avoiding It saves the overhead of the kernel, and the hardware provides a register transfer type data transmission mechanism, which avoids data copying and achieves better IPC communication performance.
  • Figure 13 shows the process of the Sqlite3 database application accessing data stored in the storage medium after applying the solution provided by this application.
  • the hardware layer expands the XPC engine and relay segment memory, and the kernel chooses to use the kernel Zircon of the Google Fuchsia system.
  • the application program selects Sqlite3, the file system is xv6fs, and the virtual memory disk ramdisk is used as the storage device.
  • the sequence number in the figure only lists the operations related to the Sqlite3 process.
  • File system process and block device driver process registration service Specifically, the file system process and the block device driver process first execute the initialization logic during the startup phase of the operating system, initialize their own programs, and register their own IPC services through the interfaces provided by the kernel respectively.
  • the file system process and the block device driver process establish a communication channel. Specifically, the file system process needs to access the real device through the block device driver process. Therefore, a communication channel between the file system process and the block device driver process is established during initialization, allowing the file system process to call the services of the block device driver process.
  • the Sqlite3 database process and the file system process establish a communication channel (number 12 34 in the figure). Specifically, when the Sqlite3 database process is started, the calling authority of the file system process is authorized to the Sqlite3 process during initialization, and a communication link between the two is established.
  • Sqlite3 prepares data to communicate with the file system process (numbered in the figure 5 6 7 8). Specifically, Sqlite3 prepares data through relay segment registers. Take the write operation as an example. Sqlite3 uses relay segment memory as its own data memory. In the write interface, the relay segment memory that can be transferred is limited to the data access requested by the write through the relay segment selection register seg-mask.
  • Sqlite3 calls the file system service (number 9 in the figure). Specifically, Sqlite3 is ready to access file system services and directly switch to the file system process context by calling the xcall command provided by the user mode library. Sqlite3's xcall will enter an entry point of the file system context. At this entry point, the file system service allocates resources and then performs write operations inside the file system. In the process of executing the write operation, there may be a process of calling the block device driver process, which is similar to the process of calling the file system process of Sqlite3, and will not be repeated.
  • the file system process returns the result to Sqlite3 through xret (number 10 in the figure). Specifically, the file system returns the result of the execution to the Sqlite3 database process through the register.
  • the YCSB (Yahoo! Cloud Serving Benchmark) test set (A-F) was used to test the progress of the Sqlite3 program. As shown in Figure 14, compared with the solution optimized by this application, the optimized version can achieve a performance improvement of 2.5 times or more in throughput.
  • FIG 15 is a schematic diagram of the dynamic expansion of the service thread.
  • the solution provided in this application allows the server to create a new work thread on demand.
  • the client makes an IPC call through the instruction xcall provided by the XPC engine, and the server determines whether it needs to allocate new thread resources through the dynamic allocation component.
  • the dynamic allocation component when only one client calls the service, the dynamic allocation component only needs to create a service running context resource required by a worker thread.
  • Figure (b) when multiple clients call the service at the same time, the dynamic allocation component will create the service running context resources required by multiple worker threads.
  • This embodiment does not need to statically allocate server-side processing thread resources, and can reuse the scheduling context resources of blocked client threads, thereby improving system resource utilization.
  • this application can run the server code in the client's scheduling context, so the cross-core interaction can be turned into a single-core interaction, avoiding cross-core cross-core interruption And other expenses.
  • IPC mechanism is not only an inter-process communication mechanism of the micro-kernel, but also IPC is used for inter-process communication in the macro-kernel.
  • the solution provided in this application is not only applicable to the micro-kernel but also to the macro-kernel.
  • the solution provided by this application is integrated into the RocketChip RISC-V core to support micro-kernel, macro-kernel and user-level data transfer (handover) mechanisms.
  • the XPC engine is implemented as a unit of the RocketChip core.
  • Table 1 shows the details of the new registers and new instructions. These new registers are implemented by control and status register (CSR), which can be accessed by csrr (CSR read) instructions and csrw (CSR write) instructions.
  • CSR control and status register
  • Three new instructions xcall, xret and swapseg are sent to the XPC engine during the execution phase.
  • the XPC engine checks the validity of the IPC and returns the callee's information to the pipeline. In addition, 5 new exceptions have been added, including invalid x-entry, invalid xcall-cap, invalid link (linkage), invalid seg-mask and swap-seg errors.
  • the kernel manages four XPC objects: 1) global x-entry table; 2) link stack (per_thread link stack) corresponding to each thread; 3) xcall capability bitmap (per_thread xcall capability bitmap) corresponding to each thread; and 4 ) The relay segment list corresponding to each address space (per_address_space relay segment list).
  • the kernel allocates memory for the x-entry table and sets the table size.
  • the kernel allocates 8KB of memory for the link stack of this thread, 128B of memory for the xcall capability bitmap, and a 4KB page for the relay segment list.
  • the kernel is responsible for saving and restoring the aforementioned objects 2) and 3).
  • the support for the microkernel is introduced from the following four aspects. The following introduction and the previous part of this application can be cross-referenced.
  • Capability Capabilities are widely used in the microkernel IPC mechanism.
  • the solution provided in this application introduces the grant-cap interface, which allows one thread to grant capabilities to another thread.
  • the kernel maintains a list of capabilities for each thread. When a thread creates an x-entry, the thread will authorize the corresponding xcall-cap to other threads through grant-cap.
  • the thread state maintained by the kernel is divided into two parts: scheduling state and runtime state.
  • the scheduling status includes information related to scheduling, specifically including kernel stack, priority, time slice, and so on.
  • the runtime state includes the current address space and capabilities.
  • Each thread can be associated with a scheduling state and one or more runtime states. Since xcall-cap-reg corresponds to each thread and may be updated during xcall, the kernel can use xcall-cap-reg to determine the runtime state. When a thread is trapped in the kernel, the kernel can determine the current runtime state of the thread according to the value in xcall-cap-reg to avoid the errors in the previous example.
  • each x-entry corresponds to multiple XPC contexts, and the XPC context includes an execution stack and local data.
  • the server sets the maximum number of XPC contexts. These XPC contexts can be created in advance. Before the x-entry is called, an idle XPC context will be selected, then switch to the corresponding execution stack and restore the local data, and release the resources before returning. If there is no free XPC context, return an error or continue to wait for a free XPC context. Further, in order to prevent DoS attacks, the server can use specific strategies to restrict calls from customers.
  • the application terminates.
  • the abnormal termination of a certain procedure in a call chain may affect the entire call chain. For example, A calls B, and B calls C, but B is killed by the kernel because of an exception, so that when C calls xret, it will return to an error process. This situation requires a way to trigger an exception so that the kernel can handle it.
  • the kernel when a process terminates, the kernel will scan all link stacks, find all the linkage records of the process through the page table pointer, and set all the linkage records as invalid. In this way, as in the previous example, when C returns, it will trigger an invalid linkage exception, so that the kernel can handle the exception.
  • this embodiment can also reduce the scanning frequency of link stack: when B is killed, the kernel does not need to perform scanning, but clears the page table of B, so that when C returns, a page will be triggered Error (page fault), so that the kernel has the opportunity to deal with the error. In addition, the kernel will revoke B's resources.
  • the solution provided by this application also supports macro kernels. Specifically, the following describes the integration scheme of this application and the Android Binder mechanism.
  • Binder is an important feature introduced by Android in the Linux kernel, which is mainly responsible for inter-process communication of applications on Android. Binder is widely used in existing Android services, such as window manager. Binder's architecture includes the basic layer, Linux Binder driver, Android Binder framework, and API layer. The solution provided in this application only modifies the driver and framework for Binder support, and ensures that the API does not change as much as possible. In Binder, "binder transaction" is used to indicate a cross-process method call, which uses two copies of the kernel to implement data transmission. Android introduced another feature, ashmem (anonymous shared memory) to accelerate the transmission of big data in the Binder communication process.
  • ashmem anonymous shared memory
  • Binder transaction includes the following steps. 1. The client prepares the method identification and puts the passed parameter data into the Parcel structure in Android. 2. The client calls the API function transact() of the Binder framework. This function will eventually fall into the binder driver of the kernel and copy the data to the server through two copies. The whole process involves two data copies and two rights switching. 3. The binder framework of the server receives the request and calls the onTransact() callback function to call the corresponding method. 4. The server returns the results of the execution to the customer through the binder driver.
  • the API interface does not need to be changed, such as transact() (see Figure 1) and onTrasact()(4), which enables the XPC-optimized binder to still be compatible with existing applications.
  • the binder driver is extended to manage xcall cap bitmap and x-entry table.
  • a process registers for a service, it needs to add x-entry to the driver configuration x-entry table through the framework sink, and delete x-entry is similar.
  • the client obtains the permission to call the service, it also needs to sink into the driver to set its own xcall-cap bitmap, and the clear operation is similar.
  • the client and the service communicate at runtime, unlike the traditional binder method (via ioctl sinking to the kernel), the client can directly call the xcall instruction to the server to complete the call (3), and the server processes the request You can also return to the client directly via the xret command (5).
  • the transmission of data has also changed from Parcel transmission to relay segment memory transfer (2).
  • Linux also needs to maintain relevant registers in the context of each thread.
  • the XPC-based optimization can avoid two permission level switching and two data copies.
  • Anonymous shared memory is available to users through file-based shared memory interface. Specifically, the user process can allocate a fd, and get a piece of memory by mapping (map) the fd, and this fd can be shared among different processes in the binder to realize data transmission. Ashmem, like traditional shared memory, there are also security issues, and an additional copy is required to ensure data security.
  • Ashmem allocation The binder framework implements ashmem through relay segment memory, and allocates the corresponding relay segment memory to the user during allocation.
  • Ashmem mapping When mapping, the corresponding relay segment register will be set to the mapped ashmem interval.
  • ashmem transmission directly transfer the relay segment memory to the server through xcall.
  • the scheduling process can be performed by triggering a page fault (page fault) and then dynamically mapping.
  • the solution provided by this application also supports data transfer across call chains. In actual scenarios, it often involves a nested call chain of multiple subjects, such as A calling B, and B calling C. Here, the data passed from A to B may be passed directly to C.
  • XPC's relay segment mechanism can realize handover across function call chains, that is, data is transferred between A, B, and C with zero copy, and there is no security problem.
  • the first case is that when B transmits data to C, some data needs to be added to the data of A; the second is that B only transmits part of the data to C; the third is The situation is that when C is executing, B may exit due to an exception and need to deal with resource recovery.
  • Data size negotiation (message size negotiation): For the first case, we use data size negotiation. That is, even if A transmits a smaller data block of B, if B wants to transmit a larger data block to C, then A can reserve this part of the data interval, so that B can directly add to the reserved interval ( append) data without the need to redistribute and move data.
  • the negotiation here depends on the call chain. If B can call C or D later, then the space that A needs to apply for should be the size of the data sent by A to B, the size of data sent by B to C, and the size of data sent by B to D.
  • the data size the largest of the three.
  • Data shrink (message shrink): For the second case, we need to reduce the interval of relay segment memory. This can be achieved by register seg-mask. Select the interval to be transmitted through the seg-mask, and the more part will not be passed to the server.
  • Relay segment revocation For the third case, when a process terminates, the kernel will traverse the relay segment list of the process, returning the caller’s relay segment memory to the caller, and the rest of the relay segment memory will be recycled .
  • This embodiment considers two binder mechanisms: a mechanism for transferring data through a buffer and a mechanism for transferring data through ashmem.
  • the two binder mechanisms are optimized based on XPC, and the communication time is compared, as shown in FIG. 17.
  • the communication time here includes data preparation (client), remote method call and data transfer (frame), surface content processing (server), and reply (frame). It can be seen from the diagram that XPC can effectively optimize the performance of binder and ashmem.
  • the macro kernel can only integrate the relay segment memory mechanism provided by XPC, while the context switch uses the existing mechanism or other mechanisms, which can also improve the efficiency and security of data transmission.
  • the hardware-supported cross-process call context switching primitive design allows the user mode to execute the context switching function through two new instructions, xcall and xret.
  • xcall and xret are parts of the IPC process that can be directly accelerated by the hardware, mainly the context switching between the client and the server in the IPC, and the hardware support accelerates the core process of the IPC.
  • Cross-core interaction optimization mechanism In the multi-core scenario, the original notification method of inter-processor interrupt is replaced with a mechanism that pulls the service process to the current core for operation. This approach can provide a better cache hit rate for the access of the service process to the data of the client process.
  • the present invention adopts a hardware cache for IPC information to store the data that the xcall/xret instruction needs to read.
  • Asynchronous state push stack During the xcall process, the hardware needs to push the context information of the current client into a stack (link stack). This process can be completed asynchronously, avoiding the hardware waiting for the stack operation to complete synchronously.
  • Use tagged TLB to avoid page table switching overhead using xcall and xret to perform context switching in hardware still needs to switch page tables. Using the tagged TLB method can avoid the refresh operation of the TLB during page table switching, and improve the performance of the xcall and xret instructions.
  • the hardware and kernel jointly maintain the call stack mechanism: the hardware primitives will record the information of the call chain into the call stack (link stack).
  • the kernel can handle the IPC exception mechanism through the call stack backtracking;
  • the client can choose the same way as the kernel maintenance and save all the state
  • Server dynamic extension mechanism hardware primitives allow multiple clients to call one client at the same time. By supporting the re-entrant work thread allocation method at the software layer, the function of dynamic expansion of server threads can be realized, and the purpose of reusing the scheduling context of the client can be achieved.
  • Relay segment memory realizes cross-chain zero-copy data transmission: through multi-entity coordination, the largest relay segment memory transmission interval is determined, and combined with the mask mechanism of the relay segment memory, secure zero-copy data across multiple entities is realized transmission;
  • Ownership transfer feature support The kernel maintains the uniqueness of the virtual address range of the relay segment memory and the physical interval of the relay segment memory to realize the permission transfer feature during the relay segment memory transfer process.
  • FIG. 18 is a schematic structural diagram of a computer system provided by this embodiment.
  • the computer system can be a smart phone, an automatic driving device applied to an unmanned car, etc.
  • the computer system includes a communication module 510, a sensor 520, a user input module 530, an output module 540, a processor 550, an audio and video input module 560, a memory 570, and a power supply 580.
  • the communication module 510 may include at least one module that enables communication between the computer system and a communication system or other computer systems.
  • the communication module 510 may include one or more of a wired network interface, a broadcast receiving module, a mobile communication module, a wireless Internet module, a local area communication module, and a location (or positioning) information module.
  • the sensor 520 may sense the current state of the system, such as open/closed state, position, contact with the user, direction, and acceleration/deceleration, and the sensor 520 may generate a sensing signal for controlling the operation of the system.
  • the user input module 530 is used to receive inputted digital information, character information, or contact touch operation/non-contact gestures, and receive signal input related to user settings and function control of the system.
  • the user input module 530 includes a touch panel and/or other input devices.
  • the output module 540 includes a display panel for displaying information input by the user, information provided to the user, or various menu interfaces of the system.
  • the display panel may be configured in the form of a liquid crystal display (LCD) or an organic light-emitting diode (OLED).
  • the touch panel can cover the display panel to form a touch display screen.
  • the output module 540 may also include an audio output module, an alarm, a haptic module, and so on.
  • the audio and video input module 560 is used to input audio signals or video signals.
  • the audio and video input module 560 may include a camera and a microphone.
  • the power supply 580 may receive external power and internal power under the control of the processor 550, and provide power required for the operation of various components of the system.
  • the processor 550 may indicate one or more processors.
  • the processor 550 may include one or more central processing units, or include a central processing unit and a graphics processor, or include an application processor and a coprocessor. (For example, micro control unit or neural network processor).
  • the processor 550 includes multiple processors, the multiple processors may be integrated on the same chip, or each may be an independent chip.
  • a processor may include one or more physical cores, where the physical core is the smallest processing unit.
  • the XPC engine 551 (also called an inter-process communication engine, or communication engine for short) provided in this embodiment is provided on the processor 550.
  • the XPC engine 551 and the processor 550 may be integrated on a chip, or may be arranged on a single board with the processor.
  • the XPC engine 551 may also be connected to the processor 550 in other non-illustrated ways.
  • the specific implementation of the XPC engine reference may be made to the foregoing embodiment, which will not be repeated here.
  • the memory 570 stores computer programs, and the computer programs include an operating system program 572, an application program 571, and the like.
  • Typical operating systems such as seL4, L4, or microkernel operating systems such as Fuchsia provided by Google; also such as Microsoft’s Windows, Apple’s MacOS and other systems used in desktops or notebooks; and another example based on Google’s Android Systems, etc., systems for mobile terminals, etc.
  • the memory 570 may be one or more of the following types: flash memory, hard disk type memory, micro multimedia card type memory, card type memory (such as SD or XD memory), random access memory (random access memory) , RAM), static random access memory (static RAM, SRAM), read-only memory (read only memory, ROM), electrically erasable programmable read-only memory (electrically erasable programmable read-only memory, EEPROM), programmable Read-only memory (programmable ROM, PROM), magnetic memory, magnetic disk or optical disk.
  • the memory 570 may also be a network storage device on the Internet, and the system may perform operations such as updating or reading the memory 570 on the Internet.
  • the processor 550 is used to read the computer program in the memory 570, and then execute the method defined by the computer program. For example, the processor 550 reads the operating system program 572 to run the operating system on the system and implement various functions of the operating system, or read One or more application programs 571 are taken to run applications on the system. If the XPC solution provided in this application is implemented in the form of software, it can be stored in the memory 570 in the form of a computer program, and read and executed by the processor 550.
  • the memory 570 also stores other data 573 besides computer programs, such as x-entrytable, link stack, relay segment list, etc. involved in this application.
  • connection relationship of each module in FIG. 18 is only an example, and the method provided in any embodiment of the present application can also be applied to terminal devices of other connection modes, for example, all modules are connected through a bus.
  • the division of each module in Figure 18 is only a logical division, and does not mean that the hardware must be separated.
  • the modules in FIG. 18 are not necessarily necessary in other embodiments of the present application.
  • this application also provides storage media, computer program products, computer programs, etc. related to the solutions provided in this application.
  • storage media for specific implementation, refer to the foregoing embodiment.
  • this application divides the implementation into multiple parts and introduces it. In order to better let readers understand the solution of this application, this application also provides different cases to illustrate the whole solution. It should be understood that there are some associations between the various parts, and the realization of the mutual associations may refer to each other. There is some duplication between the case and the realization of each part, and mutual reference can also be made, but this does not mean that a certain case must be realized in a certain process.
  • the solution provided in this embodiment can be applied to terminal devices or servers.
  • the terminal equipment here includes, but is not limited to, smart phones, vehicle-mounted devices (such as autonomous driving equipment), personal computers, artificial intelligence equipment, tablets, personal digital assistants, smart wearable devices (such as smart watches or bracelets, smart glasses), Intelligent voice devices (such as smart speakers, etc.), virtual reality/mixed reality/enhanced display devices, or network access devices (such as gateways, etc.).
  • the server may include a storage server or a computing server.
  • first object and the second object may be combined or refer to the same object in some cases ; Furthermore, since there is no limit to the order, there is no first, there can be a second or third.
  • the device embodiments described above are merely illustrative.
  • the modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in One place, or it can be distributed to multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.
  • the connection relationship between the modules indicates that they have a communication connection between them, which can be specifically implemented as one or more communication buses or signal lines. Those of ordinary skill in the art can understand and implement it without creative work.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Storage Device Security (AREA)

Abstract

一种进程间通信的方法、实现该方法相关的装置、计算机设备等。该方法可以应用于智能终端、自动驾驶等设备。该方法主要包括：运行在硬件层或高级别软件层的通信引擎提供上下文切换指令，当运行在用户态的调用者调用被调用者时，通过调用所述上下文切换指令直接实现上下文切换，不需要陷入内核，从而一定程度上避免了内核对上下文切换的干预，缩短了进程间通信IPC的执行时间。

Description

进程间通信的方法、装置以及计算机设备 技术领域
本申请涉及计算机技术，尤其涉及一种进程间通信的方法、装置以及计算机设备等。
背景技术
基于微内核的操作系统架构(简称微内核架构)被广泛使用在云平台、嵌入式设备、移动设备、无人驾驶等场景中。微内核架构将自己真正的核心功能减少到非常少，将传统的操作系统内核(例如宏内核架构Linux)中的众多的组件，比如文件系统和网络协议栈等都放在用户态的进程中运行。
相比传统的操作系统内核，微内核架构能够保证任何承担复杂功能的模块都可以被放在用户态的进程中，并能够使不同的进程隔离运行。这种方式能够极大增强操作系统的隔离性和可靠性。比如，文件系统在微内核架构中仅仅是一个应用程序，当一个恶意的应用程序攻击了一个文件系统后，只有这个文件系统能够访问的文件可能被恶意应用程序访问到，而其它的文件系统以及其它的系统组件(比如内存管理组件)仍然是处于被保护的状态。此外，如果是某个文件系统触发了内部的漏洞导致文件系统崩溃，也只会影响到这个文件系统本身，而不会影响到整个操作系统的正确性。并且管理员可以很容易地重新启动一个文件系统来继续提供服务。这也提供了相比传统的操作系统内核更加好的可靠性。
然而，微内核架构也带来了巨大的性能损失。微内核架构下，一个应用程序获取系统服务的时候，需要通过进程间通信(Inter-Process Communication,IPC)的方式。例如：如图1所示，在宏内核架构中，作为被调用者(callee)的文件系统部署在内核态，当一个调用者(caller)即数据库应用程序需要与文件系统进行通信时，仅需要一次系统调用即可；而在微内核架构下，由于数据库应用和文件系统均部署在用户态，所以数据库应用需要通过IPC和文件系统进行通信。
IPC的性能开销来源于多个方面，其中比较关键的是上下文切换(本申请有时简称为“切换”)开销。宏内核架构下，应用程序和系统服务(比如文件系统)之间的交互通过系统调用实现，而系统调用是硬件直接支持的操作，这使得单个的系统调用非常高效。而微内核架构下，上下文切换的特权指令，如切换页表等只能由内核态完成，而调用者和被调用者都在用户态运行，所以它们必须陷入(trap)到内核态去执行切换，内核的介入导致通信开销相对于宏内核大大提高。
针对微内核架构中IPC通信开销大的问题，现有技术提出一种方案：进程直接切换(Direct Process Switch)。这种方案仍然需要内核进行IPC处理，只是将IPC的处理逻辑进行最简化，只包含必要的阶段。在这种方案的应用下，在执行IPC调用时，内核跳过其它阶段直接切换到对应的上下文中，因此使得IPC通信得到一定程度的加速。但是该方案仍然需要内核干预来完成上下文切换，上下文切换的开销依然较大，导致IPC的通信的时长仍然较长。
发明内容
本申请提供一种进程间通信的方法，并提供实现该方法的装置、计算机程序产品(例如操作系统)、存储介质以及计算机设备等，用以缩短IPC的通信时长。下面将从多个方面介绍本申请，容易理解的是，该以下多个方面可以单独实施，也可以选择其中任意两个或更多联合实施。该以下多个方面的具体实现方式和有益效果可互相参考。
第一方面，本申请提供一种进程间通信的方法，该方法应用于计算机设备，该计算机设备包括硬件层以及运行在所述硬件层上的操作系统。该操作系统可以是基于微内核架构的系统，也可以是基于宏内核架构的系统。所述操作系统上运行有待通信的调用者和被调用者。所述计算机设备还包括通信引擎，该通信引擎在实施例中被称为XPC引擎，用于实现进程间的通信。该通信引擎可以设置在硬件层的处理器上，也可以作为独立的硬件装置。该通信引擎还可以用软件模拟实现。该方法包括：所述调用者调用第一指令(例如xcall)，所述第一指令由所述通信引擎执行以实现从所述调用者的上下文直接切换到所述被调用者的上下文。进一步的，所述被调用者调用第二指令(例如xret)，所述第二指令由所述通信引擎执行以实现从所述被调用者的上下文直接切换到所述调用者的上下文。第一指令和第二指令可以不同时实现。
调用者和被调用者可以是线程(或进程)，线程(或进程)的上下文是操作系统中维护的该线程的各种状态，通常包括线程使用的通用寄存器、页表、线程私有空间、线程元数据等部分。由于上下文的定义和使用在不同的计算机系统中可能有所不同，所以以上举例的上下文内容不应该作为限制本申请方案的基础。另外，本申请中提到的上下文可以指全部的上下文，也可以指部分上下文。调用者和被调用者在其他一些实施例中也可以理解为应用。
当所述操作系统是微内核架构的时候，所述调用者和所述被调用者通常运行在用户态。在传统IPC通信中，所述调用者和所述被调用者需要内核的参与才能完成上下文的切换，这就带来了用户态和内核态的切换等开销，从而导致通信时长较长。通过引入以上通信引擎，所述调用者和所述被调用者通过调用第一指令和第二指令就可以实现直接的上下文的切换，一定程度上避免了内核的干预，从而缩短了IPC的通信时长。类似的，该方法运行在宏内核架构下也能带来通信速度的提升。
在一些实现方式中，所述通信引擎在执行所述第一指令时还包括：获取所述调用者的能力信息，所述能力信息用于指示所述调用者是否有权限调用所述被调用者；当根据所述能力信息确定所述调用者有权限调用所述被调用者时，根据所述第一指令中的被调用者标识确定所述被调用者的上下文；保存所述调用者的上下文；切换到所述被调用者的上下文。传统的IPC中，能力检查是内核来执行的，本申请将能力检查也放到通信引擎中来做，进一步减少了内核的干预，从而进一步缩短了IPC的通信时长。
在一些实现方式中，所述通信引擎在执行所述第一指令时还包括以下检测中的一项或多项：检测所述被调用者标识是否合法、检测所述被调用者是否合法、或检测所述保存所述调用者的上下文的保存空间是否足够。当以上任意一个检测出现不合法或空间不足够时，触发异常，该异常提交给内核，由内核进行处理。合法性等检测的加入，以及内核处理异常的使能，使得本申请提供的通信引擎更加安全和可靠。
在一些实现方式中，所述方法还包括：保存所述调用者的上下文，所述上下文为所述调用者的部分上下文。需要说明的是，本申请中提到的保存上下文可以指保存全部上下文，也可以指保存部分上下文，根据系统需求确定。部分上下文即系统需要的关键的、核心的上下文信息，这样保存可减少保存量，从而减小存储空间占用，同时进一步缩短IPC的通信时长。
在一些实现方式中，当所述通信引擎用硬件实现的时候，访问能力信息、保存上下文信息等操作可以通过访问寄存器实现，寄存器中存储有对应的信息的存储地址，用于指示这些信息的位置。
在一些实现方式中，所述方法还包括：所述调用者申请内存区域，并将所述内存区域的地址设置在所述通信引擎包含的寄存器中；所述调用者将待传输给所述被调用者的数据存储在所述内存区域中，所述被调用者用于通过所述寄存器中存储的地址来访问所述内存区域以获得所述数据。调用者申请一段内存区域，并将该内存区域的地址信息记载在寄存器(seg-reg)中，然后被调用者就可以通过访问该寄存器来获得数据。这种内存区域在本申请具体实施例中被称为接力段(relay segment)或接力段内存。通过这种方式，被调用者可以直接从该寄存器指向的内存区域中读取调用者需要传递过来的数据，避免了数据在调用者和被调用者之间的拷贝，进一步缩短了IPC的通信时长。
本申请以内存为例来，但在其他一些实现方式中，该区域也可以不是内存，而是其他类型的存储区域。
在一些实现方式中，所述方法还包括：所述调用者调用第三指令(例如swapseg)，所述第三指令由所述通信引擎执行以实现将第一寄存器(例如seg-reg)中的地址更新为第二寄存器(例如seg-list-reg)中的地址。通过这种方式，可以让用户方便、快捷地修改接力段内存，提高了接力段内存使用的灵活性。
第二方面，本申请提供一种实现进程间通信的方法。该方法可应用在前述第一方面的通信引擎(例如XPC引擎)中。该通信引擎可以作为当前处理器的扩展单元，也可以作为独立的处理单元，也可以用程序模拟实现。该方法包括：接收调用者发送的第一指令(例如xcall#register)，所述第一指令中包含被调用者的标识(#register)；根据所述被调用者标识在第一寄存器(例如x-entry-table-reg)指示的服务集合(例如x-entry table)中确定所述被调用者的上下文，所述第一寄存器用于存储所述服务集合的内存地址，所述服务集合包括一个或多个被调用者的上下文信息；将所述调用者的上下文保存在第二寄存器(例如link-reg)指示的返回信息集合(例如link stack)中，所述第二寄存器用于存储所述返回信息集合的内存地址，所述返回信息集合包括一个或多个调用者的上下文信息；切换到所述被调用者的上下文。通过以上硬件或软件模拟扩展的方式实现调用者和被调用者的上下文的切换，一定程度上避免了内核的干预，缩短了IPC的通信时长。
在一些实现方式下，所述第一寄存器和所述第二寄存器都是内核可以读写的，因此这种扩展仍然可以向内核提供安全配置接口，比如服务注册、权限授权、或异常处理等，允许内核对切换行为进行限制，实现在用户态直接切换的情况下安全和性能的保证。
在一些实现方式中，在所述根据所述被调用者标识在第一寄存器指示的服务集合中确定所述被调用者的上下文之前，所述方法还包括：根据第三寄存器(例如xcall-cap-reg)指示的能 力信息(例如xcall cap bitmap)确定所述调用者有权限调用所述被调用者，所述第三寄存器用于存储所述能力信息的地址，所述能力信息用于指示所述调用者是否有权限调用所述被调用者。将能力检查也放在扩展的通信引擎中实现，进一步减少了内核的干预，缩短通信时长的同时也保证了调用的安全性。
在一些实现方式中，所述方法还包括：将以下信息中的任意一项或两项预取到缓存中：所述服务集合中包括的一个或多个被调用者的上下文信息、或所述能力信息。该缓存属于通信引擎可以更加快速读写的存储介质。由于服务集合、返回信息集合、能力信息集合等存储在内存中，读写这些信息的时候需要通过内存访问的机制，而缓存的访问速度相对内存更快，所以通过设置缓存以及以上预取过程，可以进一步提高数据访问的效率，从而进一步缩短了IPC的通信时长。
在一些实现方式中，采用异步的方式执行以下步骤：将所述调用者的上下文保存在第二寄存器指示的返回信息集合中。这里所谓异步方式指的是该步骤的后续的操作不需要等待该步骤的完成。这样可以进一步提高该方法的运行效率，从而进一步缩短了IPC的通信时长。
在一些实现方式中，所述被调用者的上下文的确定步骤或所述调用者的上下文的保存步骤采用被标记(tagged)的转换检测缓冲区TLB实现。以上步骤都可能涉及到内存访问中的页表切换，采用tagged TLB机制能够避免页表切换中对于TLB的刷新操作，提高了该方法的运行效率。
在一些实现方式中，所述方法还包括：将第四寄存器(例如seg-reg)指示的内存区域的访问权限赋予所述被调用者，其中，所述第四寄存器用于存储所述内存区域的地址信息，所述内存区域(实施例中被称为接力段内存)是所述调用者申请的，所述内存区域用于存储所述调用者待传输给所述被调用者的数据。通过访问该寄存器，被调用者就可以访问调用者的数据，避免了数据在调用者和被调用者之间的拷贝，进一步缩短了IPC的通信时长。这种方式也可以称为“寄存器交接”。
在一些实现方式中，所述方法还包括：将第四寄存器(例如seg-reg)和第五寄存器(例如seg-mask)指示的第二内存区域的访问权限赋予所述被调用者，其中所述第四寄存器用于存储第一内存区域的地址信息，所述第五寄存器则存储有用于缩小所述第一内存区域的信息，所述第二内存区域为缩小后的第一内存区域。通过这种方式对被调用者可访问的内存区域进行限制，提高了数据传输的灵活性和安全性。
需要说明的是，寄存器的访问权限可以是预配置的，访问权限可以包括用户态读/写，或内核读/写等。第四寄存器和第五寄存器可以被配置为用户态读/写，这样运行在用户态的调用者和被调用者就可以访问这两个寄存器。操作系统向用户态应用开放访问接口，类似于共享内存，用户通过接口访问寄存器。
在一些实现方式中，所述方法还包括：接收所述被调用者发送的第二指令(例如xret)，所述第二指令用于指示返回所述调用者的上下文；从所述第二寄存器(例如link-reg)指示的所述返回信息集合(例如link stack)中获取所述调用者的上下文；切换到所述调用者的上下文。
在一些实现方式中，保存的所述调用者的上下文为选择的所述调用者的部分上下文。调用者和被调用者可以是线程(或进程)，线程(或进程)的上下文是操作系统中维护的该线程 的各种状态，通常包括线程使用的通用寄存器、页表、线程私有空间、线程元数据等部分，在保存该上下文的时候可以全部保存，也可以像本实现方式一样部分保存，节省保存空间，提高保存速度，从而进一步缩短了IPC的通信时长。
以上关于上下文切换和接力段内存的实现为IPC的快速通信提供了基础的机制。同时，操作系统，尤其是内核，也可以对以上机制进行配置和管理等，下面将介绍这些配置和管理等。
第三方面，本申请还提供一种进程间通信的管理方法，该方法可以由操作系统执行，具体的，可以由操作系统内核层或用户态库层执行。该方法包括：接收服务端的服务注册请求，所述服务注册请求用于请求注册服务；根据第一寄存器(例如x-entry-table-reg)中的地址信息将所述服务的上下文信息保存在第一存储区域，所述地址信息指示所述第一存储区域。该方法实现了对服务信息的注册过程，为客户的调用提供了基础。
在一些实现方式中，所述方法还包括：接收对客户的授权请求，该授权请求用于请求将服务的调用权限授权给所述客户；当确定所述客户有权限调用所述服务时，将所述客户的能力信息设置为指示所述客户有权限调用所述服务，所述能力信息存储在第三存储区域，所述第三存储区域的地址信息存储在第三寄存器(例如xcall-cap-reg)中。换句话说，内核根据该第三寄存器中存储的地址信息，设置该地址信息指向的能力信息。该方法实现了对客户的授权过程，保证了客户调用服务的安全性。
在一些实现方式中，所述方法还包括：接收异常；当确定所述异常为客户与服务端进行通信的通信异常时，从返回信息集合中读取客户的上下文信息，所述返回信息集合包括一个或多个调用者(也可以称为客户)的上下文信息，所述返回信息集合存储在第二存储区域，所述第二存储区域的地址信息存储在第二寄存器(例如link-reg)中；根据所述客户的上下文信息执行恢复操作。换句话说，内核根据该第二寄存器中存储的地址信息找到并读取所述返回信息集合中与所述客户对应的上下文信息。通过该方法，内核可以正确处理IPC通信过程中的异常。
第四方面，本申请还提供一种内存分配方法，该方法用于分配接力段内存，该方法可以由内核执行。该方法包括：响应于内存申请请求，确定待分配的物理内存区域是否和已分配的物理内存区域存在交集；当确定所述待分配的物理内存区域和所述已分配的物理内存区域不存在交集时，将所述待分配的物理内存区域标记为已分配；分配虚拟内存区域，将所述待分配的物理内存区域和所述虚拟内存区域的映射关系保存在第四寄存器(例如seg-reg)中；返回所述虚拟内存区域的地址。这个“已分配的物理内存区域”包括已分配的接力段内存和普通内存。通过这种方法，实现了内核对接力段内存的分配，保证了接力段内存的唯一性。
在一些实现方式中，当确定所述待分配的物理内存区域和所述已分配的物理内存区域不存在交集时，将所述待分配的物理内存区域标记为已分配包括：当确定所述待分配的物理内存区域和所述已分配的物理内存区域不存在交集，且确定当前正在使用的物理内存区域与所述分配的物理内存区域不存在交集时，将所述待分配的物理内存区域标记为已分配。确定与当前正在使用的接力段内存不重复，可有效避免内存泄露问题。
在一些实现方式中，所述还包括：响应于内存释放请求，清空所述第四寄存器。及时的内存释放能够提高内存利用率。
第五方面，本申请还提供一种内存管理方法，作为内存管理单元(memory management unit,MMU的扩展。该方法包括：接收虚拟地址，该虚拟地址可能来源于内存访问请求；确定所述虚拟地址是否在接力段内存的虚拟地址区间内，所述接力段内存的虚拟地址区间以及对应的物理地址区间的映射关系存储在接力段寄存器(例如seg-reg)中；当确定所述虚拟地址在所述虚拟地址区间内时，根据所述接力段寄存器中存储的所述映射关系确定所述虚拟地址对应的物理地址。该方法通过对MMU的简单扩展实现了通过寄存器来翻译接力段内存的虚拟地址，提高了接力段内存的访问速度。
第六方面，本申请还提供一种方法，该方法包括：内核接收到异常或系统调用；内核从通信引擎维护的状态中获取所述线程的运行时上下文，根据所述运行时上下文处理所述异常或系统调用。本申请提出分离上下文模型：运行时上下文和调度上下文。调度上下文由内核维护，而运行时上下文由本申请提供的通信引擎维护，例如寄存器xcall-cap-reg。分离上下文模型扩展了现有内核的上下文管理。
第七方面，本申请还提供一种服务线程动态扩展的方法，该方法包括：当确定同一个服务接收到多个客户的请求时，创建与所述多个客户一一对应的多个工作线程以及创建所述多个工作线程的多个运行上下文，一个所述工作线程的上下文包括对应的客户的调度上下文和创建的所述运行上下文。该方法基于分离上下文模型，实现了服务端线程的动态扩展，并且可以复用被阻塞的客户的调度上下文。另外，通过将服务端的代码放在客户的调度上下文中运行的，因此可以将跨核的交互变成单核的交互，避免了跨核的跨核中断等开销。
除了方法之外，本申请还实现方法的装置、计算机存储介质和计算机程序产品等。
第八方面，本申请提供一种计算机设备，所述计算机设备包括硬件层以及运行在所述硬件层上的操作系统，所述操作系统上运行有待通信的调用者和被调用者，所述计算机设备还包括通信引擎，所述通信引擎用于执行如前述第二方面任意一项所述的方法。当所述通信引擎集成在计算机设备已有的处理器上时，可作为处理器核的扩展，这时通信引擎指的是“处理器”。当通信引擎独立于已有处理器时，所述通信引擎指的是另外的处理单元，具有独立的处理能力，可作为对已有处理器的加速器使用。
第九方面，本申请提供一种进程间通信的装置，所述装置包括一个或多个模块，用于实现前述第一方面至第七方面任意一项提供的方法。在一些实现方式中，该装置可以为通信引擎，用于实现前述第二方面或其任意一种实现方式所述的方法。
第十方面，本申请提供一种进程间通信的装置，该装置可以是芯片。该装置包括处理器核和多个寄存器，其中所述处理器核用于执行第二方面任意一项所述的方法。
第十一方面，本申请提供一种内存管理单元MMU，所述内存管理单元包括一个或多个模块，用于实现前述第五方面任意一项提供的方法。
第十二方面，本申请提供一种计算机存储介质，所述计算机存储介质用于存储计算机程序，当所述计算机程序被一个或多个处理器执行时实现第一方面至第七方面任意一项提供的方法。
第十三方面，本申请提供一种计算机程序产品，所述计算机程序产品用于存储计算机程序，当所述计算机程序被一个或多个处理器执行时实现第一方面至第七方面任意一项提供的方法。
第十四方面，本申请提供一种计算机设备，该计算机设备可以为终端设备，例如智能手机等，该计算机设备还可以为应用于无人驾驶的智能设备，或者虚拟现实/增强现实/混合现实设备、人工智能设备等。该终端设备包括前述任意一种进程间通信的装置或任意一种MMU。该计算机设备还可以为服务器。
需要说明的是，本申请提供的方法等也可以应用于宏内核架构下。以上提到寄存
器中2个或2个以上寄存器存储的信息也可以合并到1个寄存器中，本申请对寄存
器的数量不做限定。
附图说明
下面将对本申请附图作简单地介绍。显而易见地，下面描述的附图仅仅是本申请的一些实施例。
图1为微内核和宏内核使用文件系统对比；
图2为本申请提供的一种XPC系统的架构示意图；
图3为本申请提供的一种XPC系统中上下文切换相关部分的示意图；
图4为本申请提供的xcall和xret指令的流程示意图；
图5为本申请提供的一种XPC系统中接力段内存相关部分的示意图；
图6为本申请提供的一种内存管理方法的示意图；
图7为本申请提供的一种XPC系统中内核层的结构示意图；
图8为本申请提供的分离上下文模型的概念和应用示意图；
图9为内核实现对XPC引擎管理和配置的部分流程示意图；
图10为内核实现接力段内存的申请和释放的流程示意图；
图11为本申请提供的进程间通信IPC通信方案的整体流程示意图；
图12为传统进程间通信与本申请提供的XPC通信的对比；
图13为本申请提供的XPC方案在Sqlite3数据库上应用的示意图；
图14为Sqlite3数据库应用本申请提供的XPC方案后的测试结果示意图；
图15为本申请提供的服务端线程动态扩展的示意图；
图16为本申请提供的方案在Linux上应用的示意图；
图17为本申请提供的方案在Linux上应用后的测试结果示意图；
图18为本申请提供的一种终端设备的结构示意图。
具体实施方式
IPC的性能开销主要来源于两个方面，其一是上下文切换，可参考背景技术部分的描述。 本申请中出现的上下文一般指的是线程(或进程)上下文，具体的，指的是一个操作系统中维护的一个线程(或进程)的各种状态，通常包括线程使用的寄存器、页表、线程私有存储空间、线程元数据等等。其二是数据传输的开销。要完成跨进程的数据传输，通常使用拷贝或者共享内存的方案。使用拷贝会带来很大的性能开销，尤其对于一些数据流通比较大的应用；而共享内存方案虽然理论上可以做到零拷贝，却存在检查时间到使用时间(Time of Check to Time of Use,TOCTTOU)的安全问题。
本申请提供的方案为软硬协同方案。首先本申请设计了一套跨进程调用的硬件架构。该方案在底层硬件中对于上下文切换提供了支持。上下文切换需要切换两个进程空间(调用者和被调用者)的各种状态和信息。为了保证跨进程调用的控制流，调用的信息将会被记录在一个硬件控制的数据结构中，这个数据结构的信息将会在进程返回时的检查中使用。
进一步的，该方案将原先在内核中完成的权限检查的工作下放到硬件中完成。
进一步的，该方案还在硬件中对快速数据传输提供了支持。通过简单地扩展硬件，例如TLB，该方案支持零拷贝的数据传输。
同时，本申请在以上硬件架构的基础上提供了内核系统的软件设计方案，来保证进程直接调用和零拷贝的安全性和性能。
下面通过具体实施例介绍本申请提供的方案的实现。本申请在下述实施例中将提供的跨进程通信系统命名为XPC(cross process call)，但XPC仅为一个名称，不应该作为对本申请的限制。
图2为本实施例提供的XPC系统的架构示意图。该系统包括应用层、用户态库层、内核层和硬件层。
应用层：运行各种多个应用：应用-1到应用-n，本方案提供的进程间通信的优化对该层透明，保证兼容性。
用户态库层：包含两个模块，切换接口模块301和接力段内存接口模块302。这两个模块会提供应用所需进程间通信调用接口，并且会将接力段内存进行封装，提供和共享内存相似的使用接口。
内核层：包含四个模块，切换管理模块201、接力段内存管理模块202、XPC硬件管理模块203以及分离上下文管理模块204。硬件管理模块203负责直接操作硬件层提供的新的指令，以实现进程间的上下文切换。切换管理模块201和接力段内存管理模块202分别负责在软件层对上下文切换和数据传输的安全维护管理。分离上下文模块204则负责内核管理用户态基于新硬件原语的运行时安全。
硬件层:包括切换器101和数据传输器102两个硬件模块，从而和软件层一起实现上下文切换和数据传输等进程间通信能力。切换器101负责实现上下文切换、权限检查等功能，数据传输器负责实现数据传输。
切换器101和数据传输器102可以设置在已有的处理器上，作为处理器的扩展单元，利用已有的处理器的计算能力，也可以作为一个或多个独立于已有处理器的硬件单元，为已有处理器加速。在其他一些实施例中，切换器101和数据传输器102也可以用软件模拟实现。
需要说明的是，切换器101和数据传输器102这两个模块是从功能逻辑上的划分，并非限定二者必须是两个独立的硬件单元。在接下来介绍的XPC引擎的硬件设计中将会对这两个 功能进行详细的介绍。
切换器101、切换管理模块201和分离上下文管理模块204向用户态库层和应用层提供了快速的上下文切换接口。数据传输器102和接力段内存管理模块202向用户态库层和应用层提供了安全的、零拷贝的跨进程数据传输接口。
在整个架构中，硬件层和软件层的分工在于：硬件层提供进程间通信的能力，包括能力检查、上下文切换、以及安全有效的数据传输机制，而内核层通过对硬件层的配置等操作实现对进程通信的管理和控制。
需要说明的是，图1中展示的所有组件模块，除应用层包含的应用外均为本申请的相关模块。另外，图1中的模块划分仅是举例说明，方便理解方案，不应该作为对本申请的限制，而且所有模块并非缺一不可。
下面介绍本申请提供的XPC方案中硬件设计的部分。如图3所示，本申请主要提出了XPC引擎和接力段内存，从而提供解决两个问题的硬件基础：跨进程快速切换和零拷贝安全数据传输。在介绍具体的实现之前，先介绍几个概念。
调用者(caller)：也可以叫客户(client)或客户端，指传统的IPC通信或本申请提供的XPC通信中使用服务的一方。调用者可以是进程、线程或应用，具体根据其出现时的上下文确定。
被调用者(callee)：也可以叫服务端(server)，指传统的IPC通信或本申请提供的XPC通信中提供服务的一方。被调用者可以是进程、线程或应用，具体根据其出现时的上下文确定。
需要说明的是，调用者和被调用者仅是角色名称，不指向特定的进程、线程或应用。多个被调用者存在时也称为调用链，例如A调用B，B调用C，则A、B和C形成调用链。
x-入口(x-entry)即：一个进程可以创建一个或多个x-entry。一个x-entry用于表示一个能够被其他进程调用(invoked)的过程。每一个x-entry有一个唯一的标识(identifier,ID或id)。
调用能力(xcall cap)：是“XPC call capability”的缩写，用来记录每一个调用者的能力。在本实施例中通过一个寄存器指向的一个位图表示。
接力段内存，简称接力段(relay segment，简称为relay-seg)：在本实施例中指的是一块具有连续地址空间的内存区域，或者可以理解为是一段连续虚拟地址空间到一段连续物理地址空间的映射。其中，虚拟地址到物理地址的映射(或称地址翻译)由本实施例新增的寄存器实现，这个寄存器可以由调用者(caller)转移给被调用者(callee)，因此被调用者可以直接访问该寄存器指示的虚拟地址空间中的数据。接力段内存在转移给被调用者之前，还可以进行遮盖，即仅转移部分内存空间(参考图3(b))。需要说明的是，在其它实施例中，通过引入页表(page table)设计，本申请提出的接力段内存也可以支持不连续的内存空间。
XPC硬件设计的程序模型(也可以理解为基本的使用原理)为：服务端(server)通过传递过程句柄(procedure handler)、句柄线程以及一个最大上下文数字来注册x-entry。该最大上下文数字用于指示同时发生的调用者的最大数量。该句柄线程用于为客户提供运行时状态，并且该句柄线程可以被多个x-entry共享。x-entry注册成功之后，服务端就进入等待状态。客户通常从父进程或一个命名服务中获得一个x-entry的ID以及自己的XPC调用能力。然后， 客户可以通过执行特定指令(本实施例中为xcall)来实现对前述x-entry的调用。xcall可以携带参数，该参数用于指示待调用的x-entry的ID。在本实施例中，该ID存储在任意一个通用寄存器中，所以可以用该寄存器的标识#reg来标识该参数。待服务完成之后，再通过特定指令(例如xret)返回。xcall和xret是XPC引擎提供的两个硬件层面的指令，调用这两个指令绕过了内核，直接让硬件参与实现上下文切换，从而大大提高了上下文切换的效率。进一步的，客户与服务端之间的数据传输通过接力段内存和新增的寄存器来实现，从而避免了数据拷贝。
指令、命令、函数或函数接口指的是由软件或硬件实现的方法过程对外展示的、可调用的名称。
下面详细介绍一下XPC引擎中包含的各个组件以及各个组件的功能。图3(a)为本实施例提供的XPC引擎的结构示意图，该XPC引擎设置在现有的处理器核上，作为现有处理器核的扩展。该XPC引擎包括多个寄存器和XPC逻辑(logic)。在其它实施例中，XPC引擎可以作为一个独立于现有处理器的处理单元，用于对现有处理器进行加速。在其它实施例中，XPC引擎也可以采用软件模拟的方式实现，该软件运行在一个较高级别的模式下，例如RISC-V这种有比监控模式(supervisor mode)更高权限的权限级机器模式(machine mode)，那么可以使用软件实现XPC引擎并运行在该机器模式。
图3(c)在图3(a)的基础上进一步展示了与上下文切换相关的寄存器的含义。
寄存器x-entry-table-reg用于存储物理地址。该物理地址作为基地址，指向一块内存区域，该内存区域保存服务端可提供的服务的信息，这些信息可以以图中所示出的x-entry table的形式保存。“基地址”是一个地址区间的起始地址。该x-entry table中的每一行指示一条x-entry,。每一个x-entry的ID可以用该行的行号来标识，也可以在表中增加一列，该列用于存储x-entry的ID。每个x-entry包括页表指针(page table pointer)、能力指针(capability pointer)、入口地址(entry address)、以及有效位(valid)等属性。页表指针是页表基地址，也就是现有技术中做页表翻译的页表寄存器中存储的值。能力指针也是基地址，是本实施例中引入的新的寄存器xcall-cap-reg中存储的值，指向一个数据结构。入口地址是指切换到服务端上下文后处理器执行的函数的地址。有效位表示一项x-entry是否合法。需要说明的是，该表的内容在不同的架构下可以定制化地进行减少或扩展，图示仅为示例。
寄存器x-entry-table-size用于存储数据结构的大小信息。具体的，该寄存器用于保存上述x-entry-table的大小。
寄存器xcall-cap-reg用于存储物理地址。该物理地址作为基地址，指向一块内存区域，该内存区域中存储有图中所示的位图(bitmap)xcall-cap bitmap。这个位图表示一个调用者能够进行XPC的能力或权限，只有当该位图中指定的位被正确的设置上时才能进行进程XPC通信。换句话说，只有进程具备合适的权限时，才能执行上下文切换。该位图的大小也可以存储在x-entry-table-size中。具体的，该位图中每个标识为i的位的值代表调用者是否能调用id为i的x-entry。例如，当前调用者为线程m，该位图可以存储在该线程m的私有内存区域(per-thread memory region)中，若该位图中标识为2的位的值为1，则表示该线程m可以调用id为2的x-entry；若标识为2的位的值为0，则表示该线程m不能调用id为2的x-entry。每一位的值的意义也可以和上述示例相反。在本实施例中，该位图由内核来维护，但 由硬件在执行xcall的时候检查。
需要说明的是，以上用位图来表示能力的方式仅是举例说明，在其它实施例中，可以根据需求采用其它方式来赋予位图中每一位的含义，例如位图中每个标识为i的位的值代表被调用者是否能被id为i的调用者调用，再例如存在多个位图，对调用者的调用能力和被调用者的授权进行多种方式的定义，等等。
寄存器link-reg用于存储物理地址。该物理地址作为基地址，指向一块内存区域，该内存区域中存储有图中所示的栈link stack。该link stack负责保存用于返回调用者上下文的信息(该信息也可以称为调用信息)，这些信息在执行特定指令(例如xret)返回调用者的时候用于恢复调用者的状态。如图所示，link stack中每一行的信息可以称为一条链接(linkage)记录，包括调用者页表指针(caller page table pointer)、调用者能力(caller capability)、返回地址(return address)、调用者接力段(caller relay segment)以及有效位(valid)，这些列存储的信息的格式与x-entry table类似，不再赘述。需要说明的是，该栈的内容在不同的架构下可以定制化地进行减少或扩展，比如增加调用者的接力段内存列表。
该link stack实际上就是用于保存调用者的上下文，以便于服务完成之后恢复。
需要说明的是，上下文保存分两部分，一部分是硬件在执行xcall指令的时候保存在link stack上的，这部分保存的内容参见link stack；另一部分是软件层面的上下文保存，软件可以在调用xcall指令前保存一些状态在软件内存中，这些状态是可以为全部上下文，也可以为部分上下文。全部保存还是部分保存的选择策略可以根据系统需求确定，本申请不做限定。举例来说，可以根据被调用者的可信程度进行上下文保存，如果被调用者可信，那么保存少量的上下文信息；如果被调用者不可信，那么保存全部上下文信息。
以上四个寄存器是和上下文直接切换相关的，在本实施例中主要用于实现无内核干预的上下文切换过程。以上四个寄存器主要维护了三个数据结构，分别是x-entry table，link stack，以及xcall-cap bitmap。在上下文切换时，参考图3(c)，首先①通过xcall-cap bitmap检查是否允许执行切换，然后②通过x-entry table切换到服务端上下文，待服务执行完成后，③根据link stack记录的信息返回调用者上下文。但是，这三个数据结构并非缺一不可。在本实施例中，这三个数据结构都是允许内核访问但是不允许用户态访问的。需要说明的是，这三个数据结构仅是示例，在具体实现中，它们包含的信息也可以采用其它的形式存储，例如xcall-cap bitmap中存储的信息还可以使用根树(radix tree)的形式存储，根树类似页表(page table)，比位图具有更好的可扩展性。
和宏内核相比，微内核的IPC的性能开销的主要原因仍然是软件干预导致的。为了消除掉这部分的开销，本实施例提供的方案直接在硬件中支持进程间调用。基于前述XPC引擎的设计，硬件层向用户态提供了两个指令：xcall和xret，分别作为进程间调用的调用指令和返回指令。xcall会在硬件层完成权限检查和跳转逻辑等，而xret会通过硬件维护的栈(前述的link stack)回到之前的进程环境。
下面结合图4详细介绍xcall和xret的功能。这两个指令的功能由XPC逻辑内的硬件电路实现。在其他实施例中，xcall和xret也可以部分由硬件电路实现，部分由软件程序实现或全部由软件程序实现。
xcall主要包括图中所示的5个步骤。
①调用者在使用xcall时会同时发送被调用者的id。根据该id从xcall-cap bitmap中获取对应的位。
②检查xcall权限。如果获取的位的值为1，表示有权限进行切换；如果该位为0，则表示没有权限，会触发异常或返回错误。
③当权限检查通过后，从x-entry table中，读取该id对应的表项。在其它实施例中，该步骤也可以放到④之后，和⑤合并。
④将当前的页表指针、能力、返回地址以及接力段写入link stack，设置有效位为1。页表指针指的是页表寄存器的值，接力段指的是接力段寄存器中的值，能力指的是xcall-cap-reg中的值，返回地址指的是程序计数器(program counter,PC)中下一条指令的地址。由于当前还没有执行上下文切换，所以以上这些信息都可以认为是调用者的信息。关于接力段寄存器会在后续实施例中详细介绍。
在其它一些实施例中，步骤④可以采用异步的方式实现，例如linux的非阻塞(non blocking)方式，这样就可避免硬件必须等待该步骤完成才能执行下一步，进一步减少了切换的时间。
⑤将页表寄存器、PC等修改为步骤③从x-entry table中读取到的对应项。具体的，将页表寄存器中的值修改为page table pointer的值，将PC设置为entry address的值等。这样就从调用者的上下文切换到了被调用者的上下文。
在以上过程中，除了前面提到的检查权限之外，还可以检查id合法性、检查x-entry是否合法、检查link stack空间是否足够等，当出现不合法或空间不够的情况时发触发异常或返回错误。这些检查措施可以根据实际情况选择执行，不执行、全部执行或部分执行都可以，本申请对此不做限定。生成的异常或错误可以上报给内核，由内核处理。
在其它一些实施例中，本申请提供的方案还可以包括用于预取x-entry的缓存(cache)。这样设计主要基于两方面的考虑：1.对于每一个调用者，尤其是当调用者是一个线程时，IPC具有很高的时间局部性(temporal locality)；2.IPC是可以预测的。基于这两方面的考虑，本申请可以为XPC引擎设计一个软件可管理的缓存，使用该缓存存储一条或多条x-entry。基于该设计，用户态应用可以提前将某些x-entry存储到该缓存中，进一步缩短了IPC的通信时长。
xret主要包括图中所示的2个步骤。在xcall的过程中，调用者的信息会被记录在link stack中。在xret的时候，从link stack的顶部读取信息(①)。将页表指针、能力、入口地址等修改为从link stack中读取到的信息(②)，这样就恢复到调用者的上下文。
在以上过程中，还可以包括检查link stack是否为空，检查从link stack中读取到的有效位，以及当前的接力段寄存器是否和link stack中记录的值匹配等，若为空、无效或不匹配则触发异常或返回错误。这些检查措施可以根据实际情况选择执行，不执行、全部执行或部分执行都可以，本申请对此不做限定。生成的异常或错误可以上报给内核，由内核处理。
由于使用xcall和xret完成上下文切换的过程中仍然可能涉及到页表的切换，所以在其它一些实施例中，可以在本实施例的基础上增加被标记(tagged)的转换检测缓冲区(Translation Lookaside Buffer，TLB)的机制，通过该机制能够有效避免页表切换中对于TLB的刷新操作，进一步提升了xcall和xret指令的性能。tagged TLB具体来说是在每一个TLB项上会有一个ASID，该ASID用于表示这项TLB是哪一个进程的，利用这种方法可以使得进程间 上下文切换的时候不需要刷新整个TLB。
需要说明的是，在其他一些实施例中，可以不采用本申请提供的接力段内存的机制，例如，采用共享内存机制。如果不采用接力段内存机制，则在xcall或xret过程中不需要考虑接力段相关的内容，例如，如果使用共享内存机制，则调用者和被调用者使用共享内存接口即可。共享内存的实现可参考现有技术，本申请不再赘述。
从软件角度来看，硬件基于上述的XPC引擎向内核暴露了一系列可以配置的寄存器，并给出了两条用于上下文切换的指令xcall和xret。基于这种设计，用户态应用可以在不陷入内核的前提下就完成上下文切换，提高了上下文切换的效率，从而提高了IPC的效率。
进一步的，本申请提供的硬件还支持零拷贝的IPC数据传输，同时能够保证数据传输的安全性。如图5所示，XPC引擎中还包括三个寄存器：接力段寄存器seg-reg、接力段选择器seg-mask、以及接力段列表寄存器seg-list-reg。其中，seg-reg表征一段虚拟内存和物理内存的映射，在IPC切换的时候，会取seg-reg和seg-mask中存储的内存区间的交集作为被调用者可访问的接力段内存。
seg-reg包含四项信息：虚拟内存基地址VA base、物理内存基地址PA base、长度length、权限permission。接力段内存对应的就是从VA base开始，长度为length的内存，这段虚拟内存对应的物理内存由PA base和length制定。权限可以包括非法、读、写、执行权限等。在地址翻译的时候，seg-reg相对于现有的页表有更高的优先级。
seg-mask中包含两项信息：偏移(offset)和长度(length)。在xcall进行切换的时候，硬件会根据seg-mask中的信息，更新seg-reg中的基地址和长度。应用不能直接改变seg-reg中的映射，但是，可以使用seg-mask来缩小当前接力段内存的范围，然后将该缩小后的接力段内存传递给被调用者。这种能力在部分数据不能传输的时候有用，尤其是当多个主体形成调用链条的时候。例如，A调用B，B调用C，A的部分数据不能传递给B或C，这时可以通过seg-mask将接力段内存中的部分内存传递给B。
为了让应用使用更多的内存作为接力段内存，本实施例还提供一个寄存器seg-list-reg，该寄存器保存一个物理地址，该物理地址指向内存中的一个数据结构，即图中的表relay segment list。这个表的每一行包含一条seg-reg中的信息。seg-list-reg中每一行包含的信息和seg-reg一样，也是指向一块接力段内存，所以seg-list-reg中可以保存一块或多块接力段内存的地址信息。这样，应用就可以创建多个接力段内存，并在有需要的时候切换接力段内存，使得接力段内存的使用更加灵活。
进一步的，为了不下陷到内核就实现接力段内存的切换，本实施例还提供一个新指令：swapseg。例如，当该指令被用户态进程调用时，硬件层可以原子地切换seg-reg中的内容和relay segment list中的一行，从而实现接力段内存的切换。再例如，swapseg还可以用于原子地切换两个接力段寄存器中的内容，或者将某个地址覆盖接力段寄存器中的地址，等等。需要说明的是，relay segment list可以存储在创建它的进程或线程的私有内存空间中，并由内核管理。
需要说明的是，这三个寄存器并非缺一不可，比如，在一些情况下，可以不设置seg-mask和seg-list-reg中的一个或两个。
本实施例还对内存管理单元(memory management unit,MMU)进行了扩展，如图6所示。传统的虚拟地址到物理地址的翻译(也可以称为映射)是通过MMU以及MMU内部的转换检测缓冲区(Translation Lookaside Buffer，TLB)进行处理的，即图中白色部分。本实施例的扩展在于图中黑色部分示出的流程。在获得一个虚拟地址(VA)需要进行翻译的时候，MMU会首先判断该VA是否落在接力段内存的区间内，如果是，会直接使用前述seg-reg表示的内存映射进行翻译，输出对应的物理地址PA，具体的，PA＝VA-VA base+PA base(参考图5)。若该VA没有落在接力段内存的区间内，则使用之前的TLB和MMU进行地址翻译。
需要说明的是，MMU寄存器seg-reg的访问可以通过硬件线路实现，XPC引擎可以通过该线路将seg-reg寄存器的值传递给MMU。在其他实施例中，也可以采用其它的方式，本申请对此不做限定。
为了防止TOCTTOU攻击，内核将会保证每一个接力段内存在同一时间只能被一个核使用，即同一时间只能属于一个线程。这种所有权会伴随着调用链进行转移，比如A调用B，B调用C，则接力段内存会从A转移到B，再转移给C，可以全部或部分转移。
在xret阶段，XPC引擎还可以检查seg-reg中值与link stack里存储的seg-reg和seg-mask的交集是否一致，若不一致，则触发异常或错误，由内核处理该异常或错误；若一致，才继续执行。这样可以避免恶意的被调用者修改调用者的接力段内存。
以上主要描述了本实施例的硬件设计，总的来说，以上设计为应用程序提供了基于XPC引擎的直接的、无内核干涉的上下文切换能力，能力检查能力，以及基于接力段内存的安全的、零拷贝的数据传输能力。
从软件的角度来看，硬件层的设计为软件层提供了新的硬件原语(primitive)，包括上下文切换原语和接力段内存原语等。其中，上下文切换原语中包括两个新的指令：xcall和xret；接力段内存原语中包括一个新的指令swapseg。需要说明的是，本实施例中原语指的是完成特定功能的一个过程，具有不可分割性，硬件原语则是通过硬件层实现的原语。在其他实施例中，本申请提供的方案也可以不通过原语来实现，可以接受一定程度的功能分割。
下面介绍本实施例提供的XPC方案的软件部分的设计。图7为本实施例操作系统内核部分包括的软件模块的示意图。
硬件管理模块203、切换管理模块201和接力段内存管理模块202，这三个模块为离线配置模块，而分离上下文管理模块204为运行时模块。其中硬件管理模块203直接操作本实施例提供的新的硬件原语。而切换管理模块201和接力段内存管理模块202分别基于硬件原语，在内核中提供对于上下文切换和数据传输的配置，包括安全和策略的配置等。切换管理模块201和接力段内存管理模块202依赖于硬件管理模块203进行硬件操纵。这三个模块都是配置硬件的，因此被定位为离线配置模块。分离上下文管理模块204负责提供线程或进程运行时的状态维护和IPC信息维护。需要说明的是，以上模块划分仅是举例，并非缺一不可，本领域普通技术人员也可以通过其它分类方式对软件模块进行分类，本申请对此不做限定
下面对分离上下文管理模块204、切换管理模块201和接力段内存管理模块202分别进行详细的说明，而硬件管理模块203为内核中负责前述XPC引擎的管理代码，可以理解为驱动，该部分的实现类似于现有的硬件管理，本申请对此不再赘述。
传统IPC中的线程模型，是将所有的线程上下文都包含在一起的。线程(或进程)上下文是指一个线程的各种状态，通常包括线程使用的通用寄存器、页表、线程私有空间、线程元数据等。这种线程模型在以内核为中心的传统IPC通信中是可以工作的。然而在本申请提供的用户态直接切换上下文的方案中，传统的线程模型可能会导致内核无法识别当前用户态线程。为此，本实施例提出了“分离上下文模型”，如图8(a)所示，将传统的线程上下文进行分离，分成运行时上下文和调度上下文两个抽象。运行时上下文允许用户态通过XPC引擎进行切换，调度上下文只有内核进行维护。分离上下文模型能够扩展现有的内核线程模型，使其能够支持XPC下的用户态进程的异常和系统调用。
在分离上下文模型下，内核通过额外的寄存器(如xcall-cap-reg)确定当前线程的运行时上下文，而通过内核维护的状态来确定调度上下文。这种分离管理的方式提供了更高的灵活性，并且允许用户态重用一个调度上下文，而支持不同的运行时上下文。图8(b)为分离上下文模型的应用过程。用户态进程触发了异常(如缺页异常)或者调用了一个系统调用，下陷到内核(①)。在内核中，内核首先恢复自己的上下文，如内核的堆栈(②)。内核从恢复的状态中获得线程的调度上下文(③)。内核从当前的硬件状态(即xcall-cap-reg)中获取用户态线程的运行时上下文。内核根据运行时上下文处理异常或者系统调用，如使用运行时上下文中的页表来处理缺页异常或者通过运行时上下文中的capability表来处理系统调用(⑤)。当操作系统进行调度时，内核根据调度上下文(如时间片信息)进行调度(⑥)。请求处理完成，返回用户态(⑦)。操作系统的调度策略和调度过程可参考现有技术，本申请对此不做限定。分离上下文模型扩展了现有内核的上下文管理。
需要说明的是，在本实施例中，xcall-cap-reg是每个线程唯一的，因此可以起到一个索引的作用定位到一个线程的运行时上下文。具体的，比如可以在xcall-cap-reg的内存附近再分配一个内存页，记录该线程的运行时上下文，比如页表基地址等；然后内核直接根据xcall-cap-reg去访问那个内存页里面记录的运行时上下文。在其他实施例中，内核可以通过其他的寄存器或其他的方式获取运行时上下文。
切换管理模块201需要对硬件进行处理，需要XPC引擎提供的硬件原语支持。如图9，切换管理模块201主要用于实现服务注册、调用授权以及异常处理三个流程。图中黑色底色步骤为本申请提出的方案的核心相关过程。
一个应用，作为服务端，在提供服务之前首先通过内核提供的接口来注册自己的服务：①内核对该注册请求进行检查，判断是否合法；②然后将服务的信息记录在内核中；③将服务的信息转换成一条x-entry，包含服务端的页表、入口地址等信息(可参考前述对x-entry table的介绍)，通过硬件管理模块203提供的接口将该x-entry加入到x-entry table中。最终，内核将返回一个id给用户，表示对应的服务在x-entry table中的索引位置，该id可以作为该服务的标识被调用者使用。
一个应用，作为客户，在获得服务之前需要内核对其进行授权，该授权的实现包括：①内核首先检查该客户通过各种方式获得某个服务的调用权限是否合法；②然后更新该客户的IPC调用权限信息；③内核会将该客户对应的xcall-cap bitmap中的对应的位设置为1，表示允许这个客户直接调用到对应的服务(可参考前述对xcall-cap bitmap的介绍)。为了安全性，内核部分可以设置多种安全策略，基于安全策略来确定到底能不能授权，本申请对安全策略不做限定。
在IPC调用的过程中，用户态程序可能触发异常或错误，内核需要对这些IPC过程中的异常或错误进行处理。①首先内核获取异常类型，以判断异常是否为IPC相关异常；②内核通过读取触发异常时的link stack的信息，获取当前的IPC调用链信息并依此恢复这条IPC调用链上的状态；③终止异常线程并回收相关资源。
需要说明的是，图9中提供的三个流程中有的步骤(比如白色底色的步骤)和现有的微内核IPC通信的配置或异常处理是相同或类似的，因此在本申请中不再详述。但是图9提供的三个流程仅是举例，可以根据实际需求有所变化，也可以因不同类型的系统内核有所变化，因此图9所示的流程不应理解为对本申请的限制。
如图10所示，接力段内存管理模块202主要实现接力段内存申请和释放两个功能，并向应用层暴露实现这两个功能的接口。
接力段内存申请包括：①内核检查物理内存是否已经分配/映射，以保证新分配的接力段内存不会存在在现有的其他接力段内存和用户态内存中；②内核检查当前是否有使用中的接力段内存，避免覆盖导致内存泄漏；③前两项检查均通过后，内核标记该物理内存段为“已分配接力段”状态；④内核分配一块虚拟内存空间，将这段物理内存和虚拟内存写入接力段寄存器seg-reg中。最后内核返回分配的虚拟内存的地址，如果申请过程中有检查不通过或内存不足等异常情况时则返回错误值。
为了避免接力段内存和普通内存的重叠，步骤④中分配的虚拟内存将会被分配在特定的区间，这段区间只会拿来映射接力段内存，而不会用来映射普通内存。这里的普通内存指的是除本申请提供的接力段内存之外的内存。
接力段内存释放包括：①内核首先检查接力段内存的合法性；②若检查为合法，则释放对应的物理内存，并将该物理内存标记为空闲；③清空接力段寄存器seg-reg；④为释放的物理内存分配能力(或称权限)。最后内核返回释放的物理内存及其能力。
本实施例提供的方案可以通过维护接力段内存权限转移(ownership transfer)的来实现接力段内存的唯一性。在分配一块接力段内存时，这段接力段内存只能被对应的线程使用，即使同进程的其他线程也无法访问到这段内存，因此可有效避免TOCTTOU的攻击。
应用本实施例提供的方案之后，进程间通信流程如图11所示，主要分为三个阶段，第一个是服务阶段。①服务端初始化自己的运行环境，确保处于可以接受请求状态。②服务端注册IPC服务，其中包括微内核中的IPC服务端口配置以及微内核设置硬件中的状态，注册过程的具体实现可参考前述IPC管理模块中服务注册的实现。③服务端开始进入等待处理请求状态。第二个阶段是客户阶段。④客户获得调用服务的能力，如何获得可参考前述切换管理模块201中调用授权的实现。⑤客户将数据存储到接力段内存中。在这之前申请接力段内存，申请方法可参考图10。⑥客户调用xcall以进行IPC调用。第三个阶段是服务阶段。⑦xcall命令被XPC引擎执行之后就实现了客户进程到服务进程的切换，之后服务端通过接力段内存获取客户的数据，并开始执行服务逻辑。⑧服务端处理完成请求之后，通过xret命令将服务结果返回客户。IPC完成之后，客户可以释放接力段内存，释放方法可参考图10。
在前述步骤⑥中，XPC引擎可以对客户是否有权限执行调用操作进行检查，检查失败会触发异常，检查成功则会切换到服务的上下文中，并且接力段内存也会通过寄存器的方式转交给服务端。
在其它实施例中，步骤①-⑧的执行顺序可以根据需求调整，例如，前述步骤⑤和其它步骤的顺序可以调整，具体的，客户申请接力段内存可以在更早之前执行，或申请接力段内存和存储数据都可以在更早之前实现。
需要说明的是，前述步骤中包含的更详细的实现，例如xcall或xret的实现、能力的授权、接力段内存的申请和释放等可参考前面的描述。
本实施例通过软硬件结合的方式，软件负责安全机制保证，硬件负责运行时加速切换，实现快速的切换和安全零拷贝数据传输。软件(内核)维护接力段内存的唯一性和虚拟地址的安全性，硬件提供运行时寄存器交接式数据传递，实现安全零拷贝数据传输。
图12给出了本实施例过程和传统IPC的对比。传统IPC依赖于内核完成进程间通信(①-⑤)，包含运行模式切换、缓存污染、权限检查、上下文切换、地址空间切换、内核检查逻辑复杂等开销。传统IPC在数据传输时至少有两次拷贝过程且有TOCTTOU攻击的风险，而本申请提供的方案通过调用xcall由硬件实现权限检查、上下文切换等，成功绕过了内核(①-③)，避免了陷入内核的开销，并且由硬件提供寄存器交接式的数据传输机制，避免了数据的拷贝，从而达到了更好的IPC通信性能。
图13为应用本申请提供的方案之后，Sqlite3数据库应用访问存储在存储介质中的数据的过程。在该实施例中，硬件层扩展了XPC引擎和接力段内存，内核选择使用Google Fuchsia系统的内核Zircon。应用程序选择Sqlite3，文件系统为xv6fs，使用虚拟内存盘ramdisk作为可存储设备。图中序号仅列出Sqlite3进程相关的操作。
文件系统进程和块设备驱动进程注册服务。具体的，文件系统进程和块设备驱动进程在操作系统启动阶段先行执行初始化逻辑，对自己程序进行初始化，并且分别通过内核提供的接口，注册自己的IPC服务。
文件系统进程和块设备驱动进程建立通信通道。具体的，文件系统进程需要通过块设备驱动进程访问真实的设备，因此初始化时会建立文件系统进程和块设备驱动进程间通信的通道，允许文件系统进程调用块设备驱动进程的服务。
Sqlite3数据库进程和文件系统进程建立通信通道(图中编号① ② ③ ④)。具体的，Sqlite3数据库进程启动，初始化时会将文件系统进程的调用权限授权给Sqlite3进程，建立二者之间的通信链路。
Sqlite3准备和文件系统进程通信的数据(图中编号⑤ ⑥ ⑦ ⑧)。具体的，Sqlite3通过接力段寄存器准备数据。以写(write)操作为例，Sqlite3使用接力段内存作为自己的数据内存使用。在write接口中，通过接力段选择寄存器seg-mask将可传递的接力段内存限制在write请求的数据访问内。
Sqlite3调用文件系统服务(图中编号⑨)。具体的，Sqlite3准备访问文件系统服务，通过调用用户态库提供的xcall命令直接切换到文件系统进程上下文中。Sqlite3的xcall会进入文件系统上下文的一个入口点。在这个入口点，文件系统服务分配资源，然后执行文件系统内部的写操作。在执行写操作的过程中可能会有调用块设备驱动进程的过程，与Sqlite3调用文件系统进程的过程类似，不再赘述。
文件系统进程通过xret返回结果给Sqlite3(图中编号⑩)。具体的，文件系统将执行完的结果，通过寄存器返回给Sqlite3数据库进程。
使用了YCSB(Yahoo！Cloud Serving Benchmark)测试集(A-F)对于Sqlite3程序进程了测试。如图14所示，和没有使用本申请进行优化的方案相比，优化过的版本在吞吐量上能够达到最高2.5倍以上的性能提升。
本申请提供的方案还能够支持服务线程的动态扩展。图15为服务线程动态扩展的示意图。本申请提供的方案允许服务端按需创建新的工作线程(work thread)。如图15所示，客户通过XPC引擎提供的指令xcall进行IPC调用，服务端通过动态分配组件判断是否需要分配新的线程资源。如图中(a)所示，当仅有一个客户调用该服务时，动态分配组件仅需创建一个工作线程需要的服务运行上下文资源。如图中(b)所示，当出现多个客户同时调用该服务时，动态分配组件将会创建多个工作线程需要的服务运行上下文资源。本实施例不需要静态分配服务端处理线程资源，并且可以复用被阻塞(block)的客户线程的调度上下文资源，提高了系统资源利用率。
如图15所示，由于分离上下文机制，本申请可以将服务端的代码放在客户的调度上下文中运行的，因此可以将跨核的交互变成单核的交互，避免了跨核的跨核中断等开销。
需要说明的是，IPC机制不仅是微内核的进程间通信机制，在宏内核中，也会应用IPC进行进程间通信，本申请提供的方案不仅适用于微内核，也适用于宏内核。
下面介绍本申请提供的方案的基于RocketChip的一种具体实现。将本申请提供的方案集成到RocketChip RISC-V核上，支持微内核、宏内核以及用户级别的数据传递(handover)机制。
XPC引擎实现为RocketChip核的一个单元。表1展示了新的寄存器和新的指令的详细信息。这些新的寄存器用控制和状态寄存器(control and status register,CSR)实现，能够被csrr(CSR read)指令和csrw(CSR write)指令访问。三个新的指令xcall、xret和swapseg在执行阶段被发送到XPC引擎。XPC引擎检查IPC的有效性并且返回被调用者的信息给管道(pipeline)。另外，还增加了5个新的异常，包括无效的x-entry，无效的xcall-cap，无效的链接(linkage)，无效的seg-mask以及swap-seg错误。
表1
Figure PCTCN2020090559-appb-000001
Figure PCTCN2020090559-appb-000002
内核管理四个XPC对象：1)全局x-entry表；2)对应每个线程的link stack(per_thread link stack)；3)对应每个线程的xcall能力位图(per_thread xcall capability bitmap)；以及4)对应每个地址空间的接力段列表(per_address_space relay segment list)。在系统启动(boot)阶段，内核为x-entry表分配内存并设置表的大小。当创建一个线程时，内核为这个线程的link stack分配8KB的内存，为xcall能力位图分配128B的内存，为relay segment list分配一个4KB的页。在一次上下文切换期间，内核负责保存和恢复前述对象2)和3)。
对微内核的支持从以下四个方面介绍。下面的介绍与本申请前面介绍的部分可相互参考。
1.能力(capability)。能力在微内核IPC机制中被广泛使用。本申请提供的方案引入grant-cap这个接口，该接口允许一个线程向另一个线程授权能力。内核为每个线程维护能力 列表。当一个线程创建一个x-entry，该线程将会把对应的xcall-cap通过grant-cap授权给其他线程。
2.分离线程状态或称分离上下文。由于内核感知不到当前运行的线程，所以用户态的域切换可能会导致内核的错误行为。例如，A通过xcall调用B，但是触发了一个页错误(page fault，也可称为缺页异常)并陷入到内核，但是内核会错误地将A的页表用于处理B的页错误。
为了解决这个问题，将内核维护的线程状态分成两个部分：调度状态和运行时状态。调度状态包括与调度相关的信息，具体包括内核栈、优先级(priority)、时间片(time slice)等等。运行时状态包括当前的地址空间和能力。每个线程可以和一个调度状态，以及一个或多个运行时状态关联。由于xcall-cap-reg是对应每个线程的，并且在xcall期间有可能被更新，所以内核可以使用xcall-cap-reg确定运行时状态。当一个线程陷入内核，内核可以根据xcall-cap-reg中的值确定该线程当前的运行时状态，以避免前述例子的错误。
3.多客户同时调用。本申请提供的方案支持一个x-entry同时被多个客户调用。为了实现这个目的，每个x-entry对应多个XPC上下文，该XPC上下文包括一个执行栈和本地数据。当创建一个x-entry的时候，服务端设置XPC上下文的最大数量。这些XPC上下文可以提前创建。在该x-entry被调用之前，会有一个空闲的XPC上下文被选择出来，然后切换到对应的执行栈并恢复本地数据，在返回之前释放资源。如果没有空闲的XPC上下文，则返回错误或继续等待空闲的XPC上下文。进一步的，为了防止DoS攻击，服务端可以采用特定的策略限制来自客户的调用。
4.应用终止。一个调用链中的某个过程的不正常终止可能会影响整个调用链。例如，A调用B，B调用C，但是B因为某个异常被内核杀死(killed)，这样当C调用xret的时候就会返回到一个错误进程。这种情况需要一个方式去触发一个异常，以便于内核来处理它。
在本实施例中，当一个进程终止的时候，内核将会扫描所有的link stack，通过页表指针找到该进程的所有linkage record，并把这所有linkage record都设置为无效。这样，如前面的示例，当C返回的时候，就会触发无效linkage的异常，从而内核可以处理该异常。
进一步的，本实施例还可以减少link stack的扫描频率：当B被杀死时，内核不需要执行扫描，但将B的页表清零，这样，当C返回的时候，就会触发一个页错误(page fault)，这样内核就获得机会处理该错误。另外，内核也会撤销(revoke)B的资源。
本申请提供的方案也支持宏内核。具体的，下面介绍本申请和Android Binder机制的融合方案。
Binder是Android在Linux内核中引入的重要的特性，主要负责Android上应用的进程间通信。Binder被广泛用在Android现有的服务中，如窗口管理(window manager)。Binder的架构包含基层，Linux Binder驱动、Android Binder框架、以及API层。本申请提供的方案对于Binder的支持只修改驱动和框架，而保证API尽量不改动。在Binder中，“binder transaction”用来表示一个跨进程的方法调用，这个调用使用内核的两次拷贝来实现数据传输。Android引入了另一个特性，ashmem(匿名共享内存)来加速Binder通信过程中的大数据传输。
binder transaction包含下面几个步骤。1.客户准备好方法标识、并且将传递的参数数据 放到Android中的Parcel结构中。2.客户调用Binder框架的API函数transact()。这个函数最终会陷入到内核的binder驱动中，并通过两次拷贝将数据拷贝到服务端。整个过程涉及两次数据拷贝和两次权级切换。3.服务端的binder框架接收到请求，调用onTransact()回调函数调用对应的方法。4.服务端将执行的结果通过binder驱动返回给客户。
如图16所示，我们通过XPC方案来优化整个流程。首先，API接口不需要改动，如transact()(见图中的1)和onTrasact()(4)，这能够使得XPC优化的binder依然能够兼容现有的应用。其次，扩展了binder驱动来管理xcall cap bitmap和x-entry table。当一个进程注册服务的时候，需要通过框架下陷到驱动配置x-entry table增加x-entry，删除x-entry是类似的。当客户获取调用服务的权限的时候，同样需要下陷到驱动中去设置自己的xcall-cap bitmap，清空操作也是类似的。最后，当运行时客户和服务之间进行通信的时候，和传统binder的方法(通过ioctl下陷到内核)不同，客户可以直接调用xcall指令到服务端完成调用(3)，而服务端处理完请求也可以直接通过xret指令返回到客户端(5)。此外，数据的传输也从Parcel的传输变成接力段内存的交接(2)。此外，linux还需要维护每个线程的上下文中的相关寄存器。基于XPC的优化可以避免两次权限级的切换和两次数据拷贝。
匿名共享内存(ashmem)通过file-based shared memory interface来给用户用。具体来说，用户进程可以分配一个fd，通过映射(map)这个fd拿到一块内存，而这个fd在binder中可以在不同的进程间共享，实现数据的传输。ashmem和传统的共享内存一样，同样有安全性问题存在，需要一次额外的拷贝来保证数据安全性。
基于XPC的优化包含三个方面。ashmem分配：binder框架通过接力段内存实现ashmem，分配的时候会分配对应的接力段内存给用户。ashmem映射：映射的时候会将对应的接力段寄存器设置上映射的ashmem的区间。ashmem传输：通过xcall将接力段内存直接交接给服务端。
使用本申请提供的接力段内存来优化ashmem可以避免额外的一次拷贝。当硬件中的relay-seg-reg不够多个ashmem的映射时，可以通过触发缺页错误(page fault)然后动态的映射的方式来进行调度处理。
本申请提供的方案还支持跨调用链的数据传递。在实际场景中，往往涉及到多个主体的嵌套调用链，如A调用B、B又调用C。而这里A传递给B的数据可能会直接传递给C。XPC的接力段机制能够实现跨函数调用链的传递(handover)，即数据零拷贝地在A、B、C之间传递，并且不存在安全性问题。
这里我们主要考虑三种情况，第一种情况是当B传递数据给C的时候，需要在A的数据的基础上增加一些数据；第二种是B只传递部分的数据给C；第三种情况是当C在执行的时候，B可能因为异常导致退出，需要处理资源的回收。
数据大小协商(message size negotiation)：针对第一种情况，我们使用数据大小协商的方式。即，即使A传递B一个较小的数据，但是如果B要传递给C一个更大的数据块的话，那么A可以预留这部分数据的区间，这样B可以直接在预留的区间上追加(append)数据，而不需要去重新分配和搬运数据。这里的协商是要看调用链的，如果B后面可以调用C或者D的话，那么A需要申请的空间应该是A发给B的数据大小、B发给C的数据大小、以及B发给D的数据大小，这三者中最大的那一个。
数据缩小(message shrink)：对于第二种情况，我们需要缩小接力段内存的区间。这个可以通过寄存器seg-mask来实现。通过seg-mask选择要传输的区间，多的部分不会被传递到服务端。
接力段回收(segment revocation)：对于第三种情况，当一个进程终止的时候，内核会遍历该进程的relay segment list，将调用者的接力段内存返回给调用者，其余的接力段内存则回收。
本实施例考虑了两种binder机制：通过缓冲区(buffer)传递数据的机制和通过ashmem传递数据的机制。本实施例分别将这两种binder机制进行了基于XPC的优化，并比较了通信时间，如图17所示。这里的通信时间包括数据准备(客户)、远程方法调用以及数据转移(框架)、处理表面内容(surface content)(服务端)、以及回复(框架)。通过图示可以看出，XPC可以有效地优化binder和ashmem的性能。
需要说明的是，宏内核可以仅集成XPC提供的接力段内存机制，上下文切换则采用现有机制或其它机制，这样也能提升数据传输的效率和安全性。
总结来说，本申请提供的方案包括但不限于以下的内容。
一、硬件支持的跨进程调用上下文切换原语的设计，通过xcall和xret两条新指令，允许用户态执行上下文切换功能。
1.xcall和xret为IPC过程中可以被硬件直接加速的部分，主要是IPC中客户端和服务端的上下文切换，通过硬件支持，加速IPC核心流程。
2.跨核交互优化机制：将多核场景下，原先通过跨核中断(Inter-processor interrupt)的通知方式换成将服务进程拉到当前核进行运行的机制。这种方式可以提供更好的服务进程对于客户进程的数据的访问的缓存命中率。
3.引入硬件缓存支持加速：在执行切换的过程中，xcall和xret的两条指令需要进行多次内存访问。本发明采取了针对于IPC信息的硬件缓存，来存储xcall/xret指令需要读取的数据。
4.异步状态压栈：在xcall的过程中，硬件需要将当前的客户端的上下文信息压入一个栈(link stack)中。这个过程可以被异步完成，避免了硬件同步地等待这个压栈操作完成。
5.利用tagged TLB避免页表切换开销的方法：使用xcall和xret在硬件中执行上下文切换仍然需要切换页表。使用tagged TLB的方式，能够避免页表切换中的对于TLB的刷新操作，提升了xcall和xret指令的性能。
二、硬件支持的数据传输机制的设计，通过接力段内存及其寄存器方式的传递方式，允许快速零拷贝数据传输。
1.通过寄存器方式进行地址翻译和数据传输：提出了通过寄存器的方式来对现有基于页表的地址翻译过程进行扩展。这段寄存器翻译的扩展能够保证始终TLB命中，并且将大数据传输变成了寄存器交接的过程。
2.基于MMU的扩展，避免对于处理器核心的大幅度改动：接力段内存的扩展在MMU和TLB的基础上完成。可以在避免对处理器核心的过多修改。
三、软件(内核和用户态库)协同的IPC上下文切换实现，通过分离的线程上下文模型和IPC管理模块实现基于硬件扩展的IPC接口，大幅度提高应用程序性能。
1.软件提供的灵活安全配置方案：硬件原语只提供基础的切换功能，然而其安全策略仍 然由内核软件来维护。这样的分离能够保证内核对于IPC的灵活管理，达到和传统方案相同的安全级别。
2.硬件和内核共同维护调用栈机制：硬件原语会将调用链的信息记入调用栈(link stack)。内核可以通过调用栈回溯处理IPC异常机制；
3.根据信任级别决定用户态的保存/恢复的状态：硬件原语只负责核心的上下文切换(如页表)，而用户态寄存器等交给用户态库自己维护。相比传统的通过内核的方式(会固定将所有的相关寄存器保存)，该方案允许用户态根据IPC远端的服务进程进行选择性地保存状态。
如果远端服务进程可信：那么客户端可以只选择保存少量的状态，和传统的函数调用相似
如果远端不可信，那么客户端可以选择和内核维护的方式相同，保存所有的状态
4.服务端动态扩展机制：硬件原语允许多个客户端同时调用过一个客户端。通过在软件层支持re-entrant的工作线程分配方法，可以实现服务端线程动态扩展的功能，达到重用客户端的调度上下文的目的。
四、软件(内核和用户态库)协同的安全零拷贝传输，通过维护接力段内存的一致性/唯一性，避免如TOCTTOU这样的安全风险。
1.接力段内存实现跨链的零拷贝数据传输：通过多实体协调，确定下来最大的接力段内存传输区间，并且结合接力段内存的遮盖(mask)机制，实现跨多实体的安全零拷贝数据传输；
2.权限转移(ownership transfer)特性支持：内核通过维护接力段内存的虚拟地址区间以及接力段内存的物理区间的唯一性，来实现接力段内存交接过程中的权限转移特性。
请参考图18，为本实施例提供的一种计算机系统的结构示意图。该计算机系统可以为智能手机、应用于无人驾驶汽车的自动驾驶设备等。如图所示，该计算机系统包括通信模块510、传感器520、用户输入模块530、输出模块540、处理器550、音视频输入模块560、存储器570以及电源580。
通信模块510可以包括至少一个能使该计算机系统与通信系统或其他计算机系统之间进行通信的模块。例如，通信模块510可以包括有线网络接口、广播接收模块、移动通信模块、无线因特网模块、局域通信模块和位置(或定位)信息模块等其中的一个或多个。这多种模块均在现有技术中有多种实现，本实施例不再一一描述。
传感器520可以感测系统的当前状态，诸如打开/闭合状态、位置、与用户是否有接触、方向、和加速/减速，并且传感器520可以生成用于控制系统的操作的感测信号。
用户输入模块530，用于接收输入的数字信息、字符信息或接触式触摸操作/非接触式手势，以及接收与系统的用户设置以及功能控制有关的信号输入等。用户输入模块530包括触控面板和/或其他输入设备。
输出模块540包括显示面板，用于显示由用户输入的信息、提供给用户的信息或系统的各种菜单界面等。可选的，可以采用液晶显示器(liquid crystal display，LCD)或有机发光二极管(organic light-emitting diode,OLED)等形式来配置显示面板。在其他一些实施例中，触控面板可覆盖显示面板上，形成触摸显示屏。另外，输出模块540还可以包括音频输出模块、 告警器以及触觉模块等。
音视频输入模块560，用于输入音频信号或视频信号。音视频输入模块560可以包括摄像头和麦克风。
电源580可以在处理器550的控制下接收外部电力和内部电力，并且提供系统的各个组件的操作所需的电力。
处理器550可以指示一个或多个处理器，例如，处理器550可以包括一个或多个中央处理器，或者包括一个中央处理器和一个图形处理器，或者包括一个应用处理器和一个协处理器(例如微控制单元或神经网络处理器)。当处理器550包括多个处理器时，这多个处理器可以集成在同一块芯片上，也可以各自为独立的芯片。一个处理器可以包括一个或多个物理核，其中物理核为最小的处理单元。
本实施例提供的XPC引擎551(也可以称进程间通信引擎，或简称通信引擎)设置在处理器550上。具体的，XPC引擎551可以与处理器550集成在一块芯片上，或者与处理器设置在一块单板上。在其他实施例中，XPC引擎551还可以与处理器550通过其它非图示的方式连接。XPC引擎的具体实现可参考前述实施例，在此不再赘述。
存储器570存储计算机程序，该计算机程序包括操作系统程序572和应用程序571等。典型的操作系统如seL4、L4、或谷歌公司提供的Fuchsia等微内核操作系统；又如微软公司的Windows，苹果公司的MacOS等用于台式机或笔记本的系统；又如谷歌公司开发的基于
Figure PCTCN2020090559-appb-000003
的安卓
Figure PCTCN2020090559-appb-000004
系统等用于移动终端的系统等。
存储器570可以是以下类型中的一种或多种：闪速(flash)存储器、硬盘类型存储器、微型多媒体卡型存储器、卡式存储器(例如SD或XD存储器)、随机存取存储器(random access memory,RAM)、静态随机存取存储器(static RAM,SRAM)、只读存储器(read only memory,ROM)、电可擦除可编程只读存储器(electrically erasable programmable read-only memory，EEPROM)、可编程只读存储器(programmable ROM,PROM)、磁存储器、磁盘或光盘。在其他一些实施例中，存储器570也可以是因特网上的网络存储设备，系统可以对在因特网上的存储器570执行更新或读取等操作。
处理器550用于读取存储器570中的计算机程序，然后执行计算机程序定义的方法，例如处理器550读取操作系统程序572从而在该系统运行操作系统以及实现操作系统的各种功能，或读取一种或多种应用程序571，从而在该系统上运行应用。本申请提供的XPC方案如果用软件形式实现，就可以以计算机程序的方式存储在存储器570中，由处理器550读取并执行。
存储器570还存储有除计算机程序之外的其他数据573，例如本申请中涉及的x-entrytable、link stack、relay segment list等。
图18中各个模块的连接关系仅为一种示例，本申请任意实施例提供的方法也可以应用在其它连接方式的终端设备中，例如所有模块通过总线连接。图18中各个模块的划分仅是逻辑上的划分，并不代表硬件上一定是分开的。图18中各个模块在本申请的其他实施例中未必是必要的。
另外，本申请还提供与本申请提供的方案相关的存储介质、计算机程序产品、计算机程序等。具体实现可参考前述实施例。
为完整描述本申请的方案，本申请将实现方式分开多个部分介绍，为了更好地让读者理解本申请的方案，本申请也提供了不同的案例来说明整个方案。应理解的是，各个部分之间存在一些关联，相互关联的实现可相互参考。案例与各个部分的实现之间存在一些重复，也可以相互参考，但这并不意味着某种案例一定要按照某种过程来实现。
需要说明的是，为了方便应用和理解，本申请实施例为提到的一些系统、模块、器件、元素、数据结构以及指令等进行了命名，这些命名的大写或小写在无特殊说明的情况下均是相同的含义。同时，这些命名可以根据需求变更，不应作为对本申请所提供方案的限定。
需要说明的是，本实施例提供的方案可以应用于终端设备或服务器等。这里的终端设备包括但不限于智能手机、车载装置(例如自动驾驶设备)、个人计算机、人工智能设备、平板电脑、个人数字助理、智能穿戴式设备(例如智能手表或手环、智能眼镜)、智能语音设备(例如智能音箱等)、虚拟现实/混合现实/增强显示设备或网络接入设备(例如网关等)等。服务器可以包括存储服务器或计算服务器等。
需要说明的是，前述实施例中提出模块或单元的划分仅作为一种示例性的示出，所描述的各个模块的功能仅是举例说明，本申请并不以此为限。本领域普通技术人员可以根据需求合并其中两个或更多模块的功能，或者将一个模块的功能拆分从而获得更多更细粒度的模块，以及其他变形方式。
以上描述的各个实施例之间相同或相似的部分可相互参考。本申请中的“多个”若无特殊说明，指两个或两个以上，或“至少两个”。本申请中的“A/B”包括三种情况：“A”、“B”和“A和B”。本申请中一个对象的“标识(id)”指的是唯一标识该对象的信息，该“标识”可以直接标识该对象，例如对象的名称，也可以间接指示该对象，例如对象的存储地址。本申请中“第一”、“第二”、“第三”等仅为了区分表述，没有限定顺序的意思；另外，第一对象和第二对象在某些情况下有可能合并或指同一对象；再者，由于没有限定顺序，所以没有第一，也可以有第二或第三。
以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本申请提供的装置实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上所述，仅为本申请的一些具体实施方式，但本申请的保护范围并不局限于此。

Claims (29)

  1. 一种进程间通信的方法，其特征在于，所述方法应用于计算机设备，所述计算机设备包括硬件层以及运行在所述硬件层上的操作系统，所述操作系统上运行有待通信的调用者和被调用者，所述计算机设备还包括通信引擎；所述方法包括：
    所述调用者调用第一指令，所述第一指令由所述通信引擎执行以实现从所述调用者的上下文到所述被调用者的上下文的切换；或者
    所述被调用者调用第二指令，所述第二指令由所述通信引擎执行以实现从所述被调用者的上下文到所述调用者的上下文的切换。
  2. 根据权利要求1所述的方法，其特征在于，所述通信引擎执行所述第一指令实现上下文切换的过程包括：
    根据所述第一指令中的被调用者标识确定所述被调用者的上下文；
    保存所述调用者的上下文；
    切换到所述被调用者的上下文。
  3. 根据权利要求2所述的方法，其特征在于，所述通信引擎在执行所述第一指令时还包括：
    获取所述调用者的能力信息，所述能力信息用于指示所述调用者是否有权限调用所述被调用者；
    当根据所述能力信息确定所述调用者有权限调用所述被调用者时，执行所述上下文切换的过程。
  4. 根据权利要求1-3任意一项所述的方法，其特征在于，在所述调用者调用第一指令之前，所述方法还包括：保存所述调用者的上下文，所述上下文为所述调用者的部分上下文。
  5. 根据权利要求2-4任意一项所述的方法，其特征在于，所述通信引擎执行所述第二指令实现上下文切换的过程包括：
    读取保存的所述调用者的上下文，并切换到所述调用者的上下文。
  6. 根据权利要求1-5任意一项所述的方法，其特征在于，所述方法还包括：
    所述调用者申请内存区域，并将所述内存区域的地址设置在所述通信引擎包含的寄存器中；
    所述调用者将待传输给所述被调用者的数据存储在所述内存区域中，所述被调用者用于通过所述寄存器中存储的地址来访问所述内存区域以获得所述数据。
  7. 一种实现进程间通信的方法，其特征在于，所述方法包括：
    接收调用者发送的第一指令，所述第一指令中包含被调用者的标识；
    根据所述被调用者标识在第一寄存器指示的服务集合中确定所述被调用者的上下文，所 述第一寄存器用于存储所述服务集合的内存地址，所述服务集合包括一个或多个被调用者的上下文信息；
    将所述调用者的上下文保存在第二寄存器指示的返回信息集合中，所述第二寄存器用于存储所述返回信息集合的内存地址，所述返回信息集合包括一个或多个调用者的上下文信息；
    切换到所述被调用者的上下文。
  8. 根据权利要求7所述的方法，其特征在于，在所述根据所述被调用者标识在第一寄存器指示的服务集合中确定所述被调用者的上下文之前，所述方法还包括：
    根据第三寄存器指示的能力信息确定所述调用者有权限调用所述被调用者，所述第三寄存器用于存储所述能力信息的地址，所述能力信息用于指示所述调用者是否有权限调用所述被调用者。
  9. 根据权利要求7或8所述的方法，其特征在于，还包括：
    将以下信息中的任意一项或两项预取到缓存中：所述服务集合中包括的一个或多个被调用者的上下文信息、或所述能力信息。
  10. 根据权利要求7-9任意一项所述的方法，其特征在于，采用异步的方式执行以下步骤：将所述调用者的上下文保存在第二寄存器指示的返回信息集合中。
  11. 根据权利要求7-10任意一项所述的方法，其特征在于，所述被调用者的上下文的确定步骤或所述调用者的上下文的保存步骤采用被标记的转换检测缓冲区TLB实现。
  12. 根据权利要求7-11任意一项所述的方法，其特征在于，所述方法还包括：
    将第四寄存器指示的内存区域的访问权限赋予所述被调用者，其中，所述第四寄存器用于存储所述内存区域的地址信息，所述内存区域是所述调用者申请的，所述内存区域用于存储所述调用者待传输给所述被调用者的数据。
  13. 根据权利要求7-11任意一项所述的方法，其特征在于，所述方法还包括：
    将第四寄存器和第五寄存器指示的第二内存区域的访问权限赋予所述被调用者，其中所述第四寄存器用于存储第一内存区域的地址信息，所述第五寄存器则存储有用于缩小所述第一内存区域的信息，所述第二内存区域为缩小后的第一内存区域。
  14. 根据权利要求7-13任意一项所述的方法，其特征在于，所述方法还包括：
    接收所述被调用者发送的第二指令，所述第二指令用于指示返回所述调用者的上下文；
    从所述第二寄存器指示的所述返回信息集合中获取所述调用者的上下文；
    切换到所述调用者的上下文。
  15. 根据权利要求7-14任意一项所述的方法，其特征在于，保存的所述调用者的上下文为选择的所述调用者的部分上下文。
  16. 一种内存管理方法，其特征在于，所述方法包括：
    接收虚拟地址；
    确定所述虚拟地址是否在接力段内存的虚拟地址区间内，所述接力段内存的虚拟地址区间、物理地址区间以及所述虚拟地址区间和所述物理地址区间的映射关系存储在接力段寄存器中；
    当确定所述虚拟地址在接力段内存的虚拟地址区间内时，根据所述接力段寄存器中存储的所述映射关系确定所述虚拟地址对应的物理地址。
  17. 一种进程间通信的管理方法，其特征在于，所述方法包括：
    接收服务端的服务注册请求，所述服务注册请求用于请求注册服务；
    根据第一寄存器中的地址信息将所述服务的上下文信息保存在第一存储区域，所述地址信息指示所述第一存储区域。
  18. 根据权利要求17所述的方法，其特征在于，所述方法还包括：
    接收对客户的授权请求，该授权请求用于请求将服务的调用权限授权给所述客户；
    当确定所述客户有权限调用所述服务时，将所述客户的能力信息设置为指示所述客户有权限调用所述服务，所述能力信息存储在第三存储区域，所述第三存储区域的地址信息存储在第三寄存器中。
  19. 根据权利要求17-18任意一项所述的方法，其特征在于，所述方法还包括：
    接收异常；
    当确定所述异常为客户与服务端进行通信的通信异常时，从返回信息集合中读取客户的上下文信息，所述返回信息集合包括一个或多个客户的上下文信息，所述返回信息集合存储在第二存储区域，所述第二存储区域的地址信息存储在第二寄存器中；
    根据所述客户的上下文信息执行恢复操作。
  20. 根据权利要求19所述的方法，其特征在于，所述从返回信息集合中读取客户的上下文信息，包括：
    根据所述第二寄存器中存储的所述第二存储区域的地址信息从所述第二存储区域中读取所述返回信息集合中与所述客户对应的上下文信息。
  21. 一种内存分配方法，其特征在于，包括：
    响应于内存申请请求，确定待分配的物理内存区域是否和已分配的物理内存区域存在交集；
    当确定所述待分配的物理内存区域和所述已分配的物理内存区域不存在交集时，将所述 待分配的物理内存区域标记为已分配；
    分配虚拟内存区域，将所述待分配的物理内存区域和所述虚拟内存区域的映射关系保存在第四寄存器中；
    返回所述虚拟内存区域的地址。
  22. 根据权利要求21所述的方法，其特征在于，当确定所述待分配的物理内存区域和所述已分配的物理内存区域不存在交集时，将所述待分配的物理内存区域标记为已分配包括：
    当确定所述待分配的物理内存区域和所述已分配的物理内存区域不存在交集，且确定当前正在使用的物理内存区域与所述分配的物理内存区域不存在交集时，将所述待分配的物理内存区域标记为已分配。
  23. 根据权利要求21或22所述的方法，其特征在于，还包括：
    响应于内存释放请求，清空所述第四寄存器。
  24. 一种计算机设备，其特征在于，所述计算机设备包括硬件层以及运行在所述硬件层上的操作系统，所述操作系统上运行有待通信的调用者和被调用者，所述计算机设备还包括通信引擎，所述通信引擎用于执行如权利要求7-15任意一项所述的方法。
  25. 一种进程间通信的装置，其特征在于，所述装置包括：
    第一单元，用于接收调用者发送的第一指令，所述第一指令中包含被调用者的标识；
    第二单元，用于根据所述被调用者标识在第一寄存器指示的服务集合中确定所述被调用者的上下文，所述第一寄存器用于存储所述服务集合的内存地址，所述服务集合包括一个或多个被调用者的上下文信息；
    第三单元，用于将所述调用者的上下文保存在第二寄存器指示的返回信息集合中，所述第二寄存器用于存储所述返回信息集合的内存地址，所述返回信息集合包括一个或多个调用者的上下文信息；
    第四单元，用于切换到所述被调用者的上下文。
  26. 一种进程间通信的装置，其特征在于，所述装置包括处理器核和多个寄存器，其中所述处理器核用于执行如权利要求7-15任意一项所述的方法。
  27. 一种内存管理单元MMU，其特征在于，所述内存管理单元包括：
    第一模块，用于接收虚拟地址；
    第二模块，用于确定所述虚拟地址是否在接力段内存的虚拟地址区间内，所述接力段内存的虚拟地址区间、物理地址区间以及所述虚拟地址区间和所述物理地址区间的映射关系存储在接力段寄存器中；
    第三模块，用于当确定所述虚拟地址在接力段内存的虚拟地址区间内时，根据所述接力 段寄存器中存储的所述映射关系确定所述虚拟地址对应的物理地址。
  28. 一种计算机存储介质，其特征在于，所述计算机存储介质用于存储计算机程序，当所述计算机程序被一个或多个处理器执行时实现如权利要求17-23任意一项所述的方法。
  29. 一种计算机程序产品，其特征在于，所述计算机程序产品用于存储计算机程序，当所述计算机程序被一个或多个处理器执行时实现如权利要求17-23任意一项所述的方法。
PCT/CN2020/090559 2019-06-03 2020-05-15 进程间通信的方法、装置以及计算机设备 WO2020244369A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CA3142633A CA3142633A1 (en) 2019-06-03 2020-05-15 Method and apparatus for inter-process communication, and computer device
EP20818952.2A EP3968160A4 (en) 2019-06-03 2020-05-15 INTER-PROCESS COMMUNICATION METHOD AND DEVICE AND COMPUTER DEVICE
US17/540,948 US20220091911A1 (en) 2019-06-03 2021-12-02 Method and apparatus for inter-process communication, and computer device

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN201910478125 2019-06-03
CN201910478125.8 2019-06-03
CN201910563535.2A CN112035272A (zh) 2019-06-03 2019-06-26 进程间通信的方法、装置以及计算机设备
CN201910563535.2 2019-06-26

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/540,948 Continuation US20220091911A1 (en) 2019-06-03 2021-12-02 Method and apparatus for inter-process communication, and computer device

Publications (1)

Publication Number Publication Date
WO2020244369A1 true WO2020244369A1 (zh) 2020-12-10

Family

ID=73576232

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/090559 WO2020244369A1 (zh) 2019-06-03 2020-05-15 进程间通信的方法、装置以及计算机设备

Country Status (5)

Country Link
US (1) US20220091911A1 (zh)
EP (1) EP3968160A4 (zh)
CN (1) CN112035272A (zh)
CA (1) CA3142633A1 (zh)
WO (1) WO2020244369A1 (zh)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113220469B (zh) * 2021-03-23 2024-04-16 黑芝麻智能科技(上海)有限公司 进程间通信方法、装置和计算机设备和计算机可读介质
WO2022268142A1 (zh) * 2021-06-23 2022-12-29 华为技术有限公司 一种服务进程的调用方法及相关装置
CN115904502A (zh) * 2021-08-18 2023-04-04 华为技术有限公司 虚拟机管理方法及相关系统、存储介质
CN113704007B (zh) * 2021-09-14 2023-11-07 上海交通大学 利用硬件特性的无服务器计算平台加速系统
US11886877B1 (en) * 2021-09-24 2024-01-30 Apple Inc. Memory select register to simplify operand mapping in subroutines
CN115878343A (zh) * 2021-09-29 2023-03-31 华为技术有限公司 一种进程间通信方法及相关装置
CN114020330B (zh) * 2021-11-04 2023-11-03 苏州睿芯集成电路科技有限公司 Risc-v处理器验证中模式切换的方法、电子设备以及存储介质
CN114781322B (zh) * 2022-04-24 2023-04-25 苏州睿芯集成电路科技有限公司 Cpu芯片仿真加速中针对无mmu环境的内存状态恢复方法
WO2024050804A1 (en) * 2022-09-09 2024-03-14 Qualcomm Incorporated Dynamically varying time slice periods in a computer processor unit
CN115913579B (zh) * 2023-02-21 2023-06-13 飞天诚信科技股份有限公司 一种智能卡证书的注册应用方法及装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050182966A1 (en) * 2004-02-17 2005-08-18 Duc Pham Secure interprocess communications binding system and methods
CN103440169A (zh) * 2013-08-21 2013-12-11 华为技术有限公司 一种进程中断处理的方法及装置
CN105068859A (zh) * 2015-07-29 2015-11-18 上海谐桐信息技术有限公司 一种跨虚拟机的多服务调用方法及系统
CN106203082A (zh) * 2016-06-29 2016-12-07 上海交通大学 基于虚拟化硬件特性的高效隔离内核模块的系统及方法
CN108469986A (zh) * 2017-02-23 2018-08-31 华为技术有限公司 一种数据迁移方法及装置

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7072457B2 (en) * 2001-12-17 2006-07-04 International Business Machines Corporation Transferring a call to a backup according to call context
US7085918B2 (en) * 2003-01-09 2006-08-01 Cisco Systems, Inc. Methods and apparatuses for evaluation of regular expressions of arbitrary size
US7689971B2 (en) * 2004-08-09 2010-03-30 Intel Corporation Method and apparatus for referencing thread local variables with stack address mapping
US20060253605A1 (en) * 2004-12-30 2006-11-09 Prabakar Sundarrajan Systems and methods for providing integrated client-side acceleration techniques to access remote applications
US8549149B2 (en) * 2004-12-30 2013-10-01 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP multiplexing
WO2006069484A1 (en) * 2004-12-30 2006-07-06 Intel Corporation Methods and apparatuses to maintain multiple execution contexts
US7739731B2 (en) * 2006-01-09 2010-06-15 Oracle America, Inc. Method and apparatus for protection domain based security
US8151323B2 (en) * 2006-04-12 2012-04-03 Citrix Systems, Inc. Systems and methods for providing levels of access and action control via an SSL VPN appliance
US7512768B2 (en) * 2006-07-21 2009-03-31 Intel Corporation Dynamically sharing a stack between different code segments
CN101470667A (zh) * 2007-12-28 2009-07-01 英业达股份有限公司 Linux系统平台上指定地址范围分配物理内存的方法
US9569612B2 (en) * 2013-03-14 2017-02-14 Daniel Shawcross Wilkerson Hard object: lightweight hardware enforcement of encapsulation, unforgeability, and transactionality
US9747218B2 (en) * 2015-03-20 2017-08-29 Mill Computing, Inc. CPU security mechanisms employing thread-specific protection domains
US20160378545A1 (en) * 2015-05-10 2016-12-29 Apl Software Inc. Methods and architecture for enhanced computer performance

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050182966A1 (en) * 2004-02-17 2005-08-18 Duc Pham Secure interprocess communications binding system and methods
CN103440169A (zh) * 2013-08-21 2013-12-11 华为技术有限公司 一种进程中断处理的方法及装置
CN105068859A (zh) * 2015-07-29 2015-11-18 上海谐桐信息技术有限公司 一种跨虚拟机的多服务调用方法及系统
CN106203082A (zh) * 2016-06-29 2016-12-07 上海交通大学 基于虚拟化硬件特性的高效隔离内核模块的系统及方法
CN108469986A (zh) * 2017-02-23 2018-08-31 华为技术有限公司 一种数据迁移方法及装置

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
CN112035272A (zh) 2020-12-04
CA3142633A1 (en) 2020-12-10
EP3968160A1 (en) 2022-03-16
US20220091911A1 (en) 2022-03-24
EP3968160A4 (en) 2022-06-01

Similar Documents

Publication Publication Date Title
WO2020244369A1 (zh) 进程间通信的方法、装置以及计算机设备
US9589132B2 (en) Method and apparatus for hypervisor based monitoring of system interactions
CN108475217B (zh) 用于审计虚拟机的系统及方法
US10255088B2 (en) Modification of write-protected memory using code patching
CA2761563C (en) Annotating virtual application processes
US10176007B2 (en) Guest code emulation by virtual machine function
US10409633B2 (en) Hypervisor-visible guest thread management
US10083129B2 (en) Code loading hardening by hypervisor page table switching
US9733976B2 (en) Method and apparatus for SYSRET monitoring of system interactions
US10489185B2 (en) Hypervisor-assisted approach for locating operating system data structures based on attribute matching
US10664304B2 (en) Application memory protection using an extended page table switching virtual machine function
US11734048B2 (en) Efficient user space driver isolation by shallow virtual machines
US20180267818A1 (en) Hypervisor-assisted approach for locating operating system data structures based on notification data
US11237963B2 (en) Shared filesystem metadata caching
WO2023123850A1 (zh) 一种固件可信根的实现方法、装置、设备和可读存储介质
US20170168865A1 (en) Method and Apparatus for Hypervisor Based Monitoring of System Interactions
US20220335109A1 (en) On-demand paging support for confidential computing
CN113791898B (zh) 一种基于TrustZone的可信微内核操作系统
US11960420B2 (en) Direct memory control operations on memory data structures
WO2021088744A1 (zh) 能力的管理方法和计算机设备
CN113961366A (zh) 操作系统的内核函数调用方法及计算机设备
WO2022022708A1 (zh) 一种进程间通信的方法、装置及计算机存储介质
US20230409321A1 (en) Security vulnerability mitigation using address space co-execution
EP4372551A1 (en) Virtual machine management method and related system, and storage medium
US20240070260A1 (en) Process Credential Protection

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: 20818952

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 3142633

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2020818952

Country of ref document: EP

Effective date: 20211208