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

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?

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/architecture-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 ...

Thanks,

        tglx



  reply	other threads:[~2021-01-27 21:14 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 [this message]
2021-01-27 22:39     ` Yu, Fenghua
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=87wnvydqxi.fsf@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=bp@alien8.de \
    --cc=fenghua.yu@intel.com \
    --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=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 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.