On 15 June 2015 at 16:05, Alex Züpke <address@hidden> wrote:
Am 15.06.2015 um 16:51 schrieb Peter Maydell:
On 15 June 2015 at 15:44, Alex Züpke <address@hidden> 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