From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 92600C4332F for ; Mon, 13 Nov 2023 13:28:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=tJkiOPxZAx4Ugy1hHDXjjC/slYkvvYzT2uaVUtKsAGU=; b=cdDaL05gy0E8c3 rnaHWFU4gLtCfAlhxHl8wzPauNkJbBVNwjD3JXK2yd+k8qFyvNuMvH04E9y+wd/Z+1+gLdskIoqi5 Q2ISy/QKlDCQXlJY60VKn8YmnjRg7KnyLVKttLEwEuA4JCpQVI5Bjg8zFJzo4L1Hrf0h8qZVoBTN7 JuDAfZHw7uqivJjalNNo2kY0rVutCXMVELCaWviZ+2wyMLsS1kUffqNwLYkHCcBmD97rte8KD46/i PEL4sXf5t1LE2vPc8qlFYIchvgJDS483u5Wdhl4oxVJMwKgVIL1qGbHi6F2Dj234dCtx9cvkqvfOC OaFD14wH45nIimN+7apg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r2WyW-00E3QT-1l; Mon, 13 Nov 2023 13:27:36 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1r2WyT-00E3QA-2m for linux-arm-kernel@lists.infradead.org; Mon, 13 Nov 2023 13:27:35 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 845B360EF0; Mon, 13 Nov 2023 13:27:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 78AB9C433C7; Mon, 13 Nov 2023 13:27:29 +0000 (UTC) Date: Mon, 13 Nov 2023 13:27:26 +0000 From: Catalin Marinas To: Ryan Roberts Cc: Ard Biesheuvel , Ard Biesheuvel , Will Deacon , Marc Zyngier , Oliver Upton , Mark Rutland , Anshuman Khandual , Kees Cook , Joey Gouly , Suzuki K Poulose , James Morse , Zenghui Yu , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev Subject: Re: [RFC PATCH v1 0/3] Update tlb invalidation routines for FEAT_LPA2 Message-ID: References: <20231027115634.1432154-1-ryan.roberts@arm.com> <3800df70-73f2-44b7-a6ed-15ec0bd63f5f@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <3800df70-73f2-44b7-a6ed-15ec0bd63f5f@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231113_052733_966619_7A89C14A X-CRM114-Status: GOOD ( 32.08 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Nov 13, 2023 at 11:55:01AM +0000, Ryan Roberts wrote: > On 27/10/2023 12:56, Ryan Roberts wrote: > > As raised yesterday against Ard's LPA2 series [1], we need to address the TLBI > > changes to properly support LPA2 before Ard's changes get merged. So far those > > changes have been part of my KVM LPA2 series [2]. So this is an attempt to split > > the TLBI changes to make them independent. The idea is that this series would go > > in first, then Ard's and the rest of my series can race eachother and it doesn't > > really matter who wins. > > > > I've attempted to address all of Marc's feedback against the versions of these > > patches posted at [2], including adding benchmark data (see patch 1). Although > > if people are still nervous that this could regress non-lpa2 performance in some > > cases, I could rework so that there are lpa2 and non-lpa2 variants of > > __flush_tlb_range_op(), and the correct version is chosen at the higher level > > (based on lpa2_is_enabled() / kvm_lpa2_is_enabled()). > > > > It turns out that we won't be able to key LPA2 usage off the same static key for > > both the kernel and kvm usage because the kernel usage additionally depends on > > CONFIG_ARM64_LPA2 being enabled. So I've introduced 2 stub functions > > (lpa2_is_enabled() and kvm_lpa2_is_enabled()) to advertise it. Ard already > > defines and implements lpa2_is_enabled() in his series, so there will be a minor > > conflict to resolve there. I plan to define kvm_lpa2_is_enabled() to be the > > static key for kvm in my series. Marc, would you be happy with this approach? > > > > Anyway, I wanted to put this out there as an RFC. If we are happy with it, then > > I'll re-post on 6.7-rc1. [...] > I polite bump; I never heard back on this. I'm planning to post my LPA2/KVM > series on top of v6.7-rc1 in the next day or 2. I suspect that's what most maintainers wait for ;). Usually patches posted just before or during the merging window get ignored, unless they are urgent fixes. > By default, these 3 patches will > be the first 3 of the series. But if you have an issue with the approach it > would be good to work out an alternative plan to avoid wasting effort preparing > the series. If these patches are needed for Ard's series (I think they do), they could be posted together. But first we need to split Ard's series into at least two: reworking the memory map together with moving (some of) the init code to C and the actual LPA2 stage 1 support. We might even through LPA2 stage 2 on top if we feel brave ;). We can queue them all together but having separate series gives us an option to drop bits if needed. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel