From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Christoph Hellwig <hch@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
x86@kernel.org, Kees Cook <keescook@chromium.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Thomas Lendacky <Thomas.Lendacky@amd.com>,
Juergen Gross <jgross@suse.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [patch 00/15] x86/tlb: Unexport per-CPU tlbstate
Date: Tue, 21 Apr 2020 17:42:13 -0700 [thread overview]
Message-ID: <20200422004213.GC17836@linux.intel.com> (raw)
In-Reply-To: <87tv1durws.fsf@nanos.tec.linutronix.de>
On Tue, Apr 21, 2020 at 11:09:07AM +0200, Thomas Gleixner wrote:
> Sean Christopherson <sean.j.christopherson@intel.com> writes:
>
> > On Mon, Apr 20, 2020 at 07:27:06PM +0200, Thomas Gleixner wrote:
> >> Christoph Hellwig <hch@infradead.org> writes:
> >> > Just looking over some exports at the end of the series (and thus
> >> > ignoring bisection issues):
> >> >
> >> > - Is there any good reason to keep __flush_tlb_all inline vs moving it
> >> > out of line and kill the flush_tlb_local and flush_tlb_global exports.
> >> > Also there is just a single modular users in SVM, I wonder if there is
> >> > any way to get rid of that one as well.
> >>
> >> I'll have a look again.
> >
> > Regarding the SVM case, the only usage is for a TLB errata. At a glance,
> > svm_init_erratum_383() and is_erratum_383() don't use any KVM hooks, i.e. I
> > don't see anything that would prevent moving those to .../kernel/cpu/amd.c.
>
> Right, but that would trade one export vs. two SVM errata specific
> exports. Not really a win.
True. I was thinking the svm_init_erratum_383() call could be moved to
init_amd(), assuming the MSR's magic bit 47 is "safe" outside of SVM
enabled, but that's probably not worth risking the potential for breakage
unless you really want to hide __flush_tlb_all().
next prev parent reply other threads:[~2020-04-22 0:42 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-19 20:31 [patch 00/15] x86/tlb: Unexport per-CPU tlbstate Thomas Gleixner
2020-04-19 20:31 ` [patch 01/15] x86/tlb: Uninline __get_current_cr3_fast() Thomas Gleixner
2020-04-19 20:31 ` [patch 02/15] x86/cpu: Uninline CR4 accessors Thomas Gleixner
2020-04-20 9:01 ` Christoph Hellwig
2020-04-20 9:34 ` Borislav Petkov
2020-04-20 17:25 ` Thomas Gleixner
2020-04-19 20:31 ` [patch 03/15] x86/cr4: Sanitize CR4.PCE update Thomas Gleixner
2020-04-19 20:31 ` [patch 04/15] x86/alternatives: Move temporary_mm helpers into C Thomas Gleixner
2020-04-19 20:31 ` [patch 05/15] x86/tlb: Move __flush_tlb() out of line Thomas Gleixner
2020-04-20 13:48 ` Tom Lendacky
2020-04-20 14:03 ` Jürgen Groß
2020-04-20 14:26 ` Tom Lendacky
2020-04-20 14:38 ` Jürgen Groß
2020-04-20 18:30 ` Tom Lendacky
2020-04-19 20:31 ` [patch 06/15] x86/tlb: Move __flush_tlb_global() " Thomas Gleixner
2020-04-19 20:31 ` [patch 07/15] x86/tlb: Move __flush_tlb_one_user() " Thomas Gleixner
2020-04-19 20:31 ` [patch 08/15] x86/tlb: Move __flush_tlb_one_kernel() " Thomas Gleixner
2020-04-19 20:31 ` [patch 09/15] x86/tlb: Move flush_tlb_others() " Thomas Gleixner
2020-04-19 20:31 ` [patch 10/15] x86/tlb: Move paravirt_tlb_remove_table() to the usage site Thomas Gleixner
2020-04-19 20:31 ` [patch 11/15] x86/tlb: Move cr4_set_bits_and_update_boot() " Thomas Gleixner
2020-04-19 20:31 ` [patch 12/15] x86/tlb: Uninline nmi_uaccess_okay() Thomas Gleixner
2020-04-19 20:31 ` [patch 13/15] x86/tlb: Move PCID helpers where they are used Thomas Gleixner
2020-04-19 20:31 ` [patch 14/15] xen/privcmd: Remove unneeded asm/tlb.h include Thomas Gleixner
2020-04-19 20:31 ` [patch 15/15] x86/tlb: Restrict access to tlbstate Thomas Gleixner
2020-04-20 9:20 ` [patch 00/15] x86/tlb: Unexport per-CPU tlbstate Christoph Hellwig
2020-04-20 16:58 ` Alexandre Chartre
2020-04-20 20:08 ` Thomas Gleixner
2020-04-20 17:27 ` Thomas Gleixner
2020-04-21 8:09 ` Sean Christopherson
2020-04-21 9:09 ` Thomas Gleixner
2020-04-22 0:42 ` Sean Christopherson [this message]
2020-04-20 10:25 ` Peter Zijlstra
2020-04-20 16:33 ` Alexandre Chartre
2020-04-21 17:10 ` Andy Lutomirski
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=20200422004213.GC17836@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=Thomas.Lendacky@amd.com \
--cc=boris.ostrovsky@oracle.com \
--cc=hch@infradead.org \
--cc=jgross@suse.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.