From: Michael Kelley (LINUX) mikelley@microsoft.com Sent: Thursday, July 20, 2023 5:42 PM
From: Peter Zijlstra peterz@infradead.org Sent: Thursday, July 20, 2023 2:16 PM
@@ -472,6 +473,26 @@ void __init hyperv_init(void) }
/*
* Some versions of Hyper-V that provide IBT in guest VMs have a bug
* in that there's no ENDBR64 instruction at the entry to the
* hypercall page. Because hypercalls are invoked via an indirect call
* to the hypercall page, all hypercall attempts fail when IBT is
* enabled, and Linux panics. For such buggy versions, disable IBT.
*
* Fixed versions of Hyper-V always provide ENDBR64 on the hypercall
* page, so if future Linux kernel versions enable IBT for 32-bit
* builds, additional hypercall page hackery will be required here
* to provide an ENDBR32.
*/
+#ifdef CONFIG_X86_KERNEL_IBT
- if (cpu_feature_enabled(X86_FEATURE_IBT) &&
*(u32 *)hv_hypercall_pg != gen_endbr()) {
setup_clear_cpu_cap(X86_FEATURE_IBT);
pr_info("Hyper-V: Disabling IBT because of Hyper-V bug\n");
- }
+#endif
pr_warn() perhaps?
I wanted pr_info() so there's an immediate way to check for this case in the dmesg output if a user complains about IBT not being enabled when he expects it. In some sense, the message is temporary because once the Hyper-V patch is available and users install it, the message will go away. The pipeline for the Hyper-V patch is a bit long, so availability is at least several months away. This Linux workaround will be available much faster. Once it is picked up on stable branches, we will avoid the situations like we saw where someone upgraded Fedora 38 from a 6.2 to a 6.3 kernel, and the 6.3 kernel wouldn't boot because it has kernel IBT enabled.
I realized in the middle of the night that my reply was nonsense. :-( pr_warn() makes the message visible when pr_info() might not. I'm happy to change to pr_warn().
Michael