Re: [PATCH 3/5] hw-breakpoints: Rewrite the hw-breakpoints layeron top of perf counters

[Jan Kiszka]

Frederic Weisbecker wrote:
> This patch rebase the implementation of the breakpoints API on top of
> perf counters instances.
> 
> The core breakpoint API has changed a bit:
> 
> - register_kernel_hw_breakpoint() now takes a cpu as a parameter. For
>   now it doesn't support all cpu wide breakpoints but this may be
>   implemented soon.
> 
> - unregister_kernel_hw_breakpoint() and unregister_user_hw_breakpoint()
>   have been unified in a single unregister_hw_breakpoint()
> 
> Each breakpoints now match a perf counter which now handles the
> register scheduling, thread/cpu attachment, etc..
> 
> The new layering is now made as follows:
> 
>        ptrace       kgdb      ftrace   perf syscall
>           \          |          /         /
>            \         |         /         /

kgdb doesn't fit here as it requires nmi-safe services.

I don't think you want to make the whole stack nmi-safe but rather
provide a separate interface that allows kgdb to announce to the kernel
when it uses some slot. Those slots should simply be excluded from
hardware updates. That's roughly the logic we use in KVM for guest
debugging: when the host starts to use debug registers for that purpose,
the guest's setting will not effect the real hardware anymore.

>                                         /
>             Core breakpoint API        /
>                                       /
>                      |               /
>                      |              /
> 
>               Breakpoints perf counters
> 
>                      |
>                      |
> 
>                Breakpoints PMU ---- Debug Register constraints handling
>                                     (Part of core breakpoint API)
>                      |
>                      |
> 
>              Hardware debug registers
> 
> Reasons of this rewrite:
> 
> - Use the centralized/optimized pmu registers scheduling,
>   implying an easier arch integration
> - More powerful register handling: perf attributes (pinned/flexible
>   events, exclusive/non-exclusive, tunable period, etc...)
> 
> Impact:
> 
> - New perf ABI: the hardware breakpoints counters
> - Ptrace breakpoints setting remains tricky and still needs some per
>   thread breakpoints references.
> 
> Todo (in the order):
> 
> - Drop struct hw_breakpoint and store generic breakpoints fields inside
>   struct perf_counter_attr to have a common way to set breakpoints
>   parameters.
> - Support breakpoints perf counter events for perf tools (ie: implement
>   perf_bpcounter_event())
> - Support from perf tools

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.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature