[Qemu-devel] QEMU ARM946 emulation, DIGIC, and MPU fault handling

[Qemu-devel] QEMU ARM946 emulation, DIGIC, and MPU fault handling

[Peter Maydell]

Hi Antony; have you noticed any issues with QEMU's handling of
MPU faults (data or address faults) on our ARM946 model?
I ask because DIGIC is the only board we have that uses the 946,
and as far as I can tell from the QEMU source code we will
incorrectly trash the access permissions registers any time we
take an MPU fault.

By 'access permission registers' I mean these:

MRC p15, 0, Rd, c5, c0, 2; read data access permission bits
MRC p15, 0, Rd, c5, c0, 3; read instruction access permission bits
MRC p15, 0, Rd, c5, c0, 0; read data access permission bits
MRC p15, 0, Rd, c5, c0, 1; read instruction access permission bits

as described in the 946 TRM:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0201d/Babfaiic.html

Looking at the source code it seems like cpu_arm_handle_mmu_fault()
will write the fault status into c5_data/c5_insn, because that is where
we keep the DFSR and IFSR for an ARM with an MMU.

Since the 946 doesn't provide any way to find out what the fault
address actually was (it has no DFAR or IFAR) I presume that all
guest software treats a data abort or prefetch abort as a fatal error,
which is probably part of why nobody's ever noticed this.

This bug would also affect the ARMv7M CPU (Cortex-M3) we emulate,
except that as far as I can tell we don't implement its MPU interface at all!
(it uses memory mapped registers rather than cp15 regs, and they just
aren't wired up in armv7m_nvic.c...)

thanks
-- PMM

Re: [Qemu-devel] QEMU ARM946 emulation, DIGIC, and MPU fault handling

[Andreas Färber]

Am 23.01.2014 23:25, schrieb Peter Maydell:
> This bug would also affect the ARMv7M CPU (Cortex-M3) we emulate,
> except that as far as I can tell we don't implement its MPU interface at all!
> (it uses memory mapped registers rather than cp15 regs, and they just
> aren't wired up in armv7m_nvic.c...)

That matches my memories of investigating Cortex-R4. There is some MPU
code present somewhere, but it appeared to be for some older CPU,
possibly OMAP2.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] QEMU ARM946 emulation, DIGIC, and MPU fault handling

[Peter Maydell]

On 23 January 2014 23:36, Andreas Färber <afaerber@suse.de> wrote:
> Am 23.01.2014 23:25, schrieb Peter Maydell:
>> This bug would also affect the ARMv7M CPU (Cortex-M3) we emulate,
>> except that as far as I can tell we don't implement its MPU interface at all!
>> (it uses memory mapped registers rather than cp15 regs, and they just
>> aren't wired up in armv7m_nvic.c...)
>
> That matches my memories of investigating Cortex-R4. There is some MPU
> code present somewhere, but it appeared to be for some older CPU,
> possibly OMAP2.

The only CPUs with an MPU we support are the 946 and the M3.
(The OMAP SoCs have always had MPUs: OMAP1 was a 926 and
OMAP2 an 1136.)

Apparently in theory the Integrator/CP board can handle a 946.
I guess it would have to be running uClinux.

thanks
-- PMM

Re: [Qemu-devel] QEMU ARM946 emulation, DIGIC, and MPU fault handling

[Antony Pavlov]

On Thu, 23 Jan 2014 22:25:36 +0000
Peter Maydell <peter.maydell@linaro.org> wrote:

> Hi Antony; have you noticed any issues with QEMU's handling of
> MPU faults (data or address faults) on our ARM946 model?
> I ask because DIGIC is the only board we have that uses the 946,
> and as far as I can tell from the QEMU source code we will
> incorrectly trash the access permissions registers any time we
> take an MPU fault.
> 
> By 'access permission registers' I mean these:
> 
> MRC p15, 0, Rd, c5, c0, 2; read data access permission bits
> MRC p15, 0, Rd, c5, c0, 3; read instruction access permission bits
> MRC p15, 0, Rd, c5, c0, 0; read data access permission bits
> MRC p15, 0, Rd, c5, c0, 1; read instruction access permission bits
> 
> as described in the 946 TRM:
> http://infocenter.arm.com/help/topic/com.arm.doc.ddi0201d/Babfaiic.html
> 
> Looking at the source code it seems like cpu_arm_handle_mmu_fault()
> will write the fault status into c5_data/c5_insn, because that is where
> we keep the DFSR and IFSR for an ARM with an MMU.
> 
> Since the 946 doesn't provide any way to find out what the fault
> address actually was (it has no DFAR or IFAR) I presume that all
> guest software treats a data abort or prefetch abort as a fatal error,
> which is probably part of why nobody's ever noticed this.
> 
> This bug would also affect the ARMv7M CPU (Cortex-M3) we emulate,
> except that as far as I can tell we don't implement its MPU interface at all!
> (it uses memory mapped registers rather than cp15 regs, and they just
> aren't wired up in armv7m_nvic.c...)

Sorry for delay!

The number of software, running on DIGIC is very limited:
 * Canon Camera firware + maybe Magic Lantern or CHDK;
 * barebox.

I know nothing about MPU fault handling in barebox.

I'm planning to merge current qemu DIGIC support with patches from MagicLantern qemu patches.
May be during this work I'll be capable to answer your question, but just now I have no answer, sorry.

May be Magic Lantern people (especiall g3gg0) can help? I have added them to Cc. 

-- 
Best regards,
  Antony Pavlov

Re: [Qemu-devel] QEMU ARM946 emulation, DIGIC, and MPU fault handling

[Georg Hofstetter]

Am 24.01.2014 09:31, schrieb Antony Pavlov:
> On Thu, 23 Jan 2014 22:25:36 +0000
> Peter Maydell <peter.maydell@linaro.org> wrote:
> 
>> Since the 946 doesn't provide any way to find out what the fault
>> address actually was (it has no DFAR or IFAR) I presume that all
>> guest software treats a data abort or prefetch abort as a fatal error,
>> which is probably part of why nobody's ever noticed this.

Hi,

speaking for EOS models: indeed the original manufacturer's OS does not
handle these cases very different. They pick up the context (including
LR, the failing instruction), print an error message and kill the
failing task.

So at least the original OS does not use MPU systematically, like it
would be necessary for some kind of swapping etc.

BR,
Georg