Messages in this thread | | | From | Rian Quinn <> | Date | Thu, 8 Nov 2018 15:23:59 -0700 | Subject | x86_64 INIT/SIPI Bug |
| |
I apologize upfront if this is the wrong place to post this, pretty new to this.
We are working on the Bareflank Hypervisor (www.bareflank.org), and we are passing through the INIT/SIPI process (similar to how a VMX rootkit from EFI might boot the OS) and we noticed that on Arch Linux, the INIT/SIPI process stalls, something we are not seeing on Ubuntu.
Turns out, to fix the issue, we had to turn on cpu_init_udelay=10000. The problem is, once a hypervisor is turned on, even one that is doing nothing but passing through the instructions, the "quick" that is detailed below fails as the kernel is not giving the CPU enough time to perform a VMExit/VMEntry (even through the VMExit is not doing anything). https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/smpboot.c?h=v4.20-rc1#n650
You can see our INIT/SIPI code here if you are interested: https://github.com/rianquinn/extended_apis/blob/hyperkernel_1/bfvmm/src/hve/arch/intel_x64/vmexit/init_signal.cpp
The reason I suggest this is a bug is the manual clearly states that a wait is required and the "quirk" that turns off this delay prevents code like this from working. Would it be possible to either: - Turn this off by default, but still allow someone to turn it on if they are confident the delay is not needed? - Provide a generic way to turn this off (maybe if a hypervisor is detected, it defaults to off)?
I'd be more than happy to provide a patch and test, but I'm not sure if there is any interest in changing this code.
Thanks, - Rian Quinn
| |