From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129301 invoked by alias); 19 Apr 2016 08:00:46 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 129267 invoked by uid 89); 19 Apr 2016 08:00:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=fetches, absence X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 19 Apr 2016 08:00:44 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7C94D12B23; Tue, 19 Apr 2016 08:00:43 +0000 (UTC) Received: from zebedee.pink ([10.3.113.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3J80gaQ023227; Tue, 19 Apr 2016 04:00:42 -0400 Subject: Re: [PATCH] [AArch64] support -mfentry feature for arm64 To: Michael Matz References: <1457943260-30894-1-git-send-email-huawei.libin@huawei.com> <5714F001.8090408@redhat.com> <57151699.6020602@redhat.com> From: Andrew Haley Cc: gcc-patches@gcc.gnu.org Message-ID: <5715E5A9.8060500@redhat.com> Date: Tue, 19 Apr 2016 08:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00904.txt.bz2 On 18/04/16 18:34, Michael Matz wrote: > Hi, > > On Mon, 18 Apr 2016, Andrew Haley wrote: > >>>> That may not be safe. Consider an implementation which looks >>>> ahead in the instruction stream and decodes the instructions >>>> speculatively. >>> >>> It should go without saying that patching instructions is followed >>> by whatever means necessary to flush any such caches on a >>> particular implementation (here after patching the jump, after >>> patching the rest, and after patching the first insn again, >>> i.e. three times). >> >> That doesn't necessarily help you, though, without an ISB in the reading >> thread. > > I don't understand, which reading thread? We're writing, not reading > instructions. You mean other executing threads? Yes. > I will happily declare any implementation where it's impossible to > safely patch the instruction stream by flushing the respective > buffers or other means completely under control of the patching > machinery, to be broken by design. You can declare anything you want, but we have to program for the architectural specification. > What failure mode do you envision, exactly? It's easiest just to quote from the spec: How far ahead of the current point of execution instructions are fetched from is IMPLEMENTATION DEFINED. Such prefetching can be either a fixed or a dynamically varying number of instructions, and can follow any or all possible future execution paths. For all types of memory: The PE might have fetched the instructions from memory at any time since the last Context synchronization operation on that PE. Any instructions fetched in this way might be executed multiple times, if this is required by the execution of the program, without being re-fetched from memory. In the absence of an ISB, there is no limit on the number of times such an instruction might be executed without being re-fetched from memory. The ARM architecture does not require the hardware to ensure coherency between instruction caches and memory, even for locations of shared memory. So, if you write a bunch of instructions (which might have been pre-fetched) and then rewrite a NOP to jump to those instructions you need to make sure that the thread which might be running concurrently does an ISB. Note also: Memory accesses caused by instruction fetches are not required to be observed in program order, unless they are separated by an ISB or other context synchronization event. So, if you modify instruction memory in one thread, other threads may see those changes in a different order from the writing thread. Sure, the writing thread executes the cache maintenance instructions on its side, but you also need to do something on the side which is executing the instructions. I have wondered if it might be a good idea to use an inter-processor interrupt to force a context synchronization event across all PEs. Andrew.