Merge branch 'kvm-hw-enable-refactor' into HEAD
authorPaolo Bonzini <pbonzini@redhat.com>
Tue, 24 Jan 2023 10:57:17 +0000 (05:57 -0500)
committerPaolo Bonzini <pbonzini@redhat.com>
Tue, 24 Jan 2023 10:57:17 +0000 (05:57 -0500)
commitedd731d73221277cb384efeb66da76dae0a68dfa
tree9d06afe6dade1454fdac023cb05bba360aa53fe6
parentfc471e831016c1741f3e8042997969ace0b5a013
parent9f1a4c004869d3c8061f286fec4d8096dd099b84
Merge branch 'kvm-hw-enable-refactor' into HEAD

The main theme of this series is to kill off kvm_arch_init(),
kvm_arch_hardware_(un)setup(), and kvm_arch_check_processor_compat(), which
all originated in x86 code from way back when, and needlessly complicate
both common KVM code and architecture code.  E.g. many architectures don't
mark functions/data as __init/__ro_after_init purely because kvm_init()
isn't marked __init to support x86's separate vendor modules.

The idea/hope is that with those hooks gone (moved to arch code), it will
be easier for x86 (and other architectures) to modify their module init
sequences as needed without having to fight common KVM code.  E.g. I'm
hoping that ARM can build on this to simplify its hardware enabling logic,
especially the pKVM side of things.

There are bug fixes throughout this series.  They are more scattered than
I would usually prefer, but getting the sequencing correct was a gigantic
pain for many of the x86 fixes due to needing to fix common code in order
for the x86 fix to have any meaning.  And while the bugs are often fatal,
they aren't all that interesting for most users as they either require a
malicious admin or broken hardware, i.e. aren't likely to be encountered
by the vast majority of KVM users.  So unless someone _really_ wants a
particular fix isolated for backporting, I'm not planning on shuffling
patches.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>