On Mon, 2023-07-24 at 10:22 +0200, David Hildenbrand wrote:
On 21.07.23 13:57, Ilya Leoshkevich wrote:
After single-stepping an instruction that generates an interrupt,
GDB
ends up on the second instruction of the respective interrupt
handler.
The reason is that vcpu_pre_run() manually delivers the interrupt,
and
then __vcpu_run() runs the first handler instruction using the
CPUSTAT_P flag. This causes a KVM_SINGLESTEP exit on the second
handler
instruction.
Fix by delaying the KVM_SINGLESTEP exit until after the manual
interrupt delivery.
Signed-off-by: Ilya Leoshkevich <iii@xxxxxxxxxxxxx>
---
arch/s390/kvm/interrupt.c | 10 ++++++++++
arch/s390/kvm/kvm-s390.c | 4 ++--
2 files changed, 12 insertions(+), 2 deletions(-)
[...]
Can we add a comment like
/*
* We delivered at least one interrupt and modified the PC. Force a
* singlestep event now.
*/
Ok, will do.
+ if (delivered && guestdbg_sstep_enabled(vcpu)) {
+ struct kvm_debug_exit_arch *debug_exit = &vcpu-
run->debug.arch;+
+ debug_exit->addr = vcpu->arch.sie_block->gpsw.addr;
+ debug_exit->type = KVM_SINGLESTEP;
+ vcpu->guest_debug |= KVM_GUESTDBG_EXIT_PENDING;
}
I do wonder if we, instead, want to do this whenever we modify the
PSW.
That way we could catch any PC changes and only have to add checks
for
guestdbg_exit_pending().
Wouldn't this break a corner case where the first instruction of the
interrupt handler causes the same interrupt?