From: Paolo Bonzini <pbonzini@redhat.com>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: Jessica Yu <jeyu@kernel.org>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Sean Christopherson <sean.j.christopherson@intel.com>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Matthias Maennich <maennich@google.com>
Subject: Re: [PATCH 03/13] kvm: monolithic: fixup x86-32 build
Date: Sat, 9 Nov 2019 00:10:03 +0100 [thread overview]
Message-ID: <953e95ba-6bb6-25e1-64e8-20e1ea903652@redhat.com> (raw)
In-Reply-To: <20191108212625.GB532@redhat.com>
On 08/11/19 22:26, Andrea Arcangeli wrote:
> 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.
This is unlikely to make a difference, since kvm.o and kvm-intel.o are
overall about 700 KiB in size. You do lose some inlining opportunities
with LTO, but without LTO the L1 cache benefits are debatable too. The
real loss is in the complexity, I agree with you about that.
> 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?
For completeness, one advantage of patching would be to keep support for
built-in Intel+AMD. The modpost patch should be pretty small, and since
Jessica seemed quite open to it let's do that.
Thanks,
Paolo
> 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
>
next prev parent reply other threads:[~2019-11-08 23:10 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-04 22:59 [PATCH 00/13] KVM monolithic v3 Andrea Arcangeli
2019-11-04 22:59 ` [PATCH 01/13] KVM: monolithic: x86: remove kvm.ko Andrea Arcangeli
2019-11-04 22:59 ` [PATCH 02/13] KVM: monolithic: x86: convert the kvm_x86_ops and kvm_pmu_ops methods to external functions Andrea Arcangeli
2019-11-04 22:59 ` [PATCH 03/13] kvm: monolithic: fixup x86-32 build Andrea Arcangeli
2019-11-05 10:04 ` Paolo Bonzini
2019-11-05 10:37 ` Paolo Bonzini
2019-11-05 13:54 ` Andrea Arcangeli
2019-11-05 14:09 ` Paolo Bonzini
2019-11-05 14:56 ` Andrea Arcangeli
2019-11-05 15:10 ` Paolo Bonzini
2019-11-08 13:56 ` Jessica Yu
2019-11-08 19:51 ` Paolo Bonzini
2019-11-08 20:01 ` Andrea Arcangeli
2019-11-08 21:02 ` Paolo Bonzini
2019-11-08 21:26 ` Andrea Arcangeli
2019-11-08 23:10 ` Paolo Bonzini [this message]
2019-11-09 3:30 ` Masahiro Yamada
2019-11-04 22:59 ` [PATCH 04/13] KVM: monolithic: x86: handle the request_immediate_exit variation Andrea Arcangeli
2019-11-04 22:59 ` [PATCH 05/13] KVM: monolithic: add more section prefixes Andrea Arcangeli
2019-11-05 10:16 ` Paolo Bonzini
2019-11-04 22:59 ` [PATCH 06/13] KVM: monolithic: x86: remove __exit section prefix from machine_unsetup Andrea Arcangeli
2019-11-05 10:16 ` Paolo Bonzini
2019-11-04 22:59 ` [PATCH 07/13] KVM: monolithic: x86: remove __init section prefix from kvm_x86_cpu_has_kvm_support Andrea Arcangeli
2019-11-05 10:16 ` Paolo Bonzini
2019-11-04 22:59 ` [PATCH 08/13] KVM: monolithic: remove exports Andrea Arcangeli
2019-11-04 22:59 ` [PATCH 09/13] KVM: monolithic: x86: drop the kvm_pmu_ops structure Andrea Arcangeli
2019-11-04 22:59 ` [PATCH 10/13] KVM: x86: optimize more exit handlers in vmx.c Andrea Arcangeli
2019-11-05 10:20 ` Paolo Bonzini
2019-11-04 22:59 ` [PATCH 11/13] KVM: retpolines: x86: eliminate retpoline from vmx.c exit handlers Andrea Arcangeli
2019-11-05 10:20 ` Paolo Bonzini
2019-11-04 23:00 ` [PATCH 12/13] KVM: retpolines: x86: eliminate retpoline from svm.c " Andrea Arcangeli
2019-11-05 10:21 ` Paolo Bonzini
2019-11-04 23:00 ` [PATCH 13/13] x86: retpolines: eliminate retpoline from msr event handlers Andrea Arcangeli
2019-11-05 10:21 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=953e95ba-6bb6-25e1-64e8-20e1ea903652@redhat.com \
--to=pbonzini@redhat.com \
--cc=aarcange@redhat.com \
--cc=jeyu@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maennich@google.com \
--cc=sean.j.christopherson@intel.com \
--cc=vkuznets@redhat.com \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).