From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62190 invoked by alias); 19 Apr 2016 13:19:16 -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 62132 invoked by uid 89); 19 Apr 2016 13:19:15 -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,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=absence X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Tue, 19 Apr 2016 13:19:08 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id A1F8CABB2; Tue, 19 Apr 2016 13:19:01 +0000 (UTC) Date: Tue, 19 Apr 2016 13:19:00 -0000 From: Michael Matz To: Andrew Haley cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] [AArch64] support -mfentry feature for arm64 In-Reply-To: <5715E5A9.8060500@redhat.com> Message-ID: References: <1457943260-30894-1-git-send-email-huawei.libin@huawei.com> <5714F001.8090408@redhat.com> <57151699.6020602@redhat.com> <5715E5A9.8060500@redhat.com> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00930.txt.bz2 Hi, On Tue, 19 Apr 2016, Andrew Haley wrote: > > 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. Well, yeah, that's traditional insn caches on multiple cores. From user space you need kernel help for this, doing interprocess interrupts to flush all such buffers on all cores (or at least those potentially fetching stuff in the patched region, if such granularity is possible). An implementation providing such is non-broken :) Alternatively the various invalidate cache instructions need to have a form that invalidates the i$ on all cores. That's just normal code patching on multi-core systems. Nothing specific for aarch64 and nothing the GCC side needs to cater for. > 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. So, this, exactly. Ciao, Michael.