CN113939805A

CN113939805A - Method and system for interprocess communication

Info

Publication number: CN113939805A
Application number: CN202080001704.4A
Authority: CN
Inventors: 张建永
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2020-04-29
Filing date: 2020-04-29
Publication date: 2022-01-14
Also published as: WO2021217529A1

Abstract

A method and a system for interprocess communication are provided, the system comprises: the IPC engine hardware is used for storing the data to be transmitted required by interprocess communication and establishing a page table; running a client process, and sending a calling instruction to IPC engine hardware, wherein the calling instruction comprises an identifier of a server process and a virtual address of data to be transmitted; the physical address of the data to be transmitted is positioned in the shared memory space; the IPC engine hardware is used for indicating the processor core to run the server process; the processor core runs a server process, and the server process queries a page table according to the virtual address of the data to be transmitted to obtain the data to be transmitted so as to execute service; and, sending a return instruction to the IPC engine hardware; the IPC engine hardware is used to instruct the processor core to resume running the client process. Therefore, IPC time delay can be reduced, data transmission efficiency is improved, and performance is improved.

Description

Method and system for interprocess communication

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method, a related device, and a system for interprocess communication.

Background

Software systems, such as Linux, allocate and manage resources in units of processes. In user space, one process cannot directly access another process's resources. However, in practical applications, multiple processes are usually required to complete a task together, which requires Inter-process communication (IPC) as a communication mechanism between the processes. IPC is a technique for transferring data or signals between at least two processes. A process is a unit of a computing device that allocates resources, and processes may run on the same computing device or on different computing devices connected to a network. Each process corresponds to a part of independent system resources and is isolated from each other, and different processes can access the resources mutually and carry out coordination work through an IPC mechanism.

Conventionally, Linux-based IPC mechanisms include pipe (pipe) communication, signal communication, message queues, sockets (socket), and the like. Android (android) Linux-based kernels provide further optimized IPC mechanisms: IPC binder. The binder is a communication mechanism based on a Client-server (CS) mode, and all clients obtain services of a server through centralized binder driving.

The performance of the IPC is a key factor affecting the overall performance of the computing device, for example, for android, a process of a user space needs to frequently interact with a large number of services (services) of the user space, and the delay performance of the IPC also directly affects the user experience.

For example, referring to fig. 1, the core of the existing Binder mechanism is to run a Binder driver at a kernel layer, and since resource sharing can be performed in a kernel space in the system, the Binder driver has a strong cross-process access capability, and the Binder driver assumes a media role of IPC communication between a process (caller) of a client (client) and a process (caller) of a server (server). The user-state caller process requests kernel service through a system call function, and the caller process is trapped in a kernel state to complete context switching, namely, the user state needs to be switched to the kernel state. Then, copying IPC message data is completed, the message data is copied from the user space of the client to the kernel space, and the server serves as a data receiving end to share data with the kernel, so that the data does not need to be copied. The entire IPC process only needs one memory copy to pass the message data to the callee. Then, the kernel switches to the context of the caller in the user state to complete the service response, and finally returns by calling the function "reply ()", and the kernel restores the state of the caller process.

In the Binder mechanism, on one hand, the kernel needs to allocate execution time to complete the switching between the kernel mode and the user mode of the process and the saving/recovering process of the process context, so that the CPU cycle occupied by the IPC process can be as long as 00 cycles, and the delay overhead is large. On the other hand, a copy process is inevitably required in message data transmission, which affects data transmission efficiency. When some existing solutions attempt to overcome the above drawbacks, it is often necessary to change an address access flow of a Memory Management Unit (MMU) in the existing standard, and it is difficult to popularize and apply the existing standard-compliant product.

Disclosure of Invention

The application provides a method, related equipment and system for interprocess communication, which can reduce IPC time delay, improve data transmission efficiency and improve performance.

In a first aspect, the present application provides a hardware system for inter-process communication IPC, the system comprising: processor core, IPC engine hardware, and memory, wherein: the processor core is used for configuring a part of memory space in the memory into shared memory space of a process when the IPC engine hardware is initialized, and the shared memory space is used for storing data to be transmitted required by interprocess communication; establishing a page table according to the initial address and the length of the shared memory space, wherein the page table comprises a mapping relation from a virtual address to a physical address of the shared memory space; the processor core is further configured to run a client process (e.g., a caller), and when the client process needs to call a service of a server process (e.g., a caller), send a first processor instruction (e.g., ipccall described in the specification) to the IPC engine hardware, where the first processor instruction is a call instruction of the client process to the service, and the call instruction includes an identifier of the server process and a virtual address of data to be transferred; the physical address of the data to be transmitted is positioned in the shared memory space; the IPC engine hardware is used for indicating the processor core to run the server process according to the identifier and sending the virtual address of the data to be transmitted to the server process; the processor core is further configured to run the server process, and the server process queries the page table according to the virtual address of the data to be transmitted to obtain the data to be transmitted so as to execute the service; and sending a second processor instruction (e.g., an ipret as described in the specification) to the IPC engine hardware, the second processor instruction being a return instruction for the server process; the IPC engine hardware is further configured to instruct the processor core to resume running the client process according to the second processor instruction.

The attributes of the client process and the server process may be processes or threads.

It can be seen that the embodiment of the present application can transfer the context information saving, context switching and restoring, data transfer, etc. in the user state from time to space to a new physical entity (i.e. IPC engine) for implementation. The IPC engine serves as a medium of the IPC and provides corresponding user mode instructions ipccall and ipcret, so that the CALLER and the CALLE can complete context switching in the user mode without switching to the kernel mode, the requirements for calling of the CALLER and callback of the CALLE are met, interaction of a process in the user mode is achieved, the IPC engine can work with kernel software in parallel, and the whole time delay of the IPC process is greatly reduced. In addition, in the embodiment of the application, the data access right can be transmitted through the IPC engine, only the virtual address of the data needs to be transmitted to the caller, and the data does not need to be transmitted, so that copying (copy) of the data is avoided, the time delay of data copying is further reduced, and the data transmission efficiency is improved.

In addition, during system initialization (IPC engine initialization), the operating system running in the processor core reserves (or configures) a part of the memory in the physical memory as the shared memory of the caller and the caller. That is, in the embodiment of the present application, the shared memory is fixedly reserved and allocated at the time of initialization of the IPC engine, and the shared memory is not in the page management table of the kernel (e.g., kernel). This portion of shared memory is directly accessible by the IPC engine. The shared memory may be used to hold data that needs to be transferred between processes during IPC communications. By reserving the shared memory, a special page table (the page table contains the mapping relation between the virtual address and the physical address) can be established, and the data to be transmitted is ensured to have a corresponding physical page all the time, so that the page missing error is avoided, and the system performance is improved.

After the shared memory is allocated, when the callee registers in the IPC engine, the callee can establish a page table of the process according to the starting Address and the length (size) of the shared memory and add the page table into the MMU, where the page table globally defines a mapping relationship between a Virtual Address (VA) and a Physical Address (PA) of the shared memory, and the scheme of the embodiment of the present application can also implement that after the IPC engine is initialized, the operating system allocates the shared memory, and the callee establishes the page table of the process after initiating the registration and is managed by the MMU, thereby achieving the purpose of sharing the memory by the calller and the callee, avoiding the change of the existing MMU working flow, avoiding the occurrence of page fault, and ensuring the stability and security of IPC communication.

Based on the first aspect, in a possible embodiment, the processor core is further configured to, when the client process needs to invoke a service of the server process, configure a part of the memory space in the shared memory space to the client process, so as to store the data to be transferred.

By implementing the embodiment of the application, when a caller needs to call a caller service, an operating system performs memory allocation on the caller based on the shared memory, namely, allocates a part of memory space in the shared memory to the caller to store data to be transferred (msg), namely, the operating system allocates a memory segment for storing generation transfer data (msg) to the caller in the shared memory, and a mapping relationship between a virtual address and a physical address of the msg in the memory segment is consistent with a mapping relationship recorded in the page table managed by the MMU, so that, in subsequent IPC communication, after the msg VA is transferred from the caller to the caller by the IPC engine, the caller can access the page table to obtain the data according to the VA, thereby achieving the purpose of sharing the memory of the caller and the caller, avoiding the change of the existing MMU workflow, avoiding the occurrence of page fault, and ensuring the stability and security of IPC communication.

Based on the first aspect, in a possible embodiment, before running the client process, the processor core is further configured to send registration information of the server process to the IPC engine hardware, where the registration information includes the identifier; the IPC engine hardware is further to: receiving the registration information; saving the identification and the entry address of the server process in the IPC engine hardware in response to the registration information; the IPC engine hardware is specifically configured to: finding the entry address according to the identification; setting the entry address to a Program Counter (PC) in the processor core; the processor core is further configured to run the server process according to the entry address set in the PC.

The IPC engine hardware can comprise a callee register set, wherein the callee register set comprises a set of registers and is used for recording indication information of context information of callees. The CALLE register set is specifically used for recording entry addresses (CALLE entry addresses) of a plurality of CALLEs, and each CALLE entry address corresponds to context information of one CALLE. In one embodiment, the call entry address includes an address pointer of a call service function, which may be a Callback function (Callback function). The IPC engine may set a Program Counter (PC) in the CPU to the call entry address, so that the CPU starts executing the call process context and runs the call to execute the corresponding service.

Further, the CALLE register set further includes a first address register and a count register, where the first address register is used to store a first address of the CALLE list, and specifically, may be a first CALLE entry address in the CALLE list. The count register is used to record the number of the call entry addresses (entry size), and specifically, each time a list entry (i.e., a call entry address) is added to a call list, the number of records in the count register is added by 1. Thus, the entry addresses (the call entry addresses) of a plurality of calls can be recorded to the call list according to the registration condition of the plurality of calls by the call register set. In a specific implementation, each list entry of the callerelist may be configured to correspond to an index Identification (ID). The index ID may be the cause process ID (i.e., the cause ID), or the index ID may be mapped one-to-one with the process ID, which may be determined after registration of the cause with the IPC engine. In this way, IPC of a client process (caller) with one or more callers may be facilitated.

It can be seen that, by using the IPC engine in the embodiments of the present application, context information storage, context switching, or data transfer in the user state can be realized, and the kernels in these processes are not aware of each other (i.e., the IPC process may not need the kernel to participate in the process), thereby avoiding the drawback of frequent switching between the user state and the kernel state in the existing IPC mechanism (e.g., binder mechanism), and disengaging the IPC process of the process from the kernel, thereby releasing a large amount of software execution time of the CPU, and greatly reducing the overall time delay of the IPC process.

Based on the first aspect, in a possible embodiment, the IPC engine hardware is further configured to, after receiving the call instruction, query a status register in the processor core to obtain a call stack address of the client process, and save the call stack address of the client process in the IPC engine hardware; the IPC engine hardware is specifically configured to call the call stack address according to the second processor instruction, and instruct the processor core to resume running the client process according to the call stack address.

Specifically, the IPC engine hardware may include a link register, where the link register is used to store the entry address of the current caller, and the entry address of the caller corresponds to the context information of the caller. In particular, the link register may hold the call stack address of the current caller, which is associated with the context information of the caller, to record the call behavior of the current trigger. After a calling instruction (ipccall) is initiated by a caller, an IPC logic circuit of an IPC engine queries a state register in a CPU, and can know which caller initiates the call by querying the state of the latest saved caller in the state register, so that the calling stack address of the caller can be saved to a link register. When the CALLE completes the execution of the service, the link register can pop up the record of the current CALLER, and process switching (namely, the CPU is switched from the context of the CALLE to the context of the CALLER) is realized so as to recover the process of the CALLER. The CALLE register set and the link register provided by the embodiment of the application can realize the context switching process of the process in hardware, so that the software execution time of a CPU is released, and the time delay of an IPC process is reduced.

Based on the first aspect, in a possible embodiment, the IPC engine hardware is specifically configured to check whether the client process and the server meet requirements for inter-process communication, and instruct the processor core to run the server process according to the identifier when the client process and the server meet requirements for inter-process communication. The execution of the embodiment ensures that the IPC engine hardware provided by the application is safer and more reliable.

For example, the IPC engine may perform at least one of the following conditional checks by the IPC logic:

1) it is checked whether the caller and the caller are at different execution levels.

2) Checking whether the caller and the caller are in the same processor core (core), the IPC logic circuit can decide whether the process context information needs to be migrated according to whether the process is in the same core.

3) The security authority of the caller is checked to determine if the caller has authority to invoke the service of the caller.

4) And checking whether the relevant parameters carried by the calling instruction meet the length requirement.

Based on the first aspect, in a possible embodiment, the call instruction and the return instruction are both user-mode instructions. Therefore, the calling of the caller service and the callback of the caller are met, the interaction of the process on the user mode level is realized, the defect that the user mode and the kernel mode are frequently switched in the existing IPC mechanism (such as a binder mechanism) is avoided, the IPC engine and the CPU work in parallel on the hardware without switching to the kernel mode on the software.

Based on the first aspect, in a possible embodiment, when a caller needs to initiate ipccall to an IPC engine, an operating system performs memory allocation on the caller based on the shared memory, that is, allocates a part of memory space in the shared memory to the caller to store data (msg) to be transferred, and indicates a Virtual Address (VA) of the data to the caller, and sets an access right to be readable and writable by the caller, and the rest processes/threads are not readable and writable. When the ipccall instruction is executed, after the authority check is passed, the IPC engine sets the part of the shared memory to be readable by the callee according to the information of the callee entry, and other processes/threads are not readable and writable.

In a second aspect, the present application provides a method for inter-process communication IPC, and the method of the present embodiment is a method performed in the system described in the first aspect. The method comprises the following steps: when an IPC engine is initialized by hardware, a processor core configures a part of memory space in a memory into shared memory space of a process, wherein the shared memory space is used for storing data to be transmitted required by inter-process communication; establishing a page table according to the initial address and the length of the shared memory space, wherein the page table comprises a mapping relation from a virtual address to a physical address of the shared memory space; the processor core runs a client process, and when the client process needs to call the service of a server process, a first processor instruction is sent to IPC engine hardware, wherein the first processor instruction is a call instruction of the client process to the service, and the call instruction comprises an identifier of the server process and a virtual address of data to be transmitted; the physical address of the data to be transmitted is positioned in the shared memory space; the IPC engine hardware indicates the processor core to run the server process according to the identifier and sends the virtual address of the data to be transmitted to the server process; the processor core runs the server process, and the server process queries the page table according to the virtual address of the data to be transmitted to obtain the data to be transmitted so as to execute the service; the processor core sends a second processor instruction to the IPC engine hardware, wherein the second processor instruction is a return instruction of the server process; and the IPC engine hardware instructs the processor core to resume running the client process according to the second processor instruction.

Based on the second aspect, in a possible embodiment, when the client process needs to invoke the service of the server process, the processor core configures a part of the memory space in the shared memory space to the client process, so as to store the data to be transferred.

Based on the second aspect, in a possible embodiment, before the processor core runs the client process, the method further includes: the processor core sends registration information of the server process to the IPC engine hardware, wherein the registration information comprises the identification; the IPC engine hardware receives the registration information; saving the identification and the entry address of the server process in the IPC engine hardware in response to the registration information; correspondingly, the IPC engine hardware instructs the processor core to run the server process according to the identifier, including: the IPC engine finds the entry address according to the identification; setting the entry address to a Program Counter (PC) in the processor core; and the processor core runs the server process according to the entry address set in the PC.

Based on the second aspect, in a possible embodiment, after the processor core sends the first processor instruction to the IPC engine hardware, the method further comprises: the IPC engine hardware inquires a state register in the processor core to obtain a call stack address of the client process, and stores the call stack address of the client process in the IPC engine hardware; correspondingly, the IPC engine hardware instructs the processor core to resume running the client process according to the second processor instruction, including: and calling out the call stack address by the IPC engine hardware according to the instruction of the second processor, and instructing the processor core to resume running the client process according to the call stack address.

Based on the second aspect, in a possible embodiment, before the IPC engine hardware instructs the processor core to run the server process according to the identifier, the method further comprises: the IPC engine hardware checks whether the client process and the server meet the requirements of interprocess communication; correspondingly, the step of instructing, by the IPC engine hardware, the processor core to run the server process according to the identifier specifically includes: and when the client process and the server meet the requirements of inter-process communication, the IPC engine hardware indicates the processor core to operate the server process according to the identification.

Based on the second aspect, in a possible embodiment, the call instruction and the return instruction are both user-mode instructions.

In a third aspect, the present application provides a method for inter-process communication IPC, which is applied to an IPC engine (i.e., IPC engine hardware) in the form of a physical entity; when the IPC engine hardware is initialized, the processor core configures a part of memory space in the memory into shared memory space of a process, wherein the shared memory space is used for storing data to be transmitted required by interprocess communication; establishing a page table according to the initial address and the length of the shared memory space, wherein the page table comprises a mapping relation from a virtual address to a physical address of the shared memory space;

the method comprises the following steps: the IPC engine receives a calling instruction from a client process; the calling instruction is used for requesting the service of a server process, and comprises an identifier of the server process and a virtual address of data to be transmitted; the IPC engine activates the server process according to the identification of the server process so that the server process queries the page table according to the virtual address of the data to be transmitted to obtain the data to be transmitted to execute the service; the physical address of the data to be transmitted is positioned in the shared memory space, and the IPC engine receives a return instruction from the server process, wherein the return instruction comprises an execution result; the calling instruction and the returning instruction are both processor instructions of a user state; and the IPC engine recovers the client process according to the return instruction.

Based on the third aspect, in a possible embodiment, when the client process needs to invoke the service of the server process, the processor core configures a part of the memory space in the shared memory space to the client process, so as to store the data to be transferred.

Based on the third aspect, in a possible embodiment, the length of the data to be transmitted is greater than a preset threshold.

Based on the third aspect, in a possible embodiment, before the IPC engine receives the call instruction from the client process, the method further comprises: the IPC engine receives the registration of the server process; and the IPC engine records the identification of the server process and the entry address of the server process according to the registration of the server process.

The IPC engine activates the server process according to the identifier of the server process, and the method comprises the following steps: the IPC engine finds the entry address of the server process according to the identification of the server process; and the IPC engine operates the server process according to the entry address of the server process.

Based on the third aspect, in a possible embodiment, after the IPC engine receives the call instruction from the client process, the IPC engine further includes: the IPC engine records the entry address of the client process; correspondingly, the IPC engine recovers the client process according to the return instruction, including: and the IPC engine switches the operation of the server process into the operation of the client process according to the entry address of the client process.

Based on the third aspect, in a possible embodiment, before the IPC engine runs the server process according to the identifier of the server process, the IPC engine further includes: the IPC engine checks whether the client process and the server meet the requirements of interprocess communication; correspondingly, the IPC engine activates the server process according to the identifier of the server process, including: and under the condition that the client process and the server meet the requirements of inter-process communication, the IPC engine activates the server process according to the identification of the server process.

In a fourth aspect, an embodiment of the present application further provides IPC engine hardware, configured to execute the method described in the third aspect, or may implement the function of the IPC engine hardware in the method described in the second aspect, where the IPC engine hardware includes an IPC logic circuit (or IPC logic), a callee register set, a link register (or link reg), and a message register set, and the IPC engine may be disposed in a CPU core, or may be disposed independently. The IPC engine hardware may be a coprocessor or a separate processing chip, and in some embodiments may be integrated into the processor, running in parallel with the CPU core. In still other embodiments, the IPC engine hardware may be independent of the processor, communicating via a communication line/interface.

In a fifth aspect, the present application provides a computer storage medium for storing a computer program that, when executed by one or more processors, implements the method provided by any one of the second or third aspects.

In a sixth aspect, the present application provides a computer program product for storing a computer program that, when executed by one or more processors, implements the method provided by any one of the second or third aspects.

Drawings

Fig. 1 is a scene diagram of a prior Binder mechanism;

fig. 2 is a schematic diagram of a possible application scenario in which a client process and a server process communicate based on a CS mode according to an embodiment of the present application;

fig. 3 is a schematic diagram of another possible application scenario for communication between a client process and a server process based on a CS mode according to an embodiment of the present application;

FIG. 4A is a block diagram of one possible system configuration of a computing device in an embodiment of the present application;

FIG. 4B is an exemplary diagram of a physical hardware system provided by an embodiment of the present application;

FIG. 4C is a schematic structural diagram of a computing device according to an embodiment of the present disclosure;

FIG. 5A is a possible hardware architecture of an IPC engine provided by embodiments of the present application;

FIG. 5B is a diagram of some examples of application scenarios of the IPC engine provided by the embodiments of the present application;

FIG. 5C is a diagram of another exemplary application scenario of the IPC engine provided by the embodiment of the present application;

FIG. 6 is a flowchart illustrating a method for inter-process communication according to an embodiment of the present application;

FIG. 7 is a flowchart illustrating a method for inter-process communication according to an embodiment of the present application;

fig. 8 is a schematic view of a scenario of a shared memory scheme according to an embodiment of the present application;

fig. 9 is a schematic diagram of an IPC communication scenario applying the scheme of the present application provided in the embodiment of the present application.

Detailed Description

The terminology used in the embodiments of the present application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in the examples of this application and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. The terms "comprises" and "comprising," as well as any variations thereof, are intended to cover a non-exclusive inclusion, such as, for example, a list of steps or elements. A method, system, article, or apparatus is not necessarily limited to those steps or elements explicitly listed, but may include other steps or elements not explicitly listed or inherent to such process, system, article, or apparatus.

It is to be understood that, in the present application, "at least one" means one or more, "a plurality" means two or more. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship. "at least one of the following" or similar expressions refer to any combination of these items, including any combination of single item(s) or plural items. For example, at least one (one) of a, b, or c, may represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", wherein a, b, c may be single or plural.

The application provides a new IPC mechanism, and the time delay of the IPC process can be obviously reduced and the data transmission efficiency can be improved through the IPC mechanism. In order to better understand the scheme of the present application, a client-server (CS) mode related to the embodiments of the present application is first described below. Herein, a requestor of a service (service) may be referred to as a client (client), an implementer of the service may be referred to as a server (server), a process of the client may be referred to as a client process for short, and a process of the client is a process for accessing the service, and may also be referred to as a sending process (caller) herein. The process of the server can be referred to as a server process for short. A server process is a process that provides a service and may also be referred to herein as a receive process (callee).

Referring to fig. 2 and fig. 3, fig. 2 and fig. 3 exemplarily describe a possible application scenario for a CS mode-based client process and a server process to communicate, which is provided by an embodiment of the present application. In some possible embodiments, the two processes (the client process and the server process) may be located in the same computing device, that is, the IPC embodies communication between two processes in the same computing device, where the computing device may be a terminal or a server. In one example, as shown in FIG. 2, the two processes may run on the same processor core of the computing device, such as a CPU core. In yet another example, where the computing device has multiple CPU cores, the two processes may run on different CPU cores of the computing device (such as CPU core1 and CPU core2 as illustrated). In still other possible embodiments, the two processes may also be located in different computing devices, that is, the IPC is embodied by inter-process communication between two different computing devices (computing device 1 and computing device 2), where computing device 1 and computing device 2 may both be terminals, may both be servers, or may be one device that is a terminal and the other device that is a server.

Taking the example that two processes are located in the same computing device, the type of the operating system of the computing may be an Android system (Android system), and in the following description of the related embodiments, the inter-process communication method of the present application is described as an example that the inter-process communication method is applied to the Android system.

In the embodiment of the present application, the system architecture of the computing device may be designed by adopting a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, a cloud architecture, or the like. In the following, a system architecture of a computing device is exemplarily described by taking an Android (Android) system of a hierarchical architecture as an example. Referring to fig. 4A, fig. 4A is a block diagram of a possible system structure of a computing device in an embodiment of the present application. The system architecture includes physical hardware at the bottom level, which provides various computing resources (e.g., CPU), storage resources (e.g., memory, disk, etc.), communication resources (e.g., transceiver), etc., required by the computing device, and a software architecture running on the physical hardware. The software architecture divides the software into several layers, each layer having a clear role and division of labor. The layers communicate with each other through a software interface.

In one possible implementation, the software architecture of the Android system is divided into: kernel layer (kernel), Hardware Abstraction Layer (HAL), system services layer, application framework layer, and application layer. Wherein: the kernel layer is used for providing drivers of a Linux kernel and various hardware devices. The hardware abstraction layer is used for encapsulating the kernel layer hardware driver and providing a uniform hardware interface for the system service layer to call. The system services layer is used to provide system services (services) and provides an interface that can be invoked by the application framework layer. The application framework layer can be understood as an Android SDK and is used for providing basic components used in ordinary development such as four components, drawing and the like, and developers can call interfaces of the application framework layer. The application layer is used to provide user-oriented Applications (APPs).

It should be noted that the kernel layer adopted by the computing device in the embodiment of the present application may be a macro kernel (Monolithic kernel) or a Micro kernel (Micro kernel). The macro kernel, such as linux kernel, provides file system, driver, network protocol, etc. in addition to the most basic processes, thread management, and memory management. For the micro-kernel (e.g., SEL4, QNX, Fuchsia, LK etc.) architecture, the most basic scheduling and memory management is provided in the kernel. And the driver, the file system and the like are realized by the daemon process of the user state, so that better expandability, safety and fault-tolerant capability are brought, and the method is applied to more and more abundant products (such as mobile terminals, car machines, aircraft equipment and the like).

In the embodiment of the present application, the processing logic of the IPC is set to a physical hardware layer instead of a kernel layer, and a dedicated hardware form IPC Engine (IPC Engine) is designed, which may also be referred to herein as IPC Engine hardware, and the IPC Engine is used as a core of process interaction and can process in parallel with the kernel, and the kernel can initialize, configure, control, service process registration, interrupt processing, and the like for the IPC Engine. Service call (function call), context switch, data exchange (data access right transfer) and the like related to the IPC process are completed by the IPC engine in a hardware mode, data or data addresses are transferred in the IPC engine, and context switch, data copy and the like of a kernel mode and a user process stack are avoided in a software mode, so that a large amount of software execution time of a CPU is released, and the overall time delay is reduced.

The IPC engine may run in parallel off the software execution cycles of the CPU. In an IPC Engine implementation, hardware special logic of an IPC Engine can be added in a chip where a CPU Core is located to serve as a coprocessor, namely the CPU Core and the IPC Engine are integrated in the same chip; in yet another IPC engine implementation, the IPC engine may be a processing chip independent of the CPU Core.

In addition, to enable interaction between the IPC engine and processes, the IPC engine is used by providing the processes with a way of processor instructions, such as "ipccall instructions" and "ipcret instructions". The client process (caller) of the user space can call the service of the server process (caller) through an ipccall instruction, and the server process can return through an ipcret instruction to recover the client process. The premise of the execution of the above two instructions is that the IPC engine completes initialization (including, for example, initial configuration of the IPC engine, memory allocation, etc.), and the initialization process can be completed by a kernel state driver.

Through the design of the application, the application program framework layer in the Android is opened to a developer for use in an SDK mode, the core service in the system service layer runs along with the system starting, and the Manager (Manager) provided by the application program framework layer provides service calling for the application program in real time. Each service in the system service layer runs in an independent process space, and an application program can call the service (service) in the system service layer through an IPC engine. Therefore, the processes of context switching, data exchange and the like can be realized by hardware, the software and hardware cooperative work of the CPU is realized by the IPC engine through an IPC software communication mode, and the software execution time of the CPU is released. Thus, expressed in the aspect of user processes, the caller and the caller realize the direct IPC communication in the user state, thereby avoiding the time delay caused by the switching between the kernel state and the user state in the existing scheme, and the data interaction between the processes can only transmit the data address (data access right), thereby reducing or even eliminating the occurrence of data copy, greatly improving the data transmission efficiency, and further reducing the time delay of the IPC process.

An embodiment of the present application further provides a physical hardware system, including: the hardware of the IPC engine can be a logic circuit or an independent logic calculation chip in specific implementation. Wherein: the CPU includes a CPU core (CPU core), and in some embodiments, the IPC engine may be integrated within the CPU, running in parallel with the CPU core. In yet other embodiments, the IPC engine may be independent of the processor core.

Referring to fig. 4B, fig. 4B is an exemplary diagram of a physical hardware system provided in the embodiment of the present application, where the physical hardware system includes a CPU core11, an IPC engine 12, and a DDR memory 13. Part or all of the CPU core11, the IPC engine 12, and the DDR memory 13 may be integrated together, connected through a general-purpose communication interface, or connected through a bus. Wherein: the CPU core11 may be used to run processes (client process or server process), the IPC engine 12 may be used to implement inter-process communication, and the DDR memory 13 may be used to provide data and context information necessary for the process to run. Specifically, the method comprises the following steps: the CPU core can register the server process with an IPC engine in advance, and the IPC engine stores the identification of the server process and the entry address of the server process according to the registration. The CPU core may be configured to send a first processor instruction to the IPC engine when a client process needs to call a service of a server process, where the first processor instruction includes a call instruction (ipccall described in any embodiment of the present application) of the client process to the service, and the call instruction includes an identifier of the server process and a virtual address of data to be transferred; the virtual address of the data to be transferred may be a virtual address corresponding to a location of the data to be transferred in the DDR memory.

The IPC engine may be configured to store an entry address of the client process; and finding the entry address of the server process according to the Identification (ID) of the server process, and further indicating the CPU core to run the server process, thereby realizing the context switching of the process. In addition, the IPC engine can also establish mapping between the address of the data to be transmitted and the address of the server process in the memory space, and transmit the mapping to the server process, so that the transmission of the data access right (not the data itself) is realized.

The CPU core is also used for operating the server process to execute the service according to the data to be transmitted; the CPU core is further configured to send a second processor instruction to the IPC engine, where the second processor instruction includes a return instruction of the server process (e.g., an ipret as described in any of the embodiments of the present application). And the first processor instruction and the second processor instruction are both user-mode processor instructions. The IPC engine is also used for finding an entry address of a client process and indicating the processor core to run the client process, so that the recovery of the client process is realized.

It can be seen that, in the embodiment of the present application, processes such as context saving, context switching, and data exchange of a process can be implemented on hardware of an IPC engine, after the caller actually initiates IPC, the IPC process does not need kernel participation, the software is not switched to a kernel state, the IPC engine and a CPU core work in parallel on the hardware, the CPU realizes software and hardware cooperative work through the IPC engine by means of IPC software communication, so as to release software execution time of the CPU core, and in order to match interaction between the IPC engine and the process in the hardware, processor instructions (a first processor instruction and a second processor instruction) in a user state are provided, so that service call of the caller and callback of the caller are satisfied, interaction of the process in the user state level is realized, and realizability of the IPC process is ensured, therefore, the time delay caused by frequent switching of the user mode and the kernel mode in the existing IPC mechanism (such as a binder mechanism) is avoided. The data interaction between the processes can only transmit the mapping (data access right) of the data address, thereby reducing or even eliminating the occurrence of data copy, greatly improving the data transmission efficiency and further reducing the time delay of the IPC process.

Further, referring to fig. 4C, fig. 4C exemplarily shows a structural diagram of the computing device 30. The computing device 30 may be a terminal or a server. It should be understood that the illustrated architecture of the embodiments of the present application does not constitute a specific limitation on the computing device 30. As shown in fig. 4C, computing device 30 may include: chip 310, memory 315, user interface 314. These components may communicate over one or more communication buses.

Chip 310 may be integrated including: one or more processors 311, IPC engine hardware 312, and a power management module 313. The processor 311 may perform operations, generate operation control signals, perform control of fetching and executing instructions, execute processes (such as a client process caller or a server process collee), and so on. Power management module 313, which is integrated in chip 310, is primarily used to provide stable, high-precision voltages to chip 310 and other components of computing device 30. The IPC engine hardware 312 integrated in the chip 310 may be an IPC engine described in any embodiment of the present application, and implements processes of context saving, context switching, data exchange, and the like in IPC communication.

The IPC engine hardware 312 may be a coprocessor or a separate processing chip, and in some embodiments, the IPC engine hardware 312 may be integrated into the processor 311, with the IPC engine hardware 312 running in parallel with the CPU core. In still other embodiments, the IPC engine hardware 312 may communicate independently of the processor 311 over a communication line/interface. The specific functional implementation of the IPC engine hardware 312 can be referred to the description of the IPC engine in any embodiment of the present application.

The processor 311 may specifically include one or more processing units with different capabilities, such as: the processor 311 may include a Central Processing Unit (CPU), an Application Processor (AP), a modem processor, a Graphics Processing Unit (GPU), an Image Signal Processor (ISP), a controller, a video codec, a Digital Signal Processor (DSP), a baseband processor, and/or a neural-Network Processing Unit (NPU), etc., as described in the previous embodiments. The different processing units may be separate devices or may be integrated into one or more processors. Where each processing unit may include one or more cores (cores).

In some embodiments, the processor 311 may include one or more interfaces. The interface may include an integrated circuit (I2C) interface, an integrated circuit built-in audio (I2S) interface, a Pulse Code Modulation (PCM) interface, a universal asynchronous receiver/transmitter (UART) interface, a Mobile Industry Processor Interface (MIPI), a general-purpose input/output (GPIO) interface, a Subscriber Identity Module (SIM) interface, and/or a Universal Serial Bus (USB) interface, etc.

The memory 315 may be coupled to the processor 311 via a bus, or may be coupled to the processor 311 for storing various data, software programs, and/or sets of instructions. In particular implementations, memory 315 may include DDR memory for storing data and context information necessary for the process to run. The memory 315 may also include high-speed random access memory (e.g., cache memory), and the memory 315 may also include non-volatile memory, such as one or more magnetic disk storage devices, flash memory devices, or other non-volatile solid-state storage devices.

User interface 314 may be used to connect peripheral devices in computing device 30, such as various input/output devices (I/O devices, sensors, display screens, etc.), and embodiments of the present application are not limited in this respect.

One possible hardware architecture of the IPC engine in the embodiments of the present application is described below. Referring to fig. 5A, the hardware architecture may include an IPC logic circuit (or IPC logic), a callee register set (also referred to as a second register set), a link register (or link reg), and a message register set (also referred to as a first register set), and the IPC engine may be disposed in a CPU core or may be disposed independently.

The IPC logic circuit is used as a control center of an IPC engine and can respond to processor instructions ipccall and ipcret of two user states, wherein the ipccall and the ipcret are instructions which can be called by a process in the user state; and carrying out control processing of an IPC flow, and finishing condition inspection and the like for the callee and the caller.

The CALLE register set comprises a set of registers for recording indication information of context information of CALLE. The register may be, for example, a 32-bit register or a 64-bit register, and the bit width of the register is not limited in the present application. Specifically, the CALLE register set is specifically used for recording entry addresses (CALLE entry addresses) of a plurality of CALLEs, and each CALLE entry address corresponds to context information of one CALLE. Therefore, the call entry address may be referred to as "instruction information of the context information of the call".

In one embodiment, the caller entry address may represent an address of a context of a caller process in the global DDR (e.g., the DDR memory 13 in fig. 4B). Illustratively, the specific content of the caller entry address may be, but is not limited to: at least one of a page table pointer (page table pointer), an address pointer, a virtual address, or a physical address.

In one embodiment, the call entry address includes an address pointer of a call service function, which may be a Callback function (Callback function), that is, the address pointer of the call points to the address of a Callback function (Callback function) registered by the call, and the Callback function is used for the call to execute a corresponding service (service). The callback function belongs to a handler, and is a function called by a function pointer, and calling between functions is realized by the callback function. If a pointer (address) to a function is passed as a parameter to another function, the function is said to be a callback function when the pointer is used to call the function to which it points. The IPC engine may set a Program Counter (PC) in the CPU to the call entry address, so that the CPU starts executing the call process context and runs the call to execute the corresponding service.

Each time, one of the multiple CALLE entry addresses is recorded through the CALLE register set, and when the multiple CALLE entry addresses of multiple CALLEs are recorded in the CALLE register set, the multiple CALLE entry addresses can form a list, which can be called a CALLE list (CALLE list), and the list can be stored in a memory for indexing. The call register set can be regarded as a manager of the call list, and provides functions of registration, editing (adding and deleting), maintenance, access, query and the like of the call list to the outside.

As shown in fig. 5A, in a possible implementation, the CALLE register set further includes a first address register and a count register, where the first address register is used to store a first address of a CALLE list, and specifically, may be a first CALLE entry address in the CALLE list. The count register is used to record the number of the call entry addresses (entry size), and specifically, each time a list entry (i.e., a call entry address) is added to a call list, the number of records in the count register is added by 1. Thus, the entry addresses (the call entry addresses) of a plurality of calls can be recorded to the call list according to the registration condition of the plurality of calls by the call register set.

Referring to FIG. 5B, fig. 5B (1) shows an exemplary diagram of a scenario in which a call to a call list is registered with an IPC engine. In a specific implementation, each list entry of the callerelist may be configured to correspond to an index Identification (ID). The index ID may be the cause process ID (i.e., the cause ID), or the index ID may be mapped one-to-one with the process ID, which may be determined after registration of the cause with the IPC engine. In this way, IPC of a client process (caller) with one or more callers may be facilitated.

The registration process of the callee to the IPC engine can be completed through a system call, for example, a user interface of a CPU core can be driven by a device corresponding to the kernel, and relevant contents (for example, an address pointer) are saved in a first address register of the IPC engine according to context information of the callee.

Thus, in the IPC process, the IPC engine can find the caller entry address according to the ID passed in by the caller. As shown in (2) of FIG. 5B, the calling instruction (ipccall) initiated by the caller to the IPC engine carries the identification (caller ID) of the caller, so that the IPC logic circuit can look up the caller list according to the caller ID, and index the entry address (caller entry address) of the caller. The IPC engine may also set a Program Counter (PC) in the CPU to the call entry address to make the call run and provide the corresponding service. A program counter is a register that holds the address (location) of the instruction currently being executed. As each instruction is fetched, the memory address of the program counter is incremented by one. After each instruction is fetched, the program counter points to the next instruction in the sequence. Therefore, the IPC engine may send the callee entry address to the PC for logging, so that the CPU executes the instruction to execute the callee.

In the embodiment of the application, when the IPC engine is deployed in the CPU core, the user interface of the CPU core may provide system calls such as add (add) and remove (remove) of the caller entry address, and registration and deregistration of the caller service may also be implemented through the interface.

The link register is used for storing the entry address of the current caller, and the entry address of the caller corresponds to the context information of the caller. In particular, the link register may hold the call stack address of the current caller, which is associated with the context information of the caller, to record the call behavior of the current trigger. After a calling instruction (ipccall) is initiated by a caller, an IPC logic circuit of an IPC engine queries a state register in a CPU, and can know which caller initiates the call by querying the state of the latest saved caller in the state register, so that the calling stack address of the caller can be saved to a link register. When the CALLE completes the execution of the service, the link register can pop up the record of the current CALLER, and process switching (namely, the CPU is switched from the context of the CALLE to the context of the CALLER) is realized so as to recover the process of the CALLER. The CALLE register set and the link register provided by the embodiment of the application can realize the context switching process of the process in hardware, so that the software execution time of a CPU is released, and the time delay of an IPC process is reduced.

The message register set comprises a set of registers that record the address of the data (msg) that the caller needs to pass to the caller. The register may be, for example, a 32-bit register or a 64-bit register, and the bit width of the register is not limited in the present application. The message register set can be used to establish and store indication information (e.g. pointers) indicating the mapping of the Virtual Address (VA) to the Physical Address (PA) of the data (msg) to be transferred during IPC communication, which can be stored in the memory.

In a specific embodiment, the message register set is used for recording entry addresses (msg entry addresses) of a plurality of msgs. In a particular implementation, the message register set may record the address of the data that the caller entered in the call instruction, or the data itself (e.g., only a few bytes of small data). Each msg entry address indicates an address of an msg in the DDR memory (which may be referred to as an msg memory address for short), and the msg entry address may include at least one of the following: base address of virtual address (VA base), base address of physical address (PA base), address space length (length). It can be seen that the message register set may record the address of one or more of the callers' data that needs to be transferred, thereby facilitating IPC of the callers with one or more of the callers. It is to be understood that the following embodiments are described by way of example, but not by way of limitation, and may be extended to other types of memory.

A caller, through a call instruction (ipccall), enters an address which may be one or more msg. In an embodiment, the address of the incoming msg may be the Virtual Address (VA) of the msg. Recording one or more msg entry addresses may be accomplished each time through a set of message registers. When the message register set records msg entry addresses for multiple times, the msg entry addresses can form a list, which can be called as a msg list (msg list), and the list can be stored in a memory for indexing. The message register set can be regarded as a manager of the msg list, and the functions of editing (adding and deleting), maintaining, accessing or inquiring the msg list are provided for the outside.

In some embodiments of the present application, in order to avoid copying (copy) of data to be transferred in the IPC process, in the IPC engine, the data itself may not be directly transferred, but the transfer of the data is indirectly achieved by transferring a mapping (memory mapping) of the data without copying the data. Specifically, a mapping mechanism of the msg address space can be added in the IPC engine, a part of memory is configured in the DDR global memory in advance as a shared memory, and the shared memory can be shared and accessed by a caller and a caller. That is, the caller and the caller share a segment of memory space, which is referred to as a shared memory herein), and the Physical Address (PA) of the data msg to be transferred is the location of the msg in the segment of memory space. The shared memory is used to store data (msg) that needs to be transferred by the service invocation process so that msg is only mapped between the caller and the caller.

Specifically, referring to fig. 8, in the embodiment of the present application, when a system is initialized (IPC engine is initialized), an operating system running in a processor core reserves (or configures) a part of a memory in a physical memory as a shared memory of a controller and a controller, and in order to improve data access security, a memory access right may also be initialized. Meanwhile, the logic for accessing the shared memory can be unified into the access logic of the existing Memory Management Unit (MMU), so as to avoid the change of the execution flow of the existing MMU and avoid the occurrence of page fault. That is, in the embodiment of the present application, the shared memory is fixedly reserved and allocated during the initialization of the IPC engine, and this portion of the shared memory is not in the page table of the kernel (e.g., kernel). This portion of shared memory is directly accessible by the IPC engine. The shared memory may be used to hold data that needs to be transferred between processes during IPC communications. By reserving the shared memory, a special page table (the page table contains the mapping relation between the virtual address and the physical address) can be established, and the data to be transmitted is ensured to have a corresponding physical page all the time, so that the missing page error is avoided.

After the shared memory is allocated, a mapping relation from a Virtual Address (VA) to a Physical Address (PA) is formed globally in the shared memory, each msg related to IPC communication is stored in the shared memory, so that a large number of mapping relations (for example, mapping tables) from the Virtual Address (VA) to the Physical Address (PA) are formed, and the IPC engine can access such mapping tables. When a caller needs to call a caller service, an operating system performs memory allocation on the caller based on the shared memory, namely allocates a part of memory space in the shared memory to the caller to store data (msg) to be transferred, and indicates a Virtual Address (VA) of the data to the caller so that the caller can initiate a call instruction ipccall.

Subsequently, when the caller initiates a call instruction to the IPC engine, the IPC logic of the IPC engine can maintain the msg list by looking up the mapping table.

Referring to FIG. 5C, FIG. 5C shows an exemplary diagram of a scenario in which the msg list is maintained to the IPC engine according to the caller's Call instruction (ipccall). As shown in fig. 5C, in a possible implementation, the message register set further includes an msg register and a count register, where the msg register may also be an initial address register, and is used to store an initial address of the msg list, and specifically, may be a first msg entry address in the msg list. The counting register is used for recording the number of msg entry addresses, and specifically, every time a list entry (i.e., an msg entry address) is added to the msg list, the number recorded by the counting register is increased by 1. Thus, one or more msg entry addresses through a callee list may be recorded via the message register set. Each list entry (i.e., one msg entry address) may be specifically represented as a Physical Address (PA) of the msg in the shared memory. In a specific implementation, an ipccall of a caller may carry an msg VA (as shown in VA1), an IPC logic circuit of an IPC engine may search a mapping table corresponding to a shared memory based on the msg VA, so as to determine a PA (as shown in PA1) corresponding to the msg VA, where the PA serves as an msg entry address, and records the msg entry address to an msg list through a message register set. As can be appreciated, when multiple msg VA are introduced by the caller, multiple msg entry addresses can be recorded to the msg list through the message register set.

In a specific implementation, to facilitate data lookup, each list entry (PA) of the msg list may be configured to correspond to a Virtual Address (VA). Namely, the msg VA to PA mapping relation is formed. Therefore, only msg VA is needed to be transmitted to the callee subsequently, and msg itself is not needed to be transmitted, the defect of data copying is avoided, and the transmission efficiency is improved.

In some embodiments, during IPC communication, Callee may use the VA to query the msg list maintained by the IPC engine to achieve data acquisition. The query process includes, for example: and calling the corresponding PA from the IPC engine by using msg VA by the caller, finding the corresponding PA in the VA by the IPC logic circuit of the IPC engine based on the mapping relation, and sending the PA to the caller.

In still other embodiments, after the shared memory is allocated, when a callee registers in the IPC engine, the callee may further establish a page table of the process according to the starting Address and the length (size) of the shared memory, and add the page table to the MMU, where the page table globally defines a mapping relationship between a Virtual Address (VA) and a Physical Address (PA) of the shared memory, and the callee may access the page table according to the VA to directly obtain the PA corresponding to the VA, that is, the callee may directly access data (msg) in the shared memory using the VA, thereby implementing unification of Address access logics to the MMU, avoiding modification of an existing MMU process, and further improving feasibility of the scheme. In this embodiment, the msg list maintained by the IPC engine may be used to check the correctness of the data, that is, after the msg list is established, when the caller initiates the call of the service again, the IPC engine checks whether the PA corresponding to the VA is in the shared memory through the msg list (that is, whether the mapping relationship between the VA and the PA located in the shared memory is recorded in the msg list).

Further, in order to realize the security and accuracy of data access, the IPC logic circuit of the IPC engine can realize the control of the access authority of msg by setting the query authority of the callee to the msg list maintained by the IPC engine. For example, when a caller needs to initiate ipccall to an IPC engine, an operating system performs memory allocation on the caller based on the shared memory, that is, allocates a part of memory space in the shared memory to the caller to store data (msg) to be transferred, and indicates a Virtual Address (VA) of the data to the caller, and sets an access right to be readable and writable by the caller, and the rest processes/threads are not readable and writable. For a call corresponding to a call ID transmitted when the call service is called by the caller, the IPC engine can start a search authority in context information of the call, namely, the call corresponding to the call ID is allowed to use VA to query msg list maintained by the IPC engine, a memory where the data is located is set to be readable by the call, and other processes/threads are not readable and writable, so that access to msg is realized. And for other callees, the default searching authority is closed, so that other callees cannot query the msg list, thus avoiding other callees from illegally accessing data and improving the security and accuracy of data access.

In addition, in the execution period of the IPC logic circuit, different CPU cores can be prohibited from simultaneously accessing the resources on the IPC engine, so that possible malicious attack programs can be resisted, and the safety of the IPC process is improved.

It can be seen that data (msg) can be mapped between a caller and a caller through a shared memory, an IPC engine maintains a mapping relation from msg VA to PA, the IPC engine can set an access right of msg according to ipccall initiated by the caller, and only msg VA needs to be transferred to the caller subsequently. Therefore, the data transmission is indirectly completed under the conditions of no dependence on a kernel and no data copy, and the transmission process is invisible to the outside. It can also be understood that, in this embodiment of the present application, the data transfer form of the current caller may be transfer of an access right (not data itself) of the data, where the access right is obtained from a call chain of the caller, such as caller- > caller, so as to save transmission resources and improve data transfer efficiency.

It should be noted that, in this document, the "context information of a process" may be regarded as various variables, data, and environments in which the process is executed, which are related to the state of the process, including variables of all registers related to the process, files opened by the process, or memory information. When process scheduling occurs, the process switching is context switching of the process, and the newly scheduled process can run only when the context information mentioned above needs to be switched. For example, when a switch from a client process to a server process is required, all states of the client process need to be saved while the state of the server process is loaded. Thus, when the service is finished, the state of the interrupted client process can be restored according to the context information of the client process.

It can be seen that, by designing the IPC engine in a dedicated hardware form in the embodiments of the present application, the IPC engine can be operated in parallel as a coprocessor or a separate execution unit, departing from the software execution cycle of the CPU. An IPC logic circuit and a plurality of registers are further provided in the IPC engine to establish a new IPC mechanism. In order to cooperate with the interaction between the IPC engine in the form of hardware and the process, the embodiment of the present application further designs a user-mode processor instruction for the use of the caller and the caller respectively: ipccall and ipcret, so as to call the interface, thereby satisfying the service call of the caller and the call back of the caller, and ensuring the realizability of the IPC process. The execution of the above two instructions is premised on the completion of the initialization of the IPC engine, and the initialization process can be completed by the kernel state driver, including the initialization configuration, the memory allocation and the like of the IPC engine.

The IPC engine can realize context information storage, context switching, data transmission and the like in the user state, the kernels in the processes are not sensed (namely, the IPC process does not need kernel participation), the defect that the user state and the kernel state are frequently switched in the existing IPC mechanism (such as a binder mechanism) is avoided, the IPC process of the process is separated from the kernels, and therefore a large amount of software execution time of a CPU is released, and the whole time delay of the IPC process is greatly reduced.

In addition, the IPC engine in the embodiment of the present application maps the data memory, and only the virtual address of the data needs to be transferred to the caller, and the data itself does not need to be transferred, so that copying (copy) of the data is avoided, the time delay of data copying is reduced, and the data transmission efficiency is improved.

In addition, by implementing the scheme of the embodiment of the application, after the IPC engine is initialized, the operating system allocates the shared memory, and after the call initiates registration, the page table of the process is established and managed by the MMU. When the caller needs to call the service, the operating system allocates a memory segment for storing generation transfer data (msg) to the caller in the shared memory, and the mapping relation between the virtual address and the physical address of the msg in the memory segment is consistent with the mapping relation recorded in the page table managed by the MMU, so that in the subsequent IPC communication, after the msg VA is transferred from the caller to the caller through the IPC engine, the caller can access the page table according to the VA to obtain the data, thereby achieving the purpose of sharing the memory by the caller and the caller, avoiding the change of the existing MMU workflow, avoiding the occurrence of page fault and ensuring the stability and the safety of the IPC communication.

It should be understood that the IPC engine in fig. 5A may be implemented by pure hardware, and includes a large number of logic circuits, algorithm circuits, or registers, and may further include various interfaces or analog circuits, and the present embodiment is not limited thereto. When the IPC engine is a coprocessor, it may be implemented by pure hardware without executing software, or partially implemented by a coprocessor capable of running software, that is, the function of the IPC engine is implemented by running necessary software, and at this time, each corresponding component in fig. 5A may run necessary software modules to implement the technical solution. The IPC engine at this time is still a hardware accelerator independent of the CPU, but needs necessary software to drive its work, and this embodiment does not specifically expand on this.

For the sake of convenience, the method embodiments described below are all expressed as a combination of a series of action steps, but those skilled in the art should understand that the specific implementation of the technical solution of the present application is not limited by the order of the series of action steps described.

Based on the above described system architecture and IPC engine, the following describes a method flow of inter-process communication (IPC) provided by the embodiment of the present application, referring to fig. 6, the method is described from the perspective of IPC engine side, including but not limited to the following steps:

s100, when IPC engine hardware is initialized, an operating system running in a processor core configures a part of memory space in a memory into shared memory space of a process, wherein the shared memory space is used for storing data to be transmitted required by inter-process communication. The memory may be a memory, such as a DDR memory, e.g., DDR SDRAM (Double Data Rate SDRAM).

In the embodiment of the application, when the system is initialized (the IPC engine is initialized), the operating system fixedly reserves a part of memory in the physical memory as the shared memory of the controller and the controller, and the shared memory can be used for storing data which needs to be transmitted between processes in the IPC communication process.

In some embodiments, before running the callee process, the callee may establish a page table according to the starting address and length (size) of the shared memory space, the page table being managed by the MMU, the page table containing a mapping relationship of a virtual address to a physical address of the shared memory space, so that the callee can obtain the generation passing data in the subsequent IPC communication based on the VA lookup page table.

In still other embodiments, indication information (pointer) is saved in a register of the IPC engine, where the indication information indicates a mapping relationship between a virtual address of data to be transferred and a physical address of the data to be transferred, so that a subsequent callee queries the IPC engine to obtain generation transfer data in subsequent IPC communication based on the VA.

When a caller needs to initiate an ipccall call to an IPC engine, an operating system performs memory allocation on the caller based on the shared memory, namely allocates a memory segment in the shared memory to the caller to store data (msg) to be transferred, and indicates a Virtual Address (VA) of the data to the caller. The mapping relationship between the virtual address and the physical address of the msg in the memory segment is consistent with the mapping relationship recorded in the page table managed by the MMU.

For the related implementation content of the above embodiments, reference may be made to the related description above, and details are not repeated here.

S101, the IPC engine receives a call instruction from a client process, wherein the call instruction can be ipccall described herein, the call instruction is used for requesting service of a server process, and the call instruction comprises identification of the server process and an address of data to be transmitted. The address may be a virtual address.

In the embodiment of the application, the Server (Server) is used as an owner of a plurality of services (Service), and before the Server (Server) can provide services to the Client (Client), the Server (Server) can register own services with the IPC engine through a Server process (call). In one implementation, after the call is started, the registration process may be completed with the aid of a kernel driver, where the kernel may be a macro kernel or a micro kernel, and the present application is not limited thereto.

The IPC engine records the Identification (ID) of the callee and the entry address of the callee according to the registration of the callee, and the entry address of the callee corresponds to the context information of the callee.

Since information of various services has been registered in the IPC engine in advance, the caller can know from the IPC engine which services are available for use. When a client needs to use one or more types of callee services, the client can apply for one or more types of services from an IPC engine through a client process (caller). At this time, the client's caller may request IPC engine services using a call instruction (ipccall) at the user layer.

The call request may include information such as a command to call a service, an ID of a call, and an address of a parameter msg.

And S102, activating the server process by the IPC engine according to the Identification (ID) of the server process so as to enable the server process to execute the service according to the data to be transmitted.

On one hand, the IPC engine can search the local storage to find the entry address of the server process according to the identification of the server process; the IPC engine may then set a Program Counter (PC) to the caller entry address to start executing the caller process context, thereby causing the server process to run.

On the other hand, in order to avoid copying (copy) of data to be transferred in the IPC process, in the IPC engine, the data itself may not be directly transferred, but the transfer of the data is indirectly realized by transferring the mapping (memory mapping) of the data to the callee without copying the data. Specifically, the address of the data to be transferred may be msg VA, and the IPC engine may establish a mapping relationship from msg VA to PA according to a shared memory mechanism, give a caller an inquiry authority to the mapping relationship, and transfer VA to the caller. Or the callee can query the page table in the MMU according to the VA to obtain the PA corresponding to the VA, thereby implementing access to msg. Therefore, the subsequent callee can query the IPC engine according to the VA to realize the access to the msg and execute the service required by the client according to the msg.

S103, the IPC engine receives a return instruction (ipret) from the server process, wherein the return instruction comprises an execution result.

The ipccall and the ipcret in the application belong to processor instructions of a user mode, so that the interaction of instructions of a controller and a controller in the user mode in an IPC process is realized, and the phenomenon that the IPccall and the ipcret fall into a kernel mode is avoided.

And S104, the IPC engine recovers the client process according to the return instruction.

In the embodiment of the application, after the IPC engine receives the ipccall from the caller, the entry address of the caller may also be recorded. And the entry address of the caller corresponds to the context information of the caller. Thus, when the IPC engine receives the ipcret of the caller, the operation of the caller can be switched to the operation of the caller according to the entry address of the caller, namely, the switching of the processes is realized. Specifically, when the callee completes the processing of the IPC, the iplet can be executed. The IPC engine responds to the iplet to pop up the current caller record, thereby switching to the caller context and restoring the caller status.

It can be seen that, by implementing the embodiment of the present application, context information saving, context switching and restoring, data transfer, etc. in the user state can be transferred to a new physical entity (i.e. IPC engine) from time and space. The IPC engine serves as a medium of the IPC and provides corresponding user mode instructions ipccall and ipcret, so that the CALLER and the CALLE can complete context switching in the user mode without switching to the kernel mode, the requirements for calling of the CALLER and callback of the CALLE are met, interaction of a process in the user mode is achieved, the IPC engine can work with kernel software in parallel, and the whole time delay of the IPC process is greatly reduced. In addition, in the embodiment of the application, the data access right can be transmitted through the IPC engine, only the virtual address of the data needs to be transmitted to the caller, and the data does not need to be transmitted, so that copying (copy) of the data is avoided, the time delay of data copying is further reduced, and the data transmission efficiency is improved.

In addition, by implementing the scheme of the embodiment of the application, after the IPC engine is initialized, the operating system allocates a shared memory, the callee initiates registration and establishes the page table of the process, the callee is managed by the MMU, and when the calller needs to call a service, the operating system allocates a memory segment for storing generation transfer data (msg) to the callee in the shared memory, and the mapping relationship between the virtual address and the physical address of the msg in the memory segment is consistent with the mapping relationship recorded in the page table managed by the MMU, so that in subsequent IPC communication, after the IPC engine transfers msg VA from the callee to the callee, the callee can access the page table according to the VA to obtain the data, thereby achieving the purpose of sharing the memory by the callee and the callee, avoiding the change of the existing MMU working flow, avoiding the occurrence of page fault, ensuring the stability and security of IPC communication, and improving the feasibility of product landing.

Based on the system architecture and the IPC engine described above, the following describes another method flow of inter-process communication (IPC) provided in the embodiment of the present application, and the IPC engine may be deployed in the CPU core and interact with the outside world, for example, interact with a process, by using a user interface of the CPU core. Referring to fig. 7, the method proceeds from a multi-sided perspective to a detailed description of the protocol, including but not limited to the following steps:

s200, when IPC engine hardware is initialized, configuring a part of memory space in the memory into shared memory space of the processes, wherein the shared memory space is used for storing data to be transmitted required by inter-process communication. The memory may be a memory, such as a DDR memory, e.g., DDR SDRAM (Double Data Rate SDRAM).

The related memory of this step refers to the description of step S100, and is not described herein again.

And S201, registering the callee to an IPC engine after starting.

Illustratively, a call may be registered with the IPC engine through the kernel. Of course, the callee can also register to the IPC engine by other ways, for example, corresponding to a system with a microkernel, and can register to the IPC engine by a driver of a user mode. The registration method is not particularly limited in the present application.

In the embodiment of the application, the Server (Server) is used as an owner of a plurality of services (Service), and before the Server can provide services to the Client (Client) through the IPC, the Server (Server) firstly registers own services to the IPC engine through a Server process (callee). The server may register one or more services with the IPC engine.

In one implementation, after the call is started, the registration process may be completed with the aid of a kernel driver, where the kernel may be a macro kernel or a micro kernel, and the present application is not limited thereto. The kernel may drive the IPC engine to store the information of the callee registration, for example, the registration process may be completed through a system call (e.g., a callee list address instruction), and the IPC engine forms a callee entry address through the callee register set according to the ID of the callee, and records the ID number of the callee, where the ID number is associated with the callee entry address. It can be understood that different processes of the same server or different processes of different clients may all be registered in the IPC engine, and each time a call is registered, a call entry address is added, and all the call entry addresses may form a list (call list) pointing to the global DDR memory. A caller entry address can be considered an entry in the list. And the ID number of the callee can be used as an index for the entry.

Illustratively, the ID number of a call may be the process number (PID) of the call.

S202, when the caller needs the service of the caller, the caller sends a call instruction (ipccall) of the service to the IPC engine, wherein the call instruction comprises the ID of the caller and the address of data to be transferred (for example, the address information is recorded as msg). The address may be a virtual address.

In this step, since information of various services has been registered in the IPC engine in advance, the caller can acquire which services are available from the IPC engine. When the client needs to use one or more of the callee services, the client needs to apply for the one or more services from the IPC engine. At this time, the client may request an IPC engine service by using a call instruction (ipccall) on the user layer, and an ID and related parameters of a callee corresponding to the service are introduced through the ipccall instruction, where the related parameters include an address of data to be transferred to the callee (referred to as an address of data to be transferred for short), for example, the address of the data to be transferred is a virtual address (referred to as msg VA in the foregoing).

It should be noted that ipccall in this document can support providing a synchronous or asynchronous calling mode, and the method flow mainly takes the synchronous calling mode as an example to describe the scheme.

S203, the IPC engine carries out condition check on IPC communication between the caller and the caller.

In this step, in response to ipccall from a caller, the IPC engine may perform various conditional checks to verify that the requirements of the IPC communication are met. In a possible embodiment, the subsequent steps are not executed until the condition check is passed, and if the condition check is not passed, the ipccall can be rejected.

It should be noted that this step is an optional step.

And S204, the IPC engine records the indication information of the context information of the controller in a link register (link reg), and centrally records the entry address (msg entry address) of the data to be transmitted through a message register.

In this step, the IPC engine may record the context information of the caller in the call stack pointed by the link reg for use when the caller needs to be restored later. In addition, the IPC engine may record msg entry addresses through msg list via a message register set according to the msg address (e.g., msg CA) introduced by the caller. Caller can transmit one or more msg addresses in one calling instruction, and it can be understood that when the Caller needs to communicate with one or more callees by IPC, the Caller can transmit msg address information corresponding to different callees respectively.

It should be noted that, in a possible implementation, this step may also be performed before step S203.

S205, the IPC engine finds out the address of the callee entry through the callee register set according to the ID of the callee.

And S206, the IPC engine performs process context switching according to the address of the call entry, so as to activate the call.

In this embodiment of the present application, since the ID of the caller and the caller entry address have an explicit corresponding relationship, the IPC engine may find the caller entry address in the list (caller list) according to the ID transmitted by the caller, for example, the caller entry address may be an address pointer of a caller, the address pointer of the caller points to a callback function address registered by the caller, and the callback function is used for the caller to execute a corresponding service (service). Then the IPC engine may set a Program Counter (PC) in the CPU to the caller entry address, and begin executing the caller process context, at which time the caller is activated to execute the corresponding service.

And S207, determining the mapping relation between the address (virtual address) of the data to be transferred and the memory address by the IPC engine.

And S208, the IPC engine transmits the address (virtual address) of the data to be transmitted to the callee and transfers the access right of the data to be transmitted to the callee.

In some embodiments of the present application, in order to avoid copying (copy) of data to be transferred in the IPC process, in the IPC engine, the data itself may not be directly transferred, but the transfer of the data is indirectly achieved by transferring a mapping (memory mapping) of the data without copying the data. As shown in fig. 8, a specific implementation is: a mapping mechanism of the msg address space is added in an IPC engine, so that msg data is only mapped between a caller and a caller. When the IPC engine is initialized, a part of the memory is allocated as a shared memory, a mapping table between a Virtual Address (VA) and a memory address (physical address) for determining msg is established, and the IPC engine can access the mapping table. When a caller initiates ipccall to an IPC engine, the IPC engine may find a PA by looking up a mapping table according to an incoming msg VA, and record a mapping relationship between the VA and the PA to implement maintenance of the msg list. Therefore, on one hand, the IPC engine only needs to transmit msg VA to callee and does not need to transmit msg, the defect of data copying is avoided, and the transmission efficiency is improved. On the other hand, the IPC logic circuit of the IPC engine can realize the control of the access authority of the msg by setting the query authority of the callee to the msg list maintained by the IPC engine. For example, when a caller needs to initiate ipccall to an IPC engine, an operating system performs memory allocation on the caller based on the shared memory, that is, allocates a part of memory space in the shared memory to the caller to store data (msg) to be transferred, and indicates a Virtual Address (VA) of the data to the caller, and sets an access right to be readable and writable by the caller, and the rest processes/threads are not readable and writable. When the ipccall instruction is executed, after the authority check is passed, the IPC engine sets the part of the shared memory to be readable by the callee according to the information of the callee entry, and other processes/threads are not readable and writable. Specifically, for a call corresponding to a call ID transmitted when a call service is called, the IPC engine may start a lookup right in context information of the call, that is, allow the call corresponding to the call ID to query an msg list maintained by the IPC engine using a VA, thereby implementing access to the msg, or the call may query a page table in the MMU according to the VA to obtain a PA corresponding to the VA, thereby implementing access to the msg. I.e. to enable the transfer of data access rights from the caller to the caller. And for other callees, the default searching authority is closed, so that other callees cannot query the msg list, thus avoiding other callees from illegally accessing data and improving the security and accuracy of data access.

In some embodiments of the present application, different transmission modes may be configured for data with different lengths according to the length of the data to be transmitted, so as to improve flexibility of data transmission.

An exemplary scenario may be: configuration small data (data length less than a preset threshold, e.g., less than 32 bytes) is passed directly through the msg register copy. Configuring large data (the data length is greater than or equal to a preset threshold value, for example, greater than or equal to 32 bytes) to transmit by adopting a memory mapping scheme, and transmitting the access right of the data to the call by the IPC engine to complete the transmission process.

Yet another exemplary scenario may be: if the data length is less than 32 bytes, directly copying and transmitting through the msg register in the process of process context switching; if the data length is larger than or equal to 32 bytes and smaller than the IPC cache size (IPC BUF size, the size can be defined by self, such as 128 bytes), copy transfer can be carried out in a scheduling or interrupt mode; if the data length is larger than the IPC cache size (for example, larger than 128 bytes), a memory mapping scheme is adopted for transfer, and the IPC engine transfers the access right of the data to the callee to complete the transfer process.

It should be noted that, the specific size of the preset threshold is not limited in the present application, and the above example is only used for explaining the scheme of the present application and is not limited.

It should be further noted that there is no necessary sequence between the steps of S205-S208.

And S209, the caller acquires the data to be transmitted and executes the service required by the caller.

In this step, the caller may obtain the msg according to the access right of the data (for example, using VA to query the msg list maintained by the IPC engine, thereby implementing access to the msg), and call a related function to complete a specific service (service). The service in the system service layer can be provided for the application program in real time through the Manager provided by the application sequence framework layer. The service content may be, for example, a message, a communication, a camera, a window usage, or the like, and the application is not limited thereto.

S210. the callee sends a return instruction (ipret) to the IPC engine, which can carry the execution result of the service.

S211. the IPC engine resumes execution of the caller using the link register.

In this step, when the callee completes the processing of the IPC, the iplet can be executed. The IPC logic of the IPC engine responds to the ipcret and controls a link register (link reg) to pop up the last controller record, thereby switching to the controller context and restoring the controller state.

In order to better understand the specific scheme of the embodiment of the present application, the following description further takes fig. 9 as an example. In the illustration, the command interaction between the caller and the caller is represented by a dotted line, which is intended to illustrate that the caller and the caller can implement service invocation at the user layer, and the service invocation is not really directly interacted between the caller and the caller, but is interacted by taking an IPC engine of a hardware layer as an intermediary, so as to implement an IPC communication mode.

One IPC communication process after using the IPC engine is as follows: after starting, a service process callee of the IPC registers to an IPC engine through a kernel driver, and the calller uses an ipccall instruction to request the service of the IPC engine on a user layer and transmits a corresponding callee ID and an address of a related parameter msg to the IPC engine. context information of the caller is recorded in a call stack pointed to by a link register of the IPC engine and is used when the state of the caller needs to be restored, and msg is recorded in a continuous memory pointed to by a msg register. The IPC engine finds the callee entry address according to the ID transmitted by the calller, and sets a Program Counter (PC) in the CPU to the callee entry address, and the CPU starts to switch to the process context of the callee. The IPC engine also passes the access rights for msg to the callee. Thus, the callee can execute the method of the corresponding service. After the CALLE finishes the IPC processing, an iplet command is sent to an IPC engine, and the IPC engine controls a link register to pop up a CALLER record, so that the execution of a CALLER process is recovered. In the IPC process, the event notification of the IPC engine can be reported to the kernel (kernel) in an interrupt manner. For example, when the IPC engine is abnormal, the event can be reported to the kernel by an interrupt mode, and for example, when the IPC processing is completed, the event can also be reported to the kernel by an interrupt mode.

It should be noted that, where details are not described in the embodiment of the present method, reference may be made to the description of related contents in the foregoing, for example, the embodiments in fig. 4A, fig. 4B, fig. 5A, fig. 5B, fig. 5C, and the like, and details are not repeated here for brevity of the description.

It can be seen that, in the embodiment of the present application, context information storage, context switching and recovery, data transfer, and the like in the user state are all transferred to a new physical entity (i.e. an IPC engine) from time and space to be implemented, a kernel driver assists in completing registration of collee, initialization of the IPC engine, memory allocation, and the like in advance, after the controller actually initiates IPC, the IPC process may not require kernel participation, thereby avoiding the drawback of frequent switching of the user state and the kernel state in the existing IPC mechanism (e.g. binder mechanism), and implementing that the IPC engine and the CPU work in parallel on software, and thus releasing a large amount of software execution time of the CPU, and in order to cooperate with interaction between the IPC engine and the process in the hardware form, providing processor instructions in the user state for the controller and the controller to use: ipccall and ipcret, so as to facilitate the calling of interfaces, thereby satisfying the service calling of the caller and the call-back of the caller, realizing the interaction of the process on the user mode level, ensuring the realizability of the IPC process and greatly reducing the overall time delay of the IPC process. By implementing the embodiment of the application, application tests of the android platform show that the time delay of the IPC process can be reduced to 20 cycles, and compared with the prior art, the IPC time delay is remarkably reduced.

In addition, in the embodiment of the application, the data (such as small data) or the data access right can be transferred through the IPC engine. Specifically, the IPC engine maps the msg memory of the data to be transmitted, and the transmission of the data access right is realized without transmitting the data, so that the copy (copy) of the data is avoided, the time delay of data copy is further reduced, and the data transmission efficiency is improved.

In addition, by implementing the solution of the embodiment of the present application, after the IPC engine is initialized, the operating system allocates a shared memory, and the callee initiates registration to establish the page table of the process, and the callee is managed by the MMU, when the calller needs to call a service, the operating system allocates a memory segment for storing generation transfer data (msg) to the callee in the shared memory, and a mapping relationship between a virtual address and a physical address of the msg in the memory segment is consistent with a mapping relationship recorded in the page table managed by the MMU, so that, in subsequent IPC communication, after the IPC engine transfers msg VA from the callee to the callee, the callee can access the page table according to the VA to obtain the data, thereby achieving the purpose of sharing the memory by the callee and the callee, avoiding the change of the existing MMU workflow, avoiding the occurrence of a page fault, and ensuring the stability and security of IPC communication.

In the above embodiments, the descriptions of the respective embodiments have different emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.

Claims

A hardware system for inter-process communication IPC, comprising: processor core, IPC engine hardware, and memory, wherein:

the processor core is used for configuring a part of memory space in the memory into shared memory space of a process when the IPC engine hardware is initialized, and the shared memory space is used for storing data to be transmitted required by interprocess communication; establishing a page table according to the initial address and the length of the shared memory space, wherein the page table comprises a mapping relation from a virtual address to a physical address of the shared memory space;

the processor core is further configured to run a client process, and send a first processor instruction to the IPC engine hardware when the client process needs to call a service of the server process, where the first processor instruction is a call instruction of the client process to the service, and the call instruction includes an identifier of the server process and a virtual address of data to be transferred; the physical address of the data to be transmitted is positioned in the shared memory space;

the IPC engine hardware is used for indicating the processor core to run the server process according to the identifier and sending the virtual address of the data to be transmitted to the server process;

the processor core is further configured to run the server process, and the server process queries the page table according to the virtual address of the data to be transmitted to obtain the data to be transmitted so as to execute the service; and sending a second processor instruction to the IPC engine hardware, the second processor instruction being a return instruction of the server process;

the IPC engine hardware is further configured to instruct the processor core to resume running the client process according to the second processor instruction.
The hardware system of claim 1, wherein the processor core is further configured to, when the client process needs to invoke a service of a server process, configure a part of the memory space in the shared memory space to the client process so as to store the data to be transferred.
The hardware system according to claim 1 or 2,

before the client process is operated, the processor core is also used for sending registration information of the server process to the IPC engine hardware, wherein the registration information comprises the identification;

the IPC engine hardware is further to: receiving the registration information; saving the identification and the entry address of the server process in the IPC engine hardware in response to the registration information;

the IPC engine hardware is specifically configured to: finding the entry address according to the identification; setting the entry address to a Program Counter (PC) in the processor core;

the processor core is further configured to run the server process according to the entry address set in the PC.
The hardware system according to any one of claims 1 to 3,

the IPC engine hardware is also used for inquiring a state register in the processor core to obtain a call stack address of the client process after receiving the call instruction, and storing the call stack address of the client process in the IPC engine hardware;

the IPC engine hardware is specifically configured to call the call stack address according to the second processor instruction, and instruct the processor core to resume running the client process according to the call stack address.
The hardware system according to any one of claims 1 to 4,

the IPC engine hardware is specifically used for checking whether the client process and the server meet the requirements of inter-process communication, and when the client process and the server meet the requirements of inter-process communication, indicating the processor core to operate the server process according to the identifier.
The hardware system according to any one of claims 1 to 5,

the calling instruction and the returning instruction are both user mode instructions.
A method for inter-process communication IPC, comprising:

when an IPC engine is initialized by hardware, a processor core configures a part of memory space in a memory into shared memory space of processes, wherein the shared memory space is used for storing data to be transmitted required by interprocess communication; establishing a page table according to the initial address and the length of the shared memory space, wherein the page table comprises a mapping relation from a virtual address to a physical address of the shared memory space;

the processor core runs a client process, and when the client process needs to call the service of a server process, a first processor instruction is sent to IPC engine hardware, wherein the first processor instruction is a call instruction of the client process to the service, and the call instruction comprises an identifier of the server process and a virtual address of data to be transmitted; the physical address of the data to be transmitted is positioned in the shared memory space;

the IPC engine hardware indicates the processor core to run the server process according to the identifier and sends the virtual address of the data to be transmitted to the server process;

the processor core runs the server process, and the server process queries the page table according to the virtual address of the data to be transmitted to obtain the data to be transmitted so as to execute the service;

the processor core sends a second processor instruction to the IPC engine hardware, wherein the second processor instruction is a return instruction of the server process;

and the IPC engine hardware instructs the processor core to resume running the client process according to the second processor instruction.
The method of claim 1, further comprising:

and when the client process needs to call the service of the server process, the processor core configures a part of memory space in the shared memory space to the client process so as to store the data to be transmitted.
The method of claim 7 or 8, wherein before the processor core runs the client process, the method further comprises:

the processor core sends registration information of the server process to the IPC engine hardware, wherein the registration information comprises the identification;

the IPC engine hardware receives the registration information; saving the identification and the entry address of the server process in the IPC engine hardware in response to the registration information;

correspondingly, the IPC engine hardware instructs the processor core to run the server process according to the identifier, including:

the IPC engine finds the entry address according to the identification; setting the entry address to a Program Counter (PC) in the processor core;

and the processor core runs the server process according to the entry address set in the PC.
The method of any of claims 7-9, wherein after the processor core sends the first processor instruction to the IPC engine hardware, the method further comprises:

the IPC engine hardware inquires a state register in the processor core to obtain a call stack address of the client process, and stores the call stack address of the client process in the IPC engine hardware;

correspondingly, the IPC engine hardware instructs the processor core to resume running the client process according to the second processor instruction, including:

and calling out the call stack address by the IPC engine hardware according to the instruction of the second processor, and instructing the processor core to resume running the client process according to the call stack address.
The method of any of claims 7-10, wherein before the IPC engine hardware instructs the processor core to run the server process based on the identification, the method further comprises:

the IPC engine hardware checks whether the client process and the server meet the requirements of interprocess communication;

correspondingly, the step of instructing, by the IPC engine hardware, the processor core to run the server process according to the identifier specifically includes:

and when the client process and the server meet the requirements of inter-process communication, the IPC engine hardware indicates the processor core to operate the server process according to the identification.
The method according to any one of claims 7 to 11,

the calling instruction and the returning instruction are both user mode instructions.