| Message ID | 20230721120046.2262291-3-iii@linux.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: s390: interrupt: Fix stepping into interrupt handlers | expand |
On 21.07.23 13:57, Ilya Leoshkevich wrote: > Currently, after single-stepping an instruction that generates a > specification exception, GDB ends up on the instruction immediately > following it. > > The reason is that vcpu_post_run() injects the interrupt and sets > KVM_GUESTDBG_EXIT_PENDING, causing a KVM_SINGLESTEP exit. The > interrupt is not delivered, however, therefore userspace sees the > address of the next instruction. > > Fix by letting the __vcpu_run() loop go into the next iteration, > where vcpu_pre_run() delivers the interrupt and sets > KVM_GUESTDBG_EXIT_PENDING. > > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> > --- > arch/s390/kvm/intercept.c | 19 +++++++++++++++++-- > 1 file changed, 17 insertions(+), 2 deletions(-) > > diff --git a/arch/s390/kvm/intercept.c b/arch/s390/kvm/intercept.c > index 954d39adf85c..7cdd927541b0 100644 > --- a/arch/s390/kvm/intercept.c > +++ b/arch/s390/kvm/intercept.c > @@ -226,7 +226,22 @@ static int handle_itdb(struct kvm_vcpu *vcpu) > return 0; > } > > -#define per_event(vcpu) (vcpu->arch.sie_block->iprcc & PGM_PER) > +static bool should_handle_per_event(const struct kvm_vcpu *vcpu) > +{ > + if (!guestdbg_enabled(vcpu)) > + return false; > + if (!(vcpu->arch.sie_block->iprcc & PGM_PER)) > + return false; > + if (guestdbg_sstep_enabled(vcpu) && > + vcpu->arch.sie_block->iprcc != PGM_PER) { > + /* > + * __vcpu_run() will exit after delivering the concurrently > + * indicated condition. > + */ > + return false; > + } > + return true; > +} > > static int handle_prog(struct kvm_vcpu *vcpu) > { > @@ -242,7 +257,7 @@ static int handle_prog(struct kvm_vcpu *vcpu) > if (kvm_s390_pv_cpu_is_protected(vcpu)) > return -EOPNOTSUPP; > > - if (guestdbg_enabled(vcpu) && per_event(vcpu)) { > + if (should_handle_per_event(vcpu)) { > rc = kvm_s390_handle_per_event(vcpu); > if (rc) > return rc; Reviewed-by: David Hildenbrand <david@redhat.com>
diff --git a/arch/s390/kvm/intercept.c b/arch/s390/kvm/intercept.c index 954d39adf85c..7cdd927541b0 100644 --- a/arch/s390/kvm/intercept.c +++ b/arch/s390/kvm/intercept.c @@ -226,7 +226,22 @@ static int handle_itdb(struct kvm_vcpu *vcpu) return 0; } -#define per_event(vcpu) (vcpu->arch.sie_block->iprcc & PGM_PER) +static bool should_handle_per_event(const struct kvm_vcpu *vcpu) +{ + if (!guestdbg_enabled(vcpu)) + return false; + if (!(vcpu->arch.sie_block->iprcc & PGM_PER)) + return false; + if (guestdbg_sstep_enabled(vcpu) && + vcpu->arch.sie_block->iprcc != PGM_PER) { + /* + * __vcpu_run() will exit after delivering the concurrently + * indicated condition. + */ + return false; + } + return true; +} static int handle_prog(struct kvm_vcpu *vcpu) { @@ -242,7 +257,7 @@ static int handle_prog(struct kvm_vcpu *vcpu) if (kvm_s390_pv_cpu_is_protected(vcpu)) return -EOPNOTSUPP; - if (guestdbg_enabled(vcpu) && per_event(vcpu)) { + if (should_handle_per_event(vcpu)) { rc = kvm_s390_handle_per_event(vcpu); if (rc) return rc;
Currently, after single-stepping an instruction that generates a specification exception, GDB ends up on the instruction immediately following it. The reason is that vcpu_post_run() injects the interrupt and sets KVM_GUESTDBG_EXIT_PENDING, causing a KVM_SINGLESTEP exit. The interrupt is not delivered, however, therefore userspace sees the address of the next instruction. Fix by letting the __vcpu_run() loop go into the next iteration, where vcpu_pre_run() delivers the interrupt and sets KVM_GUESTDBG_EXIT_PENDING. Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> --- arch/s390/kvm/intercept.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-)