From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Fenghua Yu <fenghua.yu@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
"Shanbhogue, Vedvyas" <vedvyas.shanbhogue@intel.com>,
"Luck, Tony" <tony.luck@intel.com>, H Peter Anvin <hpa@zytor.com>,
Andy Lutomirski <luto@kernel.org>,
"Shankar, Ravi V" <ravi.v.shankar@intel.com>,
"Li, Xiaoyao" <xiaoyao.li@intel.com>, x86 <x86@kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC] x86/bus_lock: Enable bus lock detection
Date: Wed, 29 Jul 2020 13:39:05 -0700 [thread overview]
Message-ID: <20200729203905.GN27751@linux.intel.com> (raw)
In-Reply-To: <20200729203557.GA318595@otcwcpicx6.sc.intel.com>
On Wed, Jul 29, 2020 at 08:35:57PM +0000, Fenghua Yu wrote:
> Hi, Sean,
>
> On Wed, Jul 29, 2020 at 01:00:33PM -0700, Sean Christopherson wrote:
> > On Wed, Jul 29, 2020 at 07:42:59PM +0000, Fenghua Yu wrote:
> > > > Smushing the two into a single option is confusing, e.g. from the table
> > > > below it's not at all clear what will happen if sld=fatal, both features
> > > > are supported, and the kernel generates a split lock.
> > > >
> > > > Given that both SLD (per-core, not architectural) and BLD (#DB recursion and
> > > > inverted DR6 flag) have warts, it would be very nice to enable/disable them
> > > > independently. The lock to non-WB behavior for BLD may also be problematic,
> > > > e.g. maybe it turns out that fixing drivers to avoid locks to non-WB isn't
> > > > as straightforward as avoiding split locks.
> > >
> > > But the two features are related if both of them are enabled in hardware:
> > > If a split lock happens, SLD will generate #AC before instruction execution
> > > and BLD will generate #DB after instruction execution.
> > >
> > > The software needs to make them exclusive. The same kernel option reflects
> > > the relationship and make them exclusive, e.g. "fatal" enables SLD and
> > > disables BLD, "warn" does the other way.
> >
> > Why do they need to be exclusive? We've already established that BLD catches
> > things that SLD does not. What's wrong with running sld=fatal and bld=ratelimit
> > so that split locks never happen and kill applications, and non-WB locks are
> > are ratelimited?
>
> Sorry if I didn't explain bus lock and split lock detections clearly before.
>
> There are two causes of bus locks:
> 1. a locked access across cache line boundary: this is split lock.
> 2. a locked access to non-WB memory.
>
> BLD detects both causes and SLD only detects the first one, i.e. BLD can detect
> both split lock AND lock to non-WB memory.
>
> If sld=fatal and bld=ratelimit (both sld and bld are enabled in hw),
> a split lock always generates #AC and kills the app and bld will never have
> a chance to trigger #DB for split lock. So effectively the combination makes
> the kernel to take two different actions after detecting a bus lock: if the
> bus lock comes from a split lock, fatal (sld); if the bus lock comes from
> lock to non-WB memory, ratelimit (bld). Seems this is not a useful combination
> and is not what the user really wants to do because the user wants ratelimit
> for BLD, right?
I understood all off that. And as I user I want to run sld=fatal and
bld=ratelimit to provide maximum protection, i.e. disallow split locks at
all times, and ratelimit the crud SLD #AC can't catch.
next prev parent reply other threads:[~2020-07-29 20:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-17 21:35 [PATCH RFC] x86/bus_lock: Enable bus lock detection Fenghua Yu
2020-07-29 3:02 ` Sean Christopherson
2020-07-29 8:50 ` peterz
2020-07-29 18:09 ` Yu, Fenghua
2020-07-29 18:46 ` Sean Christopherson
2020-07-29 19:42 ` Fenghua Yu
2020-07-29 20:00 ` Sean Christopherson
2020-07-29 20:09 ` peterz
2020-07-29 20:35 ` Fenghua Yu
2020-07-29 20:39 ` Sean Christopherson [this message]
2020-07-29 22:07 ` Fenghua Yu
2020-07-29 23:28 ` Sean Christopherson
2020-07-29 8:49 ` peterz
2020-07-29 20:40 ` Fenghua Yu
2020-07-29 21:09 ` peterz
2020-07-30 10:08 ` Thomas Gleixner
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=20200729203905.GN27751@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=bp@alien8.de \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=ravi.v.shankar@intel.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=vedvyas.shanbhogue@intel.com \
--cc=x86@kernel.org \
--cc=xiaoyao.li@intel.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 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.