MSI-X虚拟化详解：直通与virtio中断机制及性能优化实践

1. 从一次虚拟机的"莫名卡顿"说起

前阵子有个把物理机迁移到虚拟化的项目，迁移完之后，业务侧反馈说网络吞吐上去了，但CPU使用率也跟着上去了，而且某些应用出现偶发的延迟毛刺。刚开始大家怀疑是驱动问题，换了好几个网卡驱动版本，问题依旧。后来我直接在虚拟机里查看中断分布，发现所有网卡中断几乎都落在同一个CPU上，其他核闲着，一个核在拼命干活。这时候我才意识到，问题出在虚拟化环境下的中断处理链路上，而"MSI-X 虚拟化"这个平时不太起眼的技术细节，恰恰是决定直通设备性能表现的关键。

先给不太熟悉这块的读者补个背景。MSI-X（Message Signaled Interrupts eXtended）是PCIe设备向CPU发送中断的一种机制，和传统的中断引脚（INTx）相比，它的优势在于每个设备可以拥有多达2048个独立中断向量，每个向量可以独立配置目标CPU，这为多队列网卡、NVMe控制器这类高并发设备提供了天然的并行基础。物理机上，操作系统可以直接操纵MSI-X表，把不同队列的中断绑定到不同CPU核心上。但在虚拟机里，事情就没这么简单了——中断要穿过虚拟化层，从硬件设备到虚拟机里的中断控制器，再到客户机操作系统，每一步都可能成为性能瓶颈。

这篇文章会把MSI-X虚拟化这件事从硬件原理讲到实际调优，内容包括：为什么虚拟化环境下中断会拖垮性能、直通（passthrough）和半虚拟化（virtio）两条路径下MSI-X的处理方式有何不同、KVM/QEMU里常见的中断投递配置怎么选、以及我在实测中总结出的一套排查思路。适合正在做虚拟化性能调优、搞云平台基础设施，或者单纯想把虚拟机网络性能压榨到极限的读者。

2. MSI-X的硬件机制，先搞清楚再谈虚拟化

2.1 从INTx到MSI-X：中断机制演进的核心逻辑

传统PCI设备使用INTx引脚发送中断，每个设备最多只能有4个中断引脚（INTA到INTD），而且多个设备可能共享同一条中断线。共享中断意味着设备触发中断时，内核需要逐个调用所有注册在该中断线上的中断处理函数去匹配设备，这就是所谓的"中断风暴"和"虚假中断"问题。吞吐一高，CPU光处理中断就要消耗大量资源。

MSI（第一代消息中断）解决了共享问题，但每个设备最多只能支持32个中断向量，而且所有向量只能分布在同一组CPU上。到了MSI-X，规格直接拉满：最多2048个向量，每个向量都可以通过MSI-X Table（存放在设备BAR空间的一段内存区域）中的Entry来独立配置消息地址（Message Address）和消息数据（Message Data），操作系统往这些地址写指定数据，设备就会产生一个定向到目标CPU的中断消息。

用个生活化的类比：INTx就像小区只有一个总信箱，邮递员每次把信投进去，全楼的人都得下来翻一遍是不是自己的；MSI把信箱分成了多个房间，但所有房间都在同一栋楼；MSI-X则是每个房间有了自己独立的邮箱地址，邮递员可以直接把信送到对应房间门口。对于支持多队列的网卡，每个队列一个中断向量，这是MSI-X最重要的应用场景。

2.2 MSI-X Capability结构和表项布局

MSI-X在PCIe配置空间中位于Capability列表里，Capability ID为0x11。它包含以下关键字段：

• Message Control：最高位的Table Size字段指明MSI-X Table项数减1，另一个重要标志是Function Mask，置位后设备所有MSI-X中断被屏蔽。
• Table Offset和Table BIR（BAR Indicator Register）：指明MSI-X Table在设备哪个BAR区域、偏移多少。
• PBA Offset和PBA BIR：Pending Bit Array（待处理位数组）的位置，用于记录尚未送达CPU的中断向量。

每个MSI-X Table Entry是16字节，结构如下：

偏移0x0：Message Address Low（32位） 偏移0x4：Message Address High（32位） 偏移0x8：Message Data（32位） 偏移0xC：Vector Control（32位，bit0为Mask）

当设备的某个队列产生事件时，设备向Message Address写入Message Data，CPU会把这个操作当作一次中断消息投递。如果目标CPU正在处理更高优先级的事情，设备会把这个中断标记到PBA对应位，等CPU空闲了再补充投递。

2.3 为什么物理机上这机制很完美，虚拟化就出问题

物理机上，MSI-X的配置完全由操作系统和设备驱动协作完成。驱动读取设备的MSI-X Table，为每个队列分配一个中断向量，然后通过内核接口把这些向量绑定到各个CPU的本地APIC上。

虚拟化环境里，设备要么直通给虚拟机（PCIe passthrough），要么由宿主机模拟/半虚拟化。直通模式下，客户机驱动想直接操作真实设备的MSI-X Table，但客户机里写入的Message Address是客户机的物理地址，这个地址对宿主机来说毫无意义——设备在宿主机眼里是真实存在的，它收到的中断消息地址必须指向宿主机的某个CPU/中断控制器。于是就需要一个翻译环节：客户机写入的中断路由信息，要被宿主机截获并转换成宿主机可以理解的目标CPU编号。这个翻译过程怎么实现、转换粒度如何、开销大不大，直接决定了中断投递的延迟和吞吐上限。

半虚拟化（virtio）模式下，设备是虚拟的，MSI-X Table也是虚拟的，但虚拟中断照样要映射到宿主机的真实中断源（eventfd + irqfd机制），只不过少了一层真实设备寄存器的访问开销，而多了一层ioeventfd/irqfd的事件通知。

可以说，MSI-X虚拟化本质上解决的是"客户机视角的中断模型"和"宿主机物理中断模型"之间的鸿沟问题。接下来就分别看这两条路径的具体实现。

3. 直通模式下的MSI-X虚拟化：中断重映射的完整链路

3.1 直通设备的中断投递路径：从设备到客户机

先看一个典型的PCIe直通网卡数据接收路径。数据包到达物理网卡，网卡按RSS（Receive Side Scaling）哈希到某个队列，该队列关联的MSI-X中断被触发。在虚拟化场景下，这个中断不直接发给某个物理CPU，而是先到达中断控制器（IOMMU或VT-d的中断重映射硬件），由硬件根据重映射表把这次中断翻译成一次面向指定vCPU的中断注入操作。

这里的关键硬件是VT-d的Interrupt Remapping（中断重映射）。它维护一张由软件（通常是宿主机内核）配置的重映射表，表项包含"源设备ID+中断向量"到"目标CPU+中断向量"的映射关系。当设备发起中断请求时，中断控制器查询这张表，找到对应的目标CPU，并把中断发送过去。如果目标vCPU刚好在某个物理CPU上运行，这个中断就能直接被投递到该物理CPU，然后转发给虚拟机。

简单说这个过程：虚拟机的MSI-X Table仍然是真实的（因为设备被直通），客户机驱动写入的Message Address并不是最终的目标地址，而是被IOMMU映射成了中断重映射格式。客户机以为自己写的是物理地址，但实际上这个地址会被中断重映射硬件拦截并翻译。

3.2 Intel VT-d和AMD IOMMU的实现差异

两家厂商的实现思路类似，但细节有差异。Intel VT-d通过Interrupt Remapping Table（IRT）实现，表项格式固定，包含"present标志、目标APIC ID、中断向量、Delivery Mode"等信息。AMD IOMMU则通过Device Table entries和Interrupt Remapping Table协作完成，实现机制更复杂一点，但能力类似。

实际运维中，影响最大的是：是否启用了x2APIC模式。x2APIC模式下，中断重映射支持最多32位APIC ID空间，适用于超过256个CPU的大规模服务器。如果你的宿主机是双路或四路服务器，逻辑CPU数量很多，一定要确认BIOS里x2APIC已经打开，否则中断重映射可能退回到传统模式，某些CPU无法接收中断，VM的CPU亲和性就白配置了。

另一个实用细节：不是所有平台都支持直通设备的中断重映射。要检查VT-d是否激活，Linux下可以通过dmesg或者以下方式确认：

# 检查内核是否支持VT-d dmesg | grep -i 'DMAR: IOMMU enabled' # 查看IOMMU中断重映射能力 cat /proc/interrupts

如果第一行没有输出，说明IOMMU可能没有启用。你需要在GRUB内核参数中加上intel_iommu=on（Intel平台）或iommu=pt（Passthrough模式），AMD平台对应是amd_iommu=on。

我遇到过不止一次：宿主机BIOS默认把VT-d关闭了，直通设备能装上，但中断全部走一条共享路径，性能比不直通还差。这种问题隐蔽性很强，排查手段就是看中断分布，如果发现所有设备中断都涌到CPU0，而CPU0的软中断占用接近100%，十有八九是重映射没生效。

3.3 IRQ保护和投递模式选择

中断重映射除了翻译功能，还承担保护职责：防止客户机通过伪造MSI-X消息绕过虚拟机监控器直接攻击物理CPU（这是裸设备直通最大的安全隐患）。所以重映射表项的添加、修改、删除必须由宿主机内核控制，客户机对MSI-X Table的访问实际上是通过VM-Exit（虚拟机退出）陷入到宿主机处理，而不是真正的MMIO直写。

这意味着客户机每次修改MSI-X表项配置，都会有VM-Exit的开销。对于网卡驱动在初始化时设置大量队列中断的场景，这个开销集中在启动阶段，可以接受。但如果某个应用在运行期频繁调整队列、绑核，这种"每次写操作都触发VM-Exit"的模式就会变成性能瓶颈。我的建议是：把这些频繁操作尽量放到初始化阶段一次完成，运行期不要频繁增删队列。

投递模式还有两种选择：固定投递（Fixed）和低优先级投递（Lowest Priority）。虚拟化场景下推荐使用Fixed模式搭配目标vCPU的APIC ID，因为Lowest Priority依赖仲裁机制，在不同厂商硬件上行为不一致，容易出现中断分配不符合预期的情况。在配置直通设备时，如果客户机里看到某些CPU中断负载不均衡，检查一下是否是客户机中断控制器处于低优先级模式。

4. virtio设备的MSI-X处理：虚拟中断路径上的"翻译官"

4.1 virtio的中断模型简介

virtio是半虚拟化I/O标准，虚拟机里的驱动通过共享内存和vhost后端通信，减少真实设备模拟的开销。virtio-pci（这里讨论1.0以上规范）暴露一个PCI设备，但它不是真实硬件，MSI-X Table也是由QEMU/KVM虚拟出来的。

当virtio设备需要通知虚拟机"有数据到账"时，vhost后端通过eventfd机制通知QEMU/KVM，KVM再把一个虚拟中断注入到目标vCPU。vmxnet3和virtio的区别在于：vmxnet3更接近真实硬件模拟（在VMware环境下优化），virtio则是一种开放标准，各种hypervisor都能用。从MSI-X角度看，virtio的实现更干净，因为它以标准PCIe设备形式暴露MSI-X能力，客户机不需要知道太多底层细节。

4.2 irqfd和ioeventfd：中断注入的加速器

中断注入性能是virtio能否跑满线速的关键。KVM提供两个内核侧加速机制：ioeventfd用于配置型事件通知（例如客户机写I/O端口通知有新的buffer要提交），irqfd用于向客户机注入虚拟中断。

irqfd的实现原理：vhost后端关联一个eventfd，KVM内核在中断事件发生时直接根据irq routing表找到目标vCPU，向该vCPU注入中断。这个过程中不需要唤醒QEMU用户态进程，所以延迟可以做到微秒级。

配置virtio网卡时，打开multi-queue模式（虚拟机多队列，mqueue），每个队列需要独立的MSI-X中断向量。QEMU命令行里通常根据虚拟机配置自动分配，但在某些老版本QEMU里，如果队列数超过MSI-X向量上限，会自动退化成单队列，性能骤降。我建议确认QEMU版本较新（至少4.2以上）再使用多队列，同时查看虚拟机里中断号数量来判断是否分配成功。

4.3 从客户机视角看中断亲和性：需要手动处理的细节

virtio中断虽然由KVM注入，但客户机内核看到的中断号和中断控制器仍是虚拟的。客户机里的irqbalance可能完全无法感知到底层物理CPU的拓扑，因此它做的CPU负载均衡往往是"盲人摸象"。我习惯在客户机里关掉irqbalance，手动把网卡的中断亲和性固定到有限的几个CPU上：

# 关闭irqbalance systemctl stop irqbalance # 查看virtio网卡的MSI-X中断号 cat /proc/interrupts | grep virtio0 # 手动设置亲和性: 示例将第一个中断绑定到CPU0和CPU1 echo 3 > /proc/irq/43/smp_affinity

这里有个容易被忽略的点：virtio的MSI-X中断在KVM里最终会落在某个物理CPU上。如果宿主机对vCPU做了CPU pinning（固定到物理核），那么中断注入大概率直接投递到vCPU所在的物理CPU，延迟最低。如果vCPU在多个物理CPU间浮动调度，中断注入可能要等vCPU被调度到某个CPU后才能处理，延迟抖动明显。所以对延迟敏感的工作负载，务必给虚拟机的vCPU绑定物理核。

4.4 直通 vs virtio：什么时候选哪种

很多人在做架构选型时纠结：到底用直通（VFIO passthrough）还是virtio？从MSI-X虚拟化实现角度给个客观对比：

从我的实测来看，如果追求极致的PPS（包每秒）处理能力，直通设备在中高负载下的稳定性比virtio好，尤其是当宿主机CPU有NUMA跨节点访问时，直通配合中断重映射可以做到确定性的低延迟。如果只是普通业务，virtio多队列完全够用，而且它支持热迁移（直通设备热迁移限制很多），运维灵活性更高。选择路径前，先搞清楚你的核心诉求是"性能确定性"还是"运维灵活"，两个都要很难。

5. 实战调优记录：中断分布、NUMA亲和性和性能对照

5.1 实验环境与基线测试

以下是我在某公司内部云平台做的一个模拟项目（下文称"某虚拟化调优项目"）中的实测数据，配置仅供参考：宿主机为双路服务器（两个NUMA节点，每节点16物理核），网卡为双口25GbE，开启32队列。Hypervisor侧使用KVM/QEMU，客户机为Linux，使用同样版本的网卡驱动。测试工具用perf和简单的TCP_STREAM基准。

基线配置（不做任何调优，默认virtio单队列）下，单TCP流吞吐约17Gbps，CPU0软中断占用100%，其他CPU占用率不足5%。这显然不对——25G网卡只跑出17G，明显是中断处理瓶颈导致的。所有中断都落在CPU0，因为默认irqbalance没启用、驱动把所有队列中断绑到了CPU0。

5.2 中断亲和性调整的三个步骤

第一步是在宿主机上确认网卡设备名和队列数。对于直通设备：

# 查看网卡队列中断 cat /proc/interrupts | grep ens3f0 # 确认网卡支持的最大队列数 ethtool -l ens3f0

输出会显示当前Combined队列数和最大Combined队列数。要调整队列数，需要用ethtool设置：

ethtool -L ens3f0 combined 32

第二步根据NUMA拓扑设计中断绑定矩阵。假设机器有两个NUMA节点，网卡插在节点0的PCIe槽位上，那么网卡的中断最好分布在节点0的CPU上，避免跨节点访问。如果中断绑到节点1的CPU，设备的中断请求从节点0的IOMMU到节点1的APIC，延迟可能增加几十纳秒，量级不大，但高PPS应用会放大这个差距。

绑定方法：用脚本把每个队列中断依次绑定到一组CPU上。常见做法：

# 示例: 中断号190为第一个队列，按顺序绑定到CPU 0,2,4,6... mask=1 for irq in $(seq 190 221); do echo $mask > /proc/irq/$irq/smp_affinity mask=$((mask << 1)) if [ $mask -gt 128 ]; then mask=1; fi done

注意smp_affinity的值是一个十六进制位图，bit0对应CPU0。如果你的CPU超过64个，这个简易脚本要适配到CPU列表数组，网上有很多工具可以做，但我更推荐直接用irqbalance配合手动覆盖，或者QEMU自带的using_msi脚本思路。

第三步在客户机里做同样的操作。virtio多队列生成的MSI-X中断号，同样需要客户机内核做亲和性配置。如果客户机的vCPU已经在宿主机被pin到确定物理核，那客户机中断亲和性和宿主机中断亲和性要配合。以virtio 4队列为例，把4个中断分别绑到客户机的vCPU 0~3，而宿主机保证这4个vCPU各自对应独立的物理核。这样中断的"最后一跳"没有跨核调度，延迟可控。

5.3 调优后的性能数据对比

调优完成后，我重新跑同一套性能测试，结果如下：

这个结果挺有参考价值：virtio通过多队列+亲和性调整，已经能逼近直通设备的吞吐水平。两者差距主要在延迟抖动上——直通模式下因为中断直接由硬件投递，不需要经过KVM的evfd唤醒流程，所以抖动更小。如果你的客户机跑的是DPDK或对时延极其敏感的用户态协议栈，直通是唯一选择。但对于普通内核协议栈，virtio多队列完全足够。

5.4 NUMA拓扑感知的中断配置建议

配置中断时要看完整的硬件拓扑，不能只看CPU编号。我的建议是先读取网卡所在的NUMA节点：

cat /sys/class/net/ens3f0/device/numa_node # 输出例如 0，表示网卡位于NUMA节点0

然后只从该节点的CPU列表里选择目标CPU。同时考虑该节点上PCIe控制器的负载：中断目标CPU最好不要跨内存控制器访问。举个例子，双路服务器节点0有16个核，网卡在节点0，那中断应该绑定到CPU0-15上。如果你把中断绑到节点1的某些CPU上，从IOMMU到节点1的APIC要经过跨节点链路，时延和带宽都有影响。

另外一个小细节：有超线程的服务器上，网卡中断建议只绑物理核，不要绑逻辑核（即同一个物理核的第二个线程）。这样当物理核执行其他任务时，逻辑核的中断处理可能产生额外的竞争和迁移。

6. 问题排查套路：MSI-X虚拟化场景下的常见故障与根因

6.1 症状一：虚拟机吞吐量比宿主机直连低一半

这个现象最常见。排查链路如下：

先看虚拟机内部的中断分布：

cat /proc/interrupts | grep -E 'eth0|virtio0'

如果所有中断都在CPU0或相同少数几个CPU上，那么先检查客户机是否安装了irqbalance且处于运行状态，irqbalance有时候在虚拟机里不会自动分配MSI-X中断，反而把所有中断集中在某些CPU。卸载它，手动配置亲和性。

如果客户机中断均匀但吞吐仍然低，回宿主机看CPU开销。用perf top观察宿主机的软中断处理占比，如果是softirq的net_rx_action占大头，可能是virtio的后端vhost线程本身在单个CPU上处理。针对这种情况，QEMU的vhost线程默认每个虚拟机一个工作线程（单线程模式），多队列下需要开多个vhost线程配合。使用较新的内核和QEMU，打开vhost多线程模式（vhost=on,多队列场景下vhost会按队列创建线程）。

另一种可能：直通设备时，IOMMU页表未开启直通（passthrough）模式，导致每次DMA都需要页表翻译，增加了内存访问开销。这时候在中核参数里加入iommu=pt，让DMA直接访问物理内存而不是经过IOMMU页表翻译，吞吐可能立刻提升几个百分点。

6.2 症状二：虚拟机内部出现"中断风暴"或CPU占用虚高

现象是CPU idle只有30%，但业务负载很低。打开/proc/interrupts，发现某个中断计数增长极快。这种情况多见于virtio场景，原因是客户机驱动和vhost后端在某些错误路径上产生"中断重触发"循环。

一个常见根因是MSI-X向量配置了但PCIe设备的中断屏蔽位没有正确维护，导致中断根本没有被真正注入，而是被KVM用轮询的方式不断探测pending状态。解决方法是升级客户机的virtio驱动，并在QEMU侧检查msi=on和msix=on配置是否显式开启。老版本QEMU默认msix可能关闭，导致virtio只能用INTx，中断处理路径从"事件通知"退化为"轮询"，CPU虚高就是必然的。

我排查这类问题时会先执行：

# QEMU侧确认设备是否启用了MSI-X virsh dumpxml vm_name | grep -i msi # 客户机侧查看设备能力 lspci -vvv | grep -i msix

如果输出中没有MSI-X相关标记，说明当前路径在使用INTx，性能差距会非常大。

6.3 症状三：宿主机dmesg刷中断重映射错误

直通设备时，dmesg可能出现类似"IOMMU interrupt remapping failed"或者"DMAR:[INTR-REMAP] Request device"的错误。这类错误通常和中断重映射表项申请失败有关。结合我排查过的案例，原因多数是：目标vCPU对应的APIC ID已超过重映射表支持的上限，或者hugepage分配导致的地址映射问题。

排查时先去BIOS确认Interrupt Remapping（Intel平台叫Interrupt Remapping，AMD平台叫IOMMU或GA）已经开启。如果BIOS无法开启（某些低端板子默认不支持），直通设备基本只能放弃，算力再强也没用。

另一个很少人注意到的坑：IOMMU的DMA重映射（DMA Remapping）和中断重映射是两套独立的机制。开启iommu=on并不等于中断重映射也一定开启。要确认中断重映射生效，查看dmesg中是否包含"Interrupt remapping enabled"。如果只看到DMA Remapping enabled而中断重映射没出现，需要检查内核是否又加上了intremap参数（在有IRQ remapping硬件时默认开启，但有些BIOS配置会把它关掉）。

6.4 排查工具推荐

我常用的工具按优先级排序：

1. /proc/interrupts——最直接的中断计数和亲和性查看入口。
2. perf sched和perf kvm stat——分析KVM exit原因和事件注入耗时。
3. ethtool -S统计——查看网卡队列收发包错误、队尾drop。
4. trace-cmd或者bpftrace——抓取irqfd/ioeventfd事件路径延迟。
5. virsh vcpupin和virsh iothreadinfo——查看vCPU和IO线程的CPU绑定状态。

有一回我抓到一个延迟抖动问题：宿主机上某个CPU间歇性跑定时器任务，导致vCPU被抢占，注入的中断必须等vCPU重新调度才能处理。通过bpftrace抓sched_wakeup和irq_injection两个事件，很快定位到是宿主机某个cron任务的高负载造成的。虚拟化调优往往不只是看虚拟化自身配置，宿主机层面的进程调度、内核参数同样重要。

7. 选型思路与经验沉淀

7.1 先定目标再选路径

如果你问我"到底该用直通还是virtio"，我通常反过来问两个问题：第一，你的业务能不能接受虚拟机热迁移的不便？直通设备通常绑定物理设备，热迁移要么依赖高级特性（比如某些厂商的SR-IOV热迁移方案），要么根本不可行。第二，你的延迟敏感度到底是多少？如果业务只需要"稳定、不抖动"但绝对值要求不高（比如小于100us即可），virtio配上多队列和绑核完全够用。如果追求的是微秒级确定性（比如高频交易领域的基础设施），直通的硬件直达链路优势短期无法替代。

从MSI-X虚拟化的实现细节看，virtio的路径更容易被软件优化，因为它的中断注入和设备通知都是软事件，未来可以配合用户态中断、更精细的调度器做优化。而直通依赖于硬件IOMMU的中断重映射能力，软件能做的主要是配置和规避，优化空间反而有限。但硬件能力的稳定性和确定性是软件难以超越的，这是直通的长久优势。

7.2 我踩过的最值得分享的几个坑

最后一个部分，分享几个项目推进过程中积累的经验：

一是关于"队列数越多越好"的误解。我见过有人把网卡队列数调到最大，然后在虚拟机里只跑一个TCP连接，结果性能不升反降。因为单流只能使用一个队列，多队列的额外中断向量增加了中断数，CPU反而更忙。多队列适合多并发流的场景（比如Web服务器、分布式存储），单流场景把队列数调成1-2就好。

二是关于"客户机里绑完核就万事大吉"的误区。客户机的亲和性只是"虚拟CPU到虚拟中断"的关系，真正决定中断落到哪个物理CPU的是宿主机对vCPU的调度。所以绑核必须从宿主机层面配合vcpupin，否则客户机看到的一切都可能是"虚的"。我经常和团队说一句话："客户机看到的物理CPU，只是宿主机让你看到的物理CPU。"

三是关于"中断重映射开启后性能一定好"的想当然。开启中断重映射只是"可以使用MSI-X直通"的必要条件，不是充分条件。真正影响性能的还包括：PCIe设备是否处于正确的NUMA节点、系统是否开启x2APIC模式、vCPU绑核是否平衡、虚拟机的内存是否用hugepages减少TLB miss。这些因素环环相扣，只调一个维度很难见效。

四是关于"小参数也能引发大问题"的教训：有的平台在开启iommu和intremap后，某些老设备会因为重映射表查询失败导致DMA超时。这种问题通常在BIOS层面禁用该设备的ACS（Access Control Services）或者更新设备固件来解决。排查此类问题要敢看硬件的spec，文档比任何论坛回答都有价值。

老实说，MSI-X虚拟化只是虚拟化底层无数细节中的一个点，但恰恰是这类细节决定了虚拟化方案能不能跑出接近物理机的性能。把这套机制理解透了，以后再遇到网络性能、存储延迟、CPU利用率相关的问题，你就不会只盯着应用层找原因，而是能顺着中断链路一层层剥下去，最后找到真正的根因。