qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] cpu-exec: Don't mask out external interrupts wh


From: Andreas Färber
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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0

Am 15.09.2014 um 18:10 schrieb Peter Maydell:
> On 15 September 2014 09:02, Martin Galvan
> <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]