在x86 Intel VT-X非根模式下，是否可以在每个指令边界处传递中断? [英] In x86 Intel VT-X non-root mode, can an interrupt be delivered at every instruction boundary?
问题描述
除了某些通常未指定将中断传递给虚拟处理器的条件(cli，if = 0等等)之外，guest虚拟机中的所有指令实际上是否可中断?
Other than certain normal specified conditions where interrupts are not delivered to the virtual processor (cli, if=0, etc), are all instructions in the guest actually interruptible?
这就是说，当将传入的硬件中断分配给LAPIC然后再分配给处理器时，可能发生了一些内部魔术，将其转换为对来宾的虚拟中断(使用虚拟APIC，没有退出).发生这种情况时，当前执行的指令是否像典型的中断传递一样立即将OOO流序列化并跳转到向量，还是VT-x的虚拟中断传递会导致某种其他类型的解决方案发生?
That is to say, when an incoming hardware interrupt is given to the LAPIC then to the processor, supposedly some internal magic happens to translate that to a virtual interrupt to the guest (using virtual APIC, no exiting). When that happens, does the currently executing instruction immediately serialize the OOO stream and jump to the vector like a typical interrupt delivery, or does VT-x's virtual interrupt delivery cause some other kind of resolution to take place?
上下文是，使用模拟器对竞赛条件和同步原语进行压力测试通常非常有价值.希望您的模拟器能够在任何指令下接收中断，以触发有趣的行为".
The context is that it's often very valuable to stress test race conditions and synchronization primitives using an emulator. One would hope your emulator would be capable of receiving an interrupt at any instruction, to trigger "interesting behavior".
这引起了一个问题，VT-x虚拟化是否提供相同的指令级中断粒度，以便像纯指令模拟器一样触发有趣的行为"?
This leads to the question, does VT-x virtualization provide the same instruction level granularity of interrupts such that "interesting behavior" would be triggered the same as a pure instruction emulator?
Intel SDM确实注意到虚拟中断是在指令边界上传递的，但是对于芯片上通常有效的所有边界是否总是 仍有一些疑问仍在VT-x模式下检查中断.
The Intel SDM does note that virtual interrupts are delivered on instruction boundaries, but there's still some questions as to whether or not all boundaries normally valid on the chip are always still checking for interrupts in VT-x mode.
推荐答案
我看不出有什么理由会特别在访客内部.当外部中断到达时会发生什么. (假设我们正在谈论的是在管道上本地运行的来宾代码，而不是根源仿真和/或决定在再次发生中断之前决定延迟重新进入来宾..请参见注释.)
I don't see any reason why being inside the guest would be special wrt. what happens when an external interrupt arrives. (Assuming we're talking about the guest code running natively on the pipeline, not the root emulating and/or deciding to delay re-entry to the guest in anticipation of another interrupt. See comments.)
它们不会有效地阻止多条指令的中断；那会影响中断延迟.由于没有特殊的同步点"，中断只能在那里传递，因此管道需要能够处理任意指令之间的中断.乱序的exec总是可能发生很多事情，因此您不能指望在处理中断之前等待任何特定的状态.这可能会花费太长时间.如果一对指令之间的间隔可以传递一个中断，为什么还没有其他指令呢?
They're not going to effectively block interrupts for multiple instructions; that would hurt interrupt latency. Since there aren't special "sync points" where interrupts can only be delivered there, the pipeline needs to be able to handle interrupts between arbitrary instructions. Out-of-order exec always potentially has a lot going on, so you can't count on waiting for any specific state before handling an interrupt; that could take too long. If the gap between one pair of instructions is ok to deliver an interrupt, why not any other?
CPU不会重命名特权级别，因此，是的，它们会回退到退休状态，丢弃后端的所有运行中指令，然后根据当前状态确定要做什么.另请参见发生中断时，流水线中的指令会如何处理?
CPUs don't rename the privilege level, so yes they'd roll back to the retirement state, discard all in-flight instructions in the back-end, and then figure out what to do based on the current state. See also When an interrupt occurs, what happens to instructions in the pipeline?
这个完全未经测试的猜测是基于我对CPU体系结构的理解.如果对中断延迟有可测量的影响，那可能是真实的事情.
This completely untested guess is based on my understanding of CPU architecture. If there was a measurable effect on interrupt latency, that might be a real thing.
实际上，不管使用VT-X，除非单步执行，否则某些指令边界可能都无法中断.
退休带宽是每个时钟3个(Nehalem)，每个逻辑线程每个4个时钟(Haswell)，或者在Skylake中甚至更高.从无序的内核中退出通常是突发性的，因为它按顺序发生(以支持精确的异常)，这就是为什么我们将ROB与预留站分开的原因.
Retirement bandwidth is 3 per clock (Nehalem), 4 per clock per logical thread (Haswell), or even higher in Skylake. Retirement from the out-of-order core is usually bursty, because it happens in-order (to support precise exceptions), this is why we have a ROB separate from the Reservation Station.
一个指令通常阻塞一段时间后的独立指令退出，然后与该指令一起突然退出，这是很常见的.例如缓存未命中负载，或长于dep链的末端，紧接一些独立的指令.
It's very common for one instruction to block retirement of later independent instructions for a while, and then for a burst of retirement along with that instruction. e.g. a cache-miss load, or the end of a long dep chain right before some independent instructions.
因此，对于某些功能或代码块，很有可能每次运行时，例如xor -zeroing指令总是与之前的指令以相同的周期退出.这意味着CPU永远不会处于异或归零指令是最早的非退休指令的状态，因此它与之前的insn之间的距离永远不会成为出现中断的地方.
So for some functions or blocks of code, it's likely that every single time they run, an xor-zeroing instruction for example always retires in the same cycle as the instruction before. That means the CPU is never in a state where the xor-zeroing instruction is the oldest non-retired instruction, and thus gap between it and the insn before can never be the place where an interrupt appears.
如果您有2条紧挨着的说明，例如在CPU从较早的指令返回到用户空间后的一个周期中，您可能会在64字节I缓存边界处获得前端效果，从而干扰通常的廉价独立指令(如nop或
If you have 2 instructions closely following each other, e.g. one coming in a cycle after the CPU returns to user-space from an earlier instruction, you could end up with front-end effects at 64-byte I-cache boundaries disturbing the usual pattern of cheap independent instructions like nop or xor-zeroing always retiring in the same cycle as an earlier higher-latency instruction, but there might still be cases that were non-disturbable where fetch and 5-wide decode, and 4-wide issue/rename will reliably get instructions into the pipe together without opportunity for having the slow one finish before the fast one after it is ready to retire.
正如我所说，这不是VT-x特有的.
As I said, this isn't specific to VT-x.
这篇关于在x86 Intel VT-X非根模式下，是否可以在每个指令边界处传递中断?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
