public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrew Haley <aph@redhat.com>
To: Michael Matz <matz@suse.de>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] [AArch64] support -mfentry feature for arm64
Date: Tue, 19 Apr 2016 08:00:00 -0000	[thread overview]
Message-ID: <5715E5A9.8060500@redhat.com> (raw)
In-Reply-To: <alpine.LSU.2.20.1604181929170.20277@wotan.suse.de>

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.

  reply	other threads:[~2016-04-19  8:00 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-14  8:13 Li Bin
2016-03-14  8:12 ` Li Bin
2016-04-14 13:08 ` Maxim Kuvyrkov
2016-04-14 13:15   ` Andrew Pinski
2016-04-14 15:58     ` Szabolcs Nagy
2016-04-18 13:26       ` Alexander Monakov
2016-04-18 13:34         ` Ramana Radhakrishnan
2016-04-18 13:44           ` Alexander Monakov
2016-04-18 13:57             ` Ramana Radhakrishnan
2016-04-18 14:03               ` Alexander Monakov
2016-04-18 14:31         ` Szabolcs Nagy
2016-04-18 15:54           ` Alexander Monakov
2016-04-19  6:46             ` AKASHI Takahiro
2016-04-19  6:13       ` AKASHI Takahiro
2016-04-19  6:44         ` Alexander Monakov
2016-04-20  0:33           ` AKASHI Takahiro
2016-04-20 10:02             ` Szabolcs Nagy
2016-04-15 15:40   ` Michael Matz
2016-04-15 17:29     ` Alexander Monakov
2016-04-17 15:06       ` Alexander Monakov
2016-04-18 12:12         ` Michael Matz
2016-04-19  6:26           ` AKASHI Takahiro
2016-04-19  6:39             ` Alexander Monakov
2016-04-20  1:23               ` AKASHI Takahiro
2016-04-20 16:45                 ` Szabolcs Nagy
2016-04-19 16:03           ` Torsten Duwe
2016-04-18 14:32       ` Andrew Haley
2016-04-18 17:13         ` Michael Matz
2016-04-18 17:17           ` Andrew Haley
2016-04-18 17:34             ` Michael Matz
2016-04-19  8:00               ` Andrew Haley [this message]
2016-04-19 13:19                 ` Michael Matz
2016-04-19 13:25                   ` Andrew Haley
2016-04-19 14:38                     ` Pedro Alves
2016-04-19 15:02                       ` Andrew Haley
2016-04-19  6:08   ` AKASHI Takahiro
  -- strict thread matches above, loose matches on Subject: below --
2015-10-22 13:24 Li Bin
2015-10-22 13:53 ` Marcus Shawcroft

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5715E5A9.8060500@redhat.com \
    --to=aph@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=matz@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).