Re: [Qemu-devel] ARM Cortex-M issues

[Peter Maydell]

On 29 August 2016 at 13:59, Bill Paul <address@hidden> wrote:
> Unfortunately it's been a frustrating experience because there seem to be
> several key places where QEMU's hardware emulation diverges from reality. The
> ChibiOS examples often seem to depend on behavior that is valid for actual
> hardware but which is either broken or just missing in QEMU. Some of these
> issues are board-specific, but the last one seems a bit more general.

Yes, our Cortex-M support is a bit undermaintained at the moment.
If you'd like to write patches to fix some of the bugs you're
encountering I'd be happy to review them, but I'm not aware of anybody
actively working on M profile right now. We could really use a
contributor who cares about it and has time to tackle improving it.
(A-profile ARM emulation is in much better shape.)

> This problem in particular has me baffled, and I'm forced to ask questions. It
> seems like the ARM CPU simulation doesn't support the notion of NMI at all. (I
> think it would be a separate input from IRQ and FIQ, no?) How is this supposed
> to work? It seems like the Cortex-M hardware allows for software-generated
> NMIs, so why isn't this supported? How is this supposed to work on other ARM
> CPUs like Cortex-A? Is it really the case that nobody has tried this before?

Our M profile interrupt code is really badly mismodelled. It was
written many years ago as a hack based on modifying the A profile
support and GIC code, but really M profile is different (the interrupt
and exception model is an integrated part of the CPU). A lot of
the bugs stem from this basic problem.

For A profile, IRQ and FIQ work fine -- there is no such thing as
NMI in A profile (sometimes OSes like Linux have an "NMI" concept
that is named from x86 that is mapped onto FIQ).

For M profile, NMI is just one of the many interrupt/exceptions;
we don't really get it right because we're mis-modelling this with
interrupts in an external interrupt controller and exceptions in
the CPU model.

There were some patches posted to the list last year (?) which had
a go at fixing this, but unfortunately they got stalled in code
review and the original submitter ran out of time/energy to finish
the job. Getting those sorted out and into master would be a good
first step.

> ChibiOS/RT seems to support an alternate preemption scheme that uses the
> PendSV interrupt instead of NMI, and if I compile it to use that mode, then
> the example works with the Stellaris machine model. That feels like a hack
> though: shouldn't a software NMI just work?

The reason for this kind of thing is that the original support was
done to support a specific RTOS, and so bugs which resulted in that
RTOS not working were found and fixed. Bugs which weren't exercised
by that RTOS remain lurking in the code, and if you try to use a
different RTOS guest then you can run into them. (This is less
obvious on the A profile cores because to a first approximation
nobody runs anything but Linux on them, but in the embedded world
there's still a fairly rich diversity of RTOSes which take different
approaches to how they prod the hardware.)

thanks
-- PMM