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:c0b::242; helo=mail-it0-x242.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (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 1E377210E3DCD for ; Mon, 11 Jun 2018 15:01:06 -0700 (PDT) Received: by mail-it0-x242.google.com with SMTP id u4-v6so12281616itg.0 for ; Mon, 11 Jun 2018 15:01:06 -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=oz3tCFzFIlUvQwPVRqN/JAhcM1MjIWfA/m+0LKJ9Gog=; b=a9zJn+asguHjO30ZcA5MKEqmLzMWC4iyzYaJKB0d18ReK6wkCdnC775Q7jQakcEGeK eO6sLqXgr95ibAnvJUzl3cWLN8Zxw9JRx0uJzbzVZVLCOkc8ibOrGwfryJqg3GFI5mre UbVXr+91mt+OAOKYbdewwiNBNPDM7GkPaeFq0= 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=oz3tCFzFIlUvQwPVRqN/JAhcM1MjIWfA/m+0LKJ9Gog=; b=fKHcDvK4BjDcyjkZOhhQ3NgXFIiKYkgxBg7HwsVpRnEH3ofbxX92NQQda6SZOARiQQ 2xCHQxHiMnczS4ROL6h6DlCSo0Mv+Mq5WOMbapqRCsFC1LS4Ix4e2MxRsiauoFcoxzd4 8kMyO6XofqIfOYqK/OCKs91GRtBt2JZ8qq2rTbEPBdqUg48dx8ZKjADvLrzk/gQ1sME8 NjeM2IvEipZshe7HGcBeKWwBRm6Bu6vpdnV6wSOrzpg0atGtOtJ2gvHPXyJ7g9R3woVL w6brVhf/p0t9PNFSJJwvFEh72CAYdzSewJrh8+QpudQpvi7Fww30Ld+8OsCNlsJ6KL1Z anuw== X-Gm-Message-State: APt69E3h/a9p+j7jiYrnB7BOk2tiRZeZysQ1soWdOt4Yw0GC2XGQ1kJT NvF3K9XbgIuBBHRWTk1XgzFLd3VRc+shXCBeSiis4MQgvuc= X-Google-Smtp-Source: ADUXVKKg/jOIBwvLdzMCSmMNerllVvW0YlRlDMBmMyce/05nVnuF7EHUDCdt8Bu7ZazgLQo3z8wvc0kWm83k16Rgw4A= X-Received: by 2002:a24:1d0e:: with SMTP id 14-v6mr785056itj.50.1528754466278; Mon, 11 Jun 2018 15:01:06 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:bbc7:0:0:0:0:0 with HTTP; Mon, 11 Jun 2018 15:01:05 -0700 (PDT) In-Reply-To: References: <20180608065811.2065-1-ard.biesheuvel@linaro.org> <20180608065811.2065-2-ard.biesheuvel@linaro.org> <74D8A39837DF1E4DA445A8C0B3885C503AC3DA25@shsmsx102.ccr.corp.intel.com> From: Ard Biesheuvel Date: Tue, 12 Jun 2018 00:01:05 +0200 Message-ID: To: "Kinney, Michael D" Cc: "Yao, Jiewen" , "edk2-devel@lists.01.org" , Leif Lindholm , "Zeng, Star" Subject: Re: [PATCH v2 1/5] 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: Mon, 11 Jun 2018 22:01:08 -0000 Content-Type: text/plain; charset="UTF-8" On 11 June 2018 at 23:40, Kinney, Michael D wrote: > Hi Ard, > > I would still prefer the cache maintenance be done independent > of capsules in case there is other memory ranges that need to > be flushed for other features. > > The CacheMaintenanceLib for ARM has several services that are > not implemented and ASSERT(). I found some ARM documentation > that says that caches can be flushed by looping through the > indexes. > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0201d/ch03s03s05.html > Please don't quote severely outdated documentation out of context. ARM9 is a ~15 year old core that predates SMP on ARM by several years. > implementations that may not work with that algorithm. However > that could require a customized CacheMaintenanceLib. Can you > provide the flush all using the documented algorithm and use that > instance for systems that are compatible with the documented algorithm. None of the ARM cores we support in EDK2 today (ARMv7 and later) are compatible with the documented algorithm. > Then, the flush all API can be used in ResetSystem() or SEC Phase > when the boot mode is warm reset. > Flushing the entire cache is simply not possible. The set/way operations are only intended to be used before the core enters the coherency domain or after it leaves it again (i.e., when cores are powered up or down). Those set/way operations are not broadcast to other cores (or other masters such as DMA capable peripherals with caches), which means that a cache line that is cleaned by set/way may simply end up in another cache and never make it to main memory. In other words, set/way operations manage the cache itself rather than the contents of the caches. The only way to perform cache maintenance in a way to ensure that the *content* makes it to main memory is to use cache maintenance by virtual address. This requires that you know the virtual address to begin with, and obviously requires that a mapping exists for that virtual address when executed with the MMU on. The bottom line is that there is no flush all API, and we will have to work around that (and believe me, this is not the first time we are struggling to deal with this limitation). So to summarize again, we have the following options, - UpdateCapsule - problematic because it may be called at runtime and the firmware has no means of translating the physical addresses - ResetSystem - same as above: it is a runtime service, and so it cannot rely on a mapping to exist for those physical addresses - SEC - lacks the information about where the capsule resides - CapsulePei - already extracts the information about the capsule address in memory, and can perform the cache maintenance right before consuming the data.