Hi, Will,
Are you happy with this?:
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
+bool hw_breakpoint_enabled(void)
+{
+ struct perf_event **slots;
+ int i;
+
+ slots = this_cpu_ptr(bp_on_reg);
+ for (i = 0; i < core_num_brps; i++) {
+ if (slots[i])
+ return true;
+ }
+
+ slots = this_cpu_ptr(wp_on_reg);
+ for (i = 0; i < core_num_wrps; i++) {
+ if (slots[i])
+ return true;
+ }
+
+ return false;
+}
It doesn't change any existing functions, and even doesn't add a new
variables, it just provide an indication for KVM, and it's low-overhead.
We will only call it upon guest entry, so there is also no race for it.
On July 7, 2015 6:24:06 PM GMT+08:00, Will Deacon <will.deacon@xxxxxxx> wrote:
>On Tue, Jul 07, 2015 at 11:06:57AM +0100, Zhichao Huang wrote:
>> Chazy and me are talking about how to reduce the saving/restoring
>> overhead for debug registers.
>> We want to add a state in hw_breakpoint.c to indicate whether the
>host
>> enable any hwbrpts or not (might export a fuction that kvm can call),
>> then we can read this state from memory instead of reading from real
>> hardware registers, and to decide whether we need a world switch or
>> not.
>> Does it acceptable?
>
>Maybe, hard to tell without the code. There are obvious races to deal
>with
>if you use variables to indicate whether resources are in use -- why
>not
>just trap debug access from the host as well? Then you could keep track
>of
>the "owner" in kvm and trap accesses from everybody else.
>
>Will
--
Zhichao Huang
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
