linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Markus Metzger" <markus.t.metzger@googlemail.com>
To: "Roland McGrath" <roland@redhat.com>
Cc: "Metzger, Markus T" <markus.t.metzger@intel.com>,
	"Andi Kleen" <ak@suse.de>,
	tglx@linutronix.de, "Andrew Morton" <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, hpa@zytor.com, "Siddha,
	Suresh B" <suresh.b.siddha@intel.com>,
	"Michael Kerrisk" <mtk-manpages@gmx.net>,
	markus.t.metzger@gmail.com, "Ingo Molnar" <mingo@elte.hu>
Subject: Re: [patch 0/2] x86, ptrace: support for branch trace store(BTS)
Date: Mon, 3 Dec 2007 14:53:27 +0100	[thread overview]
Message-ID: <a430082a0712030553v22e9b46bnb9da975a23b1c0db@mail.gmail.com> (raw)
In-Reply-To: <20071201074044.GA13974@elte.hu>

> Cool.  It's been on my list to look into exposing those features
> somehow. I hadn't planned on doing it until after the utrace stuff
> settles and there is a more coherent interface context in which to do
> it.

I'm looking very much forward to utrace. From what I read so far, this is
a much nicer interface.
I would expect that this feature, together with all other ptrace extensions,
would need to be adapted to utrace, once that is in.


> If they are tackling the MSR hacking and context switch and so forth,
> I'd like to see them start out by just adding block-step
> (debugctlmsr.btf) with the PTRACE_SINGLEBLOCK interface as ia64 has.
> That should lay some of the same groundwork needed here, but is much
> simpler.

There seems to be support for block stepping in arch/x86/kernel/step.c,
which is used by kernel/ptrace.c.

This is now another user for the DEBUGCTL MSR; the access needs to be
synchronized. I'll look into it.


> I am not really in favor of this new ptrace interface.  I think they
> should look around across arch's and think about sane general-purpose
> interfaces for features of this kind that might be built with some
> commonality across machines.

I looked at the include/asm-*/ptrace.h files and some arch/*/kernel/ptrace.c
files. Most arch's support a few variants of GET<whatever>REGS.
Most implementations simply copy_to_user the kernel structures for the
requested registers.

Sparc64 needs to convert pointer sizes and defines the returned struct
directly in the implementation.
Xtensa provides access to an array of FP regs of varying size. They provide
a ptrace command to query for the size, but otherwise also copy_to_user
the entire array.

I have not found any arch that does anything more fancy than return a single
integer value or an array of registers.
In all cases, the command carries enough information to interpret the result.

In our case, the array we're querying for can be rather big and
typically only some
of the information is interesting. The data we return is inhomogeneous.

The former may be true for register arrays as well, but they are
typically small
enough. The latter would compare to a general GETREGS command that returns
all registers in a self-describing format (that might be an
interesting extension, if
one got tired of yet another GET<new-type-of>REGS command).

Instead of providing the entire array in one command, we introduced commands to
handle that array.
Instead of carrying the information how to interpret the result in the
command itself,
we provide that information directly in the result.

I would argue that this interface may be directly (re)used and
extended by other arch's.


Do you have specific concerns regarding the interface?


> Also do it in a layered way from
> low-level, with something usable for kernel-mode too.

To disable cpl0-filtering should be fairly easy; we would simply clear
the cpl-bit
in the debugctl_mask. This way, you can trace the kernel
part of the application, but you would still debug the application.
You could call the ptrace_bts_ functions directly or we might add a new set of
interface functions that simply forward the request (or the other way round).

To provide a per-cpu trace instead of a per-thread trace would be a
completely new
feature that only has the configuration part in common with our patch.

What did you have in mind when you asked for kernel-mode support?

thanks and regards,
markus.

  reply	other threads:[~2007-12-03 13:53 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-29  8:14 [patch 0/2] x86, ptrace: support for branch trace store(BTS) Metzger, Markus T
2007-11-29 23:59 ` Andrew Morton
2007-11-30  9:57   ` Metzger, Markus T
2007-11-30 10:34     ` Andi Kleen
2007-11-30 15:45       ` Metzger, Markus T
2007-11-30 17:06         ` Ingo Molnar
2007-12-01  7:40           ` Ingo Molnar
2007-12-03 13:53             ` Markus Metzger [this message]
2007-12-03 15:17               ` Metzger, Markus T
2007-12-03 16:21               ` Andi Kleen
2007-12-03 16:45                 ` Ingo Molnar
2007-12-03 17:11                   ` Andi Kleen
2007-12-03 17:22                     ` Thomas Gleixner
2007-12-03 21:55                     ` Ingo Molnar
2007-12-03 22:02                       ` Andi Kleen
2007-12-04  8:52                 ` Metzger, Markus T
2007-11-30 10:54   ` Ingo Molnar
2007-11-30 15:48     ` Metzger, Markus T
2007-11-30 16:04   ` Michael Kerrisk
2007-11-30 16:08     ` Michael Kerrisk
2007-11-30 15:56 Markus Metzger
2007-12-04 18:03 Markus Metzger

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=a430082a0712030553v22e9b46bnb9da975a23b1c0db@mail.gmail.com \
    --to=markus.t.metzger@googlemail.com \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markus.t.metzger@gmail.com \
    --cc=markus.t.metzger@intel.com \
    --cc=mingo@elte.hu \
    --cc=mtk-manpages@gmx.net \
    --cc=roland@redhat.com \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    /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;
as well as URLs for NNTP newsgroup(s).