Re: [Qemu-devel] QEMU ARM SMP: IPI delivery delayed until next main loop event // how to improve IPI latency?

[Alex Zuepke <alexander.zuepke@hs-rm.de>]

Am 15.06.2015 um 20:58 schrieb Peter Maydell:
> On 15 June 2015 at 16:05, Alex Züpke <alexander.zuepke@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.zuepke@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