From: "K.Prasad" <prasad@linux.vnet.ibm.com>
To: linux-kernel@vger.kernel.org
Cc: Alan Stern <stern@rowland.harvard.edu>,
Roland McGrath <roland@redhat.com>,
akpm@linux-foundation.org, mingo@elte.hu,
jason.wessel@windriver.com, avi@qumranet.com,
richardj_moore@uk.ibm.com, prasad@linux.vnet.ibm.com
Subject: [RFC Patch 0/9] Hardware Breakpoint interfaces
Date: Tue, 7 Oct 2008 17:08:15 +0530 [thread overview]
Message-ID: <20081007113815.GA23523@in.ibm.com> (raw)
Hi All,
In the ensuing mails, please find the patches that provide
interfaces to use Hardware Breakpoint (or Hardware watchpoint registers)
for addresses in kernel- and user-space.
This work is primarily based on the patches that were discussed earlier
on Linux Kernel Mailing List (http://lkml.org/lkml/2007/3/2/221) through
a discussion initiated by Alan Stern and carried forward with extensive
help from Roland McGrath (copied). They now ported to the most recent
kernel version (2.6.27-rc9) along with changes to the invocation of
'@triggered' function (presently split into pre_ and post_handler
routines).
These patches add a new feature to the kernel i.e. use HW breakpoint
registers to watch kernel-space data (for read/write operations) and
kernel instructions for execute operations. The interfaces introduced
through these patches for handling HW Breakpoint registers, namely
(un)register_<kernel/user>_hw_breakpoint() are intended to serve as
core-routines that will interact with the hardware registers directly,
while the users of breakpoint registers will do so through these
interfaces. Given the large number of such users in the kernel (such
as KGDB, KVM for kernel-space), not all of them have been modified
to use the proposed interfaces - atleast in this iteration of patches.
The patches are marked as [RFC], meaning that there is plenty of
'work-in-progress' and here is a near-exhaustive list of them:
- Enable KGDB and KVM to use the register_kernel_hw_breakpoint()
interface for their HW Breakpoint usage, in the absence of which
they will be broken during simultaneous use.
- Stress test the patches to study the behaviour during multiple
requests from various sources/requests beyond available number of
registers.
- Support multiple handlers for a given breakpoint in kernel- or
user-space address.
- Provide complete breakpoint functionality in x86 i.e. include
breakpoints on I/O operations.
- Addition of Documentation/hw_bkpt.txt and samples/hw_breakpoint/*.c
files for better readability.
- Code re-arrangement to avoid the #include of kernel/hw_breakpoint.c in
arch/x86/kernel/hw_breakpoint.c
Thanks,
K.Prasad
next reply other threads:[~2008-10-07 11:38 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-07 11:38 K.Prasad [this message]
2008-10-07 11:40 ` [RFC Patch 1/9] Introducing generic hardware breakpoint handler interfaces K.Prasad
2008-10-07 15:21 ` Alan Stern
2008-10-07 16:49 ` K.Prasad
2008-10-07 11:41 ` [RFC Patch 2/9] x86 architecture implementation of Hardware Breakpoint interfaces K.Prasad
2008-10-07 15:36 ` Alan Stern
2008-10-07 17:23 ` K.Prasad
2008-10-07 17:38 ` Alan Stern
2008-10-07 17:28 ` K.Prasad
2008-10-07 11:42 ` [RFC Patch 3/9] Modifying generic debug exception to use virtual debug registers K.Prasad
2008-10-07 11:43 ` [RFC Patch 4/9] Modify kprobe exception handler to recognise single-stepping by HW Breakpoint handler K.Prasad
2008-10-07 11:44 ` [RFC Patch 5/9] Use wrapper routines around debug registers in processor related functions K.Prasad
2008-10-07 11:44 ` [RFC Patch 6/9] Use virtual debug registers in process/thread handling code K.Prasad
2008-10-07 15:40 ` Alan Stern
2008-10-07 17:48 ` K.Prasad
2008-10-07 11:45 ` [RFC Patch 7/9] Modify signal handling code to refrain from re-enabling HW Breakpoints K.Prasad
2008-10-07 11:46 ` [RFC Patch 8/9] Modify Ptrace to use wrapper routines to access breakpoint registers K.Prasad
2008-10-07 11:46 ` [RFC Patch 9/9] Cleanup HW Breakpoint registers before kexec K.Prasad
2008-10-07 12:29 ` [RFC Patch 0/9] Hardware Breakpoint interfaces Avi Kivity
2008-10-07 14:32 ` K.Prasad
2008-10-07 14:36 ` Avi Kivity
2008-10-07 16:45 ` K.Prasad
2008-10-07 16:52 ` Avi Kivity
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=20081007113815.GA23523@in.ibm.com \
--to=prasad@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=avi@qumranet.com \
--cc=jason.wessel@windriver.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=richardj_moore@uk.ibm.com \
--cc=roland@redhat.com \
--cc=stern@rowland.harvard.edu \
/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.