On Fri, Nov 08, 2019 at 10:02:52PM +0100, Paolo Bonzini wrote: > kvm_intel.ko or kvm_amd.ko, I'm not sure why that would be worse for TLB > or RAM usage. The hard part is recording the location of the call sites Let's ignore the different code complexity of supporting self modifying code: kvm.ko and kvm-*.ko will be located in different pages, hence it'll waste 1 iTLB for every vmexit and 2k of RAM in average. The L1 icache also will be wasted. It'll simply run slower. Now about the code complexity, it is even higher than pvops: KVM pvops ========= ============= 1) Changes daily Never change 2) Patched at runtime Patched only at boot time early on during module load and multiple times at every load of kvm-*.ko 3) The patching points to All patch destinations are linked into code in kernel modules the kernel Why exactly should we go through such a complication when it runs slower in the end and it's much more complex to implement and maintain and in fact even more complex than pvops already is? Runtime patching the indirect call like pvops do is strictly required when you are forced to resolve the linking at runtime. The alternative would be to ship two different Linux kernels for PV and bare metal. Maintaining a whole new kernel rpm and having to install a different rpm depending on the hypervisor/bare metal is troublesome so pvops is worth it. With kvm-amd and kvm-intel we can avoid the whole runtime patching of the call sites as already proven by KVM monolithic patchset, and it'll run faster in the CPU and it'll save RAM, so I'm not exactly sure how anybody could prefer runtime patching here when the only benefit is a few mbytes of disk space saved on disk. Furthermore by linking the thing statically we'll also enable LTO and other gcc features which would never be possible with those indirect calls. Thanks, Andrea
