From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47010) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLvYX-0008U7-OX for qemu-devel@nongnu.org; Thu, 12 Feb 2015 10:19:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YLvYU-0002sA-9d for qemu-devel@nongnu.org; Thu, 12 Feb 2015 10:19:53 -0500 Received: from cantor2.suse.de ([195.135.220.15]:40722 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLvYU-0002rk-49 for qemu-devel@nongnu.org; Thu, 12 Feb 2015 10:19:50 -0500 Message-ID: <54DCC494.2010400@suse.de> Date: Thu, 12 Feb 2015 16:19:48 +0100 From: Alexander Graf MIME-Version: 1.0 References: <31B94C07-29A9-4595-95ED-FA860B527BD8@suse.de> <45883806-2296-486F-A0DC-D8A0A74F85B9@greensocs.com> In-Reply-To: <45883806-2296-486F-A0DC-D8A0A74F85B9@greensocs.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Help on TLB Flush List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark Burton , Peter Maydell Cc: mttcg@listserver.greensocs.com, qemu-devel On 12.02.15 16:08, Mark Burton wrote: >=20 >> On 12 Feb 2015, at 16:01, Peter Maydell wro= te: >> >> On 12 February 2015 at 14:45, Alexander Graf wrote: >>> >>>> On 12.02.2015, at 15:35, Mark Burton wro= te: >>>> We are proposing to implement this by signalling all other CPU=E2=80= =99s >>>> to exit (and requesting they flush before re-starting). In other >>>> words, this would happen asynchronously. >>> >>> For global flushes, give them a pointer payload along with the flush >>> request and tell all cpus to increment it atomically. In your main >>> thread, wait until *ptr =3D=3D nKickedCpus. >> >> I bet this will not be the only situation where you want to >> do an "get all other CPUs to do $something and wait til they >> have done so" kind of operation, so some lightweight but generic >> infrastructure for doing that would not be a bad plan. (Similarly >> "get all other CPUs to stop, then I can do $something and let >> the others continue=E2=80=9D.) >=20 > We tried this - we ended up in knots. > We had 2 CPU=E2=80=99s trying to flush at about the same time, both wai= ting for the other. > We had CPU=E2=80=99s trying to get the global mutex to finish what they= were doing, while being told to flush,=20 > We had CPU=E2=80=99s in the global mutex trying to do something that wo= uld cause a flush=E2=80=A6 etc.... > We had spaghetti with extra Bolognese sauce=E2=80=A6 >=20 > We eventually concluded, yes - in an infinite universe everything is po= ssible, but if we could simply do this =E2=80=98asynchronously=E2=80=99 t= hen our lives would be a LOT easier. > e.g. - ask all CPU=E2=80=99s to =E2=80=9Cexit and do something=E2=80=9D= is easy - wait for them to do that is a whole other problem=E2=80=A6 >=20 > Our question is - do we need this =E2=80=98sync=E2=80=99 (before the fl= ush), or can we actually allow CPU=E2=80=99s to flush themselves asynchro= nously=E2=80=A6. The respective target architecture specs will tell you. And I very much doubt that it is ok in most cases. Alex