mbox series

[v4,0/6] KVM: s390: interrupt: Fix stepping into interrupt handlers

Message ID 20230725143857.228626-1-iii@linux.ibm.com
Headers
Series KVM: s390: interrupt: Fix stepping into interrupt handlers |

Message

Ilya Leoshkevich July 25, 2023, 2:37 p.m. UTC 
  v3: https://lore.kernel.org/kvm/20230724094716.91510-1-iii@linux.ibm.com/
v3 -> v4: Restore the per_event() macro (Claudio).

v2: https://lore.kernel.org/lkml/20230721120046.2262291-1-iii@linux.ibm.com/
v2 -> v3: Add comments, improve the commit messages (Christian, David).
          Add R-bs.
          Patches that need review: [4/6], [6/6].

v1: https://lore.kernel.org/lkml/20230629083452.183274-1-iii@linux.ibm.com/
v1 -> v2: Fix three more issues.
          Add selftests (Claudio).

Hi,

I tried to compare the behavior of KVM and TCG by diffing instruction
traces, and found five issues in KVM related to stepping into interrupt
handlers.

Best regards,
Ilya

Ilya Leoshkevich (6):
  KVM: s390: interrupt: Fix single-stepping into interrupt handlers
  KVM: s390: interrupt: Fix single-stepping into program interrupt
    handlers
  KVM: s390: interrupt: Fix single-stepping kernel-emulated instructions
  KVM: s390: interrupt: Fix single-stepping userspace-emulated
    instructions
  KVM: s390: interrupt: Fix single-stepping keyless mode exits
  KVM: s390: selftests: Add selftest for single-stepping

 arch/s390/kvm/intercept.c                     |  38 ++++-
 arch/s390/kvm/interrupt.c                     |  14 ++
 arch/s390/kvm/kvm-s390.c                      |  27 ++-
 tools/testing/selftests/kvm/Makefile          |   1 +
 .../testing/selftests/kvm/s390x/debug_test.c  | 160 ++++++++++++++++++
 5 files changed, 229 insertions(+), 11 deletions(-)
 create mode 100644 tools/testing/selftests/kvm/s390x/debug_test.c

Comments

Sean Christopherson Aug. 2, 2023, 10:24 p.m. UTC | #1 
On Tue, Jul 25, 2023, Ilya Leoshkevich wrote:
> Ilya Leoshkevich (6):
>   KVM: s390: interrupt: Fix single-stepping into interrupt handlers
>   KVM: s390: interrupt: Fix single-stepping into program interrupt
>     handlers
>   KVM: s390: interrupt: Fix single-stepping kernel-emulated instructions
>   KVM: s390: interrupt: Fix single-stepping userspace-emulated
>     instructions
>   KVM: s390: interrupt: Fix single-stepping keyless mode exits
>   KVM: s390: selftests: Add selftest for single-stepping

FYI, the selftests change silently conflicts with a global s/ASSERT_EQ/TEST_ASSERT_EQ
rename[1], but the conflicts are very straightforward to resolve (just prepend TEST_).
If we want to proactively avoid mild pain in linux-next, one option would be to merge
the full kvm-x86/selftests branch/tag once I've made that immutable[2] (will be done
Friday if there are no fireworks).  Though we can probably just get away with doing
nothing other than letting Paolo know there's a silent conflict.

[1] https://lore.kernel.org/all/169101245511.1754469.7852701829984104093.b4-ty@google.com
[2] https://lore.kernel.org/all/169101267140.1755771.17089576255751273053.b4-ty@google.com
Christian Borntraeger Aug. 3, 2023, 7:48 a.m. UTC | #2 
Am 03.08.23 um 00:24 schrieb Sean Christopherson:
> On Tue, Jul 25, 2023, Ilya Leoshkevich wrote:
>> Ilya Leoshkevich (6):
>>    KVM: s390: interrupt: Fix single-stepping into interrupt handlers
>>    KVM: s390: interrupt: Fix single-stepping into program interrupt
>>      handlers
>>    KVM: s390: interrupt: Fix single-stepping kernel-emulated instructions
>>    KVM: s390: interrupt: Fix single-stepping userspace-emulated
>>      instructions
>>    KVM: s390: interrupt: Fix single-stepping keyless mode exits
>>    KVM: s390: selftests: Add selftest for single-stepping
> 
> FYI, the selftests change silently conflicts with a global s/ASSERT_EQ/TEST_ASSERT_EQ
> rename[1], but the conflicts are very straightforward to resolve (just prepend TEST_).
> If we want to proactively avoid mild pain in linux-next, one option would be to merge
> the full kvm-x86/selftests branch/tag once I've made that immutable[2] (will be done
> Friday if there are no fireworks).  Though we can probably just get away with doing
> nothing other than letting Paolo know there's a silent conflict.
> 
> [1] https://lore.kernel.org/all/169101245511.1754469.7852701829984104093.b4-ty@google.com
> [2] https://lore.kernel.org/all/169101267140.1755771.17089576255751273053.b4-ty@google.com

Thanks for telling. Paolo, do you have a preference?

Janosch, Claudio I think this series is good to go otherwise.