Re: [Xen-devel] [PATCH] xen/arm64: Use __flush_dcache_area instead of __flush_dcache_all

[Mark Rutland <mark.rutland@xxxxxxx>]

On Tue, Oct 07, 2014 at 10:27:20AM +0100, Ian Campbell wrote:
> On Mon, 2014-10-06 at 17:28 +0100, Mark Rutland wrote:
> > Hi Suravee,
> > 
> > On Mon, Oct 06, 2014 at 04:49:10PM +0100, suravee.suthikulpanit@xxxxxxx 
> > wrote:
> > > From: Suravee Suthikulpanit <Suravee.Suthikulpanit@xxxxxxx>
> > > 
> > > when booting with EFI, __flush_dcache_all does not correctly flush data.
> > > 
> > > According to Mark Rutland, __flush_dcache_all does not guaranteed to push
> > > data to the PoC if there is a system-level cache as it uses Set/Way
> > > operations.
> > 
> > A better way to look at this is that Set/Way operations are never
> > guaranteed to flush data to the PoC, regardless of the presence of a
> > system-level cache. They might on certain implementations, but that's
> > not an architectural guarantee. The same caveat applies to using them to
> > push data to other points in the cache hierarchy (PoUU or PoUIS).
> > 
> > Generally, Set/Way cache maintenance operations can only be used to
> > empty or clean the architected caches visible to a given CPU, and only
> > when all masters sharing those caches have been prevented from
> > allocating any cache entries. Outside of IMPLEMENTATION DEFINED
> > power-down sequences or reset-like operations they are typically the
> > wrong thing to use.
> > 
> > So any other uses of Set/Way operations should also be treated as
> > suspect, and are likely to be problematic on platforms with system-level
> > caches.
> 
> I suppose this set of problematic situations still includes "running
> apparently UP during boot" since we may not be aware of secondary
> processors currently running platform firmware and therefore
> (potentially) interacting with caches?

Yes.

That said, if those CPUs have active cacheable mappings for memory that
is not special reserved and/or secure, you could have issues with
mismatched aliases anyway.

I'd hope that in the FW secondary CPUs were either running without
caches enabled, or only secure mappings if the caches are necessary.

Mark.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel