public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: "Kinney, Michael D" <michael.d.kinney@intel.com>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	 "Yao, Jiewen" <jiewen.yao@intel.com>,
	"Ni, Ruiyu" <ruiyu.ni@intel.com>,
	 "Zeng, Star" <star.zeng@intel.com>,
	"Gao, Liming" <liming.gao@intel.com>
Subject: Re: [PATCH] MdeModulePkg/CapsulePei: clean Dcache before consuming capsule data
Date: Wed, 6 Jun 2018 18:13:25 +0200	[thread overview]
Message-ID: <CAKv+Gu-2nVTReZsFhu_Oingn_L80Le_FcoSzXfta-sNDq9rwfg@mail.gmail.com> (raw)
In-Reply-To: <E92EE9817A31E24EB0585FDF735412F5B8A68A4F@ORSMSX113.amr.corp.intel.com>

On 6 June 2018 at 18:07, Kinney, Michael D <michael.d.kinney@intel.com> wrote:
> Ard,
>
> Thanks for adding the note.  I was thinking that this could be done
> just before ResetSystem().  It could also be done in SEC phase.
>
> Since capsules are just one use of warm reset, would it make more sense
> to flush all the caches in either warm reset of SEC instead of just
> the ranges used by capsules.
>

The ARM architecture does not provide for that, unfortunately. The
only architected cache maintenance that guarantees that dirty
cachelines make it all the way to memory (point of coherency or PoC in
ARM parlance) is to clean the caches by virtual address, and cleaning
all of memory by VA is intractible.

The architecture does provide clean by set/way operations, but those
operate on each cache level individually, and only on architected
cache levels. (The architecture permits so-called system caches that
whose set/way maintenance is implementation defined, and only
maintenance by VA is guaranteed to clean the data to main memory)


  reply	other threads:[~2018-06-06 16:13 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-06  9:52 [PATCH] MdeModulePkg/CapsulePei: clean Dcache before consuming capsule data Ard Biesheuvel
2018-06-06 12:09 ` Ard Biesheuvel
2018-06-06 13:59   ` Yao, Jiewen
2018-06-06 16:07   ` Kinney, Michael D
2018-06-06 16:13     ` Ard Biesheuvel [this message]
2018-06-07  1:37   ` Zeng, Star
2018-06-07  4:50     ` Ard Biesheuvel
2018-06-07  5:41       ` Zeng, Star
2018-06-07  6:00         ` Ard Biesheuvel
2018-06-07  9:46           ` Zeng, Star
2018-06-07  9:52             ` Ard Biesheuvel
2018-06-07 10:12               ` Zeng, Star
2018-06-07 10:14                 ` Ard Biesheuvel
2018-06-07 10:27                   ` Zeng, Star
2018-06-07 10:27                     ` Ard Biesheuvel

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-list 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=CAKv+Gu-2nVTReZsFhu_Oingn_L80Le_FcoSzXfta-sNDq9rwfg@mail.gmail.com \
    --to=devel@edk2.groups.io \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox