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 30ED8C4332F for ; Mon, 13 Nov 2023 16:45:35 +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:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=vOhie6VCHOmIG2IKNCvD2v7Gpp4iSpEaNhJVIKqrRlE=; b=dICnXW+jY2KJwL LbnzQsiA/2TFUffHzx+eTcfRFLullQB86BKIier65lW22QUGWOcHbBy3AXIQV05UUmxRXYHinKKXn 7kw/mQlmCy/VaqPBMHPAqEr426prV+hq6DaZNuXS0iGX/OI+eM7LLj4nwwWggKto3glXg+h+Q8Ptq gy4beEYZAvagxG2UFusAnLTe8Druv8s7aXvPwgzqcYjLBcQbUSz8tWmncOhXGLqxGudGVq57Nqowf xg5Nsfo8NDtGGVOOO2W10Dc5MwOzPbea4mx4sJqTUO2ecW7fbrUHS5Q3X6BfdVMV0Sx+fm2NKg/1Y 16LVeRQh2BqSv4cYz7Bw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r2a3h-00ELtP-1F; Mon, 13 Nov 2023 16:45:09 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r2a3e-00ELsi-1N for linux-arm-kernel@lists.infradead.org; Mon, 13 Nov 2023 16:45:08 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B8536FEC; Mon, 13 Nov 2023 08:45:47 -0800 (PST) Received: from [10.57.73.13] (unknown [10.57.73.13]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EC3113F7B4; Mon, 13 Nov 2023 08:44:59 -0800 (PST) Message-ID: <1bdcdd85-9470-408c-aaac-fa4548bb2385@arm.com> Date: Mon, 13 Nov 2023 16:44:58 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v1 0/3] Update tlb invalidation routines for FEAT_LPA2 Content-Language: en-GB To: Catalin Marinas 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 References: <20231027115634.1432154-1-ryan.roberts@arm.com> <3800df70-73f2-44b7-a6ed-15ec0bd63f5f@arm.com> From: Ryan Roberts In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231113_084506_561578_62F469F6 X-CRM114-Status: GOOD ( 26.91 ) 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 13/11/2023 13:27, Catalin Marinas wrote: > 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. Sorry I'm not completely sure what you are suggesting I do here. In the context of the lpa2/kvm series, Marc previously said he would merge it for v6.8 if I posted against v6.7-rc1 (which is what I'm gearing up for now). My series and Ard's are independent except that they both depend on the 3 patches in this RFC. Ard has just suggested he would prefix his series with these 3 patches and I would continue to do the same, then they can be handled as 2 independent series (or more if Ard is splitting his) - the first 3 patches will just desolve to nothing for the series that goes in second. Does that work for you, are are you suggesting I should re-post this as an independent series? Thanks, Ryan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel