Question about DBCR0 initialization for 440

[Hollis Blanchard]

On Friday 17 April 2009 12:22:37 Josh Boyer wrote:
> On Fri, Apr 17, 2009 at 11:46 AM, John Linn <John.Linn at xilinx.com> wrote:
> > Josh, any thoughts on putting this into head_44x.S?
> 
> The code in the fsl file looks like the right solution.  I do have an
> odd question though, in that it's hard for the
> kernel to really know if something like a BDI is running.  Namely,
> that config option doesn't cover RiscWatch in an obvious manner.

Yeah, setting DBCR0 would interfere with all JTAG probes. The ifdef meands you 
can't support both a JTAG debugger and hardware breakpoints in the same 
binary? Now that's an annoying restriction.

> I also wonder if it's possible to have a host system be setting those
> registers in a guest KVM system so the guest could be debugged with
> gdb...  Hollis, any idea on that?

You mean is KVM currently doing that, and would this patch conflict with that 
behavior?

Right now KVM (on 440) context switches the necessary DB* registers for out-
of-band debugging. That is, qemu sends a "set breakpoint in guest" ioctl to 
KVM, and then when switching from host to guest mode, KVM will save the old 
DB* values, put in some new ones, and swap them back again when re-entering 
the host. So I *think* the answer to your question is "yes, KVM messes with 
these registers to enable software breakpoints when debugging a guest with 
gdb." That code path isn't heavily tested, but the values put into DB* by 
other host code shouldn't matter.

However, KVM doesn't support in-band breakpoints, i.e. it doesn't emulate the 
setting of those registers from within the guest. It's basically a no-op. So 
whether the kernel sets them or not, in-band debugging won't work with the 
current KVM code.

-- 
Hollis Blanchard
IBM Linux Technology Center