Supporting KVM_GUESTDBG_BLOCKIRQ or something similar on ARM64
Marc Zyngier
maz at kernel.org
Mon Oct 28 04:23:30 PDT 2024
[+ArdB, which I assume you really wanted to Cc on this, as well as the
KVM/arm64 stakeholders]
On Mon, 28 Oct 2024 10:53:34 +0000,
puranjay at kernel.org wrote:
>
> Hi Everyone,
>
> I work on the BPF JIT for arm64 and regularly use Qemu with gdb for
> debugging by single stepping parts of the code. I realized that whenever
> I enable KVM, single stepping doesn't work as expected and it lands in an
> interrupt handler.
I disagree. Single-stepping works *exactly* as you should expect, by
not interfering with the rest of the system.
> It always worked for me on x86 so I looked in the source code and found
> that x86 supports KVM_GUESTDBG_BLOCKIRQ that blocks IRQs when single
> stepping.
Right, and that is not an architectural behaviour, but something that
helps the person running the debugger. I'm not saying it is not
useful, but that this is an *additional* behaviour that the
architecture is not supposed to cover.
Also, given that KVM_GUESTDBG_BLOCKIRQ has *zero* documentation,
nobody felt compelled to implement it. I didn't even know of its
existence until you mentioned it.
> I assume that arm64 doesn't support KVM_GUESTDBG_BLOCKIRQ because it is
> not trivial to implement this on arm64 due to some architectural
> limitations? There was a patch [1] posted in 2022 to solve this issue
> but it was not merged.
That patch does the wrong thing when it comes to KVM. We are not
building a Linux-only hypervisor, and we need a solution that works
irrespective of the guest.
> Let's start a discussion about what needs to be done to support this on
> arm64.
A good start would be to define the semantics of such a flag:
- what should it affect? the vcpu you are single-stepping? all vcpu?
- should userspace to know that interrupts are pending?
- should this result in any effect on the guest's view of time?
- what of interactions on the rest of the system (such as devices)?
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
More information about the linux-arm-kernel
mailing list