Message-ID: <20090914180104.GA6045@nowhere>
Date:	Mon, 14 Sep 2009 20:01:06 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Jan Kiszka <jan.kiszka@....de>
Cc:	Ingo Molnar <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>,
	Prasad <prasad@...ux.vnet.ibm.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Peter Zijlstra <peterz@...radead.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Jiri Slaby <jirislaby@...il.com>,
	Li Zefan <lizf@...fujitsu.com>, Avi Kivity <avi@...hat.com>,
	Paul Mackerras <paulus@...ba.org>,
	Mike Galbraith <efault@....de>,
	Masami Hiramatsu <mhiramat@...hat.com>
Subject: Re: [PATCH 3/5] hw-breakpoints: Rewrite the hw-breakpoints layer
	on top of perf counters

On Mon, Sep 14, 2009 at 08:24:29AM +0200, Jan Kiszka wrote:
> > I don't quite understand what must be NMI-safe here. Is it when
> > we request a breakpoint or when we hit one?
> > 
> 
> Both. With kgdb, the kernel may be interrupted (almost) everywhere, and
> then the operator may decide to add/remove hardware breakpoints during
> this interruption.



Ok, a breakpoint can trigger in NMI context since the trigger callback
doesn't take any lock, and doesn't need to. And perf is NMI safe
in this scope too.

But register a breakpoint while in NMI can't be done in this
patchset. You can't even do that from common interrupts because
we are taking mutexes.

So this part will indeed need a bit of a rework, not a large change
though.


 
> > 
> >  
> >> Still on my wishlist for KVM is a cheap & easy way to obtain the current
> >> register content or to refresh it in hardware. It's not yet clear to me
> >> where to hook this in the given design. It looks like this information
> >> can be scattered over the current thread and some perf counters.
> > 
> > 
> > With this design approach, the debug registers are not anymore stored
> > in the thread structure. They are not stored anymore actually.
> > 
> > Especially because the breakpoint are not anymore assigned to a
> > specific address register. This one is decided when the counter
> > is enabled. And the counter is often toggled on/off, depending
> > if we start/end profiling the desired context. It can be a single task,
> > in which case the counter is enabled while the task is sched in, and
> > disabled when it is sched out.
> > And between two sched atoms, the register used for a breakpoint
> > can be different.
> > 
> > The arch informations about the breakpoints (len/type/addr) are stored
> > in the counter structure, and the address/control registers contents
> > are now dynamically computed.
> > 
> > For your needs, basically the control must be done from perfcounters.
> > When you switch from host to guest, the counter must be sched out.
> > And in the reverse direction, it must be sched in.
> > Then perf will take care of that by itself.
> 
> Actually, we wanted to avoid sched-out activity, and so far this is
> possible. But if both steps are cheap enough, specifically if the
> sched-out does _not_ touch the hardware and is very cheap if no
> breakpoints are set, KVM will likely be a happy user.
> 
> Does that API already exist or what additional work is required?
> 
> Jan
> 


Well, what you could do is walking through the list of counters of
the current context, look at breakpoint type counters and disable
their pmu.

Ok it's not very cheap, I must admit.


It would be much less costly to just save the debug registers
actually, which is not that much costy in itself btw.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists