From: Paolo Bonzini <pbonzini@redhat.com>
To: Jessica Yu <jeyu@kernel.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
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: Fri, 8 Nov 2019 20:51:04 +0100 [thread overview]
Message-ID: <b77283e5-a4bc-1849-fbfa-27741ab2dbd5@redhat.com> (raw)
In-Reply-To: <20191108135631.GA22507@linux-8ccs>
On 08/11/19 14:56, Jessica Yu wrote:
> And I am
> not sure what Masahiro (who takes care of all things kbuild-related)
> thinks of this idea. But before implementing all this, is there
> absolutely no way around having the duplicated exported symbols? (e.g.,
> could the modules be configured/built in a mutally exclusive way? I'm
> lacking the context from the rest of the thread, so not sure which are
> the problematic modules.)
The problematic modules are kvm_intel and kvm_amd, so we cannot build
them in a mutually exclusive way (but we know it won't make sense to
load both). We will have to build only one of them when built into
vmlinux, but the module case must support building both.
Currently we put the common symbols in kvm.ko, and kvm.ko acts as a kind
of "library" for kvm_intel.ko and kvm_amd.ko. The problem is that
kvm_intel.ko and kvm_amd.ko currently pass a large array of function
pointers to kvm.ko, and Andrea measured a substantial performance
penalty from retpolines when kvm.ko calls back through those pointers.
Therefore he would like to remove kvm.ko, and that would result in
symbols exported from two modules.
I suppose we could use code patching mechanism to avoid the retpolines.
Andrea, what do you think about that? That would have the advantage
that we won't have to remove kvm_x86_ops. :)
Thanks,
Paolo
next prev parent reply other threads:[~2019-11-08 19:51 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 [this message]
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
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=b77283e5-a4bc-1849-fbfa-27741ab2dbd5@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).