[Qemu-devel] Cortex-M3: reading NVIC registers causes segfaults

[Qemu-devel] Cortex-M3: reading NVIC registers causes segfaults

[Andreas Galauner]

Hi qemu developers,

I'm currently trying to emulate an ARM Cortex-M3 and I need to debug the
system using GDB and IDA Pro. The platform is an STM32 and I'm using a
port from github [1] based on qemu 1.5.1 for that. I ported the custom
STM32 code to qemu 1.7.0 to have a more recent version to work with.

During a debug session, I'm experiencing segfaults in armv7m_nvic.c when
reading the CPUID and Vector base registers (lines 176 and 212), because
ARM_CPU(current_cpu) returns a NULL-pointer. IDA seems to do that quite
regularly. Debugging with GDB works until you try to read the mentioned
registers by hand like this:

> (gdb) target remote :1234
> Remote debugging using :1234
> 0x08005d1c in ?? ()
> (gdb) x/x *0xE000ED00
> Remote connection closed

The original STM32-port was based on qemu 1.5.1 and the behaviour was
the same. That was the reason why I ported all that stuff over to 1.7.0
which unfortunately didn't solve the problem.

Is this a known bug?
Any hints on how I could possibly solve that problem?

- Andy

[1]: https://github.com/beckus/qemu_stm32

Re: [Qemu-devel] Cortex-M3: reading NVIC registers causes segfaults

[Peter Maydell]

On 17 February 2014 14:52, Andreas Galauner <andreas@galauner.de> wrote:
> I'm currently trying to emulate an ARM Cortex-M3 and I need to debug the
> system using GDB and IDA Pro. The platform is an STM32 and I'm using a
> port from github [1] based on qemu 1.5.1 for that. I ported the custom
> STM32 code to qemu 1.7.0 to have a more recent version to work with.
>
> During a debug session, I'm experiencing segfaults in armv7m_nvic.c when
> reading the CPUID and Vector base registers (lines 176 and 212), because
> ARM_CPU(current_cpu) returns a NULL-pointer. IDA seems to do that quite
> regularly. Debugging with GDB works until you try to read the mentioned
> registers by hand like this:
>
>> (gdb) target remote :1234
>> Remote debugging using :1234
>> 0x08005d1c in ?? ()
>> (gdb) x/x *0xE000ED00
>> Remote connection closed
>
> The original STM32-port was based on qemu 1.5.1 and the behaviour was
> the same. That was the reason why I ported all that stuff over to 1.7.0
> which unfortunately didn't solve the problem.

I don't think I would expect trying to read and write device
registers over the gdbstub to work properly -- gdb kind of
assumes it's talking to memory, which doesn't have side
effects the way devices do.

The crash you're running into is caused by the device code assuming
that it's only ever accessed by a CPU, not by some other thing like
a debugger or DMA access. For the NVIC code in armv7m_nvic.c we
know that a v7M CPU has only one core, so you should just be able
to replace the uses of "current_cpu" with "first_cpu". Other
places which use current_cpu (such as the GIC proper) might be
shared with configurations which do have multiple cores and so
really do need current_cpu.

thanks
-- PMM

Re: [Qemu-devel] Cortex-M3: reading NVIC registers causes segfaults

[Andreas Färber]

Am 17.02.2014 16:18, schrieb Peter Maydell:
> On 17 February 2014 14:52, Andreas Galauner <andreas@galauner.de> wrote:
>> I'm currently trying to emulate an ARM Cortex-M3 and I need to debug the
>> system using GDB and IDA Pro. The platform is an STM32 and I'm using a
>> port from github [1] based on qemu 1.5.1 for that. I ported the custom
>> STM32 code to qemu 1.7.0 to have a more recent version to work with.
>>
>> During a debug session, I'm experiencing segfaults in armv7m_nvic.c when
>> reading the CPUID and Vector base registers (lines 176 and 212), because
>> ARM_CPU(current_cpu) returns a NULL-pointer. IDA seems to do that quite
>> regularly. Debugging with GDB works until you try to read the mentioned
>> registers by hand like this:
>>
>>> (gdb) target remote :1234
>>> Remote debugging using :1234
>>> 0x08005d1c in ?? ()
>>> (gdb) x/x *0xE000ED00
>>> Remote connection closed
[...]
> The crash you're running into is caused by the device code assuming
> that it's only ever accessed by a CPU, not by some other thing like
> a debugger or DMA access. For the NVIC code in armv7m_nvic.c we
> know that a v7M CPU has only one core, so you should just be able
> to replace the uses of "current_cpu" with "first_cpu". Other
> places which use current_cpu (such as the GIC proper) might be
> shared with configurations which do have multiple cores and so
> really do need current_cpu.

While first_cpu may help Andreas in his local copy for STM32, that
assumption is not okay in general. The Vybrid VF6 has both a GIC and an
NVIC, so our NVIC code should not make assumptions which CPU it can
access. I assume we would shield both using CPU address spaces, but I
wonder if either of you two has already thought about how those will
interact for gdbstub?

I remember there being two CPU variables in gdbstub, maybe Andreas can
use them to temporarily set current_cpu?

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] Cortex-M3: reading NVIC registers causes segfaults

[Peter Maydell]

On 18 February 2014 01:14, Andreas Färber <afaerber@suse.de> wrote:
> While first_cpu may help Andreas in his local copy for STM32, that
> assumption is not okay in general. The Vybrid VF6 has both a GIC and an
> NVIC, so our NVIC code should not make assumptions which CPU it can
> access.

Do you mean it has an M core CPU with an NVIC plus some other
A-class CPU with a GIC. Certainly in a system with heterogenous
CPUs this change won't work, but we don't support that at all
currently and there's a lot of work between here and there.

> I assume we would shield both using CPU address spaces

The GIC needs to know which CPU it's being accessed by.
I guess in theory you could have it export N distributor memory
regions which were identical apart from making "I assume I'm
being accessed by CPU X" assumptions, but that seems like a
bit of a kludge. Ideally we should have some way for the target
of a memory transaction to get at information about the source
(ie all the out of band info that hardware sends like master ID,
privilege level, secure vs nonsecure, etc).

> but I
> wonder if either of you two has already thought about how those will
> interact for gdbstub?

I'd need to look at the protocol to figure out if gdbstub does
memory accesses in the context of a particular thread (CPU
for us) or not. If not, that could be awkward.

thanks
-- PMM