Cross-platform running method based on bottom state perspective and execution flow takeover

Abstract

This invention belongs to the field of computer system architecture and cross-platform driver porting technology. Specifically, it is a cross-platform driver operation method based on low-level state perspective and execution flow takeover. The method includes: utilizing MMU page table flags to silently track memory page states by hardware when there are no abnormal read / write operations in the driver, and performing cache synchronization only when control plane operations are intercepted, thus eliminating context switching storms; using a low-level isolated proxy DMA descriptor to delay the translation of the hypothetical physical address natively constructed by the driver into a real physical address before submitting it to the hardware, resolving physical address conflict deadlocks; and sensing peripheral interrupt load through low-level probes, directly taking over the execution flow to the user-mode interrupt service routine for ultra-fast preemption under low load, and disabling interrupts at the hardware level and forcing the driver to switch to overhead-free polling mode under high load, resuming operation when the hardware is idle. This achieves microsecond-level deterministic response, combining high real-time performance with high throughput.

Description

Technical Field

[0001] This invention relates to the field of computer system architecture and cross-platform porting technology for drivers, and in particular to a method for cross-platform driver operation based on low-level state perspective and execution flow takeover. Background Technology

[0002] In aerospace, industrial control, and other fields, drivers for a large number of core hardware devices are developed based on dedicated embedded real-time operating systems (RTOS). As system architectures evolve towards general-purpose monolithic kernel operating systems (such as Linux), directly reusing RTOS driver binaries faces three major mutual exclusion problems in the underlying model: Memory layout conflict: RTOS drivers assume a flat memory model (VA==PA) and hardcode physical addresses in DMA descriptors, while Linux user-space virtual address space is fragmented and cannot guarantee identity mapping.

[0003] Cache consistency overhead: RTOS drivers often omit explicit cache refresh. The traditional approach of using memory protection exceptions (such as SIGSEGV) to intercept reads and writes before refreshing the cache can cause tens of thousands of context switches per second under high-frequency I / O, resulting in system jitter.

[0004] Interrupt latency and storms: RTOS relies on microsecond-level hard interrupt preemption, while Linux user-space signal simulation (such as SIGIO) has a long path, which violates the semantics of hard preemption; simply handling interrupt storms can easily lead to system livelock or deadlock.

[0005] Existing technologies cannot systematically solve the above problems, causing RTOS drivers to lose real-time performance and determinism under Linux. Summary of the Invention

[0006] This invention proposes a cross-platform driver operation method based on low-level state perspective and execution flow takeover, aiming to solve the technical problems of how to overcome memory mapping conflicts, high-frequency context switching jitter, interrupt latency and storms when running native RTOS binary drivers in monolithic kernel operating systems (such as Linux).

[0007] This invention provides a cross-platform driver execution method based on low-level state perspective and execution flow takeover, for running binary drivers of native embedded real-time operating systems (RTOS) within a monolithic kernel operating system, including: By utilizing the page table flag of the hardware memory management unit (MMU), the hardware silently tracks the memory page state when there are no abnormal reads or writes by the driver, and performs cache synchronization only as needed when control plane operations are intercepted. By using a low-level isolated proxy DMA descriptor, the hypothetical physical address natively constructed by the driver is delayed in being translated into a real physical address and then submitted to the hardware. Additionally, it senses peripheral interrupt load through low-level probes, directly takes over the execution flow to user-mode interrupt service routines when the load is low, and disables interrupts at the hardware level and forces the driver to switch to user-mode polling mode when the load is high, and resumes operation when the hardware is idle.

[0008] The technical advantages of the driver cross-platform operation method based on low-level state perspective and execution flow takeover disclosed in this invention are as follows: This invention abandons the traditional approach of high-frequency anomaly interception and asynchronous signal simulation. Through the organic combination of low-level hardware state perspective and execution flow takeover, it overcomes three major technical challenges—memory layout conflicts, cache consistency overhead storms, and interrupt latency and storms—without modifying the driver source code or relying on high-overhead virtualization. Practical tests show that this invention can achieve microsecond-level deterministic response of native RTOS drivers in a monolithic kernel user-space environment, while eliminating context switching overhead in high-throughput scenarios, achieving an excellent balance between high real-time performance and high throughput.

[0009] Furthermore, the method of silently tracking the memory page status using the hardware MMU page table flags specifically includes: clearing the access bit and dirty bit of the driver's DMA buffer to zero in the macro kernel page table, allowing the driver to read and write the buffer in user mode without triggering any exceptions; and the CPU hardware MMU silently setting the dirty bit or access bit of the corresponding page table entry to 1 when performing read and write operations.

[0010] Furthermore, the step of performing cache synchronization only when the control plane operation is intercepted specifically includes: scanning the page table entries of the buffer only when the driver issues a DMA start command, performing cache synchronization operation only for physical pages where the hardware MMU automatically sets the dirty bit or access bit, and then clearing the flag bit and allowing the DMA start command.

[0011] Furthermore, the delayed translation via the underlying isolated proxy DMA descriptors specifically includes: pre-allocating a linked list of proxy DMA descriptors with real and valid physical addresses at the underlying level; allowing the driver to freely construct a linked list of native DMA descriptors containing hypothetical physical addresses in user space; when the driver sends the address of the native linked list, pausing the submission, batch delaying the translation of the hypothetical physical addresses into real I / O virtual addresses IOVA, synchronously mapping them to the linked list of proxy DMA descriptors, and finally redirecting the real physical addresses of the proxy linked list to the hardware peripheral.

[0012] Furthermore, the batch delayed translation is implemented by calling the operating system kernel's get_user_pages interface or by directly traversing the process page table tree.

[0013] Furthermore, the step of sensing peripheral interrupt load through the underlying probe specifically includes: the underlying probe is bound to a peripheral physical interrupt, and when triggered, it parses the hardware buffer descriptor characteristics to identify whether the interrupt event is a critical control flow or a normal data load; for normal data loads, it calculates the exponentially weighted moving average of the interrupt arrival time interval and evaluates the load level based on this value.

[0014] Furthermore, the smoothed mean of the interruption arrival time interval Calculate according to the following formula: ; in This is the current interrupt trigger time. The time since the last interrupt was triggered. The smoothing weighting coefficient is used; when the smoothing mean is lower than the preset storm threshold, it is determined to be a high-load data storm state.

[0015] Furthermore, the direct takeover of the execution flow to the user-mode interrupt service routine under low load specifically includes: the low-level probe finds the pt_regs structure at the top of the kernel stack of the current driver process, backs up its original stack pointer and program counter to an independent interrupt stack, then rewrites the stack pointer in pt_regs to the top of the independent interrupt stack, rewrites the program counter to the entry address of the user-mode interrupt service routine, and the CPU directly jumps to the interrupt service routine after executing the interrupt return instruction.

[0016] Furthermore, the hardware-level disabling of interrupts and forced driver switching to polling mode under high load specifically includes: writing an interrupt mask to the peripheral's memory-mapped I / O register to disable physical interrupt triggering, setting a shared polling flag, then finding the pt_regs structure at the top of the current driver process's kernel stack, backing up its original stack pointer and program counter to an independent interrupt stack, rewriting the stack pointer in pt_regs to the top of the independent interrupt stack, rewriting the program counter to the entry address of the user-mode interrupt service routine, and forcibly jumping to the interrupt service routine after the CPU executes the interrupt return instruction.

[0017] Furthermore, the user-mode polling mode includes: after the interrupt service routine detects the shared polling flag, it enters a state of continuously polling the hardware buffer and continuously reads data in batches; when the hardware idle time exceeds a preset exit threshold, the interrupt service routine clears the polling flag, re-enables the physical interrupt of the peripheral device, and performs a context recovery operation to exit the interrupt service routine. Attached Figure Description

[0018] Figure 1This is a flowchart illustrating the cross-platform running method based on low-level state perspective and execution flow takeover proposed in this invention. Figure 2 This is a schematic diagram of the anomaly-free tracking and on-demand cache synchronization mechanism based on hardware page table flag bit perspective in the method of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] To address the challenges of overcoming memory mapping conflicts, high-frequency context switching jitter, and interrupt latency and storms when running native RTOS binary drivers in monolithic kernel operating systems (such as Linux), as mentioned in the background section, and thus achieving microsecond-level deterministic response, this invention provides a cross-platform embedded driver operation method based on low-level state perspective and execution flow takeover. This method achieves the above effects through the synergistic combination of the following three core mechanisms: utilizing the page table flags of the hardware memory management unit (MMU), the hardware silently tracks the memory page state when there are no abnormal read / write operations in the driver, and performs cache synchronization only when control plane operations are intercepted; through low-level isolated proxy DMA descriptors, the hypothetical physical address natively constructed by the driver is delayed in translation into a real physical address and then submitted to the hardware; and through low-level probes to sense peripheral interrupt load, the execution flow is directly taken over to the user-mode interrupt service routine under low load, and interrupts are disabled at the hardware level and the driver is forced to switch to user-mode polling mode under high load, resuming operation when the hardware is idle.

[0021] This invention uses the example of running a native RTOS gigabit Ethernet card driver in a Linux monolithic kernel operating system to illustrate a complete DMA send and interrupt handling process. (Reference) Figures 1 to 2 As shown, the specific steps include: Step 1: System initialization and mounting of underlying probes.

[0022] During system startup, the compatibility layer (which can consist of Linux kernel modules and user-space auxiliary libraries) pre-allocates a physically contiguous memory segment within the Linux kernel via the `dma_alloc_coherent` interface. This segment is used to construct a "Proxy DMA Descriptor Ring," which resides in the hardware-visible real DMA memory. Simultaneously, the compatibility layer attaches a low-level probe module to the physical hardware interrupt entry point of the target network interface card (NIC). This low-level probe can be a custom Kprobe kernel module or an eBPF probe program with relaxed security authentication permissions, capable of directly reading hardware MMIO registers and parsing the NIC's receive ring descriptor.

[0023] The system initially runs in interrupt mode (S_IRQ), and the shared polling flag F_poll is set to 0.

[0024] Step 2: Anomaly-free tracking based on hardware page table flags (Mechanism 1).

[0025] like Figure 2 As shown, after the compatibility layer allocates a DMA send buffer (e.g., 1MB in size) for the RTOS driver, it obtains the page table entries (PTEs) for all memory pages in that buffer, clears the access bit and dirty bit in each PTE to zero, but retains its read and write permissions. In this way, any write operation by the CPU to that buffer will be recorded by the hardware MMU without triggering any page faults or protection exceptions.

[0026] The RTOS driver executes `memcpy` at full speed in user space to write the message data to be sent into the DMA buffer. When the CPU executes each write instruction, the MMU hardware automatically sets the PTE dirty bit of the corresponding memory page to 1. The entire process does not generate any exceptions that trap into the kernel, and the performance is completely consistent with the native RTOS environment. Therefore, this invention achieves hardware-level perspective tracking of "dirty" memory pages with zero overhead, completely avoiding the high-frequency context switching storms caused by memory protection exceptions in the traditional `mprotect` scheme.

[0027] Step 3: The driver builds the native descriptor and issues DMA commands.

[0028] The driver continues to freely construct its native DMA descriptor linked list (e.g., an SG linked list containing 100 scattered aggregate fragments) in user space without any interference. Due to the natural fragmentation of Linux user-space memory, the driver fills the linked list nodes with its assumed, contiguous physical addresses (in reality, these addresses are spurious and do not match the actual physical memory layout). Throughout the entire construction process, the compatibility layer does not intervene or intercept, ensuring the integrity of the driver's original logic.

[0029] After filling the linked list, the driver writes the physical address of the head of the native SG linked list, PA_orig, to the NIC's transmit doorbell (TXDoorbell) register, preparing to initiate DMA transfer. This is the only control plane operation initiated by the driver to the hardware.

[0030] Step 4: Intercept the coordinated execution of the control plane and core mechanisms (mechanism one and mechanism two working together).

[0031] The compatibility layer pre-captures write operations to the doorbell register using UIO (Userspace I / O) or MMIO write interception techniques in the kernel module. When the write occurs in step 3, the system suspends submitting DMA requests to the hardware, and this interception enters a microsecond-level processing window. Within this window, Mechanism 1 and Mechanism 2 execute collaboratively: (4.1) Delayed translation and isolated commit of asymmetric proxy descriptors (mechanism 2).

[0032] The system first accesses user-space memory via kernel functions based on the captured physical address PA_orig of the head of the native linked list, traversing the native SG linked list (e.g., 100 nodes) constructed by the driver. For each dummy physical address in the native node encountered, the compatibility layer translates these dummy addresses in batches and with delay into I / O virtual addresses (IOVAs) that can be truly accessed by the hardware and correspond to the actual physical memory locations of the user-space buffers. This is done by calling the get_user_pages_fast() function provided by the Linux kernel or by directly querying the mm_struct page table tree of the current process.

[0033] In a more specific implementation, if the peripheral device supports IOMMU, the translated value is directly the IOVA; otherwise, it is converted to a contiguous physical address. After translation, these real IOVAs are sequentially filled into the corresponding nodes of the kernel-mode "proxy DMA descriptor list" pre-allocated in step 1. Then, the system saves the real physical header address PA_proxy of the proxy list, ready to submit it to the hardware.

[0034] This step removes the address resolution process from the "hot path" of driver descriptor construction and moves it to the "cold path" at the moment of DMA startup, significantly reducing driver execution overhead. At the same time, it cleverly maps the "pseudo-continuous" user-mode addresses to "true discrete" kernel-mode hardware-executable I / O addresses, completely solving the deadlock of identity mapping failure.

[0035] (4.2) On-demand cache synchronization based on page table dirty bits (mechanism one).

[0036] Simultaneously (or sequentially), the system scans all PTEs in the DMA buffer from step 2. Assuming the 1MB buffer contains 256 4KB pages, the scan finds three page table entries with a dirty bit of 1. The system only executes CPU-architecture-dependent cache cleanup instructions for these three confirmed "dirty" physical pages (e.g., on ARM64, first executing DCCCVAC to write data from the cache back to main memory, then executing DSBSY memory barrier to ensure order), and then clears the dirty bits of these PTEs back to zero. This "on-demand synchronization" mechanism avoids a global cache flush of the entire DMA buffer, greatly reducing CPU pipeline stalls.

[0037] (4.3) Redirect submission.

[0038] After completing the address translation and cache synchronization, the compatibility layer writes the real physical header address PA_proxy (instead of the fake address PA_orig provided by the driver) of the proxy list into the network card's DMA register and allows the doorbell command. Subsequently, the network card hardware reads the proxy list based on PA_proxy, obtains all the real IOVAs, and begins DMA transfer. Data flows correctly at the hardware level without any corruption.

[0039] The aforementioned coordination of control plane interception, address reconstruction, and cache synchronization is completed within a microsecond window, completely resolving the dual challenges of address conflicts and cache inconsistencies. Its overall timing coordination relationship is as follows: Figure 1 As shown.

[0040] Step 5: Load-aware physical interrupt dynamic takeover and execution flow tampering (mechanism three).

[0041] After the DMA transfer is complete, the network card sends a physical interrupt to the CPU, and the underlying probe module is executed immediately. The probe executes the following logic: (5.1) Intent identification and load assessment.

[0042] The probe reads the descriptor of the network card's receiver ring, and identifies the intent attribute I(E_i) of the current interrupt event E_i by parsing the status bits (such as packet type, error flag, etc.) in the descriptor, and classifies it into critical control commands (C) or ordinary data payloads (D).

[0043] If it is a critical control command (C), then proceed directly to the low-latency takeover path in step 5.2.

[0044] If it is a normal data payload (D), the probe further calculates the exponentially weighted moving average (EWMA) of the interruption arrival time interval: ; in This is the current interrupt trigger time. is the trigger time of the previous interruption, is the smoothing weight coefficient (for example, take 0.125); when the smoothed mean is lower than the preset storm threshold, it is determined as the high-load data storm state. The calculated smoothing interval is smaller, indicating that the current data throughput load of the peripheral device is higher.

[0045] The system presets a storm threshold T_storm (for example, 10 microseconds). If >= T_storm, it is regarded as the normal load state; if < T_storm, it is determined as the high-load data storm state.

[0046] (5.2) Direct takeover of the execution flow under normal load.

[0047] When in the normal load state, the system maintains the interrupt mode (S_IRQ). The probe directly takes over the execution flow to the user-state interrupt service routine (ISR) through the following operations: Locate the pt_regs structure at the top of the kernel stack of the current driver process (i.e., the user-state process to which this driver belongs).

[0048] Back up the original stack pointer (SP) and program counter (PC) in the pt_regs to an independent interrupt stack.

[0049] Rewrite pt_regs->sp as the top address of the independent interrupt stack.

[0050] Rewrite pt_regs->pc as the entry address of the user-state ISR.

[0051] After the CPU executes the interrupt return instruction (eret for ARM64 or iret for x86), it directly jumps from the kernel state to the user-state ISR.

[0052] After the ISR finishes processing (for example, reading a control command response packet), it calls a lightweight recovery system call. The kernel writes the original SP and PC backed up in the independent interrupt stack back to the pt_regs structure of the kernel stack, and the process seamlessly resumes execution from the exact position where the interruption occurred. Compared with the traditional signal delivery path of Linux, this step realizes the microsecond-level hard interrupt preemption in the user state by directly tampering with the register context, and preserves the hard real-time semantics of the RTOS driver.

[0053] (5.3) Interrupt suppression and polling forced switching under high-load data storm.

[0054] When a data storm is detected (i.e., I(E_i)=D and < T_storm), the probe execution state machine flips, switching from S_IRQ to the polling mode (S_POLL): Hardware interrupt suppression: The probe immediately writes a specific control word to the network card's MMIO interrupt mask register, disabling subsequent interrupt triggering at the physical hardware level. This eliminates hardware interrupt storms on the PCIe bus.

[0055] Set the polling flag: Set the shared flag F_poll to 1. This flag is located in shared memory accessible to the user-mode driver.

[0056] Final execution flow takeover: The probe performs the exact same pt_regs tampering operation as in step 5.2 (backup, rewrite SP / PC, execute interrupt return), forcing the CPU to jump to user-mode ISR.

[0057] When a user-space ISR is triggered, it first checks the value of F_poll. Since F_poll == 1, the ISR does not perform a single-process return, but instead enters a compact while loop to continuously read packets in batches from the network interface card's receive ring. This polling mode eliminates any system call and context switching overhead, achieving high-throughput processing with zero overhead.

[0058] When the continuous idle time of the receive ring exceeds the preset exit threshold T_idle (e.g., 50 microseconds), the polling loop exits. The ISR actively clears F_poll and re-enables the physical interrupt of the peripheral by writing a control word to the network card's MMIO register. Finally, it calls the recovery system call to restore the original pt_regs and exits. The system safely switches back to S_IRQ state.

[0059] This mechanism enables zero-overhead adaptive switching between interrupt mode and polling mode: it guarantees microsecond-level response under low load, actively suppresses interrupts and switches to polling under high load, and automatically resumes when the hardware is idle, perfectly balancing real-time performance and throughput.

[0060] Step 6: System closed loop and effect summary.

[0061] Through the synergy of steps 1 to 5, this invention achieves cross-platform operation of RTOS drivers in a monolithic kernel operating system without modifying the source code or virtualization. The specific effects are as follows: Data preparation phase (steps 2 and 3): Silent tracking of dirty bits in hardware page tables with zero exception overhead.

[0062] Submission trigger period (step 4): Control plane interception, delayed translation and on-demand caching are completed synchronously, with microsecond-level latency.

[0063] Response takeover period (step 5): Based on load awareness, dynamic interrupt / polling switching ensures both real-time performance and avoids storms.

[0064] Figure 1The invention fully demonstrates the closed-loop coordination of the three mechanisms on the timeline, proving that the invention enables native RTOS drivers to achieve true microsecond-level deterministic responses in the Linux environment.

[0065] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of the invention as set forth in the appended claims.

Claims

1. A method for running binary drivers of a native embedded real-time operating system (RTOS) in a macro-kernel operating system based on the state of the underlying platform and the execution flow takeover, characterized in that, include: By utilizing the page table flag of the hardware memory management unit (MMU), the hardware silently tracks the memory page state when there are no abnormal reads or writes by the driver, and performs cache synchronization only as needed when control plane operations are intercepted. By using a low-level isolated proxy DMA descriptor, the hypothetical physical address natively constructed by the driver is delayed in being translated into a real physical address and then submitted to the hardware. Additionally, it senses peripheral interrupt load through low-level probes, directly takes over the execution flow to user-mode interrupt service routines when the load is low, and disables interrupts at the hardware level and forces the driver to switch to user-mode polling mode when the load is high, and resumes operation when the hardware is idle.

2. The method according to claim 1, characterized in that, The method of silently tracking memory page status using hardware MMU page table flags specifically includes: clearing the access bit and dirty bit of the driver's DMA buffer to zero in the macro kernel page table, allowing the driver to read and write the buffer in user mode without triggering any exceptions; and the CPU hardware MMU silently setting the dirty bit or access bit of the corresponding page table entry to 1 when performing read and write operations.

3. The method according to claim 2, characterized in that, The provision that cache synchronization is performed only when control plane operations are intercepted includes: scanning the page table entries in the buffer only when a DMA start command is intercepted from the driver, performing cache synchronization only on physical pages for which the hardware MMU automatically sets the dirty bit or access bit, and then clearing the flag bit and allowing the DMA start command.

4. The method according to claim 1, characterized in that, The deferred translation via the underlying isolated proxy DMA descriptors specifically includes: pre-allocating a linked list of proxy DMA descriptors with real and valid physical addresses at the underlying level; allowing the driver to freely construct a linked list of native DMA descriptors containing hypothetical physical addresses in user space; when the driver sends the address of the native linked list, pausing the submission, batch deferred translating the hypothetical physical addresses into real I / O virtual addresses IOVA, synchronously mapping them to the linked list of proxy DMA descriptors, and finally redirecting the real physical addresses of the proxy linked list to the hardware peripheral.

5. The method according to claim 4, characterized in that, The batch delayed translation is achieved by calling the operating system kernel's get_user_pages interface or by directly traversing the process page table tree.

6. The method according to claim 1, characterized in that, The method of sensing peripheral interrupt load through low-level probes specifically includes: the low-level probes are bound to peripheral physical interrupts, and when triggered, the hardware buffer descriptor features are parsed to identify whether the interrupt event is a critical control flow or a normal data load; for normal data loads, the exponentially weighted moving average of the interrupt arrival time interval is calculated, and the load level is evaluated based on this value.

7. The method according to claim 6, characterized in that, The smoothed mean of the interruption arrival time interval Calculate according to the following formula: ； in This is the current interrupt trigger time. The time since the last interrupt was triggered. The smoothing weighting coefficient is used; when the smoothing mean is lower than the preset storm threshold, it is determined to be a high-load data storm state.

8. The method according to claim 6, characterized in that, The process of directly taking over the execution flow to the user-mode interrupt service routine under low load includes: the low-level probe finds the pt_regs structure at the top of the kernel stack of the current driver process, backs up its original stack pointer and program counter to an independent interrupt stack, then rewrites the stack pointer in pt_regs to the top of the independent interrupt stack, rewrites the program counter to the entry address of the user-mode interrupt service routine, and the CPU executes the interrupt return instruction and directly jumps to the interrupt service routine.

9. The method according to claim 6, characterized in that, The process of disabling interrupts and forcing the driver to switch to polling mode at the hardware level under high load includes: writing an interrupt mask to the peripheral's memory-mapped I / O register to disable physical interrupt triggering, setting a shared polling flag, finding the pt_regs structure at the top of the current driver process's kernel stack, backing up its original stack pointer and program counter to an independent interrupt stack, rewriting the stack pointer in pt_regs to the top of the independent interrupt stack, rewriting the program counter to the entry address of the user-mode interrupt service routine, and forcibly jumping to the interrupt service routine after the CPU executes the interrupt return instruction.

10. The method according to claim 9, characterized in that, The user-mode polling mode includes: after the interrupt service routine detects the shared polling flag, it enters a state of continuously polling the hardware buffer and continuously reads data in batches; when the hardware idle time exceeds a preset exit threshold, the interrupt service routine clears the polling flag, re-enables the physical interrupt of the peripheral device, and performs a context recovery operation to exit the interrupt service routine.

Images