Re: [PATCH 6/7] xen/arm: flush D-cache and I-cache when appropriate

[Tim Deegan <tim@xen.org>]

At 17:05 +0100 on 24 Oct (1351098349), Ian Campbell wrote:
> On Wed, 2012-10-24 at 16:59 +0100, Tim Deegan wrote:
> > > +    asm volatile (
> > > +        "dsb;"
> > > +        STORE_CP32(0, DCCMVAC)
> > > +        "isb;"
> > > +        : : "r" (r0) : "memory");
> > 
> > Does this need a 'memory' clobber?  Can we get away with just saying it
> > consumes *va as an input?  All we need to be sure of is that the
> > particular thing we're flushing has been written out; no need to stop
> > any other optimizations.
> > 
> > I guess it might need to be re-cast as a macro so the compiler knows how
> > big *va is?
> 
> Does it matter that this flushes the cache line containing va, which
> might be larger than whatever type va is?

That depends why you're flushing. :)  From this CPU's PoV the flush
should have no effect at all, so the things to worry about are:

 - the write of the thing we're trying to flush gets moved by the
   compiler so it's after the flush.   That case is handled by using an 
   input memory operand of the right size.
 - something else on the cacheline that's written after the flush gets
   hoisted and written before.  It seems like anything that's relying on
   that (?!) is on very thin ice already and ought to be using (at least)
   explicit memory barriers of its own.

Another interesting case is where we're flushing a large area by
cachelines (like the new loop after relocation), so effectively we don't
know the size of the input operand (a.k.a. 1 cacheline) at compile time.
But there I think a single explicit barrier before the loop isn't too much
to ask.  We could break that and the loop out into a separate function.

Tim.