Cluster distributed virtual interrupt control method, device and system

Abstract

The present disclosure relates to a cluster distributed virtual interrupt control method, device and system. The method comprises: in the case that a first distributed virtual interrupt controller (DVIC) node receives a virtual interrupt request, determining interrupt target routing information corresponding to the virtual interrupt; the first DVIC node constructs a cross-chip hardware-level direct injection message according to the interrupt target routing information; the first DVIC node sends the hardware-level direct injection message to a second DVIC node through an inter-chip interconnection, and the hardware-level direct injection message is directly written into an incoming message signal interrupt controller (IMSIC) interrupt file by the second DVIC node through hardware logic. The present disclosure can significantly reduce the cross-chip virtual interrupt delivery delay and improve system determinacy.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to interrupt control technology in virtual environments, especially to clustered distributed virtual interrupt control methods, devices and systems. Background Technology

[0002] Virtualization technology, by abstracting physical resources, allows multiple isolated virtual machines (VMs) to run on a single physical host, and has become the cornerstone of modern data center and cloud computing infrastructure. In a virtualized environment, interrupt control mechanisms are used to handle communication between hardware devices and the central processing unit (CPU), and are a key component in ensuring system input / output (I / O) performance and real-time responsiveness.

[0003] In related technologies, when delivering virtual interrupts across different physical chips or NUMA (Non-Uniform Memory Access) nodes, the main reliance is on Hypervisor software trap forwarding or indirect delivery mechanisms based on memory writes. However, this approach results in end-to-end interrupt latency typically as high as 8–50 μs or even higher, severely degrading the performance of guest operating systems (such as RT-Linux and functional safety OS) and cloud-native high-density container workloads that have strict requirements for interrupt determinism and real-time performance. Furthermore, the current RISC-V Advanced Interrupt Architecture (APLIC + IMSIC) only defines a direct guest injection mechanism within the chip. The Hypervisor needs to additionally rely on high-overhead doorbell register writes, IPI (Inter-Processor Interrupt) software interrupts, or periodic polling of the target core to wake up the target virtual CPU (vCPU), which significantly increases CPU load, power consumption, and further amplifies latency jitter. Summary of the Invention

[0004] This disclosure provides a cluster-distributed virtual interrupt control method, apparatus, and system, which can solve problems such as high latency and low determinism in cross-chip virtual interrupt delivery.

[0005] In a first aspect, embodiments of this disclosure provide a clustered distributed virtual interrupt control method, the method being applied to a first distributed virtual interrupt controller (DVIC) node, the method comprising:

[0006] Upon receiving a virtual interrupt request, determine the interrupt target routing information corresponding to the virtual interrupt;

[0007] Based on the interrupt target routing information, construct a cross-chip hardware-level direct injection message;

[0008] The hardware-level direct injection message is sent to the second DVIC node through inter-chip interconnect. The hardware-level direct injection message is then written directly into the incoming message signal interrupt controller IMSIC interrupt file by the second DVIC node through hardware logic.

[0009] Secondly, embodiments of this disclosure provide a clustered distributed virtual interrupt control method, the method being applied to a second distributed virtual interrupt controller (DVIC) node, the method comprising:

[0010] The first DVIC node receives a hardware-level direct injection message sent through the inter-chip interconnect. The hardware-level direct injection message is constructed by the first DVIC node based on the interrupt target routing information corresponding to the global virtual interrupt identity. The global virtual interrupt identity is the global virtual interrupt identity within the cluster where the first DVIC node maps the interrupt source associated with the virtual interrupt request to the global virtual interrupt identity within the cluster.

[0011] The hardware-level direct injection message uses hardware logic to directly write virtual interrupts into the incoming message signal interrupt controller IMSIC interrupt file.

[0012] Thirdly, embodiments of this disclosure provide a clustered distributed virtual interrupt control device, the device being configured on a first distributed virtual interrupt controller (DVIC) node, the device comprising:

[0013] The routing determination module is used to determine the interrupt target routing information corresponding to the virtual interrupt upon receiving a virtual interrupt request.

[0014] The message construction module is used to construct a cross-chip hardware-level direct injection message based on the interrupt target routing information;

[0015] The message sending module is used to send the hardware-level directly injected message to the second DVIC node through inter-chip interconnection. The hardware-level directly injected message is written directly into the incoming message signal interrupt controller IMSIC interrupt file by the second DVIC node through hardware logic.

[0016] Fourthly, embodiments of this disclosure provide a clustered distributed virtual interrupt control device, the device being configured on a second distributed virtual interrupt controller (DVIC) node, the device comprising:

[0017] The message receiving module is used to receive hardware-level direct injection messages sent by the first DVIC node through inter-chip interconnection. The hardware-level direct injection messages are constructed by the first DVIC node based on the interrupt target routing information corresponding to the global virtual interrupt identity. The global virtual interrupt identity is the global virtual interrupt identity within the cluster range that the first DVIC node maps the interrupt source associated with the virtual interrupt request to.

[0018] The interrupt writing module is used to write the virtual interrupt directly into the incoming message signal interrupt controller IMSIC interrupt file through hardware logic using the hardware-level directly injected message.

[0019] Fifthly, embodiments of this disclosure provide a clustered distributed virtual interrupt control system, comprising multiple distributed virtual interrupt controller (DVIC) nodes, wherein the multiple DVIC nodes include at least a first DVIC node and a second DVIC node;

[0020] The first DVIC node is configured to perform the method described in the first aspect above, and the second DVIC node is configured to perform the method described in the second aspect above.

[0021] Sixthly, embodiments of this disclosure provide an electronic device, including:

[0022] One or more processors;

[0023] The electronic device is used to perform the methods described in the first and second aspects above.

[0024] In a seventh aspect, embodiments of this disclosure provide a storage medium storing instructions that, when executed on an electronic device, cause the electronic device to perform the methods described in the first and second aspects described above.

[0025] Eighthly, embodiments of this disclosure provide a program product including at least one of a program and instructions, wherein when the program and instructions are executed by an electronic device, they implement the steps of the methods described in the first and second aspects.

[0026] According to the technical solution disclosed herein, when the first DVIC node receives a virtual interrupt request, it can determine the interrupt target routing information corresponding to the virtual interrupt. Based on this interrupt target routing information and the hardware-accelerated direct injection protocol (DIP), a hardware-level direct injection message (i.e., a DVIC-specific message) is constructed across chips. This message is then directly sent to the second DVIC node via inter-chip interconnection to complete the injection of the virtual interrupt. In other words, by employing the hardware-accelerated direct injection protocol (DIP) and the DVIC-specific message, the high-overhead Hypervisor software stack and doorbell mechanism can be bypassed, significantly reducing the end-to-end latency of cross-chip virtual interrupt delivery. This greatly improves the real-time performance and determinism of the virtualization cluster, enabling the RISC-V platform to meet the needs of critical applications such as automotive functional safety OS (operating system), high-frequency trading, and latency-sensitive NFV (Network Functions Virtualization). Furthermore, by bypassing the doorbell mechanism, cache coherence storms and power spikes caused by the doorbell mechanism can be eliminated, thereby improving CPU resource utilization and power efficiency.

[0027] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0028] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0029] Figure 1 This is an architecture diagram of a clustered distributed virtual interruption control system according to an exemplary embodiment.

[0030] Figure 2 This is a flowchart illustrating a cluster-distributed virtual interruption control method according to an exemplary embodiment.

[0031] Figure 3 This is a flowchart illustrating a method for constructing a mapping relationship between a global virtual interrupt identity, a DVIC node's node identifier, and an IMSIC interrupt file entry, according to an exemplary embodiment.

[0032] Figure 4 This is a flowchart illustrating a cluster-distributed virtual interruption control method according to an exemplary embodiment.

[0033] Figure 5 This is a flowchart illustrating a cluster-distributed virtual interruption control method according to an exemplary embodiment.

[0034] Figure 6 This is a cluster-distributed virtual interruption control method illustrated according to an exemplary embodiment.

[0035] Figure 7 This is a cluster-distributed virtual interruption control method illustrated according to an exemplary embodiment.

[0036] Figure 8 This is a block diagram illustrating a clustered distributed virtual interrupt control device according to an exemplary embodiment.

[0037] Figure 9 This is a block diagram illustrating a clustered distributed virtual interrupt control device according to an exemplary embodiment.

[0038] Figure 10 This is a block diagram of an electronic device according to an exemplary embodiment. Detailed Implementation

[0039] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0040] This disclosure is not exhaustive, but merely illustrative of some embodiments, and is not intended to limit the scope of protection of this disclosure. Unless otherwise specified, each step in a particular embodiment can be implemented as an independent embodiment, and the steps can be arbitrarily combined. For example, a solution after removing some steps in a particular embodiment can also be implemented as an independent embodiment, and the order of the steps in a particular embodiment can be arbitrarily interchanged. Furthermore, the optional implementation methods in a particular embodiment can be arbitrarily combined; moreover, the embodiments can be arbitrarily combined, for example, some or all steps of different embodiments can be arbitrarily combined, and a particular embodiment can be arbitrarily combined with the optional implementation methods of other embodiments. In all embodiments of this disclosure, unless otherwise specified or logically conflicting, the terminology and / or descriptions between the embodiments are consistent and can be mutually referenced. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.

[0041] The terminology used in the embodiments of this disclosure is for the purpose of describing particular embodiments only and is not intended to limit the scope of this disclosure.

[0042] In some embodiments, terms such as “in response to…”, “in response to determining…”, “in the case of…”, “when…”, “when…”, “if…”, etc. can be used interchangeably. These descriptions all refer to the device making a corresponding action under certain objective circumstances. They do not necessarily limit the time, nor do they require the device to make a judgment action when implementing it, nor do they mean that there must be other limitations.

[0043] The prefixes "first," "second," etc., used in the embodiments of this disclosure are merely for distinguishing different descriptive objects and do not impose restrictions on the position, order, priority, quantity, or content of the descriptive objects. The description of the descriptive objects is found in the claims or the context of the embodiments, and the use of prefixes should not constitute unnecessary restrictions. For example, if the descriptive object is a "field," the ordinal numbers preceding "field" in "first field" and "second field" do not restrict the position or order of the "fields." "First" and "second" do not restrict whether the "fields" they modify are in the same message, nor do they restrict the order of "first field" and "second field." Similarly, if the descriptive object is a "level," the ordinal numbers preceding "level" in "first level" and "second level" do not restrict the priority between "levels." Furthermore, the number of descriptive objects is not limited by ordinal numbers and can be one or more. For example, in "first device," the number of "devices" can be one or more. Furthermore, the objects modified by different prefixes can be the same or different. For example, if the object being described is "device", then "first device" and "second device" can be the same device or different devices, and their types can be the same or different. Similarly, if the object being described is "information", then "first information" and "second information" can be the same information or different information, and their content can be the same or different.

[0044] It should be noted that the collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0045] It should also be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in this disclosure are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0046] In related technologies, when delivering virtual interrupts across different physical chips or NUMA (Non-Uniform Memory Access) nodes, the main reliance is on Hypervisor software trap forwarding or indirect delivery mechanisms based on memory writes. However, this approach results in end-to-end interrupt latency typically as high as 8–50 μs or even higher, severely degrading the performance of guest operating systems (such as RT-Linux and functional safety OS) and cloud-native high-density container workloads that have strict requirements for interrupt determinism and real-time performance. Furthermore, the current RISC-V Advanced Interrupt Architecture (APLIC + IMSIC) only defines a direct guest injection mechanism within the chip. The Hypervisor needs to additionally rely on high-overhead doorbell register writes, IPI (Inter-Processor Interrupt) software interrupts, or periodic polling of the target core to wake up the target virtual CPU (vCPU), which significantly increases CPU load, power consumption, and further amplifies latency jitter.

[0047] Based on this, this disclosure provides a clustered distributed virtual interrupt control method, apparatus, system, and electronic device, which can solve the problems of high latency and low determinism in cross-chip virtual interrupt delivery. The clustered distributed virtual interrupt control method, apparatus, system, and electronic device of this disclosure are described below with reference to the accompanying drawings.

[0048] Figure 1 This is an architecture diagram of a clustered distributed virtual interrupt control system according to an exemplary embodiment. The clustered distributed virtual interrupt control system may include multiple DVIC (Distributed Virtual Interrupt Controller) nodes. These multiple DVIC nodes may include a first DVIC node and a second DVIC node. Figure 1 The number and shape of nodes shown are for illustrative purposes only and do not constitute a limitation on the embodiments of this disclosure. In actual applications, there may be two or more first DVIC nodes and two or more second nodes. Figure 1 The cluster-distributed virtual interrupt control system 100 shown is exemplified by including a first DVIC node 101 and a second DVIC node 102.

[0049] In some embodiments, the first DVIC node 101 and the second DVIC node 102 can be distributed virtual interrupt controllers built in a multi-chip, multi-cluster, or chiplet interconnect architecture, respectively. These controllers enable low-latency delivery of cross-chip virtual interrupts, scalable management of large-scale cluster interrupt resources, and maintenance of interrupt state consistency during vCPU dynamic migration. The clustered distributed virtual interrupt control scheme disclosed herein can consist of a DVIC node structure, a local IMSIC collaboration mechanism, a Global Virtual Interrupt Identity (GVII) system, a hierarchical resource allocation mechanism, a hardware-accelerated direct injection protocol (DIP) across chips, an atomic state transfer for pended interrupts (ASTP) mechanism, and a Hypervisor-DVIC runtime management interface (HV-DVIC API).

[0050] Optionally, the virtual interrupt control system may further include an Incoming Message Signal Interrupt Controller (IMSIC). Optionally, the virtual interrupt control system may further include an inter-chip interconnect network, with DVIC nodes distributed across different physical locations on multiple chips, multiple clusters, or chiplet SoCs, forming a unified distributed virtual interrupt domain. In some embodiments, a DVIC node is integrated into each physical die or chiplet, which can be used for local virtual interrupt file management, interrupt priority determination, and coordinated scheduling of local IMSICs. Multiple DVIC nodes can form a unified distributed virtual interrupt forwarding plane through high-speed inter-chip interconnects (such as UCIe / BoW / CXL.mem) or board-level high-speed interconnects to support fast routing and delivery of cross-chip virtual interrupts.

[0051] Optionally, to overcome the limitations of static and difficult-to-expand IMSIC resources, in some embodiments, this disclosure may define a Global Virtual Interrupt Identity (GVII) and achieve dynamic mapping between the global and local spaces through a hierarchical resource allocation mechanism, enabling linear expansion of the number of interrupt sources and virtual machines in a large-scale cluster. The GVII layer can be responsible for global naming and isolation, while the DVIC node can be responsible for interrupt context, target vCPU selection, and priority arbitration, thereby breaking the problem of limited interrupt file quantity in traditional methods.

[0052] Optionally, to address the high latency issue in cross-chip delivery, in some embodiments, this disclosure proposes a hardware-level direct cross-chip injection protocol (DIP). This protocol uses a 64-byte uniformly formatted hardware interrupt direct delivery message (e.g., this message may include a 64-bit GVII, an 8-bit priority, a 32-bit timestamp, and a payload) to deliver point-to-point between the source DVIC node (such as the first DVIC node 101 in this document) and the target DVIC node (such as the second DVIC node 102 in this document). The target IMSIC interrupt file is directly written at the receiving end, enabling guest-level fast injection that bypasses the hypervisor. This mechanism can reduce the end-to-end latency of cross-chip virtual interrupts to sub-microsecond levels.

[0053] Optionally, in some embodiments, during the vCPU dynamic migration process, this disclosure provides an atomic transfer mechanism for virtual interrupt states (ASTP). When the migration is triggered, the DVIC node can freeze the interrupt state of the corresponding GVII (e.g., it may include pending, enabled, priority, etc.) and ensure state consistency through a hardware handshake mechanism. Then, the state packet is transmitted across chips to the target node and restored, thereby avoiding problems such as interrupt loss, duplicate injection, or disordered processing order.

[0054] Optionally, in some embodiments, this disclosure provides a Hypervisor-DVIC runtime management interface (HV-DVICAPI), which can be used to support commands such as virtual machine creation, destruction, GVII allocation, vCPU migration triggering, and performance monitoring, enabling the Hypervisor to configure and manage the entire distributed virtual interrupt domain with minimal software overhead.

[0055] Through the aforementioned structure and mechanism, this disclosure enables low-latency injection of cross-chip virtual interrupts, scalable management of interrupt resources in large-scale clusters, and interrupt state consistency during vCPU dynamic migration, thereby significantly improving the interrupt performance and scalability of RISC-V virtualization clusters in cloud computing, edge computing, and real-time systems. When the DVIC function is disabled or the system degrades to single-chip operation, all newly added hardware modules are automatically bypassed. That is, when the DVIC function is disabled or the system is in single-chip operation mode, all DVIC-related extended hardware modules can automatically enter bypass mode, and the interrupt delivery path directly falls back to the standard APLIC→IMSIC path, making the system behavior fully compliant with the RISC-V APLIC+IMSIC specification and seamlessly compatible with existing guest operating systems (such as Linux, RT-Linux, OpenHarmony) and hypervisors (such as KVM, Bao).

[0056] In some embodiments, the cluster-distributed virtual interrupt control system may be a layered, distributed architecture consisting of core static components such as DVIC-Node, DVIC-Global, HV-DVIC API, and vCPU State Buffer, and the functions of these components and their collaborative relationship with the local IMSIC are defined.

[0057] In some embodiments, the cluster-distributed virtual interrupt control system proposed in this disclosure is applicable to RISC-V clusters. This system can consist of multiple DVIC nodes distributed across different physical locations on multiple chips, multiple clusters, or Chiplet SoCs, forming a unified distributed virtual interrupt domain through an on-chip / inter-chip interconnect network (NoC / Chiplet Interconnect). This architecture maps all virtual interrupt sources to a globally unified namespace through a Global Virtual Interrupt Identity (GVII) system and achieves low-latency transmission of virtual interrupts across nodes through a direct cross-chip injection protocol (DIP). In vCPU migration or virtual machine rescheduling scenarios, DVIC nodes maintain interrupt state consistency through an atomic transfer mechanism (ASTP) to ensure that interrupts are not lost or duplicated during migration. The hypervisor configures and manages the entire distributed virtual interrupt domain through the HV-DVIC API, forming a dynamic, scalable, and virtualization-supporting interrupt control system covering the entire cluster.

[0058] In some embodiments, the overall architecture of the cluster-distributed virtual interrupt control system can be divided into: interrupt source input layer, DVIC distributed scheduling layer, cross-chip transmission layer, IMSIC injection layer, and virtual machine management layer, which together constitute a complete virtual interrupt processing data path.

[0059] In some possible embodiments, the core components of the overall architecture of the clustered distributed virtual interruption control system may include, but are not limited to, the following modules:

[0060] 1. DVIC Node

[0061] Deployed on each physical cluster or each Chiplet, it is the fundamental building block of this disclosure. It may include:

[0062] Local Virtual Interrupt File Management Module: Responsible for maintaining the local mapping, interrupt status, priority, and target vCPU information of all GVIIs on this node;

[0063] Interrupt scheduling and arbitration module: Within this node, it determines the target IMSIC or target DVIC node based on GVII mapping (such as the mapping relationship between global virtual interrupt identity GVII and IMSIC interrupt file entries), priority, and routing policy;

[0064] IMSIC Collaboration Interface Module: Communicates with the local hardware IMSIC to directly deliver the hit virtual interrupt to the corresponding interrupt file of the vCPU;

[0065] Cross-node communication module: Used to construct DIP messages and communicate with other DVIC nodes.

[0066] It is worth noting that the DVIC node is the basic hardware logic for implementing distributed virtual interrupt control.

[0067] 2. A global virtual interrupt management layer may include the following modules:

[0068] 1) Global Virtual Interrupt Identity (GVII) Management Module

[0069] This module can be used to overcome the limitations of IMSIC's native resources (fixed number of Interrupt IDs) to achieve scalable interrupt naming and isolation across clusters and large-scale virtual machine environments. It includes:

[0070] GVII Global Namespace: Assigns a global ID to each virtual interrupt source that is not bound to the physical IMSIC;

[0071] Hierarchical mapping mechanism: GVII → DVIC-Node local ID → IMSIC interrupt file entry;

[0072] Namespace isolation mechanism: Supports independent namespaces for multiple VMs, multiple tenants, and multiple vCPUs, achieving hardware-level isolation.

[0073] It is worth noting that the Global Virtual Interrupt Identity (GVII) management module enables the system to expand the number of virtual interrupts in clusters with thousands or even tens of thousands of cores.

[0074] 2) Hierarchical resource allocation module

[0075] This module can be used to solve the problem of cross-node distribution and expansion of interrupted resources, including:

[0076] Centralized or distributed GVII allocation strategies (e.g., round-robin, allocation by tenant or VM dimension);

[0077] On-demand expandable virtual interrupt file resource pool;

[0078] Dynamic reassignment mechanism across Chiplet (for large-scale VM expansion).

[0079] It is worth noting that through this hierarchical resource allocation module, the system can avoid the bottleneck problem caused by the traditional IMSIC "fixed capacity" and achieve true horizontal scaling.

[0080] 3. Cross-chip Virtual Interrupt Direct Injection Protocol (DIP) Module

[0081] This module is the core innovative component for achieving low latency in this disclosure, including:

[0082] DIP messages defined by hardware format (e.g., may include, but are not limited to, at least one or more of the following: GVII, target vCPU, priority, interrupt status bit);

[0083] Cross-node transmission path selection (e.g., via NoC or Chiplet interconnection);

[0084] Fast parsing logic for target nodes (no Hypervisor required);

[0085] Injection direct access mechanism (DIP message direct writing to IMSIC file).

[0086] It is worth noting that the cross-chip virtual interrupt direct injection protocol (DIP) module can significantly reduce the latency of cross-chip interrupt delivery and improve determinism.

[0087] 4. Virtual Interrupt State Atomic Transfer (ASTP) Module

[0088] Primarily used in vCPU dynamic migration scenarios to ensure consistent interrupt behavior, this Virtual Interrupt State Atomic Transfer (ASTP) module may include:

[0089] Interruption state freeze unit (freeze pending / enable / priority atomic);

[0090] State encapsulation and serialization module (generates migration state packets);

[0091] Cross-chip transmission module;

[0092] Target node recovery module (restore pending bits & enable bits).

[0093] It is worth noting that the Virtual Interrupt State Atomic Transfer (ASTP) module can ensure that interrupt states are not lost, repeated, or out of order.

[0094] 5. Hypervisor – DVIC Runtime Interface (HV-DVIC API)

[0095] The HV-DVIC API interface provides software management layer capabilities: VM creation / destruction interface (assigning GVII, binding interrupt policies); vCPU binding / migration interface (triggering ASTP); virtual interrupt configuration instructions; and performance monitoring and debugging interface. This interface enables the entire distributed architecture to work with existing RISC-V virtualization frameworks (such as KVM and OpenSBI). This disclosure, by providing the HV-DVIC API, allows the hypervisor to configure and manage the entire distributed interrupt domain with minimal software overhead, offloading interrupt management complexity from the software layer to the hardware-accelerated DVIC plane. Simultaneously, the HV-DVIC API supports interrupt domain isolation, enhancing security and isolation in multi-tenant environments, thereby optimizing hypervisor software overhead and architectural flexibility.

[0096] Figure 2 This is a flowchart illustrating a clustered distributed virtual interruption control method according to an exemplary embodiment. The method can be applied to a first DVIC node, which can be a source DVIC node among multiple DVIC nodes. Figure 2 As shown, the cluster-distributed virtual interruption control method may include, but is not limited to, the following steps.

[0097] Step 201: Upon receiving a virtual interrupt request, determine the interrupt target routing information corresponding to the virtual interrupt.

[0098] In some embodiments, the virtual interrupt request may originate from the local device or I / O virtualization of the first DVIC node. In some embodiments, upon receiving a virtual interrupt request, the first DVIC node may perform Global Virtual Interrupt Identity (GVII) identification on the virtual interrupt source and perform routing information query based on the identified GVII identifier to determine the interrupt target routing information corresponding to the virtual interrupt.

[0099] In one possible implementation, the first DVIC node can map the interrupt source associated with the virtual interrupt request to a cluster-wide Global Virtual Interrupt Identity (GVII). The first DVIC node can query its local cache or manager (such as the DVIC Global Manager or the Cluster Rules Manager) to determine the interrupt target routing information from the interrupt routing map table. Optionally, this interrupt routing map table may include the mapping relationship between the Global Virtual Interrupt Identity, the node identifier of the DVIC node, and IMSIC interrupt file entries. The interrupt target routing information may include the node identifier of the second DVIC node (such as the target DVIC-Node ID) and the thread identifier (Hart ID) of the first hardware thread, which may be the hardware thread of the target vCPU running on the second DVIC node. For example, the first DVIC node can look up the interrupt routing map table based on the Global Virtual Interrupt Identity, and combine it with priority and routing policy to determine the node identifier of the second DVIC node corresponding to the Global Virtual Interrupt Identity and the Hart ID of the target vCPU.

[0100] Step 202: Based on the interrupt target routing information, construct a cross-chip hardware-level direct injection message.

[0101] In some embodiments, the cross-chip hardware-level direct injection message can be a message constructed based on the Direct Injection Protocol (DIP). This DIP message is a hardware-formatted message that enables interrupts to be directly encapsulated from the source hardware to the target hardware for reception, verification, and injection, completely bypassing the Hypervisor software stack. In some embodiments, the DIP message may include, but is not limited to, one or more of the following: GVII, target vCPU identifier, priority information, interrupt status bits, timestamp, payload, etc. For example, the size of the DIP message may be 64 bytes.

[0102] In the embodiments of this disclosure, when the first DVIC node finds the interrupt target routing information corresponding to the virtual interrupt, it can encapsulate the interrupt target routing information using the DIP protocol to form a hardware-recognizable cross-chip virtual interrupt direct injection message. For example, the cross-node communication module of the first DVIC node constructs a hardware-formatted cross-chip virtual interrupt direct injection message based on the interrupt target routing information. In some embodiments, the hardware-level direct injection message may include, but is not limited to, one or more of the following: Global Virtual Interrupt Identity (GVII); target vCPU identifier; priority information; timestamp; interrupt payload, etc. For example, the size of the hardware-level direct injection message is 64 bytes, and it may include a 64-bit GVII, an 8-bit priority, a 32-bit timestamp, and a payload, etc.

[0103] Step 203: The hardware-level direct injection message is sent to the second DVIC node through inter-chip interconnection. The hardware-level direct injection message is written directly into the IMSIC interrupt file by the second DVIC node through hardware logic.

[0104] In the embodiments of this disclosure, the first DVIC node can directly send the hardware-level direct injection message to the receive queue of the second DVIC node in a point-to-point manner via inter-chip interconnect (such as NoC / CXL / Chiplet interconnect). This process bypasses the Hypervisor software stack and can achieve sub-microsecond low-latency transmission. Upon receiving the hardware-level direct injection message, the second DVIC node can quickly parse the message to obtain the global virtual interrupt identity (GVII) and priority information. The IMSIC coordination interface module of the second DVIC node can directly write the parsed global virtual interrupt identity (GVII) into the local IMSIC interrupt file entry corresponding to the target vCPU, completing the virtual interrupt injection and achieving fast injection at the Guest level.

[0105] Optionally, in some possible embodiments, when the DVIC node is disabled or the system is running in single-chip mode, the interrupt handling path of the DVIC node is automatically bypassed by the virtual interrupt control system, so that the virtual interrupt control system delivers interrupts according to the standard interrupt paths of RISC-VAPLIC and IMSIC, to achieve seamless compatibility.

[0106] In the above embodiment, when the first DVIC node receives a virtual interrupt request, it can determine the interrupt target routing information corresponding to the virtual interrupt. Based on this interrupt target routing information and the hardware-accelerated direct injection protocol (DIP), it constructs a cross-chip hardware-level direct injection message (i.e., a DVIC-specific message). This message is then sent directly to the second DVIC node via inter-chip interconnection to complete the virtual interrupt injection. In other words, by employing the hardware-accelerated direct injection protocol (DIP) and the DVIC-specific message, the high-overhead Hypervisor software stack and doorbell mechanism can be bypassed, significantly reducing the end-to-end latency of cross-chip virtual interrupt delivery. This greatly improves the real-time performance and determinism of the virtualization cluster, enabling the RISC-V platform to meet the needs of critical applications such as automotive functional safety OS (operating system), high-frequency trading, and latency-sensitive NFV (Network Functions Virtualization). Furthermore, by bypassing the doorbell mechanism, the cache coherence storms and power spikes caused by the doorbell mechanism can be eliminated, thereby improving CPU resource utilization and power efficiency.

[0107] In some embodiments, the global virtual interrupt identity can be allocated by the cluster-level resource management module according to a hierarchical resource allocation strategy, and a mapping relationship between the global virtual interrupt identity and IMSIC interrupt file entries can be established locally on each DVIC node. It should be noted that the mapping relationship between the global virtual interrupt identity, the node identifier of the DVIC node, and the IMSIC interrupt file entries can be pre-built. Optionally, in some embodiments, such as... Figure 3 As shown, the method for constructing the mapping relationship between the global virtual interrupt identity, the node identifier of the DVIC node, and the IMSIC interrupt file entry may include, but is not limited to, the following steps.

[0108] Step 301: According to the hierarchical resource allocation strategy, allocate a set of global virtual interrupt identity ranges from the global virtual interrupt identity namespace.

[0109] For example, step 301 can be performed by a manager (such as DVIC Global Manager or CRM). This tiered resource allocation strategy can be based on tenant or VM dimensions. For instance, a set of GVII ranges can be allocated from the global GVII namespace based on tenant or VM dimensions, ensuring the uniqueness and isolation of the global namespace.

[0110] Step 302: Notify the DVIC node to reserve or initialize local interrupt identifier mapping entries corresponding to the global virtual interrupt identity range in its local virtual interrupt file; wherein, the DVIC node binds the global virtual interrupt identity mapping to its local IMSIC resources to build a mapping relationship between the global virtual interrupt identity, the node identifier of the DVIC node, and the IMSIC interrupt file entries.

[0111] For example, step 302 can be performed by the manager. After allocating a set of GVII ranges from the global GVII namespace, the GVII ranges can be sent to the DVIC node, and the DVIC node can reserve or initialize the corresponding local interrupt identity (Local ID) mapping entries in its local virtual interrupt file to establish the mapping basis between GVII and local IMSIC interrupt file entries. The DVIC node binds the GVII mapping to its local IMSIC resources to build the mapping relationship between the global virtual interrupt identity, the DVIC node's node identifier, and the IMSIC interrupt file entries.

[0112] It should be noted that this disclosure supports scalable management of interrupt resources for large-scale clusters. To support this functionality, this disclosure can utilize the GVII system to achieve large-scale linear scaling of virtual interrupt resources across clusters. For example, such as Figure 4 As shown, the method for assigning a Global Virtual Interruption Identity (GVII) may include the following steps.

[0113] Step 401, VM Creation Request: The Hypervisor sends a request via the HV-DVIC API to allocate a virtual interrupt resource namespace for the newly created virtual machine (VM).

[0114] Step 402, GVII Space Allocation: The manager (such as DVIC Global Manager or CRM) allocates a set of GVII ranges from the global GVII namespace according to the hierarchical resource allocation strategy (e.g., by VM dimension or tenant dimension).

[0115] Step 403, Local Resource Reservation: The manager notifies the target DVIC node (i.e., the node where the vCPU is located) to reserve or initialize the corresponding GVII range local interrupt identity (Local ID) mapping entry in its local virtual interrupt file.

[0116] Step 404, Layered Mapping Establishment: The target DVIC node binds the GVII mapping to its local IMSIC resources and notifies the Hypervisor and Manager to complete the mapping.

[0117] In the above embodiments, by introducing a Global Virtual Interrupt Identity (GVII) system and a hierarchical resource allocation mechanism, the namespace of the virtual interrupt identity is extended to the entire cluster, which can realize large-scale linear expansion of virtual interrupt resources. This can solve the bottleneck of the fixed number of interrupt identities in the existing IMSIC architecture, and make the virtual interrupt carrying capacity of the DVIC system linearly expand with the number of physical cores. It can support large-scale RISC-V clusters with higher levels of cores (such as 1024 cores or even 4096 cores or more), and meet the huge demand of high-density multi-tenant cloud computing environments for the number of virtual machines and interrupt sources.

[0118] Optionally, this disclosure can ensure the atomicity and reliability of interrupt states during the dynamic migration of vCPUs in vCPU migration or virtual machine rescheduling scenarios, thus solving the O(N²) overhead caused by relying on full cluster broadcast in existing technologies. In some possible embodiments, based on any of the above embodiments or a set of embodiments, such as Figure 5 As shown, the cluster-distributed virtual interruption control method may also include, but is not limited to, the following steps.

[0119] Step 501: In response to the vCPU migration instruction, the first DVIC node enters a silent state and freezes all new interrupt requests flowing to the vCPU.

[0120] For example, this embodiment describes how to ensure the atomic consistency of virtual interrupt states when a vCPU migrates from a first DVIC node to a second DVIC node. Optionally, the aforementioned vCPU migration instruction can be triggered by the Hypervisor. For example, the Hypervisor sends the vCPU migration instruction through the HV-DVIC API interface; that is, the Hypervisor sends the vCPU migration instruction to the first DVIC node through the HV-DVIC API interface, notifying the first DVIC node to prepare for interrupt state transition. Upon receiving the vCPU migration instruction, the first DVIC node's interrupt and arbitration module enters a silent state, freezing all new interrupt requests flowing to that vCPU.

[0121] Step 502: In the frozen state, extract all virtual interrupt status information associated with the vCPU from the vCPU status buffer and form virtual interrupt status transition data; wherein the virtual interrupt status information may include, but is not limited to, suspended state, enabled state and priority information.

[0122] Optionally, in the frozen state, the first DVIC node can atomically extract all interrupt states such as suspended, enabled, and priority from the vCPU state buffer and form virtual interrupt state transfer data for consistent migration across DVIC nodes, avoiding changes in state during transmission.

[0123] Step 503: Encapsulate the virtual interrupt status information into a virtual interrupt status atomic transfer message, and send the virtual interrupt status atomic transfer message to the second DVIC node through inter-chip interconnect. The virtual interrupt status atomic transfer message can be used by the second DVIC node to atomically write the virtual interrupt status information into the vCPU status buffer and the corresponding IMSIC entry of the target core.

[0124] For example, the first DVIC node can encapsulate the frozen virtual interrupt status information into an ASTP state transition data packet, and then encapsulate this ASTP state transition data packet into a virtual interrupt status atomic transition message through the cross-node communication module in conjunction with the DIP protocol. This virtual interrupt status atomic transition message is a special message format of the DIP protocol, and the message may include at least interrupt status bits. This virtual interrupt status atomic transition message is sent to the second DVIC node through the cross-node communication module to achieve high-speed and reliable status transmission. Upon receiving the virtual interrupt status atomic transition message, the second DVIC node can parse the message to obtain the virtual interrupt status information, and, with the guarantee of the hardware handshake mechanism, atomically write the virtual interrupt status information into the target core's vCPU status buffer and the corresponding IMSIC entry to achieve immediate and complete recovery on the target node. After completing the writing of the virtual interrupt status information, the second DVIC node can notify the manager to update the new physical location of the vCPU. Upon receiving the notification, the manager can synchronize the new routing information to the cluster, and the first DVIC node will be de-silent to ensure that subsequent interruption messages can be correctly delivered to the new location.

[0125] Step 504: After the virtual interrupt state transition message is sent, the first DVIC node enters the invalidation state of the vCPU virtual interrupt state, and the second DVIC node takes over the management of the virtual interrupt state corresponding to the vCPU.

[0126] For example, after the first DVIC node completes the virtual interrupt state transition message, it can put the virtual interrupt state of the vCPU on its own node into an invalid state, that is, invalidate the virtual interrupt state on the first DVIC node, and can notify the second DVIC node to take over the management of the virtual interrupt state of the vCPU.

[0127] Optionally, in some possible embodiments, after the first DVIC node enters a silent state, it caches virtual interrupt requests arriving during the migration. These cached virtual interrupt requests can be redelivered after the second DVIC node takes over the virtual interrupt state, and the target DVIC node can then take over vCPU interrupt routing based on the virtual interrupt state transfer data. For example, after the first DVIC node enters a silent state, it can cache virtual interrupt requests arriving during the migration and can redeliver these cached virtual interrupt requests after the second DVIC node takes over the vCPU virtual interrupt state.

[0128] In the above embodiments, by introducing the Virtual Interrupt State Atomic Transfer (ASTP) mechanism, combined with the DVIC node's vCPU state buffer and hardware handshake, atomic encapsulation, transmission, and recovery of interrupt states can be achieved. This solves the problem of O(N) latency caused by relying on full cluster broadcast in existing technologies. 2 By mitigating the overhead limitations, we can guarantee zero loss, zero duplication, and zero out-of-order interrupt states during vCPU cross-chip live migration. This significantly improves the service continuity and reliability of the cluster, forming the foundation for high-performance load balancing and failover.

[0129] Figure 6 This is a cluster-distributed virtual interruption control method illustrated according to an exemplary embodiment. This cluster-distributed virtual interruption control method can be applied to a second DVIC node 102. For example... Figure 6 As shown, this cluster-distributed virtual interruption control method

[0130] Step 601: Receive the hardware-level direct injection message sent by the first DVIC node through the inter-chip interconnect.

[0131] In some embodiments of this disclosure, the hardware-level direct injection message can be constructed by the first DVIC node based on the interrupt target routing information corresponding to the global virtual interrupt identity. The global virtual interrupt identity can be a cluster-wide global virtual interrupt identity mapped by the first DVIC node to the interrupt source associated with the virtual interrupt request. In some embodiments, the hardware-level direct injection message includes at least one or more of the following: global virtual interrupt identity; target vCPU identifier; priority information; timestamp; interrupt payload.

[0132] For example, upon receiving a virtual interrupt request, the first DVIC node determines the interrupt target routing information corresponding to the virtual interrupt; based on the interrupt target routing information, the first DVIC node constructs a cross-chip hardware-level direct injection message; the first DVIC node sends the hardware-level direct injection message to the second DVIC node via inter-chip interconnect, and the hardware-level direct injection message is used to directly write the target incoming message signal interrupt controller IMSIC interrupt file in the second DVIC node. Optional implementation methods can be found in the description of the relevant steps in the above-described method embodiment on the first DVIC node side, and will not be repeated here.

[0133] Step 602: The hardware-level direct injection message is written directly into the IMSIC interrupt file through hardware logic to inject virtual interrupts.

[0134] For example, when the second DVIC node receives a hardware-level direct injection message sent by the first DVIC node in a point-to-point manner via inter-chip interconnect, it can parse the message to obtain the global virtual interrupt identity (GVII) and priority information. The IMSIC coordination interface module of the second DVIC node can then directly write the parsed GVII into the local IMSIC interrupt file entry corresponding to the target vCPU, completing the virtual interrupt injection and achieving fast injection at the Guest level.

[0135] In the above embodiment, when the first DVIC node receives a virtual interrupt request, it can determine the interrupt target routing information corresponding to the virtual interrupt. Based on this interrupt target routing information and the hardware-accelerated direct injection protocol (DIP), a hardware-level direct injection message (i.e., a DVIC-specific message) is constructed. This message is then sent directly to the second DVIC node in a point-to-point manner via inter-chip interconnection, completing the virtual interrupt injection. In other words, by employing the hardware-accelerated direct injection protocol (DIP) and the DVIC-specific message, the high-overhead Hypervisor software stack and doorbell mechanism can be bypassed, significantly reducing the end-to-end latency of cross-chip virtual interrupt delivery. This greatly improves the real-time performance and determinism of the virtualization cluster, enabling the RISC-V platform to meet the needs of critical applications such as automotive functional safety OS (operating system), high-frequency trading, and latency-sensitive NFV (Network Functions Virtualization). Furthermore, by bypassing the doorbell mechanism, cache coherence storms and power spikes caused by the doorbell mechanism can be eliminated, thereby improving CPU resource utilization and power efficiency.

[0136] Optionally, this disclosure can ensure the atomicity and reliability of interrupt states during the dynamic migration of vCPUs in vCPU migration or virtual machine rescheduling scenarios, thus solving the O(N²) overhead caused by relying on full cluster broadcast in existing technologies. In some possible embodiments, based on any of the above embodiments or a set of embodiments, the cluster-distributed virtual interrupt control method involved in the embodiments of this disclosure can be applied to the second node 102, such as... Figure 7 As shown, the method may also include, but is not limited to, the following steps.

[0137] Step 701: Receive the virtual interrupt status atomic transfer message sent by the first DVIC node.

[0138] In one embodiment of this disclosure, the virtual interrupt state atomic transfer message can be generated based on all virtual interrupt state information extracted atomically from the vCPU state buffer by the first DVIC node. The virtual interrupt state information is extracted by the first DVIC node after receiving the vCPU migration instruction and entering a silent state, freezing all new interrupt requests flowing to the vCPU.

[0139] Optionally, the aforementioned vCPU migration command can be triggered by the Hypervisor. For example, the Hypervisor sends the vCPU migration command through the HV-DVIC API interface; that is, the Hypervisor sends the vCPU migration command to the first DVIC node through the HV-DVIC API interface, notifying the first DVIC node to prepare for interrupt state transition. Upon receiving the vCPU migration command, the first DVIC node's interrupt and arbitration module enters a silent state, freezing all new interrupt requests flowing to that vCPU, and atomically extracting all suspended, enabled, and priority interrupt states from the vCPU state buffer to prevent state changes during transmission. The first DVIC node can encapsulate all frozen virtual interrupt state information into an ASTP state transition data packet, and then, through the cross-node communication module combined with the DIP protocol, encapsulate this ASTP state transition data packet into a virtual interrupt state atomic transition message. This virtual interrupt state atomic transition message is a special message format of the DIP protocol, and the message may include at least interrupt status bits. The virtual interrupt state atomic transfer message is sent to the second DVIC node through the cross-node communication module. Correspondingly, the second DVIC node can receive the virtual interrupt state atomic transfer message sent by the first DVIC node.

[0140] Step 702: Parse the virtual interrupt status atomic transfer message to obtain the virtual interrupt status information, and atomically write the virtual interrupt status information into the target core's vCPU status buffer and the corresponding IMSIC entry.

[0141] For example, when the second DVIC node receives the virtual interrupt state atomic transfer message, it can parse the virtual interrupt state atomic transfer message to obtain the virtual interrupt state information. Under the guarantee of the hardware handshake mechanism, the virtual interrupt state information is atomically written into the target core's vCPU state buffer and the corresponding IMSIC entry to achieve immediate and complete recovery on the target node.

[0142] Step 703: Take over the virtual interrupt status management corresponding to the vCPU.

[0143] For example, the DVIC Global Manager or Cluster Rule Manager can be notified to update the new physical location of the vCPU, so that the Cluster Rule Manager can synchronize the new routing information to the cluster and take over the virtual interrupt status management corresponding to the newly migrated vCPU.

[0144] For example, after completing the writing of virtual interrupt status information, the second DVIC node can notify the manager to update the new physical location of the vCPU. Upon receiving this notification, the manager can synchronize the new routing information to the cluster, and the first DVIC node will be unsilent to ensure that subsequent interrupt messages can be correctly delivered to the new location.

[0145] In the above embodiments, by introducing the Virtual Interrupt State Atomic Transfer (ASTP) mechanism, combined with the DVIC node's vCPU state buffer and hardware handshake, atomic encapsulation, transmission, and recovery of interrupt states can be achieved. This solves the problem of O(N) latency caused by relying on full cluster broadcast in existing technologies. 2 By mitigating the overhead limitations, we can guarantee zero loss, zero duplication, and zero out-of-order interrupt states during vCPU cross-chip live migration. This significantly improves the service continuity and reliability of the cluster, forming the foundation for high-performance load balancing and failover.

[0146] This disclosure may also provide a clustered distributed virtual interruption control system, which may include multiple DVIC nodes. For example, the DVIC nodes may include a first DVIC node 101 and a second DVIC node 102. The first DVIC node 101 may be configured to execute the clustered distributed virtual interruption control method in the aforementioned first DVIC node-side method embodiment; the second DVIC node 102 may be configured to execute the clustered distributed virtual interruption control method in the aforementioned second DVIC node-side method embodiment. Further details are omitted here.

[0147] Figure 8This is a block diagram illustrating a clustered distributed virtual interrupt control device according to an exemplary embodiment. Optionally, the clustered distributed virtual interrupt control device may be configured on a first DVIC node, or the device may also be the first DVIC node. Figure 8 As shown, the cluster distributed virtual interruption control device may include: a route determination module 801, a message construction module 802, and a message sending module 803.

[0148] Among them, the route determination module 801 is used to determine the interrupt target route information corresponding to the virtual interrupt when a virtual interrupt request is received.

[0149] The message construction module 802 is used to construct cross-chip hardware-level direct injection messages based on the interrupt target routing information.

[0150] The message sending module 803 is used to send hardware-level direct injection messages to the second DVIC node through inter-chip interconnection. The hardware-level direct injection messages are written directly into the IMSIC interrupt file of the incoming message signal interrupt controller by the second DVIC node through hardware logic.

[0151] In some embodiments, the routing determination module 801 is configured to: map the interrupt source associated with the virtual interrupt request to a global virtual interrupt identity within the cluster; and search the interrupt routing mapping table based on the global virtual interrupt identity to determine the interrupt target routing information, wherein the interrupt target routing information includes at least the node identifier of the second DVIC node and the thread identifier of the first hardware thread, wherein the first hardware thread is the hardware thread in which the target virtual central processing unit (vCPU) runs on the second DVIC node.

[0152] In some embodiments, the global virtual interrupt identity is allocated by the cluster-level resource management module according to a hierarchical resource allocation strategy, and a mapping relationship between the global virtual interrupt identity and the IMSIC interrupt file entry is established locally on each DVIC node.

[0153] In some embodiments, the hardware-level direct injection message includes at least one or more of the following: global virtual interrupt identity; target vCPU identifier; priority information; timestamp; interrupt payload.

[0154] In some embodiments, the cluster-distributed virtual interruption control device may further include a migration processing module. The migration processing module is configured to: respond to a vCPU migration command by causing the first DVIC node to enter a silent state and freezing all new interrupt requests flowing to the vCPU; in the frozen state, extract all virtual interrupt status information associated with the vCPU from the vCPU status buffer and form virtual interrupt status transfer data; wherein the virtual interrupt status information includes suspended state, enabled state, and priority information; encapsulate the virtual interrupt status information into a virtual interrupt status atomic transfer message and send it to the second DVIC node via the inter-chip interconnect; the virtual interrupt status atomic transfer message is used by the second DVIC node to atomically write the virtual interrupt status information into the target core's vCPU status buffer and the corresponding IMSIC entry; after the virtual interrupt status transfer message is sent, the first DVIC node enters an invalid state for the vCPU virtual interrupt status, and the second DVIC node takes over the management of the virtual interrupt status corresponding to the vCPU; after the first DVIC node enters a silent state, the first DVIC node caches the virtual interrupt requests that arrive during the migration, and the cached virtual interrupt requests are used to resubmit after the second DVIC node takes over the virtual interrupt status.

[0155] Optionally, in some embodiments, when the DVIC node is disabled or the system is running in single-chip mode, the interrupt handling path of the DVIC node is automatically bypassed by the virtual interrupt control system, so that the virtual interrupt control system delivers interrupts according to the standard interrupt paths of RISC-VAPLIC and IMSIC.

[0156] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0157] Figure 9 This is a block diagram illustrating a clustered distributed virtual interrupt control device according to an exemplary embodiment. Optionally, the clustered distributed virtual interrupt control device may be configured on a second DVIC node, or the device may also be the second DVIC node. Figure 9 As shown, the cluster-distributed virtual interrupt control device may include: a message receiving module 901 and an interrupt writing module 902.

[0158] The message receiving module 901 is used to receive the hardware-level direct injection message sent by the first DVIC node in a point-to-point manner through inter-chip interconnection. The hardware-level direct injection message is constructed by the first DVIC node according to the interrupt target routing information corresponding to the global virtual interrupt identity. The global virtual interrupt identity is the global virtual interrupt identity that the first DVIC node maps the interrupt source associated with the virtual interrupt request to the cluster-wide global virtual interrupt identity.

[0159] The interrupt writing module 902 is used to write virtual interrupts directly into the incoming message signal interrupt controller IMSIC interrupt file through hardware logic by directly injecting hardware-level messages.

[0160] In some embodiments, the hardware-level direct injection message includes at least one or more of the following: global virtual interrupt identity; target vCPU identifier; priority information; timestamp; interrupt payload.

[0161] In some embodiments, the cluster-distributed virtual interrupt control device may further include a migration processing module. This migration processing module is configured to: receive a virtual interrupt state atomic transfer message sent by a first DVIC node, the virtual interrupt state atomic transfer message being generated based on all virtual interrupt state information atomically extracted by the first DVIC node from the vCPU state buffer, wherein the virtual interrupt state information is extracted by the first DVIC node after receiving a vCPU migration instruction and entering a silent state, freezing all new interrupt requests flowing to the vCPU; parse the virtual interrupt state atomic transfer message to obtain the virtual interrupt state information, and atomically write the virtual interrupt state information into the target core's vCPU state buffer and the corresponding IMSIC entry; and take over the virtual interrupt state management corresponding to the vCPU.

[0162] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0163] Figure 10 This is a block diagram illustrating an electronic device 1000 according to an exemplary embodiment. For example, the electronic device 1000 may be provided as a DVIC node (such as a first DVIC node 101 and a second DVIC node 102 herein). Figure 10 As shown, the electronic device 1000 may include a processing component 1022, which further includes one or more processors, and memory resources represented by memory 1032 for storing instructions, such as application programs, that can be executed by the processing component 1022. The application programs stored in memory 1032 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 1022 is configured to execute instructions to perform the methods described above.

[0164] Electronic device 1000 may also include a power supply component 1026 configured for power management of electronic device 1000, a wired or wireless network interface 1050 configured to connect electronic device 1000 to a network, and an input / output (I / O) interface 1058. Electronic device 1000 may operate on an operating system stored in memory 1032, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, or similar.

[0165] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 1032 including instructions, which can be executed by a processor of an electronic device 1000 to perform the above-described method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0166] In an exemplary embodiment, a program product is also provided, including at least one of a program and instructions, wherein the program and instructions, when executed by a processor of an electronic device 1000, implement the steps of the above-described method.

[0167] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0168] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A cluster-distributed virtual interruption control method, characterized in that, The method is applied to the first distributed virtual interrupt controller (DVIC) node, and the method includes: Upon receiving a virtual interrupt request, the system determines the interrupt target routing information corresponding to the virtual interrupt, including: mapping the interrupt source associated with the virtual interrupt request to a global virtual interrupt identity within the cluster; searching the interrupt routing mapping table based on the global virtual interrupt identity to determine the interrupt target routing information, wherein the interrupt target routing information includes at least the node identifier of the second DVIC node and the thread identifier of the first hardware thread, the first hardware thread being the hardware thread where the target virtual central processing unit (vCPU) runs on the second DVIC node; wherein the global virtual interrupt identity is allocated by the cluster-level resource management module according to a hierarchical resource allocation strategy, and a mapping relationship between the global virtual interrupt identity and the IMSIC interrupt file entry of the incoming message signal interrupt controller is established locally on each DVIC node; Based on the interrupt target routing information, construct a cross-chip hardware-level direct injection message; The hardware-level direct injection message is sent to the second DVIC node through inter-chip interconnection. The hardware-level direct injection message is then written directly into the IMSIC interrupt file by the second DVIC node through hardware logic.

2. The method according to claim 1, characterized in that, The hardware-level direct injection message includes at least one or more of the following: global virtual interrupt identity; target vCPU identifier; priority information; timestamp; interrupt payload.

3. The method according to any one of claims 1-2, characterized in that, The method also includes one or more of the following: In response to the vCPU migration command, the first DVIC node enters a silent state and freezes all new interrupt requests flowing to the vCPU. In the frozen state, all virtual interrupt status information associated with the vCPU is extracted from the vCPU status buffer and virtual interrupt status transfer data for cross-DVIC node consistency migration is formed; wherein the virtual interrupt status information includes suspended state, enabled state and priority information. The virtual interrupt status information is encapsulated into a virtual interrupt status atomic transfer message and sent to the second DVIC node via inter-chip interconnect; the virtual interrupt status atomic transfer message is used by the second DVIC node to atomically write the virtual interrupt status information into the vCPU status buffer and the corresponding IMSIC entry of the target core; After the virtual interrupt state transition message is sent, the first DVIC node enters an invalid state for the vCPU virtual interrupt state, and the second DVIC node takes over the management of the virtual interrupt state corresponding to the vCPU. After the first DVIC node enters a silent state, the first DVIC node caches virtual interrupt requests that arrive during the migration. The cached virtual interrupt requests are used to resubmit the virtual interrupt state after the second DVIC node takes over the virtual interrupt state and complete the takeover of the vCPU interrupt route by the target DVIC node based on the virtual interrupt state transfer data.

4. The method according to claim 1, characterized in that, When the DVIC node is disabled or the system is running in single-chip mode, the interrupt handling path of the DVIC node is automatically bypassed by the virtual interrupt control system, so that the virtual interrupt control system delivers interrupts according to the standard interrupt paths of APLIC and IMSIC in the RISC-V advanced interrupt architecture.

5. A cluster-distributed virtual interruption control method, characterized in that, The method is applied to the second distributed virtual interrupt controller (DVIC) node, and the method includes: The system receives a hardware-level direct injection message sent by the first DVIC node via inter-chip interconnect. This message is constructed from interrupt target routing information corresponding to the global virtual interrupt identity of the first DVIC node. The global virtual interrupt identity is the cluster-wide global virtual interrupt identity mapped by the first DVIC node to the interrupt source associated with the virtual interrupt request. The interrupt target routing information is determined as follows: mapping the interrupt source associated with the virtual interrupt request to the cluster-wide global virtual interrupt identity; and searching the interrupt routing mapping table based on the global virtual interrupt identity to determine the interrupt target routing information. This interrupt target routing information includes at least the node identifier of the second DVIC node and the thread identifier of the first hardware thread, where the first hardware thread is the hardware thread where the target virtual central processing unit (vCPU) runs on the second DVIC node. The global virtual interrupt identity is allocated by the cluster-level resource management module according to a hierarchical resource allocation strategy, and a mapping relationship between the global virtual interrupt identity and the IMSIC interrupt file entry is established locally on each DVIC node. The hardware-level direct injection message uses hardware logic to directly write virtual interrupts into the incoming message signal interrupt controller (IMSIC) interrupt file.

6. A clustered distributed virtual interruption control device, characterized in that, The device is configured on a first distributed virtual interrupt controller (DVIC) node, and the device includes: The routing determination module is used to determine the interrupt target routing information corresponding to the virtual interrupt upon receiving a virtual interrupt request. This includes: mapping the interrupt source associated with the virtual interrupt request to a global virtual interrupt identity within the cluster; searching the interrupt routing mapping table based on the global virtual interrupt identity to determine the interrupt target routing information, wherein the interrupt target routing information includes at least the node identifier of the second DVIC node and the thread identifier of the first hardware thread, where the first hardware thread is the hardware thread where the target virtual central processing unit (vCPU) runs on the second DVIC node; wherein the global virtual interrupt identity is allocated by the cluster-level resource management module according to a hierarchical resource allocation strategy, and a mapping relationship between the global virtual interrupt identity and the IMSIC interrupt file entry of the incoming message signal interrupt controller is established locally on each DVIC node. The message construction module is used to construct a cross-chip hardware-level direct injection message based on the interrupt target routing information; The message sending module is used to send the hardware-level direct injection message to the second DVIC node through inter-chip interconnection. The hardware-level direct injection message is written directly into the IMSIC interrupt file by the second DVIC node through hardware logic.

7. A clustered distributed virtual interrupt control device, characterized in that, The device is configured on a second distributed virtual interrupt controller (DVIC) node, and the device includes: The message receiving module is used to receive hardware-level direct injection messages sent by the first DVIC node through inter-chip interconnection. The hardware-level direct injection messages are constructed by the first DVIC node based on interrupt target routing information corresponding to a global virtual interrupt identity. The global virtual interrupt identity is the global virtual interrupt identity mapped by the first DVIC node to the interrupt source associated with the virtual interrupt request within the cluster. The interrupt target routing information is determined as follows: mapping the interrupt source associated with the virtual interrupt request to a global virtual interrupt identity within the cluster; and searching the interrupt routing mapping table based on the global virtual interrupt identity to determine the interrupt target routing information. The interrupt target routing information includes at least the node identifier of the second DVIC node and the thread identifier of the first hardware thread, where the first hardware thread is the hardware thread where the target virtual central processing unit (vCPU) runs on the second DVIC node. The global virtual interrupt identity is allocated by the cluster-level resource management module according to a hierarchical resource allocation strategy, and a mapping relationship between the global virtual interrupt identity and the IMSIC interrupt file entry of the incoming message signal interrupt controller is established locally on each DVIC node. The interrupt writing module is used to write the virtual interrupt directly into the IMSIC interrupt file through hardware logic using the hardware-level direct injection message.

8. A clustered distributed virtual interruption control system, characterized in that, include: Multiple distributed virtual interrupt controller (DVIC) nodes, wherein the multiple DVIC nodes include at least a first DVIC node and a second DVIC node; Wherein, the first DVIC node is configured to perform the method of any one of claims 1-4, and the second DVIC node is configured to perform the method of claim 5.

Images