为验证x86 hypervisor性能问题，求x86_64 Linux中断生成方案

针对你要验证hypervisor被无关中断打断的场景，直接通过本地APIC发送IPI（处理器间中断）是最贴合需求的方案——IPI是x86多处理器系统原生的跨CPU中断机制，完全模拟外部设备/无关进程触发的异步中断，能精准控制投递频率，且中断处理可以做到极简，完全聚焦在中断投递强度上。

核心方案：用APIC发送IPI #

IPI的工作机制和你场景中的“无关中断”完全一致：它由其他CPU主动投递，目标CPU会触发硬件级的中断响应流程，包括中止正在执行的长指令（比如VMX的VMEnter），完美匹配你的测试目标。

具体实现步骤（内核模块） #

1. 定位目标CPU的APIC ID #

在Linux内核里，直接通过cpu_data(cpu).apicid获取hypervisor所在CPU的APIC ID，cpu是目标核心的编号（可通过/proc/cpuinfo查看）。

2. 注册极简中断处理函数 #

申请一个未被占用的中断向量，注册一个只做最基础确认的处理函数，确保单中断耗时可忽略：

#include <linux/interrupt.h>

static irqreturn_t dummy_irq_handler(int irq, void *dev_id) {
    // 仅确认中断，无额外逻辑
    return IRQ_HANDLED;
}

// 动态分配中断向量
int irq = alloc_irq(0, 0, IRQF_NO_THREAD, "dummy-irq", dummy_irq_handler);
if (irq < 0) {
    // 处理分配失败逻辑
}

3. 循环发送IPI控制频率 #

使用内核提供的IPI发送接口，向目标CPU投递中断：

• 现代Linux内核推荐用ipi_send_single（需包含<asm/apic.h>），传入目标APIC ID和分配到的中断向量。
• 要实现1k/10k/100k/1M级别的每秒中断，可在绑定到非目标CPU的高优先级内核线程中循环发送，配合高精度定时器或延迟函数控制间隔：

#include <linux/kthread.h>
#include <linux/delay.h>

static int ipi_sender_thread(void *data) {
    unsigned int target_apicid = *(unsigned int *)data;
    int irq = ...; // 之前分配的中断向量
    unsigned int freq = 1000000; // 1M次/秒
    unsigned long interval_ns = 1000000000 / freq;

    set_current_state(TASK_RUNNING);
    while (!kthread_should_stop()) {
        ipi_send_single(target_apicid, irq);
        // 控制发送间隔
        ndelay(interval_ns);
    }
    return 0;
}

• 如果是极高频率（比如1M/s），可以在单次循环中批量发送多个IPI，减少循环本身的开销。

4. 绑定线程到固定CPU #

将发送IPI的内核线程绑定到非目标CPU，避免发送逻辑占用目标CPU资源，影响测试结果：

struct task_struct *sender_thread = kthread_run(ipi_sender_thread, &target_apicid, "ipi-sender");
if (sender_thread) {
    set_cpus_allowed_ptr(sender_thread, cpumask_of(1)); // 绑定到CPU 1，假设目标是CPU 0
}

为什么不选其他方案？ #

• 虚拟设备中断：比如用virtio等虚拟设备触发中断，虽然更贴近真实场景，但无法精准控制中断频率，且设备驱动会引入额外开销，不符合“单中断处理无耗时”的要求。
• 用户态信号：用户态信号属于软件层面的通知，不会触发CPU的硬件中断响应流程，根本无法中止hypervisor的长指令，完全不匹配测试需求。

关键注意事项 #

• 内核模块需要root权限加载，代码要符合Linux内核编程规范，避免触发panic。
• 动态分配中断向量时，要检查返回值确保向量未被占用；也可以手动选择系统预留的向量（0x20以上的非异常向量）。
• 对于1M/s级别的高频中断，推荐使用Linux实时内核（PREEMPT_RT），减少调度延迟带来的频率误差。
• 测试时通过/proc/interrupts或perf stat -e interrupts监控目标CPU的实际中断计数，验证投递频率是否符合预期。

内容的提问来源于stack exchange，提问作者Grigory Rechistov