为什么 VMREADs/VMWRITEs 比内存读/写操作慢答案

【问题标题】：Why are VMREADs/VMWRITEs slower than Memory Read/Write operation为什么 VMREADs/VMWRITEs 比内存读/写操作慢
【发布时间】：2018-03-24 03:43:59
【问题描述】：

从逻辑上讲，写入任何 CPU 存储变量都应该比相应的内存操作更快，因为没有缓存未命中的机会。这些状态缓存在 CPU 中，它们不会在下一次 VMLAUNCH/VMRESUME 操作之前更改任何 CPU 状态。因此，它们应该比对内存地址的等效操作更快

在查看 AMD 和 Intel 提供的不同虚拟化解决方案时会出现这个问题。英特尔已强制要求对 VMCS 数据结构的所有更改都应始终通过 VMREAD/VMWRITE 接口，而不是通过常规内存 R/W 操作。但是，AMD 没有这样的限制，它的 VMCB 区域是通过常规的内存操作来修改的。

与 AMD 相比，Intel 方法的好处应该是更快的 VMExit/VMResume 时间。但是，英特尔会通过添加新指令在灵活性方面松懈。

但是，实际上，VMREAD/VMWRITE 操作比常规内存操作要慢。这对我来说没有任何意义。

【问题讨论】：

vmread 和 vmwrite 不仅仅是加载和存储。它们执行附加检查（例如 VMCS 字段必须存在）和操作（VMCS 链接用于影子 VMCS）。另外，我不确定 Intel 是否保证所有 VMCS 都必须被缓存，因此仍可能发生正常负载。
你说他们慢的依据是什么？据我了解，在当前的处理器中，它们比 L1 命中稍慢，但比实际进入内存要快很多倍。
@prl：这是吞吐量还是延迟？微编码指令的吞吐量可能比 L1D 加载或存储更差，但更好的延迟很容易相信。我根本没有使用它们，我只是从表面上看问题来写我的答案。但是 Margaret 的观点是他们对写入进行了额外的检查，这使得段寄存器比我想象的更好。
感谢大家的cmets和回复。我对 VMReads/VMWrites 感到特别困惑，因为它们不会改变任何当前的来宾/主机状态。此外，没有检查 VMReads/VMWrites（我的意思是在现场），而是检查 VMEntry。有一些与正确操作模式相关的检查，但这些检查非常简单。总之，我只是想比较英特尔架构和 AMD 架构，当常规内存操作可以完成相同的工作时，似乎没有其他有效的理由来引入单独的指令。我知道我错过了什么。

标签： x86-64 intel virtualization amd-processor

【解决方案1】：

常规内存读取/写入由专用硬件处理以优化它们，因为真正的程序充满了它们。

大多数工作负载不会花费太多时间来修改特殊的 CPU 控制寄存器，因此这些指令的内部处理通常没有经过大量优化。在内部，它可能是微编码的（即从微码 ROM 解码为许多微指令）。

段寄存器可能不是一个很好的类比，因为写入一个会触发 CPU 从 GDT / LDT 加载描述符。但根据Agner Fog's testing for Nehalem，mov sr, r 每 13 个周期有一个吞吐量，并解码为 6 uop（来自微码）。（他停止为后来的 CPU 测试段寄存器的东西。）实际上，我不确定这是 16 位还是 32 位模式。如果是 16 位实模式，那么写入段寄存器不会读取描述符；它只是更新了基础和限制。

读取段寄存器更快：每个时钟一个。但这仍然比读取普通寄存器慢（常规 mov 指令在 Nehalem 上的吞吐量为 0.33c）。

Nehalem 每个时钟只能加载和/或存储一次，不像 Sandybridge 系列每个时钟可以加载 2 次。但是段寄存器读取可能不会更快。

移入/移出控制寄存器可能会更慢，因为它比段寄存器少。

【讨论】：