From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34672) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1cJd-0000Aq-Vo for qemu-devel@nongnu.org; Thu, 18 Dec 2014 09:44:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y1cJW-0004AL-Fq for qemu-devel@nongnu.org; Thu, 18 Dec 2014 09:44:33 -0500 Received: from cantor2.suse.de ([195.135.220.15]:36210 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1cJW-00049y-7l for qemu-devel@nongnu.org; Thu, 18 Dec 2014 09:44:26 -0500 Message-ID: <5492E847.6050701@suse.de> Date: Thu, 18 Dec 2014 15:44:23 +0100 From: Alexander Graf MIME-Version: 1.0 References: <1418721234-9588-1-git-send-email-fred.konrad@greensocs.com> <54915A76.3000408@greensocs.com> <54915AE8.3010809@suse.de> <54915EC6.2050708@suse.de> <8B6B4BF9-3400-4125-8571-F4EF9F12AA89@greensocs.com> <5491666A.7060001@suse.de> <54916829.3020200@redhat.com> <60A11491-8466-4EBC-9877-22E341688DD9@greensocs.com> <6B541656-15EA-47CB-8043-AE3B18FC60D4@greensocs.com> <5492C798.8070503@suse.de> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH] target-arm: protect cpu_exclusive_*. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark Burton Cc: mttcg@listserver.greensocs.com, Peter Maydell , QEMU Developers , Paolo Bonzini , =?UTF-8?B?TGx1w61zIFZpbGFub3Zh?= , =?UTF-8?B?S09OUkFEIEZyw6lkw6lyaWM=?= On 18.12.14 15:20, Mark Burton wrote: >=20 >=20 >> On 18/12/2014 13:24, Alexander Graf wrote: >>> That's the nice thing about transactions - they guarantee that no oth= er >>> CPU accesses the same cache line at the same time. So you're safe >>> against other vcpus even without blocking them manually. >>> >>> For the non-transactional implementation we probably would need an "I= PI >>> others and halt them until we're done with the critical section" >>> approach. But I really wouldn't concentrate on making things fast on = old >>> CPUs. >> >> The non-transactional implementation can use softmmu to trap access to >> the page from other VCPUs. This makes it possible to implement (at th= e >> cost of speed) the same semantics on all hosts. >> >> Paolo >=20 > I believe what your describing, using transactional memory, or using so= ftmmu amounts to either option 3 below or option 4. > Relying on it totally was option 4.=20 >=20 > Seems to me, the problem with that option is that support for some host= s will be a pain, and covering everything will take some time :-( >=20 > Option 3 suggests that we build a =E2=80=98slow path=E2=80=99 mechanism= first - make sure that works (as a backup), and then add optimisations f= or specific hosts/guests afterwards. To me that still seems preferable? Yes, the only thing I'm in favor for here is to align the semantics with what transactional memory would give you. That way moving to the fast implementation will be easy and people would actually want to use multi-threaded TCG ;) Alex