From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39376) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1ceE-0002Qt-3D for qemu-devel@nongnu.org; Thu, 18 Dec 2014 10:05:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y1ce7-0005zk-Gk for qemu-devel@nongnu.org; Thu, 18 Dec 2014 10:05:50 -0500 Received: from cantor2.suse.de ([195.135.220.15]:36782 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1ce7-0005zO-4x for qemu-devel@nongnu.org; Thu, 18 Dec 2014 10:05:43 -0500 Message-ID: <5492ED45.5040300@suse.de> Date: Thu, 18 Dec 2014 16:05:41 +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> <5492E847.6050701@suse.de> <522D6BCF-C0ED-4ADF-B7CA-7D7787E1238A@greensocs.com> In-Reply-To: <522D6BCF-C0ED-4ADF-B7CA-7D7787E1238A@greensocs.com> 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:51, Mark Burton wrote: >=20 >> On 18 Dec 2014, at 15:44, Alexander Graf wrote: >> >> >> >> On 18.12.14 15:20, Mark Burton wrote: >>> >>> >>>> On 18/12/2014 13:24, Alexander Graf wrote: >>>>> That's the nice thing about transactions - they guarantee that no o= ther >>>>> 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 = "IPI >>>>> others and halt them until we're done with the critical section" >>>>> approach. But I really wouldn't concentrate on making things fast o= n 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 = the >>>> cost of speed) the same semantics on all hosts. >>>> >>>> Paolo >>> >>> I believe what your describing, using transactional memory, or using = softmmu amounts to either option 3 below or option 4. >>> Relying on it totally was option 4.=20 >>> >>> Seems to me, the problem with that option is that support for some ho= sts will be a pain, and covering everything will take some time :-( >>> >>> Option 3 suggests that we build a =E2=80=98slow path=E2=80=99 mechani= sm first - make sure that works (as a backup), and then add optimisations= for 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 wi= th >> 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 ;) >=20 > In other words =E2=80=94 the back-end (slow path) memory interface shou= ld look =E2=80=98transactional=E2=80=99=E2=80=A6? Yeah, the semantics should be tied to what TM would give you. We can always be more safe than TM in our fallback implementation, but I wouldn't want to see semantic optimizations tied to the MMIO implementation put in. This is mostly theory though, try to write the code and see where things fall apart, then we'll be in a much better position to rationalize on where to do things differently. Alex