From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:4864:20::341; helo=mail-wm1-x341.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) (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 0DCC620971733 for ; Wed, 23 Jan 2019 08:20:29 -0800 (PST) Received: by mail-wm1-x341.google.com with SMTP id n190so2616655wmd.0 for ; Wed, 23 Jan 2019 08:20:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=QQVyWLeCercTQoh9ZXVCjjnBAjsWG8UwQKWLjwo8oGg=; b=U97WoH/vE/AWhKs30WH0rb9EdjUTE8wBVr/dy7LG0PnChB4bu0Kyteu+S+VOf4ZnOK 7fQYagN8n7HZQTP9oBy1WiUh2ElIo3Xm7sokQd6AY5ooJh+6FHNxnAuzk04NZgI1mA1p sDJ+2wssXq0JNprrsZi03KHquzVVqJVT9A3OI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=QQVyWLeCercTQoh9ZXVCjjnBAjsWG8UwQKWLjwo8oGg=; b=qhBSkJvMMTGbkVem9KDy8n3Zbzyc+WnQWD97Egb0OgaTf2nJKhBBlGhH+cqPTJo7HQ ceG9YZqBUWUs7x9wj4EGDow1VlI75wuKLLycMQCsgyz3zSdXt8sd6OaG8kqx5kdHzxJt SWHMRGMhEE1RL5MXCYvQUUeRWN5tmqzDo//GqHKm68ia5i6++1ubyEiBOtSW3HH/0PiJ eEyFsUHB7zun6BuHXhkr1n6qAEStDgvgH3QL+cNSaEB4EpFIVgHtWN/8dey2xfXIWlAs XAEbPvcnfTbp7q+NWhaL+yyKSr6VxG58X7hd8UejPhfXtpS3lddfSC+ueiZesnSAjKOg gXFw== X-Gm-Message-State: AJcUukeAlq+r2nLh3l34auR98BEG1I3gQQxaIDTyDmOB7/+o1/WUBVej 4wBnT1WK+nUzAULJq5wQ/Xh0OA== X-Google-Smtp-Source: ALg8bN57nge54aWowCbuHUI/OiedlxQnrtPov/S/9DAVzMdDh5/lDRwA82jSseDptZ4BBHnGDuADsQ== X-Received: by 2002:a1c:ac85:: with SMTP id v127mr3027212wme.62.1548260428417; Wed, 23 Jan 2019 08:20:28 -0800 (PST) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id x186sm74348152wmg.41.2019.01.23.08.20.27 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 23 Jan 2019 08:20:27 -0800 (PST) Date: Wed, 23 Jan 2019 16:20:26 +0000 From: Leif Lindholm To: Ard Biesheuvel Cc: "edk2-devel@lists.01.org" Message-ID: <20190123162026.i3id7zabzmo52sin@bivouac.eciton.net> References: <20190107071504.2431-1-ard.biesheuvel@linaro.org> <20190107071504.2431-3-ard.biesheuvel@linaro.org> <20190123154622.pibw6mi5gh6ywb26@bivouac.eciton.net> <20190123161257.nydm3s5c27oibn6e@bivouac.eciton.net> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [PATCH 2/5] ArmPkg/ArmMmuLib AARCH64: get rid of needless TLB invalidation X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 16:20:30 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jan 23, 2019 at 05:16:57PM +0100, Ard Biesheuvel wrote: > On Wed, 23 Jan 2019 at 17:13, Leif Lindholm wrote: > > > > On Wed, Jan 23, 2019 at 04:55:28PM +0100, Ard Biesheuvel wrote: > > > On Wed, 23 Jan 2019 at 16:46, Leif Lindholm wrote: > > > > > > > > On Mon, Jan 07, 2019 at 08:15:01AM +0100, Ard Biesheuvel wrote: > > > > > Currently, we always invalidate the TLBs entirely after making > > > > > any modification to the page tables. Now that we have introduced > > > > > strict memory permissions in quite a number of places, such > > > > > modifications occur much more often, and it is better for performance > > > > > to flush only those TLB entries that are actually affected by > > > > > the changes. > > > > > > > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > > > Signed-off-by: Ard Biesheuvel > > > > > --- > > > > > ArmPkg/Include/Library/ArmMmuLib.h | 3 ++- > > > > > ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S | 6 +++--- > > > > > ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c | 16 +++++++--------- > > > > > ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S | 14 ++++++++------ > > > > > 4 files changed, 20 insertions(+), 19 deletions(-) > > > > > > > > > > diff --git a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c > > > > > index d66df3e17a02..e1fabfcbea14 100644 > > > > > --- a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c > > > > > +++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c > > > > > @@ -129,13 +129,14 @@ STATIC > > > > > VOID > > > > > ReplaceLiveEntry ( > > > > > IN UINT64 *Entry, > > > > > - IN UINT64 Value > > > > > + IN UINT64 Value, > > > > > + IN UINT64 Address > > > > > ) > > > > > { > > > > > if (!ArmMmuEnabled ()) { > > > > > *Entry = Value; > > > > > } else { > > > > > - ArmReplaceLiveTranslationEntry (Entry, Value); > > > > > + ArmReplaceLiveTranslationEntry (Entry, Value, Address); > > > > > } > > > > > } > > > > > > > > > > @@ -296,7 +297,8 @@ GetBlockEntryListFromAddress ( > > > > > > > > > > // Fill the BlockEntry with the new TranslationTable > > > > > ReplaceLiveEntry (BlockEntry, > > > > > - ((UINTN)TranslationTable & TT_ADDRESS_MASK_DESCRIPTION_TABLE) | TableAttributes | TT_TYPE_TABLE_ENTRY); > > > > > + (UINTN)TranslationTable | TableAttributes | TT_TYPE_TABLE_ENTRY, > > > > > + RegionStart); > > > > > > > > > > /me pages in the data ... > > > > > > > OK, this whole patch took a few times around the loop before I think I > > > > caught on what was happening. > > > > > > > > I think I'm down to the only things confusing me being: > > > > - The name "Address" to refer to something that is always the start > > > > address of a 4KB-aligned translation region. > > > > Is this because the function will be usable in other contexts in > > > > later patches? > > > > > > I could change it to VirtualAddress if you prefer. > > > It is only passed > > > for TLB maintenance which is only needed at page granularity, and the > > > low bits are shifted out anyway. > > > > Yeah, exactly. It would just be nice if the name reflected that. Not > > sure VirtualAddress does. VirtualBase? PageBase? > > > > Well, the argument passed in is called RegionStart, so let's just > stick with that. Sure. With that: Reviewed-by: Leif Lindholm > > > > - Why drop the & TT_ADDRESS_MASK_DESCRIPTION_TABLE bit here? > > > > Was it just always pointless and you decided to drop it while you > > > > were at it? > > > > > > IIRC yes. It is a newly allocated page, so the masking does not do anything. > > > > Yeah, that's fair enough. > > Just made me wonder if anything unobvious was going on :) > > > > / > > Leif