From: Thomas Gleixner <tglx@linutronix.de>
To: "Singh\, Balbir" <sblbir@amazon.com>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "keescook\@chromium.org" <keescook@chromium.org>,
"tony.luck\@intel.com" <tony.luck@intel.com>,
"benh\@kernel.crashing.org" <benh@kernel.crashing.org>,
"jpoimboe\@redhat.com" <jpoimboe@redhat.com>,
"x86\@kernel.org" <x86@kernel.org>,
"dave.hansen\@intel.com" <dave.hansen@intel.com>
Subject: Re: [PATCH v3 4/5] arch/x86: Optionally flush L1D on context switch
Date: Sat, 18 Apr 2020 12:17:44 +0200 [thread overview]
Message-ID: <87mu79xflj.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <bdf950167b86a01db93a9633b708c17a66ad73d0.camel@amazon.com>
"Singh, Balbir" <sblbir@amazon.com> writes:
> On Fri, 2020-04-17 at 16:41 +0200, Thomas Gleixner wrote:
>> Balbir Singh <sblbir@amazon.com> writes:
>> static void *l1d_flush_pages;
>> static DEFINE_MUTEX(l1d_flush_mutex);
>>
>> int l1d_flush_init(void)
>> {
>> int ret;
>>
>> if (static_cpu_has(X86_FEATURE_FLUSH_L1D) || l1d_flush_pages)
>> return 0;
>>
>> mutex_lock(&l1d_flush_mutex);
>> if (!l1d_flush_pages)
>> l1d_flush_pages = l1d_flush_alloc_pages();
>> ret = l1d_flush_pages ? 0 : -ENOMEM;
>> mutex_unlock(&l1d_flush_mutex);
>> return ret;
>> }
>> EXPORT_SYMBOL_GPL(l1d_flush_init);
>>
>> which removes the export of l1d_flush_alloc_pages() and gets rid of the
>> cleanup counterpart. In a real world deployment unloading of VMX if used
>> once is unlikely and with the task based one you end up with these pages
>> 'leaked' anyway if used once.
>>
> I don't want the patches to be enforce that one cannot unload the kvm module,
> but I can refactor those bits a bit more
Not freeing the l1d flush pages does not prevent unloading the kvm
module. It just keeps the around. It's the same problem with your L1D
flush for tasks. If one tasks uses it then the pages stay around until
the system reboots.
>> If any other architecture enables this, then it will have _ALL_ of this
>> code duplicated. So we should rather have:
>
> But that is being a bit prescriptive to arch's to implement their L1D flushing
> using TIF flags, arch's should be free to use bits in struct_mm for their arch
> if they feel so.
>> - All architectures have to use TIF_SPEC_FLUSH_L1D if they want to
>> support the prctl.
>>
>
> That is a concern (see above), should we enforce this?
Fair enough, but it's trivial enough to have:
static inline void arch_task_l1d_flush_update(bool enable)
static inline bool arch_task_l1d_flush_state(void)
and the rest of the logic is just identical.
Thanks,
tglx
next prev parent reply other threads:[~2020-04-18 10:17 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-08 9:02 [PATCH v3 0/5] Optionally flush L1D on context switch Balbir Singh
2020-04-08 9:02 ` [PATCH v3 1/5] arch/x86/kvm: Refactor l1d flush lifecycle management Balbir Singh
2020-04-17 12:57 ` Thomas Gleixner
2020-04-17 22:34 ` Singh, Balbir
2020-04-08 9:02 ` [PATCH v3 2/5] arch/x86: Refactor tlbflush and l1d flush Balbir Singh
2020-04-17 13:03 ` Thomas Gleixner
2020-04-17 22:58 ` Singh, Balbir
2020-04-08 9:02 ` [PATCH v3 3/5] arch/x86/mm: Refactor cond_ibpb() to support other use cases Balbir Singh
2020-04-17 13:07 ` Thomas Gleixner
2020-04-17 23:02 ` Singh, Balbir
2020-04-18 9:59 ` Thomas Gleixner
2020-04-21 3:46 ` Singh, Balbir
2020-04-21 9:02 ` Thomas Gleixner
2020-04-08 9:02 ` [PATCH v3 4/5] arch/x86: Optionally flush L1D on context switch Balbir Singh
2020-04-17 14:41 ` Thomas Gleixner
2020-04-18 1:30 ` Singh, Balbir
2020-04-18 10:17 ` Thomas Gleixner [this message]
2020-04-20 0:24 ` Singh, Balbir
2020-04-08 9:02 ` [PATCH v3 5/5] arch/x86: Add L1D flushing Documentation Balbir Singh
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=87mu79xflj.fsf@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=benh@kernel.crashing.org \
--cc=dave.hansen@intel.com \
--cc=jpoimboe@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sblbir@amazon.com \
--cc=tony.luck@intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox