Received: by 2002:a05:7208:9594:b0:7e:5202:c8b4 with SMTP id gs20csp2150381rbb; Tue, 27 Feb 2024 12:11:48 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCWyD8LksDJIKXnhKBcMVjp0IpxmbAH9WipGFR03OE7vimK3P79+aPi7JLtVSnGaxHXKbQ3AaJaRuL5pdZQpep0uFvocVISyJ/iWIzwXSw== X-Google-Smtp-Source: AGHT+IGW/pnfTEw7eRwvJyf8yVXo/45XProVMChE2LVeEnqE2v/2tMA2l+Zrpmy/m4HqWZvHM3lz X-Received: by 2002:a05:6871:33a9:b0:21e:e0d3:41b8 with SMTP id ng41-20020a05687133a900b0021ee0d341b8mr12057577oac.51.1709064708496; Tue, 27 Feb 2024 12:11:48 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709064708; cv=pass; d=google.com; s=arc-20160816; b=WXZvyir673N8+C+JouuWiwa6W5+D1+cB0MzxcwoJB+AxaLyfYQPRsr1/EpMMrI4m0r NqUOFLrM1/dK1Do0Mvs+6+YCqIlpL8UFxK5t+f4qc4HNuSSkgmaiI6RhncmhIMI9i0Eo /Fnruawm0sDrMaeTgRTGbRw2lhWgewBH781gPwSDQ6qcvTzpmKs9w6EjsGhgUWLgC9tx 7nQMLSlLYVOFzlmTKehirJxlGACpVYb9UGH9WkQx+fiTs+uSC/HIR/6p2wHXr6C0h25Z KeIEWhu2cWLIrAS1Ga6CMJwBNR56F8ZmULC0uFgYjUwHilX/tarQDlA7GN6M+1rEqWhM Y+zw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date; bh=X/6BZ8LboZUSoLOB1sSk+01qUwbPHcafNSxjUDeiLoo=; fh=TfJCtJmGTllyWOG9Iwh+8iW8qX866x1uQoaCSed7ARQ=; b=Du99xG3hUG09rflLHLgk11WQ81V4DOVzhFHDL+jlASeKGIJY1Z/zamo4zQxFEGXt7L LVLCDqWvNJtdVvKvjK3GV2UUC3Vk0/pk5PFg27onA0ZBgsc/HcTWhtEKHD++A27bGzHs 1DhKwdg9BBD7aMZStclOajfvPnvQ1jGq7lk57nTKlzuqj8xkvwx2pTno4GbbhM/KeLGP OqiSHBtVHYzxnJ50jZsg/vvuosDgYN3jtNoS9osPz8oHSmlZXaxKgwJdwYLM7r7D4v7B 06E3rYHcUmbrsnimUh+8fh9YNJbh68ueJllPeK+OF4k6E0sxQIuEvnveQ/kCw4O1yEbW PstQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-83966-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-83966-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id wk19-20020a05620a579300b0078734fe5612si8120232qkn.656.2024.02.27.12.11.48 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Feb 2024 12:11:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-83966-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-83966-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-83966-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id BDA2D1C245D5 for ; Tue, 27 Feb 2024 20:11:38 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 948BB14A4FC; Tue, 27 Feb 2024 20:11:28 +0000 (UTC) Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1525B1D6A8; Tue, 27 Feb 2024 20:11:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709064688; cv=none; b=R2sZTofyoV9KuIu1jQt9nSvoKE8H3QxQMxzpfrv4phwBjzIEDnCC/IIugvaw6vJ3fqZSM4R2N7Bwc/Jr11IumeCq+ZYKfVdBK2LKK5oiI/m/MiPk294VpITQZFMN/025krYRtZaXQCjj4eTXklGmGaAZT52kdUuX3r1d1xwTD/0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709064688; c=relaxed/simple; bh=asmb5gigKVGR1GsnUvrFAnwASHCIwvnjV+4uj7J8U7Y=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XO8SIT+jM3Haz2QOXeRwseh0r/fCICPNbwl5XASE02/bDpbS3BlswItdCYKLbsXtu8qr8Ta67jNb0t/pFaTukK8v6P0Rqu+VbqhDKCgdYivveQm+hXGb9rJ2FdMxgDVbog/9hXKVa8xL751pPZiJyl04KTEi1HUR1BlmBKgvOo0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id B399DC433F1; Tue, 27 Feb 2024 20:11:24 +0000 (UTC) Date: Tue, 27 Feb 2024 20:11:22 +0000 From: Catalin Marinas To: Oliver Upton Cc: Ganapatrao Kulkarni , kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, maz@kernel.org, will@kernel.org, suzuki.poulose@arm.com, james.morse@arm.com, corbet@lwn.net, boris.ostrovsky@oracle.com, darren@os.amperecomputing.com, d.scott.phillips@amperecomputing.com Subject: Re: [PATCH] arm64: errata: Minimize tlb flush due to vttbr writes on AmpereOne Message-ID: References: <20240207090458.463021-1-gankulkarni@os.amperecomputing.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: (catching up on emails) On Wed, Feb 07, 2024 at 09:45:59AM +0000, Oliver Upton wrote: > On Wed, Feb 07, 2024 at 01:04:58AM -0800, Ganapatrao Kulkarni wrote: > > AmpereOne implementation is doing tlb flush when ever there is > > a write to vttbr_el2. As per KVM implementation, vttbr_el2 is updated > > with VM's S2-MMU while return to VM. This is not necessary when there > > is no VM context switch and a just return to same Guest. > > > > Adding a check to avoid the vttbr_el2 write if the same value > > already exist to prevent needless tlb flush. > > Sorry, zero interest in taking what is really a uarch optimization. > The errata framework exists to allow the kernel achieve *correctness* > on a variety of hardware and is not a collection of party tricks for > optimizing any given implementation. Definitely, we should not abuse the errata framework for uarch optimisations. > Think of the precedent this would establish. What would stop > implementers from, say, changing out our memcpy implementation into a > a hundred different uarch-specific routines. That isn't maintainable, > nor is it even testable as most folks don't have access to your > hardware. I agree. FTR, I'm fine with uarch optimisations if (a) they don't run-time patch the kernel binary, (b) don't affect the existing hardware and (c) show significant gains on the targeted uarch in some meaningful benchmarks (definitely not microbenchmark hammering a certain kernel path). We did have uarch optimisations in the past that broke rule (a). We tried to make them somewhat more justifiable by creating optimisation classes (well, I think it was only ARM64_HAS_NO_HW_PREFETCH). But such changes don't scale well for maintainers, so I'd rather not go back there. So, if one wants an optimisation, it better benefits the other implementations or at least it doesn't make them worse. Now, we do have hardware from mobiles to large enterprise systems, so at some point we may have to make a call on different kernel behaviours, possibly even at run-time. We already do this at build-time, e.g. CONFIG_NUMA where it doesn't make much sense in a mobile (yet). But they should not be seen as uarch specific tweaks, more like higher-level classes of optimisations. -- Catalin