[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAFYn=yB7v+nRCTy5-WrQ9YU35_HdEVWWUWwbWmOg6udB4=K7PQ@mail.gmail.com>
Date: Tue, 27 Aug 2013 03:34:07 -0400
From: Yaniv Sapir <yaniv@...pteva.com>
To: john-dev@...ts.openwall.com
Subject: Re: Parallella: host-Epiphany communication (was: Katja's
weekly report #6)
On Tue, Aug 20, 2013 at 2:43 PM, Solar Designer <solar@...nwall.com> wrote:
> Yaniv, Katja, Rafael -
>
> On Thu, Jul 25, 2013 at 07:26:03PM -0400, Yaniv Sapir wrote:
> > > Here's a piece of code that will be integrated into the e-hal. It
> should
> > > ensure the completion of a host write transaction (soft ack). The idea
> is
> > > to use a destination address which is in the same endpoint as the
> > > data-write transactions:
> > >
> > > void e_write_ack(unsigned *addr)
> > > {
> > > unsigned probe_data;
> > > probe_data = (*addr); //read old data
> > > probe_data = ~probe_data; //toggle old data
> > > *addr = probe_data; //write new toggled data
> > > while (probe_data != *addr); //keep reading until match is met
> > > }
> >
> > I just realized that this code is for the device side (duh!), not the
> host
> > side. But anyway, it should be straight forward to make the equivalent
> > e-hal version.
>
> I guess the intended use is for this busy loop to be followed with
> setting of another variable to signal completion of computation to the
> other side.
>
The intention is to wait until the last write arrived at its destination.
Assuming the writing of a block of data to a location where all data is
supposed to travel via the same path, polling on the last location is the
way to prevent RAW problems.
> How does this work given the presence of caches and store buffers on
> host side?
>
As far as we could tell from reading the Zynq documentation, our experience
thus far and the verification and study of another friend Parallella user,
the cache is disabled when addressing the non-linux memory space (i.e.,
Epiphany cores and Epiphany External Memory). IOW, those regions are
non-cacheable. As for store buffers, if any exist in these paths, the
question is still open, but again, from our experience, this should not be
a problem.
>
> With writes from Epiphany to host, the host program might read stale
> data from a cache, even after it happened to read an updated completion
> flag. No?
>
Epiphany does not write to the host. At most, it can write to a mailbox in
the DRAM, from which the host reads the information. Given the above
statement, cache does not seem to be a problem.
> With writes from host to Epiphany, the loop above will terminate right
> away, without indicating that the data actually made it through to
> Epiphany, and a subsequent setting of another variable to signal
> completion might arrive out of order. No?
>
> You are assuming caching, which is not applicable here.
Do you possibly disable caching (both L1 and L2?) for the address range
> used for communication with Epiphany? If so, where is this being done?
>
> Upon reset, the caches are disabled. Our assumption is that caching of
Linux memory is enabled by the Linux itself.
> Even if so, the store buffers may break the above approach for host to
> Epiphany communication (this one direction). No? Or are they also
> disabled for writes to non-cached regions?
>
Possibly, but does not seem to be the case.
>
> Perhaps I am missing something. I'd appreciate clarification.
>
> Thanks,
>
> Alexander
>
--
===========================================================
Yaniv Sapir
Adapteva Inc.
1666 Massachusetts Ave, Suite 14
Lexington, MA 02420
Phone: (781)-328-0513 (x104)
Email: yaniv@...pteva.com
Web: www.adapteva.com
============================================================
CONFIDENTIALITY NOTICE: This e-mail may contain information
that is confidential and proprietary to Adapteva, and Adapteva hereby
designates the information in this e-mail as confidential. The information
is
intended only for the use of the individual or entity named above. If you
are
not the intended recipient, you are hereby notified that any disclosure,
copying,
distribution or use of any of the information contained in this
transmission is
strictly prohibited and that you should immediately destroy this e-mail and
its
contents and notify Adapteva.
==============================================================
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
