A cloud platform-based autonomous controllable adaptive verification laboratory management system

Abstract

The application relates to the technical field of industrial cloud computing, in particular to a self-controllable adaptive verification laboratory management system based on a cloud platform, which comprises a cloud platform resource monitoring module; according to the multi-core virtual machine CPU thread identification and the host machine preemption suspension time value in the cloud platform resource pool, the suspension duration state on the host machine node is obtained; according to the corresponding time stamp counter value and the host machine preemption suspension time value under the suspension duration state, the counter increment value is generated. In the application, when all clock offset completion states are updated, the period alignment is executed according to the running cycle parameter value, the whole CPU thread reenters the unified running rhythm, the internal clock consistency and the execution consistency of the multi-core virtual machine are improved, the stability of the log time sequence, the verification result and the experimental environment in the self-controllable adaptive verification process is enhanced, and the influence of resource preemption and thread suspension on the verification accuracy is reduced.

Description

Technical Field

[0001] This invention relates to the field of industrial cloud computing technology, and in particular to an autonomous and controllable adaptive verification laboratory management system based on a cloud platform. Background Technology

[0002] Industrial cloud computing technology is a comprehensive technology based on cloud computing architecture, integrating virtualization, distributed computing, resource pooling, software-defined infrastructure, container orchestration, edge collaboration and intelligent scheduling, etc., to provide unified computing resources, storage resources and network resources management capabilities for industrial production, industrial R&D, industrial testing, industrial manufacturing and industrial operation and maintenance.

[0003] Existing industrial cloud computing technologies primarily focus on the unified management of computing, storage, and network resources, meeting the needs for centralized resource scheduling and elastic allocation. However, when multi-core virtual machines undertake adaptation and verification tasks, they focus more on the overall operating status of the virtual machine, lacking continuous correlation processing for CPU thread-level scheduling changes. When resource preemption or thread suspension occurs on the host machine, the time for different CPU threads to resume execution often differs. Some CPU threads have already resumed execution, while others remain in a waiting state, easily leading to multiple different time bases within the same multi-core virtual machine. Furthermore, time synchronization in existing operating models is typically performed at fixed intervals. During time synchronization, each CPU thread may continue its execution process, causing some threads to have completed time updates while others remain in their original time state, resulting in time discrepancies in log recording order, transaction execution order, and the verification process. Therefore, improvements are needed. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of existing technologies by proposing a cloud-based autonomous and controllable adaptive verification laboratory management system.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: A cloud-based autonomous and controllable adaptive verification laboratory management system includes: The cloud platform resource monitoring module obtains the suspension duration status on the host node based on the CPU thread identifier of the multi-core virtual machine in the cloud platform resource pool and the host machine preemption suspension time value. It generates a counter increment value based on the corresponding timestamp counter value and the host machine preemption suspension time value under the suspension duration status. It extracts the CPU thread identifier corresponding to the time limit exceeding the preset time limit and gathers all CPU thread identifiers belonging to the same multi-core virtual machine to generate an affinity suspension thread group. The clock skew compensation module obtains the clock drift deviation based on the time reading value of the CPU thread identifier in the virtual clock register within the affinity suspended thread group and the host system time value. Based on the time message synchronization cycle parameter under the multi-core virtual machine in the cloud platform management base, the clock drift deviation is divided into multiple compensation step values, and the multiple compensation step values ​​are assigned to the corresponding CPU thread identifier to establish step-by-step clock compensation variables. The interrupt barrier control module extracts the first triggering CPU thread identifier from the step-by-step clock compensation variables, writes a forced interception instruction to the operating system kernel interrupt vector table, freezes the running address information of all CPU thread identifiers except the first triggering CPU thread identifier in the execution engine state machine, establishes an execution engine suspension array, and writes all compensation step size values ​​into the clock offset field in the corresponding multi-core virtual machine control block of the execution engine suspension array to establish a globally consistent compensation vector.

[0006] Preferably, the system further includes: The collaborative wake-up scheduling module extracts the clock offset completion status of all CPU thread identifiers within the globally consistent compensation vector in the multi-core virtual machine control block. When the clock offset completion status changes to the updated mark, it sends the unfreezing instruction assigned to the execution engine suspension array to the underlying scheduling queue of the cloud platform. This restores the running address information under all CPU thread identifiers in the execution engine suspension array to the active mark state. Based on the running cycle parameter values ​​under all CPU thread identifiers, it performs cycle alignment operations to generate a collaborative verification clock alignment cluster.

[0007] Preferably, the step of obtaining the suspension duration status is as follows: Read the CPU thread identifier corresponding to each multi-core virtual machine in the cloud platform resource pool, locate the bearer node according to the host node mapping relationship recorded by the CPU thread identifier, call the host preemption suspension time value recorded by the host node for the CPU thread identifier item by item, match the CPU thread identifier, host node and host preemption suspension time value according to the same scheduling record, check whether the host preemption suspension time value is in a continuous timer state. If the host preemption suspension time value is in a continuous timer state, mark the CPU thread identifier as suspended. If the host preemption suspension time value is not in a continuous timer state, mark the CPU thread identifier as not suspended, and obtain the suspension duration status.

[0008] Preferably, the step of obtaining the affinity-suspended thread group is as follows: The process involves filtering CPU thread identifiers marked as suspended, extracting the timestamp counter value of the time when the suspension duration occurred according to the scheduling record corresponding to the CPU thread identifier, calling the host machine preemption suspension time value in the same scheduling record, adding the timestamp counter value to the host machine preemption suspension time value item by item, writing the sum to the counting record of the corresponding CPU thread identifier, generating a counter increment value, comparing the counter increment value with a preset time limit item by item, retaining CPU thread identifiers whose counter increment value is greater than the preset time limit value, and removing CPU thread identifiers whose counter increment value is less than or equal to the preset time limit value, thus obtaining the corresponding CPU thread identifiers that exceed the preset time limit value. Based on the CPU thread identifier corresponding to the time limit exceeding the preset limit, each CPU thread identifier is read item by item to its corresponding multi-core virtual machine. According to the multi-core virtual machine to which the CPU thread identifier belongs, all CPU thread identifiers belonging to the same multi-core virtual machine are retrieved in the cloud platform resource pool. All CPU thread identifiers belonging to the same multi-core virtual machine are merged according to the multi-core virtual machine. Duplicate CPU thread identifiers registered in the same multi-core virtual machine are deleted. The complete CPU thread identifier sequence in the same multi-core virtual machine is retained. The complete CPU thread identifier sequence is bound to the multi-core virtual machine to which the CPU thread identifier corresponding to the time limit exceeding the preset limit belongs, generating an affinity suspended thread group.

[0009] Preferably, the step of obtaining the clock drift deviation is as follows: Read the multi-core virtual machine identifier corresponding to each CPU thread identifier in the affinity suspended thread group, locate the virtual clock register according to the multi-core virtual machine identifier, extract the time read value written to the virtual clock register when the CPU thread identifier performs the time read operation, synchronously read the host system time value of the host node where the CPU thread identifier is located, establish a one-to-one correspondence between the time read value and the host system time value based on the CPU thread identifier and the same read time, subtract the host system time value from the time read value, retain the positive and negative directions of the difference, positive value marks the virtual clock advanced state, negative value marks the virtual clock lagging state, and zero value marks the virtual clock synchronized state to obtain the clock drift deviation.

[0010] Preferably, the step of obtaining the step-by-step clock compensation variable is as follows: According to the multi-core virtual machine identifier corresponding to the clock drift deviation, the time message synchronization period parameter in the multi-core virtual machine configuration record is read from the cloud platform management base. The number of CPU thread identifiers belonging to the same multi-core virtual machine in the affinity suspended thread group is counted. The initial division number is set according to the number of CPU thread identifiers. The clock drift deviation is divided equally according to the initial division number. The absolute value of each division result is compared with the time message synchronization period parameter. When the absolute value of the division result exceeds the time message synchronization period parameter, the division number is increased and the division is restarted. When the absolute value of all division results does not exceed the time message synchronization period parameter, the division is stopped. The remaining deviation that cannot be divided is incorporated into the last division result to generate multiple compensation step size values. According to the multi-core virtual machine identifier to which the multiple compensation step values ​​belong, the CPU thread identifiers belonging to the same multi-core virtual machine in the affinity suspending thread group are retrieved. An allocation order is established based on the arrangement order of the CPU thread identifiers in the affinity suspending thread group. The multiple compensation step values ​​are written into the compensation record of the corresponding CPU thread identifier one by one according to the allocation order. When the number of compensation step values ​​is greater than the number of CPU thread identifiers, they are allocated cyclically according to the arrangement order. When the number of compensation step values ​​is less than the number of CPU thread identifiers, the compensation step value corresponding to the unallocated CPU thread identifier is recorded as zero. The compensation step value, compensation direction, time message synchronization period parameter and allocation order corresponding to each CPU thread identifier are recorded to establish a step-by-step clock compensation variable.

[0011] Preferably, the step of obtaining the execution engine suspension array is as follows: Read the compensation trigger flag, trigger timestamp, allocation order, and multi-core virtual machine identifier corresponding to each CPU thread identifier in the step-by-step clock compensation variable. Filter the CPU thread identifiers whose compensation trigger flags have been changed, arrange them from earliest to latest according to the trigger timestamp, and arrange them from front to back according to the allocation order if the trigger timestamps are the same. Select the CPU thread identifier that is first in the order, locate the interrupt entry address of the corresponding multi-core virtual machine in the operating system kernel interrupt vector table, write the forced interception instruction to the interrupt entry address, lock the interrupt response range corresponding to the forced interception instruction, and obtain the first triggering CPU thread identifier. The system calls all CPU thread identifiers belonging to the same multi-core virtual machine from the step-by-step clock compensation variable, excludes the first triggering CPU thread identifier, locates the current running address information, instruction offset position, state transition position and activity flag of the remaining CPU thread identifiers in the execution engine state machine, saves the recovery order corresponding to the current running address information, modifies the activity flag of the remaining CPU thread identifiers to a freeze flag, blocks the state transition position from switching, arranges the frozen running address information according to the multi-core virtual machine identifier and recovery order, and establishes the execution engine suspension array.

[0012] Preferably, the step of obtaining the globally consistent compensation vector is as follows: Based on the execution engine suspension array, the corresponding multi-core virtual machine control block is located according to the multi-core virtual machine identifier. The compensation step size, compensation direction, and allocation order corresponding to each CPU thread identifier in the step-by-step clock compensation variable are read. The CPU thread identifier is bound to the clock offset field in the multi-core virtual machine control block item by item. All compensation step size values ​​are loaded into the write position of the corresponding clock offset field according to the allocation order. The number of CPU thread identifiers, the number of compensation step size values, and the number of clock offset fields are checked to see if they are consistent. If they are consistent, the same write trigger flag is sent to all write positions. If they are inconsistent, the writing is stopped and the binding relationship is re-checked. After confirming that all clock offset fields have been written, a globally consistent compensation vector is established.

[0013] Preferably, the step of obtaining the collaborative verification clock alignment cluster is as follows: Read the multi-core virtual machine identifier corresponding to each CPU thread identifier in the global consistent compensation vector, locate the multi-core virtual machine control block according to the multi-core virtual machine identifier, read the clock offset completion status corresponding to each CPU thread identifier in the multi-core virtual machine control block item by item, check whether the clock offset completion status has been written with the updated mark, register the CPU thread identifiers that have been written with the updated mark to the completion sequence, register the CPU thread identifiers that have not been written with the updated mark to the confirmation sequence, and repeatedly read the clock offset completion status corresponding to the confirmation sequence according to the arrangement order of the CPU thread identifiers in the global consistent compensation vector until the confirmation sequence is empty, confirm that all the clock offset completion statuses have been changed to the updated mark, and obtain the clock offset completion confirmation result; Based on the clock offset confirmation result, unfreeze instructions are generated according to the multi-core virtual machine identifier, CPU thread identifier and recovery order recorded in the execution engine suspension array. The unfreeze instructions are written into the underlying scheduling queue of the cloud platform. The running address information corresponding to all CPU thread identifiers in the execution engine suspension array is located item by item according to the recovery order. It is checked whether the current mark of the running address information is a frozen mark. The frozen mark is changed to an active mark state. The instruction offset position and state transition position corresponding to the running address information are restored. The running address information corresponding to all CPU thread identifiers is verified item by item to be restored to the active mark state. The execution engine recovery state is generated. Based on the execution engine recovery status, the runtime parameter values ​​corresponding to all CPU thread identifiers are read item by item. The runtime parameter values ​​belonging to the same multi-core virtual machine are grouped according to the multi-core virtual machine identifier. The cycle start position, cycle duration, and cycle boundary position of each group of runtime parameter values ​​are extracted. The latest cycle start position in the same group is selected as the unified start position. The cycle boundary position corresponding to each CPU thread identifier is adjusted according to the unified start position. Runtimes earlier than the unified start position are postponed to the unified start position. Runtimes exceeding the unified start position are retained to the next cycle boundary. The cycle start positions of all CPU thread identifiers in the same group are repeatedly verified to ensure that all CPU thread identifiers have completed the cycle alignment operation, and a collaborative verification clock alignment cluster is generated.

[0014] Compared with the prior art, the advantages and positive effects of the present invention are as follows: In this invention, the thread suspension status on the host node is continuously determined by reading the CPU thread identifier of the multi-core virtual machine and the preemption suspension time value of the host machine. A counter increment value is generated by combining the timestamp counter value, and CPU thread identifiers exhibiting continuous preemption are filtered according to a preset time limit. CPU thread identifiers belonging to the same multi-core virtual machine are uniformly merged into an affinity suspension thread group. This expands the subsequent processing object from a single thread to a set of threads with runtime relationships, avoiding the problem of inconsistent time bases within the same virtual machine caused by adjusting only local threads. Furthermore, by combining the time read value in the virtual clock register, the host system time value, and the time message synchronization period parameter, the clock drift deviation is broken down step by step and allocated to the corresponding CPU thread identifier, making the clock compensation process smoother and effectively reducing the clock jump phenomenon caused by one-time compensation. During the compensation process, the first triggering CPU thread identifier is used as the synchronization control entry point. The running address information corresponding to the identifiers of the remaining CPU threads is frozen uniformly, and execution is resumed uniformly after all compensation step values ​​are written. This ensures that all CPU threads maintain a consistent clock offset reference, preventing execution timing deviations caused by different CPU threads continuing to execute during the compensation period. After all clock offset completion statuses are updated, execution cycle alignment is performed based on the running cycle parameter values, allowing all CPU threads to re-enter a unified running rhythm. This not only improves the clock consistency and execution consistency within the multi-core virtual machine but also enhances the stability of log timing, verification results, and the experimental environment during the independent and controllable adaptation verification process. It also reduces the impact of resource contention and thread suspension on verification accuracy, improving the reliability of experimental results. Attached Figure Description

[0015] Figure 1 A graph showing the counter increment value versus the preset time limit; Figure 2This is a step-by-step compensation diagram for clock drift deviation. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0017] Please see Figure 1-2 This invention provides a technical solution: a cloud-based, autonomous, controllable, adaptable, and verification laboratory management system comprising: The cloud platform resource monitoring module obtains the suspension duration status on the host node based on the CPU thread identifier of the multi-core virtual machine in the cloud platform resource pool and the host machine preemption suspension time value. It generates a counter increment value based on the corresponding timestamp counter value and the host machine preemption suspension time value under the suspension duration status. It extracts the CPU thread identifier corresponding to the time limit exceeding the preset time limit and gathers all CPU thread identifiers belonging to the same multi-core virtual machine to generate an affinity suspension thread group. The clock skew compensation module obtains the clock drift deviation based on the time reading value of the CPU thread identifier in the virtual clock register within the affinity suspended thread group and the host system time value. Based on the time message synchronization cycle parameter under the multi-core virtual machine in the cloud platform management base, the clock drift deviation is divided into multiple compensation step values, and the multiple compensation step values ​​are assigned to the corresponding CPU thread identifier to establish step-by-step clock compensation variables. The interrupt barrier control module extracts the first triggering CPU thread identifier from the step-by-step clock compensation variables, writes a forced interception instruction to the operating system kernel interrupt vector table, freezes the running address information of all CPU thread identifiers except the first triggering CPU thread identifier in the execution engine state machine, establishes an execution engine suspension array, and writes all compensation step size values ​​into the clock offset field in the corresponding multi-core virtual machine control block of the execution engine suspension array to establish a globally consistent compensation vector. The collaborative wake-up scheduling module extracts the clock offset completion status of all CPU thread identifiers within the globally consistent compensation vector in the multi-core virtual machine control block. When the clock offset completion status changes to the updated mark, it sends the unfreezing instruction assigned to the execution engine suspension array to the underlying scheduling queue of the cloud platform. This restores the running address information under all CPU thread identifiers in the execution engine suspension array to the active mark state. Based on the running cycle parameter values ​​under all CPU thread identifiers, it performs cycle alignment operations to generate a collaborative verification clock alignment cluster.

[0018] The steps to obtain the suspension duration status are as follows: Read the CPU thread identifier corresponding to each multi-core virtual machine in the cloud platform resource pool, locate the bearer node according to the host node mapping relationship recorded by the CPU thread identifier, call the host preemption suspension time value recorded by the host node for the CPU thread identifier item by item, match the CPU thread identifier, host node and host preemption suspension time value according to the same scheduling record, check whether the host preemption suspension time value is in a continuous timer state. If the host preemption suspension time value is in a continuous timer state, mark the CPU thread identifier as suspended. If the host preemption suspension time value is not in a continuous timer state, mark the CPU thread identifier as not suspended, and obtain the suspension duration status.

[0019] Specifically, the process reads the CPU thread identifier corresponding to each multi-core virtual machine in the cloud platform resource pool. It then queries the virtual machine-to-physical core mapping table in the cloud platform resource management database. This mapping table records the binding relationship between each virtual CPU (vCPU) thread and its currently running physical host CPU core. Based on this mapping relationship, the physical host node carrying each CPU thread identifier is located. After locating the host node, the kernel monitoring interface of the host machine is called. Specifically, this involves accessing the status file corresponding to each thread under the / proc file system (e.g., / proc / [tid] / schedstat) or using the performance monitoring unit (PMU) virtualization interface provided by the hypervisor. The process then retrieves the preemption suspension time value recorded by the host machine for each CPU thread identifier. This value is a monotonically increasing value maintained by the kernel, starting from when the thread is preempted by the scheduler and placed in the waiting queue. The timer then records the acquired CPU thread identifier, its host node identifier, and the current host preemption suspension time value as an atomic information unit in a temporary scheduling record table in memory. The time value is then checked for a continuous increase and non-zero value between two consecutive reads (e.g., 5 milliseconds apart). If the timer value continuously increases, it is determined to be in a continuous timing state, and the CPU thread identifier is marked as "suspended" in the scheduling record table. Conversely, if the timer value remains zero or is reset to zero between two reads, it indicates that the thread has been rescheduled and is not in a continuous timing state; in this case, it is marked as "not suspended." After traversing all configured virtual machines and their CPU threads in the cloud platform resource pool, a suspension duration status list containing all CPU thread identifiers and their corresponding suspension states is finally generated.

[0020] The steps to obtain the affinity-based suspended thread group are as follows: The process involves filtering CPU threads marked as suspended, extracting the timestamp counter value of the suspension duration from the scheduling record corresponding to the CPU thread identifier, calling the host machine preemption suspension time value in the same scheduling record, adding the timestamp counter value to the host machine preemption suspension time value item by item, writing the sum to the corresponding CPU thread identifier's counting record, generating a counter increment value, comparing the counter increment value with the preset time limit item by item, retaining CPU thread identifiers whose counter increment value is greater than the preset time limit value, and removing CPU thread identifiers whose counter increment value is less than or equal to the preset time limit value, thus obtaining the corresponding CPU thread identifiers that exceed the preset time limit value. Based on the CPU thread identifier corresponding to the time limit exceeding the preset limit, each CPU thread identifier is read item by item to its parent multi-core virtual machine. According to the parent multi-core virtual machine of the CPU thread identifier, all CPU thread identifiers belonging to the same multi-core virtual machine are retrieved in the cloud platform resource pool. All CPU thread identifiers belonging to the same multi-core virtual machine are merged according to the multi-core virtual machine. Duplicate CPU thread identifiers registered in the same multi-core virtual machine are deleted. The complete CPU thread identifier sequence in the same multi-core virtual machine is retained. The complete CPU thread identifier sequence is bound to the multi-core virtual machine to which the corresponding CPU thread identifier belongs when the time limit exceeds the preset limit, generating an affinity suspended thread group.

[0021] Specifically, the process of filtering CPU thread identifiers marked as suspended involves iterating through the previously generated list of suspended durations and extracting all entries with the status "suspended." For each CPU thread identifier marked as suspended, the process traces back to the time when the suspension event occurred, i.e., when the thread was first marked as suspended, based on its associated scheduling record index in the list. This is done using the system's high-precision time stamp counter. The TSC (Time Stamp Controller) captures the timestamp counter value and simultaneously calls the host kernel monitoring interface pointed to in the same scheduling record again to obtain the latest host preemption suspension time value. The counter increment value here is this latest obtained host preemption suspension time value, which directly reflects the total suspension time of the thread from the start of preemption to the current moment. Then, this counter increment value is compared with a dynamically calculated preset time limit value. The preset time limit value is set as follows: within the baseline period of normal system operation (e.g., 24 hours), preemption suspension time samples of all CPU threads are collected to form a dataset. The average value μ (e.g., μ=50 microseconds) and standard deviation σ (e.g., σ=15 microseconds) of this dataset are calculated. Then, the preset time limit value is set to μ+3σ, that is, 50+3 * 15 = 95 microseconds is a statistically extreme suspension duration. When the counter increment of a suspended CPU thread is greater than 95 microseconds, the CPU thread identifier is retained because it is considered a potential source of performance jitter. If the counter increment is less than or equal to 95 microseconds, it is judged as normal scheduling latency and removed. After comparing and filtering all suspended threads, a set of CPU thread identifiers containing only those whose suspension time exceeds the preset time limit is obtained.

[0022] Based on the CPU thread identifier corresponding to the time limit exceeding the preset limit, for each CPU thread identifier in the set, a query request is initiated to the metadata service of the cloud platform resource pool to read the detailed attributes of the CPU thread identifier and extract its parent multi-core virtual machine identifier. To avoid duplicate processing of the same virtual machine, a hash set is used to store all the multi-core virtual machine identifiers that have appeared, ensuring that each virtual machine is processed only once. After collecting all affected multi-core virtual machine identifiers, this hash set is traversed again, and for each multi-core virtual machine identifier, a reverse search is performed within the cloud platform resource pool. The goal of this search operation is to find and list all CPU thread identifiers belonging to the same multi-core virtual machine, regardless of whether they have a hanging problem. This operation ensures that the internal information of the virtual machine is obtained. The complete thread context is retrieved, and the search results are merged into a dictionary or hash map structure, with the multi-core virtual machine identifier as the key and a list of all CPU thread identifiers under it as the value. In this process, since the search operation itself is directly obtained from the virtual machine configuration, the uniqueness of the thread identifier is naturally guaranteed, and no additional deduplication operation is required. However, for program robustness, a set-based fast deduplication is performed to retain a complete and unique sequence of CPU thread identifiers within the multi-core virtual machine. Finally, this complete sequence of CPU thread identifiers is bound back to the multi-core virtual machine to which the CPU thread identifier that generated the query (i.e., the one with the initial suspension time exceeding the limit) belongs, forming a thread group, i.e., an affinity suspension thread group, which contains all its sibling threads within the multi-core virtual machine.

[0023] The steps for obtaining the clock drift deviation are as follows: Read the multi-core virtual machine identifier corresponding to each CPU thread identifier in the affinity-suspended thread group. Locate the virtual clock register according to the multi-core virtual machine identifier. Extract the time read value written to the virtual clock register when the CPU thread identifier performs a time read operation. Synchronously read the host system time value of the host node where the CPU thread identifier is located. Establish a one-to-one correspondence between the time read value and the host system time value based on the CPU thread identifier and the same read time. Subtract the host system time value from the time read value, retain the positive and negative directions of the difference. A positive value marks the virtual clock leading state, a negative value marks the virtual clock lagging state, and a zero value marks the virtual clock synchronization state to obtain the clock drift deviation.

[0024] Specifically, the process reads the multi-core virtual machine identifier corresponding to each CPU thread identifier within the affinity suspension thread group. For each identified multi-core virtual machine, its identifier is used to locate a memory region maintained by the Hypervisor for that virtual machine, namely the virtual clock register. This is typically achieved through a specific Hypercall (e.g., HYPERCALL_GET_VM_TIME). Executing this Hypercall atomically triggers an operation: retrieving the time read value recorded by the TSC (timestamp counter) inside the virtual machine (Guest OS) when the CPU thread performs the time read operation. Almost simultaneously, the Hypervisor immediately reads the host system time value recorded by the physical TSC of its host node. This tightly coupled reading method reduces the time delay between the two operations to the nanosecond level, thus ensuring the synchronization of the values. Then, based on the CPU thread identifier and this same read time point, a temporary mapping relationship is established, matching the obtained time read value (from the virtual machine) with the host system time value (from the physical machine) item by item. Next, numerical calculation is performed by subtracting the host system time from the time read value. The difference between the two is calculated using numerical values. This difference represents the amount of drift of the virtual clock relative to the physical clock. The sign of the calculation result is retained to indicate the direction of drift. If the difference is positive, it means that the virtual machine's time is faster than the physical machine's time. In this case, the clock state identified by the CPU thread is marked as virtual clock ahead. If the difference is negative, it means that the virtual machine's time is slower. It is marked as virtual clock lagging. If the difference is within a very small error range (e.g., ±100 nanoseconds), it is considered to be synchronized and marked as virtual clock synchronized. Finally, a set of clock drift deviations is obtained, which contains the specific values ​​and states of clock drift for all threads in each affected virtual machine.

[0025] The steps for obtaining the step-by-step clock compensation variable are as follows: Based on the multi-core virtual machine identifier corresponding to the clock drift deviation, the time message synchronization period parameter in the multi-core virtual machine configuration record is read from the cloud platform management base. The number of CPU thread identifiers belonging to the same multi-core virtual machine in the affinity suspended thread group is counted. The initial division number is set according to the number of CPU thread identifiers. The clock drift deviation is divided equally according to the initial division number. The absolute value of each division result is compared with the time message synchronization period parameter. When the absolute value of the division result exceeds the time message synchronization period parameter, the division number is increased and the division is restarted. When the absolute value of all division results does not exceed the time message synchronization period parameter, the division is stopped. The remaining deviation that cannot be divided is incorporated into the last division result to generate multiple compensation step size values. Based on the multi-core virtual machine identifiers to which multiple compensation step values ​​belong, the CPU thread identifiers belonging to the same multi-core virtual machine within the affinity suspension thread group are retrieved. The allocation order is established according to the arrangement order of the CPU thread identifiers within the affinity suspension thread group. Multiple compensation step values ​​are written into the compensation record of the corresponding CPU thread identifier in the allocation order. When the number of compensation step values ​​is greater than the number of CPU thread identifiers, they are allocated cyclically according to the arrangement order. When the number of compensation step values ​​is less than the number of CPU thread identifiers, the compensation step value corresponding to the unallocated CPU thread identifier is recorded as zero. The compensation step value, compensation direction, time message synchronization period parameter, and allocation order corresponding to each CPU thread identifier are recorded to establish a step-by-step clock compensation variable.

[0026] Specifically, based on the multi-core virtual machine identifier corresponding to the clock drift deviation, for each virtual machine with clock drift, the system first reads the preset time message synchronization period parameter from the configuration record of the configuration record of the virtual machine in the cloud platform management base configuration database. This parameter is usually set by the system administrator according to the network environment and application requirements. For example, for time-sensitive applications, it may be set to 16 seconds (16000 milliseconds), and for ordinary applications, it may be 64 seconds. The system counts the total number of CPU thread identifiers belonging to the same multi-core virtual machine in the affinity suspended thread group, denoted as N. This number N is set as the initial division number of the compensation step size. Then, the absolute value of the total clock drift deviation of the virtual machine calculated above is equally divided according to the initial division number N to calculate the initial size of each step size. Subsequently, an iterative comparison process is entered, checking one by one whether the absolute value of each division result exceeds the time message synchronization period parameter. For example, if the total deviation is 1000 milliseconds, N=4, the initial step size is 250 milliseconds, and the synchronization period is 16000 milliseconds, then 250... <16000, meeting the condition. If the total deviation is 80000 milliseconds, N=4, and the initial step size is 20000 milliseconds, which exceeds 16000 milliseconds, then the number of divisions needs to be increased. The number of divisions N is incremented by 1 (i.e., N=5), and the step size is recalculated (80000 / 5 = 16000 milliseconds). The division is stopped when the absolute value of the step size of all the divisions is not greater than the time message synchronization period parameter. During the division process, if the total deviation cannot be divided evenly by the number of divisions, the remaining deviation, for example, 1003 milliseconds divided into 3 parts, will result in 334, 334, 335. This remainder is added to the last division result. After the division is completed, a set of specific and compliant compensation step size values ​​is finally generated for each virtual machine.

[0027] Based on the multi-core virtual machine identifiers to which multiple compensation step values ​​belong, for each virtual machine, the list of all CPU thread identifiers corresponding to it within the affinity suspension thread group is retrieved. These CPU thread identifiers are then sorted in ascending order according to their thread ID values ​​in the operating system kernel, thus establishing a deterministic allocation order. The multiple compensation step values ​​generated for the virtual machine in the previous step are then allocated item by item to the corresponding CPU thread identifiers according to this allocation order, and the allocation results are written to the compensation record of each CPU thread identifier. There are two scenarios during allocation: First, the number of compensation step values ​​is greater than the number of CPU thread identifiers, for example, there are 10 step values ​​but only 4 CPU threads. In this case, a round-robin allocation strategy is used, i.e., the first step value is allocated to the first thread, the second to the second, ..., the fourth to the fourth, and so on. The compensation step value is then assigned to the first thread, and so on, until all step values ​​are assigned. Second, if the number of compensation step values ​​is less than the number of CPU thread identifiers, for example, there are 3 step values ​​but 5 CPU threads, then according to the allocation order, the first 3 threads each get one step value, while the 4th and 5th CPU threads are assigned zero compensation step values, indicating that they do not directly undertake the compensation task in this step-by-step compensation. After the allocation is completed, a structured record is generated for each CPU thread identifier. This record details the compensation step value assigned to it, the compensation direction (leading or lagging) inherited from the clock drift deviation, the virtual machine's time message synchronization period parameter, and its order number in this allocation. All these records together establish a clearly structured step-by-step clock compensation variable.

[0028] The steps to obtain the execution engine suspension array are as follows: Read the compensation trigger flag, trigger timestamp, allocation order, and multi-core virtual machine identifier corresponding to each CPU thread identifier in the step-by-step clock compensation variable. Filter the CPU thread identifiers whose compensation trigger flags have been changed, arrange them from earliest to latest according to the trigger timestamp, and arrange them from front to back according to the allocation order if the trigger timestamps are the same. Select the CPU thread identifier at the top of the list, locate the interrupt entry address of the corresponding multi-core virtual machine in the operating system kernel interrupt vector table, write the forced interception instruction to the interrupt entry address, lock the interrupt response range corresponding to the forced interception instruction, and obtain the first triggering CPU thread identifier. Call all CPU thread identifiers belonging to the same multi-core virtual machine in the step-by-step clock compensation variable, exclude the first triggering CPU thread identifier, locate the current running address information, instruction offset position, state transition position and activity flag of the remaining CPU thread identifiers in the execution engine state machine, save the recovery order corresponding to the current running address information, modify the activity flag of the remaining CPU thread identifiers to the freeze flag, block the state transition position from switching, arrange the frozen running address information according to the multi-core virtual machine identifier and recovery order, and establish the execution engine suspension array.

[0029] Specifically, the compensation trigger flag, trigger timestamp, allocation order, and multi-core virtual machine identifier corresponding to each CPU thread identifier are read from the step-by-step clock compensation variable. First, all CPU thread identifiers whose compensation trigger flags have been updated to "pending execution" status by external events (such as performance monitoring alarms) are filtered out. These pending threads are then sorted according to their recorded trigger timestamps, with earlier timestamps ranked first. If multiple threads have identical trigger timestamps, they are further sorted according to their allocation order recorded in the step-by-step clock compensation variable, with earlier allocation orders ranked first. This dual sorting mechanism ensures the uniqueness and determinism of the processing order. The CPU thread identifier at the head of the sorted queue is selected, and its multi-core virtual machine identifier is used to locate the CPU thread. The specific location of the interrupt vector table in the operating system kernel memory is found, especially the interrupt entry address dedicated to virtual machine exit (VM-Exit) or hypercall. Then, a predefined forced interception instruction (e.g., a specially designed VMCALL instruction or a software interrupt instruction) is written to this interrupt entry address. The function of this instruction is to force redirection to the hypervisor's control logic when any CPU thread in the virtual machine triggers a specific interrupt. At the same time, the interrupt response range of this forced interception instruction is locked, so that it only takes effect on the target multi-core virtual machine, thereby avoiding affecting the normal operation of other unrelated virtual machines. After completing this series of operations, the selected CPU thread identifier used to set the interception is determined as the first triggering CPU thread identifier.

[0030] The process involves calling all CPU thread identifiers belonging to the same multi-core virtual machine from the step-by-step clock compensation variable, excluding the first triggering CPU thread identifier determined in the previous step from this list. For each remaining CPU thread identifier in the list, the detailed runtime information in the virtual machine execution engine (usually the vCPU context) state machine is located item by item through the Hypervisor's debugging interface or memory introspection technology. This includes the memory address of the currently executing instruction (i.e., the program counter PC value), the instruction offset relative to the current function or code block, the current value of the stack pointer or state machine variable used for state transitions, and a flag indicating its active state. After locating this information, the process first involves... A complete snapshot of the execution context, including information and instruction offsets, is saved to a memory area, and their original restoration order is recorded (e.g., according to the CPU thread ID order). Then, the activity flag of these CPU threads in the vCPU status descriptor is modified, forcibly changing it from "running" or "runnable" to "frozen". This operation immediately blocks the scheduling and execution of the vCPU, pausing its state transition at the current position and preventing it from switching to the next state. Finally, snapshots of the running address information of all frozen CPU threads are grouped according to their respective multi-core virtual machine identifiers and arranged within each group according to the previously recorded restoration order, forming a structured data array. This array is the execution engine suspension array.

[0031] The steps to obtain the globally consistent compensation vector are as follows: Based on the execution engine's suspended array, the corresponding multi-core virtual machine control block is located according to its multi-core virtual machine identifier. The compensation step size, compensation direction, and allocation order corresponding to each CPU thread identifier in the step-by-step clock compensation variable are read. The CPU thread identifier is bound to the clock offset field in the multi-core virtual machine control block item by item. All compensation step sizes are loaded into the corresponding clock offset field's write position according to the allocation order. The number of CPU thread identifiers, the number of compensation step sizes, and the number of clock offset fields are checked to see if they are consistent. If they are consistent, the same write trigger flag is sent to all write positions. If they are inconsistent, the writing is stopped and the binding relationship is re-checked. After confirming that all clock offset fields have been written, a globally consistent compensation vector is established.

[0032] Specifically, based on the execution engine's suspension array, the system first locates the core data structure managed by the Hypervisor for that virtual machine, which stores its runtime state and configuration, namely the Multi-Core Virtual Machine Control Block (VMCS or equivalent structure), according to the multi-core virtual machine identifier recorded in the array. Then, it reads the compensation step size, compensation direction, and allocation order corresponding to all suspended CPU threads within that virtual machine from the step-by-step clock compensation variable. Next, it binds the CPU thread identifiers in the execution engine's suspension array to the clock offset field specifically used for clock control within the Multi-Core Virtual Machine Control Block. This binding process essentially establishes a mapping from the CPU thread ID to its corresponding memory address in the clock control region of the VMCS. After binding, based on the allocation order recorded in the step-by-step clock compensation variable, all the step size values ​​to be compensated are adjusted according to their compensation direction (positive values ​​represent increasing time, negative values ​​represent decreasing time). Before the actual write operation, a strict verification is performed on the buffer position to be loaded into the clock offset field bound to the corresponding CPU thread. This verification checks whether the number of CPU thread identifiers, the number of compensation step values ​​to be written, and the number of bound clock offset fields are completely consistent. For example, if there are 8 threads, there must be 8 compensation step values ​​(some can be 0) and 8 successfully bound fields. When the numbers are confirmed to be consistent, the same write trigger flag is sent to all positions to be written through an atomic Hypercall. This trigger will cause the Hypervisor to synchronously apply all compensation values ​​in the buffer to their respective clock offset fields. If the numbers are inconsistent, the write operation is stopped immediately, the binding relationship is rolled back, and the verification is performed again until they are consistent. After confirming that the Hypervisor returns a signal that all clock offset fields have been successfully updated, a globally consistent compensation vector is established.

[0033] The steps for obtaining the collaborative verification clock alignment cluster are as follows: Read the multi-core virtual machine identifier corresponding to each CPU thread identifier in the globally consistent compensation vector, locate the multi-core virtual machine control block according to the multi-core virtual machine identifier, read the clock offset completion status corresponding to each CPU thread identifier in the multi-core virtual machine control block item by item, check whether the clock offset completion status has been written with the updated mark, register the CPU thread identifiers that have been written with the updated mark to the completion sequence, register the CPU thread identifiers that have not been written with the updated mark to the pending confirmation sequence, and repeatedly read the clock offset completion status corresponding to the pending confirmation sequence according to the arrangement order of the CPU thread identifiers in the globally consistent compensation vector until the pending confirmation sequence is empty, confirm that all clock offset completion statuses have been changed to the updated mark, and obtain the clock offset completion confirmation result; Based on the clock offset confirmation result, unfreeze instructions are generated according to the multi-core virtual machine identifier, CPU thread identifier and recovery order recorded in the execution engine suspension array. The unfreeze instructions are written into the underlying scheduling queue of the cloud platform. The running address information corresponding to all CPU thread identifiers in the execution engine suspension array is located item by item according to the recovery order. It is checked whether the current mark of the running address information is a frozen mark. The frozen mark is changed to an active mark state. The instruction offset position and state transition position corresponding to the running address information are restored. The running address information corresponding to all CPU thread identifiers is verified to have been restored to the active mark state. The execution engine recovery state is generated. Based on the execution engine recovery status, read the runtime parameter values ​​corresponding to all CPU thread identifiers one by one. Group the runtime parameter values ​​belonging to the same multi-core virtual machine according to the multi-core virtual machine identifier. Extract the cycle start position, cycle duration, and cycle boundary position from each group of runtime parameter values. Select the latest cycle start position in the same group as the unified start position. Adjust the cycle boundary position corresponding to each CPU thread identifier according to the unified start position. Delay the runtimes earlier than the unified start position to the unified start position. Retain the runtimes exceeding the unified start position to the next cycle boundary. Repeatedly verify whether the cycle start positions of all CPU thread identifiers in the same group are consistent. Confirm that all CPU thread identifiers have completed the cycle alignment operation and generate a collaborative verification clock alignment cluster.

[0034] Specifically, the process reads the multi-core virtual machine identifier corresponding to each CPU thread identifier within the globally consistent compensation vector. Based on the virtual machine identifier, it locates the corresponding multi-core virtual machine control block (VMCS). Then, a polling check mechanism is initiated, sequentially reading the clock offset completion status field set for each CPU thread identifier within that control block. After the Hypervisor completes the actual application of the clock compensation value, this field is modified by the Hypervisor itself from an "updating" state to an "updated" flag (e.g., setting the flag of a memory location from 0 to 1). The specific checking process is as follows: CPU thread identifiers that have detected an "updated" flag are registered in a temporary completion sequence list, while those that have not yet detected an "updated" flag are... The marked CPU thread identifiers are registered in another list of pending confirmation sequences. Then, according to the preset CPU thread arrangement order within the globally consistent compensation vector, the clock offset completion status of the threads in the pending confirmation sequence list is repeatedly and cyclically read at a fixed time interval (e.g., 100 microseconds). After each read, the threads that have newly changed to the "updated" status are moved from the pending confirmation sequence to the completion sequence. This process continues until all entries in the pending confirmation sequence are removed, i.e., the list is empty. This indicates that the clock compensation operation of all CPU threads in the virtual machine has been completed at the Hypervisor level. At this point, the entire polling and checking process ends, generating a confirmatory result signal, i.e., the clock offset completion confirmation result.

[0035] Based on the confirmation result after clock offset, and immediately using the multi-core virtual machine identifiers, CPU thread identifiers, and saved recovery order recorded in the previously constructed execution engine suspension array, a set of unfreeze instructions is dynamically generated for all suspended threads within the virtual machine. This set of instructions is essentially a specific Hypercall request encapsulating a list of target virtual machine IDs and target CPU thread IDs. This unfreeze instruction is then written into the command queue monitored by the Hypervisor scheduler at the cloud platform's underlying layer. Upon receiving the instruction, the scheduler, according to the instruction content and the recovery order recorded in the execution engine suspension array, locates the vCPU context snapshot corresponding to each frozen CPU thread identifier in the array, i.e., its runtime address. Before restoration, a status check is performed to confirm that the current flag of the running address information is indeed "frozen". If the confirmation is correct, the flag is changed back to "active". At the same time, the complete execution context information, such as instruction offsets and state transition positions (e.g., stack pointers) saved in the snapshot, is written back to the corresponding vCPU registers and state structures all at once. This process is executed sequentially for all suspended threads in the virtual machine. After all are completed, a final verification is performed to check whether the vCPU state corresponding to all CPU thread identifiers has been restored to the "active" flag state. After confirming that all threads have successfully resumed execution, an execution engine restoration status report is generated, marking that all relevant vCPUs have resumed operation.

[0036] After confirming that all relevant CPU threads have resumed activity based on the execution engine recovery status, the runtime parameter values ​​defined in the cloud platform metadata for these CPU threads are read item by item. This parameter is a structure containing three timestamps or counters: the cycle start position, the cycle duration, and the cycle boundary position. These runtime parameter values ​​are then merged according to the multi-core virtual machine identifier, grouping thread parameters belonging to the same multi-core virtual machine into groups. For each group, the cycle start position values ​​of all threads within the group are extracted, and the latest value is selected as the unified start position for the group. Then, a cycle alignment operation is performed on all threads within the group based on this unified start position: for threads whose cycle start position is earlier than the unified start position, their entire runtime is delayed, the new cycle start position is set as the unified start position, and their cycle boundary positions are adjusted accordingly to "unified start position + ... "Original cycle duration" For threads whose execution cycles were originally planned to start after the unified start position, their original arrangement is retained, but their execution priority is placed in the next scheduling cycle to wait for the completion of the current alignment cycle. After adjusting the cycle parameters of all threads in the group, a repeat check is performed to check again whether the cycle start position of all CPU threads in the group has been precisely unified to the selected latest start position. When it is confirmed that the cycle start positions of all threads in the group are completely consistent, the group of threads has completed the cycle alignment operation. All virtual machine thread groups that have completed the alignment operation are gathered together to generate the final cooperative verification clock alignment cluster.

Claims

1. A cloud-based, autonomous, controllable, adaptable, and verification laboratory management system, characterized in that: The system includes: The cloud platform resource monitoring module obtains the suspension duration status on the host node based on the CPU thread identifier of the multi-core virtual machine in the cloud platform resource pool and the host machine preemption suspension time value. It generates a counter increment value based on the corresponding timestamp counter value and the host machine preemption suspension time value under the suspension duration status. It extracts the CPU thread identifier corresponding to the time limit exceeding the preset time limit and gathers all CPU thread identifiers belonging to the same multi-core virtual machine to generate an affinity suspension thread group. The clock skew compensation module obtains the clock drift deviation based on the time reading value of the CPU thread identifier in the virtual clock register within the affinity suspended thread group and the host system time value. Based on the time message synchronization cycle parameter under the multi-core virtual machine in the cloud platform management base, the clock drift deviation is divided into multiple compensation step values, and the multiple compensation step values ​​are assigned to the corresponding CPU thread identifier to establish step-by-step clock compensation variables. The interrupt barrier control module extracts the first triggering CPU thread identifier from the step-by-step clock compensation variables, writes a forced interception instruction to the operating system kernel interrupt vector table, freezes the running address information of all CPU thread identifiers except the first triggering CPU thread identifier in the execution engine state machine, establishes an execution engine suspension array, and writes all compensation step size values ​​into the clock offset field in the corresponding multi-core virtual machine control block of the execution engine suspension array to establish a globally consistent compensation vector.

2. The cloud-based autonomous and controllable adaptive verification laboratory management system according to claim 1, characterized in that, The system also includes: The collaborative wake-up scheduling module extracts the clock offset completion status of all CPU thread identifiers within the globally consistent compensation vector in the multi-core virtual machine control block. When the clock offset completion status changes to the updated mark, it sends the unfreezing instruction assigned to the execution engine suspension array to the underlying scheduling queue of the cloud platform. This restores the running address information under all CPU thread identifiers in the execution engine suspension array to the active mark state. Based on the running cycle parameter values ​​under all CPU thread identifiers, it performs cycle alignment operations to generate a collaborative verification clock alignment cluster.

3. The cloud-based autonomous and controllable adaptive verification laboratory management system according to claim 1, characterized in that, The steps for obtaining the suspension duration status are as follows: Read the CPU thread identifier corresponding to each multi-core virtual machine in the cloud platform resource pool, locate the bearer node according to the host node mapping relationship recorded by the CPU thread identifier, call the host preemption suspension time value recorded by the host node for the CPU thread identifier item by item, match the CPU thread identifier, host node and host preemption suspension time value according to the same scheduling record, check whether the host preemption suspension time value is in a continuous timer state. If the host preemption suspension time value is in a continuous timer state, mark the CPU thread identifier as suspended. If the host preemption suspension time value is not in a continuous timer state, mark the CPU thread identifier as not suspended, and obtain the suspension duration status.

4. The cloud-based autonomous and controllable adaptive verification laboratory management system according to claim 1, characterized in that, The steps for obtaining the affinity-based suspended thread group are as follows: The process involves filtering CPU thread identifiers marked as suspended, extracting the timestamp counter value of the time when the suspension duration occurred according to the scheduling record corresponding to the CPU thread identifier, calling the host machine preemption suspension time value in the same scheduling record, adding the timestamp counter value to the host machine preemption suspension time value item by item, writing the sum to the counting record of the corresponding CPU thread identifier, generating a counter increment value, comparing the counter increment value with a preset time limit item by item, retaining CPU thread identifiers whose counter increment value is greater than the preset time limit value, and removing CPU thread identifiers whose counter increment value is less than or equal to the preset time limit value, thus obtaining the corresponding CPU thread identifiers that exceed the preset time limit value. Based on the CPU thread identifier corresponding to the time limit exceeding the preset limit, each CPU thread identifier is read item by item to its corresponding multi-core virtual machine. According to the multi-core virtual machine to which the CPU thread identifier belongs, all CPU thread identifiers belonging to the same multi-core virtual machine are retrieved in the cloud platform resource pool. All CPU thread identifiers belonging to the same multi-core virtual machine are merged according to the multi-core virtual machine. Duplicate CPU thread identifiers registered in the same multi-core virtual machine are deleted. The complete CPU thread identifier sequence in the same multi-core virtual machine is retained. The complete CPU thread identifier sequence is bound to the multi-core virtual machine to which the CPU thread identifier corresponding to the time limit exceeding the preset limit belongs, generating an affinity suspended thread group.

5. The cloud-based autonomous and controllable adaptive verification laboratory management system according to claim 1, characterized in that, The steps for obtaining the clock drift deviation are as follows: Read the multi-core virtual machine identifier corresponding to each CPU thread identifier in the affinity suspended thread group, locate the virtual clock register according to the multi-core virtual machine identifier, extract the time read value written to the virtual clock register when the CPU thread identifier performs the time read operation, synchronously read the host system time value of the host node where the CPU thread identifier is located, establish a one-to-one correspondence between the time read value and the host system time value based on the CPU thread identifier and the same read time, subtract the host system time value from the time read value, retain the positive and negative directions of the difference, positive value marks the virtual clock advanced state, negative value marks the virtual clock lagging state, and zero value marks the virtual clock synchronized state to obtain the clock drift deviation.

6. The cloud-based autonomous and controllable adaptive verification laboratory management system according to claim 1, characterized in that, The steps for obtaining the step-by-step clock compensation variable are as follows: According to the multi-core virtual machine identifier corresponding to the clock drift deviation, the time message synchronization period parameter in the multi-core virtual machine configuration record is read from the cloud platform management base. The number of CPU thread identifiers belonging to the same multi-core virtual machine in the affinity suspended thread group is counted. The initial division number is set according to the number of CPU thread identifiers. The clock drift deviation is divided equally according to the initial division number. The absolute value of each division result is compared with the time message synchronization period parameter. When the absolute value of the division result exceeds the time message synchronization period parameter, the division number is increased and the division is restarted. When the absolute value of all division results does not exceed the time message synchronization period parameter, the division is stopped. The remaining deviation that cannot be divided is incorporated into the last division result to generate multiple compensation step size values. According to the multi-core virtual machine identifier to which the multiple compensation step values ​​belong, the CPU thread identifiers belonging to the same multi-core virtual machine in the affinity suspending thread group are retrieved. An allocation order is established based on the arrangement order of the CPU thread identifiers in the affinity suspending thread group. The multiple compensation step values ​​are written into the compensation record of the corresponding CPU thread identifier one by one according to the allocation order. When the number of compensation step values ​​is greater than the number of CPU thread identifiers, they are allocated cyclically according to the arrangement order. When the number of compensation step values ​​is less than the number of CPU thread identifiers, the compensation step value corresponding to the unallocated CPU thread identifier is recorded as zero. The compensation step value, compensation direction, time message synchronization period parameter and allocation order corresponding to each CPU thread identifier are recorded to establish a step-by-step clock compensation variable.

7. The cloud-based autonomous and controllable adaptive verification laboratory management system according to claim 1, characterized in that, The steps for obtaining the execution engine suspension array are as follows: Read the compensation trigger flag, trigger timestamp, allocation order, and multi-core virtual machine identifier corresponding to each CPU thread identifier in the step-by-step clock compensation variable. Filter the CPU thread identifiers whose compensation trigger flags have been changed, arrange them from earliest to latest according to the trigger timestamp, and arrange them from front to back according to the allocation order if the trigger timestamps are the same. Select the CPU thread identifier that is first in the order, locate the interrupt entry address of the corresponding multi-core virtual machine in the operating system kernel interrupt vector table, write the forced interception instruction to the interrupt entry address, lock the interrupt response range corresponding to the forced interception instruction, and obtain the first triggering CPU thread identifier. The system calls all CPU thread identifiers belonging to the same multi-core virtual machine from the step-by-step clock compensation variable, excludes the first triggering CPU thread identifier, locates the current running address information, instruction offset position, state transition position and activity flag of the remaining CPU thread identifiers in the execution engine state machine, saves the recovery order corresponding to the current running address information, modifies the activity flag of the remaining CPU thread identifiers to a freeze flag, blocks the state transition position from switching, arranges the frozen running address information according to the multi-core virtual machine identifier and recovery order, and establishes the execution engine suspension array.

8. The cloud-based autonomous and controllable adaptive verification laboratory management system according to claim 1, characterized in that, The steps for obtaining the globally consistent compensation vector are as follows: Based on the execution engine suspension array, the corresponding multi-core virtual machine control block is located according to the multi-core virtual machine identifier. The compensation step size, compensation direction, and allocation order corresponding to each CPU thread identifier in the step-by-step clock compensation variable are read. The CPU thread identifier is bound to the clock offset field in the multi-core virtual machine control block item by item. All compensation step size values ​​are loaded into the write position of the corresponding clock offset field according to the allocation order. The number of CPU thread identifiers, the number of compensation step size values, and the number of clock offset fields are checked to see if they are consistent. If they are consistent, the same write trigger flag is sent to all write positions. If they are inconsistent, the writing is stopped and the binding relationship is re-checked. After confirming that all clock offset fields have been written, a globally consistent compensation vector is established.

9. The cloud-based autonomous and controllable adaptive verification laboratory management system according to claim 2, characterized in that, The steps for obtaining the collaborative verification clock alignment cluster are as follows: Read the multi-core virtual machine identifier corresponding to each CPU thread identifier in the global consistent compensation vector, locate the multi-core virtual machine control block according to the multi-core virtual machine identifier, read the clock offset completion status corresponding to each CPU thread identifier in the multi-core virtual machine control block item by item, check whether the clock offset completion status has been written with the updated mark, register the CPU thread identifiers that have been written with the updated mark to the completion sequence, register the CPU thread identifiers that have not been written with the updated mark to the confirmation sequence, and repeatedly read the clock offset completion status corresponding to the confirmation sequence according to the arrangement order of the CPU thread identifiers in the global consistent compensation vector until the confirmation sequence is empty, confirm that all the clock offset completion statuses have been changed to the updated mark, and obtain the clock offset completion confirmation result; Based on the clock offset confirmation result, unfreeze instructions are generated according to the multi-core virtual machine identifier, CPU thread identifier and recovery order recorded in the execution engine suspension array. The unfreeze instructions are written into the underlying scheduling queue of the cloud platform. The running address information corresponding to all CPU thread identifiers in the execution engine suspension array is located item by item according to the recovery order. It is checked whether the current mark of the running address information is a frozen mark. The frozen mark is changed to an active mark state. The instruction offset position and state transition position corresponding to the running address information are restored. The running address information corresponding to all CPU thread identifiers is verified item by item to be restored to the active mark state. The execution engine recovery state is generated. Based on the execution engine recovery status, the runtime parameter values ​​corresponding to all CPU thread identifiers are read item by item. The runtime parameter values ​​belonging to the same multi-core virtual machine are grouped according to the multi-core virtual machine identifier. The cycle start position, cycle duration, and cycle boundary position of each group of runtime parameter values ​​are extracted. The latest cycle start position in the same group is selected as the unified start position. The cycle boundary position corresponding to each CPU thread identifier is adjusted according to the unified start position. Runtimes earlier than the unified start position are postponed to the unified start position. Runtimes exceeding the unified start position are retained to the next cycle boundary. The cycle start positions of all CPU thread identifiers in the same group are repeatedly verified to ensure that all CPU thread identifiers have completed the cycle alignment operation, and a collaborative verification clock alignment cluster is generated.

Images