> On 4 Nov 2022, at 19.41, francesco.cag...@gmail.com wrote:
>
> From: Francesco Cagnin <fcag...@quarkslab.com>
>
> Support is added for single-stepping, software breakpoints, hardware
> breakpoints and watchpoints. The code has been structured like the KVM
> counterpart (and many parts are basically identical).
>
> Guests can be debugged through the gdbstub.
>
> Signed-off-by: Francesco Cagnin <fcag...@quarkslab.com>
> ---
> accel/hvf/hvf-accel-ops.c | 124 ++++++++++++++++++++++++
> accel/hvf/hvf-all.c | 24 +++++
> cpu.c | 3 +
> include/sysemu/hvf.h | 29 ++++++
> include/sysemu/hvf_int.h | 1 +
> target/arm/hvf/hvf.c | 194 +++++++++++++++++++++++++++++++++++++-
> 6 files changed, 374 insertions(+), 1 deletion(-)
>
> diff --git a/include/sysemu/hvf.h b/include/sysemu/hvf.h
> index bb70082e45..3e99c80416 100644
> --- a/include/sysemu/hvf.h
> +++ b/include/sysemu/hvf.h
> @@ -1180,6 +1201,9 @@ int hvf_vcpu_exec(CPUState *cpu)
>
> flush_cpu_state(cpu);
>
> + r = hv_vcpu_set_trap_debug_exceptions(cpu->hvf->fd,
> trap_debug_exceptions);
> + assert_hvf_ok(r);
> +
> qemu_mutex_unlock_iothread();
> assert_hvf_ok(hv_vcpu_run(cpu->hvf->fd));
We don't need to set this at every call to `hvf_vcpu_exec`. Would it make sense
to move it to `hvf_arch_update_guest_debug` or even `hvf_arch_init_vcpu`?
(CC'ed Alex Bennée as we discussed the GDB stub in HVF at KVM Forum 2022)
