Re: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support

[Marc Zyngier]

On 15/07/16 08:50, Catalin Marinas wrote:
> On Thu, Jul 14, 2016 at 01:09:08PM -0400, William Cohen wrote:
>> On 07/14/2016 12:22 PM, Catalin Marinas wrote:
>>> On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
>>>> David A. Long (3):
>>>>   arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
>>>>   arm64: Add more test functions to insn.c
>>>>   arm64: add conditional instruction simulation support
>>>>
>>>> Pratyush Anand (2):
>>>>   arm64: Blacklist non-kprobe-able symbol
>>>>   arm64: Treat all entry code as non-kprobe-able
>>>>
>>>> Sandeepa Prabhu (4):
>>>>   arm64: Kprobes with single stepping support
>>>>   arm64: kprobes instruction simulation support
>>>>   arm64: Add kernel return probes support (kretprobes)
>>>>   kprobes: Add arm64 case in kprobe example module
>>>>
>>>> William Cohen (1):
>>>>   arm64: Add trampoline code for kretprobes
>>>
>>> I applied these patches on top of the arm64 for-next/core branch an
>>> tried to run the resulting kernel in a guest (on a Juno platform using
>>> both kvmtool and qemu) with KPROBES_SANITY_TEST enabled. Unfortunately,
>>> the kernel fails to boot with lots of "Unexpected kernel single-step
>>> exception at EL1".
>>>
>>> Did you manage to run Kprobes in a guest before?
>>
>> I ran the systemtap testsuite several times on a physical machine
>> running a kernel with the kprobe v15 patches without problem.
>> Shouldn't the guest machine behave in the same manner as a host
>> machine for single stepping and exception handling?  If the guest
>> machine is failing, wouldn't that suggest there is a problem with the
>> KVM handling of single stepping for guests?
> 
> It didn't fail for me on the host either. What's strange is that on some
> occasions even the guest managed to get to a prompt. I'll do more tests
> today on different CPU configurations, just to rule out potential
> hardware issues. If not hardware related, it's possible that the
> interaction with KVM doesn't work as expected, maybe the
> saving/restoring of the guest debug state loses information.

Could well be the latter. I'll try to have a look, but Alex Bennée (on
cc) is our man when it comes to the KVM debug infrastructure.

Alex, any chance you could try this and shed some light on it?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...