From: James Morse <james.morse@arm.com>
To: Florian Jakobsmeier <florian.jakobsmeier@googlemail.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
Julien Grall <julien.grall@arm.com>,
Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: xen/arm: Software Step ARMv8 - PC stuck on instruction
Date: Thu, 03 Aug 2017 14:02:52 +0100 [thread overview]
Message-ID: <59831EFC.1080207@arm.com> (raw)
In-Reply-To: <CAAH2inebouvCLjjAyTDhQd2HCn5JAKpss2gfOs+LEV9orBvfjw@mail.gmail.com>
Hi Florian,
On 03/08/17 13:29, Florian Jakobsmeier wrote:
> So as far as I understood both of you don't see a general problem with
> (timer) interrupts or the scheduler while being single stepped? Because in
> my opinion after enabling singlestep the system will go into a "spinlock"
> routine.
Interrupts taken to EL2 will cause PSTATE.SS to be saved in SPSR_EL2.SS. This is
then restored by the ERET (provided Xen's PSTATE.D bit is set).
If its a virtual interrupt taken to EL1, you will end up stepping the interrupt
handler.
> Adapting your recommendations doesn't change the behavior.
> I'm still able to step over each instruction, but the control flow does not
> follow my module but rather executes my SMC to start SS and then enters the
> before mentioned procedure.
again?
SMC... Xen runs at EL2 so you must be trapping this. If the SMC is taken as trap
the ELR isn't updated to point to the instruction after the SMC, you have to do
this yourself. (See the 'note' for HCR_EL2.TSC in 'D1.15.3 EL2 configurable
controls')
SMC is also a corner case for single step. The PSTATE.SS bit isn't saved in the
SPSR. See Table D2-25 in 'D2.12.5 Behaviour in the active-not-pending state'.
Thanks,
James
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-08-03 13:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-04 12:30 xen/arm: Software Step ARMv8 - PC stuck on instruction Florian Jakobsmeier
2017-07-04 18:37 ` Julien Grall
2017-07-05 14:03 ` Florian Jakobsmeier
2017-07-26 13:12 ` Florian Jakobsmeier
2017-08-02 13:32 ` Julien Grall
2017-08-03 9:49 ` James Morse
2017-08-03 10:16 ` Florian Jakobsmeier
2017-08-03 10:46 ` James Morse
2017-08-03 11:08 ` Julien Grall
2017-08-03 12:29 ` Florian Jakobsmeier
2017-08-03 13:02 ` James Morse [this message]
2017-08-03 16:00 ` Florian Jakobsmeier
2017-08-07 17:05 ` James Morse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=59831EFC.1080207@arm.com \
--to=james.morse@arm.com \
--cc=florian.jakobsmeier@googlemail.com \
--cc=julien.grall@arm.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).