Messages in this thread | | | Subject | Re: [PATCH v2 1/6] KVM: s390: interrupt: Fix single-stepping into interrupt handlers | From | Ilya Leoshkevich <> | Date | Mon, 24 Jul 2023 10:42:29 +0200 |
| |
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@linux.ibm.com> > > --- > > 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?
> But this is simpler and should work as well. > > Acked-by: David Hildenbrand <david@redhat.com>
| |