ARM64: threads, interrupts and WFI

[pewterbrass]

Running some firmware on the latest commit to the dev branch, I'm encountering a situation I'm not sure how to resolve.

The firmware runs in AARCH64 mode and uses threading, as well as the GIC block to listen for peripheral interrupts. I'm well aware that Unicorn is CPU emulator and am prepared to implement my own interrupt handling.

The thing I'm confused about is how to handle when the main thread stops to wait for an interrupt and switches context to the next scheduled thread.

Since there are no other threads wanting to run at the moment, execution goes to the idle thread.

The idle thread, which hasn't gotten any cpu time so far, does some initialization, but then eventually goes into a tight loop calling the WFI instruction.

Basically, there is nothing that wants to run and I assume it's because of this that emu_start just returns.

Just calling emu_start again will cause the same thread to run WFI again with the same result as before.

Does anyone know how to handle this?

Ideally I'd want to raise the interrupt that the main thread is waiting for and get the scheduler to switch context to this thread instead of the idle thread.

Do I need to manually do the context switch before calling emu_start again? I'm uncertain what actually happens in the ARM64 core when WFI is called on a thread.

I'm looking for the simplest solution that will work in a generic case.

For instance, I don't want to have to parse the firmware specific thread block data, but solve this using CPU and peripheral primitives (GIC, Timer, etc)

[wtdcode]

Generally, you can emulate this in a polling behavior. See our FAQ.

[pewterbrass]

I finally managed to get it right, but it did require a lot of manual work that was ripped out with the GIC.

in particular, I feel that it would have been good if exception handling wouldn’t have been ripped out of the ARM core. It’s such an integral part of most ARM firmware that you have to have it to emulate anything but the simplest binaries.