From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:35910)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Alexander.Zuepke@hs-rm.de>) id 1Z4WQu-0005L7-E0
	for qemu-devel@nongnu.org; Mon, 15 Jun 2015 11:36:26 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <Alexander.Zuepke@hs-rm.de>) id 1Z4WQp-0005va-By
	for qemu-devel@nongnu.org; Mon, 15 Jun 2015 11:36:20 -0400
Received: from mxout-1k.itc.hs-rm.de ([195.72.102.133]:44343)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Alexander.Zuepke@hs-rm.de>) id 1Z4WQp-0005tQ-1O
	for qemu-devel@nongnu.org; Mon, 15 Jun 2015 11:36:15 -0400
Message-ID: <557EF0EB.70601@hs-rm.de>
Date: Mon, 15 Jun 2015 17:36:11 +0200
From: =?UTF-8?B?QWxleCBaw7xwa2U=?= <alexander.zuepke@hs-rm.de>
MIME-Version: 1.0
References: <557B0B21.2030009@hs-rm.de>
	<CAFEAcA_yNS1jQugH9e=0_e_TabPZ83TnUPUPtxbRnHGLr5Jv0Q@mail.gmail.com>
	<557EEA46.10507@hs-rm.de>
	<CAFEAcA_djpBm07HgBZ+BuUfgdqDav1ES80zFybBOWjwkwrGqrQ@mail.gmail.com>
In-Reply-To: <CAFEAcA_djpBm07HgBZ+BuUfgdqDav1ES80zFybBOWjwkwrGqrQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] QEMU ARM SMP: IPI delivery delayed until next main
 loop event // how to improve IPI latency?
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>

Am 15.06.2015 um 17:18 schrieb Peter Maydell:
> On 15 June 2015 at 16:07, Alex Z=C3=BCpke <alexander.zuepke@hs-rm.de> w=
rote:
>> Am 15.06.2015 um 17:04 schrieb Peter Maydell:
>>> On 12 June 2015 at 17:38, Alex Z=C3=BCpke <alexander.zuepke@hs-rm.de>=
 wrote:
>>>> Hi,
>>>>
>>>> I'm benchmarking some IPI (=3D=3D inter-processor-interrupt) synchro=
nization stuff of my custom kernel on QEMU ARM (qemu-system-arm -M vexpre=
ss-a15 -smp 2) and ran into the following problem: pending IPIs are delay=
ed until the QEMU main loop receives an event (for example the timer inte=
rrupt expires or I press a key on the console).
>>>>
>>>> The following timing diagram tries to show this:
>>>>
>>>>   CPU #0                       CPU #1
>>>>   =3D=3D=3D=3D=3D=3D                       =3D=3D=3D=3D=3D=3D
>>>>   ... other stuff ...          WFI (wait for interrupt, like x86 "HL=
T")
>>>>   send SGI in MPCore
>>>>   polls for completeness
>>>>                  <time passes ...>
>>>>   polls ...
>>>>                  <... and passes ...>
>>>>   still polls ...
>>>>                  <... and passes ...>
>>>>   still polls ...
>>>>                  <... and passes ...>
>>>>
>>>>
>>>>                  <timer interrupt expires>
>>>>                  <now QEMU switches to CPU #1>
>>>>                                receives IPI
>>>>                                signals completeness
>>>>                                WFI
>>>>                  <QEMU switches to CPU #0>
>>>>   polling done
>>>>   process timer interrupt
>>>>   ...
>>>
>>> Does your polling loop have a YIELD insn in it? We (and hardware)
>>> can use that as a hint that you're busy-looping and we should
>>> try doing something else. (QEMU doesn't implement that for A32/T32
>>> yet, but we should; we already do on A64.)
>>
>> Yes, I should be yielding here, but SEV isn't implemented.
>> Probably the notification should be done there as well.
>=20
> YIELD isn't related to SEV -- it's just a generic "hey, I'm
> polling" hint. We NOP SEV, and make WFE be a "yield this CPU's
> timeslice" event", which is architecturally valid, and sufficient
> for this situation anyway.
>=20
> -- PMM
>=20

Ah, YIELD, thanks for the hint. I never used it because all CPUs I got my=
 hand on were physical ones so far ...


So this is the way to go:

--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -4084,6 +4084,7 @@ static void gen_nop_hint(DisasContext *s, int val)
         gen_set_pc_im(s, s->pc);
         s->is_jmp =3D DISAS_WFI;
         break;
+    case 1: /* yield */
     case 2: /* wfe */
         gen_set_pc_im(s, s->pc);
         s->is_jmp =3D DISAS_WFE;


Thanks
Alex