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 654BAC43458 for ; Sun, 5 Jul 2026 20:11:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=qr0T2gZ7cQ4RuZNQ+X++TNOR0UVtPP31aIo4hFrA2nc=; b=IBQEcEt19TtpKym9ZFTrQjjZyo vY2rtbaYEO5BW3GRoUD+mSDAIc9q7BVSdPeYIjhX/CkOR/FCehYXL6yTZ5fA8OZmao0id5bV1w77v wxD2177ytkWDutc/PbiSkhdWMXtKSGnGdvZr/tJErC3XS+MR9QI1O8EuAZ/f52Swd9cPvboZDQMeu 49baOK/3gkNvm20sl43RJZ1TlrHc7OY7/KOZT49BlWXJpQJ8zePDnJqBL7mHL3nQIIQuubWsvuBxy X0tOyVJjT2vTSsKcmNfcuasZclQSJjeQbLQstWXoZZ63gJxJmS4iCv+muY0W8UZg5KVhbx8qthUap JArdp1Zw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wgTBs-00000009gHj-1tfR; Sun, 05 Jul 2026 20:11:48 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wgTBq-00000009gHK-3sW3 for linux-arm-kernel@lists.infradead.org; Sun, 05 Jul 2026 20:11:47 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 3AD5560018; Sun, 5 Jul 2026 20:11:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DD4541F000E9; Sun, 5 Jul 2026 20:11:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783282304; bh=qr0T2gZ7cQ4RuZNQ+X++TNOR0UVtPP31aIo4hFrA2nc=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Ol25SDr2BpbXXiYij/EM4vhiqHYMEcnT8RbwoPGBG7U3el8XMF6H7SIi/b0t1wWsf RxzDhBpsws9jZVwLwufzy8pZQI3lduV1eEJxDYqiKrgKMUVz4TvFg1lj2Ebu6KfWVm jgaeeJyilMD/CL58B0rNmupX7y9yk73BxJOohPj4sZR6q7iXnsJTgOIBFnHwBYLgYw ZuHuxuriChiRN/kYE1bfPGh7HeeiDeqV8mnTWpP05XxnoKxqPr5Xea9T8atbsUi9iT ZSIM+BnC12EiYsirNh0NNeMMzMnaDL0Pm/CS4qEiWF8DvLfapj8Bi1j1GpFbw0NTJR iPTpltyPryf3w== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wgTBm-00000001gV0-3ET4; Sun, 05 Jul 2026 20:11:42 +0000 Date: Sun, 05 Jul 2026 21:13:31 +0100 Message-ID: <87cxx16vpw.wl-maz@kernel.org> From: Marc Zyngier To: Bradley Morgan Cc: Dev Jain , Oliver Upton , Fuad Tabba , Joey Gouly , Steffen Eiden , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , Quentin Perret , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4] KVM: arm64: Record whether pKVM stage 2 mapping is cacheable In-Reply-To: <8D464B64-27CF-4430-8F7F-9E21B77CE4D3@grrlz.net> References: <20260701192428.17430-1-include@grrlz.net> <87echh6xuh.wl-maz@kernel.org> <8D464B64-27CF-4430-8F7F-9E21B77CE4D3@grrlz.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: include@grrlz.net, dev.jain@arm.com, oupton@kernel.org, tabba@google.com, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, qperret@google.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sun, 05 Jul 2026 20:29:20 +0100, Bradley Morgan wrote: > > On July 5, 2026 8:27:34 PM GMT+01:00, Marc Zyngier wrote: > >On Sun, 05 Jul 2026 15:08:58 +0100, > >Dev Jain wrote: > >> > >> > >> > >> On 02/07/26 12:54 am, Bradley Morgan wrote: > >> > pKVM keeps its own mapping list for stage 2 operations. Its flush path > >> > uses that list directly, so it lost the PTE attribute check done by > >the > >> > generic stage 2 walker. > >> > > >> > Record whether a mapping is cacheable and skip cache maintenance for > >> > mappings that are not cacheable. > >> > > >> > Fixes: e912efed485a ("KVM: arm64: Introduce the EL1 pKVM MMU") > >> > >> Is Fixes tag required? If I am reading correctly, Arm ARM says this: > >> > >> "For VA-based cache maintenance instructions, the instruction operates > >on the > >> caches regardless of the memory type and cacheability attributes marked > >for > >> the memory address in the VMSA translation table entries. This means > >that > >> the effects of the cache maintenance instructions can apply regardless > >of: > >> Whether the address accessed: > >> Is Normal memory or Device memory. > >> Has the Cacheable attribute or the Non-cacheable attribute." > >> > >> So nothing goes wrong if we do dcache clean for non-cacheable > >> memory. > > > >Two things: > > > >- having to perform CMOs for something that is not *expected* to be > > cacheable is both pointless and a contradiction of the intent > > > >- what you quote is about the nature of the *mapping*, and not the > > memory that is being mapped. Cleaning a dirty cache line on an > > unsuspecting MMIO endpoint is never going to end nicely. Just have a > > try. > > > >My reading of all this is that a fix indeed is required, and therefore > >a Fixes tag *must* be present. > > > > M. > > > > > > > Well, fair enough. > > It's kind of two things. > > 1: A fix > 2: a optimization > > I say it's a fix, because it's not fun, no. > > And I Also say it's a optimization because wasting cycles isn't a good > idea, trust me. This is getting tiresome. Really. And when it comes to wasting cycles, you strike me as the expert here. It's not an optimisation at all. If anything, the test is going to cost cycles because there is statistically never a case that you map a device with upstream pKVM. If you call this an optimisation, I'll ask for numbers *proving* this is actually one. Do you really want to get down that road? M. -- Jazz isn't dead. It just smells funny.