WO2012062113A1

WO2012062113A1 - Method and system for realizing multi-core hot patching

Info

Publication number: WO2012062113A1
Application number: PCT/CN2011/075972
Authority: WO
Inventors: 汤时虎; 郑国春; 赵路
Original assignee: 中兴通讯股份有限公司
Priority date: 2010-11-12
Filing date: 2011-06-20
Publication date: 2012-05-18
Also published as: CN102467394A

Abstract

A method and system for realizing multi-core hot patching are provided. The method comprises: before executing a patching operation to codes, one of multiple core processing units notifies other core processing units which share code with the core processing unit, and the other core processing units wait for the completion of the patching operation after receiving the notice (S102); the core processing unit for executing the patching operation executes the patching operation (S104); and after completing the patching operation, the core processing unit for executing the patching operation notifies other core processing units of the completion of the patching operation (S106). The technical solution improves the stability of the system.

Description

The present invention relates to the field of communications, and in particular to a method and system for implementing a multi-core hot patch. BACKGROUND With the continuous development of the Central Processing Unit (CPU) technology, multi-core technology has become the mainstream. There are two traditional multi-core architectures: Asymmetrical Multi-Processing (abbreviated as AMP) and Symmetrical Multi-Processing (SMP). SMP is where multiple cores run an operating system that shares memory, bus, and other resources, and tasks are evenly distributed to each core for processing. In the SMP architecture, the status of each core is equal. In the AMP architecture, each core has its own master and time. Each core runs an operating system, and different types of tasks are handled according to the division of labor. In the AMP architecture, in order to save memory, the code of the same virtual address between multiple cores is usually mapped to the same physical address for code sharing. Defects and vulnerabilities are inevitable in any software system. 4 The methods of software defects are usually: Release a new version or patch. Since the release of the version involves more aspects, when the impact of the defect is small and the number is small, the patching method is usually adopted. The so-called patching, that is, using the correct code to correct the defects in the current software version, usually in the form of a patch file, such as the various patches released by the Windows operating system. In telecommunications services, the system is required to be quickly corrected after a software defect is discovered, and the system is not allowed to be interrupted to avoid unnecessary losses. The approximate flow of the patch operation is as follows: Step 1: Add the patch file patch.c to the existing project and compile the link into a new project. Step 2: Make a patch version. Step 3: The new patch version replaces the original version. Compared with the normal patch operation (cold patch;), the process of completing the patch operation without interrupting the system operation is called hot patch. The hot patch implementation method in the related art is only applicable to a single core system (one CPU), and a hot patch for a multi-core system may cause system instability or even service interruption. SUMMARY OF THE INVENTION A primary object of the present invention is to provide a multi-core hot patch implementation method and system, to at least solve the above-mentioned related art hot patch implementation method only applicable to a single core system (a CPU), and a hot patch for a multi-core system may result in The system is unstable or even the business is interrupted. In order to achieve the above object, according to an aspect of the present invention, a method for implementing a multi-core hot patch is provided. The multi-core hot patch according to the present invention includes: one of the plurality of core processing units notifying other core processing units sharing the code before performing the patch operation on the code, and the other core processing units waiting for the patch operation to be executed after receiving the notification The core processing unit that performs the patch operation performs the patch operation; after the patch operation is completed, the core processing unit that performs the patch operation notifies the other core processing unit that the patch operation is completed. One of the plurality of core processing units notifies other core processing units that share the code before performing the patch operation on the code, and the other core processing units wait for the execution of the patch operation after receiving the notification, including: a core processing unit that performs the patch operation^爹爹 tampering global shared variables to notify other core processing units with which they share code, where global shared variables are used for multi-core synchronization; other core processing units modify global variables to ready states to notify the core processing unit that performs the patch operation You are ready to perform the patch operation and wait for the patch operation to complete. The core processing unit performing the patch operation modifies the global shared variable to the patched state to notify other core processing units with which the code is shared; the other core processing units respectively tamper with the global variable to the ready state to notify the core processing of the patch operation. The unit is ready to perform the patch operation and waits for the patch operation to complete in the IDLE task (system idle task). One of the plurality of core processing units notifies other core processing units that share the code before performing the patch operation on the code, and the other core processing units wait for the execution of the patch operation after receiving the notification, including: the core processing unit performing the patch operation Other cores distribute inter-core interrupts to notify other core processing units with which they share code; other core processing units wait for the patch operation to complete after receiving the inter-core interrupt; after the patch operation is completed, the core processing unit that performs the patch operation The inter-core interrupt is sent again to notify other core processing unit that the patch operation has been completed. Before performing the patch operation, a fixed memory space is reserved for the patch corresponding to the patch operation. A core processing unit that identifies the shared code by setting a flag bit. The patch corresponding to the patch operation is a patch pair, and the patch pair includes a patched function and a patch function. The MAP file generated after the patch operation and the MAP file generated before the patch operation are consistent except for the reserved patch segment. According to another aspect of the present invention, an implementation system of a multi-core hot patch is provided. The implementation system of the multi-core hot patch according to the present invention includes: a core processing unit that performs a patch operation, comprising: a first notification module configured to notify other core processing units with which the code is shared before performing a patch operation on the code; The execution module is configured to perform a patch operation; the second notification module is configured to notify other core processing unit that the patch operation is completed after the execution of the patch operation is completed; and other core processing units, including: a waiting module, configured to receive the first After the notification of the notification module, the patch operation is completed. The first notification module includes: a first modification submodule, configured to modify the global shared variable to notify other core processing units with which the code is shared; the waiting module includes: a second modification submodule, configured to modify the global variable to a ready state, The core processing unit that notifies the execution of the patch operation is ready to perform the patch operation; the first waiting sub-module is set to wait for the patch operation to be completed. The first modification submodule is configured to modify the global shared variable to be patched to notify other core processing units with which the code is shared; the second modification submodule is set to modify the global variable to the ready state to notify the core processing of performing the patch operation The unit is ready to perform a patch operation. The first notification module includes: a first distribution sub-module configured to distribute an inter-core interrupt to other cores to notify other core processing units with which the code is shared; the second notification module includes: a second distribution sub-module, configured to be in a patch operation After the execution is completed, the inter-core interrupt is sent again to notify other core processing units that the patch operation is completed. The waiting module includes: a receiving sub-module, configured to receive an inter-core interrupt; and a second waiting sub-module, set to be interrupted after receiving the inter-core Wait for the patch operation to complete. Through the present invention, a plurality of core processing units are used, and the hot patch implementation method in the related art is only applicable to a single core system (one CPU), and the hot patch for the multi-core system may cause the system to be unstable or even interrupted, and further The implementation of the hot patch in the multi-core system avoids the loss caused by the system interruption and achieves the effect of improving the stability of the system. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are set to illustrate,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, In the drawings: FIG. 1 is a flowchart of a method for implementing a multi-core hot patch according to an embodiment of the present invention; FIG. 2 is a structural diagram of a foreground system and a background patch tool according to an embodiment of the present invention; FIG. 4 is a schematic diagram of a hot patch function of a multi-core system according to an embodiment of the present invention; FIG. 5 is a flowchart of processing a patch command according to an embodiment of the present invention; FIG. 7 is a flow chart of a multi-core synchronization according to an embodiment of the present invention; FIG. 8 is a flowchart of an implementation system of a multi-core hot patch according to an embodiment of the present invention; Block diagram; and FIG. 9 is a structural block diagram of an implementation system of a multi-core hot patch according to an embodiment of the present invention. BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, the present invention will be described in detail with reference to the accompanying drawings. It should be noted that the embodiments in the present application and the features in the embodiments may be combined with each other without conflict. This embodiment provides a method for implementing a multi-core hot patch. FIG. 1 is a flowchart of a hot patch implementation method according to an embodiment of the present invention. As shown in FIG. 1, the method includes: Step 4: S 102: One of the core processing units notifies other core processing units sharing the code before performing the patch operation on the code, and the other core processing units wait for the execution of the patch operation after receiving the notification; Step S104: Perform core processing of the patch operation The unit performs a patch operation; Step S106: After the execution of the patch operation is completed, the core processing unit that performs the patch operation notifies the other core processing unit that the patch operation is completed. Through the above step 4, one of the core processing units of the plurality of shared codes notifies other core processing units sharing the code to wait for the execution of the patch operation thereof before performing the patch operation on the code, and then notifies after the patch operation is performed. The other core processing unit patch operations with the shared code are executed, and the hot patch implementation method in the related art is only applicable to the single core processing unit, which causes system instability and business interruption in the multi-core processing unit system. The implementation of hot patching in a multi-core system has improved the stability of the system. Preferably, a preferred embodiment of step S102 is described below. The core processing unit 4 performing the patch operation tampers with the global shared variable to notify other core processing units with which the code is shared, wherein the global shared variable is used for multi-core synchronization; the other core processing units respectively tamper with the global variable to the ready state The core processing unit that notifies the execution of the patch operation is ready to perform the patch operation and waits for the patch operation to complete. With the preferred embodiment, it is implemented to modify the global shared variable to notify other core processing units related to the patch operation, and to tamper with the global variable to the ready state to notify that the patch operation is ready to be executed, and wait for the patch operation. After the execution is completed, synchronization between multiple cores is achieved without affecting the business process. Preferably, the core processing unit performing the patch operation tampers the global shared variable to the patched state to notify other core processing units with which the code is shared; the other core processing units respectively tamper with the global variable to the ready state to notify the execution of the patch The core processing unit of the operation is ready to perform the patch operation and wait for the patch operation to complete in the IDLE task. Through the preferred embodiment, the interaction of information between multiple cores is implemented by IDLE, which reduces the interruption delay of the hot patch and reduces the impact on the business process. A preferred embodiment of step S102 will now be described. The core processing unit performing the patch operation distributes the inter-core interrupt to other cores to notify other core processing units with which the code is shared; after receiving the interrupt, the other core processing units wait for the patch operation to be completed; after the execution of the patch operation is completed, the execution The core processing unit of the patch operation again sends an inter-core interrupt to notify other core processing unit that the patch operation is completed. With the preferred embodiment, the transfer of inter-core information in the hot patch is achieved by distributing inter-core interrupts. Preferably, a fixed memory space is reserved for the patch corresponding to the patch operation before the patch operation is performed. With the preferred embodiment, all memory except the patch file is guaranteed to be unaffected, and the correctness of executing the hot patch is guaranteed. Preferably, the core processing unit for identifying the shared code is identified by setting a flag bit. With the preferred embodiment, all core processing orders can be implemented by a core processing unit identified as a logo sharing code Meta-shared code or part of the core processing unit shared code, which can support both SMP-based and AMP-based systems. Preferably, the patch corresponding to the patch operation is a patch pair, and the patch pair includes a patched function and a patch function. With the preferred embodiment, the patched function and the patch function are used as patch pairs. When an error occurs in the patch operation, the patched function can be executed for system restoration, thereby improving the robustness of the system. Preferably, the MAP file generated after the patch operation and the MAP file generated before the patch operation are consistent except for the reserved patch segment. With this preferred embodiment, the accuracy of the patch to the file is guaranteed. Embodiment 1 This embodiment combines the foregoing embodiments and preferred embodiments thereof. In this embodiment, a method for implementing a multi-core hot patch is provided. The method includes: Step 1: Marking a core applicable to a patch function Number distribution (patches applicable bitmap). The patch function (the implementation of the error in the original system) and the patch function (the correct implementation for modifying the patched function) are called a pair of patches (Pair). If the pair of patches applies to a core, its corresponding bit position is 1. All patch pairs and other patch information (such as the binary implementation of the patch function, the distribution of the patch function in the patch segment, etc.) together form a patch file called a patch. In a complex system (referring to the AMP-architecture multi-core system), due to the need for functional partitioning, there may be multiple core shared code, single-core private code, or even a few core shared, other cores can not access the packet code, Through step 1, the code can be used to identify which cores are shared. Step 4: 2: Reserve patch segments in the original system. To ensure that the original system avoids call exceptions after the patch operation, you must ensure that in addition to the patch segment.

Other memory partitions (data segments, code segments, constant segments, etc.) are consistent before and after the patch. For example: In the original system, a function calls callp FuncOrigText. In the binary code generated after the link, _FuncOrigText is replaced by a memory address generated by the compilation. If the address of FuncOrigText before and after the patch is divided into 'J 0x1000 and 0x2000, then executing the function call after the patch will not get the correct result. To this end, the application is required to reserve a certain memory space (fixed size and fixed address) in advance for the hot patch module. The global variables, codes, constants, etc. defined in the file added during the patch must be specified in the patch segment, thereby ensuring All memory except the patch file is unaffected. Step 3: Use the background patch tool to create, verify, and distribute the patch package. 2 is an architectural diagram of a foreground system and a background patching tool according to an embodiment of the present invention. As shown in FIG. 2, the background patching tool sends a patch command to the foreground software system, and receives an execution result fed back from the foreground software system. The patch tool provides a user-friendly interface that allows the user to specify various configurations of the patch: such as the version number of the patch pair and the applicable core number of the patch pair. The patch tool extracts information about patch pairs from user-defined MAP files and OUT files: function names, function definitions, binary implementations, and more. The information is written to the patch package according to the defined format patch. Before making the patch package, in order to ensure the memory consistency in step 2, the patch tool provides the MAP file school-risk function, that is, the patch tool can determine whether the map file of the original system MAP file and the patch system is in addition to the patch segment. Nothing else is different. When the school-risk is consistent, the patch tool generates a patch package file. At the same time, the patch tool opens the TFTP server. Specifically, FIG. 3 is a flowchart of a patching tool for creating a patch package according to an embodiment of the present invention. As shown in FIG. 3, the method includes: Step S302: The user inputs various attribute information of the patch package on the patch tool. Step S304: Whether the patch tool school-risk system MAP file is consistent with the new system MAP. Step S306: The patch tool extracts patch segment information from the new system MAP file and the OUT file. Step 4: S308: The patch tool generates a patch package file. Step 4: The software system hot patch function module processes the patch request. When the software system initializes the hot patch module, it creates a patch processing task to process all commands related to the patch operation. These include: activating patches and uninstalling patches. When an existing patch requires a patch operation, the patch tool sends a command to the foreground software, the foreground hot patch module processes the command request, initiates the download of the TFTP request patch package file, and parses the patch package, and then configures the patch according to the content of the patch package. segment. 4 is a schematic diagram of a hot patch function of a multi-core system according to an embodiment of the present invention. As shown in FIG. 4, the hot patch function management module performs information interaction with a memory storage unit to complete patch command processing, patch version management, and code. . Cache (CACHE) synchronization, multi-core state synchronization and more. Step 5: After multi-core synchronization ^ ί 'tamper the jump code at the patched function. There is shared code in a multi-core system, one of which is under repair? When the patch is patched, other cores cannot execute the function. Preferably, all multi-core patch operations can be performed by the core with the smallest core number, and other cores are only responsible for cooperation with the core. The specific process of multi-core synchronization is as follows: The minimum core modifies the global shared variable and notifies other cores related to this patch operation. Other cores found that the core needs to be patched and enter IDLE. Modify the global shared variable to the ready state, and notify the minimum core that the core has been synchronized. Thereafter, the other cores die in the IDLE task until the minimum core completes the patch operation. When all the cores are synchronized, the minimum core starts to perform the patch operation. After the completion, the global variable is modified to the exit status to notify other cores to exit the synchronization. Specifically, FIG. 5 is a flowchart of processing a patch command according to an embodiment of the present invention, including: Step 4: S502: The patch tool sends a patch request command to a software system. Step S504: The minimum core change global variable notifies other cores to enter the multi-core synchronization state. Step S506: The other core receives the synchronization request, enters the IDLE task, modifies the global variable, and dies. Step S508: The minimum core configures the patch segment after the other cores are synchronized, and modifies the jump code of the patched function. Step S510: The minimum core patch operation is completed, and the other cores are notified to leave the multi-core synchronization state. Preferably, the synchronization process can also be implemented in the following manner. The primary core is responsible for receiving the patch request and distributing the inter-core interrupt to other cores that need to cooperate. The other cores receive the inter-core interrupt for the first time (the main core is ready to start the hot patch operation) and wait until the primary core is received again. If the inter-core interrupt is sent, the primary core can be considered to have completed the hot patch operation, returning from the interrupt and continuing to execute the business process. However, the drawback of this method is that it may affect the business process, and the delay of the interruption is relatively large. In addition, multi-core synchronization can also be achieved by using a multi-core synchronization mechanism such as inter-core semaphores and inter-core mailboxes. Step 6: The software system manages different patch versions. After the patch is downloaded to the foreground, it is backed up in memory. Different versions of the patch are allowed to exist in the current system at the same time as the memory allows. This feature is an add-on feature that allows users to define multiple fix packs for flexible operation and more comprehensive support for unit and integration testing. It should be noted that the technical solution presented in the foregoing embodiment is implemented in a multi-core DSP system, but the same applies to other single-core systems or multi-core systems, and is not mentioned here. Embodiment 2 This embodiment provides a multi-core hot patch implementation method. The system environment in this embodiment is a multi-core AMP system, as shown in FIG. 6, n=5. Among them, the code segment is divided into 3 types: 1) 6 core shared code, called ST; 2) core 0, core 1 shared group code, called G1T; 3) core 2 3, 4, 5 Shared grouping code, called G2T. Suppose there are 3 functions in the original software system: ST_Func, GlT_Func, G2T Func. Now we find that these three functions have errors, so we want to patch them. The corresponding patch functions are ST_Func_Patch, GlT Func Patch and G2T_Func_Patch. The method includes the following steps: Step 1: Implement the patch function, compile the patch project, and generate the patch code. Specifically, write the implementation of ST_Func_Patch, GlT Func Patch, and G2T_Func_Patch into Patch.c, and add a patch to the original system project. .c, compile the patch project using the build environment or Makefile to generate new map files and out files. It should be noted that for the sake of optimization, the uncalled function may not be linked to the new out file. Take steps to ensure that the patch function is linked. Step 2: Create a patch package file Specifically, connect the software system to the patch tool. The user sets the patch pair (ST_Func, ST Func Patch), (GlT_Func, GlT Func Patch) in turn through the patch tool. ), ( G2T_Func, G2T_Func_Patch ) attributes: version number, applicable And specify the map file and out file generated by the patch project, and specify the map file of the original system. The patch tool first compares the difference between the two map files, only when all the differences are in the reserved memory of the patch segment, 2 The map file is considered to be a match. If the map file does not match, the next step cannot be continued. Then, the patch tool finds the function address of the patch pair from the new map file, and extracts the entire patch segment content from the out file. Finally, it is packaged into a patch package according to the agreed format. Step 3: Send a patch activation or uninstall command. Specifically, the activation command is used by the software system to download the patch package file from the background host to the memory, and replace the patch function with the patch function in the patch package. The patch function is used to remove the currently running patch package, the system status is restored to the state before the patch, and the backup of the patch package is deleted from the memory. Step 4: The hot patch task processes the patch request. Including step a and step b. Step a: If the patch tool sends an activation to the software system So, the patch tool to open a TFTP server locally, while the IP address of the TFTP server, the local patch storage path, patch version number as an additional command is sent to the reception system parameters. The parameters of the reception Download the patch package to the local host, and then apply dynamic memory from the memory to back up the patch package and the code of the patched function. When the backup job is completed, the smallest core that is currently running starts to perform the patch operation. Synchronization of multi-core systems uses global shared variables to flag the state of each core for synchronization. Volatile unsigned int gaudCoresPatchStat[6]; 〃 flag multi-core synchronization state. Each core of this embodiment corresponds to an index of gaudCoresPatchStat. There are three possible states for gaudCoresPatchStat: PM SYNC ENTER , PM SYNC READY, PM SYNC EXIT. PM SYNC ENTER indicates that the core currently needs to enter the synchronization state, but the synchronization has not yet been completed. PM_SYNC_READY indicates that the core has entered the synchronization state. PM_SYNC_EXIT indicates that the core can exit the synchronization state. FIG. 7 is a flowchart of multi-core synchronization according to an embodiment of the present invention. As shown in FIG. 7, the method includes: Step S702: The minimum core modifies the core flag related to the current patch operation to PM SYNC ENTER. Step S704: The minimum core configuration patch segment. Step S706: The minimum core modification patch function jump code. Step S708: Update gtCachetrl (multi-core cache control information variable). Step S710: The minimum core modifies gaudCoresPatchStat (weight synchronization state flag variable) to PM SYNC EXIT. Step S712: feedback the execution result, and exit. Step S714: After the other cores enter the IDLE task, check whether the flag of the core is

PM SYNC ENTER, if yes, change the flag of this core to PM_SYNC_READY. Step S716: Then die, until the flag of the core is PM_SYNC_EXIT. The minimum core copies the patch code segments, data segments, and constant segments saved in the patch package file to the corresponding physical memory after all the cores are synchronized. Then modify the first instruction of the patched function in turn, and change it to the entry address of its patch function. For example: ST Func's first instruction should be modified to jmp ST Func Patch, where _ST_Func_Patch should be a specific memory address. It is important to note that after executing the ST Func Patch, the PC pointer should be returned to the address where ST Func is called. Step S718: At the same time, since the code segment may be cacheable, after the minimum core modifies the code of the patched function, the other core should be notified to refresh the cache of the patched function, so that other cores still execute the old code in the cache. The specific implementation scheme is as follows: Define a global structure variable gtCacheCtrl, and save the data related to the patched function in the patch package. After the minimum core performs the patch operation, the information in the patch package is backed up to gtCacheCtrl. Other cores will flush the gtCacheCtrl content to the cache before exiting the IDLE task, completing the synchronization of the memory and the cache. Step S720: After the minimum core completes the above work, the flag of the patch-related core is modified to be PM_SYNC_EXIT. Other cores were able to exit in the IDLE task and continue to execute. Step b: If the patch tool sends an uninstall command to the software system, the foreground system performs the following operations: The information of the original patch function of the backup is used to restore the system state before the patch. The synchronization operation in this process is consistent with the above. Then, all the dynamic memory that is applied during the patch activation process is released, and the backup patch file is deleted to avoid the hidden danger of the memory leak in the system. Step 5: Hot patch task feedback processing results. The result of the final processing of the foreground system is fed back to the background patch tool in the form of an error code. This embodiment provides a system for implementing a multi-core hot patch. FIG. 8 is a structural block diagram of a system for implementing a multi-core hot patch according to an embodiment of the present invention. As shown in FIG. 8, the foregoing structure is described in detail: The core processing unit 2 of the operation, comprising: a first notification module 82, configured to notify other core processing units sharing the code with the code before performing the patch operation on the code; the execution module 84 is connected to the first notification module 82, and is set to After the first notification module 82 notifies the other core processing units with which the code is shared, the patch operation is performed; the second notification module 86 is connected to the execution module 84, and is configured to notify other core processing after the execution of the patch operation of the execution module 84 is completed. The unit patch operation is completed; the other core processing unit 4 includes: a waiting module 88, configured to wait for the execution of the patch operation after receiving the notification of the first notification module 82. FIG. 9 is a block diagram showing a preferred structure of an implementation system of a multi-core hot patch according to an embodiment of the present invention. As shown in FIG. 9, the foregoing structure is described in detail. The first notification module 82 includes: a first modification submodule 822, set to modify the global shared variable to notify other core processing units with which to share the code; the waiting module 88 includes: a second modification sub-module 882, configured to modify the global variable to the ready state to notify the core processing unit that performs the patch operation It is ready to perform the patch operation; the first wait sub-module 884, connected to the second modification sub-module 882, is set to wait for the patch operation to complete. Preferably, the first modification submodule 822 is configured to modify the global shared variable to be in a state to be synchronized to notify other core processing units with which the code is shared; the second modification submodule 882 is set to modify the global variable to a ready state to notify execution The core processing unit of the patch operation is ready to perform the patch operation. The first notification module 82 includes: a first distribution sub-module 824 configured to distribute inter-core interrupts to other cores to notify other core processing units with which the code is shared; the second notification module 86 includes: a second distribution sub-module 862, setting After the execution of the patch operation is completed, the inter-core interrupt is sent again to notify other core processing unit that the patch operation is completed. The waiting module 88 includes: a receiving submodule 886, configured to receive the inter-core interrupt; and a second waiting sub-module 888, the connection The receiving sub-module 886 is configured to wait for the execution of the patch operation after receiving the inter-core interrupt; and the foregoing embodiment provides a multi-core hot patch implementation method and system, by which the core processing unit of multiple shared codes is provided One of the other core processing units that have shared the code waits for the completion of the patch operation before performing the patch operation on the code, and then notifies the other core processing unit of the shared code that the patch operation is completed after the patch operation is performed, overcoming The hot patch implementation method in the related art only applies Single-core processing unit, multi-core processing units in the system can cause problems in system instability and service interruption, to achieve a hot patches in multi-core systems to achieve the effect of improving the stability of the system. Obviously, those skilled in the art should understand that the above modules or steps of the present invention can be implemented by a general-purpose computing device, which can be concentrated on a single computing device or distributed over a network composed of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device, such that they may be stored in the storage device by the computing device, and in some In this case, the steps shown or described may be performed in an order different from that herein, or they may be separately fabricated into individual integrated circuit modules, or a plurality of the modules or steps may be implemented as a single integrated circuit module. Thus, the invention is not limited to any specific combination of hardware and software. The above is only the preferred embodiment of the present invention, and is not intended to limit the present invention, and various modifications and changes can be made to the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the scope of the present invention are intended to be included within the scope of the present invention.

Claims

1. A method for implementing a multi-core hot patch, comprising:

One of the plurality of core processing units notifies other core processing units with which the code is shared before performing the patching operation on the code, the other core processing unit waiting for the execution of the patch operation after receiving the notification;

The core processing unit that performs the patch operation performs the patch operation. After the patch operation is completed, the core processing unit that executes the patch operation notifies the other core processing unit that the patch operation is completed.

2. The method of claim 1 wherein one of the plurality of core processing units notifies other core processing units with which the code is shared prior to performing a patch operation on the code, the other core processing unit being Waiting for the execution of the patch operation after receiving the notification includes:

The core processing unit executing the patch operation tampers with the global shared variable to notify other core processing units with which the code is shared, wherein the global shared variable is used for multi-core synchronization;

The other core processing unit respectively modifies the global variable to a ready state to notify the core processing unit that performs the patch operation that it is ready to perform a patch operation, and waits for the patch operation to be completed.

3. The method of claim 2, wherein:

The core processing unit 4 executing the patch operation tampers the global shared variable into a to-be-patched state to notify other core processing units with which the code is shared;

The other core processing unit respectively modifies the global variable to a ready state to notify the core processing unit that performs the patch operation that it is ready to perform a patch operation, and waits for the patch operation to be completed in the idle IDLE task.

4. The method of claim 1, wherein one of the plurality of core processing units notifies other core processing units with which the code is shared prior to performing a patch operation on the code, the other core processing unit being Waiting for the execution of the patch operation after receiving the notification includes: A core processing unit performing the patch operation distributes an inter-core interrupt to the other core to notify other core processing units with which the code is shared; the other core processing unit waits after receiving the inter-core interrupt The patch operation is completed;

After the execution of the patch operation is completed, the core processing unit that performs the patch operation transmits an inter-core interrupt again to notify the other core processing unit that the patch operation is completed.

The method according to any one of claims 1 to 4, wherein a fixed memory space is reserved for a patch corresponding to the patch operation before the patch operation is performed.

The method according to any one of claims 1 to 4, wherein the flag is used to identify a core processing unit that shares the code.

The method according to any one of claims 1 to 4, wherein the patch corresponding to the patch operation is a patch pair, and the patch pair includes a patched function and a patch function.

8. The method of claim 7, wherein the MAP file generated after the patch operation and the MAP file generated before the patch operation are consistent except for the reserved patch segment.

9. A system for implementing a multi-core hot patch, comprising:

A core processing unit that performs a patch operation, which includes:

a first notification module, configured to notify other core processing units with which the code is shared before performing a patch operation on the code;

An execution module, configured to perform the patch operation;

a second notification module, configured to notify the other core processing unit that the patch operation is completed after the execution of the patch operation is completed;

The other core processing unit includes:

The waiting module is configured to wait for the completion of the patch operation after receiving the notification of the first notification module. The system of claim 9

The first notification module includes: a first modification submodule, configured to modify the global shared variable to notify other core processing units with which the code is shared;

The waiting module includes:

a second modification submodule, configured to modify the global variable to a ready state to notify the core processing unit that performs the patch operation that it is ready to perform a patch operation;

The first waiting sub-module is set to wait for the patch operation to be completed.

11. The system of claim 10, wherein:

The first modifying submodule is configured to modify the global shared variable to be in a patched state to notify other core processing units with which the code is shared; and the second modified submodule is configured to modify the global variable to a ready state to notify The core processing unit that performs the patch operation is ready to perform a patch operation.

12. The system according to claim 9, wherein

The first notification module includes:

a first distribution sub-module configured to distribute an inter-core interrupt to the other core to notify other core processing units with which the code is shared;

The second notification module includes:

a second distribution sub-module, configured to: after the execution of the patch operation is completed, send an inter-core interrupt to notify the other core processing unit that the patch operation is completed;

The waiting module includes:

Receiving a submodule, configured to receive the inter-core interrupt;

The second waiting sub-module is arranged to wait for the execution of the patch operation after receiving the inter-core interrupt.