Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1443574 > unrolled thread

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

Started byCatalin Marinas <catalin.marinas@arm.com>
First post2016-07-14 18:30 +0200
Last post2016-07-19 16:10 +0200
Articles 10 — 5 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support Catalin Marinas <catalin.marinas@arm.com> - 2016-07-14 18:30 +0200
    Re: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support William Cohen <wcohen@redhat.com> - 2016-07-14 19:10 +0200
      Re: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support Catalin Marinas <catalin.marinas@arm.com> - 2016-07-15 10:00 +0200
        Re: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support Marc Zyngier <marc.zyngier@arm.com> - 2016-07-15 10:10 +0200
          Re: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support Alex Bennée <alex.bennee@linaro.org> - 2016-07-15 11:00 +0200
            Re: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support Marc Zyngier <marc.zyngier@arm.com> - 2016-07-15 11:10 +0200
            Re: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support Marc Zyngier <marc.zyngier@arm.com> - 2016-07-15 12:00 +0200
    Re: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support David Long <dave.long@linaro.org> - 2016-07-14 20:00 +0200
    Re: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support Catalin Marinas <catalin.marinas@arm.com> - 2016-07-19 16:00 +0200
      Re: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support David Long <dave.long@linaro.org> - 2016-07-19 16:10 +0200

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

FromCatalin Marinas <catalin.marinas@arm.com>
Date2016-07-14 18:30 +0200
SubjectRe: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
Message-ID<rURGp-3xe-7@gated-at.bofh.it>
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?

-- 
Catalin

[toc] | [next] | [standalone]

#1443608

FromWilliam Cohen <wcohen@redhat.com>
Date2016-07-14 19:10 +0200
Message-ID<rUSj8-41y-21@gated-at.bofh.it>
In reply to#1443574
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?
> 

Hi,

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?

-Will Cohen

[toc] | [prev] | [next] | [standalone]

#1444021

FromCatalin Marinas <catalin.marinas@arm.com>
Date2016-07-15 10:00 +0200
Message-ID<rV6cp-4aE-1@gated-at.bofh.it>
In reply to#1443608
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.

-- 
Catalin

[toc] | [prev] | [next] | [standalone]

#1444026

FromMarc Zyngier <marc.zyngier@arm.com>
Date2016-07-15 10:10 +0200
Message-ID<rV6m6-4sZ-11@gated-at.bofh.it>
In reply to#1444021
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...

[toc] | [prev] | [next] | [standalone]

#1444079

FromAlex Bennée <alex.bennee@linaro.org>
Date2016-07-15 11:00 +0200
Message-ID<rV78t-4JM-21@gated-at.bofh.it>
In reply to#1444026
Marc Zyngier <marc.zyngier@arm.com> writes:

> 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?

Sure I'll have a look. There are problems with running gdb inside a
guest while trying to debug from outside associated with single-stepping
but none of this should get in the way if your not debugging the guest.

Let me get my system spun up and see if I can reproduce.

Shall I just apply this series on top of the current master?

--
Alex Bennée

[toc] | [prev] | [next] | [standalone]

#1444094

FromMarc Zyngier <marc.zyngier@arm.com>
Date2016-07-15 11:10 +0200
Message-ID<rV7ia-52g-63@gated-at.bofh.it>
In reply to#1444079
On 15/07/16 09:59, Alex Bennée wrote:
> 
> Marc Zyngier <marc.zyngier@arm.com> writes:
> 
>> 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?
> 
> Sure I'll have a look. There are problems with running gdb inside a
> guest while trying to debug from outside associated with single-stepping
> but none of this should get in the way if your not debugging the guest.
> 
> Let me get my system spun up and see if I can reproduce.
> 
> Shall I just apply this series on top of the current master?

I'm trying with -rc7 at the moment.

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

[toc] | [prev] | [next] | [standalone]

#1444129

FromMarc Zyngier <marc.zyngier@arm.com>
Date2016-07-15 12:00 +0200
Message-ID<rV84x-5iI-11@gated-at.bofh.it>
In reply to#1444079
On 15/07/16 09:59, Alex Bennée wrote:
> 
> Marc Zyngier <marc.zyngier@arm.com> writes:
> 
>> 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?
> 
> Sure I'll have a look. There are problems with running gdb inside a
> guest while trying to debug from outside associated with single-stepping
> but none of this should get in the way if your not debugging the guest.
> 
> Let me get my system spun up and see if I can reproduce.
> 
> Shall I just apply this series on top of the current master?

I managed to reproduce it by taskset-ing 2 vcpus on the same physical
CPU, and trying a few dozen times on Juno-r1. It is not easy to trigger,
but when it happens it is quite bad.

Warning, pure speculation ahead: I suspect that we preempt a vcpu with
single-step enabled, somehow fail to clear the SS state, schedule
another vcpu that inherits that state and takes this unexpected SS
exception.

/me goes and have a look...

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

[toc] | [prev] | [next] | [standalone]

#1443648

FromDavid Long <dave.long@linaro.org>
Date2016-07-14 20:00 +0200
Message-ID<rUT5w-4jD-15@gated-at.bofh.it>
In reply to#1443574
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 have not run this code as a guest, I have only tested it natively.

-dl

[toc] | [prev] | [next] | [standalone]

#1446498

FromCatalin Marinas <catalin.marinas@arm.com>
Date2016-07-19 16:00 +0200
Message-ID<rWDJ0-4IM-25@gated-at.bofh.it>
In reply to#1443574
On Thu, Jul 14, 2016 at 05:22:08PM +0100, 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".

FYI, we managed to track down the issue to two bugs in the arm64 kernel
boot part, occasionally leaving the PSTATE.D bit set for kernel threads.
While not KVM specific, the pre-conditions were more likely when running
as a guest (receiving interrupts early on during boot, possibly because
of a slow-down in the booting process due to stage 2 page faulting
mechanism).

Will is going to post the fixes soon.

-- 
Catalin

[toc] | [prev] | [next] | [standalone]

#1446502

FromDavid Long <dave.long@linaro.org>
Date2016-07-19 16:10 +0200
Message-ID<rWDSF-516-3@gated-at.bofh.it>
In reply to#1446498
On 07/19/2016 09:57 AM, Catalin Marinas wrote:
> On Thu, Jul 14, 2016 at 05:22:08PM +0100, 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".
>
> FYI, we managed to track down the issue to two bugs in the arm64 kernel
> boot part, occasionally leaving the PSTATE.D bit set for kernel threads.
> While not KVM specific, the pre-conditions were more likely when running
> as a guest (receiving interrupts early on during boot, possibly because
> of a slow-down in the booting process due to stage 2 page faulting
> mechanism).
>
> Will is going to post the fixes soon.
>

Excellent news.

Thanks,
-dl

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web