Am 15.06.2015 um 20:58 schrieb Peter Maydell:
On 15 June 2015 at 16:05, Alex Züpke <alexander.zue...@hs-rm.de> wrote:
Am 15.06.2015 um 16:51 schrieb Peter Maydell:
On 15 June 2015 at 15:44, Alex Züpke <alexander.zue...@hs-rm.de> wrote:
Am 12.06.2015 um 20:03 schrieb Peter Maydell:
Probably the best approach would be to have something in
arm_cpu_set_irq() which says "if we are CPU X and we've
just caused an interrupt to be set for CPU Y, then we
should ourselves yield back to the main loop".
Something like this, maybe, though I have done no more testing
than checking it doesn't actively break kernel booting :-)
Thanks! One more check for "level" is needed to get it work:
What happens without that? It's reasonable to have it,
but extra cpu_exit()s shouldn't cause a problem beyond
being a bit inefficient...
The emulation get's stuck, for whatever reason I don't understand.
I'm beginning to suspect that your guest code has a race
condition in it, such that if the other CPU runs at a
point you weren't expecting it to then you end up
deadlocking or otherwise running into a bug in your guest.
In particular, I see the emulation getting stuck even without
this patch to arm_cpu_set_irq().
-- PMM
Yes, it's a bug, sorry for that. I removed too much code to get a simple
testcase. It's stuck in the first spinlock where CPU#1 is waiting for
CPU#0 to initialize the rest of the system, and I need to WFE or YIELD
here as well.
But this is showing the original problem again: the emulation get's
stuck spinning on CPU #1 forever, because the main loop doesn't switch
to CPU #0 voluntarily. Just press a key on the console/emulated serial
line to trigger an event to QEMU's main loop, and the testcase should
continue.
Best regards
Alex
