David Gibson <da...@gibson.dropbear.id.au> writes: > On Wed, Sep 01, 2021 at 02:33:52PM -0300, Fabiano Rosas wrote: >> This series merges our three kvm modules kvm.ko, kvm-hv.ko and >> kvm-pr.ko into one kvm.ko module. > > That doesn't sound like a good idea to me. People who aren't on BookS > servers don't want - and can't use - kvm-hv. Almost nobody wants > kvm-pr. It's also kind of inconsistent with x86, which has the > separate AMD and Intel modules.
But this is not altering the ability of having only kvm-hv or only kvm-pr. I'm taking the Kconfig options that used to produce separate modules and using them to select which code gets built into the one kvm.ko module. Currently: CONFIG_KVM_BOOK3S_64=m <-- produces kvm.ko CONFIG_KVM_BOOK3S_64_HV=m <-- produces kvm-hv.ko CONFIG_KVM_BOOK3S_64_PR=m <-- produces kvm-pr.ko I'm making it so we now have one kvm.ko everywhere, but there is still: CONFIG_KVM_BOOK3S_64=m <-- produces kvm.ko CONFIG_KVM_BOOK3S_HV_POSSIBLE=y <-- includes HV in kvm.ko CONFIG_KVM_BOOK3S_PR_POSSIBLE=y <-- includes PR in kvm.ko In other words, if you are going to have at least two modules loaded at all times (kvm + kvm-hv or kvm + kvm-pr), why not put all that into one module? No one needs to build code they are not going to use, this is not changing. About consistency with x86, this situation is not analogous because we need to be able to load both modules at the same time, which means kvm.ko needs to stick around when one module goes away in case we want to load the other module. The KVM common code states that it expects to have at most one implementation: /* * kvm_arch_init makes sure there's at most one caller * for architectures that support multiple implementations, * like intel and amd on x86. (...) which is not true in our case due to this requirement of having two separate modules loading independently. (tangent) We are already quite different from other architectures since we're not making use of kvm_arch_init and some other KVM hooks, such as kvm_arch_check_processor_compat. So while other archs have their init dispatched by kvm common code, our init and cleanup happens independently in the ppc-specific modules, which obviously works but is needlessly different and has subtleties in the ordering of operations wrt. the kvm common code. (tangent)