Exit陷入，触发INIT信号 （常量 3）

[progromyang]

您好前辈，我试图成功编译了您的这个工程，
HyperPlatform.sys 加载成功以后，有几率会遇到蓝屏。
查看了DUMP文件后，是 Exit陷入时，遇到了INIT信号。
按道理来说 计算机正常运行以后不会再遇到INIT这个信号了。
所以请教前辈是否遇到同样的情况，希望前辈可以指点一二、

[tandasat]

Hi, I do not think I encountered INIT signal while working on this project. I also cannot think of why INIT would be sent either.

I would try to see which code is sending INIT (and why). If the system is configured to use x2APIC, it would be simply intercepting WRMSR to Interrupt Command Register (See x2APIC Register Address Space).

[progromyang]

感谢前辈的回帖， 我在运行中发现 win7系统不会遇到此类情况，win10 才会这样，不晓得是什么原因

[progromyang]

您好前辈，通过您的指点，我尝试在您的项目中定义了 ：kIa32Icr= 0x40000071, 也就是您说的 Interrupt Command Register
我尝试在 VmmpHandleMsrAccess 拦截ICR 想观察到底是谁在发送 INIT，
const auto msr = static_cast(guest_context->gp_regs->cx);
switch (msr) {
case Msr::kIa32Icr:
VmmpDumpGuestState();
ULONG_PTR qualification;
qualification = UtilVmRead(VmcsField::kExitQualification);
HYPERPLATFORM_COMMON_BUG_CHECK(HyperPlatformBugCheck::kUnexpectedVmExit,
reinterpret_cast<ULONG_PTR>(guest_context),
guest_context->ip, qualification);
break;
添加代码以后 这里并没有触发 checkdebug。
触发的位置依然是 case VmxExitReason::kInit: 相当于 在msr并没有拦截到。
一开始我猜想可能是 电脑问题，但是我在测试了系统版本 win10 Win11，i7-13000k，i5-9400f。 都会触发INIT
我换了 NoirVisor 的项目，https://github.com/Zero-Tang/NoirVisor
但是 依然会触发INIT。这让我摸不到头脑。
因为INIT 触发蓝屏以后，GuestContext的上下文已经是不可信的了。我不知道在windbg kn看到的上下文是否有用？

[progromyang]

非常感谢前辈给我的回信: 关于您说MWAIT会导致 Exit Vt接收到 INIT信号。 我在代码中模拟了 MWAIT 运行，但是并没有触发Exit vt INIT信号的产生。

…

------------------&nbsp;原始邮件&nbsp;------------------ 发件人: "tandasat/HyperPlatform" ***@***.***&gt;; 发送时间:&nbsp;2023年2月12日(星期天) 下午5:32 ***@***.***&gt;; ***@***.******@***.***&gt;; 主题:&nbsp;Re: [tandasat/HyperPlatform] Exit陷入，触发INIT信号 （常量 3） (Issue #91) The INIT signal could be due to MWAIT was being processed, return with no-op could resolved. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***&gt;

[KelvinMsft]

I have a theory about receiving INIT signal when hypervisor is running - I guess it is because the core was being unresponsive, one thing you can try is skip the INIT signal , see if you receive CLOCK_WATCHDOG_TIMEOUT

[progromyang]

您好前辈，感谢您的回信。 关于您说的&nbsp;试跳过INIT信号，我的做法是 Exit Vt 陷入以后。陷入原因是INIT。 这个时候我不做任何处理 让他自己返回。这个时候电脑会卡死,电脑无法画面任何都无响应 (不是蓝屏)。

…

------------------&nbsp;原始邮件&nbsp;------------------ 发件人: "tandasat/HyperPlatform" ***@***.***&gt;; 发送时间:&nbsp;2023年2月13日(星期一) 下午3:25 ***@***.***&gt;; ***@***.******@***.***&gt;; 主题:&nbsp;Re: [tandasat/HyperPlatform] Exit陷入，触发INIT信号 （常量 3） (Issue #91) I have a theory about receiving INIT signal when hypervisor is running - I guess it is because the core was being unresponsive, one thing you can try is skip the INIT signal , see if you receive CLOCK_WATCHDOG_TIMEOUT — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***&gt;

[KelvinMsft]

not even adjust the RIP..

[progromyang]

不改变 rip。 在我的认知里，触发INIT 信号，陷入Exit Vt以后。 context已经不是可信的上下文了。 我曾经尝试过自己模拟触发INIT信号。 只有apic wirte +300 (300偏移量),成功过。 而且context，包括rip已经不是写 apic wirte +300 时的上下文了。

…

------------------&nbsp;原始邮件&nbsp;------------------ 发件人: "tandasat/HyperPlatform" ***@***.***&gt;; 发送时间:&nbsp;2023年2月13日(星期一) 下午4:01 ***@***.***&gt;; ***@***.******@***.***&gt;; 主题:&nbsp;Re: [tandasat/HyperPlatform] Exit陷入，触发INIT信号 （常量 3） (Issue #91) not even jump the RIP.. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***&gt;

[KelvinMsft]

What is the current RIP?

[progromyang]

context 的rip吗？ context 的 rip 很随机，位置每次都不确定。 不过我见到过。&nbsp; mwait test r9,r9&nbsp; &nbsp;← rip 指向这里。 但是这个时候&nbsp; 当前rip 是不可信的。

…

------------------&nbsp;原始邮件&nbsp;------------------ 发件人: "tandasat/HyperPlatform" ***@***.***&gt;; 发送时间:&nbsp;2023年2月13日(星期一) 下午4:09 ***@***.***&gt;; ***@***.******@***.***&gt;; 主题:&nbsp;Re: [tandasat/HyperPlatform] Exit陷入，触发INIT信号 （常量 3） (Issue #91) What is the current RIP? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***&gt;

[KelvinMsft]

The reason why idle thread get scheduled is because there's no other thread on the system could be scheduled on the core from scheduler point of view, it shouldn't be in a busy system, and if it persist for too long can cause some normal thread cannot be scheduled by some reason, and affect tick accumulation, System or HAL would think the core is being unresponsive, hence trigger CLOCK_WATCHDOG_TIMEOUT bugcheck.

I guess if you keep the RIP unchanged, the system will still run for awhile, but eventually get the bugcheck, just because the system thinks the processor core isn't responsive. and System or HAL might tries to restart the system and/or processors where issue INIT#. (unsure if some firmware also do so)

So I think the problem here is because the thread scheduler is not functioning properly on that core, and it appears INIT# randomly asserted.

One interesting finding: you can try to disable gdt/ldt intercept and see if it works.

[progromyang]

你好，KelvinMsft
真的很抱歉现在才回复到您。
有空的时候我会对 init信号来源进行测试，但是依然无法找到init 信号的来源。
我听取了你的意见 关闭了对 gdt/idt 的拦截，但是没用。
我尽量关闭了msr，io，dr 等一些拦截，都不起作用。
很抱歉这么长时间我依旧没有解决这个init 的问题。
不过在今后的日子，我会慢慢研究，如果有什么突破性的解决，我会给您发信息。

[progromyang]

我现在得到的信息是：
win7，win11 很难触发 init
win10 ，几乎可以100%触发。
我不知道是不是和ept有关，或者init信号来源于看门狗。