CN117407054A - 中断处理方法、电子设备和存储介质 - Google Patents

中断处理方法、电子设备和存储介质 Download PDF

Info

Publication number
CN117407054A
CN117407054A CN202210803080.9A CN202210803080A CN117407054A CN 117407054 A CN117407054 A CN 117407054A CN 202210803080 A CN202210803080 A CN 202210803080A CN 117407054 A CN117407054 A CN 117407054A
Authority
CN
China
Prior art keywords
interrupt
user
thread
user state
state
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210803080.9A
Other languages
English (en)
Inventor
廖畅
李政谕
郭寒军
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN202210803080.9A priority Critical patent/CN117407054A/zh
Priority to PCT/CN2023/103632 priority patent/WO2024007934A1/zh
Publication of CN117407054A publication Critical patent/CN117407054A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/32—Address formation of the next instruction, e.g. by incrementing the instruction counter
    • G06F9/322—Address formation of the next instruction, e.g. by incrementing the instruction counter for non-sequential address
    • G06F9/327—Address formation of the next instruction, e.g. by incrementing the instruction counter for non-sequential address for interrupts
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098—Register arrangements
    • G06F9/30105—Register structure
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/32—Address formation of the next instruction, e.g. by incrementing the instruction counter
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4812—Task transfer initiation or dispatching by interrupt, e.g. masked

Abstract

本申请实施例提供一种中断方法、电子设备和存储介质，该方法包括：确定中断线程在处理器上运行时，基于用户态中断备忘信息寄存器记录的当前处理器运行线程的状态信息，若确定当前线程在用户态运行，则向所述处理器投递用户态中断，并基于用户态中断向量寄存器存储的地址读取指令，在用户态执行中断处理函数。通过该方法处理器的地址空间可以直接调用用户态中断处理函数，进一步减少了软件响应用户态中断的开销。

Description

中断处理方法、电子设备和存储介质
技术领域
本申请涉及中断控制技术领域，尤其涉及一种中断处理方法、电子设备和存储介质。
背景技术
随着个人电脑、移动计算设备，以及云计算的普及，数据中心承载的业务规模快速增长，数据库，web服务器，AI训练和推理系统，网页搜索系统，电子商务系统处理的数据量越来越大，这些应用软件处理的数据都是通过高速网卡进行收发。
网卡设备由运行在内核态的软件模块管理，网卡设备上产生的事件，比如，报文到达，报文发送完毕等，都会产生硬件中断，这些中断的典型处理流程是：先由运行在CPU内核态的操作系统(Operating System，OS)处理，再转发给对应驱动软件处理，用户态的应用程序必须依赖内核态的驱动软件和网卡设备进行数据交互，一个典型场景是：即时聊天工具收发消息的过程，先执行系统调用将CPU切换到内核态，OS处理系统调用后再通过驱动程序将聊天消息数据交给网卡设备处理，网卡处理完毕会产生一个中断，中断先被OS和驱动程序处理，然后将CPU切换到用户态后，调用应用程序注册的回调函数。
可见，应用程序需要经历多次的特权级切换才能完成和输入/输出(Input/Output，IO)设备的交互，包括，从用户态通过系统调用进入内核态；当硬件成功发起了IO操作后，会从内核态回到用户态；当硬件成功完成数据处理，又会进入内核态处理中断；最后还会回到用户态执行应用程序注册的回调函数。由于这些特权级切换的存在，都会为应用程序每次和IO设备的交互带来很多额外响应时延，当数据中心业务量特别大的情况下，这些时延将会大大降低应用程序的处理能力，导致网络丢包和用户体验差。
发明内容
本申请实施例提供一种中断方法、电子设备和存储介质，可以通过该中断方法减少这种不必要的特权级切换次数，从而改善应用程序和IO设备交互性能。
第一方面，本申请实施例提供一种中断方法，包括：确定中断线程在处理器上运行时，基于用户态中断备忘信息寄存器记录的当前处理器运行线程的状态信息，若确定当前线程在用户态运行，则向所述处理器投递用户态中断，并基于用户态中断向量寄存器存储的地址读取指令，在用户态执行中断处理函数。通过该方法处理器的地址空间可以直接调用用户态中断处理函数，进一步减少了软件响应用户态中断的开销。
进一步地，所述基于用户态中断备忘信息寄存器的记录信息，确定当前线程在用户态运行包括：确定所述用户态中断备忘信息寄存器的终端线程陷入内核标记为第一状态，并且所述用户态中断备忘信息寄存器的中断线程是否在线标记为第二状态，则确定当前线程在用户态运行。在一种实施方式中，用户态中断备忘信息寄存器的终端线程陷入内核标记为第一状态可以为用户态中断备忘信息寄存器的T值为0，用户态中断备忘信息寄存器的中断线程是否在线标记为第二状态可以为户态中断备忘信息寄存器的V值为1，(uinoteinfo.T＝＝0，uinoteinfo.V＝＝1)即表示当前线程在用户态运行。
进一步地，所述确定当前线程在用户态运行之前还包括：基于用户态中断备忘信息寄存器的记录信息，确定当前线程是否在用户态运行；其中，基于用户态中断备忘信息寄存器的记录信息，若确定所述用户态中断备忘信息寄存器的终端线程陷入内核标记非第一状态，和/或所述用户态中断备忘信息寄存器的中断线程是否在线标记非第二状态，则将中断服务程序表条目的处理中断上下文填入用户态中断上下文寄存器，并向所述处理器投递门铃中断。
进一步地，所述确定中断线程在处理器上运行时之前，还包括：确定中断服务表中的待处理中断列表与所述用户态中断备忘信息寄存器的待线程处理中断信息是否相同，若相同则确定中断线程在处理器上运行。
进一步地，若确定中断服务表中的待处理中断列表与所述用户态中断备忘信息寄存器的待线程处理中断信息不相同，则将中断服务程序条目的中断服务上下文填入用户态中断上下文寄存器，并向所述处理器投递内核门铃中断。
进一步地，所述确定中断线程在处理器上运行时之前，还包括：确定所述处理器陷入内核态时，在安全检测点检测非安全上下文寄存器的值，若确定处理器处于非安全冲入状态，则将内核上下文保存在设定内存，并将所述设定内存的地址记录在被挂起上下文寄存器，其中，所述安全检测点为内核异常处理入口；基于所述被挂起上下文寄存器记录的所述设定内存的地址，将处理器恢复到被打断的现场，并使被打断的内核继续执行安全重入点，其中，所述安全重入点为内核返回用户态的点；在内核执行到所述安全重入点时，通过所述被挂起上下文寄存器恢复被挂起的内核上下文。其中，常规内核都是在异常和系统调用结束后才返回用户态，但为了支持快速响应用户态中断，本申请实施例允许内核在非结束这些操作时就快速返回到用户态响应中断，这就导致内核此时处于非安全可重入状态。如果用户态中断处理函数又陷入内核，内核的数据完整性将面临较大的不确定性。本申请实施例通过在异常和系统调用入口处利用UCR寄存器将内核状态恢复到被打断的现场，并在内核再次进入安全可重入状态后，(即结束了异常和系统调用处理，准备返回到用户态时)，再利用OCR寄存器开始处理来自用户态中断处理函数的异常和系统调用。通过上述方式解决了在内核里响应用户态中断的带来的非安全可重入问题，既保证了用户态中断可以及时响应，又不会破坏内核的状态。
第二方面，本申请实施例还提供一种中断控制器，包括：处理器和存储器，所述存储器用于存储至少一条指令，所述指令由所述处理器加载并执行时以实现第一方面提供的中断处理方法。
第三方面，本申请实施例还提供一种中断控制器，包括：用户态中断路由引擎和用户态中断快速调用引擎；所述用户态中断快速调用引擎包括：用户态中断备忘信息寄存器，用于记录当前处理器运行线程的状态信息；所述中断控制器确定中断线程在处理器上运行时，基于用所述户态中断备忘信息寄存器记录的当前处理器运行线程的状态信息，若确定当前线程在用户态运行，则向所述处理器投递用户态中断，并基于用户态中断向量寄存器存储的地址读取指令，在用户态执行中断处理函数。
进一步地，所述用户态中断快速调用引擎还包括：用户态中断上下文寄存器，用于记录内存地址；其中，基于用户态中断备忘信息寄存器的记录信息，若确定所述用户态中断备忘信息寄存器的终端线程陷入内核标记非第一状态，和/或所述用户态中断备忘信息寄存器的中断线程是否在线标记非第二状态，则将中断服务程序表条目的处理中断上下文填入用户态中断上下文寄存器，并向所述处理器投递门铃中断。本申请实施例提供的中断控制器中引入的用户态中断备忘信息寄存器和用户态中断上下文寄存器，进而可以实现允许内核快速切换到中断处理线程所在地址空间。
第四方面，本申请实施例还提供一种电子设备，该电子设备可以包括第二方面提供的中断控制器。
第五方面，本申请实施例还提供一种电子设备，该电子设备可以包括第三方面提供的中断控制器。
第六方面，本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现第一方面提供的中断处理方法。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为相关技术中内核态中断和用户态中断处理流程对比示意图；
图2为相关技术中中断投递架构示意图；
图3为图2所示中断控制器的用户态中断投递的流程图；
图4为相关技术中另一种中断流程示意图；
图5为本申请实施例适用的一种系统架构；
图6为本申请一个实施例提供的用户态中断硬件架构图；
图7为本申请一个实施例提供的用户态中断路由引擎示意图；
图8为本申请一个实施例提供的用户态中断路由硬件流程示意图；
图9为本申请一个实施例提供的用户态中断快速调用硬件模块示意图；
图10为本申请实施例提供的一种硬件投递用户态中断流程示意图；
图11为本申请一个实施例提供的一种软件模块分类示意图；
图12为本申请一个实施例提供的中断事件管理模块的示意图；
图13为本申请一个实施例提供的中断地址空间切换模块示意图；
图14为本申请一个实施例提供的安全可重入模块示意图；
图15为本申请一个实施例提供的DPDK中断模式流程示意图；
图16为本申请一个实施例提供的一种软件框架示意图；
图17为本申请实施例提供的DPDK中断模式与用户态中断之间的时延对比图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
为清楚地理解本申请实施例，以下对本申请实施例涉及到的概念进行相应解释：
微内核架构：一种内核架构方案，在该架构中，只保留最核心的内核组件在内核态中，示例性的，将权限管理模块、任务调度的内核组件保留在内核态中；将传统的内核组件设在用户态，示例性的，将文件系统，中断处理框架，网络协议栈等内核组件都放到用户态。
宏内核架构：一种内核架构方案，在该架构中，将所有内核组件放在内核态中，示例性的，将IPC模块、权限管理模块、文件系统，中断处理框架和网络协议栈等内核组件均放在内核态中；用户态只负责运行应用代码。
线程上下文：一个操作系统(Operating System，OS)中维护一个线程的各种状态，包括线程使用的通用寄存器、页表、线程私有空间，线程元数据等部分。
中央处理器(Central Processor Unit，CPU)特权级：现有芯片支持用户态和内核态两种特权级，在不同特权级下运行着各种软件系统，这些软件系统对底层硬件有不同的访问权限，比如，OS运行在CPU高特权级下，各种应用程序，比如，编辑器，网页浏览器等运行在CPU低特权级下。当应用程序需要和硬件交互，比如，通过打印机打印文件，通过键盘编辑文件，就会依赖高特权级的软件系统完成这些工作。
内核驱动：计算机里会有各种硬件设备，比如，键盘，网卡，硬盘，每种硬件设备都依赖不同软件模块来进行操作，这些软件模块属于OS的一部分，运行在CPU高特权级下。
中断：一种由硬件触发的事件，该事件发生时将中断CPU的执行流，并从特定内核驱动继续执行。
上下文保存和恢复：CPU的执行流被硬件打断后，为了能回到被打断点继续执行，软件将打断时的通用寄存器(General Purpose Register，GPR)和控制和状态寄存器(Control Status Register，CSR)都保存在内存里，软件将备份的数据再次恢复到GPR和CSR里，就能恢复CPU原执行流继续执行。
响应时延：从硬件触发中断事件到CPU开始执行该中断处理函数，这个过程消耗的时间。
内核可重入性：内核在任意时候被中断后执行了另外一段代码，这段代码又调用了内核，但内核状态仍然能保持正确。
任务迁移：在多CPU的系统里，当CPU的工作负载过重，OS会将该CPU运行队列里的任务迁移到其他CPU的运行队列里。
以上为本申请实施例所涉及的概念。
随着个人电脑、移动计算设备以及云计算的普及，数据中心承载的业务规模快速增长，数据库、web服务器、Al训练和推理系统、网页搜索系统或者电子商务系统处理的数据量越来越大，这些应用软件处理的数据都是通过高速网卡进行收发。
其中，网卡设备由运行在内核态的软件模块管理，网卡设备上产生的事件，比如，报文到达，报文发送完毕等，都会产生硬件中断，这些中断的典型处理流程是：先由运行在CPU内核态的OS处理，再转发给对应驱动软件处理，用户态的应用程序需依赖内核态的驱动软件和网卡设备进行数据交互，示例性的，即时聊天工具收发消息的过程，先执行系统调用将CPU切换到内核态，OS处理系统调用后再通过驱动程序将聊天消息数据交给网卡设备处理，网卡处理完毕会产生一个中断，中断先被OS和驱动程序处理，然后将CPU切换到用户态后，调用应用程序注册的回调函数。
可见，应用程序需要经历多次的特权级切换才能完成和IO设备的交互，包括，从用户态通过系统调用进入内核态；当硬件成功发起了IO操作后，会从内核态回到用户态；当硬件成功完成数据处理，又会进入内核态处理中断；最后还会回到用户态执行应用程序注册的回调函数。由于这些特权级切换的存在，都会为应用程序每次和IO设备的交互带来很多额外响应时延，当数据中心业务量特别大的情况下，这些时延将会大大降低应用程序的处理能力，导致网络丢包和用户体验差，改善应用程序和IO设备交互性能的策略就是尽可能减少这种不必要的特权级切换次数。
图1为相关技术中内核态中断和用户态中断处理流程对比示意图。参照图1所示，基于用户态中断的架构是一项广泛使用以降低IO响应时延的技术，大多数的用户态中断实现方案都支持：当CPU正在运行特定应用程序时才会触发中断，并且通过内存里的管理数据对象，由硬件自动将中断发送给运行特定应用程序的CPU，避免了先由内核态的OS处理再调用用户态回调函数的问题。所以在用户态中断的支持下，应用程序只需要发起硬件操作，当硬件触发用户态中断时，应用程序的指令流可以直接跳转到用户态的回调函数，减少至少两次特权级切换和任务调度开销，当数据密集业务负载非常繁重时，消耗在处理中断上的时延开销可减少10～30倍。
图2为相关技术中中断投递架构示意图。参照图2所示，该中断控制器采用基于事件的分支(Event-Based Branches，EBB)的方案。该中断控制器包含两种功能部件，具体如下：
中断源控制器(Interrupt Source Controller，ISC)，每个设备都先将中断信息发往ISC，再由ISC将中断封装成紧急通知报文(Emergency Notification Message，ENM)发到IPC部件。
中断呈现控制器(Interrupt Presentation Controller，IPC)，IPC接收来自ISC的ENM后，再将中断发送给在特定地址空间下运行的软件处理。
图2所示的中断控制器中还定义了四种内存数据，用来支持中断投递和中断响应，具体如下：
每个中断源都由软件在内存里分配一个管理对象事件状态缓存(Event StateBuffer，ESB)，
每个中断响应目标(比如，虚拟机Hypervisor，内核态OS和用户态进程)都由软件在内存里分配一个管理对象事件通知描述符(Event Notification Descriptor END)，注意，运行在不同Physical Thread(物理线程)上的OS有不同的END。
软件还会在内存里分配一个管理对象事件指派结构(Event AssignmentStructure，EAS)EAS，用来描述将投递中断的策略。
如图2所示，同时在每个物理线程上还存在三个物理寄存器User TIMA，OS TIMA和Hyp TIMA分别记录当前物理线程上正在执行的虚拟机Hypervisor，OS和用户态进程的END识别码。
图3为图2所示中断控制器的用户态中断投递的流程图。参照图3所示，该中断控制器利用EBB机制使用户态进程直接响应PMU(Performance Monitor Unit，性能监控单元，用于收集CPU内各功能部件的计数器)中断，应用程序先通过OS注册用户态的PMU中断，这个操作会在内存里创建三个对象：ESB，EAS，END，用户态中断投递流程包括以下步骤：
步骤301：当该中断控制器的ISC模块接收到用户态中断后，会根据中断请求号从内存里获取中断号对应的ESB对象数据，从数据里获取用户态线程的END对象数据和EAS对象数据，并将这两个数据封装成ENM消息发送给该中断控制器的IPC模块。
步骤302：IPC模块从ENM报文里解析出用户态线程的END数据，和所有物理线程的User TIMA进行比较，如果匹配就代表当前物理线程上运行的进程属于特定地址空间，此物理线程上正在执行流将被打断，程序指针寄存器(Program Counter，PC)跳转到用户态中断入口地址。其中，程序指针寄存器指示了CPU当前正在取指的地址。
步骤303：如果END数据没有能匹配所有User TIMA，就意味着目标线程没有运行，IPC再利用EAS数据里获取上升(Escalate)中断的END对象地址，该对象对应的是一个运行在特定物理线程上的OS中断处理函数，将该END对象和所有物理线程的OS TIMA进行比较，并将用户态中断投递到对应物理线程上的OS来响应。
步骤304：OS响应用户态中断后，根据中断信息唤醒对应用户态线程，往User TIMA里填入用户态线程对应的END对象并设置中断Pending标记。
步骤305：当线程返回到用户态时，芯片会通过User TIMA检测到有用户态中断Pending，PC跳转到用户态中断处理入口地址。
基于图3所示的流程，该中断控制器处理用户态线程不在线的策略同样是通过更高特权级的软件OS线(中断控制器的内核驱动)唤醒用户态线程，需等到线程返回到用户态后响应用户态中断。目前只支持在用户态处理PMU中断，其他设备中断暂不支持；并且只能使当前运行的进程处理中断，如果要保证中断能被及时响应，就要求进程以轮询模式运行，这会导致CPU功耗大和利用率低。
图4为相关技术中另一种中断流程示意图。参照图4所示，用户态直接触发硬件中断(指令集称之为User IPI)，并且能保证由某个特定线程来响应该中断(指令集称之为User Interrupt)，软件响应中断时不必发生特权级切换，这套User Interrupt机制主要围绕以下两个关键的内存对象来实现：
User Posted-interrupt Descriptor(UPID)，UPID代表一个中断处理任务对象。
User Interrupt Target Table(UITT)，UITT起到了中断路由表的作用。
参照图4所示，User IPI和User Interrupt的逻辑模型是：
(1)软件通过“SENDUIPI index”指令触发用户态中断，该指令可以在Ring3操作，硬件利用UITTSIZE检测index的有效性，确保index不超过UITT条目数量，然后利用UITTADDR获取UITT条目虚拟地址。
(2)UITT条目包含两种信息：UIV和UPIDADDR，其中UIV就是中断请求号，用户态中断处理根据UIV选择不同处理逻辑，UPIDADDR用于访问目标线程对应的UPID对象，硬件将UIV登记到UPID.PIR字段里，并且根据UPID.Notification_destination字段选择中断路由的目标CPU。
(3)硬件将UPID.Notification_vector字段发往UPID.Notification_destination指定的CPU，目标CPU的APIC接收到Notification_vector后，和本地UINV MSR进行比较，如果相同APIC将会按照用户态中断的方式来投递中断。
(4)当CPL＝＝3(表示CPU运行在用户态)，硬件通过UPIDADDR寄存器访问当前正在CPU上线程的UPID对象，将UPID.PIR的值填充到UIRR寄存器，然后将PC设置为UIHANDLER寄存器的值，栈指针寄存器(Stack Pointer，SP)设置为UISTACKADJUST寄存器的值，最后保存寄存器跳转到UIHANDLER。该栈指针寄存器指示了当前函数使用的栈顶地址。
(5)当用户态中断触发线程被OS调入时，需要更新本地的UITTADDR和UITTSIZE寄存器，当用户态中断处理线程被OS调入时，也需要更新CPU本地的UPIDADDR，UIHANDLER，UISTACKADJUST和UINV寄存器。
基于图4所示的流程，每个线程最多能处理64种不同的用户态中断请求号，并且要求CPU必须运行在Ring3(用户态)才能响应中断，如果线程阻塞在Ring0(内核态)或者被调度出去，先由OS响应该中断后再将目标线程调度起来。
综合现有技术中存在的缺陷，存在以下技术问题：
(一)、相关用户态中断方案均不支持当任务处于阻塞时直接执行用户态中断处理函数。
(二)、相关用户态中断方案中内核执行过程中突然切回到用户态执行函数，将导致内核里部分不可重入代码的上下文被破坏。
为克服上述技术问题，本申请实施例提供一种软硬件协同方案，其中提供一种包括中断路由和中断投递的硬件架构，并基于该硬件架构进一步提供一种软件方案(即一种中断处理方法)，通过该方法可以支持在底层硬件中对快速调用用户态函数并保证内核安全可重入。当中断处理线程阻塞在内核态或者被抢占的情况下，调用用户态中断处理函数前要求复杂的地址空间和特权级切换流程，本方案将地址空间和特权级切换依赖的上下文数据保存在一组硬件寄存器，内核可以利用这些上下文数据实现快速切换，避免了内核任务唤醒和调度过程，改善了切换流程的开销，该方案还能保证内核安全可重入，即使内核执行过程被用户态中断打断的情况下，仍然能正常提供服务。
图5为本申请实施例适用的一种系统架构。参照图5所示，该系统架构包括应用层、用户态库层、内核层和硬件层。各层说明具体如下：
应用层：运行各种应用程序，本申请提供的优化方案对该层透明，保证兼容性。
用户态库层：包含两个模块，用户态中断注册模块，用户态中断上下文切换模块。这两个模块会提供注册用户态中断处理函数的接口，并且将中断上下文切换的通用流程进行封装，提供给所有需要在用户态处理中断的程序。
内核层：内核态包含四个模块，“用户态中断路由引擎驱动”，“用户态中断事件管理模块”，“内核安全可重入模块”和“中断地址空间切换模块”。“用户态中断路由引擎驱动”负责分配和配置中断事件路由列表(Interrupt Routing Table，IRT)和中断服务对象列表(Interrupt Service Table，IST)以保证用户态中断能由正确的用户态线程响应，“用户态中断事件管理模块”负责将硬件中断封装成内核的一种事件资源，“安全可重入模块”和“中断地址空间切换模块”解决用户中断处理函数快速调用和用户中断陷入内核的问题，并且在内核调度模块里提供钩子函数，防止用户态中断处理任务迁移到其他处理器。本申请以下实施例中涉及的处理器以CPU为例进行说明，并不限定于CPU。
硬件层：用户态中断引擎(Reentrant User Interrupt，RUI)提供了用户态中断路由引擎和用户态中断调用引擎。
为解决现有技术中存在的技术问题，示例性的该技术问题为：“中断处理任务处于阻塞状态或者运行在内核态，需要通过任务调度和特权级切换才可以安全的调用用户态中断处理函数，这个过程带来的时延很大”，基于图5所示实施例提供的系统架构，其中该硬件层提供了基于用户态任务进行中断路由和快速调用中断处理函数的硬件机制，软件层负责为驱动这些硬件功能并为应用程序提供一套通用的接口，方便应用程序利用用户态中断来改善IO处理性能。
本申请提供的以线程为目标的中断路由机制，可以通过Interrupt ServiceTable和Interrupt Router Table和相关的硬件逻辑，允许将根据线程的允许运行状态和位置来动态选择响应中断的CPU。
图6为本申请一个实施例提供的用户态中断硬件架构图。参照图6所示，该中断硬件架构包括用户态中断路由引擎和用户态中断快速调用引擎。其中，第一部分61表示的是用户态中断路由引擎的硬件接口；第二部分62表示用户态中断路由硬件逻辑；第三部分63表示用户态中断路由引擎依赖的内存表对象，软件分配和构造内存表，并通过第一部分61的硬件接口配置表信息；第四部分64表示用户态中断快速调用相关的硬件寄存器。
其中，该用户态中断路由引擎(Router Engine)不同于由内核处理的中断，用户态中断的处理函数属于特定地址空间，这个地址空间会在多个CPU上动态迁移，本申请提供的架构可以通过硬件选择一个CPU来处理用户态中断，保证该CPU上运行的地址空间可以直接调用中断处理函数。为此，硬件构上引入了一套内存数据查询模块，即Router Engine，这个模块用来查询两种内存表数据：Interrupt Router Table和Interrupt Service Table。当用户态中断发生触发时，硬件根据中断请求号查询Interrupt Router Table获取处理中断的线程标识符，再根据线程标识符查询Interrupt Service Table获取处理中断的CPU，最后将中断投递到该CPU上。
图7为本申请一个实施例提供的用户态中断路由引擎示意图。参照图7所示，在一种实施方式中，该用户态中断路由引擎可以是一个挂接在系统总线上的设备，该用户态中断路由引擎的软件编程接口包括：
irtbar(interrupt routing table base address register):是设备配置空间里的一个Memory-mapped寄存器，该寄存器保存一个物理地址，作为一个基地址，指向内存里面的一块连续区间，即中断路由表(interrupt router table)。该内存区域(中断路由表)保存系统里所有用户态中断源的信息，具体而言包含有效位(Valid)，路由类型(RouteType)，事件编号(Event ID),服务编号(Service ID)。其中Router Type目前只支持User-mode一种类型，可以根据具体场景扩展更多类型值。
istbar(interrupt service table base address register)：是设备配置空间里的一个Memory-mapped寄存器，该寄存器保存一个物理地址，作为一个基地址，指向内存里面的一块连续区间。即中断服务表(interrupt service table)。该内存区域保存系统里所有用户态中断处理线程的信息，具体而言包含有效位(Valid)，中断服务上下文(Interrupt Service Context)，待处理中断列表(Interrupt Pending Buffer)，物理中断编号(Physical Processor ID)。
bcbbar(byte code buffer base address register)：是设备配置空间里的一个Memory-mapped寄存器，该寄存器保存一个物理地址，作为一个基地址，指向内存里面的一块连续区间(byte code buffer)。该内存区域保存Router Engine执行的字节码序列，为了防止软件直接修改IRT和IST造成的竞争问题，统一由Router Engine对IRT和IST进行更新，软件通过往BCB里填充字节码来控制硬件更新IRT和IST。
bcbsize(byte code buffer size)：是设备配置空间里的一个Memory-mapped寄存器，该寄存器保存BCB的长度信息，包括每条字节码的长度，整块BCB的长度。
bcbcurp(byte code buffer current pointer)：是设备配置空间里的一个Memory-mapped寄存器，该寄存器保存了Router Engine正在执行的字节码在BCB里的偏移。
bcbendp(byte code buffer end pointer)：是设备配置空间里的一个Memory-mapped寄存器，该寄存器保存了Router Engine正在更新的字节码在BCB里的偏移。
在一种实施方式中，上述的Memory-mapped寄存器主要用于维护三个结构，分别是Interrupt Router表，Interrupt Service表和Byte Code Buffer。这三个结构都是由内核构造和访问，不允许在用户态访问。
其中，Interrupt Router表有很多条目，每一个条目对应一个用户态中断源，条目信息包含该有效位(Valid)，中断路由类型(Route Type)，事件编号(Event ID),服务编号(Service ID)，每个条目默认长度是64位，Event ID和Service ID分别占用16～24位，Route Type占3～7位，Valid占1位，在不同实现上可以根据需要进行调整，该表基地址和长度要保证按页对齐。
中断服务表(Interrupt Service Table)也有很多条目，每一个条目对应一个中断处理线程，条目信息包含该线程有效位(Valid),中断服务上下文(Interrupt ServiceContext)，待处理中断列表(Interrupt Pending Buffer)，物理中断编号(PhysicalProcessor ID)，其中Interrupt Service Context指向一个内存区块，该区块要能容纳一组PC，SP和线程页表基地址，Interrupt Pending Buffer指向一个内存区块，该区块的每个比特代表一个待处理的用户态中断，Physical Processor ID长度由系统CPU拓扑控制，该表基地址和长度都要求按页对齐。
字节码缓存(Byte Code Buffer)是记录字节码的连续内存区块，每个字节码长度是32位，BCB的基地址和长度都要求按页对齐。
Router Engine通过上述的Interrupt Router Table和Interrupt ServiceTable将用户态中断转发到处理线程的运行CPU上，这个过程全程由硬件完成，避免了内核介入用户态中断转发导致的性能开销和竞争问题。图8为本申请一个实施例提供的用户态中断路由硬件流程示意图。参照图8所示，该流程可以包括如下步骤：
步骤801：Router Engine通过总线接收到来自中断源的中断消息，通过MessageDecoder将从消息报文里解析出用户态中断请求号，并将中断请求号发送给选择器Selector(用于IRT)。
步骤802：Selector从内存里的Interrupt Router Table将中断请求号对应的条目读取出来。
步骤803：确定中断请求号是否超过范围，若超出范围，则执行步骤804，若未超出范围则执行步骤805。
步骤804：结束中断流程。
步骤805：将条目数据传递给Interrupt Router Entry Decoder。
步骤806：Interrupt Router Entry Decoder将条目各个字段解析出来，确定有效位(Valid)是否为0，若有效位为0，则执行步骤804，若有效位不为0，则执行步骤807。
步骤807：将Event ID传递给仲裁器(Arbiter)，将Service ID传递给Selector(用于IST)。
步骤808：Selector从内存的Interrupt Service Table将Service ID对应的条目读取出来，并将各个字段解析出来，并确定有效位(Valid)是否为0，若有效位为0，则执行步骤804，若有效位不为0，则执行步骤809。
步骤809：将Physical Processor ID，Interrupt Service Context和InterruptPending Buffer字段发送给Arbiter。
步骤810：Arbiter将Event ID写入Interrupt Pending Buffer指向的内存区块。
步骤811：比较Interrupt Pending Buffer和CPU的GPR保存值是否相同，若相同，则执行步骤812，若不相同，则执行步骤813。
其中，Arbiter通过内部的各种比较器(Comparator，CMP)来判断PhysicalProcessor ID对应的CPU是否在运行该线程(即为该中断提供处理函数的线程)，具体可以通过比较Interrupt Pending Buffer和CPU的GPR保存值是否相同，来确认PhysicalProcessor ID对应的CPU是否在运行该线程，即为该中断提供处理函数的线程。
步骤812：在目标CPU上触发用户态中断。
步骤813：在目标CPU上触发门铃(Doorbell)中断。
步骤814：CPU接收到用户态中断，CPU不会陷入内核态。CPU接收到Doorbell中断，CPU会陷入内核态。通过这套硬件提供的中断路由机制，当中断处理线程在任意CPU上运行的情况下，都能直接在用户态接收中断事件。其中，可以通过Doorbell中断通知内核来准备一个安全的用户态中断处理上下文。
本申请实施例可以当中断处理线程处于阻塞状态或者运行在内核态，也可以快速调用用户态中断处理函数。如图6所示，硬件模块中提供了用户态中断快速调用的一组寄存器：uicontext，uienable，uivector和uinoteinfo。为了解决在内核态调用用户态中断处理函数导致的重入问题，硬件模块又提供了两个寄存器：非安全上下文寄存器(unsafecontext register，UCR)和被挂起上下文寄存器(ongoing context register，OCR)。
图9为本申请一个实施例提供的用户态中断快速调用硬件模块示意图。参照图9所示，
用户态中断快速调用寄存器可以包括用户态中断向量寄存器(uivector)，用户态中断使能寄存器(uienable)，用户态中断备忘信息寄存器(uinoteinfo)，用户态中断上下文寄存器(uicontext)，上述四个寄存器的具体说明如下：
uivector(user interrupt vector)：该寄存器记录一个用户态中断处理函数的虚拟地址，CPU从内核态返回到用户态将从uivector保存的地址取指执行。当CPU在用户态执行时，如果此时被用户态中断打断，也会从uivector保存的地址取指执行，这个寄存器不允许在用户态访问。
uienable(user interrupt enable)：该寄存器用来屏蔽用户态中断，当寄存器的值为0，CPU将不会被用户态中断打断，当寄存器值为1，允许CPU被用户态中断打断，这个寄存器允许在用户态访问。
uinoteinfo(user interrupt noteinfo)：该寄存器记录了CPU运行的中断处理线程的一些关联信息，从图9所示，这个寄存器由三部分构成，第0位代表CPU运行的线程是否能处理用户态中断，如图9所示的“V”；第1位表示CPU运行的线程是否陷入内核，如图9所示的“T”；其他位记录一个内存块地址，这个内存块登记了所有待线程处理的中断，如图9所示的“Pending Buffer Address”所示。
uicontext(user interrupt context)：该寄存器记录了一个内存块地址，内核利用该内存地址里的数据执行快速地址空间切换，该内存由内核分配，将中断处理函数所在地址空间页表基地址(ATT_ADDR)，中断处理函数入口地址(UI_PC)，中断处理函数栈指针(UI_SP)保存在该内存块里。
ukcp(unsafe kernel context pointer)：内核被用户态中断打断时，将现场的PC，GPR，CSR等上下文信息保存在内核栈帧里，保存上下文的栈帧地址记录在该寄存器里。
okcp(ongoing kernel context pointer)：用户态中断处理函数陷入内核时，将陷入现场的PC，GPR，CSR等上下文信息保存在内核栈帧里，保存上下文的栈帧地址记录在该寄存器里。
本申请实施例提供的用户态中断快速调用机制可以通过引入的uinoteinfo和uicontext寄存器，允许内核快速切换到中断处理线程所在地址空间，通过引入UCR和OCR寄存器允许在内核永远处于安全可以重入状态。具体地，一方面可以通过uinoteinfo寄存器保存了当前CPU运行线程的状态信息，包括，待处理中断信息(pending buffer address字段),中断线程陷入内核标记(uinoteinfo.T)，中断线程是否在线标记(uinoteinfo.V)，配合硬件中断路由模块和Interrupt Service Table表项可以快速判断线程状态，区分了V和T这两种状态的收益是，避免在无意义的页表切换操作。
另一方面，还可以通过uicontext寄存器来加速用户态调用的过程，硬件中断路由模块自动将处理中断依赖的页表，PC和SP填充到uicontext里，这个机制的收益是，避免内核通过复杂查询来获取页表基地址，内核利用硬件提供的信息，以最小的代码完成地址空间切换和中断处理函数的调用。
再一方面，CPU在内核态也可以快速响应用户态中断，既能满足DPDK这种能耗比敏感场景，也可以满足用户态IPC和RPC这响应时延敏感场景。
再一方面，可以通过引入两个内核栈指针备份寄存器(UCR和OCR)，其中，UCR用于记录内核被中断打断时的栈指针，OCR用于记录中断处理函数陷入内核时的栈指针，通过这两个栈指针可以快速恢复内核可重入状态。
常规内核都是在异常和系统调用结束后先回到用户态，才可以执行用户态函数，这个过程往往涉及到复杂的唤醒和线程调度流程，通过配合uinoteinfo和uicontext寄存器，内核可以避免复杂的唤醒和调度开销，通过uicontext寄存器里直接获取用户态函数对应的页表，PC和SP，用最小的代价完成函数调用。
在一种替代方案中，还可以在用户态应用程序里直接触发用户态中断，实现快速IPC。
图10为本申请实施例提供的一种硬件投递用户态中断流程示意图。参照图10所示，该流程包括以下步骤：
步骤1001：用户态中断路由引擎(Router Engine)将中断投递到CPU前，确定uinoteinfo里的pending buffer address和IST条目的Interrupt Pending Buffer是否相同。
其中，中断处理线程只有在用户态运行时才可以直接调用处理函数，所以RouterEngine将中断投递到CPU前，会对比用户态中断备忘信息寄存器(uinoteinfo)和IST条目的内容，若内容不相同，则执行步骤1002，如果uinoteinfo里的pending buffer address和IST条目的Interrupt Pending Buffer相同，就表示中断线程正在CPU上运行，则执行步骤1003。
步骤1002：用户态中断路由引擎(Router Engine)将中断服务程序(InterruptService Routines，ISR)表条目的Interrupt Service Context填入uicontext寄存器，然后将一个特殊的内核Doorbell中断投递到CPU上，CPU陷入内核，内核从uicontext寄存器指向内存读取数据中断处理函数所在页表基地址，中断处理函数PC，中断处理函数栈帧，内核利用这三个数据以实现地址空间的快速切换。
步骤1003：确定uinoteinfo.V是否等于1，若等于1，则继续执行步骤1004，若不等于1，则返回执行步骤1002。
步骤1004：确定uinoteinfo.T＝＝0是否等于0，若等于0，则继续执行步骤1005，若不等于0，则返回执行步骤1002。
其中，uinoteinfo.T＝＝0和uinoteinfo.V＝＝1，表示当前线程正在用户态运行。
步骤1005：确定uienable是否等于1，若等于1则执行步骤1006，若不等于1则执行步骤1007。
步骤1006：向CPU投递用户态中断，从而使CPU从uivector里的地址开始取指，并直接在用户态执行处理函数。
步骤1007：陷入内核处理(门铃)Doorbell中断。
其中，中断处理线程只有在用户态运行时才可以直接调用处理函数，所以RouterEngine将中断投递到CPU前，会对比uinoteinfo和IST条目的内容，如果uinoteinfo里的pending buffer address和IST条目的Interrupt Pending Buffer相同，就表示中断线程正在CPU上运行，如果uinoteinfo.T等于0并且uinoteinfo.V等于1，表示当前线程(即，为该中断提供处理函数的线程)正在用户态运行，Router Engine将被用户态中断投递到CPU上，CPU将从uivector里的地址开始取指，并直接在用户态执行处理函数。若uinoteinfo.T等于0但是uinoteinfo.V不等于1，Router Engine将ISR表条目的Interrupt Service Context填入uicontext寄存器，然后将一个特殊的内核Doorbell中断投递到CPU上，CPU陷入内核，内核从uicontext寄存器指向内存读取数据中断处理函数所在页表基地址，中断处理函数PC，中断处理函数栈帧，内核利用这三个数据以实现地址空间的快速切换。当中断处理线程陷入内核时要将uinoteinfo.T设置为1，当中断处理线程返回到用户态前要将uinoteinfo.T设置为0，中断处理线程被CPU调度出去时要将uinoteinfo.V设置为0，中断处理线程被CPU调入时要更新uinoteinfo的pending buffer address字段，并将uinoteinfo.V设置为1。
图11为本申请一个实施例提供的一种软件模块分类示意图。参照图11所示，内核层(软件层)包括：调度模块、异常处理模块、用户态中断事件管理模块，用户态中断路由引擎驱动，中断地址空间快速切换模块，保证内核安全可重入模块。
其中用户态中断路由引擎驱动直接操作本申请提供的用户态中断引擎硬件，包括配置Memory-mapped寄存器，构造字节码并填充至Byte Code Buffer。用户态中断事件管理模块负责在内存里分配和管理本申请提供的Interrupt Router Table和InterruptService Table，将线程注册成用户态中断处理线程，将中断注册为用户态中断，这些操作最终都会通过用户态中断路由引擎驱动进行硬件操作。中断地址空间快速切换模块负责操作本申请提供的中断快速调用寄存器，该模块在线程调度和异常处理模块里都会使用。内核安全可重入模块负责操作本申请提供的安全可重入寄存器，该模块在线程调度和异常处理模块都会使用。
以下针对用户态中断事件管理模块(以下简称中断事件管理模块)，中断地址空间快速切换模块和保证内核安全可重入模块进行详细说明。
关于用户态中断事件管理模块：
普通线程要先将自己注册为中断处理线程，才能具备处理用户态中断的能力。另外，由内核处理的中断的路由目标是物理CPU，无论中断在哪个CPU上处理，内核都可以直接调用中断处理函数，但用户态中断处理函数属于特定的地址空间的，所以用户态处理的中断的路由目标是中断处理线程。所以中断事件管理模块包含两个特性：注册中断处理线程和配置中断路由目标。
图12为本申请一个实施例提供的中断事件管理模块的示意图。参照图12所示，如果线程需要在用户态处理中断就可以将自己注册为中断处理线程，内核会在InterruptService Table分配一个表条目，并且填充条目的Interrupt Service Context和Interrupt Pending Buffer字段，这两个字段指向的内存区块也是由内核分配，每个线程的内核管理对象都需要登记对应的IST条目编号，Interrupt Service Context和Interrupt Pending buffer内存区块地址。Interrupt Service Table表条目里InterruptPending Buffer字段指向一块内存区块，这个内存块里保存中断线程所有待处理的中断信息，支持线程在不同的CPU都能快速获取待处理中断信息。
当线程注册为中断处理线程后，就要为自己配置待处理的中断源：内核会在Interrupt Router Table里分配一个表条目，并且将条目里的Router Type设置为User-mode(值为1)，将条目里的Service ID里的设置为中断处理线程对应的IST条目编号，EventID由应用程序提供。
本申请实施例提供的Interrupt Router Table将中断触发端和中断处理端进行了解耦，可以支持更加灵活的软件场景，比如，利用用户态中断加速常规同步原语futex，eventfd，pipe，signal等。
图13为本申请一个实施例提供的中断地址空间切换模块示意图。参照图13所示，以下通过三种场景进行说明，具体如下：
第一种场景是用户态中断的处理线程正在CPU上运行，Router Engine直接将中断发送到CPU上，此时在CPU上运行程序被打断，并且从uivector里保存的用户态中断入口开始执行：
步骤1301：将CPU被打断的上下文保存在中断处理栈帧里，包含GPR和PC。
步骤1302：遍历Interrupt Pending buffer里所有设置的比特位，其中，每个设置的比特位对应一个待处理的Event ID。
步骤1303：根据Event ID获取对应的用户态的中断处理函数，然后调用该函数。
步骤1304：将所有待处理的Event ID都处理完毕后，从栈帧里恢复GPR和PC。
步骤1305：调用中断返回指令恢复到被中断的上下文继续执行。
第二种场景是中断处理线程运行在内核态，此时uinoteinfo寄存器的T位为1，Router Engine会往CPU上发送一个Doorbell中断，这个Doorbell中断由内核处理，Doorbell的处理函数主要是：
步骤1311：将中断上下文保存在内核栈帧里，再将内核栈顶地址保存在非安全上下文寄存器UCR里。
步骤1312：检测uinoteinfo.T的值，如果为1，表示中断处理线程在内核态执行，无需切换地址空间。
步骤1313：从uicontext指向的内存里取出用户态中断处理函数(UI_PC)和中断栈帧地址(UI_SP)，构造一个用户态上下文栈帧，其中PC和SP寄存器分别设置为UI_PC和UI_SP。
步骤1314：执行中断返回指令，返回到用户态中断入口函数。
第三种场景是中断处理线程未在CPU上执行，此时uinoteinfo寄存器的V位为0，Router Engine也会往CPU上发送一个Doorbell中断，这个Doorbell的处理流程和第二种场景基本一致，但需要额外执行中断地址空间切换操作：
步骤1321：从uicontext指向的内存里取出中断处理线程所在的页表基地址(ATT_ADDR)。
步骤1322：切换CPU的页表基础地址，为防止转换检测缓冲区(TranslationLookaside Buffer,TLB)的重名问题，还要刷新所有TLB条目。
步骤1323：将中断处理线程暂时固定在当前CPU上，防止被内核迁移到其他CPU上。
基于上述三种场景，第一种场景下调用中断处理函数的开销最低，第三种场景的开销最大，但按图13所示，即使是需要切换地址空间，利用uicontext也可避免开销最大的任务调度环节，整体任务切换开销<100指令周期，如果CPU的主频是2G HZ，这个中断地址空间切换开销<100ns，本申请相比已有的用户态中断方案在第三种场景上有10～20倍性能优势。
图14为本申请一个实施例提供的安全可重入模块示意图。参照图14所示，为了支持用户态中断处理函数，本申请实施例可以实现用户态中断直接打断内核的执行流，并且快速返回到用户态执行中断处理函数，然而会出现导致内核处于一种不可重入状态，如果处理用户态中断过程中使用了内核的任何功能，可能破坏内核状态的问题。为解决上述技术问题，本申请实施例可以通过提供两个寄存器UCR(unsafe context register)和OCR(ongoing context register)，并且在内核里定义若干“安全重入点”和“重入检测点”来保证处理用户态中断的过程能安全的使用内核功能，具体包括以下步骤：
步骤1401：将内核异常处理入口定义为“重入检测点”，将内核返回用户态的点定义为“安全重入点”。
步骤1402：内核被用户态中断打断的上下文保存到一个内存块里，并将内存块地址记录在UCR寄存器里，然后快速返回到用户态执行中断处理函数。
其中，Interrupt Service Table表条目里Interrupt Service Context字段指向一块内存块，这个内存块里保存的数据可以为软件提供快速调用用户态中断处理函数所必须的信息。
步骤1403：内核在“重入检测点”检查UCR，如果UCR值非0表示CPU正处于非安全重入状态，还不能直接使用内核的功能，此时先将内核上下文保存在一个内存块里，并将内存块地址记录在OCR寄存器里，当前内核的执行流被挂起直到内核恢复安全重入状态。
步骤1404：接着通过OCR寄存器取出保存内核上下文的内存块地址，将CPU恢复到这个被打断的现场，让被打断的内核继续执行到“安全重入点”。
步骤1405：当内核执行到“安全重入点”时，此时再通过OCR寄存器恢复被挂起的内核上下文，即第3步，此时内核就可以安全的使用内核的功能。
基于步骤1401至步骤1405，中断地址快速切换和安全可重入模块是本申请软件部分的核心特性，考虑到大部分使用用户态中断的场景，都是中断处理线程处于阻塞状态这种情况，这两个模块提供的快速调用用户态中断处理函数能力，相比其他的用户态中断机制在性能和适用场景上会更有竞争力。
数据面开发套件(Data Plane Development Kit，DPDK)为一种用户态网卡驱动框架，它能提供高性能的网络报文IO处理能力，为了追求高性能，DPDK应用必须一组占用CPU进行轮询操作，在网络比较空闲的时候，CPU将处于空转状态，带来了数据中心的高能耗问题，使用DPDK的中断模式可以降低能耗。
图15为本申请一个实施例提供的DPDK中断模式流程示意图。参照图15所示，在网络空闲时CPU可以进入idle状态，节省能耗，中断模式和轮询模式能耗相差40倍，但DPDK中断模块会带来额外开销，导致网络收发包时时延增加，可能会造成丢包，在云核以及云等关键业务中，高时延以及丢包导致业务性能不可用。
通过在RISC-V环境上加入本申请提供的用户态中断机制，基于Linux内核，将DPDK针对用户态中断模式进行适配，该实施例涉及的组件包括，硬件中断路由引擎，硬件用户态中断调用寄存器，硬件安全可重入寄存器；内核中断事件管理模块、中断路由引擎驱动、中断地址切换模块、安全可重入模块；用户态层的中断线程注册模块、中断事件注册模块。
图16为本申请一个实施例提供的一种软件框架示意图。参照图16所示，DPDK中断模块响应网卡中断的流程包括以下步骤：
步骤1601：DPDK App调用用户态中断线程注册模块，DPDK App提供用于处理用户态中断的函数地址和栈帧地址，对应图中(1)。
步骤1602：DPDK App调用用户态中断注册模块，将某个中断的路由目标设置为本线程，对应图中(2)。
其中，步骤1601和步骤1602都是通过内核的中断事件管理模块完成，具体可以为从内存里的IST和IRT里分配可用表项并对其进行初始化，对应图中(3)(4)。
步骤1603：通过内核的中断路由引擎驱动将分配的IST和IRT表项配置到本申请提供的Router Engine硬件模块里，这个环节需要构造Byte Codes并填充到内存的BytesCode Buffer里并等待Router Engine执行完毕，对应图中(5)(6)。
上述步骤是DPDK App为了利用本申请提供的用户态中断机制必须额外执行的过程，这些环节在DPDK App的生命周期只需执行一次。
步骤1605：每确定DPDK App陷入内核态、被内核调度出或者调入CPU时，内核更新uinoteinfo寄存器。对应图中(7)。
步骤1606：网卡设备触发RX中断，Router Engine硬件模块先接收到中断，然后访问内存的IST和IRT选择中断投递目标。如果DPDK App当前正在CPU上运行，CPU直接跳转到用户态中断函数入口，对应图中(8)。
步骤1607：如果DPDK App阻塞在内核态或者被调度出去了，CPU跳转到内核态的中断地址空间快速切换模块，先保存CPU现场，再执行地址空间切换流程，最后返回到DPDKApp的用户态中断处理函数入口，见图(9)和(10)
图17为本申请实施例提供的DPDK中断模式与用户态中断之间的时延对比图。参照图17所示，传统的DPDK中断模式流程网卡中断、陷入内核、唤醒任务、任务调度、切换页面以及返回用户态后通过DPDK App进行报文处理。然而本申请实施例提供的基于用户态中断实现流程简化，包括网卡中断、陷入内核、切换页表后返回到用户态中断入口函数。相比而言，传统的DPDK中断模式响应内核态中断转发时，其对应的响应时延为16000～18000cycles，然而本申请实施例提供的基于用户态中断响应用户态中断调用时，其对应的响应时延为500～1500cycles，减小了中断响应时延。
本申请实施例还提供一种中断控制器，包括：处理器和存储器，所述存储器用于存储至少一条指令，所述指令由所述处理器加载并执行时以实现本申请任一实施例提供的中断处理方法。
本申请实施例还提供一种中断控制器，包括：用户态中断路由引擎和用户态中断快速调用引擎；用户态中断快速调用引擎包括：用户态中断备忘信息寄存器，用于记录当前处理器运行线程的状态信息；中断控制器确定中断线程在处理器上运行时，基于用户态中断备忘信息寄存器记录的当前处理器运行线程的状态信息，若确定当前线程在用户态运行，则向处理器投递用户态中断，并基于用户态中断向量寄存器存储的地址读取指令，在用户态执行中断处理函数。
在一种实施方式中，用户态中断快速调用引擎还包括：用户态中断上下文寄存器，用于记录内存地址；其中，基于用户态中断备忘信息寄存器的记录信息，若确定用户态中断备忘信息寄存器的终端线程陷入内核标记非第一状态，和/或用户态中断备忘信息寄存器的中断线程是否在线标记非第二状态，则将中断服务程序表条目的处理中断上下文填入用户态中断上下文寄存器，并向处理器投递门铃中断。本申请实施例提供的中断控制器中引入的用户态中断备忘信息寄存器和用户态中断上下文寄存器，进而可以实现允许内核快速切换到中断处理线程所在地址空间。
本申请实施例还提供一种电子设备，该电子设备可以包括上述中断控制器，从而通过该中断控制器实现上述中断控制方法。
本申请实施例还提供一种计算机刻度存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现本申请任一实施例提供的中断处理方法。
可以理解的是，所述应用可以是安装在终端上的应用程序(nativeApp)，或者还可以是终端上的浏览器的一个网页程序(webApp)，本申请实施例对此不进行限定。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机装置(可以是个人计算机，服务器，或者网络装置等)或处理器(Processor)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。
最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (11)

1.一种中断处理方法，其特征在于，所述方法包括：
确定中断线程在处理器上运行时，基于用户态中断备忘信息寄存器记录的当前处理器运行线程的状态信息，若确定当前线程在用户态运行，则向所述处理器投递用户态中断，并基于用户态中断向量寄存器存储的地址读取指令，在用户态执行中断处理函数。
2.根据权利要求1所述的方法，其特征在于，所述基于用户态中断备忘信息寄存器的记录信息，确定当前线程在用户态运行包括：
确定所述用户态中断备忘信息寄存器的终端线程陷入内核标记为第一状态，并且所述用户态中断备忘信息寄存器的中断线程是否在线标记为第二状态，则确定当前线程在用户态运行。
3.根据权利要求1所述的方法，其特征在于，所述确定当前线程在用户态运行之前还包括：
基于用户态中断备忘信息寄存器的记录信息，确定当前线程是否在用户态运行；
其中，基于用户态中断备忘信息寄存器的记录信息，若确定所述用户态中断备忘信息寄存器的终端线程陷入内核标记非第一状态，和/或所述用户态中断备忘信息寄存器的中断线程是否在线标记非第二状态，则将中断服务程序表条目的处理中断上下文填入用户态中断上下文寄存器，并向所述处理器投递门铃中断。
4.根据权利要求1所述的方法，其特征在于，所述确定中断线程在处理器上运行时之前，还包括：
确定中断服务表中的待处理中断列表与所述用户态中断备忘信息寄存器的待线程处理中断信息是否相同，若相同则确定中断线程在处理器上运行。
5.根据权利要求4所述的方法，其特征在于，若确定中断服务表中的待处理中断列表与所述用户态中断备忘信息寄存器的待线程处理中断信息不相同，则将中断服务程序条目的中断服务上下文填入用户态中断上下文寄存器，并向所述处理器投递内核门铃中断。
6.根据权利要求1所述的方法，其特征在于，所述确定中断线程在处理器上运行时之前，还包括：
确定所述处理器陷入内核态时，在安全检测点检测非安全上下文寄存器的值，若确定处理器处于非安全冲入状态，则将内核上下文保存在设定内存，并将所述设定内存的地址记录在被挂起上下文寄存器，其中，所述安全检测点为内核异常处理入口；
基于所述被挂起上下文寄存器记录的所述设定内存的地址，将处理器恢复到被打断的现场，并使被打断的内核继续执行安全重入点，其中，所述安全重入点为内核返回用户态的点；
在内核执行到所述安全重入点时，通过所述被挂起上下文寄存器恢复被挂起的内核上下文。
7.一种中断控制器，其特征在于，所述中断控制器包括：
处理器和存储器，所述存储器用于存储至少一条指令，所述指令由所述处理器加载并执行时以实现如权利要求1-6中任意一项所述的中断处理方法。
8.一种中断控制器，其特征在于，所述中断控制器包括：用户态中断路由引擎和用户态中断快速调用引擎；
所述用户态中断快速调用引擎包括：用户态中断备忘信息寄存器，用于记录当前处理器运行线程的状态信息；
所述中断控制器确定中断线程在处理器上运行时，基于用所述户态中断备忘信息寄存器记录的当前处理器运行线程的状态信息，若确定当前线程在用户态运行，则向所述处理器投递用户态中断，并基于用户态中断向量寄存器存储的地址读取指令，在用户态执行中断处理函数。
9.根据权利要求8所述的中断控制器，其特征在于，所述用户态中断快速调用引擎还包括：用户态中断上下文寄存器，用于记录内存地址；
其中，基于用户态中断备忘信息寄存器的记录信息，若确定所述用户态中断备忘信息寄存器的终端线程陷入内核标记非第一状态，和/或所述用户态中断备忘信息寄存器的中断线程是否在线标记非第二状态，则将中断服务程序表条目的处理中断上下文填入用户态中断上下文寄存器，并向所述处理器投递门铃中断。
10.一种电子设备，其特征在于，所述电子设备包括权利要求8或9所述的中断控制器。
11.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-6中任意一项所述的中断处理方法。
CN202210803080.9A 2022-07-07 2022-07-07 中断处理方法、电子设备和存储介质 Pending CN117407054A (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202210803080.9A CN117407054A (zh) 2022-07-07 2022-07-07 中断处理方法、电子设备和存储介质
PCT/CN2023/103632 WO2024007934A1 (zh) 2022-07-07 2023-06-29 中断处理方法、电子设备和存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210803080.9A CN117407054A (zh) 2022-07-07 2022-07-07 中断处理方法、电子设备和存储介质

Publications (1)

Publication Number Publication Date
CN117407054A true CN117407054A (zh) 2024-01-16

Family

ID=89454259

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210803080.9A Pending CN117407054A (zh) 2022-07-07 2022-07-07 中断处理方法、电子设备和存储介质

Country Status (2)

Country Link
CN (1) CN117407054A (zh)
WO (1) WO2024007934A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117670649A (zh) * 2024-01-30 2024-03-08 南京砺算科技有限公司 元数据写入及读取方法、图形处理单元

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9519532B2 (en) * 2014-01-20 2016-12-13 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Handling system interrupts with long-running recovery actions
WO2017070861A1 (zh) * 2015-10-28 2017-05-04 华为技术有限公司 一种中断响应方法、装置及基站
CN113010275B (zh) * 2019-12-20 2024-01-30 大唐移动通信设备有限公司 一种中断处理方法和装置
CN112231007B (zh) * 2020-11-06 2022-08-19 中国人民解放军国防科技大学 基于用户态与内核态驱动协同处理框架的设备驱动方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117670649A (zh) * 2024-01-30 2024-03-08 南京砺算科技有限公司 元数据写入及读取方法、图形处理单元

Also Published As

Publication number Publication date
WO2024007934A1 (zh) 2024-01-11

Similar Documents

Publication Publication Date Title
CN100570565C (zh) 在管理程序中提供基于策略的操作系统服务的方法和系统
US9396013B2 (en) Method for controlling a virtual machine and a virtual machine system
EP0945797B1 (en) Method and apparatus for object-oriented interrupt system
US9798595B2 (en) Transparent user mode scheduling on traditional threading systems
US7406699B2 (en) Enhanced runtime hosting
US20020161957A1 (en) Methods and systems for handling interrupts
US7149832B2 (en) System and method for interrupt handling
US4685125A (en) Computer system with tasking
KR101400286B1 (ko) 다중 프로세서 시스템에서 작업을 이동시키는 방법 및 장치
EP2182438A1 (en) Virtual machine control method and virtual machine system
JP2000330806A (ja) 計算機システム
JP2000242512A (ja) 複数のオペレーティングシステムを実行する計算機
JP2004536382A (ja) 置換可能なサービス品質機能のあるネットワーク通信チャネルコンポーネントを選択するために、置換可能なコンポーネントを用いるシステム、方法及び製造物
US20020052911A1 (en) Finite state machine in a portable thread environment
JP2004501407A (ja) 呼出し元アドレスを使用した安全なソフトウェアｓｍｉディスパッチング
WO2024007934A1 (zh) 中断处理方法、电子设备和存储介质
CN114003363B (zh) 线程间中断信号发送方法及装置
EP0290942B1 (en) Guest machine execution control system for virtual machine system
US20030014558A1 (en) Batch interrupts handling device, virtual shared memory and multiple concurrent processing device
CN109445959A (zh) 一种传感器数据处理实时操作系统
Mutia Inter-Process Communication Mechanism in Monolithic Kernel and Microkernel
US7320044B1 (en) System, method, and computer program product for interrupt scheduling in processing communication
CN113791898B (zh) 一种基于TrustZone的可信微内核操作系统
CN113032154B (zh) 一种虚拟cpu的调度方法、装置、电子设备及存储介质
US11782713B1 (en) Security vulnerability mitigation using address space co-execution

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication