Patch 01 is a fix for a NULL pointer deref that I ran into with a bad VMM
configuration. That specific error path is remedied by patch 02, but
Hyper-V can still end up in an inactive state if a memory allocation fails.
Patch 02 effectively makes the required MSRs mandatory for recognizing
Hyper-V at all.
Some versions of QEMU prior to ~6.0 make it all too easy to advertise
Hyper-V and a slew of features without advertising the Hyper-V HYPERCALL
MSR, e.g. +hv-ipi,+hv-tlbflush,+hv-vpindex,+hv-reenlightenment advertises
a bunch of things, but not the HYPERCALL MSR.
That results in the guest identifying Hyper-V and setting a variety of PV
ops that then get ignored because hyperv_init() silently disables Hyper-V
for all intents and purposes. The VMM (or its controller) is obviously
off in the weeds, but ideally the guest kernel would acknowledge the bad
setup in some way.
v2:
- Add Vitaly's review.
- Rebase to hyperv-next, commit 285f68afa8b2 ("x86/hyperv: Protect
set_hv_tscchange_cb() against getting preempted"). [Vitaly]
- Tweak the changelog in patch 01 to omit the example about a bad VM
config since the NULL check is needed even if that specific issue is
resolved.
v1: https://lore.kernel.org/all/20211028222148.2924457-1-seanjc@xxxxxxxxxx/t/#u
Sean Christopherson (2):
x86/hyperv: Fix NULL deref in set_hv_tscchange_cb() if Hyper-V setup
fails
x86/hyperv: Move required MSRs check to initial platform probing
arch/x86/hyperv/hv_init.c | 12 ++++--------
arch/x86/kernel/cpu/mshyperv.c | 20 +++++++++++++++-----
2 files changed, 19 insertions(+), 13 deletions(-)
--
2.34.0.rc0.344.g81b53c2807-goog
