On 24.07.23 10:42, Ilya Leoshkevich wrote:
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?
Could be, there are many possible corner cases (PGM interrupt at the
first instruction of PGM interrupt handler -- our PSW address might not
even change)
--
Cheers,
David / dhildenb
