From: "Andreas Färber" <afaerber@suse.de>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
Martin Galvan <martin.galvan@tallertechnologies.com>,
Anthony Liguori <aliguori@amazon.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH] cpu-exec: Don't mask out external interrupts when single-stepping an invalid instruction.
Date: Mon, 15 Sep 2014 18:17:29 +0200 [thread overview]
Message-ID: <54171119.1030902@suse.de> (raw)
In-Reply-To: <CAFEAcA_hzvuTgpshsCut9nOU01wb0pWp1n4vQhZ1wp+1hbs2ig@mail.gmail.com>
Am 15.09.2014 um 18:10 schrieb Peter Maydell:
> On 15 September 2014 09:02, Martin Galvan
> <martin.galvan@tallertechnologies.com> wrote:
>> I did a bit more research on how Cortex-M handles nested interrupts.
>> In particular, I noticed if we were to have an invalid instruction
>> inside the exception handler itself, trying to single-step it would
>> again cause Qemu not to return control back to gdb. Reading up a bit I
>> found out that when the CPU is handling an exception, all other
>> exceptions with the same or lower priority will be blocked.
>>
>> Qemu seems to implement this by setting the exception as pending, yet
>> not changing cpu->interrupt_request so that we modify the PC in the
>> second call to do_interrupt. That seems fine to me, but since the
>> translation block is the same as before (and if that one contained an
>> exception_with_syndrome ending in a call to cpu_loop_exit) we'll be
>> stuck in the loop and we'll never return control to Gdb.
>>
>> Therefore I have two questions:
>> 1) Is this a bug?
>> 2) If it is, what should the behaviour be? I think we should return
>> control back to gdb, but we shouldn't try to translate that
>> instruction again. How could we handle this in a clean way?
>
> Our handling of exceptions and exception priorities for
> Cortex-M CPUs is totally wrong. We attempt to reuse the
> GIC priority handling code for interrupts, which then leaves
> the exceptions without the correct priority handling. Ideally
> we should rewrite this completely to give the M profile
> cores the architecturally mandated exception priority
> handling and masking, and stop trying to reuse the
> A/R profile core code at all. The two profiles are just
> too different for that to make sense.
Are you saying we should dump the inheritence completely?
Andreas
>
> Any bugs or weirdness in the current code are likely
> symptoms of attempting to shoehorn M profile into the
> A/R profile handling.
>
> -- PMM
>
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
next prev parent reply other threads:[~2014-09-15 16:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-11 21:02 [Qemu-devel] [PATCH] cpu-exec: Don't mask out external interrupts when single-stepping an invalid instruction Martin Galvan
2014-09-11 22:13 ` Peter Maydell
2014-09-11 23:52 ` Richard Henderson
2014-09-12 14:33 ` Martin Galvan
2014-09-12 15:37 ` Richard Henderson
2014-09-12 15:50 ` Martin Galvan
2014-09-15 16:02 ` Martin Galvan
2014-09-15 16:10 ` Peter Maydell
2014-09-15 16:17 ` Andreas Färber [this message]
2014-09-15 16:22 ` Peter Maydell
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=54171119.1030902@suse.de \
--to=afaerber@suse.de \
--cc=aliguori@amazon.com \
--cc=martin.galvan@tallertechnologies.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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).