ARMv8-based virtual machine interrupt straight-through routing method

Abstract

The invention discloses an ARMv8-based virtual machine interrupt through routing method, which comprises the following steps that: a Hypervisor directly routes a physical interrupt to an EL1 through configuration, sets a top page table address of a vCPU (Virtual Central Processing Unit) and a Hypervisor control register at the same time, and sets a vcpudid flag bit for indicating whether the vCPU adopts a virtual interrupt injection mechanism or a physical interrupt through routing mechanism; and judging whether an interrupt through routing condition is met or not so as to determine whether an interrupt through routing mechanism or a virtual interrupt injection mechanism is adopted, periodically judging whether a switching condition is met or not when the interrupt through routing mechanism is adopted, and switching from the interrupt through routing mechanism to the virtual interrupt injection mechanism if the switching condition is met. The method is compatible with two interrupt controller specifications of GICv2 and GICv3, supports the virtual machine and the hypervisor to respectively and independently respond to respective corresponding interrupt requests, and meanwhile, the method has the capability of dynamically switching an interrupt routing mechanism during the system operation period, so that the flexibility of interrupt processing and the expandability of the system are improved.

Description

Technical Field

[0001] The present invention belongs to the technical field of virtual machines, and more specifically, relates to an ARMv8-based virtual machine interrupt direct routing method. Background Art

[0002] Virtualization technology uses software to emulate a hardware platform to create multiple virtual environments, enabling multiple operating systems to run independently on the same physical hardware. Its core concept is to abstract a computer's hardware resources and manage and schedule virtual machines (VMs) through a hypervisor. Virtualization technology is broadly categorized into two types: full virtualization and paravirtualization. Full virtualization simulates the complete hardware environment, enabling unmodified operating systems to run as guests, typically using hardware virtualization extensions to improve performance. Paravirtualization requires modifying the guest operating system so that it can directly interact with the hypervisor, thereby reducing virtualization overhead and improving operational efficiency. Virtualization technology is widely used in data centers, cloud computing, and embedded systems. It not only improves hardware resource utilization but also enhances system flexibility and manageability.

[0003] Interrupts are a critical event handling mechanism that can significantly improve CPU resource utilization and system responsiveness. In an ARMv8 virtualization environment, the hypervisor needs to emulate the interrupt controller to ensure that virtual machines can correctly handle interrupts. The ARMv8 architecture introduces the Generic Interrupt Controller (GIC) to manage interrupts. Taking GICv3 as an example, it defines the following types of interrupts: shared peripheral interrupts (SPIs), private peripheral interrupts (PPIs), software-generated interrupts (SGIs), and local peripheral interrupts (LPIs). Different interrupt types have different interrupt IDs. SGIs typically have IDs ranging from 0 to 15, PPIs from 16 to 31, and SPIs from 32 to N (the value of N is hardware-defined). LPIs are a new interrupt type primarily used for large-scale interrupt management and are often combined with the Interrupt Translation Service (ITS) to support message-based interrupts.

[0004] GICv3 consists of the following key components: the interrupt dispatcher (GICD), the CPU interface (GICC), the virtual CPU interface (GICV), the virtualization control interface (GICH), and the interrupt redistributor (GICR). GICD, as the global interrupt controller, uniformly manages and distributes interrupt handlers (SPIs), and uses a priority arbitration mechanism to prevent multiple processors from responding to the same interrupt simultaneously. GICR manages the current core's PPI, SGI, and LPI, receives SPIs from GICD, and forwards interrupts to GICC based on priority, providing a more flexible interrupt routing strategy. GICC is the interface between physical interrupts and processors, responsible for transmitting and responding to interrupt signals. GICV provides a virtual interrupt handling interface, allowing virtual machines to transparently handle virtual interrupts. GICH is responsible for mapping and injecting virtual interrupts, enabling the hypervisor to efficiently manage the interrupt status and priority of multiple virtual machines.

[0005] As far as optimization solutions for virtual interrupts are concerned, technical personnel in related fields have already proposed some solutions. For example, in the patent number "2021100887138" and the invention name "A method and system for interrupt virtualization processing in the field of ARM architecture virtualization", Zuo Long and others proposed an interrupt virtualization processing method for ARM architecture virtualization. This method unifies the two steps of virtual interrupt collection and virtual interrupt injection at the virtual machine monitor (VMM) layer for processing. The virtualization of external device or virtual device interrupts is completed through the VMM layer, and it is forwarded to the client operating system in the corresponding virtual machine for final processing. Compared with traditional methods, this interrupt virtualization mechanism centrally managed by the VMM has obvious advantages in efficiency.

[0006] In the patent with application number "202311567816.8" and invention name "A virtual interrupt processing method and related products", Yu Bicong and others proposed a virtual interrupt processing mechanism. After receiving the first physical interrupt signal, the system first switches from the first working mode to the second working mode. In the second working mode, the system sets the state of the first virtual interrupt corresponding to the first physical interrupt to the preset state. When the state of the first virtual interrupt reaches the preset state, the system switches directly from the second working mode to the first virtual mode and executes the first virtual interrupt. Through this design, the steps of switching from the second working mode to the first working mode and then switching to the first interrupt mode in the traditional scheme are omitted, thereby reducing the overall time consumption and system resource consumption in the virtual interrupt processing process, and improving the processing efficiency of the system.

[0007] In the paper "Gordon, A., Amit, N., Har'El, N., Ben-Yehuda, M., Landau, A., Schuster, A., & Tsafrir, D. (2012). ELI: Bare-metal performance for I / O virtualization. ACM SIGPLAN Notices, 47(4), 411-422.", Abel Gordon et al. proposed the ELI (Exitless Interrupts) mechanism, which was optimized for SR-IOV devices and integrated into the KVM hypervisor to eliminate the VM exit overhead of virtual interrupt processing in traditional virtualization environments. The core idea of ​​ELI is to enable physical interrupts to be directly delivered to virtual machines by using a shadow interrupt descriptor table (Shadow IDT), avoiding the intervention of the hypervisor and thus eliminating the additional overhead caused by context switching and cache pollution. In addition, ELI also introduces interrupt completion technology to optimize the injection and processing of virtual interrupts to ensure both system security and efficiency. Experimental results show that the ELI mechanism brings I / O performance close to the bare metal level (97%-100%), significantly reduces interrupt processing latency, and effectively improves throughput and response speed in virtualized environments.

[0008] In the paper "Tu, CC, Ferdman, M., Lee, CT, & Chiueh, TC (2015). A comprehensive implementation and evaluation of direct interrupt delivery. Acm Sigplan Notices, 50(7), 1-15.", Cheng-Chun Tu et al. proposed the DID (Direct Interrupt Delivery) method, which aims to optimize the interrupt handling mechanism in a virtualized environment and be compatible with SR-IOV devices and paravirtualized I / O devices. For interrupts from SR-IOV devices, DID avoids unnecessary virtual machine exits by clearing the external interrupt exit EIE bit in the virtual machine control structure VMCS, and implements direct interrupt delivery through the IOMMU's interrupt remapping table IRT. At the same time, it dynamically adjusts the interrupt target CPU core to improve interrupt handling efficiency. For virtual interrupts from paravirtualized devices, DID introduces the inter-processor interrupt IPI mechanism to reduce the VM exit overhead during the virtual interrupt injection process.

[0009] Based on the above existing technologies, research on virtual interrupt optimization in the ARM architecture is still in its early stages, and most existing research solutions still rely on the frequent intervention of the hypervisor in the virtual interrupt processing process, otherwise a relatively complex software conversion mechanism would be required. While virtual interrupt optimization solutions based on the x86 architecture have achieved relatively mature research results in theory and practice, the architectural differences between ARM and x86, particularly ARM's lack of complex hardware acceleration mechanisms such as PostedInterrupt and APICv, make x86-based optimization solutions, while useful as design references, difficult to directly migrate to the ARM architecture. Summary of the Invention

[0010] The present invention aims to overcome the shortcomings of the existing technology in terms of interrupt handling mechanisms. It proposes a direct routing method for virtual machine interrupts based on the ARMv8 architecture. The method is compatible with both GICv2 and GICv3 interrupt controller specifications, allowing virtual machines and hypervisors to independently respond to their respective interrupt requests. At the same time, the method has the ability to dynamically switch interrupt routing mechanisms during system operation, thereby improving the flexibility of interrupt handling and the scalability of the system.

[0011] In order to achieve the above-mentioned object of the invention, the present invention provides a virtual machine interrupt direct routing method based on ARMv8, comprising the following steps:

[0012] S1: First, the hypervisor is configured to route physical interrupts directly to EL1 by extending the vCPU thread context. The specific method is as follows:

[0013] 1) Page table address setting: When the ARM architecture adopts the GICv2 architecture, each vCPU stores two sets of top-level page table addresses, namely the virtual memory two-stage translation zero-level page table base address vttbr of the virtual interrupt injection mechanism and the virtual memory two-stage translation zero-level page table base address vttbr_did of the interrupt direct routing mechanism; in the virtual interrupt injection mechanism, the hypervisor maps the intermediate physical address IPA of the CPU interface GICC register to the host physical address HPA of the virtual CPU interface GICV register; in the interrupt direct routing mechanism, the hypervisor maps the IPA of the GICC register to the host physical address HPA of the virtual CPU interface GICV register. The PA address is mapped to the HPA address of the GICC register. When the ARM architecture adopts the GICv3 architecture, each vCPU saves the virtual memory two-stage translation zero-level page table base address vttbr of the virtual interrupt injection mechanism, and the hypervisor maps the IPA address of the GICC register to the HPA address of the GICV register. In the interrupt direct routing mechanism, the hypervisor implements interrupt routing control by configuring the HCR_EL2.IMO and HCR_EL2.AMO bits in the virtualization configuration control register HCR_EL2, transparently controlling the virtual machine to directly access the GICC or GICV.

[0014] 2) Register Configuration: Each vCPU stores and manages two sets of hypervisor control registers: the hypervisor control register hcr for the virtual interrupt injection mechanism and the hypervisor control register hcr_did for the interrupt direct routing mechanism. In the virtual interrupt injection mechanism, the vCPU uses hcr to set HCR_EL2.IMO and HCR_EL2.AMO to 1, routing all interrupts to EL2 for unified processing by the virtualization layer. In the interrupt direct routing mechanism, the vCPU uses hcr_did to set HCR_EL2.IMO and HCR_EL2.AMO to 0, routing physical interrupts to EL1, allowing the virtual machine to directly handle the interrupt signal.

[0015] 3) Flag setting: Each vCPU sets the vcpu_did flag to indicate the interrupt mechanism used by the vCPU;

[0016] S2: Determine whether the current virtual machine meets the interrupt direct routing condition. If yes, proceed to step S3; otherwise, proceed to step S9.

[0017] S3: The virtual machine directly handles the physical interrupt at the EL1 level. It first reads the interrupt identification register to determine the source of the physical interrupt. If the physical interrupt is a hypervisor interrupt, it proceeds to step S4; otherwise, it proceeds to step S5.

[0018] S4: The virtual machine initiates a Hypercall and passes the corresponding interrupt number to the hypervisor. The vCPU is temporarily suspended and control is switched to the hypervisor. After the hypervisor completes the relevant interrupt processing according to the received interrupt number, control is returned to the virtual machine, and the virtual machine then performs internal interrupt context recovery.

[0019] S5: The vCPU responds to the interrupt directly at EL1 and executes the corresponding interrupt service routine;

[0020] S6: Determine whether the interrupt routing mechanism switching judgment period has been reached. If so, proceed to step S7; otherwise, return to step S3.

[0021] S7: Determine whether the switching condition is met, that is, whether the current virtual machine no longer meets the direct routing condition. If the switching condition is met, proceed to step S8; otherwise, proceed back to step S3;

[0022] S8: The hypervisor globally configures the virtual general interrupt controller vGIC based on the current general interrupt controller GIC status and simultaneously updates the vGIC status. The specific method is as follows:

[0023] Hypervisor adjusts the interrupt end mode EOImode to support the virtualized interrupt process, that is, setting GICC_CTLR.EOImode / ICC_CTLR.EOImode to 1;

[0024] The virtual machine reads the key GICC register status associated with the vCPU running thread, including the interrupt control register GICC_CTLR / ICC_CTLR, the priority mask register GICC_PMR_EL1 / ICC_PMR_EL1, and the active priority register GICC_APRn / ICC_AP1R <n>_EL1, saves these register values ​​to the interrupt configuration context associated with the vCPU thread;

[0025] The Hypervisor sets vcpu_did to false, indicating that the current vCPU no longer directly handles physical interrupts. When the vCPU resumes context, all physical interrupts are configured to be routed to EL2 and handled by the Hypervisor.

[0026] The hypervisor parses the interrupt type and target and re-injects the interrupt as a virtual interrupt. The target vCPU receives and processes the virtual interrupt at EL1. The specific method is as follows:

[0027] The hypervisor extracts the interrupt status information of the target vCPU from the GIC, identifies the interrupts associated with the current vCPU that are in the Pending, Active, or Active and Pending states, and constructs these interrupts into a set of interrupts to be injected.

[0028] The hypervisor analyzes the physical interrupt status in the interrupt set to be injected through status comparison and priority parsing, determines the events that need to be mapped as virtual interrupts, and maps them into virtual interrupts. It then updates the virtual interrupt structure information based on the currently active virtual interrupt information and injects the virtual interrupt into the target vCPU through the list registers LRs. The target vCPU receives and completes the virtual interrupt processing at EL1.

[0029] S9: In this state, all interrupts are routed to EL2. After being captured by the Hypervisor, the interrupt belonging to the virtual machine is injected into the virtual machine through virtual interrupt injection, and the virtual machine processes the injected interrupt.

[0030] The present invention is based on an ARMv8-based virtual machine interrupt direct routing method. The hypervisor is configured to route physical interrupts directly to EL1. At the same time, the top-level page table address of the vCPU and the hypervisor configuration register are set, and the vcpu_did flag is set to indicate whether the vCPU adopts a virtual interrupt injection mechanism or a physical interrupt direct routing mechanism. Whether the interrupt direct routing condition is met is judged to determine whether the interrupt direct routing mechanism or the virtual interrupt injection mechanism is adopted. When the interrupt direct routing mechanism is adopted, it is periodically judged whether a switching condition is met. If so, the interrupt direct routing mechanism is switched to the virtual interrupt injection mechanism.

[0031] The present invention has the following beneficial effects:

[0032] 1) Support for virtual machine and hypervisor interrupt processing: The present invention can support interrupt processing at the virtual machine and hypervisor layers while directly routing interrupts to the virtual machine. This feature ensures the efficiency and consistency of the virtualization system when handling interrupts at different levels, improving the flexibility and adaptability of the system.

[0033] 2) Compatibility with two interrupt controller architectures: By extending the context information of vCPU threads, this mechanism is compatible with both GICv2 and GICv3 interrupt controller architectures;

[0034] 3) Dynamically switching interrupt routing mechanisms: This invention supports the hypervisor to dynamically switch the interrupt handling mechanism at the vCPU granularity. This not only enables it to adapt to more diverse application scenarios, but also strengthens the hypervisor's security control over the vCPU under the interrupt direct routing mechanism, improving the manageability and security of the system.

[0035] 4) Simplified hardware requirements: The present invention relies only on the basic functions of the GIC and does not require additional cooperation from other interrupt-related hardware, which simplifies the system architecture, reduces hardware overhead, and reduces system complexity and cost. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 This is a flowchart of a specific implementation of the ARMv8-based virtual machine interrupt direct routing method of the present invention;

[0037] Figure 2 It is a schematic diagram of processing physical interruption in the present invention;

[0038] Figure 3 This is a flow chart of how virtual machines complete inter-core communication through SGI under the interrupt direct routing mechanism in this embodiment. DETAILED DESCRIPTION

[0039] The following describes the specific embodiments of the present invention in conjunction with the accompanying drawings so that those skilled in the art can better understand the present invention. It should be noted that in the following description, when detailed descriptions of known functions and designs may dilute the main content of the present invention, such descriptions will be omitted here.

[0040] Example

[0041] Figure 1 This is a flow chart of a specific implementation of the virtual machine interrupt direct routing method based on ARMv8 of the present invention. Figure 1 As shown, the virtual machine interrupt direct routing method based on ARMv8 of the present invention includes the following steps:

[0042] S101: Hypervisor Configuration:

[0043] Given that most physical interrupts running on a physical CPU core are usually handled by the virtual machine executing on that core, in the present invention, the hypervisor is configured to route physical interrupts directly to EL1, allowing the virtual machine to directly respond to and handle interrupt events. This solution can effectively reduce the context switching overhead caused by hypervisor intervention, thereby improving interrupt response efficiency.

[0044] In order to support the direct interrupt routing mechanism and allow dynamic switching of the interrupt routing mechanism at the vCPU thread granularity, it is necessary to extend two independent configurations for each vCPU thread context to adapt to the virtual interrupt injection mechanism and the direct interrupt routing mechanism respectively. The extension of the vCPU thread context in this invention mainly includes the second-stage mapping address, control register and interrupt routing mechanism flag. The specific method is as follows:

[0045] 1) Page table address setting:

[0046] When the ARM architecture uses GICv2, each vCPU maintains two sets of top-level page table addresses: vttbr, the virtual memory two-stage translation zero-level page table base address for the virtual interrupt injection mechanism, and vttbr_did, the virtual memory two-stage translation zero-level page table base address for the direct interrupt routing mechanism (where "did" stands for Direct Interrupt Delivery). The primary difference in page table information between these two sets lies in the mapping of the virtual machine's GICC address (IPA). In the virtual interrupt injection mechanism, the vCPU is responsible for receiving and processing virtual interrupts. In this case, the hypervisor maps the intermediate physical address (IPA) of the CPU interface's GICC register to the host physical address (HPA) of the virtual CPU interface's GICV register, completing two-stage address translation in the virtualized environment. In the direct interrupt routing mechanism, the vCPU directly receives and processes physical interrupts. In this case, the hypervisor maps the GICC register's IPA address to the GICC register's HPA address, enabling direct access to the GICC by the virtual machine.

[0047] When the ARM architecture adopts the GICv3 architecture, since GICv3 supports register access to GICC and GICV, the need to save the top-level page table address vttbr_did in the interrupt direct routing mechanism is reduced. The vCPU only needs to save the virtual memory two-stage translation zero-level page table base address vttbr of the virtual interrupt injection mechanism, and the hypervisor maps the IPA address of the GICC register to the HPA address of the GICV register; in the interrupt direct routing mechanism, the hypervisor implements interrupt routing control by configuring the HCR_EL2.IMO and HCR_EL2.AMO bits in the virtualization control register HCR_EL2, transparently controlling the virtual machine's access to GICC or GICV, so there is no need to additionally save the page table base address, thereby avoiding the reliance on the IPA address of the GICC register for two-stage address mapping.

[0048] 2) Register configuration:

[0049] Each vCPU also stores and manages two sets of Hypervisor control registers (HCR_EL2) to support different interrupt handling mechanisms: the Hypervisor Control Register (hcr) for the virtual interrupt injection mechanism and the Hypervisor Control Register (hcr_did) for the direct interrupt routing mechanism. In the virtual interrupt injection mechanism, the vCPU uses hcr to set HCR_EL2.IMO and HCR_EL2.AMO to 1, routing all interrupts to EL2 for unified processing by the virtualization layer. In the direct interrupt routing mechanism, the vCPU uses hcr_did to set HCR_EL2.IMO and HCR_EL2.AMO to 0, routing physical interrupts to EL1, allowing the virtual machine to directly handle the interrupt signal.

[0050] 3) Flag setting:

[0051] Each vCPU sets the vcpu_did flag to indicate the interrupt mechanism used by the vCPU.

[0052] S102: Determine whether the current virtual machine meets the cut-through interrupt routing conditions. If so, proceed to step S103; otherwise, proceed to step S109. The cut-through routing conditions can be determined based on actual needs. In this embodiment, the current vCPU must exclusively occupy the physical CPU and the number of interrupts belonging to the virtual machine on the current physical CPU must be greater than a preset threshold. If these two requirements are met, the current application scenario requires more efficient vCPU operation, making the cut-through interrupt routing mechanism more suitable.

[0053] S103: Determine the type of physical interruption:

[0054] To ensure that the hypervisor can correctly handle its own interrupt requests, the present invention introduces a certain degree of paravirtualization support. That is, under the interrupt direct routing mechanism, the virtual machine directly handles physical interrupts at the EL1 level, first reading the interrupt identification register (such as GICC_IAR or ICC_IAR) to obtain the interrupt number, and then determining the source of the physical interrupt. If the physical interrupt is a hypervisor interrupt, proceed to step S104; otherwise, proceed to step S105.

[0055] S104: Hypervisor interrupt processing:

[0056] If the current physical interrupt is a hypervisor interrupt, the virtual machine initiates a Hypercall, passing the corresponding interrupt number to the hypervisor. The vCPU is temporarily suspended, and control is transferred to the hypervisor. After the hypervisor completes the interrupt processing based on the received interrupt number, control returns to the virtual machine, which then restores its internal interrupt context.

[0057] S105: Virtual machine interrupt processing:

[0058] When the physical interrupt belongs to the virtual machine itself, the vCPU responds to the interrupt directly at EL1 and executes the corresponding interrupt service routine.

[0059] Figure 2 This is a schematic diagram of the processing of physical interruption in the present invention. Figure 2 As shown in the figure, when a physical interrupt is a hypervisor interrupt, control must be transferred to the hypervisor for processing, requiring the virtual machine to interact with the hypervisor. However, when a physical interrupt is a virtual machine interrupt, the virtual machine does not need to interact with the hypervisor, further reducing interrupt processing latency. As can be seen, by determining the source of physical interrupts, the correct interrupt distribution and processing mechanism can be ensured, thereby improving interrupt processing efficiency.

[0060] Among the interrupts of the virtual machine itself, common interrupts include peripheral interrupts and software-generated interrupts. This embodiment proposes a specific interrupt direct routing solution for these two types of interrupts.

[0061] In the ARMv8 architecture, GIC peripheral interrupts primarily include shared peripheral interrupts (SPIs) and private peripheral interrupts (PPIs). SPIs are suitable for peripherals shared by multiple CPUs, while PPIs are processed only on specific CPUs. In a virtualized environment, traditional peripheral interrupt processing requires the hypervisor to capture interrupts and then inject them into the virtual machine, increasing interrupt processing latency. However, the present invention utilizes a direct interrupt routing mechanism, routing peripheral interrupts directly to the virtual machine, reducing the number of hypervisor interventions, thereby optimizing I / O response time and improving system real-time performance.

[0062] SPI is primarily used for passthrough devices (such as serial ports, network devices, and discrete graphics cards), enabling virtual machines to interact directly with peripherals without the need for hypervisor emulation. In the interrupt passthrough routing mechanism, through GIC configuration, SPI interrupts are routed directly to the target vCPU's EL1 exception context, where the VM kernel handles the interrupt request autonomously. This reduces interrupt processing latency and improves system real-time performance and efficiency. It's important to note that with traditional virtual interrupt injection, when a device interrupt triggers but the target vCPU is not running, the hypervisor must first capture and forward the interrupt, which can introduce additional interrupt processing latency. In contrast, with the interrupt passthrough routing mechanism, since the vCPU exclusively uses the physical CPU, which only runs the guest operating system code and some hypervisor code, there's no need for additional interrupt forwarding. Furthermore, this project doesn't support interrupt nesting. When the target vCPU thread is paused, the physical CPU won't handle other peripheral interrupts, eliminating the hypervisor's overhead of interrupt forwarding and ensuring deterministic and real-time interrupt processing.

[0063] The direct routing mechanism of PPI interrupts is similar to the implementation principle of SPI. The difference is mainly reflected in the usage scenarios and management details of virtual machine clock interrupts, that is, it mainly involves virtual machine clock interrupts. The clock interrupt of the virtual machine may be affected by time drift during operation, which is mainly due to the suspension operation of the vCPU (for example, due to resource competition, thread switching or manual suspension). This drift will cause the clock in the virtual machine to be inconsistent with the actual time, thereby affecting the accuracy of time-sensitive tasks. To solve this problem, the ARM architecture provides a CNTVOFF register for offsetting the error caused by time drift in the internal clock of the virtual machine. Based on this mechanism, in this embodiment, the virtual machine preferably uses a virtual clock interrupt (interrupt 27) as its clock source. Between each vCPU suspension and resumption, the hypervisor will dynamically calculate the corresponding time drift and write the value to the corresponding CNTVOFF register to ensure that the virtual machine's clock can accurately reflect the actual time process. For the operation of virtual clock-related registers, two implementation schemes are proposed in this embodiment, which are respectively adapted to different application requirements and implementation conditions.

[0064] 1) Method without modifying the guest operating system driver source code: In this method, to support virtualization, the hypervisor configures the HCR_EL2 bits, causing all virtual machine accesses to the EL1 physical clock registers to trigger an exception and fall through to EL2. The hypervisor then emulates the access logic for the virtual clock-related registers, providing transparent virtual clock support for the virtual machine. This method does not require extensive changes to the guest operating system's clock driver source code and offers high compatibility. However, the high frequency of hypervisor involvement may introduce some performance loss.

[0065] 2) Method of modifying the client operating system driver source code: In this method, the virtual machine's access to the EL1 physical clock register is redirected to access to the virtual clock register by modifying the client operating system clock driver source code. At the same time, the Hypervisor configures the relevant bits of the HCR_EL2 register to ensure that when the virtual machine accesses the virtual clock register in the EL1 abnormal state, it will not trigger an exception to fall to EL2. The Hypervisor only needs to update the value of the CNTVOFF register when the vCPU thread is suspended and resumed. In most cases, there is no need to intervene in the virtual machine's operation on the clock register. This method reduces performance overhead by reducing the frequency of Hypervisor participation, but requires changes to the client operating system's clock driver source code. It is suitable for scenarios with high performance requirements and where source code changes are allowed.

[0066] In the ARM architecture virtualization environment, software-generated interrupts (SGIs) are mainly used in two key scenarios: first, SGIs support inter-core communication between virtual machines, allowing vCPUs to efficiently trigger and process interrupts, thereby optimizing the parallel computing capabilities within the virtual machine and reducing communication latency in a multi-vCPU environment to meet the task scheduling and load balancing requirements of the virtualization system; second, SGIs play an important role in virtual device interrupt management, allowing precise control of virtual device interrupt event routing in a software-programmable manner, enabling the hypervisor to efficiently pass virtual device interrupt events to the target vCPU, thereby reducing interrupt processing overhead and optimizing the I / O performance of virtual devices. Figure 3 This is a flow chart of the virtual machine completing inter-core communication through SGI under the interrupt direct routing mechanism in this embodiment. Figure 3 As shown in the figure, the process of virtual machines completing inter-core communication through SGI under the interrupt direct routing mechanism includes:

[0067] 1) Initiation of IPI request: vCPU n initiates an inter-processor interrupt (IPI) request to vCPU m. At this time, the GIC driver of the virtual machine will try to write to the corresponding software-generated interrupt register (SGIR) to trigger an inter-core interrupt.

[0068] 2) Exception handling: This operation triggers an exception, causing the execution flow to fall into EL2 and be handled by the Hypervisor simulation. During this period, the operation of vCPU n is suspended.

[0069] 3) Hypervisor Simulation and Hardware Operation: The hypervisor interprets the virtual machine's write request to the SGIR, updates the corresponding state based on the request, and writes data to the hardware SGIR, triggering an inter-core interrupt between physical cores. After the operation is complete, vCPU n resumes operation.

[0070] 4) Interrupt reception and processing: vCPU m directly receives the inter-core interrupt signal at EL1 and completes the corresponding interrupt processing operation.

[0071] Steps 1-3 are executed on CPU core y, while step 4 is completed on CPU core x.

[0072] In the direct interrupt routing solution, each inter-core interrupt triggering only involves pausing and resuming the source vCPU thread, effectively reducing the need for pausing and resuming the target vCPU thread and the frequent transitions to abnormal states. Furthermore, the target vCPU thread can directly receive and process physical SGIs at EL1 without pausing execution, avoiding the virtual interrupt structure management and hardware operation costs introduced by vSGI injection in virtualized environments. This mechanism significantly optimizes the processing efficiency of inter-core interrupts while reducing the complexity and performance overhead of interrupt management in virtualized environments.

[0073] It should be emphasized that in the interrupt direct routing mechanism, the source vCPU's read and write operations on the SGIR still need to be captured and parsed by the hypervisor. For example, when there is a specific mapping relationship between the vCPU identification ID and the pCPU identification ID, the hypervisor needs to intercept and parse the virtual machine's write request to the SGIR, and adjust the targetlist field of the target core according to the encoding conversion rules between the vCPU and the pCPU. The converted information is then written to the hardware SGIR to ensure that the software interrupt of the target core can be correctly triggered and processed. This mechanism ensures the correctness of interrupt communication across vCPUs under the direct routing mechanism, while avoiding interrupt anomalies caused by mismatched target core selection. The specific implementation method is slightly different for GICv2 and GICv3.

[0074] In the GICv2 architecture, SGI triggering relies on the hardware register GICD_SGIR, which is accessed through address access. In this embodiment, the second-stage address mapping of the hardware register GICD_SGIR is omitted. This triggers an exception when the virtual machine accesses GICD_SGIR, causing the execution flow to fall into EL2. The hypervisor then simulates the virtual machine's write request to SGIR.

[0075] In the GICv3 architecture, SGI triggering relies on the system registers ICC_SGI1R_EL1 and ICC_SGI0R_EL1. ICC_SGI1R_EL1 is used for SGIs routed to EL1 or EL2, while ICC_SGI0R_EL1 is used for SGIs routed to EL3. In a configuration where all interrupts are routed to EL1, virtual machines accessing these registers generally do not trigger an exception entry into EL2. To address this GICv3 feature and support the aforementioned inter-core communication mechanism, the following two solutions are available:

[0076] 1. Fixed ID mapping: The hypervisor keeps the vCPU ID consistent with the corresponding pCPU ID to avoid additional ID translation.

[0077] 2. Modify the guest operating system driver: Adjust the virtual machine GIC driver so that it directly adapts to the ID mapping relationship between vCPU and pCPU set by the hypervisor, thereby ensuring that the virtual machine can correctly configure and handle interrupts of the target core.

[0078] Both solutions can adapt to the special needs of inter-core interrupts in the GICv3 environment, and provide a flexible implementation approach to improve the performance and accuracy of inter-core communication in a virtualized environment.

[0079] To fully exploit the parallelism between physical I / O device operations and virtual machine execution, modern hypervisors (such as KVM) typically employ device thread separation, allocating a separate thread to each virtual device associated with a VM. These virtual device threads typically run on a separate CPU core from the VM's own vCPU, thereby improving system concurrency and resource utilization efficiency while reducing the vCPU's overhead in processing I / O events.

[0080] Because device threads send interrupt notifications to vCPUs via SGIs, the client operating system code can be modified under the direct interrupt routing scheme to ensure that the interrupt number used to handle virtual devices within the virtual machine matches the SGI interrupt number triggered by the hypervisor device thread. Specifically, a mapping relationship between virtual device interrupt numbers and SGI interrupt numbers should be established in the virtual machine's interrupt control mechanism. This ensures that when the hypervisor device thread triggers an SGI, the virtual machine can correctly interpret and respond to the corresponding device interrupt event, thereby ensuring the accuracy of interrupt delivery and the correctness of device I / O processing.

[0081] S106: Determine whether the interrupt routing mechanism switching determination period has been reached. If so, proceed to step S107; otherwise, return to step S103.

[0082] S107: Determine whether the switching condition has been met, that is, whether the current virtual machine no longer meets the cut-through routing condition. If the switching condition has been met, proceed to step S108; otherwise, proceed back to step S103. In this embodiment, if the exclusive scenario is broken, for example, when a single physical CPU needs to support multiple vCPUs or vCPU migration occurs, the cut-through routing condition is no longer met, and the cut-through routing mechanism is no longer applicable.

[0083] S108: Interrupt routing mechanism switching:

[0084] The Hypervisor globally configures the virtual GIC based on the current GIC status and updates the vGIC status synchronously. The specific method is as follows:

[0085] The Hypervisor adjusts the interrupt end mode EOImode to support the virtualized interrupt process: set the GICC_CTLR.EOImode / ICC_CTLR.EOImode position to 1. In this mode, the degradation and deactivation of the interrupt are divided into two independent stages to ensure the effective conversion and management of the physical interrupt state.

[0086] During the interrupt handling mechanism switching process, the virtual machine needs to obtain and store the GICC key state related to the current conversion vCPU thread to ensure that the interrupt handling can be correctly restored and continued after the switch. Specifically, the virtual machine needs to read the GICC key register state associated with the vCPU thread, including the interrupt control register GICC_CTLR / ICC_CTLR, the priority mask register GICC_PMR_EL1 / ICC_PMR_EL1 and the active priority register GICC_APRn / ICC_AP1R <n>_EL1. These register values ​​are saved to the interrupt configuration context related to the vCPU thread, so that when the vCPU thread resumes running, the GICV can be correctly configured according to the previous interrupt status, thereby ensuring the consistency of the interrupt delivery and processing mechanism.

[0087] The Hypervisor sets vcpu_did to false, indicating that the current vCPU no longer directly handles physical interrupts. When the vCPU restores the context, all physical interrupts are configured to be routed to EL2 and taken over by the Hypervisor.

[0088] Interrupt processing is performed under the virtual interrupt injection mechanism. That is, the hypervisor analyzes the interrupt type and target and re-injects the interrupt as a virtual interrupt. The target vCPU receives and completes the virtual interrupt processing at EL1. During this process, the hypervisor accurately identifies and restores the interrupt status associated with the current vCPU to ensure the continuity and correctness of interrupt processing. The specific method is:

[0089] The hypervisor extracts the interrupt status information of the target vCPU from the GIC, identifies interrupts associated with the current vCPU that are in the Pending, Active, or Active and Pending states, and constructs these interrupts into a set of interrupts to be injected. This interrupt identification ensures that uncompleted interrupts are correctly delivered during the handover process, avoiding interrupt loss or processing delays, thereby maintaining the semantic consistency of interrupt processing for the vCPU.

[0090] On this basis, the hypervisor analyzes the physical interrupt status in the set of interrupts to be injected through status comparison and priority parsing, determines the events that need to be mapped as virtual interrupts, and maps them as virtual interrupts. Then, based on the currently active virtual interrupt information, it updates the virtual interrupt structure information and injects the virtual interrupt into the target vCPU through the list registers LRs. The target vCPU receives and completes the virtual interrupt processing at EL1. Through this mechanism, the virtual machine can accurately perceive and respond to related interrupt events according to the established interrupt processing process after the vCPU resumes operation, thereby ensuring the consistency of interrupt processing in the virtualized environment and improving the real-time performance and stability of the system.

[0091] S109: Virtual interrupt injection:

[0092] In this state, all interrupts are routed to EL2. After being captured by the Hypervisor, the interrupts belonging to the virtual machine are injected into the virtual machine through virtual interrupt injection, and the virtual machine processes the injected interrupts.

[0093] While the foregoing specific embodiments of the application have been described in some detail to provide a clear understanding thereof, it will be apparent to those of ordinary skill in the art that numerous modifications can be made to the specific embodiments described without departing from the spirit and scope of the application defined by the appended claims.< / n> < / n>

Claims

1. A virtual machine interrupt direct routing method based on ARMv8, characterized in that: The following steps are involved: S1: First, the hypervisor is configured to route physical interrupts directly to EL1 by extending the vCPU thread context. The specific method is as follows: 1) Page table address setting: When the ARM architecture adopts the GICv2 architecture, each vCPU stores two sets of top-level page table addresses, namely the virtual memory two-stage translation zero-level page table base address vttbr of the virtual interrupt injection mechanism and the virtual memory two-stage translation zero-level page table base address vttbr_did of the interrupt direct routing mechanism; in the virtual interrupt injection mechanism, the hypervisor maps the intermediate physical address IPA of the CPU interface GICC register to the host physical address HPA of the virtual CPU interface GICV register; in the interrupt direct routing mechanism, the hypervisor maps the IPA of the GICC register to the host physical address HPA of the virtual CPU interface GICV register. The PA address is mapped to the HPA address of the GICC register. When the ARM architecture adopts the GICv3 architecture, each vCPU saves the virtual memory two-stage translation zero-level page table base address vttbr of the virtual interrupt injection mechanism, and the hypervisor maps the IPA address of the GICC register to the HPA address of the GICV register. In the interrupt direct routing mechanism, the hypervisor implements interrupt routing control by configuring the HCR_EL2.IMO and HCR_EL2.AMO bits in the virtualization configuration control register HCR_EL2, transparently controlling the virtual machine to directly access the GICC or GICV. 2) Register Configuration: Each vCPU stores and manages two sets of hypervisor control registers: the hypervisor control register hcr for the virtual interrupt injection mechanism and the hypervisor control register hcr_did for the interrupt direct routing mechanism. In the virtual interrupt injection mechanism, the vCPU uses hcr to set HCR_EL2.IMO and HCR_EL2.AMO to 1, routing all interrupts to EL2 for unified processing by the virtualization layer. In the interrupt direct routing mechanism, the vCPU uses hcr_did to set HCR_EL2.IMO and HCR_EL2.AMO to 0, routing physical interrupts to EL1, allowing the virtual machine to directly handle the interrupt signal. 3) Flag setting: Each vCPU sets the vcpu_did flag to indicate the interrupt mechanism used by the vCPU; S2: Determine whether the current virtual machine meets the interrupt direct routing condition. If yes, proceed to step S3; otherwise, proceed to step S9. S3: The virtual machine directly handles the physical interrupt at the EL1 level. It first reads the interrupt identification register to determine the source of the physical interrupt. If the physical interrupt is a hypervisor interrupt, it proceeds to step S4; otherwise, it proceeds to step S5. S4: The virtual machine initiates a Hypercall and passes the corresponding interrupt number to the hypervisor. The vCPU is temporarily suspended and control is switched to the hypervisor. After the hypervisor completes the relevant interrupt processing according to the received interrupt number, control is returned to the virtual machine, and the virtual machine then performs internal interrupt context recovery. S5: The vCPU responds to the interrupt directly at EL1 and executes the corresponding interrupt service routine; S6: Determine whether the interrupt routing mechanism switching judgment period has been reached. If so, proceed to step S7; otherwise, return to step S3. S7: Determine whether the switching condition is met, that is, whether the current virtual machine no longer meets the direct routing condition. If the switching condition is met, proceed to step S8; otherwise, proceed back to step S3; S8: The hypervisor globally configures the virtual general interrupt controller vGIC based on the current general interrupt controller GIC status and simultaneously updates the vGIC status. The specific method is as follows: Hypervisor adjusts the interrupt end mode EOImode to support the virtualized interrupt process, that is, setting GICC_CTLR.EOImode / ICC_CTLR.EOImode to 1; The virtual machine reads the key GICC register status associated with the vCPU running thread, including the interrupt control register GICC_CTLR / ICC_CTLR, the priority mask register GICC_PMR_EL1 / ICC_PMR_EL1, and the active priority register GICC_APRn / ICC_AP1R <n> _EL1, saves these register values ​​to the interrupt configuration context associated with the vCPU thread;< / n> The Hypervisor sets vcpu_did to false, indicating that the current vCPU no longer directly handles physical interrupts. When the vCPU resumes context, all physical interrupts are configured to be routed to EL2 and handled by the Hypervisor. The hypervisor parses the interrupt type and target and re-injects the interrupt as a virtual interrupt. The target vCPU receives and processes the virtual interrupt at EL1. The specific method is as follows: The hypervisor extracts the interrupt status information of the target vCPU from the GIC, identifies the interrupts associated with the current vCPU that are in the Pending, Active, or Active and Pending states, and constructs these interrupts into a set of interrupts to be injected. The hypervisor analyzes the physical interrupt status in the interrupt set to be injected through status comparison and priority analysis, determines the events that need to be mapped as virtual interrupts, and maps them to virtual interrupts; Then, based on the currently active virtual interrupt information, the virtual interrupt structure information is updated, and the virtual interrupt is injected into the target vCPU through the list register LRs. The target vCPU receives and completes the processing of the virtual interrupt at EL1; S9: In this state, all interrupts are routed to EL2. After being captured by the Hypervisor, the interrupt belonging to the virtual machine is injected into the virtual machine through virtual interrupt injection, and the virtual machine processes the injected interrupt.

2. The ARMv8-based virtual machine interrupt direct routing method according to claim 1, characterized in that: The direct routing condition is set as whether a single vCPU in the virtual machine exclusively occupies the physical CPU and the number of interrupts belonging to the virtual machine on the current physical CPU is greater than a preset threshold.

3. The ARMv8-based virtual machine interrupt direct routing method according to claim 1, characterized in that: When the physical interrupt is a shared peripheral interrupt SPI, the virtual machine directly responds to the interrupt.

4. The ARMv8-based virtual machine interrupt direct routing method according to claim 1, wherein: When the physical interrupt is a private peripheral interrupt (PPI), it mainly involves the virtual machine clock interrupt. The virtual machine uses the EL1 virtual clock interrupt as its clock source. At the same time, select one of the following two methods for configuration based on the actual scenario: (1) Method without modifying the client operating system driver source code: The hypervisor configures the relevant bits of HCR_EL2 so that all virtual machine accesses to the EL1 physical clock registers trigger an exception and fall to EL2. The hypervisor simulates the access logic of the virtual clock related registers, thereby providing transparent virtual clock support for the virtual machine; (2) Modify the client operating system driver source code method: redirect the virtual machine's access to the EL1 physical clock register to access the virtual clock register; at the same time, the hypervisor configures the relevant bits of the HCR_EL2 register to ensure that when the virtual machine accesses the virtual clock register in the EL1 abnormal state, it will not trigger an abnormal fall to EL2; the hypervisor only needs to update the value of the CNTVOFF register when the vCPU thread is suspended and resumed.

5. The ARMv8-based virtual machine interrupt direct routing method according to claim 1, wherein: When the physical interrupt is a software-generated interrupt SGI, the virtual machine implements inter-core communication through the SGI interrupt. The specific method is as follows: 1) vCPU n initiates an inter-processor interrupt (IPI) request to vCPU m. At this time, the virtual machine's GIC driver attempts to write to the corresponding software-generated interrupt register (SGIR) to trigger an inter-core interrupt. 2) This operation triggers an exception, causing the execution flow to fall into EL2 and be handled by the hypervisor simulation. During this period, the operation of vCPUn is suspended; 3) The hypervisor parses the virtual machine's write request to the SGIR, updates the corresponding state based on the request content, and writes data to the hardware SGIR, thereby triggering an inter-core interrupt between physical cores; after the operation is completed, vCPU n resumes operation; 4) vCPU m directly receives the inter-core interrupt signal at EL1 and completes the corresponding interrupt processing operation.

6. The ARMv8-based virtual machine interrupt direct routing method according to claim 5, characterized in that: When the ARM architecture uses the GICv2 architecture, the address of the hardware register GICD_SGIR is not mapped in the second stage, which triggers an exception when the virtual machine accesses GICD_SGIR, causing the execution flow to fall into EL2. The hypervisor is responsible for simulating the virtual machine's write request to GICD_SGIR.

7. The ARMv8-based virtual machine interrupt direct routing method according to claim 5, characterized in that: When the ARM architecture uses the GICv3 architecture, the hypervisor keeps the vCPU ID consistent with the corresponding pCPU ID, or adjusts the virtual machine GIC driver to directly adapt to the ID mapping relationship between the vCPU and pCPU set by the hypervisor.

8. The ARMv8-based virtual machine interrupt direct routing method according to claim 5, characterized in that In step S1, a mapping relationship between the virtual device interrupt number and the SGI interrupt number is established in the interrupt control mechanism of the virtual machine.

Images