[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <dba4395d-400a-7bea-5eba-a44cab80ce0e@redhat.com>
Date: Mon, 24 Jul 2023 10:56:56 +0200
From: David Hildenbrand <david@...hat.com>
To: Ilya Leoshkevich <iii@...ux.ibm.com>,
Christian Borntraeger <borntraeger@...ux.ibm.com>,
Janosch Frank <frankja@...ux.ibm.com>,
Claudio Imbrenda <imbrenda@...ux.ibm.com>,
Heiko Carstens <hca@...ux.ibm.com>,
Vasily Gorbik <gor@...ux.ibm.com>,
Alexander Gordeev <agordeev@...ux.ibm.com>
Cc: Sven Schnelle <svens@...ux.ibm.com>, kvm@...r.kernel.org,
linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org,
Jens Freimann <jfreimann@...hat.com>
Subject: Re: [PATCH v2 1/6] KVM: s390: interrupt: Fix single-stepping into
interrupt handlers
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@...ux.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?
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
Powered by blists - more mailing lists