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::344; helo=mail-wm1-x344.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (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 F1053211B7F7A for ; Mon, 28 Jan 2019 10:01:08 -0800 (PST) Received: by mail-wm1-x344.google.com with SMTP id y185so11042548wmd.1 for ; Mon, 28 Jan 2019 10:01:08 -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=mcAubca4pH33JQxJxvtv/jBSHrT7d/xuGpMH3zhm6Ig=; b=YRpwgzbWuPlJz5Gqk6DjKTNq4PVsxbxjAxBIV0iT6Jr+uRF8imyr7KYgDCzPUXh/7t uFMeSodBJYxqfWkauoTCN1woIZSD6dyceS6XM/1WZiP1RVQBg33Qiajq6VEYFXESlkKK tHEag/ca4zGFW7WKs/sPqEzMY+gb1jUhN0saU= 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=mcAubca4pH33JQxJxvtv/jBSHrT7d/xuGpMH3zhm6Ig=; b=Gms1EHhM0LOwjjLpmLvp0UWuC0/6nCvKbxuLiku79MSKX/Pnl6CidvGQjyuPXUMrqm oioleqeiKDRFbdmmoUCUDoFBCBp+cWaMlC97DNdtEzLrD/bfIBOMrrn18aHLKr79yGFl AHtvLzXv4spQNy38qlfdM2uufmaKSXUJDM8onfRfuRahT54f52BWK9c9FEuqeKd+vlN7 PFqumnsl+vNrKwAhwLupa29m/rDU5sU2fIMNVl/QQQK8H9+0NIGqVLR8EYWgBa7x1PFe kB9jiPzXHvLg9nR07wsuzk7HoMGuGeJeQcYe/LMKGWjq14ZXcUNwIfw9dz9zgyWaDDlG zzgw== X-Gm-Message-State: AJcUukdlHWeBLjVVOgEEDw5Hxzx9GZRLqXD1gQpHZj+G3LEpw6M1I17A yRt5L4H22abq/r+TyPbLFF957g== X-Google-Smtp-Source: ALg8bN4jyMjGl92o4lFj5k9riBpbbhIFfFF8yKIU+7zRF9Ncbzj0qoyw/oA1TZ7D0KPRCYdqWPsvHw== X-Received: by 2002:a7b:c4cb:: with SMTP id g11mr17994801wmk.149.1548698466937; Mon, 28 Jan 2019 10:01:06 -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 y138sm162181wmc.16.2019.01.28.10.01.04 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 28 Jan 2019 10:01:04 -0800 (PST) Date: Mon, 28 Jan 2019 18:01:02 +0000 From: Leif Lindholm To: Ard Biesheuvel Cc: "edk2-devel@lists.01.org" Message-ID: <20190128180102.et36pybogdptwy25@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> <20190123162026.i3id7zabzmo52sin@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: Mon, 28 Jan 2019 18:01:09 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jan 28, 2019 at 01:29:54PM +0100, Ard Biesheuvel wrote: > > > > > > > @@ -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 > > > > Thanks > > GIven the discussion in the other thread regarding shareability > upgrades of barriers and TLB maintenance instructions when running > under virt, mind if I fold in the hunk below? (and add a mention to > the commit log) > > --- a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S > +++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S > @@ -35,7 +35,7 @@ > // flush translations for the target address from the TLBs > lsr x2, x2, #12 > tlbi vae\el, x2 > - dsb sy > + dsb nsh So, this one, definitely. MMU is off, shareability is a shady concept at best, so it's arguably a fix. > // re-enable the MMU > msr sctlr_el\el, x8 > @@ -58,7 +58,7 @@ ASM_FUNC(ArmReplaceLiveTranslationEntry) > // clean and invalidate first so that we don't clobber > // adjacent entries that are dirty in the caches > dc civac, x0 > - dsb ish > + dsb nsh This one I guess is safe because we know we're never going to get pre-empted or migrated (because interrupts are disabled and we don't do that sort of thing)? If that's the rationale: Reviewed-by: Leif Lindholm / Leif > EL1_OR_EL2_OR_EL3(x3) > 1:__replace_entry 1 > > The first one reduces the scope of the tlb maintenance of a live entry > to the current CPU (and when running under virt, the hypervisor will > upgrade this to inner shareable) > The second one prevents the cache maintenance from being broadcast > unnecessarily, and will be upgraded back to ish in the same way when > running under virt.