System methods, apparatus and storage media for achieving thermal migration

Abstract

This disclosure relates to methods, systems, integrated circuit devices, boards, and computer-readable storage media for implementing hot migration, wherein the system-on-a-chip of this disclosure is included in an integrated circuit device, which includes a general interconnect interface and other processing devices. The computing device interacts with the other processing devices to jointly perform user-specified computational operations. The integrated circuit device may also include a storage device connected to the computing device and other processing devices respectively, for data storage of the computing device and 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, circuit board, and computer-readable storage medium for implementing hot migration. 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 realizing hot migration.

[0005] According to a first aspect of this disclosure, a system for implementing hot migration storage is provided, connected to kernel space, comprising: a read-only storage device and a serialization device. The read-only storage device stores firmware, the firmware including physical functions virtualized into multiple virtual functions, the physical functions receiving a hot migration start request from the kernel space, the hot migration start request specifying a particular virtual function to be hot migrated, the particular virtual function being one of the multiple virtual functions. The serialization device is used to respond to the hot migration start request to generate a data structure of information to be migrated, the data structure including a protocol layer, the protocol layer including a domain identifier for recording the particular virtual function. The physical function sends the information to be migrated to the kernel space.

[0006] According to another aspect of this disclosure, a system for implementing hot migration recovery is provided, connected to kernel space, comprising: a read-only storage device and a deserialization device. The read-only storage device stores firmware, the firmware including physical functions, virtualized into multiple virtual functions, the physical functions receiving information to be migrated, the data structure of the information to be migrated including a protocol layer, the protocol layer including a domain identifier. The deserialization device is used to: extract information of a specific virtual function from the domain identifier, the specific virtual function being one of the multiple virtual functions; and restore the information to be migrated to the specific virtual function.

[0007] According to another aspect of this disclosure, an integrated circuit device is provided, including the system according to the foregoing; and a board is provided, including the integrated circuit device described above.

[0008] According to another aspect of this disclosure, a method for hot-migrating and saving a path to a system is provided. The system is connected to a kernel space and includes a read-only storage device (ROM). The ROM stores firmware, which includes physical functions virtualized into a plurality of virtual functions. The method includes: receiving a hot-migrating start request, the hot-migrating start request specifying a particular virtual function to be hot-migrated, the particular virtual function being one of the plurality of virtual functions; generating a data structure for information to be migrated, the data structure including a domain identifier for recording the particular virtual function; and sending the information to be migrated to the kernel space.

[0009] According to another aspect of this disclosure, a method for hot-migrating and restoring a path to a system is provided, the system being connected to kernel space and including a read-only storage device storing firmware, the firmware including physical functions, the physical functions being virtualized into a plurality of virtual functions, the method comprising: receiving information to be migrated, the data structure of the information to be migrated including a domain identifier; retrieving information of a specific virtual function from the domain identifier, the specific virtual function being one of the plurality of virtual functions; and restoring the information to be migrated to the specific virtual function.

[0010] According to another aspect of this disclosure, a computer-readable storage medium is provided that stores hot-migrating computer program code that, 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 3This 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 migration recovery path of an embodiment of this disclosure;

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

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

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

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

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

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

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

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

[0034] 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.

[0035] 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.

[0036] 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.

[0037] 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."

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

[0039] 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.

[0040] Figure 1This 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.

[0041] 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.

[0042] 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.

[0043] 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.

[0044] 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.

[0045] 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.

[0046] 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.

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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.

[0051] 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.

[0052] 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.

[0053] 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.

[0054] 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.

[0055] 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.

[0056] 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.

[0057] 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.

[0058] 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.

[0059] 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.

[0060] 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.

[0061] 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.

[0062] 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.

[0063] 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.

[0064] 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.

[0065] 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.

[0066] 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.

[0067] 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 specific hardware-related drivers, firmware, hardware information, context information, and status information of the system-on-a-chip 106 are packaged and sent out from the source server. The "status information" may include the status information of virtual function drivers, firmware and hardware status information, state machines, registers, context status information of internal hardware states, software state machines, variables, and runtime context status information of constants, etc.

[0068] 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.

[0069] 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.

[0070] 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.

[0071] 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.

[0072] 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.

[0073] 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.

[0074] 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.

[0075] 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.

[0076] 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.

[0077] 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, which specifies a particular hardware 408 for hot migration. The particular 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 hardware 408.

[0078] Specific hardware 408 can be a specific virtual computing device, such as Figure 1The 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. Specific hardware 408 can also be... Figure 1 If the 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 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.

[0079] 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 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 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 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.

[0080] 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.

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

[0082] In step 310, after the migration command is sent, physical function 406 releases the resources of specific 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 save path ends.

[0083] 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 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.

[0084] 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.

[0085] 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.

[0086] 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.

[0087] 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.

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

[0089] 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.

[0090] 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.

[0091] 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.

[0092] 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.

[0093] 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.

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

[0095] 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.

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

[0097] 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.

[0098] 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.

[0099] 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.

[0100] 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.

[0101] 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.

[0102] 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.

[0103] 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.

[0104] 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.

[0105] 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.

[0106] 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.

[0107] 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.

[0108] 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.

[0109] 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".

[0110] 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".

[0111] 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.

[0112] 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.

[0113] 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.

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

[0115] 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.

[0116] 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.

[0117] 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.

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

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

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

[0121] 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.

[0122] 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.

[0123] 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.

[0124] 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.

[0125] 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 node 704's node 706, 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.

[0126] 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.

[0127] 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.

[0128] 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.

[0129] 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.

[0130] 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.

[0131] 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).

[0132] 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.

[0133] 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.

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

[0135]

[0136]

[0137] 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.

[0138] 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.

[0139] 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.

[0140] 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".

[0141] 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.

[0142] 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.

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

[0144]

[0145] 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.

[0146] 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".

[0147] 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".

[0148] 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.

[0149] 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.

[0150] 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.

[0151] 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.

[0152] 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.

[0153] 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.

[0154] 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.

[0155] 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.

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

[0157] 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.

[0158] 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.

[0159] 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.

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

[0161] 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.

[0162] 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.

[0163] 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 13 This is a flowchart illustrating the migration and recovery path. Figure 14 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.

[0164] In step 1301, Libvirt 1401 sends a request to QEMU 1402 to import the information to be migrated. QEMU 1402 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.

[0165] In step 1302, VMLUQOM 1404 sends the migration information to the physical function driver 1403. After receiving the migration instruction, VMLUQOM 1404 responds to the hot migration start request, calls the write function, and sends the migration information to the physical function driver 1403.

[0166] In step 1303, physical function 1406 receives the migration information. In the previous step, VMLU QOM 1404 sent the migration information to physical function driver 1403, and physical function driver 1403 then sent the migration information to physical function 1406.

[0167] In step 1304, the configuration, data and context are restored for specific virtual functions 1407 and specific hardware 1408.

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

[0169] Similarly, specific hardware 1408 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 specific hardware 1408. Upon recovery, specific virtual function 1407 and specific hardware 1408 will have the exact same environment and data as specific virtual function 407 and specific hardware 408.

[0170] In step 1305, physical function 1406 reports to physical function driver 1403 that the migration is complete. After the instruction is sent, physical function 1406 sends an end signal to physical function driver 603 in kernel space 104.

[0171] In step 1306, the physical function driver 1403 notifies the VMLU QOM 1404 that the hot migration has been completed, that is, the physical function driver 1403 sends a stop signal to the QEMU 1402.

[0172] In step 1307, VMLU QOM 1404 changes its state to notify the virtual function driver 1405 that the hot migration is complete. VMLU QOM 1404 responds to the end signal, notifying the virtual function driver 1405 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 1407 and specific hardware 1408 of the destination server.

[0173] In step 1308, the virtual function driver 1405 sends a control signal to the virtual function driver interface 1409 to resume the execution of the guest operating system's tasks.

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

[0175] In step 1310, VMLU QOM 1404 notifies Libvirt 1401 that the hot migration is complete, and Libvirt 1401 cleans up the hardware resources allocated on the source server. This completes the migration recovery path.

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

[0177] In more detail, Figure 14 The system also includes a deserialization device 1410, which responds to a hot migration start request and, in step 1304, recovers data such as the driver, firmware, and specific hardware 1408 information, context information, and status information of the specific virtual function 1407 based on the migration information. The deserialization device 1410 in this embodiment can be implemented using hardware or firmware. If it is hardware, the deserialization device 1410 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.

[0178] The method for implementing the hot migration recovery path using the deserialization device 1410 is as follows: Figure 15As described above. In step 1501, the deserialization device 1410 receives the information to be migrated. In step 1502, the deserialization device 1410 deserializes the information of the protocol layer 51. This step is further refined into... Figure 16 The process.

[0179] In step 1601, since the source server and the destination server follow the same protocol, the deserialization device 1410 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 1602, 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 1603, 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.

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

[0181] Next, in step 1606, 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 encoding / decoding device, a virtual JPEG encoding / decoding device, and a virtual storage device, and the deserializing device 1410 restores the information to be migrated to the specified specific virtual suite according to the information in the data source identifier 506.

[0182] Next, in step 1607, 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 1608, 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 1407. In step 1609, the information of the data structure layer 52 is retrieved from the payload identifier 510.

[0183] In step 1503, the deserializing device 1410 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.

[0184] If data structure layer 52 records configuration information, then step 1504 is executed to deserialize the configuration information. This step is further refined into... Figure 17The process is as follows: In step 1701, the deserializing device 1410 extracts the specific hardware information from the domain identifier 511, preparing to restore the information to be migrated to the specific hardware 1408. In step 1702, 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 1703, 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 1704, 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.

[0185] In step 1705, 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 1706, 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 1707, 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.

[0186] Next, in step 1708, information about a 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 1408, which is one of the virtual computing device, virtual video codec device, virtual JPEG codec device, and virtual storage device.

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

[0188] If data structure layer 52 is used to record data information, then step 1505 is executed to deserialize the data information. This step is refined into... Figure 18 The process is as follows: In step 1801, the deserialization device 1410 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 deserialization device 1410 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 1802, the type is identified from the type identifier 526. In step 1803, the name of the variable is extracted from the key identifier 527. Similarly, since the key identifier 527 includes a prefix symbol, the deserialization device 1410 first identifies the prefix symbol and can then extract the name of the variable based on the prefix symbol. In step 1804, the information of the serialization layer 53 is extracted from the entity identifier 528.

[0189] Back Figure 15 Next, step 1506 is executed to identify or extract information from the serialization layer 53. This step is further refined into... Figure 19 The process is as follows: In step 1901, the deserializing device 1410 then identifies the start of the serialization layer 53 based on the magic number identifier 529. In step 1902, the length of the serialization layer 53 is identified from the length identifier 530. In step 1903, the storage byte order of the data is identified as big-endian or little-endian based on the byte order identifier 531. In step 1904, the compression format of the data is identified based on the compression identifier 532. In step 1905, the type is identified based on the type identifier 533. In step 1906, the variable name is extracted from the key identifier 534. In step 1907, the number of variables is identified based on the count identifier 535. In step 1908, the variable format is identified based on the format identifier 536. In step 1909, the value or string of the variable is extracted from the value identifier 537.

[0190] The deserializing device 1410 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 1407 and specific hardware 1408 on the destination server through the physical function 1406.

[0191] Figure 20 This is a structural diagram illustrating an integrated circuit device 2000 according to an embodiment of the present disclosure. Figure 20 As shown, the integrated circuit device 2000 is the system-on-a-chip 106 in the aforementioned embodiments, which includes a specific virtual suite 2002, 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 2000 also includes a general interconnect interface 2004 and other processing devices 2006.

[0192] Other processing devices 2006 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 2006 serve as the interface between the specific virtual suite 2002 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 2002. Other processing devices 2006 may also collaborate with the specific virtual suite 2002 to complete computational tasks.

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

[0194] The integrated circuit device 2000 also includes a storage device 2008, which can be connected to the specific virtual suite 2002 and other processing devices 2006 respectively. The storage device 2008 is a virtual storage device 148, used to store data of the specific virtual suite 2002 and other processing devices 2006, especially suitable for data that needs to be processed but cannot be fully stored in the internal storage of the specific virtual suite 2002 or other processing devices 2006.

[0195] Depending on the application scenario, the integrated circuit device 2000 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 interconnect interface 2004 of the integrated circuit device 2000 connects to certain components of the device. These components may be, for example, a camera, monitor, mouse, keyboard, network card, or Wi-Fi interface.

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

[0197] Another embodiment of this disclosure is a circuit board that includes the above-described chip package structure. See also... Figure 21 In addition to including multiple chips 2102, the board 2100 may also include other supporting components, including a storage device 2104, an interface device 2106, and a controller 2108.

[0198] The storage device 2104 is connected to the chip 2102 within the chip package structure via a bus 2114 and is used to store data. The storage device 2104 may include multiple sets of storage cells 2110.

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

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

[0201] Another embodiment of this disclosure is an electronic device or apparatus that includes the aforementioned board 2100. 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.

[0202] Another embodiment of this disclosure is a computer-readable storage medium storing hot-migrating computer program code that performs the aforementioned method when the computer program code is run by a processor.

[0203] 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.

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

[0205] Clause A1. A system for implementing hot migration saving, connected to kernel space, comprising: a read-only storage device storing firmware, the firmware including physical functions virtualized into a plurality of virtual functions, the physical functions receiving a hot migration start request from the kernel space, the hot migration start request specifying a specific virtual function to be hot migrated, the specific virtual function being one of the plurality of virtual functions; and a serialization device for responding to the hot migration start request to generate a data structure of information to be migrated, the data structure including a protocol layer, the protocol layer including a domain identifier for recording the specific virtual function; wherein the physical function sends the information to be migrated to the kernel space.

[0206] Clause A2, the system according to Clause A1, wherein the serialization device generates a version identifier in the protocol layer to mark the version of the information to be migrated.

[0207] Clause A3. The system described in Clause A1 further includes suites, virtualized into multiple virtual suites, each virtual function corresponding to one virtual suite, wherein the suite includes at least one of a computing device, a video encoding / decoding device, a JPEG encoding / decoding device, and a storage device, and the specific virtual function corresponds to a specific virtual suite.

[0208] Clause A4. In the system described in Clause A3, the information to be migrated originates from a specific device, which is at least one of the computing device, the video encoding / decoding device, the JPEG encoding / decoding device, and the storage device, and the serialization device generates a data source identifier in the protocol layer to record the specific device.

[0209] Clause A5. The system according to Clause A1, wherein the data structure further includes a data structure layer, and the serialization device generates a payload symbol in the protocol layer, the payload symbol being used to record information of the data structure layer.

[0210] Clause A6. The system described in Clause A5, wherein the data structure layer is used to record configuration information.

[0211] Clause A7. The system according to Clause A6, wherein the serialization device generates a chip identifier in the data structure layer to record the chipset model of the system.

[0212] Clause A8. The system according to Clause A6, wherein the serialization device generates a board identifier in the data structure layer to record the board version or model of the system.

[0213] Clause A9. The system according to Clause A6, wherein the serialization device generates a firmware identifier in the data structure layer to record the firmware version of the system.

[0214] Clause A10. The system described in Clause A6, wherein the information to be migrated comes from a specific device, the specific device being at least one of a computing device, a video encoding / decoding device, a JPEG encoding / decoding device, and a storage device in the system, and the serialization device generating a specific device identifier in the data structure layer to record the configuration of the specific device.

[0215] Clause A11, the system described in Clause A5, wherein the data structure layer is used to record data information.

[0216] Clause A12, the system according to Clause A11, wherein the data information includes a structure, and the serialization device generates a symbolic identifier in the data structure layer to mark the beginning of the structure.

[0217] Clause A13, the system according to Clause A12, wherein the structure includes at least Clause A1, a type, and the serialization device generates a type identifier in the data structure layer to record the type.

[0218] Clause A14. The system according to Clause A13, wherein the type includes at least one variable, and the serialization device generates a key identifier in the data structure layer to record the name of the variable.

[0219] Clause A15. The system according to Clause A13, wherein the data structure further includes a serialization layer, and the serialization device generates entity identifiers in the data structure layer to record information of the serialization layer.

[0220] Clause A16, the system according to Clause A15, wherein the serialization device generates a magic number identifier in the serialization layer to indicate the start of the serialization layer.

[0221] Clause A17. The system according to Clause A15, wherein the data information includes a type, and the serialization device generates a type identifier in the serialization layer to identify the type.

[0222] Clause A18, the system according to Clause A17, wherein the type includes at least one variable, and the serialization device generates a key identifier in the serialization layer to identify the name of the variable.

[0223] Clause A19. The system according to Clause A18, wherein the serialization device generates a numerical identifier in the serialization layer to record the numerical value or string of the variable.

[0224] Clause A20. A system for implementing hot migration recovery, connected to kernel space, comprising: a read-only storage device storing firmware including physical functions, virtualized into multiple virtual functions, the physical functions receiving information to be migrated, the data structure of the information to be migrated including a protocol layer, the protocol layer including a domain identifier; and a deserializing device for: retrieving information of a specific virtual function from the domain identifier, the specific virtual function being one of the multiple virtual functions; and restoring the information to be migrated to the specific virtual function.

[0225] Clause A21. The system described in Clause A20 further includes a suite, virtualized into multiple virtual suites, each virtual function corresponding to one virtual suite, wherein the suite includes at least one of a computing device, a video encoding / decoding device, a JPEG encoding / decoding device, and a storage device, and the deserializing device restores the information to be migrated to the corresponding specific virtual suite according to the specific virtual function.

[0226] Clause A22. The system according to Clause A20, wherein the data structure further includes a data structure layer, and the protocol layer further includes a payload symbol for recording information of the data structure layer.

[0227] Clause A23, the system described in Clause A22, wherein the data structure layer is used to record configuration information.

[0228] Clause A24. The system according to Clause A23, wherein the data structure layer further includes a chip identifier, and the deserializing device identifies the chipset model of the system from the chip identifier.

[0229] Clause A25. The system according to Clause A23, wherein the data structure layer further includes a board identifier, and the deserializing device identifies the board version or model of the system from the board identifier.

[0230] Clause A26. The system according to Clause A23, wherein the data structure layer further includes a specific device identifier, the deserializing device restores the configuration of the specific device based on the specific device identifier, and the specific device is at least one of a computing device, a video encoding / decoding device, a JPEG encoding / decoding device, and a storage device in the system.

[0231] Clause A27. The system described in Clause A22, wherein the data structure layer is used to record data information.

[0232] Clause A28. The system according to Clause A27, wherein the data information includes a structure, the data structure layer further includes a symbolic identifier, and the deserialization device identifies the beginning of the structure from the symbolic identifier.

[0233] Clause A29, the system according to Clause A28, wherein the structure includes at least Clause A1, a type, the data structure layer further includes a type identifier, and the deserializing device identifies the type from the type identifier.

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

[0235] Clause A31. The system according to Clause A29, wherein the data structure further includes a serialization layer, and the data structure layer further includes an entity identifier for recording information of the serialization layer.

[0236] Clause A32, the system according to Clause A31, wherein the data information includes a type, the serialization layer includes a type identifier, and the deserialization device identifies the type from the type identifier.

[0237] Clause A33, the system according to Clause A32, wherein the type includes at least one variable, the serialization layer includes a key identifier, and the deserialization device extracts the name of the variable from the key identifier.

[0238] Clause A34, the system according to Clause A33, wherein the serialization layer includes a numeric identifier, and the deserialization device extracts the numeric value or string of the variable from the numeric identifier.

[0239] Clause A35, an integrated circuit device comprising the system described in any one of Clauses A1-34.

[0240] Clause A36, a board including the integrated circuit device described in Clause A35.

[0241] Clause A37. A method for hot-migrating a system to save a path, the system being connected to kernel space and including a read-only storage device, the read-only storage device storing firmware, the firmware including physical functions, the physical functions being virtualized into a plurality of virtual functions, the method comprising: receiving a hot-migrating start request, the hot-migrating start request specifying a specific virtual function to be hot-migrated, the specific virtual function being one of the plurality of virtual functions; generating a data structure for migration information, the data structure including a domain identifier for recording the specific virtual function; and sending the migration information to the kernel space.

[0242] Clause A38. A method for hot-migrating and restoring a path to a system, the system being connected to kernel space and including a read-only storage device storing firmware including physical functions virtualized into a plurality of virtual functions, the method comprising: receiving migration information, the data structure of the migration information including a domain identifier; retrieving information of a specific virtual function from the domain identifier, the specific virtual function being one of the plurality of virtual functions; and restoring the migration information to the specific virtual function.

[0243] Clause A39. A computer-readable storage medium having hot-migrating computer program code stored thereon, which, when run by a processor, performs the methods described in Clause A37 or 38.

Claims

1. A system for implementing live migration, coupled to a kernel space, the kernel space being a space where kernel codes run, the system comprising: a read-only memory storing firmware, the firmware including a physical function, virtualized into a plurality of virtual functions, the physical function receiving a live migration initiation request from the kernel space, the live migration initiation request specifying a live migration of a specific virtual function, the specific virtual function being one of the plurality of virtual functions; and a serialization device for generating a data structure of migration information in response to the live migration initiation request, the data structure including a protocol layer, the protocol layer including a domain identifier for recording the specific virtual function, wherein the migration information is generated by serializing the specific virtual function; wherein the physical function sends the migration information to the kernel space; wherein the data structure further includes a data structure layer for indicating an organization of the migration information, the data structure layer for recording data information; the data structure further including a serialization layer, the entity identifier being expanded into the serialization layer to serialize a complex structure when a variable has the complex structure; the serialization device generating an entity identifier in the data structure layer for recording information of the serialization layer.

2. The system of claim 1, wherein the serialization device generates a version identifier in the protocol layer for marking a version of the migration information.

3. The system of claim 1, further comprising a suite, virtualized into a plurality of virtual suites, each virtual function corresponding to a virtual suite, wherein the suite includes at least one of a compute device, a video codec device, a JPEG codec device, and a storage device, the specific virtual function corresponding to a specific virtual suite.

4. The system of claim 3, wherein the migration information is from a specific device, the specific device being at least one of the compute device, the video codec device, the JPEG codec device, and the storage device, the serialization device generating a data source identifier in the protocol layer for recording the specific device.

5. The system of claim 1, the serialization device generating a payload symbol in the protocol layer for recording information of the data structure layer.

6. The system of claim 5, wherein the data structure layer records configuration information.

7. The system of claim 6, wherein the serialization device generates a chip identifier in the data structure layer for recording a chipset model of the system.

8. The system of claim 6, wherein the serialization device generates a board identifier in the data structure layer for recording a board version or model of the system.

9. The system of claim 6, wherein the serialization device generates a firmware identifier in the data structure layer for recording a firmware version of the system. ​ 10. The system of claim 6, wherein the information to be migrated is from a specific device, the specific device being at least one of a computing device, a video codec device, a JPEG codec device, and a storage device in the system, the serialization device generating a specific device identifier in the data structure layer to record a configuration of the specific device.

11. The system of claim 1, wherein the data information includes a structure, the serialization device generating a symbol identifier in the data structure layer to mark a beginning of the structure.

12. The system of claim 11, wherein the structure includes at least one type, the serialization device generating a type identifier in the data structure layer to record the type.

13. The system of claim 12, wherein the type includes at least one variable, the serialization device generating a key identifier in the data structure layer to record a name of the variable.

14. The system of claim 1, wherein the serialization device generates a magic number identifier in the serialization layer to mark a beginning of the serialization layer.

15. The system of claim 1, wherein the data information includes a type, the serialization device generating a type identifier in the serialization layer to mark the type.

16. The system of claim 15, wherein the type includes at least one variable, the serialization device generating a key identifier in the serialization layer to mark a name of the variable.

17. The system of claim 16, wherein the serialization device generates a value identifier in the serialization layer to record a value or a string of the variable.

18. A system for live migration recovery, connected to a kernel space, the kernel space being a space where kernel code runs, the system comprising: a read-only storage device storing a firmware, the firmware including a physical function, virtualized into a plurality of virtual functions, the physical function receiving information to be migrated, a data structure of the information to be migrated including a protocol layer, the protocol layer including a domain identifier, wherein the information to be migrated is generated by a specific virtual function in serialization; wherein the data structure further includes a data structure layer, the data structure layer being used to represent an organization structure of the information to be migrated, the data structure layer recording data information; wherein the data structure further includes a serialization layer, when a variable has a complex structure, an entity identifier is expanded into the serialization layer to serialize the complex structure; a serialization device generating the entity identifier in the data structure layer to record information of the serialization layer; and a deserialization device to: extract information of the specific virtual function from the domain identifier, the specific virtual function being one of the plurality of virtual functions; and restore the information to be migrated into the specific virtual function.

19. The system of claim 18, further comprising a kit, virtualized into a plurality of virtual kits, each virtual function corresponding to a virtual kit, wherein the kit comprises at least one of a computing device, a video codec device, a JPEG codec device, and a storage device, and the de-serializing device restores the information to be migrated to the corresponding specific virtual kit according to the specific virtual function.

20. The system of claim 18, wherein the protocol layer further comprises a payload symbol, the payload symbol used to record information of the data structure layer.

21. The system of claim 20, wherein the data structure layer is used to record configuration information.

22. The system of claim 21, wherein the data structure layer further comprises a chip identifier, the de-serializing device identifying a chip set model of the system from the chip identifier.

23. The system of claim 21, wherein the data structure layer further comprises a board card identifier, the de-serializing device identifying a board card version or model of the system from the board card identifier.

24. The system of claim 21, wherein the data structure layer further comprises a specific device identifier, the de-serializing device restoring configuration of a specific device according to the specific device identifier, the specific device being at least one of a computing device, a video codec device, a JPEG codec device, and a storage device in the system.

25. The system of claim 18, wherein the data information comprises a structure, the data structure layer further comprises a symbol identifier, the de-serializing device identifying a start of the structure from the symbol identifier.

26. The system of claim 25, wherein the structure comprises at least one type, the data structure layer further comprises a type identifier, the de-serializing device identifying the type from the type identifier.

27. The system of claim 26, wherein the type comprises at least one variable, the data structure layer further comprises a key identifier, the de-serializing device taking a name of the variable from the key identifier.

28. The system of claim 18, wherein the data information comprises a type, the serialization layer comprises a type identifier, the de-serializing device identifying the type from the type identifier.

29. The system of claim 28, wherein the type comprises at least one variable, the serialization layer comprises a key identifier, the de-serializing device taking a name of the variable from the key identifier.

30. The system of claim 29, wherein the serialization layer comprises a value identifier, the de-serializing device taking a value or string of the variable from the value identifier.

31. An integrated circuit device comprising the system of any one of claims 1-30.

32. A board card comprising the integrated circuit device of claim 31. 33.A method for performing live migration save path of a system, the system being connected to a kernel space and comprising a read-only storage device, the kernel space being a space in which a kernel code runs, the read-only storage device storing a firmware, the firmware comprising physical functions, the physical functions being virtualized into a plurality of virtual functions, the method comprising: receiving a live migration start request, the live migration start request specifying a specific virtual function, the specific virtual function being one of the plurality of virtual functions; generating a data structure of to-be-migrated information, the data structure comprising a domain identifier, the domain identifier being used to record the specific virtual function, wherein the to-be-migrated information is generated by serializing the specific virtual function; wherein the data structure further comprises a data structure layer, the data structure layer being used to represent an organization structure of the to-be-migrated information, the data structure layer being used to record data information; wherein the data structure further comprises a serialization layer, when a variable has a complex structure, an entity identifier is expanded into the serialization layer to serialize the complex structure; a serialization device generates an entity identifier in the data structure layer to record information of the serialization layer; and sending the to-be-migrated information to the kernel space. 34.A method for performing live migration recovery path of a system, the system being connected to a kernel space and comprising a read-only storage device, the kernel space being a space in which a kernel code runs, the read-only storage device storing a firmware, the firmware comprising physical functions, the physical functions being virtualized into a plurality of virtual functions, the method comprising: receiving to-be-migrated information, a data structure of the to-be-migrated information comprising a domain identifier, wherein the to-be-migrated information is generated by serializing a specific virtual function; wherein the data structure further comprises a data structure layer, the data structure layer being used to represent an organization structure of the to-be-migrated information, the data structure layer being used to record data information; wherein the data structure further comprises a serialization layer, when a variable has a complex structure, an entity identifier is expanded into the serialization layer to serialize the complex structure; a serialization device generates an entity identifier in the data structure layer to record information of the serialization layer; extracting information of the specific virtual function from the domain identifier, the specific virtual function being one of the plurality of virtual functions; and recovering the to-be-migrated information into the specific virtual function. 35.A computer readable storage medium having stored thereon computer program codes of live migration, when the computer program codes are executed by a processor, performing the method of claim 33 or 34.

Images