Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Aug 2013 22:43:17 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Parallella: host-Epiphany communication (was: Katja's weekly report #6)

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.

How does this work given the presence of caches and store buffers on
host side?

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?

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?

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?

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?

Perhaps I am missing something.  I'd appreciate clarification.

Thanks,

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ