From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) by mx.groups.io with SMTP id smtpd.web12.31246.1643631740732285593 for ; Mon, 31 Jan 2022 04:22:21 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@nuviainc-com.20210112.gappssmtp.com header.s=20210112 header.b=Lbtva5jE; spf=pass (domain: nuviainc.com, ip: 209.85.221.48, mailfrom: leif@nuviainc.com) Received: by mail-wr1-f48.google.com with SMTP id a13so25052933wrh.9 for ; Mon, 31 Jan 2022 04:22:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuviainc-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Ak+qa69qXh/lz6fM8ufaNbTad7SQ0HxOTF7HEf4K4oM=; b=Lbtva5jEd6BxgUoYlRRBLZwZUHjyhc+lWrF6vA+z7T2caFuMUuqQi0UTdRXvofpcxE kN91cSa3kYttg+99edOMj6M/UQ8eEKdpl0ZzpKaS2J6fHsFzvrNVKwPviOjAticFKxn/ bRLpLxymmbXHXVucgq2fIto2wqTOGDG6fis98/VQnWCqH8b2UZ1zKjnZo9Csp92CPveb frC1qU5KBM03GKaYEREwd3HXWRu/EU/afkiaOmkdxGvHcix7WAk3i7zL/esJK1JH1DA+ md6mWfPqBSn1QMENX0D+A0c+wSz5cFHnomX4QDkdgEpqWvcn0YJXQcOM/k2WvvqHpsg+ KPpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Ak+qa69qXh/lz6fM8ufaNbTad7SQ0HxOTF7HEf4K4oM=; b=tGpAelESDMtT+0e/Atx9qpgbaihDIrKcbfu44bn8DjyzoggHobKImKAcgsBrfADBRE xC9HuOkP7DMr5VMF/uPX5VeYJ3NNxa2gLrC3zgQYGhkKJxIUvYKZrK4Fnldpe+8wSwur WRbvoCS9OuAbQy+rH4Q3DUwJHd5tOJCMkPQsxw82UCH9+dVbJpuOBWQfgcJ5A/TmvkQ2 CG4k9ZOOTy02lzDhZQIT+cxkFIZJsl1gs4otXkIs/loSFxZQKdGxmAiKFLjc8xKVE2Yk 1RVGCpmzkB6Kq/6yMjr7WaixaT1B5WNa4WL5kyKVWwVyDqzyqhO5xPUWGYwAAORvKY1C iBzg== X-Gm-Message-State: AOAM531r3XE391R6B8yYHfhA73TOH4Af6SUuT5O/cVAAgauBs2wZcC2i Wcyo0e0R/KNSakLLqUhRoIHwVg== X-Google-Smtp-Source: ABdhPJx2aN/A+XrcDg6gZXn9hUGsB742rLHqOHQKDy1O4LRFEOLk4i7i+O2WILVozPsZxmT+wpqBMw== X-Received: by 2002:a05:6000:186b:: with SMTP id d11mr17526902wri.21.1643631739305; Mon, 31 Jan 2022 04:22:19 -0800 (PST) Return-Path: Received: from leviathan (cpc92314-cmbg19-2-0-cust559.5-4.cable.virginm.net. [82.11.186.48]) by smtp.gmail.com with ESMTPSA id n10sm14395084wrf.96.2022.01.31.04.22.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 31 Jan 2022 04:22:18 -0800 (PST) Date: Mon, 31 Jan 2022 12:22:17 +0000 From: "Leif Lindholm" To: Ard Biesheuvel Cc: devel@edk2.groups.io, sami.mujawar@arm.com, Alexander Graf Subject: Re: [PATCH] ArmVirtPkg/ArmVirtMemoryInitPeiLib: avoid redundant cache invalidation Message-ID: References: <20220129151346.4120964-1-ardb@kernel.org> MIME-Version: 1.0 In-Reply-To: <20220129151346.4120964-1-ardb@kernel.org> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Jan 29, 2022 at 16:13:46 +0100, Ard Biesheuvel wrote: > Alex reports that the cache invalidation performed by > ArmVirtMemoryInitPeiLib takes a non-negligible amount of time at boot. > This cache invalidation used to be necessary to avoid inconsistencies > between the CPU's cached and uncached views of the permanent PEI memory > region, given that the PEI phase is where the MMU gets enabled. > > The only allocations done from permanent PEI memory with the MMU off are > pages used for page tables, and since commit 748fea6279ef > ("ArmPkg/ArmMmuLib AARCH64: invalidate page tables before populating > them"), each of those is invalidated in the caches explicitly, for > reasons described in the patch's commit log. All other allocations done > in PEI are either from temporary PEI memory, which includes the stack, > or from permanent PEI memory but after the MMU has been enabled. > > This means that the cache invalidation in ArmVirtMemoryInitPeiLib is no > longer necessary, and can simply be dropped. > > Cc: Alexander Graf > Signed-off-by: Ard Biesheuvel Reviewed-by: Leif Lindholm > --- > .../ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c | 9 --------- > 1 file changed, 9 deletions(-) > > diff --git a/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c b/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c > index 022e13e762b6..98d90ad4200d 100644 > --- a/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c > +++ b/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c > @@ -91,15 +91,6 @@ MemoryPeim ( > ); > } > > - // > - // When running under virtualization, the PI/UEFI memory region may be > - // clean but not invalidated in system caches or in lower level caches > - // on other CPUs. So invalidate the region by virtual address, to ensure > - // that the contents we put there with the caches and MMU off will still > - // be visible after turning them on. > - // > - InvalidateDataCacheRange ((VOID *)(UINTN)UefiMemoryBase, UefiMemorySize); > - > // Build Memory Allocation Hob > InitMmu (); > > -- > 2.30.2 >