All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: "julien.grall@linaro.org" <julien.grall@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"roy.franz@linaro.org" <roy.franz@linaro.org>,
	"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
	"stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>
Subject: Re: [PATCH] xen/arm64: Use __flush_dcache_area instead of __flush_dcache_all
Date: Tue, 7 Oct 2014 10:27:20 +0100	[thread overview]
Message-ID: <1412674040.4972.14.camel@citrix.com> (raw)
In-Reply-To: <20141006162828.GA22575@leverpostej>

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@amd.com wrote:
> > From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> > 
> > 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?

Ian.

  parent reply	other threads:[~2014-10-07  9:27 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-06 15:49 [PATCH] xen/arm64: Use __flush_dcache_area instead of __flush_dcache_all suravee.suthikulpanit
2014-10-06 16:28 ` Mark Rutland
2014-10-07  4:15   ` Roy Franz
2014-10-07  9:32     ` Ian Campbell
2014-10-07 10:40     ` Mark Rutland
2014-10-14  3:48       ` Roy Franz
2014-10-14  9:21         ` Mark Rutland
2014-10-14  9:35           ` Ian Campbell
2014-10-14 10:32             ` Mark Rutland
2014-10-14 10:39               ` Ian Campbell
2014-10-14 11:23                 ` Mark Rutland
2014-10-14 12:54                   ` Ian Campbell
2014-10-14 14:30                     ` Mark Rutland
2014-10-14 16:26                       ` Roy Franz
2014-10-14 17:07                         ` Mark Rutland
2014-10-14 17:19                           ` Roy Franz
2014-10-15  8:02                           ` Ian Campbell
2014-10-15 15:02                           ` Stefano Stabellini
2014-10-07  9:27   ` Ian Campbell [this message]
2014-10-07 10:52     ` Mark Rutland
  -- strict thread matches above, loose matches on Subject: below --
2014-10-21  3:55 Roy Franz
2014-10-21  3:57 ` Roy Franz
2014-10-21  8:17 ` Ian Campbell

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=1412674040.4972.14.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=julien.grall@linaro.org \
    --cc=mark.rutland@arm.com \
    --cc=roy.franz@linaro.org \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=xen-devel@lists.xen.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.