是否使用x86 VIF和VIP标志？

我已经阅读了《英特尔软件开发人员手册》第3卷第20节，其中解释了virtual-8086模式的工作原理，包括VIF和VIP标志的使用。然而，我仍然对一些事情感到困惑

VIF标志用作IF标志的代理，因此8086仿真器（可能是某个用户空间程序）可以接收可屏蔽的硬件中断，即使它所模拟的实模式程序不想接收

模拟器为什么要这样做

VIP用作收到中断时的标记空间。根据手册，如果处理器接收到可屏蔽中断，但被仿真程序不想接收（因此VIF标志将被清除），仿真器应设置VIP标志，等待仿真程序设置if标志，然后处理中断

为什么我们要等待处理中断而不是立即处理？实模式8086上的中断是否延迟而不是忽略

附加问题当设置VIP且程序启用中断（通过STI等）时，处理器会生成一个#GP，但当以多种方式设置VIP标志时，可能会生成一个#GP，例如通过无效的内存访问。手册中没有提到检查GP的原因，因此无论是否设置了IF，程序是否应该处理挂起的中断

编辑：好的，我看到我的困惑的一部分是内核需要保持IF设置。在这种情况下，我更应该问#2-为什么我们要等待处理中断而不是完全忽略它

原因见第20.3.2节：“现有8086程序通常设置并清除EFLAGS寄存器中的IF标志，以启用和禁用可屏蔽硬件中断。”在现代操作系统下以虚拟8086模式运行此类应用程序时，操作系统不允许8086程序禁用系统中的中断。因此，IF标志需要保持在操作系统的控制之下，并且必须代表virtual-8086程序对其进行虚拟化。VIF和VIP标志的使用“消除了将所有与IF相关的操作（如PUSH、POPF、CLI和STI指令）捕获到virtual-8086监视器的需要。”

如果virtual-8086模式程序已执行CLI以清除if（具有清除VIF的效果），则无法将中断发送到该程序

这是个好问题。在我看来，处理器应该在生成#GP之前设置VIF；然后，virtual-8086监视器中的GP处理程序可以很容易地看到VIP和VIF都已设置。这是由POPF或IRET设置VIF时所描述的行为；我不知道为什么STI的行为会有所不同

原因见第20.3.2节：“现有8086程序通常设置并清除EFLAGS寄存器中的IF标志，以启用和禁用可屏蔽硬件中断。”在现代操作系统下以虚拟8086模式运行此类应用程序时，操作系统不允许8086程序禁用系统中的中断。因此，IF标志需要保持在操作系统的控制之下，并且必须代表virtual-8086程序对其进行虚拟化。VIF和VIP标志的使用“消除了将所有与IF相关的操作（如PUSH、POPF、CLI和STI指令）捕获到virtual-8086监视器的需要。”

如果virtual-8086模式程序已执行CLI以清除if（具有清除VIF的效果），则无法将中断发送到该程序

这是个好问题。在我看来，处理器应该在生成#GP之前设置VIF；然后，virtual-8086监视器中的GP处理程序可以很容易地看到VIP和VIF都已设置。这是由POPF或IRET设置VIF时所描述的行为；我不知道为什么STI的行为会有所不同

---

问题1已经回答了，让我们 稍微处理一下2和3

实模式8086上的中断是否延迟而不是忽略

值得注意的是 执行模式（真实或受保护） 与此无关。 CLI确实忽略了中断， 它不会推迟任何事情。但是 中断处理非常复杂， 而且，在大多数配置中 中断设备和/或 中断控制器将确保 CPU的INT引脚保持激活状态 直到你做了STI和维修 打断 因此，过度简化， 可以说CLI延迟了 打断但你不会发现这样的情况 CPU手册中的语句，因为 这是通过外部逻辑完成的， 这取决于许多可配置的东西

但是在设置VIP标志时，可以生成一个GP 以多种方式，例如通过无效的内存访问

在v86模式下，有相当多的 GPF源，例如端口IO指令， 当IOPL小于3时。唯一可靠的 区分它们的方法是查找 出现故障的操作码，并对其进行模拟。这是不可能的 例如，仅设置VIF和升高GPF 在此之后，作为例外，不应留下任何 错误指令的可观察影响，

---

允许软件干净地模拟它。

问题1已经回答，让我们 稍微处理一下2和3

实模式8086上的中断是否延迟而不是忽略

值得注意的是 执行模式（真实或受保护） 与此无关。 CLI确实忽略了中断， 它不会推迟任何事情。但是 中断处理非常复杂， 而且，在大多数配置中 中断设备和/或 中断控制器将确保 CPU的INT引脚保持激活状态 直到你做了STI和维修 打断 因此，过度简化， 可以说CLI延迟了 打断但你不会发现这样的情况 CPU手册中的语句，因为 这是通过外部逻辑完成的， 并且取决于许多配置