public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Yu, Fenghua" <fenghua.yu@intel.com>
To: Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"Luck, Tony" <tony.luck@intel.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	"Li, Xiaoyao" <xiaoyao.li@intel.com>,
	"Shankar, Ravi V" <ravi.v.shankar@intel.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>
Subject: RE: [PATCH v4 1/4] x86/cpufeatures: Enumerate #DB for bus lock detection
Date: Wed, 27 Jan 2021 22:39:59 +0000	[thread overview]
Message-ID: <adf4082ffef7410c961cfe76acc93606@intel.com> (raw)
In-Reply-To: <87wnvydqxi.fsf@nanos.tec.linutronix.de>

Hi, Thomas,

> On Wed, Jan 27, 2021 2:16 PM, Thomas Gleixner wrote:
> On Tue, Nov 24 2020 at 20:52, Fenghua Yu wrote:
> 
> > A bus lock is acquired though either split locked access to writeback
> > (WB) memory or any locked access to non-WB memory. This is typically
> > >1000 cycles slower than an atomic operation within a cache line. It
> > also disrupts performance on other cores.
> >
> > Some CPUs have ability to notify the kernel by an #DB trap after a
> > user instruction acquires a bus lock and is executed. This allows the
> > kernel to enforce user application throttling or mitigations.
> 
> That's nice, but how does that interact with a data breakpoint on the same
> location?

If both data breakpoint and bus lock happen on the same location, the bus lock
is handled first and then the data breakpoint is handled in the same exception:

1. If warn on bus lock, a rate limited warning is printed for the bus lock and then
    a SIGTRAP is sent to the user process.
2. If fatal on bus lock, a SIGBUS is sent to the user process for the bus lock and a
    SIGTRAP is also sent to the user process. I think the SIGBUS will be delivered first
    to the process and then SIGTRAP will be delivered to the process.
3. If ratelimit on bus lock, first the tasks in the user sleep for specified time, then
    SIGTRAP is sent to the user process.

Is the interaction OK?

> 
> Also the information you pointed to in the cover letter
> 
> >  [1] Intel Instruction Set Extension Chapter 8:
> > https://software.intel.com/sites/default/files/managed/c5/15/architect
> > ure-instruction-set-extensions-programming-reference.pdf
> 
> does not contain anything which is even remotely related to this patch series.
> That chapter describes another bit in TEST_CTRL_MSR ...

I think either I gave an old link or the content in the link was changed to an older version of ISE doc after this series was released.

Here is the new ISE doc and the bus lock exception is described in Chapter 9.
https://software.intel.com/content/dam/develop/public/us/en/documents/architecture-instruction-set-extensions-programming-reference.pdf

I'll update the link in the next version.

Thanks!

-Fenghua

  reply	other threads:[~2021-01-27 23:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-24 20:52 [PATCH v4 0/4] x86/bus_lock: Enable bus lock detection Fenghua Yu
2020-11-24 20:52 ` [PATCH v4 1/4] x86/cpufeatures: Enumerate #DB for " Fenghua Yu
2021-01-27 21:13   ` Thomas Gleixner
2021-01-27 22:39     ` Yu, Fenghua [this message]
2021-01-27 23:23       ` Thomas Gleixner
2020-11-24 20:52 ` [PATCH v4 2/4] x86/bus_lock: Handle warn and fatal in #DB for bus lock Fenghua Yu
2021-01-27 21:16   ` Thomas Gleixner
2020-11-24 20:52 ` [PATCH v4 3/4] x86/bus_lock: Set rate limit " Fenghua Yu
2021-01-27 21:57   ` Thomas Gleixner
2020-11-24 20:52 ` [PATCH v4 4/4] Documentation/admin-guide: Change doc for split_lock_detect parameter Fenghua Yu
2021-01-27 22:09   ` Thomas Gleixner
2020-12-02 20:36 ` [PATCH v4 0/4] x86/bus_lock: Enable bus lock detection Yu, Fenghua
2021-01-04 19:42 ` Fenghua Yu
2021-01-25 19:27   ` Fenghua Yu

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=adf4082ffef7410c961cfe76acc93606@intel.com \
    --to=fenghua.yu@intel.com \
    --cc=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=ravi.v.shankar@intel.com \
    --cc=rdunlap@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox