linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: tingwei@codeaurora.org
To: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: hw_breakpoint: don't clear debug registers in halt mode
Date: Tue, 31 Mar 2020 10:39:42 +0800	[thread overview]
Message-ID: <2f4d076b2b21de3908f0821126d0c61e@codeaurora.org> (raw)
In-Reply-To: <20200330134218.GB10633@willie-the-truck>

在 2020-03-30 21:42,Will Deacon 写道:
> On Mon, Mar 30, 2020 at 01:39:46PM +0100, Mark Rutland wrote:
>> On Sat, Mar 28, 2020 at 04:32:09PM +0800, Tingwei Zhang wrote:
>> > If external debugger sets a breakpoint for one Kernel function
>> > when device is in bootloader mode and loads Kernel, this breakpoint
>> > will be wiped out in hw_breakpoint_reset(). To fix this, check
>> > MDSCR_EL1.HDE in hw_breakpoint_reset(). When MDSCR_EL1.HDE is
>> > 0b1, halting debug is enabled. Don't reset debug registers in this
> case.
>> 
>> I don't think this is sufficient, because the kernel can still
>> subsequently mess with breakpoints, and the HW debugger might not be
>> attached at this point in time anyhow.
>> 
>> I reckon this should hang off the existing "nodebumon" command line
>> option, and we shouldn't use HW breakpoints at all when that is 
>> passed.
>> Then you can pass that to prevent the kernel stomping on the external
>> debugger.
>> 
>> Will, thoughts?
> 
> I was going to suggest the same thing, although we will also need to 
> take
> care to reset the registers if "nodebugmon" is toggled at runtime via 
> the
> "debug_enabled" file in debugfs.
> 
> Will

Thanks for the suggestion, Mark and Will. It's a great idea to use
"nodebugmon". When "nodebugmon" is set, Kernel won't change HW 
breakpoints.

For reset the registers after "debug_enabled" is toggled, I'm thinking 
if
we are adding unnecessary complexity here.If we take that approach, we 
will
hook "debug_enabled" interface and use smp_call_function_single() to 
call
hw_breakpoint_reset() on each CPU. Wait for all CPUs' execution done and
change "debug_enabled". External debugger would clear the breakpoints 
when
it detaches the device and restores its breakpoints when attaches the 
device.
Assume debug_enabled is changed to one after external debugger detaches 
the
device. Debugger would already clear the breakpoint registers. If 
debgger is
still attached, there's nothing Kernel can do to stop it 
restores/programs
the breakpoint registers.

What do you think of this?

Thanks,
Tingwei

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-03-31  2:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-28  8:32 [PATCH] arm64: hw_breakpoint: don't clear debug registers in halt mode Tingwei Zhang
2020-03-30 12:39 ` Mark Rutland
2020-03-30 13:42   ` Will Deacon
2020-03-31  2:39     ` tingwei [this message]
2020-03-31  7:41       ` Will Deacon
2020-03-31 11:33         ` tingwei
2020-03-31 11:45           ` Will Deacon
2020-04-21  3:49             ` tingwei
2020-04-21  7:10               ` Will Deacon

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=2f4d076b2b21de3908f0821126d0c61e@codeaurora.org \
    --to=tingwei@codeaurora.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=will@kernel.org \
    /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).