Re: [PATCH 03/13] kvm: monolithic: fixup x86-32 build

Andrea Arcangeli
2019-11-08T21:26:31Z

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