Method, device and storage medium for implementing serialization and deserialization of logical pointers

Abstract

The present disclosure relates to methods, systems, integrated circuit devices, boards, and computer-readable storage media that implement serialization and deserialization of logical pointers, where a system-on-a-chip of the present disclosure is included in an integrated circuit device that includes a general interconnect interface and other processing devices. A computing device interacts with the other processing devices to collectively perform a user-specified computing operation. The integrated circuit device can also include a storage device connected to the computing device and the other processing devices, respectively, for data storage of the computing device and the other processing devices.

Description

Technical Field

[0001] This disclosure generally relates to the field of computers. More specifically, this disclosure relates to a method, system, integrated circuit device, board, and computer-readable storage medium for implementing serialization and deserialization logic pointers. Background Technology

[0002] Live migration, also known as dynamic migration or real-time migration, refers to the process of migrating a virtual machine from one physical server to another by saving its entire running state using a save / load procedure. After recovery, the virtual machine continues to run smoothly, and users will not notice any difference.

[0003] In the field of artificial intelligence, the high complexity of Application-Specific Integrated Circuits (ASICs) makes complete hot migration impossible. In particular, how the source server serializes information and how the destination server deserializes information during hot migration are problems that need to be addressed in existing technologies. Summary of the Invention

[0004] To at least partially solve the technical problems mentioned in the background art, the present disclosure provides a method, system, integrated circuit device, board, and computer-readable storage medium for implementing serialization and deserialization logic pointers.

[0005] According to one aspect of this disclosure, a system for serializing logical pointers is provided, comprising: memory and a serialization device. The memory is used to store a first structure and a second structure. The serialization device is used to: generate migration information in response to a hot migration initiation request; generate a first symbolic identifier and a first entity identifier in the data structure of the migration information; place the name of the first structure into the first symbolic identifier; and place the name of the logical pointer, wherein the name of the logical pointer is the name of the second structure, into the first entity identifier.

[0006] According to another aspect of this disclosure, a system for deserializing logical pointers is provided, including a deserializing device for: receiving information to be migrated, the data structure of the information to be migrated including a first symbol identifier and a first entity identifier; extracting the name of the first structure from the first symbol identifier; and extracting the name of the second structure from the first entity identifier.

[0007] According to another aspect of this disclosure, an integrated circuit device is provided, including the system described in any of the preceding claims, and a board is provided, including the said integrated circuit device.

[0008] According to another aspect of this disclosure, a method for serializing logical pointers is provided, the logical pointers associating a first structure with a second structure, the method comprising: responding to a hot migration initiation request to generate information to be migrated; generating a first symbol identifier and a first entity identifier in a data structure of the information to be migrated; placing the name of the first structure into the first symbol identifier; and placing the name of the second structure into the first entity identifier.

[0009] According to another aspect of this disclosure, a method for deserializing a logical pointer is provided, comprising: receiving information to be migrated, wherein the data structure of the information to be migrated includes a first symbol identifier and a first entity identifier; extracting the name of the first structure from the first symbol identifier; and extracting the name of the second structure from the first entity identifier.

[0010] According to another aspect of this disclosure, a computer-readable storage medium is provided that stores computer program code containing serialized or deserialized logical pointers, which, when run by a processor, performs the aforementioned method.

[0011] This disclosure enables the serialization of information on the source server and the deserialization of information on the destination server, achieving the technical effect of hot migration. Attached Figure Description

[0012] The description of exemplary embodiments of the present disclosure, as well as other objects, features, and advantages, will become readily understood by reading the following detailed description with reference to the accompanying drawings. In the drawings, several embodiments of the present disclosure are illustrated by way of example and not limitation, and like or corresponding reference numerals denote like or corresponding parts, wherein:

[0013] Figure 1 This is a schematic diagram illustrating an artificial intelligence chip framework according to an embodiment of the present disclosure;

[0014] Figure 2 This is a schematic diagram illustrating the internal structure of a computing device according to an embodiment of the present disclosure;

[0015] Figure 3 This is a flowchart of the migration and save path according to an embodiment of this disclosure;

[0016] Figure 4 This is a schematic diagram illustrating the migration and saving path on the source server side according to an embodiment of this disclosure;

[0017] Figure 5 This is a schematic diagram showing the data structure of the information to be migrated;

[0018] Figure 6 This is a schematic diagram illustrating the structure of an embodiment of the present disclosure at the data structure layer;

[0019] Figure 7 This is exemplary tree data illustrating an embodiment of this disclosure;

[0020] Figure 8 This shows the serialized data obtained when traversing tree data according to an embodiment of this disclosure;

[0021] Figure 9 This shows the data structure generated during nested data serialization;

[0022] Figure 10 This is a schematic diagram illustrating how a serialization device serializes a structure including logical pointers into information to be transferred;

[0023] Figure 11 This is a flowchart illustrating the data structure used to generate the information to be migrated;

[0024] Figure 12 This is a flowchart illustrating the data structure used to generate the information to be migrated;

[0025] Figure 13 This is a flowchart illustrating the serialization of tree data according to an embodiment of the present disclosure;

[0026] Figure 14 This is a flowchart illustrating the generation of migration information according to an embodiment of this disclosure;

[0027] Figure 15 This is a flowchart illustrating the serialization logic pointer in an embodiment of this disclosure;

[0028] Figure 16 This is a flowchart illustrating the migration recovery path of an embodiment of this disclosure;

[0029] Figure 17 This is a schematic diagram illustrating the migration and recovery path performed on the target server side according to an embodiment of this disclosure;

[0030] Figure 18 This is a flowchart illustrating the hot migration recovery path implemented by the deserialization apparatus according to an embodiment of the present disclosure;

[0031] Figure 19 This is a flowchart illustrating the deserialization protocol layer of the deserialization apparatus according to an embodiment of the present disclosure;

[0032] Figure 20 This is a flowchart illustrating the deserialization configuration information of an embodiment of this disclosure;

[0033] Figure 21 This is a flowchart illustrating deserialized data information according to an embodiment of the present disclosure;

[0034] Figure 22 This is a flowchart illustrating the identification or extraction of information from the serialization layer according to an embodiment of the present disclosure;

[0035] Figure 23 This is a flowchart illustrating the deserialization of tree data according to an embodiment of the present disclosure;

[0036] Figure 24 This is a flowchart illustrating the deserialization of nested data according to an embodiment of the present disclosure;

[0037] Figure 25 This is a schematic diagram illustrating nested data in an embodiment of this disclosure;

[0038] Figure 26 This is a flowchart illustrating the identification or retrieval of information about the second-layer structure according to an embodiment of this disclosure;

[0039] Figure 27 This is a flowchart illustrating the deserialization logic pointer of an embodiment of this disclosure;

[0040] Figure 28 This is a structural diagram illustrating an integrated circuit device according to an embodiment of the present disclosure; and

[0041] Figure 29 This is a schematic diagram illustrating a board card according to an embodiment of the present disclosure. Detailed Implementation

[0042] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. The described embodiments are some, but not all, of the embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0043] It should be understood that the terms "first," "second," "third," and "fourth," etc., in the claims, specification, and drawings of this disclosure are used to distinguish different objects, rather than to describe a specific order. The terms "comprising" and "including" as used in the specification and claims of this disclosure indicate the presence of the described features, integrals, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof.

[0044] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this disclosure. As used in this disclosure and claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this disclosure and claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes such combinations.

[0045] As used in this specification and claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection."

[0046] The specific embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0047] This disclosure relates to a framework employing virtualization technology applied on application-specific integrated circuits (ASICs), such as machine learning devices for neural networks, which may be convolutional neural network accelerators. An example of an artificial intelligence chip will be used below for illustration.

[0048] Figure 1 This is a framework diagram of artificial intelligence chip virtualization. The framework 100 includes user space 102, kernel space 104, and on-chip system 106, separated by dashed lines. User space 102 is the runtime space for user programs, performing only simple calculations and cannot directly access system resources. Instructions must be sent to kernel space 104 through the system interface. Kernel space 104 is the space where kernel code runs, capable of executing arbitrary commands and accessing all system resources. On-chip system 106 comprises the various modules of the artificial intelligence chip, collaborating with user space 102 through kernel space 104.

[0049] In this embodiment, the hardware of user space 102 is uniformly referred to as a device or apparatus, and the hardware of system-on-chip 106 is uniformly referred to as a device or unit, for distinction. This arrangement is only for the purpose of more clearly describing the technology of this embodiment and is not intended to limit the technology of this disclosure in any way.

[0050] Unless otherwise emphasized, this embodiment is illustrated by virtualizing one physical component into four virtual components, but this disclosure does not limit the number of virtual components.

[0051] Before virtualization is implemented, user space 102 is controlled by hardware monitoring tool 108, which obtains information about the on-chip system 106 through interface calls. Hardware monitoring tool 108 can not only collect information about the on-chip system 106, but also obtain real-time data on the resource consumption of the on-chip system 106 by upper-layer software. This allows users to monitor the current detailed information and status of the on-chip system 106 in real time. This detailed information and status can include dozens of data points such as hardware device model, firmware version number, driver version number, device utilization, storage device overhead status, board power consumption and peak power consumption, and PCIe (High-Speed ​​Interconnect) technology. The content and quantity of monitored information may vary depending on the version of hardware monitoring tool 108 and the usage scenario.

[0052] After the system starts virtualization, the operation of user space 102 is taken over by user virtual machine 110. User virtual machine 110 is an abstraction and simulation of the real computing environment. The system allocates a set of data structures to manage the state of user virtual machine 110, including a full set of registers, physical memory usage, virtual device status, etc. In this embodiment, the physical space virtualization of user space 102 consists of four virtual spaces 112, 114, 116, and 118. These four virtual spaces 112, 114, 116, and 118 are independent and do not affect each other. They can each host different guest operating systems, such as guest operating system 1, guest operating system 2, guest operating system 3, and guest operating system 4 as shown in the figure. The guest operating system can be Windows, Linux, Unix, iOS, Android, etc., and different applications run on each guest operating system.

[0053] In this disclosed environment, the user virtual machine 110 is implemented using a Quick Emulator (QEMU). QEMU is an open-source virtualization software written in C that virtualizes interfaces through dynamic binary translation and provides a series of hardware models, enabling guest operating systems 1, 2, 3, and 4 to believe they are directly accessing the on-chip system 106. User space 102 includes processors, memory, I / O devices, etc. QEMU can virtualize the processor in user space 102 into four virtual processors, the memory into four virtual memories, and the I / O devices into four virtual I / O devices. Each guest operating system occupies a portion of the resources in user space 102, for example, one-quarter each, meaning each can access one virtual processor, one virtual memory, and one virtual I / O device to execute its tasks. Through this mode, guest operating systems 1, 2, 3, and 4 can operate independently.

[0054] Kernel space 104 hosts kernel virtual machine 120 and chip driver 122. Kernel virtual machine 120, in conjunction with QEMU, is primarily responsible for the virtualization of kernel space 104 and system-on-chip 106, ensuring that each guest operating system can obtain its own address space when accessing system-on-chip 106. More specifically, the address space mapped to the guest operating system on system-on-chip 106 is actually a virtual component mapped to that process.

[0055] The kernel virtual machine 120 includes a physical function driver, which is a driver specifically designed to manage the global functions of the SR-IOV device. It generally requires higher privileges than a regular virtual machine to operate. The physical function driver contains all the functionality of traditional drivers, enabling user space 102 to access the I / O resources of the system-on-chip 106.

[0056] From the perspective of user virtual machine 110, during virtual machine operation, QEMU performs kernel settings through the system call interface provided by kernel virtual machine 120. QEMU utilizes the virtualization capabilities of kernel virtual machine 120 to provide hardware virtualization acceleration for its virtual machine, thereby improving virtual machine performance. From the perspective of kernel virtual machine 120, when users cannot directly interact with kernel space 104, they need to rely on the management tools of user space 102, thus requiring the use of QEMU, a tool running in user space 102.

[0057] Chip driver 122 is used to drive physical function (PF) 126. During virtual machine operation, user space 102 does not access on-chip system 106 through chip driver 122 by hardware monitor tool 108. Therefore, guest operating system 1, guest operating system 2, guest operating system 3, and guest operating system 4 are configured with user-end kernel space 124 to load chip driver 122, so that each guest operating system can still drive on-chip system 106.

[0058] The System-on-a-Chip 106 performs virtualization through Single Root I / O Virtualization (SR-IOV) technology. More specifically, in the context of this disclosure, SR-IOV technology is implemented through a combination of hardware and software, enabling the virtualization of various components of the System-on-a-Chip 106. SR-IOV technology is a virtualization solution that allows for efficient sharing of PCIe resources among virtual machines. SR-IOV technology enables a single PCIe resource to be shared by multiple virtual components of the System-on-a-Chip 106, providing dedicated resources for these virtual components. In this way, each virtual component has its own uniquely accessible resource.

[0059] The system-on-chip 106 in this embodiment includes hardware and firmware. The hardware includes a read-only memory (ROM) (not shown) for storing the firmware, which includes physical functions 126 for supporting or cooperating with SR-IOV's PCIe functionality. Physical function 126 has full authority to configure PCIe resources. When implementing SR-IOV technology, physical function 126 virtualizes multiple virtual functions (VFs) 128; in this embodiment, there are four virtual functions 128. A virtual function 128 is a lightweight PCIe function managed by physical function 126 and can share PCIe physical resources with physical function 126 and other virtual functions 128 associated with the same physical function 126. Virtual functions 128 are only allowed to control the resources configured by physical function 126 for themselves.

[0060] Once SR-IOV is enabled in physical function 126, each virtual function 128 can access its own PCIe configuration space via its own bus, device, and function number. Each virtual function 128 has a memory space for mapping its register set. The virtual function 128 driver operates on the register set to enable its function and directly assigns it to the corresponding user virtual machine 110. Although virtual, it is perceived by the user virtual machine 110 as a real PCIe device.

[0061] The hardware of the system-on-a-chip 106 also includes a computing device 130, a video encoding / decoding device 132, a JPEG encoding / decoding device 134, a storage device 136, and a PCIe 138. In this embodiment, the computing device 130 is an intelligent processing unit (IPU) used to perform convolution calculations of neural networks; the video encoding / decoding device 132 is used to encode and decode video data; the JPEG encoding / decoding device 134 is used to encode and decode still images using the JPEG algorithm; the storage device 136 can be dynamic random access memory (DRAM) used to store data; the PCIe 138 is the aforementioned PCIe, which is virtualized into four virtual interfaces 140 during virtual machine operation. The virtual functions 128 and virtual interfaces 140 have a one-to-one correspondence, that is, the first virtual function is connected to the first virtual interface, the second virtual function is connected to the second virtual interface, and so on.

[0062] Using SR-IOV technology, computing device 130 is virtualized into four virtual computing devices 142, video encoding / decoding device 132 is virtualized into four virtual video encoding / decoding devices 144, JPEG encoding / decoding device 134 is virtualized into four virtual JPEG encoding / decoding devices 146, and storage device 136 is virtualized into four virtual storage devices 148.

[0063] Each guest operating system is configured with a set of virtual suites. Each set of virtual suites includes a user virtual machine 110, a virtual interface 140, a virtual function 128, a virtual computing device 142, a virtual video codec device 144, a virtual JPEG codec device 146, and a virtual storage device 148. Each set of virtual suites operates independently and does not affect others. They are used to execute the tasks assigned by the corresponding guest operating system to determine whether each guest operating system can access the configured virtual computing device 142, virtual video codec device 144, virtual JPEG codec device 146, and virtual storage device 148 through the configured virtual interface 140 and virtual function 128.

[0064] More specifically, each guest operating system may access different hardware depending on the task being performed. For example, if a task involves matrix convolution calculation, the guest operating system will access the configured virtual computing device 142 through the configured virtual interface 140 and virtual function 128; if a task involves video encoding / decoding, the guest operating system will access the configured virtual video encoding / decoding device 144 through the configured virtual interface 140 and virtual function 128; if a task involves JPEG encoding / decoding, the guest operating system will access the configured virtual JPEG encoding / decoding device 146 through the configured virtual interface 140 and virtual function 128; and if a task involves reading or writing data, the guest operating system will access the configured virtual storage device 148 through the configured virtual interface 140 and virtual function 128.

[0065] Figure 2 A schematic diagram of the internal structure of a multi-core computing device 130 is shown. The computing device 130 has sixteen processing unit cores (processing unit cores 0 to 15) for performing matrix calculation tasks. Every four processing unit cores form a processing unit group, or cluster. More specifically, processing unit cores 0 to 3 form the first cluster 202, processing unit cores 4 to 7 form the second cluster 204, processing unit cores 8 to 11 form the third cluster 206, and processing unit cores 12 to 15 form the fourth cluster 208. The computing device 130 essentially performs computing tasks in cluster units.

[0066] The computing device 130 also includes a storage unit core 210 and a shared storage unit 212. The storage unit core 210 is mainly used to control data exchange, serving as a communication channel between the computing device 130 and the storage device 136. The shared storage unit 212 is used to temporarily store intermediate computation values ​​of these clusters 202, 204, 206, and 208. During virtualization operation, the storage unit core 210 is divided into four virtual storage unit cores, and the shared storage unit 212 is also divided into four virtual shared storage units.

[0067] Each virtual computing device 142 is configured with a virtual memory unit core, a virtual shared memory unit, and a cluster to support the tasks of a specific guest operating system. Similarly, each virtual computing device 142 operates independently and does not affect the others.

[0068] The number of clusters of computing device 130 should be at least the same as the number of virtual computing devices 142 to ensure that each virtual computing device 142 can be configured with a cluster. When the number of clusters exceeds the number of virtual computing devices 142, clusters can be appropriately configured to virtual computing devices 142 according to actual needs to increase hardware configuration flexibility.

[0069] The video codec device 132 in this embodiment includes six video codec units. The video codec device 132 can flexibly allocate resources based on the number of virtual components and required resources, using video codec units as the unit of allocation. For example, if the video codec device 132 is virtualized into four virtual video codec devices 144, and assuming the first and second virtual video codec devices require more video codec resources, then two video codec units can be allocated to the first and second virtual video codec devices respectively, while one video codec unit can be allocated to each of the other virtual video codec devices 144. Alternatively, if the video codec device 132 is virtualized into three virtual video codec devices 144, and none of the virtual video codec devices require much video codec resources, then two video codec units can be allocated to each virtual video codec device 144.

[0070] The number of video codec units should be at least the same as the number of virtual video codec devices 144 to ensure that each virtual video codec device 144 can be configured with one video codec unit. When the number of video codec units exceeds the number of virtual video codec devices 144, the video codec units can be appropriately configured to the virtual video codec devices 144 according to actual needs to increase hardware configuration flexibility.

[0071] Similarly, the JPEG encoding / decoding device 134 in this embodiment includes six JPEG encoding / decoding units. The JPEG encoding / decoding device 134 can flexibly allocate resources in units of JPEG encoding / decoding units according to the number of virtual components and the required resources. The allocation method is the same as that of the video encoding / decoding device 132, so it will not be described in detail.

[0072] Storage device 136 can adopt a non-uniform memory access (NUMA) architecture, including multiple DDR channels. Storage device 136 can flexibly allocate resources in units of DDR channels according to the number of virtual components and the required resources. Its allocation method is no different from that of computing device 130, video codec device 132 and JPEG codec device 134, so it will not be described in detail.

[0073] One application scenario of this disclosure is a cloud-based data center. Data centers require maintenance to ensure the stability and smoothness of the entire system. This maintenance involves computer sharing, database backup, troubleshooting, addressing uneven resource allocation (such as overload or underload), and routine maintenance. While performing the aforementioned maintenance, the data center must also ensure the normal operation of the system so that users do not perceive any difference. This disclosure is based on... Figure 1 and Figure 2 The architecture enables a hot migration technique that completely saves the running state of the entire virtual machine and quickly restores it to the original hardware platform or even a different hardware platform. After restoration, the virtual machine continues to run smoothly.

[0074] Based on the aforementioned exemplary framework, the hot migration solution disclosed herein consists of two stages: the first stage is to package and send the configuration and data on the source server to the destination server, i.e., the migration save path; the second stage is to place these configurations and data in the corresponding locations on the destination server, i.e., the migration restore path. This hot migration solution completely saves the entire virtual machine's running state and data, and then quickly restores it to the original hardware platform or even a different hardware platform. Regardless of whether they are on the same platform, the source server and the destination server have the following characteristics: Figure 1 and Figure 2 The architecture shown requires that the hardware, software, and firmware versions of the destination server be equal to or higher than those of the source server to ensure that the destination server can correctly identify the information during migration and recovery. The two phases of the hot migration solution will be explained separately.

[0075] Figure 3 This illustrates another embodiment of the present disclosure, which is a flowchart of the migration and save path. In this embodiment, the source server can be... Figure 1 The system revealed Figure 4 Then it shows that it has Figure 1 This is a schematic diagram of the migration and saving path of the source server in the architecture. In this embodiment, while user space 102 is still running, the driver, firmware, hardware information, context information, and status information related to specific virtual hardware on the system-on-a-chip 106 are packaged and sent out from the source server. The "status information" may include the status information of the virtual function driver, the status information of the firmware and hardware, the state machine, registers, the context status information of the internal hardware state, the state machine of the software, variables, and the runtime context status information of constants, etc.

[0076] In step 301, the virtualization management software initiates a migration request to the emulated virtual machine QEMU 402. In this embodiment, the virtualization management software is Libvirt 401. Libvirt 401 is an open-source application programming interface (API), daemon, and management tool for managing virtualization platforms. It can be used to manage the virtualization technology of QEMU 402. When the system-on-chip 106 experiences a maintenance requirement as described above, Libvirt 401 will initiate a hot migration to ensure the normal operation of the virtual machine services.

[0077] In step 302, QEMU 402 notifies the physical function driver 403 to initiate the migration, that is, QEMU 402 initializes the hot migration start request. This embodiment provides a model to manage the entire migration save path process, which is the Virtual Machine Learning Unit QEMU Object Model (VMLU QOM), where the virtual machine learning unit refers to the virtual machine learning unit for... Figure 1 The virtualized AI system-on-a-chip 106 is shown, while the QEMU object model is a simulated PCIe.

[0078] More specifically, the function of VMLU QOM 404 is to add a virtual PCIe device to QEMU 402, register it as a QEMU object model, and indicate to QEMU 402 that it has hot migration capabilities. It also provides hot migration-related dispatch routine functions, enabling QEMU 402 to successfully schedule the hot migration. In this step, QEMU 402 operates the physical function driver 403 through the dispatch routine functions to notify and control the physical function driver 403 to cooperate in performing the hot migration.

[0079] The interaction between user space 102 and physical function driver 403 is achieved through memory-mapped I / O (MMIO) of VMLU QOM 404. MMIO is part of the PCI specification, where I / O devices are placed in memory space rather than I / O space. From the perspective of the processor in user space 102, accessing other devices after memory-mapped I / O is the same as accessing memory, simplifying program design and reducing interface complexity.

[0080] In this step, VMLU QOM 404 in QEMU 402 initializes the hot migration start request and sends the hot migration start request to the physical function driver 403.

[0081] In step 303, the physical function driver 403 notifies the virtual function driver 405 to initiate the migration. The virtual function driver 405 is stored in the virtual machine kernel space. From the user space 102's perspective, during the hot migration process, it sees the aforementioned virtual PCIe device, which has a readable and writable memory-mapped I / O space. The virtual function driver 405's read and write operations on the memory-mapped I / O space (i.e., the on-chip system 106) are captured and managed by the VMLU QOM 404. For read operations, the VMLU QOM 404 can return the appropriate value as needed by the virtual function driver 405, thus synchronizing the virtual function driver 405 and the physical function driver 403.

[0082] VMLU QOM 404 obtains the migration status of physical function driver 403 by calling the interface of physical function driver 403. When virtual function driver 405 wants to read the memory-mapped I / O space of VMLU QOM 404, VMLU QOM 404 returns the status of physical function driver 406 to virtual function driver 405. In this step, VMLU QOM 404 passes the status of physical function driver 403 being ready for hot migration to virtual function driver 405.

[0083] In step 304, the virtual function driver 405 suspends the execution of tasks from user space 102. In this embodiment, the virtual function driver 405 does not return control of the processor to the application in user space 102; the guest operating system continues to wait and does not issue the next task to the virtual function driver 405, thus suspending the execution of tasks in user space 102.

[0084] In step 305, the virtual function driver 405 notifies the physical function driver 403 to prepare for migration. After pausing the execution of instructions from user space 102, the virtual function driver 405 notifies the physical function driver 403 that user space 102 is ready and there will be no instruction interruption during the hot migration.

[0085] In step 306, the physical function driver 403 notifies the physical function 406 to prepare for migration. The physical function driver 403 sends a hot migration start request to the physical function 406, the hot migration start request specifying a particular virtual hardware 408 for hot migration. The particular virtual hardware 408 is one of the multiple virtual hardware devices of the system-on-chip 106. For ease of explanation, it is assumed here that the hot migration start request is for a particular virtual function 407 and its corresponding particular virtual hardware 408.

[0086] Specific virtual hardware 408 can be a specific virtual computing device, such as Figure 1 The virtual computing device 142 in the context of the data transfer includes the configuration of the virtual computing device 142, intermediate computation values ​​stored in the virtual shared memory unit, and data stored in the virtual memory unit core. The specific virtual hardware 408 can also be... Figure 1 If a specific virtual storage device 148 is used, then the information to be migrated includes the data stored in the specific virtual storage device 148. If the specific virtual hardware 408 can also be a virtual video codec device 144 or a virtual JPEG codec device 146, then the information to be migrated includes the configuration of the virtual video codec device 144 or the virtual JPEG codec device 146, and the corresponding codec information.

[0087] In step 307, physical function 406 uploads data including the driver and firmware of the specific virtual function 407, and information, context information, and status information of the specific virtual hardware 408 to physical function driver 403. First, physical function 406 sends an instruction to physical function driver 403 in kernel space 104. This instruction records information related to the specific virtual hardware 408, informing physical function driver 403 how much data needs to be migrated. At this time, VMLU QOM 404 is in the stop-and-copy phase and does not allocate physical resources to user space 102. User space 102 naturally has no time slice to run programs, thus interrupting the connection between user space 102 and the specific virtual function 407. However, other virtual functions and their corresponding virtual hardware continue to run normally. After idling the specific virtual function 407, physical function 406 retrieves the information to be migrated from the specific virtual hardware 408 in batches and sends it to physical function driver 403. When the information to be migrated is completely sent, physical function 406 sends a stop signal to physical function driver 403.

[0088] In step 308, VMLU QOM 404 obtains the migration information from physical function driver 403. The physical function driver 403 in kernel space sends the migration information to VMLU QOM 404.

[0089] In step 309, VMLU QOM 404 embeds the migration information into the migration instruction and transmits it to Libvirt 401.

[0090] In step 310, after the migration command is sent, physical function 406 releases the resources of specific virtual hardware 408 and specific virtual function 407, VMLU QOM 404 sends a termination signal to virtual function driver 405, virtual function driver 405 sends a control signal to virtual function driver interface 409, and the guest operating system restarts and issues the task. The entire migration and save path ends.

[0091] In more detail, Figure 4 The system also includes a serialization device 410, which, in response to a hot migration start request, serializes data such as the driver and firmware of the specific virtual function 407, and information, context information, and status information of the specific virtual hardware 408 in step 307 to generate migration information, which is then uploaded to the physical function driver 403. The serialization device 410 in this embodiment can be implemented using hardware or firmware. If it is hardware, the serialization device 410 is configured in the system-on-a-chip 106; if it is firmware, it is stored in the read-only memory of the system-on-a-chip 106.

[0092] To ensure the destination server can successfully complete the migration and recovery path, the migration information generated in step 307 must adhere to the protocol. The source server generates the migration information based on this protocol, and the destination server interprets the migration information according to the protocol to correctly restore the configuration and data. To fully describe the status and data of a specific virtual function 407 and specific hardware 408, the data structure of the migration information specified in this embodiment is as follows: Figure 5 As shown, the serialization device 410 generates a three-layer framework under this protocol: protocol layer 51, data structure layer 52, and serialization layer 53.

[0093] Protocol layer 51 is used to record information such as the protocol version, data ownership, and length of the information to be migrated. In this embodiment, the serialization device 410 generates 10 identifiers in protocol layer 51, namely, magic number identifier 501, version identifier 502, request / response identifier 503, command identifier 504, sequence number identifier 505, data source identifier 506, byte identifier 507, domain identifier 508, reserved identifier 509, and payload identifier 510. The functions of these identifiers are explained exemplarily below.

[0094] The magic number identifier 501 is set to 4 bytes to mark the beginning of the information to be migrated. More specifically, the characters in the magic number identifier 501 are fixed. When the destination server receives a certain instruction, as long as it recognizes the characters in the magic number identifier 501, it can know that this is the information to be migrated and then start the migration recovery path.

[0095] Version identifier 502 is set to 2 bytes to mark the version of the information to be migrated. As mentioned earlier, if the system version of the source server is inconsistent with the system version of the destination server, especially if the system version of the source server is higher than that of the destination server, compatibility issues will arise. In order for the destination server to determine compatibility, protocol layer 51 uses version identifier 502 to record the version of the information to be migrated, that is, to record the system version of the source server.

[0096] The request-response identifier 503 is set to 1 byte to indicate whether the instruction is a request or a response.

[0097] Command identifier 504 is set to 1 byte to indicate the task type of the information to be migrated. In this embodiment, the task types include migration status / data and updating the data dictionary. Migration status and data have been described previously and will not be repeated here. The data dictionary defines and describes the data items, data structures, data flows, data storage, and processing logic of the data. Its purpose is to provide detailed descriptions of each element of the data. In short, the data dictionary is a collection of information describing data; it is a collection of definitions for all data elements used in the system. Updating the data dictionary involves defining and describing the data items, data structures, data flows, data storage, and processing logic of the updated data.

[0098] The sequence number identifier 505 is set to 4 bytes to record the serial number of the information to be migrated, which corresponds to the order of each piece of information to be migrated.

[0099] The data source identifier 506 is set to 2 bytes to record which device the information in the information to be migrated comes from. Figure 4 The specific hardware 408, that is, the virtual computing device, virtual video encoding / decoding device, virtual JPEG encoding / decoding device, and virtual storage device that are to be hot-migrated corresponding to the specific virtual function 407, is at least one of them.

[0100] The byte identifier 507 is set to 8 bytes to record the total number of bytes of the information to be migrated or the total number of bytes of the payload.

[0101] Domain identifier 508 is used to mark a specific virtual function that is to be hot-migrated, i.e. Figure 4 Specific virtual function 407 in the context.

[0102] The reserved identifier 509 is set to 2 bytes, reserved for future use when other information needs to be recorded.

[0103] The payload identifier 510 is used to record information about the data structure layer 52. The data structure layer 52 is used to represent the organizational structure of the information to be migrated. For hot migration, it is usually not necessary to describe the data topology and the relationship between data structures in too much detail, because the source server and the destination server have similar or even identical frameworks. Therefore, the data structure layer 52 in this embodiment does not need to record too much information, as long as the destination server has enough information to understand the information to be migrated from the source server.

[0104] The information to be migrated disclosed herein is divided into two types: configuration and data.

[0105] When the information to be migrated is configured, in this embodiment, the protocol framework generated by the serialization device 410 in the data structure layer 52 is as shown in the configuration framework 54, including the generation domain identifier 511, chip identifier 512, board identifier 513, microcontroller identifier 514, firmware identifier 515, host driver identifier 516, virtual machine identifier 517, reserved identifier 518, computing device identifier 519, storage device identifier 520, video codec device identifier 521, JPEG codec device identifier 522, PCIe identifier 523, and reserved identifier 524.

[0106] Domain identifier 511 is used to identify a specific virtual function 407; chip identifier 512 is used to record the chipset model of the source server; board identifier 513 is used to record the board version or model of the source server.

[0107] The microcontroller identifier 514 is used to record the version of the microcontroller in the source server. The microcontroller is a general-purpose control element in the system-on-a-chip 106, used to detect or control the server environment, such as detecting or controlling the server temperature and operating frequency.

[0108] Firmware identifier 515 is used to record the firmware version of the source server; host driver identifier 516 is used to record the host driver software version of the source server; virtual machine identifier 517 is used to record the virtual machine driver software version of the source server; reserved identifiers 518 and 524 are not used for the time being and are reserved for future use when other information needs to be recorded.

[0109] The computing device identifier 519, storage device identifier 520, video encoding / decoding device identifier 521, and JPEG encoding / decoding device identifier 522 are collectively referred to as specific device identifiers, used to record... Figure 4 The configuration of specific hardware 408 in the configuration. More specifically, the computing device identifier 519 is used to record the virtual computing device (such as...) of the source server. Figure 1 The configuration of the virtual computing device 142); the storage device identifier 520 is used to record the virtual storage device of the source server (such as... Figure 1 The configuration of the virtual storage device 148); the video codec identifier 521 is used to record the virtual video codec device (e.g., the virtual storage device 148) of the source server. Figure 1 The configuration of the virtual video codec device 144; the JPEG codec device identifier 522 is used to record the virtual JPEG codec device of the source server (e.g., Figure 1 The configuration of the virtual JPEG codec device 146.

[0110] PCIe identifier 523 is used to record the virtual interface of the source server (e.g., Figure 1The configuration of the virtual interface 140, where the virtual interface refers to the PCIe virtual interface assigned to a specific virtual function 407.

[0111] When the information to be migrated is data, this data was originally stored in memory. This memory is a virtual storage unit that can be directly accessed by specific hardware 408. It may be the internal storage space of a virtual computing device 142, a virtual video encoding / decoding device 144, or a virtual JPEG encoding / decoding device 146, such as a virtual shared storage unit in the virtual computing device 142. The memory could also be a virtual storage device 148. The serialization device 410 generates a data frame 55 to carry the information. This embodiment considers that some complex scenarios may require describing the relationships between data; therefore, the serialization device 410 uses specific symbols to display the relationships between data, enabling the destination server to completely and accurately recover the data based on this information.

[0112] The data information recorded in the data structure layer 52 may be several data items of different types but related to each other. In this embodiment, the serialization device 410 defines a structure based on the correlation between the data, which includes at least one type, and each type is composed of at least one variable (i.e., data). In other words, several related variables are grouped into a type, and several related types are grouped into a structure. These structures, types, variables, and their relationships are all stored in the aforementioned memory.

[0113] When labeling a structure, the stringification device 410 adds a prefix to the structure name as a starting symbol for representing the structure. In this embodiment, a string is used as the prefix symbol. The prefix symbol can be any character other than English letters and numbers, such as ".", "$", " / ", "#", "%", "&", "*", and "-". For ease of explanation, the English period "." will be used as the prefix symbol uniformly below.

[0114] Specifically, the data frame 55 generated by the serialization device 410 includes symbol identifiers 525, type identifiers 526, key identifiers 527 and entity identifiers 528, which are used to describe and record structures, types and variables.

[0115] The symbol identifier 525 is used to mark the beginning of a structure or data frame 55. The serialization device 410 inserts a prefix symbol and the name of the structure into the symbol identifier 525 according to the protocol. For example, if the structure name is "foo_nested", its symbol identifier 525 is recorded as ".foo_nested". Since the source server and the destination server follow the same protocol, when the destination server recognizes the prefix symbol ".", it knows that the prefix symbol is followed by the structure name, and that the subsequent identifiers are all related descriptions of the structure.

[0116] Type identifier 526 is used to record various types under this structure, including trees, images, linked lists, heaps, integers, and floating-point numbers. The name of the type can be defined by the serialization device 410 or used by the data stored in memory. For example, if integer a (with a value of 20) and integer b (with a value of 10) are defined as the same type under this structure, and the serialization device 410 names this type "foo_nested_t", then type identifier 526 records the category name "foo_nested_t" for integers a and b.

[0117] Key identifier 527 is used to record the variable name under this type. When marking variables, according to the protocol, the serialization device 410 adds a prefix to the variable name. The prefix is ​​the content of the symbol identifier 525 plus the prefix symbol plus the variable name. Taking the aforementioned integers a and b as an example, since the type "foo_nested_t" has two variables, integers a and b, the serialization device 410 first describes integer a in data frame 55. Therefore, the key identifier 527 for integer a is ".foo_nested.a". Entity identifier 528 then records the value of the variable. The value of integer a is 20, so entity identifier 528 directly records "20".

[0118] Since the type "foo_nested_t" also has a variable b, after the key identifier 527 and entity identifier 528 describing the integer a, the key identifier 527 and entity identifier 528 of the integer b will be followed, respectively recording ".foo_nested.b" and the value "10".

[0119] The structure "foo_nested" is recorded in data structure layer 52 as follows: Figure 6 As shown in the foregoing description, in this embodiment, when describing a structure in the information to be migrated, the structure name is first recorded in symbol identifier 525, the type name under the structure is recorded in type identifier 526, the variable name under the type is described in key identifier 527, and the variable value or string is described in entity identifier 528. If the same type has multiple variables, key identifier 527 and entity identifier 528 are repeated after describing type identifier 526 for that type until all variables are described. If the structure has multiple types, the first type and all variables of the first type are described first, then the second type and all variables of the second type are described, and so on, to completely describe the members of the structure.

[0120] If the variable is a simple structure such as a number, string, sequence, or list, then data frame 55 is sufficient to store all the information. When the variable has a complex structure, entity identifier 528 is further expanded into serialization layer 53 to serialize the complex structure. Returning to... Figure 5 The serialization device 410 generates a magic number identifier 529, a length identifier 530, a byte order identifier 531, a compression identifier 532, a type identifier 533, a key identifier 534, a count identifier 535, a format identifier 536, and a value identifier 537 under the serialization layer 53.

[0121] The magic number identifier 529 is a specific character used to mark the beginning of a new data segment, which is the beginning of serialization layer 53. When the destination server reads the magic number identifier 529, it can know that the following information is from serialization layer 53 and perform the corresponding processing.

[0122] The length identifier 530 is used to indicate the length of the serialization layer 53.

[0123] The byte order identifier 531 indicates the storage byte order of data in this serialization layer 53, generally stored in big-endian or little-endian mode. Big-endian means the most significant byte is stored at the lowest memory address, while the least significant byte is stored at the highest memory address. This storage mode is similar to treating data as a string, with addresses increasing from small to large and data stored from high to low. Little-endian means the most significant byte is stored at the highest memory address, while the least significant byte is stored at the lowest memory address. This storage mode effectively combines the high and low addresses with the data bits, with higher addresses having higher weights and lower addresses having lower weights.

[0124] Compression identifier 532 is used to indicate the compression form of data information. Data is appropriately compressed during transmission to reduce the amount of data transmitted. This embodiment does not limit the compression form, but BDI (base deltamed median) compression is preferred.

[0125] Type identifier 533 is used to indicate the type of data information. Type identifier 533 differs from type identifier 526, which records various types under a structure, while type identifier 533 indicates the type of the data itself.

[0126] Key identifier 534 is used to identify the variable name under the type in type identifier 533.

[0127] The count identifier 535 is used to indicate the number of variables under the type in the type identifier 533.

[0128] The format identifier 536 is used to indicate the variable format under the type in the type identifier 533. For example, int 16, int32 and int 64 indicate that the variable is a 16-bit integer, a 32-bit integer or a 64-bit integer, respectively.

[0129] Numeric identifier 537 records the numerical value or string of the variable. In this embodiment, if a variable has multiple numerical values, multiple numeric identifiers 537 are directly appended after the format identifier 536 to record each numerical value respectively. For example, if a variable is a list containing 128 numerical values, then the type identifier 533 indicates that the data is a list, the count identifier 535 indicates that there are a total of 128 numerical values, and there will be 128 numeric identifiers 537 to store the 128 numerical values ​​respectively.

[0130] More complex data, such as tree data, nested data, or logical pointers, requires the use of a serialization layer 53. Tree data refers to binary trees, which are a type of tree structure. A binary tree is a collection of multiple elements (also called nodes). This collection can be empty or consists of an element called the root and two disjoint binary trees called the left subtree and the right subtree, respectively. It is an ordered tree. Figure 7 The example tree data shown includes nodes 701 to 707, each node corresponding to a numerical value, such as node 701 having a value of 20, node 702 having a value of 8, etc. Nested data refers to a data format in which one or more tables, images, layers, or functions are added to existing tables, images, layers, or functions. A logical pointer is a structure that points to another structure by adding an identifier, establishing a relationship between structures. The following will explain how the serialization device 410 serializes tree data, nested data, or logical pointers.

[0131] When the data is tree data, the serialization device 410 marks the beginning of the tree data information in the magic number identifier 529, records the length of the serialization layer 53 in the length identifier 530, indicates whether the tree data is stored in big-endian or little-endian mode in the byte order identifier 531, indicates the compression form of the tree data in the compression identifier 532, indicates that the type is a binary tree in the type identifier 533, indicates the variable name of the tree data in the key identifier 534, indicates the number of elements in the tree data in the count identifier 535, and indicates the element format of the tree data in the format identifier 536.

[0132] Numeric identifier 537 records the numerical values ​​of each element in the tree data. When recording these values, the tree data needs to be serialized. First, the binary tree is traversed in a specific order to form serialized data. The specific order can be agreed in the protocol and can be one of preorder, inorder, postorder, or reverse postorder. Then, the traversed values ​​are sequentially placed into numeric identifier 537.

[0133] Preorder traversal, for the current tree data, first outputs the root node, then its left subtree, and so on until there is no left subtree, then outputs its right subtree. Figure 7 Taking the tree data as an example, its root node is node 701, so first record the value of node 701 as 20, then record the value of its left subtree node 702 as 8, then record the value of its left subtree node 703 as 4. Node 703 has no left subtree, so record NIL (meaning empty). Next, output the right subtree of node 703. Node 703 also has no right subtree, so record NIL again. Go back to the previous level node 702, its right subtree is node 704, record its value as 12, then record the value of its left subtree node 705 as 10. Node 705 also has no left or right subtree, so record NIL for both. Go back to the right subtree 706 of node 704, record its value as 14. Node 706 also has no left or right subtree, so record NIL for both. Finally, go back to the root node 701, its right subtree is node 707, record its value as 22. Node 707 also has no left or right subtree, so record NIL for both, ending the traversal process. Therefore, the serialization device 410 performs a preorder traversal. Figure 7 When processing tree data, the resulting serialized data is as follows: 20, 8, 4, NIL, NIL, 12, 10, NIL, NIL, 14, NIL, NIL, 22, NIL, NIL, with the numerical identifier 537 as... Figure 8 As shown.

[0134] Inorder traversal, for the current node, first outputs its left subtree, then outputs the node itself, and finally outputs its right subtree. Figure 7 For example, when the serialization device 410 traverses in inorder, the resulting serialized data are as follows: NIL, 4, NIL, 8, NIL, 10, NIL, 12, NIL, 14, NIL, 20, NIL, 22, NIL.

[0135] In post-order traversal, for the current node, first output its left subtree, then its right subtree, and finally the node itself. Figure 7 For example, when the serialization device 410 performs a subsequent traversal, the resulting serialized data is as follows: NIL, NIL, 4, NIL, NIL, 10, NIL, NIL, 14, 12, 8, NIL, NIL, 22, 20.

[0136] Reverse postorder traversal is simply reversing the result of postorder traversal, and so on. Figure 7 For example, when the serialization device 410 traverses in reverse order, the resulting serialized data is as follows: 20, 22, NIL, NIL, 8, 12, 14, NIL, NIL, 10, NIL, NIL, 4, NIL, NIL.

[0137] Through any of the aforementioned methods, the serialization device 410 converts the tree data into serialized data and places the serialized data into the numerical identifier 537. This embodiment does not limit the method of traversing the tree data, but traversal in a preorder manner is preferred.

[0138] When processing nested data, because of its hierarchical structure, it is also necessary to record the nested data hierarchically during hot migration. In reality, nested data may include multiple levels of nested structures; for ease of explanation, the following example will be nested data with two levels.

[0139] The serialization device 410 also presents the nested data in a structured manner, divided into a first-level structure (upper-level structure) and a second-level structure (lower-level structure), that is, the second-level structure is nested within the first-level structure. When generating the information to be migrated, the serialization device 410 divides the data structure layer 52 into two segments. The symbol identifier 525 (first symbol identifier), type identifier 526 (first type identifier), and key identifier 527 (first key identifier) ​​of the first segment record the relevant information of the first-level structure, and the serialization layer 53 of the first-level structure is expanded in the entity identifier 528 (first entity identifier).

[0140] The serialization device 410 generates the following identifiers in the serialization layer 53 of the first-level structure: magic number identifier 529 indicates the start of the serialization of the first-level structure; length identifier 530 records the length of the serialization layer 53 of the first-level structure; byte order identifier 531 indicates whether the first-level structure is stored in big-endian or little-endian mode; compression identifier 532 indicates the compression form of the first-level structure; type identifier 533 indicates the type of the first-level structure; key identifier 534 indicates the variable name in the first-level structure; count identifier 535 indicates the number of variables in the first-level structure; format identifier 536 indicates the variable format of the first-level structure; and value identifier 537 records the value of each variable in the first-level structure.

[0141] Following the entity identifier 528 of the first-level structure, the serialization device 410 immediately generates a description of the second-level structure. The serialization device 410 generates a key identifier 527 (second key identifier) ​​to record the name of the second-level structure, and expands the serialization layer 53 of the second-level structure within the entity identifier 528 (second entity identifier). The way the identifiers of the serialization layer 53 of the second-level structure are recorded is the same as that of the first-level structure, and will not be described again.

[0142] For example, suppose we have the following nested data:

[0143]

[0144]

[0145] The aforementioned code describes nested data consisting of a two-level structure. The first-level structure is named "foo_nested" and includes three types: the first type is an array of integers named "array" with the sequence {26, 91, 1029}; the second type is the second-level structure, which includes the number 91 and the string "Hello world"; and the third type is the integer 10029.

[0146] Figure 9 The data structure generated during nested data serialization is shown. Since this only describes the serialization of nested data, the identifiers of protocol layer 51 are omitted. In the data structure layer 52 generated by serialization device 410, the first symbol identifier 901 records the name of the first-level structure, i.e., ".foo_nested"; the first type identifier 902 records the type of the first-level structure, i.e., "foo_nested_t"; the first key identifier 903 and the first entity identifier 904 record information about the integer array {26, 91, 1029} of the first type, where the first key identifier 903 records its variable name as ".foo_nested.array", and the first entity identifier 904 records the three values ​​of the array, i.e., the integers 26, 91, and 1029. Since the array is simple data, the first entity identifier 904 does not need to expand the serialization layer 53.

[0147] After describing the first type of information, the second type of information is recorded. After the first entity identifier 904, the second type is recorded for the second key identifier 905. The second type is a second-level structure of nested data, named "foo1". According to the protocol, the second key identifier 905 is recorded as ".foo_nested.foo1", which means that the "foo1" structure is nested under the "foo_nested" structure.

[0148] The serialization device 410 expands the serialization layer 53 using the second entity identifier 906 to represent the second-level structure. The magic number identifier 907 marks the beginning of the second-level structure, the length identifier 908 records the length of the serialization layer 53, the byte order identifier 909 indicates whether the second-level structure is stored in big-endian or little-endian mode, the compression identifier 910 indicates the compression format of the second-level structure, the second symbol identifier 911 records the name of the second-level structure (".foo_nested.foo1" according to the protocol), and the second type identifier 912 records the type name of the second-level structure, i.e., "foo1_t". Since the data {91, "Hello world"} of the second-level structure includes the number "91" and the string "Hello world", the serialization device 410 records the relevant information using two sets of key identifiers and entity identifiers. The third key identifier 913 and the third entity identifier 914 are used to record the number, where the third key identifier 913 records the variable name as ".foo_nested.foo1.integer", and the third entity identifier 914 records the value "91"; the fourth key identifier 915 and the fourth entity identifier 916 are used to record the string, where the fourth key identifier 915 records the variable name as ".foo_nested.foo1.str", and the fourth entity identifier 916 records the string "Hello world".

[0149] After the second type of information is identified, the third type of information is then recorded in the data structure layer 52. The serialization device 410 adds a fifth key identifier 917 after the second entity identifier 906 to record the variable name of the third type, namely ".foo_nested.seq", and records the variable value of the third type, namely "10029", in the fifth entity identifier 918. At this point, the serialization device 410 has loaded all the nested data information into the information to be migrated.

[0150] When serializing a logical pointer, the serialization device 410 also uses the data structure layer 52 and the serialization layer 53 to fully describe the pointer's pointing relationship.

[0151] For example, suppose we have the following structure:

[0152]

[0153] The aforementioned code describes a first structure named "foo_nested", which includes a first type named "foo_nested_t". This first type contains two variables: the first variable is a logical pointer "foo1", which points to a second structure "foo2", and the second variable is an integer named "seq" with a value of 10029. The second structure "foo2" also includes a second type named "foo2_t", which contains an integer variable named "integer" with a value of 91.

[0154] Figure 10 This diagram illustrates how the serialization device 410 serializes the aforementioned structure, including logical pointers, into information to be transferred. Similarly, this is only used to illustrate the serialization of logical pointers; therefore, the identifiers in the protocol layer 51 are omitted. In the data structure layer 52, the serialization device 410 records the name of the first structure, ".foo_nested", according to the protocol using the first symbol identifier 1001; the name of the first type, "foo_nested_t", is recorded using the first type identifier 1002; the logical pointer information is recorded using the first key identifier 1003 and the first entity identifier 1004. The first key identifier 1003 records the logical pointer name as ".foo_nested.foo1" according to the protocol, and the first entity identifier 1004 records that the logical pointer points to ".foo2". Next, the second key identifier 1005 and the second entity identifier 1006 record the information of the second variable. The second key identifier 1005 records the second variable name as ".foo_nested.seq" according to the protocol, and the second entity identifier 1006 records the value of the second variable as "10029".

[0155] The serialization device 410 will appropriately insert the information of the second structure foo2 into a certain segment of the data structure of the same information to be transferred. For example... Figure 10 As shown, information about several other structures exists after the second entity identifier 1006. In a certain segment of the data structure layer 52, the serialization device 410 then records the information of the second structure. The second symbol identifier 1007 records the name of the second structure, namely ".foo2". The period is used by the system to identify this as a symbol identifier, which is the beginning of a structure information. The second type identifier 1008 records the name of the second type, namely "foo2_t". The third key identifier 1009 and the third entity identifier 1010 record the variable information in the second type. The third key identifier 1009 records the variable name as ".foo2.integer", and the third entity identifier 1010 records the value of the variable as "91".

[0156] exist Figure 10In the example of logical pointers, since the variables are simple enough, the first entity identifier 1004, the second entity identifier 1006, and the third entity identifier 1010 do not need to be expanded as shown below. Figure 5 The serialization layer 53 is shown. This disclosure does not require or limit the data structure of each piece of information to be migrated to include the serialization layer 53 or each identifier of the serialization layer 53.

[0157] In summary, when generating the information to be migrated, the serialization device 410 can concatenate multiple identifiers according to actual needs to appropriately extend the length of the data structure layer 52 and the serialization layer 53, and then record the total number of bytes of the information to be migrated in the byte identifier 507. In other words, the data structure layer 52 and the serialization layer 53 can include multiple symbolic identifiers, type identifiers, key identifiers, or entity identifiers concatenated together, each recording different data entities.

[0158] After the serialization device 410 generates the information to be migrated, the physical function 406 sends the information to be migrated to the physical function driver 403 in the kernel space 104 in step 307 to complete the data serialization process.

[0159] Another embodiment of this disclosure is a method for hot-migrating and saving paths in a system. More specifically, this embodiment is a process for generating a data structure for the information to be migrated in step 307. Figure 11 The flowchart is shown.

[0160] In step 1101, a hot migration start request is received. The hot migration start request specifies a particular virtual function for hot migration, and the particular virtual function is one of a plurality of virtual functions. Figure 3 In step 306, the physical function driver 403 sends a hot migration start request to notify the physical function 406 to prepare for migration. The physical function 406 receives the hot migration start request, which specifies the hot migration specific virtual function 407.

[0161] In step 1102, a data structure for the information to be migrated is generated. The serialization device 410 responds to the hot migration initiation request and generates the data structure for the information to be migrated. This step can be further refined as follows: Figure 12 The process is shown below.

[0162] In step 1201, the protocol layer of the data structure is generated; in step 1202, the data structure layer of the data structure is generated; in step 1203, the serialization layer of the data structure is generated.

[0163] In step 1204, at least one of the following is generated in the protocol layer: magic number identifier, version identifier, request / response identifier, command identifier, sequence number identifier, data source identifier, byte identifier, domain identifier, reserved identifier, payload identifier, etc.

[0164] In step 1205, it is determined whether the information to be migrated is configuration or data.

[0165] If configured, proceed to step 1206 to generate at least one of the following in the data structure layer: domain identifier, chip identifier, board identifier, microcontroller identifier, firmware identifier, host driver identifier, virtual machine identifier, reserved identifier, computing device identifier, storage device identifier, video codec device identifier, JPEG codec device identifier, PCIe identifier, etc.

[0166] If it is data, then proceed to step 1207 to generate at least one of the following in the data structure layer: symbol identifier, type identifier, key identifier, and entity identifier.

[0167] Next, step 1208 is executed to generate at least one of the following in the serialization layer: magic number identifier, length identifier, byte order identifier, compression identifier, type identifier, key identifier, count identifier, format identifier, and numeric identifier.

[0168] The definitions and contents of these identifiers have been described in the foregoing embodiments, and the details will not be repeated here.

[0169] In the final execution step 1103, the migration information is sent to the kernel space. After the serialization device 410 generates the migration information, the physical function 406 sends the migration information to the physical function driver 403 in the kernel space 104.

[0170] Another embodiment of this disclosure is a method for serializing tree data, the flowchart of which is shown below. Figure 13 As shown, the process includes the following steps. In step 1301, a hot migration initiation request is responded to generate migration information, the data structure of which includes a numerical identifier; in step 1302, the tree data is traversed in a specific order to form serialized data; in step 1303, the serialized data is placed into the numerical identifier. The details of the serialized tree data have been described in the foregoing embodiments and will not be repeated here.

[0171] Another embodiment of this disclosure is a method for serializing nested data, wherein the nested data includes at least a first-level structure and a second-level structure. The serialization device 410 responds to a hot migration initiation request and generates information to be migrated. The steps for generating the information to be migrated are as follows: Figure 14As shown. In step 1401, a first symbolic identifier is generated in the data structure layer of the information to be migrated to record the name of the first-layer structure; in step 1402, a second symbolic identifier is generated in the serialization layer to record the name of the second structure. The details of serializing nested data have been described in the foregoing embodiments, and therefore will not be repeated here.

[0172] Another embodiment of this disclosure is a method for serializing logical pointers, wherein the logical pointers establish an association between a first structure and a second structure, and the flowchart is as follows. Figure 15 As shown, the process includes the following steps: In step 1501, a hot migration initiation request is responded to to generate migration information; in step 1502, a first symbolic identifier and a first entity identifier are generated in the data structure of the migration information; in step 1503, the name of the first structure is placed in the first symbolic identifier; in step 1504, the value of the logical pointer is placed in the first entity identifier, where the value of the logical pointer is the name of the second structure. The details of serializing the logical pointer have been described in the foregoing embodiments and will not be repeated here.

[0173] Through the description of the above embodiments, this disclosure realizes the serialization of data in the migration and storage path. While executing the aforementioned process, for non-specific virtual functions and hardware, the tasks from user space 102 are still executed without being affected.

[0174] Another embodiment of this disclosure is a migration recovery path, in which the destination server is also... Figure 1 The system has the same environment as the source server. Figure 16 This is a flowchart illustrating the migration and recovery path. Figure 17 This shows the migration recovery path in Figure 1 A schematic diagram of the environment. More specifically, this embodiment is... Figure 3 and Figure 4 After completing the migration and saving path in the example, the information to be migrated is then migrated to the destination server.

[0175] In step 1601, Libvirt 1701 sends a request to QEMU 1702 to import the information to be migrated. QEMU 1702 receives the information from external sources... Figure 3 and Figure 4 In the embodiment, the migration command is issued, and a hot migration start request is initialized. The "off-chip" refers to the source server, which may be on the same hardware platform or a different hardware platform as the destination server.

[0176] In step 1602, VMLUQOM 1704 sends the migration information to the physical function driver 1703. After receiving the migration instruction, VMLUQOM 1704 responds to the hot migration start request, calls the write function, and sends the migration information to the physical function driver 1703.

[0177] In step 1603, physical function 1706 receives the migration information. In the previous step, VMLU QOM 1704 sent the migration information to physical function driver 1703, and physical function driver 1703 then sent the migration information to physical function 1706.

[0178] In step 1604, the configuration, data and context are restored for specific virtual functions 1707 and specific virtual hardware 1708.

[0179] First, physical function 1706 idles a specific virtual function 1707, temporarily preventing it from communicating with user space 102, while other virtual functions continue to operate normally. After idling the specific virtual function 1707, physical function 1706 sends migration information to specific virtual hardware 1708 through the specific virtual function 1707.

[0180] Similarly, specific virtual hardware 1708 can be Figure 1 This refers to a virtual computing device, a specific virtual storage device, a virtual video codec, or a virtual JPEG codec. The information to be migrated includes drivers, firmware, hardware information, context information, and status information related to the specific virtual hardware 1708. Upon recovery, the specific virtual function 1707 and specific virtual hardware 1708 will have the exact same environment and data as the specific virtual function 407 and specific virtual hardware 408.

[0181] In step 1605, physical function 1706 reports to physical function driver 1703 that the migration is complete. After the instruction is sent, physical function 1706 sends an end signal to physical function driver 603 in kernel space 104.

[0182] In step 1606, the physical function driver 1703 notifies the VMLU QOM 1704 that the hot migration has been completed, that is, the physical function driver 1703 sends a stop signal to the QEMU 1702.

[0183] In step 1607, VMLU QOM 1704 changes its state to notify the virtual function driver 1705 that the hot migration is complete. VMLU QOM 1704 responds to the end signal, notifying the virtual function driver 1705 that the hot migration is complete, and at the same time changes the state of the base address register to point to the specific virtual function 1707 and the specific virtual hardware 1708 of the destination server.

[0184] In step 1608, the virtual function driver 1705 sends a control signal to the virtual function driver interface 1709 to resume the execution of the guest operating system's tasks.

[0185] In step 1609, the virtual function driver interface 1709 notifies the virtual function driver 1705 to resume execution of the guest operating system's tasks. The virtual function driver 1705 resumes receiving tasks from the processor of user space 102 through the virtual function driver interface 1709. These tasks no longer access the specific virtual hardware 408 of the source server, but instead access the specific virtual hardware 1708 of the destination server.

[0186] In step 1610, VMLU QOM 1704 notifies Libvirt 1701 that the hot migration is complete, and Libvirt 1701 cleans up the hardware resources allocated on the source server. This completes the migration recovery path.

[0187] By combining the aforementioned migration save path and migration restore path embodiments, this disclosure enables hot migration of virtualized application-specific integrated circuits.

[0188] In more detail, Figure 17 The system also includes a deserialization device 1710, which responds to a hot migration start request and, in step 1604, recovers data such as the driver, firmware, and information, context information, and status information of the specific virtual function 1707 and the specific virtual hardware 1708 based on the migration information. The deserialization device 1710 in this embodiment can be implemented using hardware or firmware. If it is hardware, the deserialization device 1710 is configured in the system-on-a-chip 106; if it is firmware, it is stored in the read-only memory of the system-on-a-chip 106.

[0189] The method for implementing the hot migration recovery path using the deserialization device 1710 is as follows: Figure 18 As described above. In step 1801, the deserialization device 1710 receives the information to be migrated. In step 1802, the deserialization device 1710 deserializes the information of the protocol layer 51. This step is further refined into... Figure 19 The process.

[0190] In step 1901, since the source server and the destination server follow the same protocol, the deserialization device 1710 can identify... Figure 5 The data structure identifies the beginning of the protocol layer 51 of the information to be migrated from the magic number identifier 501. In step 1902, the version of the information to be migrated is identified from the version identifier 502 to confirm that the system version of the destination server is equal to or higher than the system version of the source server. In step 1903, the information instruction is identified as a request or a response from the request-response identifier 503. If it is a request, the migration recovery path continues; if it is a response, it indicates that this information is not the information to be migrated, and recovery stops.

[0191] Next, in step 1904, the task type of the information to be migrated is identified from command identifier 504 as either migration status and data or updating the data dictionary. In step 1905, the serial number of the information to be migrated is identified from sequence identifier 505 to determine the position of this information to be migrated in the entire hot migration recovery path.

[0192] Next, in step 1906, a specific virtual suite is identified from the data source identifier 506, wherein the specific virtual suite includes at least one of a virtual computing device, a virtual video codec device, a virtual JPEG codec device, and a virtual storage device, and the deserializing device 1710 restores the information to be migrated to the specified specific virtual suite based on the information in the data source identifier 506.

[0193] Next, in step 1907, the total number of bytes of the information to be migrated or the total number of bytes of the payload is identified from the byte identifier 507. In step 1908, the information of the specific virtual function is retrieved from the domain identifier 508, and the information to be migrated is restored to the specific virtual function 1707. In step 1909, the information of the data structure layer 52 is retrieved from the payload identifier 510.

[0194] In step 1803, the deserializing device 1710 begins to deserialize the information of the data structure layer 52, first determining whether the data structure layer 52 records configuration information or data information.

[0195] If data structure layer 52 records configuration information, then step 1804 is executed to deserialize the configuration information. This step is further refined into... Figure 20The process is as follows: In step 2001, the deserialization device 1710 extracts the specific hardware information from the domain identifier 511, preparing to restore the information to be migrated to the specific hardware 1708. In step 2002, the chipset model of the source server is identified from the chip identifier 512 to determine whether it is compatible with the chipset of the destination server. In step 2003, the board version or model of the source server is identified from the board identifier 513 to determine whether it is compatible with the board of the destination server. In step 2004, the microcontroller model of the source server is identified from the microcontroller identifier 514 to determine whether it is compatible with the microcontroller of the destination server.

[0196] In step 2005, the firmware version of the source server is then identified from firmware identifier 515 to determine whether it is compatible with the firmware of the destination server. In step 2006, the host driver software version of the source server is identified from host driver identifier 516 to determine whether it is compatible with the host driver software of the destination server. In step 2007, the virtual machine driver software version of the source server is identified from virtual machine identifier 517 to determine whether it is compatible with the virtual machine driver software of the destination server.

[0197] Next, in step 2008, information of the specific device identifier is retrieved, that is, information is retrieved from the computing device identifier 519, storage device identifier 520, video codec device identifier 521, and JPEG codec device identifier 522 to restore the configuration of the specific device. The specific device is the specific hardware 1708, which is one of the virtual computing device, virtual video codec device, virtual JPEG codec device, and virtual storage device.

[0198] Finally, in step 2009, the configuration of the virtual interface is restored based on the information of PCIe identifier 523.

[0199] If data structure layer 52 is used to record data information, then step 1805 is executed to deserialize the data information. This step is refined into... Figure 21 The process is as follows: In step 2101, the deserializing device 1710 identifies the beginning of the marked structure from the symbol identifier 525 and extracts the name of the structure. More specifically, since the symbol identifier 525 includes a prefix symbol, the deserializing device 1710 first identifies the prefix symbol and can then identify the name of the structure, as well as the various identifiers that follow, based on the prefix symbol. In step 2102, the type is identified from the type identifier 526. In step 2103, the name of the variable is extracted from the key identifier 527. Similarly, since the key identifier 527 includes a prefix symbol, the deserializing device 1710 first identifies the prefix symbol and can then extract the name of the variable based on the prefix symbol. In step 2104, the information of the serialization layer 53 is extracted from the entity identifier 528.

[0200] Back Figure 18 Next, step 1806 is executed to identify or extract information from the serialization layer 53. This step is further refined into... Figure 22 The process is as follows: In step 2201, the deserializing device 1710 then identifies the start of the serialization layer 53 based on the magic number identifier 529. In step 2202, the length of the serialization layer 53 is identified from the length identifier 530. In step 2203, the storage byte order of the data is identified as big-endian or little-endian based on the byte order identifier 531. In step 2204, the compression format of the data is identified based on the compression identifier 532. In step 2205, the type is identified based on the type identifier 533. In step 2206, the variable name is extracted from the key identifier 534. In step 2207, the number of variables is identified based on the count identifier 535. In step 2208, the variable format is identified based on the format identifier 536. In step 2209, the value or string of the variable is extracted from the value identifier 537.

[0201] When encountering complex data during deserialization, such as tree data, nested data, or logical pointers, the deserialization device 1710 will perform the following deserialization processes respectively.

[0202] During deserialization of tree data, the deserializing device 1710 will perform... Figure 23 The process is as follows: In step 2301, the type is identified as a binary tree by the type identifier 533. In step 2302, the tree data name is extracted from the key identifier 534. In step 2303, the number of elements in the tree data is identified by the count identifier 535. In step 2304, the element format of the tree data is identified by the format identifier 536. In step 2305, the serialized element data is extracted from the numeric identifier 537. In step 2306, the tree data is restored in a specific order according to the protocol.

[0203] During deserialization of nested data, the deserializing device 1710 receives the information to be migrated. The data structure layer 52 of the information to be migrated includes a first symbol identifier, and the serialization layer 53 includes a second symbol identifier. First serialized data is extracted based on the first symbol identifier; second serialized data is extracted based on the second symbol identifier; the first serialized data is restored to the first-layer structure; and the second serialized data is restored to the second-layer structure. Finally, the first-layer structure and the second-layer structure are stored in memory.

[0204] More specifically, the deserialization device 1710 performs operations on the first-layer structure. Figure 24 The process is shown below. The following will use... Figure 25Nested data is used as an example for illustration. In step 2401, information to be migrated is received. The data structure of the information to be migrated includes a data structure layer 52 and a serialization layer 53, wherein the data structure layer 52 includes a first symbol identifier 2501, and the serialization layer 53 includes a second symbol identifier 2509. In step 2402, the first serialized data is identified and extracted according to the first symbol identifier 2501, and its structure name is "foo_nested". In step 2403, the first type is restored from the first type identifier 2502, and its type name is "foo_nested_t". In step 2404, the variable name in the first-level structure is restored from the first key identifier 2503, which is "foo1". In step 2405, the serialization layer 53 information is extracted from the first entity identifier 2504, that is, the information of the second-level structure is identified or extracted. This step can be further refined as follows: Figure 26 The process is shown below.

[0205] In step 2601, the start of the second-level structure is identified from the magic number identifier 2505. In step 2602, the length of the serialization layer 53 is identified from the length identifier 2506. In step 2603, the storage byte order of the data in the second-level structure is identified from the byte order identifier 2507. In step 2604, the compressed form of the data in the second-level structure is identified from the compression identifier 2508. In step 2605, the name of the second-level structure is identified as "foo_nested_foo1" from the second symbol identifier 2509. In step 2606, the second type is identified from the second type identifier 2510, and its name is "foo_t". In step 2607, the number of variables is identified from the count identifier 2511. In step 2608, the variable format is identified from the format identifier 2512. In step 2609, the name of the first variable, "integer", is extracted from the second key identifier 2513. In step 2610, the value "91" of the first variable is retrieved from the first numeric identifier 2514. In step 2611, the name "str" ​​of the second variable is retrieved from the third key identifier 2515. In step 2612, the string "Hello world" of the second variable is retrieved from the second numeric identifier 2516. In step 2613, the first and second layer structures are stored, i.e., all information under the first and second layer structures is restored.

[0206] During the deserialization of the logical pointer, the deserialization device 1710 will execute... Figure 27 The process, while referring to Figure 10The process includes receiving information about logical pointers to be migrated. In step 2701, the information to be migrated is received. In step 2702, the name of the first structure is retrieved from the first symbol identifier 1001. In step 2703, the first type is identified from the first type identifier 1002. In step 2704, the name of the logical pointer is retrieved from the first key identifier 1003. In step 2705, the name of the second structure is retrieved from the first entity identifier 1004. In step 2706, the name of the second structure is retrieved from the second symbol identifier 1007. In step 2707, the second type is identified from the second type identifier 1008. In step 2708, the name of the variable is retrieved from the second key identifier 1009. In step 2709, the information of the variable is retrieved from the second entity identifier 1010. In step 2710, the information of the first and second structures is restored.

[0207] The deserializing device 1710 deserializes the information to be migrated, and restores the drivers, firmware and hardware information, context information and status information of the specific virtual function 407 and specific hardware 408 in the source server to the memory of the specific virtual function 1707 and specific hardware 1708 on the destination server through the physical function 1706.

[0208] Figure 28 This is a structural diagram illustrating an integrated circuit device 2800 according to an embodiment of the present disclosure. Figure 28 As shown, the integrated circuit device 2800 is the system-on-a-chip 106 in the aforementioned embodiments, which includes a specific virtual suite 2802, which is at least one of a virtual computing device, a virtual video encoding / decoding device, and a virtual JPEG encoding / decoding device. In addition, the integrated circuit device 2800 also includes a general interconnect interface 2804 and other processing devices 2806.

[0209] Other processing devices 2806 may be one or more types of processors, such as central processing units, graphics processing units, and artificial intelligence processors, and their number is not limited but determined according to actual needs. Other processing devices 2806 serve as the interface between the specific virtual suite 2802 and external data and control, performing tasks including but not limited to data transfer and basic control such as starting and stopping the specific virtual suite 2802. Other processing devices 2806 may also cooperate with the specific virtual suite 2802 to jointly complete computational tasks.

[0210] The general-purpose interconnect interface 2804 can be used to transfer data and control commands between a specific virtual suite 2802 and other processing devices 2806. For example, the specific virtual suite 2802 can obtain the required input data from other processing devices 2806 via the general-purpose interconnect interface 2804 and write it to the on-chip storage unit of the specific virtual suite 2802. Furthermore, the specific virtual suite 2802 can obtain control commands from other processing devices 2806 via the general-purpose interconnect interface 2804 and write them to the on-chip control cache of the specific virtual suite 2802. Alternatively or optionally, the general-purpose interconnect interface 2804 can also read data from the storage module of the specific virtual suite 2802 and transmit it to other processing devices 2806.

[0211] The integrated circuit device 2800 also includes a storage device 2808, which can be connected to the specific virtual suite 2802 and other processing devices 2806 respectively. The storage device 2808 is also known as the virtual storage device 148, which is used to store data of the specific virtual suite 2802 and other processing devices 2806, and is particularly suitable for data that needs to be processed but cannot be fully stored in the internal storage of the specific virtual suite 2802 or other processing devices 2806.

[0212] Depending on the application scenario, the integrated circuit device 2800 can serve as a system-on-a-chip (SoC) for devices such as mobile phones, robots, drones, and video capture devices, thereby effectively reducing the core area of ​​the control section, increasing processing speed, and reducing overall power consumption. In this case, the general-purpose interconnect interface 2804 of the integrated circuit device 2800 is connected to certain components of the device. These components may include, for example, a camera, monitor, mouse, keyboard, network card, or Wi-Fi interface.

[0213] This disclosure also discloses a chip or integrated circuit chip that includes an integrated circuit device 2800. This disclosure further discloses a chip package structure that includes the aforementioned chip.

[0214] Another embodiment of this disclosure is a circuit board that includes the above-described chip package structure. See also... Figure 29 In addition to including multiple chips 2902, the board 2900 may also include other supporting components, such as a storage device 2904, an interface device 2906, and a controller 2908.

[0215] The storage device 2904 is connected to the chip 2902 within the chip package structure via a bus 2914 and is used to store data. The storage device 2904 may include multiple sets of storage cells 2910.

[0216] Interface device 2906 is electrically connected to chip 2902 within the chip package structure. Interface device 2906 is used to realize data transmission between chip 2902 and external device 2912 (e.g., a server or computer). In this embodiment, interface device 2906 is a standard PCIe interface. Data to be processed is transferred from the server to chip 2902 via the standard PCIe interface, realizing data transfer. The calculation results of chip 2902 are also transmitted back to external device 2912 by interface device 2906.

[0217] The controller 2908 is electrically connected to the chip 2902 to monitor the status of the chip 2902. Specifically, the chip 2902 and the controller 2908 can be electrically connected via an SPI interface. The controller 2908 may include a microcontroller (“MCU”).

[0218] Another embodiment of this disclosure is an electronic device or apparatus that includes the aforementioned board 2900. Depending on the application scenario, the electronic device or apparatus may include a data processing device, robot, computer, printer, scanner, tablet computer, smart terminal, mobile phone, dashcam, navigator, sensor, camera, server, cloud server, camera, camcorder, projector, watch, earphone, mobile storage, wearable device, vehicle, home appliance, and / or medical device. The vehicle includes airplanes, ships, and / or vehicles; the home appliances include televisions, air conditioners, microwave ovens, refrigerators, rice cookers, humidifiers, washing machines, lights, gas stoves, and range hoods; the medical devices include MRI scanners, ultrasound machines, and / or electrocardiographs.

[0219] Another embodiment of this disclosure is a computer-readable storage medium storing serialized or deserialized computer program code that, when run by a processor, performs the aforementioned method.

[0220] This disclosure enables the hot migration of virtual specific functions and virtual hardware drivers, firmware and hardware information, context information and their status information from the source server to the destination server. It uses serialization technology to generate the information to be migrated to facilitate transmission. The destination server then deserializes the information to be migrated based on the same protocol to restore its configuration and data.

[0221] The foregoing can be better understood in accordance with the following terms:

[0222] Clause A1. A system for serializing logical pointers, comprising: memory for storing a first structure and a second structure; and serialization means for: responding to a hot migration initiation request to generate migration information; generating a first symbolic identifier and a first entity identifier in a data structure of the migration information; placing the name of the first structure in the first symbolic identifier; and placing the name of the logical pointer in the first entity identifier, wherein the name of the logical pointer is the name of the second structure.

[0223] Clause A2, the system according to Clause A1, wherein the first structure includes at least one first type, and the serialization device generates a first type identifier in the data structure to record the first type.

[0224] Clause A3, the system according to Clause A1, wherein the serialization device generates a first key identifier in the data structure to record the name of the logical pointer.

[0225] Clause A4. The system according to Clause A1, wherein the serialization device generates a second symbolic identifier in the data structure for inserting the name of the second structure.

[0226] Clause A5. The system according to Clause A1, wherein the second structure includes at least one second type, and the serialization device generates a second type identifier in the data structure to record the second type.

[0227] Clause A6. The system according to Clause A5, wherein the second type includes at least one variable, and the serialization device generates a second key identifier in the data structure to record the name of the variable.

[0228] Clause A7. The system according to Clause A6, wherein the serialization device generates a second entity identifier in the data structure to record information about the variable.

[0229] Clause A8. A system for deserializing logical pointers, comprising: a deserializing device for: receiving information to be migrated, the data structure of the information to be migrated including a first symbol identifier and a first entity identifier; extracting the name of the first structure from the first symbol identifier; and extracting the name of the second structure from the first entity identifier.

[0230] Clause A9. The system according to Clause A8, wherein the first structure includes at least one first type, the data structure includes a first type identifier, and the deserializing device identifies the first type from the first type identifier.

[0231] Clause A10, the system according to Clause A8, wherein the data structure includes a first key identifier, and the deserializing device extracts the name of the logical pointer from the first key identifier.

[0232] Clause A11. The system according to Clause A8, wherein the data structure includes a second symbolic identifier, the deserializing device extracts the name of the second structure from the second symbolic identifier and compares it with the name of the logical pointer.

[0233] Clause A12, the system according to Clause A8, wherein the second structure includes at least one second type, the data structure includes a second type identifier, and the deserializing device identifies the second type from the second type identifier.

[0234] Clause A13, the system according to Clause A12, wherein the second type includes at least one variable, the data structure includes a second key identifier, and the deserializing device extracts the name of the variable from the second key identifier.

[0235] Clause A14, the system according to Clause A13, wherein the data structure includes a second entity identifier, and the deserializing device extracts information of the variable from the second entity identifier.

[0236] Clause A15, an integrated circuit device comprising the system described in any one of Clauses A1-13.

[0237] Clause A16, a board including the integrated circuit device as described in Clause A15.

[0238] Clause A17. A method for serializing a logical pointer, the logical pointer associating a first structure with a second structure, the method comprising: responding to a hot migration initiation request to generate migration information; generating a first symbolic identifier and a first entity identifier in a data structure of the migration information; placing the name of the first structure in the first symbolic identifier; and placing the name of the second structure in the first entity identifier.

[0239] Clause A18. A method for deserializing a logical pointer, comprising: receiving information to be migrated, the data structure of the information to be migrated including a first symbol identifier and a first entity identifier; retrieving the name of the first structure from the first symbol identifier; and retrieving the name of the second structure from the first entity identifier.

[0240] Clause A19. A computer-readable storage medium having stored thereon computer program code that, when run by a processing device, performs the method described in Clause A17 or 18.

Claims

1. A system for serializing logical pointers, comprising: Memory is used to store the first structure and the second structure; as well as Serialization device, used for: Respond to the live migration start request to generate migration information; Generate a first symbolic identifier and a first entity identifier in the data structure of the information to be migrated; The name of the first structure is entered into the first symbol identifier; as well as The name of the logical pointer is placed in the first entity identifier, and the name of the logical pointer is the name of the second structure, wherein the logical pointer is used to establish an association between the first structure and the second structure; The first structure includes at least one first type, and the serialization device generates a first type identifier in the data structure to record the first type; The second structure includes at least one second type, and the serialization device generates a second type identifier in the data structure to record the second type; The second type includes at least one variable, and the serialization device generates a second key identifier in the data structure to record the name of the variable; The serialization device generates a second entity identifier in the data structure to record information about the variable.

2. The system according to claim 1, wherein the serialization device generates a first key identifier in the data structure to record the name of the logical pointer.

3. The system according to claim 1, wherein the serialization device generates a second symbolic identifier in the data structure for inserting the name of the second structure.

4. A system for deserializing logical pointers, comprising: Deserialization device, used for: Receive information to be migrated, wherein the data structure of the information to be migrated includes a first symbol identifier and a first entity identifier; Extract the name of the first structure from the first symbol identifier; as well as The name of the second structure is extracted from the first entity identifier, wherein the logical pointer is used to establish an association between the first structure and the second structure; The first structure includes at least one first type, the data structure includes a first type identifier, and the deserialization device identifies the first type from the first type identifier; The second structure includes at least one second type, the data structure includes a second type identifier, and the deserialization device identifies the second type from the second type identifier; The second type includes at least one variable, the data structure includes a second key identifier, and the deserialization device extracts the name of the variable from the second key identifier; The data structure includes a second entity identifier, and the deserialization device extracts the variable information from the second entity identifier.

5. The system according to claim 4, wherein the data structure includes a first key identifier, and the deserializing device extracts the name of the logical pointer from the first key identifier.

6. The system according to claim 4, wherein the data structure includes a second symbol identifier, the deserializing device extracts the name of the second structure from the second symbol identifier, and compares it with the name of the logical pointer.

7. An integrated circuit device comprising the system according to any one of claims 1-6.

8. A board comprising the integrated circuit device according to claim 7.

9. A method for serializing a logical pointer, wherein the logical pointer associates a first structure with a second structure, the method comprising: Respond to the live migration start request to generate migration information; Generate a first symbolic identifier and a first entity identifier in the data structure of the information to be migrated; The name of the first structure is entered into the first symbol identifier; as well as The name of the second structure is entered into the first entity identifier; The first structure includes at least one first type, and a first type identifier is generated in the data structure to record the first type; The second structure includes at least one second type, and a second type identifier is generated in the data structure to record the second type; The second type includes at least one variable, and a second key identifier is generated in the data structure to record the name of the variable; A second entity identifier is generated in the data structure to record information about the variable.

10. A method for deserializing a logical pointer, comprising: Receive information to be migrated, wherein the data structure of the information to be migrated includes a first symbol identifier and a first entity identifier; Extract the name of the first structure from the first symbol identifier; as well as The name of the second structure is extracted from the first entity identifier, wherein the logical pointer is used to establish an association between the first structure and the second structure; The first structure includes at least one first type, and the data structure includes a first type identifier, from which the first type is identified; The second structure includes at least one second type, and the data structure includes a second type identifier, from which the second type is identified; The second type includes at least one variable, and the data structure includes a second key identifier from which the name of the variable is extracted; The data structure includes a second entity identifier from which information about the variable is extracted.

11. A computer-readable storage medium having stored thereon computer program code of processing logic pointers, which, when run by a processing device, performs the method of claim 9 or 10.

Images