讲一点背景故事。我的 Xen 体验始于大约 5 年前，当时使用的是一台具有 4GB 内存的 Aaeon EMB-CV1，运行四个虚拟机。随着硬件的不断增长，我换成了一台具有 8GB 内存的 Aaeon EMB-KB1。随着硬件的不断增长，我换成了一台具有 16GB 内存的 Asrock J5040-ITX。这些都运行良好，性能也非常好，半虚拟化的能力和平台的效率让我感到惊讶。所有都运行在 Debian dom0 和 Debian domu 上，使用 Debian 维护的 Xen 版本。每个 dom0 安装都是全新构建的，之后会迁移虚拟机。
我最近决定添加一块额外的主板来帮助负载，这样需要更多马力的东西（比如我的 ELK 堆栈、minecraft 服务器、nextcloud 实例等）就可以运行在 5040 上，而低 CPU 的东西（比如 DNS、VPN 服务器、邮件服务器等）可以运行在 CPU 较慢的主板上。我希望使用相同的 CPU 架构，以便可以实时迁移虚拟机进行维护，所以我选择了具有 8GB 内存的 Asrock J4205。安装 Debian 10（我目前的标准版本）后，主板运行迅速且性能良好。然后我安装了 xen-tools 和 xen-system-amd64，重新启动后，系统启动时间明显变长，控制台（和 SSH）也非常卡顿。此时我没有运行任何虚拟机，没有任何自定义调整等。从顶部看，有很多“窃取”，四个核心（所有物理核心）之间的总体平均约为 10%。
我尝试将 dom0 绑定到一个 CPU，此时 dom0 再次稳定地运行。但是，我尝试启动的任何 domu 都会非常卡顿，并且“窃取”率很高。将它们实时迁移回 5040 后，它们又会恢复正常。如果我没有实时迁移，而是在 4205 上启动它们，情况也是如此。
我想也许我在构建过程中犯了某些错误，所以我放弃了那个安装并从头开始重建它，并遇到了同样的事情。
如果我重新启动并选择非 Xen grub 条目，则不会出现任何“窃取”或卡顿，所以我不认为它与安装的其他系统软件有关，它似乎与 Xen 本身有关。
我也尝试过在 BIOS 中完全禁用 speedstep、所有 c 状态等，但似乎没有什么区别。
我开始使用 sysstat 记录性能，这是我所看到的：
在运行 6 个虚拟机的 5040 上：
08:25:01 AM CPU %user %nice %system %iowait %steal %idle
08:35:01 AM all 0.03 0.00 0.11 0.00 0.05 99.81
08:45:01 AM all 0.03 0.00 0.11 0.00 0.05 99.81
08:55:01 AM all 0.03 0.00 0.17 0.00 0.20 99.60
09:05:01 AM all 0.03 0.00 0.12 0.00 0.05 99.80
09:15:01 AM all 0.03 0.00 0.13 0.00 0.09 99.75
09:25:01 AM all 0.03 0.00 0.18 0.00 0.26 99.53
Average: all 0.03 0.00 0.14 0.00 0.12 99.72
在没有运行虚拟机的 4205 上：
08:35:01 AM CPU %user %nice %system %iowait %steal %idle
08:45:02 AM all 0.03 0.00 0.07 0.01 7.74 92.15
08:55:02 AM all 0.03 0.00 0.09 0.00 8.95 90.93
09:05:01 AM all 0.03 0.00 0.07 0.00 9.19 90.70
09:15:01 AM all 0.03 0.00 0.08 0.00 7.93 91.96
09:25:01 AM all 0.03 0.00 0.07 0.00 8.85 91.05
09:35:01 AM all 0.03 0.00 0.19 0.00 6.73 93.05
Average: all 0.03 0.00 0.09 0.00 8.24 91.63
# top
top - 09:45:55 up 1:29, 1 user, load average: 0.15, 0.11, 0.08
Tasks: 161 total, 2 running, 159 sleeping, 0 stopped, 0 zombie
%Cpu0 : 0.0 us, 1.1 sy, 0.0 ni, 96.6 id, 0.0 wa, 0.0 hi, 0.0 si, 2.3 st
%Cpu1 : 0.0 us, 0.0 sy, 0.0 ni, 78.9 id, 0.0 wa, 0.0 hi, 0.0 si, 21.1 st
%Cpu2 : 0.0 us, 1.1 sy, 0.0 ni, 89.4 id, 0.0 wa, 0.0 hi, 0.0 si, 9.6 st
%Cpu3 : 0.0 us, 0.0 sy, 0.0 ni, 62.8 id, 0.0 wa, 0.0 hi, 0.0 si, 37.2 st
有什么方法可以判断是什么导致了性能下降，以及 dom0 在“窃取”CPU 时做了什么？最近几天我一直在谷歌上搜索这个问题，到目前为止还没有找到任何有用的信息，只有帖子说当你超额订阅 domu 时会发生这种情况，但由于我目前没有运行任何 domu，我看不出这会成为一个问题，因为它只是坐在那里看起来很酷，但没有做任何实际工作。
两个 dom0 上的本地磁盘存储都是单个 20GB Intel 313 SLC SSD。虚拟机存储在 Debian nas 盒上，通过 iscsi 连接。
# uname -a
Linux vhost2 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 GNU/Linux
# cat /etc/debian_version
10.9
# xl info
host :
release : 4.19.0-14-amd64
version : #1 SMP Debian 4.19.171-2 (2021-01-30)
machine : x86_64
nr_cpus : 4
max_cpu_id : 3
nr_nodes : 1
cores_per_socket : 4
threads_per_core : 1
cpu_mhz : 1497.612
hw_caps : bfebfbff:47f8e3bf:2c100800:00000101:0000000f:2094e283:00000000:00000100
virt_caps : hvm hvm_directio
total_memory : 8040
free_memory : 7413
sharing_freed_memory : 0
sharing_used_memory : 0
outstanding_claims : 0
free_cpus : 0
xen_major : 4
xen_minor : 11
xen_extra : .4
xen_version : 4.11.4
xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler : credit
xen_pagesize : 4096
platform_params : virt_start=0xffff800000000000
xen_changeset :
xen_commandline : placeholder dom0_mem=512M,max:512M no-real-mode edd=off
cc_compiler : gcc (Debian 8.3.0-6) 8.3.0
cc_compile_by : pkg-xen-devel
cc_compile_domain : lists.alioth.debian.org
cc_compile_date : Fri Dec 11 21:33:51 UTC 2020
build_id : 6d8e0fa3ddb825695eb6c6832631b4fa2331fe41
xend_config_format : 4
编辑：我知道 dom0 在技术上是一个特殊的 domu，所以在技术上，盒子上有一个 domu 在运行，此时，我从控制台执行的任何操作在技术上都是在该 domu 中运行的。有没有办法从虚拟机管理程序中查看透视图？例如，虚拟机管理程序当时正在执行什么非常重要的任务，以至于它必须中断 dom0/其他 domu。我注意到有些事情会加剧这个问题，比如在 vim 中查看大文件时按住其中一个光标键 - 这往往会使窃取（和卡顿）更加明显。诸如此类的事情让我怀疑可能与 acpi/speedstep/c-states 有关，但在 BIOS 中禁用它们似乎没有什么区别。如果与此有关，我认为在非 xen Debian 安装中也会发生这种情况，而不仅仅是在使用 xen 启动时
当我只授予 dom0 一个核心时，这个问题就消失了（无论如何从 dom0 的角度来看），这也很奇怪（但任何正在运行的 domu 即使只分配了一个 vcpu 仍然会存在这个问题）。
我绞尽脑汁，用尽 Google 搜索，试图弄清楚到底发生了什么，因为这真的相当令人恼火。我知道 xen 可能无法与此主板兼容，这没关系，我只是想在放弃之前更好地了解发生了什么以及为什么会发生这种情况（如果可能的话）。