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::242; helo=mail-io0-x242.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::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 56E07211DE900 for ; Tue, 12 Jun 2018 03:31:41 -0700 (PDT) Received: by mail-io0-x242.google.com with SMTP id u4-v6so27451316iof.2 for ; Tue, 12 Jun 2018 03:31:41 -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=PUic2eSQSAYsZXiA0qCyxgkiWpXUzLq5tq9gcQE23bk=; b=EzXlTrcL3ldp59ClGE2Gb5tfztyAtNf/WZH/1Kg0nfVO9zcT5rQPwYDfqYUxhWZCNA jWkzABEc74Ql5uledQL2KYF2Ld+9tMPLeT6oWgWPMu3EZULGWyK0TjFLwYR3XcKA5uNr Uisp4CzA0f05AMzK562jWC58OZqJc2v8aaSFI= 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=PUic2eSQSAYsZXiA0qCyxgkiWpXUzLq5tq9gcQE23bk=; b=lveLgibmRa5671/X/EudKbp2tmUiBIyhJcXk3dC2CNKjiM08UU0Wr0xRPcUG8wc+nQ cDQsmcCTpP2nWTjhLqJGdKsv4DyKrnVJw0+RxuFxoybMk/dG23Dg+suw95G87S9G7sGn eCSFOfgqArWNUDz5hKCf6/wuE4j0qc50YWRYGxPJxERymj7JOql4oJdg9Sjx3rUXgbI7 Ja4aEfBXmyX8abGf2oYoHGj5QhqU0SXWNKk8nBLuGFRl3E5VN0AFODQktRh36o86wATf 8fuUzU3lM5SGFEVNDQ+jB7k4RShIiozRcPRNkpkJI819Tma2rv4W8rc3Fz238d/jJMyF JXSg== X-Gm-Message-State: APt69E3mPHLt5NgjQSKjFY2NCfeuZNmtR0UDtnMF/AKytxOKwhEfr3qq sJcHbH1ip26KvtqApwLOW34sKyphsQ4WY4spycxHSw== X-Google-Smtp-Source: ADUXVKJWkiRZanV17gfvkydqKKeTGYWOhZWDGawz6kLBRFizO/9CLv1HL+QkWXbZvTPHmf+gdR74Q19mlNXaLQsEdM4= X-Received: by 2002:a6b:6709:: with SMTP id b9-v6mr2664199ioc.170.1528799500559; Tue, 12 Jun 2018 03:31:40 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:bbc7:0:0:0:0:0 with HTTP; Tue, 12 Jun 2018 03:31:39 -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 12:31:39 +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: Tue, 12 Jun 2018 10:31:41 -0000 Content-Type: text/plain; charset="UTF-8" On 12 June 2018 at 11:01, Ard Biesheuvel wrote: > On 12 June 2018 at 02:54, Kinney, Michael D wrote: >> Ard, >> >> What about memory init when the memory HOBs are >> created. Could you flush all the ranges of >> initialized memory by HOB as the HOBs are created? >> >> PEI and DXE can not use memory not described by >> the HOBs. More memory can be added in DXE phase >> through the GCD services, and additional flush >> could be done as added. >> > > CapsuleCoalesce() goes and finds the capsule data wherever it was left > in memory by the OS. This is independent of what the HOBs may describe > or which memory was added at which point. > As it turns out, relying on the state of the caches to be preserved across a reboot and cleaning them afterwards is something that cannot be architecturally guaranteed either. So I will withdraw this patch, and propose another approach that cleans the capsule during the call to UpdateCapsule(). For the time being, that only works at boot time, but given that both Windows and Linux perform capsule updates before ExitBootServices(), this is something we should be able to live with. > >>> -----Original Message----- >>> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] >>> Sent: Monday, June 11, 2018 3:01 PM >>> 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 >>> >>> 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.