From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c06::22c; helo=mail-io0-x22c.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 5E1AE2098EA95 for ; Wed, 6 Jun 2018 09:13:27 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id l25-v6so8218777ioh.12 for ; Wed, 06 Jun 2018 09:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LEhQ9GxBxs1PmxJZD5xCyMVSpw64F7ZoIEJHm4CF95w=; b=Ek6xuBFDB43RV1g2fVaSeT5aoeC1hu40tIAzRuc7Bm68EmPGEJCw6QbGFKXwal169d 73Yr0dl0qtuwkwxvfwwa7gSf1TJRXYC1eVxgfxlKpYOBnoJ+SUjbTWneOewb2VAKm72Z /2zQ9oGoGA6VcCiLlzbgY/UdYHS2u74iFUoxM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LEhQ9GxBxs1PmxJZD5xCyMVSpw64F7ZoIEJHm4CF95w=; b=b4DyRdwxkrLMcTAqt0zjeTm9S0FfyAlwlL3K6TNte07mzAig6sZ7b3K4H1zWooXGfV 0UEpg599PDSslWF/otYLsnTfCEfoP8PQ9BsnQ2vPdtezOGsFqSdyhAoro7YF/pgzZSBb pm45U6eP1H16NZEr8n2t1QosK4In9RbOWL2cxT4+gLhPJnX9obIsh+/cKnyVenyIZhCu a1EQktZEn3Fi/lXkZzm5+cUnUhA/J1ksRfbv4HniqQ0TjailZqhs27nfrop0ON2Ev/kh +Og4JB3CdKby67mC1BZu+eooVpJ5F6x0qVOK+Y1g3QhjPIg4ePcqtZf430C28LRKZjGw V4gg== X-Gm-Message-State: APt69E3PiE5UikYfPYGxCGe8as5y2Fihf7yttV6V5Gx99U0aIaJplBI7 DY0GMnjA8f/SazUQB7k3O6P85dAjAevcSqSxDeKWuw== X-Google-Smtp-Source: ADUXVKLrWLkdRL9egpik7lkXbxNugms4wYIt84wuCDyh38cqqRWT2y8MidN/beWeBm8GbdioU4MEJIb3K6+JxC/zv0Q= X-Received: by 2002:a6b:dd0b:: with SMTP id f11-v6mr3531369ioc.173.1528301606616; Wed, 06 Jun 2018 09:13:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:bb86:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 09:13:25 -0700 (PDT) In-Reply-To: References: <20180606095235.20822-1-ard.biesheuvel@linaro.org> From: Ard Biesheuvel Date: Wed, 6 Jun 2018 18:13:25 +0200 Message-ID: To: "Kinney, Michael D" Cc: "edk2-devel@lists.01.org" , Leif Lindholm , "Yao, Jiewen" , "Ni, Ruiyu" , "Zeng, Star" , "Gao, Liming" Subject: Re: [PATCH] MdeModulePkg/CapsulePei: clean Dcache before consuming capsule data X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 16:13:27 -0000 Content-Type: text/plain; charset="UTF-8" On 6 June 2018 at 18:07, Kinney, Michael D 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)