From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59019) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhO8Y-0001Qv-LH for qemu-devel@nongnu.org; Wed, 30 Sep 2015 16:38:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhO8U-0003Oc-1w for qemu-devel@nongnu.org; Wed, 30 Sep 2015 16:38:02 -0400 Received: from mail-pa0-x22d.google.com ([2607:f8b0:400e:c03::22d]:35625) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhO8T-0003OT-Tm for qemu-devel@nongnu.org; Wed, 30 Sep 2015 16:37:58 -0400 Received: by pacfv12 with SMTP id fv12so51618186pac.2 for ; Wed, 30 Sep 2015 13:37:57 -0700 (PDT) Sender: Richard Henderson References: <1443083566-10994-1-git-send-email-a.rigo@virtualopensystems.com> <1443083566-10994-3-git-send-email-a.rigo@virtualopensystems.com> <560B585D.6010103@twiddle.net> From: Richard Henderson Message-ID: <560C4819.7050105@twiddle.net> Date: Thu, 1 Oct 2015 06:37:45 +1000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v5 2/6] softmmu: Add new TLB_EXCL flag List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: alvise rigo , Peter Maydell Cc: mttcg@greensocs.com, Claudio Fontana , QEMU Developers , Paolo Bonzini , Jani Kokkonen , VirtualOpenSystems Technical Team , =?UTF-8?Q?Alex_Benn=c3=a9e?= On 09/30/2015 10:44 PM, alvise rigo wrote: > On Wed, Sep 30, 2015 at 1:09 PM, Peter Maydell wrote: >> On 30 September 2015 at 10:24, alvise rigo >> wrote: >>> On Wed, Sep 30, 2015 at 5:34 AM, Richard Henderson wrote: >>>> (1) I don't see why EXCL support should differ whether MMIO is set or not. >>>> Either we support exclusive accesses on memory-mapped io like we do on ram >>>> (in which case this is wrong) or we don't (in which case this is >>>> unnecessary). >>> >>> I was not sure whether or not we had to support also MMIO memory. >>> In theory there shouldn't be any issues for including also >>> memory-mapped io, I will consider this for the next version. >> >> Worth considering the interaction between exclusives and other >> cases for which we force the slowpath, notably watchpoints. >> >>>> AFAIK, Alpha is the only target we have which specifies that any normal >>>> memory access during a ll+sc sequence may fail the sc. >>> >>> I will dig into it because I remember that the Alpha architecture >>> behaves like ARM in the handling of LDxL/STxC instructions. >> >> ARM semantics are that a non-exclusive store by this CPU between >> a ldrex and a strex might result in loss of the (local) monitor, >> but non-exclusive loads by this CPU won't. (It's an IMPDEF >> choice.) > > Indeed, what is implemented by this patch series is one of the > permissible choices - very close to the one implemented by the current > TCG - that could match all the other architectures with similar > semantics Except for the case I pointed out -- where a ldr to a page that conflicts with the ldrex in the tlb will result in the replacement of the tlb entry, and thus you'll see the outgoing tlb entry has TLB_EXCL set and set the dirty bit (i.e. clear the lock bit) on the ldrex page. I.e. this is a case that *must* pass on arm, but your implementation won't. > (now I'm not sure about Alpha). Alpha is trivial, as always. Those guys wrote the spec such that anything hard isn't guaranteed to work, but also isn't guaranteed to fail. The rule is: no memory accesses of any kind, lest the lock flag be lost. In practice, it's a test of the MESI state of the cacheline. Which, I assume is what most other targets use. > Like having some per-architecture functions that, for each LoadLink, > set the size of the exclusive memory region to be protected We probably do need that; I sort of assumed that simply be part of the implementation on the instruction side, not done as a side-effect of the actual load. > and decide whether a normal store/load will make one CPU's SC fail. There's likely no need to do this. And certainly I don't think we should do it right away. r~